2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kazumasa57

AWS認定セキュリティ専門知識(SCS-C03)に2週間弱で合格 ~本番で問われた考え方・頻出ポイント~

2
Last updated at Posted at 2026-06-14

はじめに

先日 AWS Certified Security - Specialty (SCS-C03) に合格しました :tada:

この記事は、私が試験対策中に解いた問題を1問ずつ徹底的に振り返り、「なぜ間違えたのか」「どう考えれば正解にたどり着けたのか」を言語化していった記録をまとめたものです。

勉強していて一番効いたのは、個々のサービス知識を暗記すること以上に「問題文の読み方（読み筋）」を矯正することでした。SCS-C03は「全部正しそうな選択肢から最も適切なものを選ばせる」問題が多く、知識があっても読み方を間違えると落とします。

👈 いいねやストックをいただけるとモチベにつながりますのでお願いします！

この記事では以下をまとめます。

  • :white_check_mark: 本番で繰り返し問われた「読み筋」のパターン
  • :white_check_mark: ドメイン別の重要知識（IAM / 検出 / インフラ保護 / データ保護 / インシデント対応 / ガバナンス）
  • :white_check_mark: 混同しやすいサービスの使い分け

この記事は2026年6月時点での私個人の学習記録です。試験問題そのものの転載ではなく、学んだ概念を自分の言葉で再構成しています。サービスの仕様は変わることがあるので、最終的にはAWS公式ドキュメントを確認してください。

SCS-C03の試験概要

2025年12月にSCS-C02から置き換わった新しいバージョンです。ドメイン構成と配点は以下の通り。

ドメイン 配点
1. 検出 (Detection) 16%
2. インシデント対応 (Incident Response) 14%
3. インフラストラクチャ保護 18%
4. IAM 20%（最大）
5. データ保護 18%
6. セキュリティ基盤とガバナンス 14%
  • 65問 / 170分 / 1000点満点中750点で合格 / 受験料300USD

C03の主な変更点

  • IAMが16%→20%に上昇し、単独で最大配点ドメインに。「アイデンティティが新しい境界」という思想。
  • 旧「脅威検出とインシデント対応」が 「検出」と「インシデント対応」の2ドメインに分割。
  • 新規トピック：OCSF準拠のログ統合（Security Lake）、生成AIのガードレール（Bedrock Guardrails）、リソース間の転送中暗号化、鍵管理。

【最重要】本番を貫く「読み筋」5パターン

知識よりこっちが大事でした。問題文を読んだら、選択肢を見る前にまずこれを確認します。

1. 「動詞」を先に拾う（目的の形容詞に釣られない）

問題文には「セキュリティ違反がないか確認する」のような“目的”が書かれますが、求められているのは**動作（動詞）**です。

動詞 答えるサービス
記録・保持する CloudTrail / VPC Flow Logs
状態を確認する AWS Config
検出する GuardDuty / Macie / Inspector
調査する Detective
自動修復する Config + Lambda/SSM

例：「セキュリティ違反がないか確認」という目的でも、求められている動作が「APIコールの記録・保持」なら答えは CloudTrail。「セキュリティチェック」という言葉に釣られて Trusted Advisor を選ぶと外します。

2. 影響範囲から原因の場所を特定する

全台で異常   → 共通設定を疑う（NACL・ルートテーブル・仮想アプライアンス）
1台だけ異常  → インスタンス固有の設定を疑う（SG・ALBターゲット）

「他のサーバーは正常、1台だけ接続できない」+「NACL/SGは検証済み」
→ 共通設定は除外。ENI単位のSGとALBのターゲット登録状態を疑う。

3. 「診断・調査」か「構築・作成」かを見分ける

トラブルシュート問題（原因を特定せよ）なのに「新しい構成を作る」「別アーキテクチャを提案する」選択肢は基本的に罠です。

「ログ配信が止まった原因を特定するには？」
→ 新しくKinesisを構成する、メトリクスフィルタを作る、は診断ではない。
→ エージェントの稼働確認・IAM権限確認が正解。

4. コスト・労力の制約を最初にチェック

「最も費用対効果が高い」「最小限の労力」「追加コストなし」が要件にあるなら、機能を満たす選択肢が複数あってもそこで決まります。

2,000個の認証情報を保存。Secrets Manager（$0.40/件 × 2,000 = 月$800）vs Parameter Store SecureString（ほぼ無料）。
→ ローテーション要件がなければ Parameter Store が費用対効果で勝つ。

5. 状況描写から背景概念を引き出す（行間を読む）

C03の難問はキーワードを直接書きません。状況描写から概念を連想します。

問題文の描写 読み取るべき概念
外部監査機関が複数顧客アカウントにアクセス Confused Deputy → External ID
全リージョン+将来も自動カバー All-region trail（マルチリージョン証跡）
ペイロードの中身を検査 プロキシ / ホストベースエージェント
追加コストなし + クォータ超え OSのホストベースファイアウォール
別リージョンで同じKMSキーで復号 マルチリージョンキー

ドメイン1: IAM（20%・最重要）

SCPの評価とRootユーザーへのGuardrail

  • SCPは Organizations Root → OU → アカウント の順に継承される
  • 明示的Denyが最優先
  • :star: RootユーザーもSCPで制限できる（IAMポリシー・Permission BoundaryはRootに効かない）

ただしSCPは「管理アカウント（master account）」自体には効きません。

クロスアカウント vs 単一アカウント

クロスアカウント : アカウントA・Bの両方でAllowされたアクションのみ実行可能（AND条件）
単一アカウント   : 許可された全アクションがAllow（OR条件）。拒否は明示的Denyが必要

Confused Deputy（混乱した代理人）対策

サードパーティが複数顧客アカウントへAssumeRoleするときの典型対策。

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "12345" }
  }
}

「外部サードパーティ × 複数アカウント」を見たら External ID を連想する。AssumeRole失敗の原因としても問われる（External IDの不一致・未指定）。

AssumeRole失敗の3大原因

原因 確認場所
sts:ExternalId が未指定/不一致 ターゲットロールの信頼ポリシー
sts:AssumeRole 権限がない 呼び出し側のIAMポリシー
ロールARNが間違い/存在しない AssumeRole APIのパラメータ

Permission Boundary

  • IAMエンティティに付与できるアクセス許可の上限を定義
  • 「IAMユーザー/ロールを作成する権限は委譲するが、管理者権限の付与は防ぎたい（権限エスカレーション防止）」→ Permission Boundary

IAM Access Analyzer

  • 意図しない外部アクセスと未使用の権限を自動検出
  • 未使用権限は「これ使われてないですよ」と提案するだけ（自動削除はしない）
  • 検出後の例
    • EventBridge⇒SNSで自動メール配信
    • EventBridge⇒Lambdaで自動処理
    • SecurityHubに紐づけて検出内容をほかの検出内容と一緒にDashboardで表示
  • ポリシーの構文・ベストプラクティス検証、最小権限ポリシーの自動生成も可能

補足

Domain1（検出）

  • 検出系は「何を検出するか」で切り分け：機密データ=Macie / 脆弱性=Inspector / 脅威=GuardDuty
  • GuardDutyはログを自分で有効化しなくても動く
  • Detectiveだけ EventBridge に直接つながらない

ドメイン2: 検出（16%）

ConfigとCloudTrailの違い:star:

  • AWS Config = 設定（状態）の履歴：「その時点でどういう設定だったか」
  • AWS CloudTrail = 操作（API）の履歴：「誰が・いつ・何をしたか」

「インシデントの前後でIAM権限への変更を監査」
→ 状態の前後比較なので Config。

「監査」という言葉で「犯人捜し → CloudTrail」と連想しがちですが、監査の“対象”がWhat（状態）かWho（操作者）かで分岐します。

監査の対象 サービス
状態・設定（何がどうなっていたか） Config
操作・行為者（誰が「APIで」何をしたか） CloudTrail

マルチリージョン証跡

「現在および将来のリージョンを、最もシンプルにカバー」
→ リージョンごとに個別証跡を作る選択肢は「将来カバー」で脱落。
→ all-region trail を1つ作って全リージョンに適用。
→ マルチアカウントなら Organization Trail。

各検出サービスの守備範囲

サービス 役割
GuardDuty 脅威・不審なアクティビティの検出（CloudTrail/VPC Flow Logs/DNSログ等を分析。エージェント不要）
Macie S3内の機密データ（クレカ番号・健康情報等）をMLで検出・分類
Inspector CVE脆弱性スキャン（EC2 / ECR / Lambda）
Detective 検出結果をもとに根本原因・影響範囲を調査（検出ツールではない）
Security Hub 検出結果をASFF形式で一元集約（CSPM）
Security Lake 生のセキュリティログをOCSF形式で集約 → Athenaで分析

Security Hub と Security Lake の違いは新出題ポイント。

  • 「ASFF・検出結果の集約・CISベンチマーク」 → Security Hub
  • 「OCSF・生ログ・Athenaで分析」 → Security Lake

「EventBridge経由で通知/自動修復」「Security Hubへ集約」という連携パターンは、
IAM AccessAnalyzer/GuardDuty/Macie/Config など検出系サービスに共通です。
（ただし Detective だけは調査ツールのため、EventBridgeに直接はつながりません）

Configマネージドルール（覚えておくと強い）

  • cloudtrail-enabled（CloudTrailが無効になっていないか）
  • iam-root-access-key-check（rootにアクセスキーが存在しないか）
  • restricted-ssh（ポート22の無制限開放）
  • s3-bucket-public-read-prohibited

ドメイン3: インフラストラクチャ保護（18%）

Security Group vs Network ACL

Security Group Network ACL
適用単位 ENI（インスタンス） サブネット
性質 Stateful（戻り自動許可） Stateless
戻りトラフィック 自動的に許可 明示的にルールが必要
Deny/Allow Allowのみ Deny/Allow両方

:star:NACLは Stateless なので、HTTPレスポンスを返すにはアウトバウンドでエフェメラルポート（1024-65535）を許可する必要があります。応答の宛先はHTTPポート(80)ではなくクライアントのエフェメラルポートです。

SGはAllowのみしか書けないので、特定のIPアドレスからの通信を拒否したい場合はSGではできないのでNACLを使う。両方使う(Subnet単位で大まかにDenyをNACLでガードレール的に制御し、ENI単位のSGで細かくAllowを制御する)多層防御が実務的。

VPC Peering

異なるVPC間（EC2↔EC2など）をプライベートに接続する仕組み。S3などVPC外のリソースへのアクセス経路にはならない点に注意。

VPC Peering経由でEC2間通信するには、SGだけでなく「ルートテーブル」の設定が必須。

① VPC Peering接続を確立
② ルートテーブルに相手VPCへのルートを追加（両VPC）
   VPC A：10.1.0.0/16 → pcx-xxxxx
   VPC B：10.0.0.0/16 → pcx-xxxxx
③ Security Group
   - 起点側：アウトバウンド許可
   - 受信側：インバウンド許可（Statefulなので戻りは自動許可）

SGを正しく設定してもルートテーブルに経路がないと通信できない。

受信側SGのソースは、CIDR（VPC全体）よりも**SG参照（相手のSG ID）**を使うとより厳密に絞れる（同一リージョンのPeeringの場合）。

NATゲートウェイ

  • :warning: アウトバウンド専用（出口）。インバウンド（外からの攻撃）の制御やWeb攻撃防御の機能はない
  • 「インバウンドにNATゲートウェイ」という選択肢は即脱落

VPCエンドポイント

Gateway型 Interface型
料金 無料 有料
対応サービス S3 / DynamoDB ほぼ全サービス
仕組み ルートテーブル ENI + PrivateLink
オンプレからのアクセス 不可（プロキシ必須） 可能
SGの適用 不可 可能

「オンプレから（DX経由で）プロキシなしでS3/DynamoDBへ、SGで制御したい」→ DX + PrivateLink + Interface VPC Endpoint。

DynamoDBは以前 Gateway型のみでしたが、現在はInterface型（PrivateLink）にも対応しています（DynamoDB StreamsはInterface型のみ）。

エンドツーエンド暗号化 / 転送中暗号化

「カスタムプロトコル」+「全区間を暗号化（E2E）」
→ NLB（TCPリスナー）で透過転送 + EC2でTLS終端
→ ALBはHTTP/HTTPS専用なのでカスタムプロトコル不可、即脱落

  • SSL/TLS終端 = その地点で復号すること（SSLとTLSは同義。TLSはSSLの後継）
  • NLBで終端するとNLB→EC2間が平文になりE2Eにならない
  • E2Eにしたいなら最終送信先（EC2）でTLS終端

「転送中暗号化を最小限の労力で」
→ ACM（無料・自動更新）+ ELB（HTTPSリスナーに証明書をプロビジョニング）

多層防御（Defense in Depth）の全体像

インターネット
  │
[L3/4/7] Shield Advanced … DDoS自動検知・緩和
  │
[L7]     WAF（ALBに関連付け）… SQLi/XSS/ボット
  │
[L3-7]   Network Firewall … IDS/IPS・カスタムルール
  │
[L3/4]   NACL（Stateless・サブネット単位）
  │
[L3/4]   Security Group（Stateful・ENI単位）
  │
EC2
  │
[OS層]   iptables/nftables・ホストベースエージェント

「追加コストなし + SG/NACLのクォータ超え + インスタンス間通信制御」→ OSのホストベースファイアウォール（iptables/nftables）。AWSのサービス上限と無関係に、無料で複雑なルールを実装できる。

ペイロードを検査できるか

サービス ペイロード（中身）
VPC Flow Logs / CloudTrail / ELBアクセスログ :x: メタデータのみ
プロキシサーバー（Squid等） :white_check_mark: 中身を検査可能
ホストベースエージェント（HIDS/EDR） :white_check_mark: リアルタイム検査
VPC Traffic Mirroring :white_check_mark: パケットコピーで深く分析

WAF / Shield（DDoS・Web攻撃対策）

「どのレイヤーの、どんな攻撃を防ぐか」で使い分ける。

サービス 対象レイヤー 防ぐもの
Shield Standard L3/L4 DDoS（SYN/UDPフラッド、リフレクション攻撃）。全アカウント無料・自動有効
Shield Advanced L3/L4 + L7 高度なDDoS（HTTPフラッド等）。有料。WAFと連携
WAF L7のみ SQLインジェクション、XSS、ボット、レート制限
Network Firewall L3〜L7 IDS/IPS・カスタムルール・ドメインフィルタリング

「DDoS対策」と来たら Shield、「Webアプリ攻撃（SQLi/XSS/ボット）」と来たら WAF。
両者は役割が違うので、高度な要件では併用する（Shield Advanced + WAF）。

WAF（Web Application Firewall）

L7のWebアプリ攻撃を防ぐ。中心は Web ACL。

ルールで制御できる項目 例
送信元 IPアドレス・CIDR範囲・地理的位置（国）
HTTPリクエスト ヘッダー・クエリ文字列・URIパス・ボディサイズ・メソッド
攻撃シグネチャ SQLインジェクション・XSS
リクエストレート レート制限・ブルートフォース・DoS 
マネージドルール：AWSが自動更新（OWASP Top10・既知の脆弱性・ボット対策等）
カスタムルール  ：地理的位置・IPなどユーザー独自に定義

WAFを関連付けられるのは ALB / CloudFront / API Gateway など。
EC2に直接は関連付けられない（前段のALB/CloudFrontに付ける）。

Shield

DDoS攻撃からAWSリソースを保護するマネージドサービス。

Shield Standard Shield Advanced
料金 無料・自動有効 有料
レイヤー L3/L4 L3/L4 + L7
防御例 SYN/UDPフラッド、リフレクション攻撃 + HTTPフラッド、DNSクエリフラッド
WAF連携 ❌ ✅
DRT（DDoS対応チーム） ❌ ✅ 24/365サポート

Shield Advancedの保護対象は CloudFront / Route53 / ELB / Global Accelerator / EC2に紐づくEIP。
「L7のDDoS（HTTPフラッド）も防ぎたい」「DDoS発生時の専門サポート（DRT）が欲しい」→ Shield Advanced。

Firewall Manager（複数アカウントのファイアウォール一元管理）

複数のAWSアカウントにまたがって、各種ファイアウォール・セキュリティ設定を一元的に管理するサービス。「アカウントが増えるたびに個別設定するのは大変」を解決する。

管理できる対象

対象
AWS WAF（Web ACL）
AWS Shield Advanced
VPC Security Group
AWS Network Firewall
Route53 Resolver DNS Firewall

利用の前提条件

Firewall Managerを使うには以下が必要。

  • AWS Organizations に参加している
  • AWS Config が有効になっている
  • Firewall Manager の管理者アカウントを指定する

ポリシーの適用範囲

適用先を柔軟に指定できる：
- 組織単位（OU）
- 特定のアカウント
- タグが付いたリソース

新しいアカウントやリソースが追加されても、ポリシーが自動的に適用されるのが強み。

「組織全体・複数アカウントに、WAF/Shield/Network Firewall/SGのルールを統一して適用したい」→ Firewall Manager。
検出結果は Security Hub に送信することも可能。

ACM（証明書管理）と CloudFront / ALB の組み合わせ

ACM（AWS Certificate Manager）は SSL/TLS証明書の発行・更新・管理を行うサービス。転送中暗号化（HTTPS）の要となる。

ACMの基本

項目 内容
パブリック証明書 無料・自動更新。一般的なHTTPS化に使う
プライベート証明書 ACM PCA（Private CA）で発行。有料。社内システム・IoTデバイス間通信など閉じた環境向け
検証方法 DNS検証（推奨・自動更新）/ メール検証（手動更新）
認証レベル ドメイン認証型（DV）

ACM証明書を関連付けられるのは CloudFront / ELB（ALB/NLB）/ API Gateway など。
EC2には直接関連付けできない（EC2にはOS内に証明書を手動でインストールする）。

典型構成：CloudFront → ALB → EC2 のTLS

:star:3層構成での証明書の付け方はよく間違えやすいポイント。各区間で別々に証明書を用意するのがポイント。

Client ──HTTPS──▶ CloudFront ──HTTPS──▶ ALB ──HTTPS──▶ EC2
            ①              ②              ③
区間 証明書 発行元 ACMで発行できるか
① Client→CloudFront パブリック証明書 ACM（us-east-1で発行） ✅
② CloudFront→ALB パブリック証明書（リージョンのACM） ACM ✅
③ ALB→EC2（内部通信） プライベート/自己署名証明書 認証局 or 自己署名 ❌ ACM不可

CloudFrontに付けるACM証明書は必ず us-east-1（バージニア北部）で発行する必要がある。
リージョナルなALBに付ける証明書は、そのALBと同じリージョンのACMで発行する。

ALB→EC2 の内部通信を暗号化したい場合、ACMでは証明書を発行できない。
プライベートCA発行の証明書か自己署名証明書をEC2側に用意する必要がある（ACM PCAを使う手もある）。

転送中暗号化を「最小限の労力」で実現

「Webサーバーへの転送中暗号化を最小限の労力で」
→ ACM（無料・自動更新）+ ELB（HTTPSリスナーに証明書をプロビジョニング）

ACM ──証明書（自動更新）──▶ ELB（ALB）のHTTPSリスナー
                                    ↓
Client ──HTTPS（暗号化）──▶ ALB ──▶ EC2

IAM証明書ストアにサードパーティ証明書をアップロードする方法もあるが、有効期限管理・更新が手動になり「最小限の労力」に反する。ACMなら無料・自動更新で済む。

ドメイン4: インシデント対応（14%）

侵害されたクレデンシャルの対応順序

1. アクセスキーを無効化
2. CloudTrailで影響範囲を特定
3. 不正に作成されたリソースを削除
4. 新しいクレデンシャルを発行
5. 根本原因を調査

侵害されたEC2の対応

1. スナップショット取得（証拠保全）
2. SGでネットワーク隔離
3. 別インスタンスにアタッチしてフォレンジック調査
4. 元インスタンスを終了

鉄則は 「まず隔離・無効化、後で調査」。証拠保全のスナップショットを忘れずに。

検出→自動修復の典型フロー

GuardDuty / Macie / Config（検出）
        │
Security Hub（ASFFで集約）
        │
EventBridge（イベントルール）
        │
Lambda（自動修復） / SNS（通知）
  • Config = 状態ベース（望ましくない状態を継続監視）
  • EventBridge = イベントベース（StopLoggingされた瞬間に反応）
  • ConfigはSSM Automation経由でEventBridgeなしでも自動修復できる
  • CloudTrailは記録するだけ。イベント検出・トリガーはEventBridgeの役割

ドメイン5: データ保護（18%）

KMSの2層構造（ :star:エンベロープ暗号化 ）

キーマテリアル（CMKの中身。外に出ない）
  │ DEKを暗号化する
CMK（カスタマーマスターキー）
  │ GenerateDataKeyで都度生成
DEK（データキー = 一意の共通鍵）
  │ 実際のデータを暗号化する
データ
  • CMK = DEKを暗号化する親鍵、DEK = データを暗号化する子鍵
  • 「すべてのオブジェクトを一意のキーで暗号化」の「キー」はDEKのこと。SSE-KMSはオブジェクトごとに一意のDEKを自動生成するので、CMKは1つ（データ分類ごと）でOK

自動キーローテーションの可否

キータイプ 自動ローテーション
CMK（KMS生成） :white_check_mark: 可能・設定可能（90日〜7年）
AWSマネージドキー :warning: 自動だがユーザー設定不可
BYOK（外部インポート） :x: 不可
CloudHSM/XKS・非対称CMK :x: 不可

「365日ごとに確実にローテーションされなければならない」というポリシー要件なら、ユーザーがコントロールできる CMK（KMS生成）一択。AWSマネージドキーは「約365日」で保証されず、設定も変更できないので不適。

BYOK（Bring Your Own Key）のローテーション方法

BYOKは自動ローテーション不可、既存CMKへのキーマテリアル上書きも不可。

1. 新しいキーマテリアルを外部で生成
2. 新しいCMKを作成（オリジン=外部）
3. 新CMKに新マテリアルをインポート
4. キーエイリアスを新CMKに向け直す ← アプリのコード変更なしで切り替え

キーエイリアス（Alias）を設定するのがポイント。

アプリがキーID/キーARNで直接CMKを指定していると、ローテーションのたびに新しいCMKのIDを設定し直す必要がある。

対してエイリアスを使えば、新しいCMKを作成してエイリアスの向き先を付け替えるだけで、アプリ側はコード変更なしに新しいキーへ切り替えられる。

（BYOKは既存CMKへのキーマテリアル上書きが不可なので、ローテーション=新CMK作成+エイリアスの付け替え、となる）

マルチリージョンキー

「プライマリで暗号化したデータを別リージョンで復号したい」
→ CMKは直接コピーできない。マルチリージョンキー（同じKeyID・キーマテリアルを持つプライマリ + レプリカ）を使う。

EC2起動と暗号化EBS

暗号化EBSをアタッチしたEC2が「Pending→Stopped」を繰り返す
→ EC2サービスがKMSグラントを作成するための権限不足

必要な権限とベストプラクティス条件：

{
  "Effect": "Allow",
  "Action": "kms:CreateGrant",
  "Resource": "arn:aws:kms:...:key/...",
  "Condition": {
    "Bool": { "kms:GrantIsForAWSResource": "true" }
  }
}

KMSエラーのトラブルシュート

「権限は適切」と書かれている場合、疑うのはキーそのもの。

状態 エラー
Disabled / PendingDeletion KMSInvalidStateException
削除済み（存在しない） NotFoundException

CMKの指定は KeyID / Key ARN / Alias / Alias ARN のどれでも有効。「ARNでなくKeyIDを使っているからエラー」という選択肢は誤り。

Secrets Manager vs Parameter Store

Secrets Manager Parameter Store(SecureString)
自動ローテーション あり なし
暗号化 必須 オプション
コスト 有料（シークレット単位） 基本無料
用途 RDS等のDB認証情報 設定データ・環境変数

KMSは「鍵を管理する場所」であって「認証情報を保存する場所」ではありません。認証情報の保存先としてKMSを選ぶ選択肢は誤り。保存先はSecrets Manager / Parameter Store。

EC2とLambdaへのIAMロールのアタッチ

  • EC2 → インスタンスプロファイル経由でアタッチ
  • Lambda → 実行ロール（Execution Role）として直接設定
  • :warning: インスタンスプロファイルはEC2専用。Lambdaにはアタッチできない

S3のセキュリティ要件 3点セット

要件 設定
転送中暗号化 バケットポリシーで aws:SecureTransport: false をDeny
保管時暗号化 S3デフォルト暗号化（SSE-S3 / SSE-KMS）
GetObjectのログ CloudTrailのデータイベントを有効化 
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::bucket/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

コンプライアンス・監査要件がある環境では SSE-KMS がほぼ一択。鍵を顧客管理でき、鍵アクセスがCloudTrailに残るため監査要件を満たせます。

補足

「平文通信を拒否して暗号化を強制する」設定パターン

サービス 設定
S3 バケットポリシーで aws:SecureTransport: false を Deny
RDS/Aurora(MySQL) パラメータグループで require_secure_transport = ON
RDS/Aurora(PostgreSQL) rds.force_ssl = 1
EMR Security Configuration で通信暗号化を有効化
ELB HTTPSリスナー + ACM証明書

→ 「転送中暗号化を必須にしたい」という要件で、サービスごとにこの設定が問われる。

Domain5（データ保護）

  • S3暗号化：SSE-C（鍵を保存しない）/ CSE（送る前に暗号化）が狙われる
  • 「誰も削除させない」→ Object Lock コンプライアンスモード
  • 「FIPS Level 3・鍵を完全制御」→ CloudHSM
  • KMSは鍵管理、認証情報の保存はSecrets Manager/Parameter Store

ドメイン6: ガバナンス（14%）

  • 予防的ガードレール = SCP（実行を防ぐ） / 発見的ガードレール = AWS Config（逸脱を検出）
  • Control Tower = Landing Zoneを自動構築し、Organizations + Config + CloudTrailを統合
  • Firewall Manager = 複数アカウントのWAF / Shield Advanced / Network Firewall等を一元管理（Organizations参加 + Config有効化が必要）

Route53のルーティングポリシー

「何を基準に振り分けるか」で覚えると迷いません。

ポリシー キーワード
フェイルオーバー 障害時に切り替え（ヘルスチェック必須）
位置情報 国・地域で振り分け（コンテンツ差異・特定国の遮断）
地理的近接性 物理的に最も近いサーバーへ
IPベース 送信元IPで振り分け
加重 比率指定（ABテスト・段階的移行）
複数値回答 ランダム・最大8つ
シンプル 1対1の基本ルーティング

Route53 Resolver DNS Firewall は、VPCから出ていくDNSクエリをフィルタリングし、悪意あるドメインへのアクセスを ALLOW/BLOCK/ALERT で制御できます。「悪意あるドメインへのアクセスをブロックしたい」場合の答え。

Trusted Advisor（ベストプラクティスの推奨）

AWSアーキテクチャを分析し、ベストプラクティスに従うための推奨事項を提供するサービス。「検出」ではなく「アドバイス」がポイント。

5つのチェックカテゴリ

カテゴリ チェック内容の例
コスト最適化 低使用率のEC2、関連付けられていないEIP
パフォーマンス 高負荷インスタンス、過剰なSGルール
セキュリティ アクセスキーのローテーション、MFA、無制限アクセスの有無、パスワードポリシー
耐障害性 SPOF・AZバランス、ロードバランサー最適化
サービスクォータ 使用率が80%を超えていないか

できること・できないこと

✅ ベストプラクティスに基づいた推奨事項を提示
✅ Security Hubに検出結果を統合可能
✅ Business/Enterpriseサポートで包括的なチェック（Basic/Developerは一部のみ）

❌ ユーザー独自のカスタムルール追加・編集はできない
❌ リアルタイムの脅威検出はしない
❌ 自動修復のトリガーには不適（定期チェックのため）

Trusted Advisorは「検出」ツールではなく「推奨（アドバイス）」ツール。
「APIコールを記録・保持したい」→ CloudTrail、「リアルタイムに脅威を検出・自動修復したい」→ GuardDuty/Config + EventBridge であり、Trusted Advisorは当てはまらない。検出系の問題に「それっぽい選択肢」として紛れ込むので注意。

「セキュリティのベストプラクティスに沿っているか、推奨事項を確認したい」という定期的な改善・最適化の文脈なら Trusted Advisor。

まとめ

試験直前チェックリスト（折りたたみ）
  • SCPはRootユーザーも制限できる（ただし管理アカウントには効かない）
  • クロスアカウントはAND条件
  • Confused Deputy → External ID
  • Config=状態 / CloudTrail=操作
  • Security Hub=ASFF / Security Lake=OCSF
  • NACLはStateless・エフェメラルポート必須
  • NATは出口専用
  • Interface型VPC Endpoint=オンプレOK・SG可
  • E2E暗号化=NLB + EC2でTLS終端
  • CMK生成のみ自動ローテーション可・BYOKは不可
  • KMSは鍵管理、認証情報の保存はSecrets Manager/Parameter Store
  • Lambdaは実行ロール、EC2はインスタンスプロファイル
  • 別リージョンで同じKMSキー → マルチリージョンキー
  • 侵害時はまず隔離・無効化、証拠保全のスナップショット

これから受験する方の参考になれば嬉しいです。:muscle:
最後まで読んでいただきありがとうございました。誤りやご指摘があればコメントで教えていただけると嬉しいです。

2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?