横断整理・サービス選択・試験戦略

SCS-C03試験に合格するために最後に必要なのは、サービスを個別に理解すること ではなく、それらがどう組み合わさるか、どう選び分けるかを戦略的に理解すること です。

本講では、これまでの14講を横断的に整理し、試験で頻出の「サービス選択問題」と「シナリオ別の最適構成」に対応するための総合的な思考フレームワークを構築します。

1. SCS-C03 全体像: ドメイン別・サービス役割マッピング

1-1. 5つのドメインの全体像

SCS-C03は5つのドメインで構成されます。各ドメインがカバーするサービスと、それらの相互関係を理解することが出発点です。

ドメイン	比重	中核サービス	補助サービス
ドメイン1: 脅威検出とインシデントレスポンス	26%	GuardDuty, Security Hub, Inspector	CloudTrail, Lambda, Systems Manager
ドメイン2: セキュリティロギングとモニタリング	25%	CloudTrail, VPC Flow Logs, CloudWatch	S3 (ログ保存), Athena, EventBridge
ドメイン3: インフラストラクチャセキュリティ	25%	VPC, Security Groups, NACL, WAF	Shield, DDoS Protection, Network Firewall
ドメイン4: IAMとアクセス管理	15%	IAM, STS, Cognito, Identity Center	KMS (キー管理統合), Directory Service
ドメイン5: データ保護	9%	KMS, CloudHSM, Secrets Manager, S3 Encryption	Parameter Store, ACM, TLS/SSL

SCS-C03 5ドメイン全体図

Loading diagram...

1-2. 脅威検出とインシデントレスポンスドメイン

このドメインの核心は、「検出→分類→調査→修復」のフロー全体を実装できるか という一点に尽きます。

サービス役割の整理

┌─────────────────────────────────────────────────────────────┐
│         脅威検出とインシデントレスポンス フロー              │
├─────────────────────────────────────────────────────────────┤
│                                                               │
│  [検出層]  → GuardDuty, Inspector, Macie, Config           │
│  ↓ (シグナル)                                                │
│  [統合層]  → Security Hub (全シグナルを一元集約)           │
│  ↓ (知見)                                                    │
│  [調査層]  → CloudTrail (証拠), VPC Flow Logs (通信)       │
│  ↓ (対応の意思決定)                                         │
│  [修復層]  → Systems Manager, Lambda (自動修復)            │
│            IAM修正, SG更新, EBS削除など                     │
│                                                               │
└─────────────────────────────────────────────────────────────┘

各検出サービスの責務を言語化

サービス	検出対象	検出粒度	修復の容易さ
GuardDuty	ネットワークレベルの異常（通信パターン）	アカウント/リージョン単位	△ (手動が多い)
Inspector	EC2/ラムダのサスペンス（脆弱性)	リソース単位	△ (報告が主)
Macie	S3内のセンシティブデータ漏えい	オブジェクト単位	✅ (SCP/ACLで制御)
Config	インフラのドリフト（期待値からの乖離）	リソース単位	△ (Remediation可)
Security Hub	上記全ての統合・正規化	アカウント横断	✅ (統合後のアクション)

1-3. セキュリティロギングとモニタリングドメイン

このドメインの本質は、「何を、どこに、どう長く保存し、どう検索・分析するか」 という設計です。

ログの種類別・配信先マッピング

ログの種類              → CloudTrail
  ↓ (API呼び出し)
  → EventBridge (リアルタイム検知)
  → S3 (長期保存 + Athena検索)

VPC Flow Logs           → CloudWatch Logs
  ↓ (ネットワーク通信) 
  → S3 Parquet形式 (Athena クエリ)

ALB/NLB アクセスログ    → S3
  ↓
  → Athena (分析)
  → CloudWatch Logs Insights (リアルタイム)

WAF ログ                → CloudWatch Logs または S3
  ↓
  → VPC Flow Logs との関連付け分析

CloudWatch ロジック      → Metric Filters
  ↓
  → SNS/SQS (アラート・イベント)

Config 変更ログ         → CloudTrail + S3
  ↓
  → SecurityHub (統合)

ロギングアーキテクチャの3つのレイヤー

レイヤー	役割	サービス	保持期間
リアルタイム層	異常を即座に検知・アクション	EventBridge + Lambda	制限なし（リアルタイム）
分析層	事後分析・トレンド把握	S3 + Athena, CloudWatch Insights	1-3か月（ホット）
保管層	コンプライアンス保証	S3 Glacier, S3 Glacier Deep Archive	7年以上（コールド）

設計のポイント

CloudTrail はAWS APIの監査証拠。必ず有効化。
VPC Flow Logs はネットワークの目。東西通信の検知に不可欠。
Config はリソース状態の履歴管理。ドリフト検知に活用。

1-4. インフラストラクチャセキュリティドメイン

ネットワークセキュリティは、多層防御 が原則です。どの層の脅威に対応するかで、選択すべきサービスが決まります。

多層防御の全体図

層ごとのサービス選択マトリクス

防御層	脅威	主要サービス	代替/補助
エッジ層	DDoS大規模	Shield Standard, Shield Advanced	CloudFront + WAF
DNS層	DNS Amplification	Route 53 DNSSEC, Shield	Resolver DNS Query Logging
アプリ層	SQL Injection, XSS	WAF (CloudFront/ALB/API Gateway)	API Gateway リソースポリシー
VPC Entry	不正トラフィック	Security Group (Stateful)	Network Firewall (Stateless + IDS)
Subnet	横展開、East-West	NACL (Stateless)	Security Group (細粒度制御)
Instance	OS脆弱性、ポートスキャン	Inspector, Systems Manager Patch	GuardDuty (異常検知)
ストレージ	データ盗難	EBS/S3 Encryption (KMS)	Secrets Manager, Parameter Store

選択の指針

WAF: アプリケーション層の攻撃（SQLi, XSS, CSRF）に対応。CloudFront, ALB, API Gateway に付与。
Security Group: ステートフル。戻り通信は自動で許可。EC2インスタンスの最初の砦。
NACL: ステートレス。サブネット全体に適用。明示的な戻り規則が必要。
Network Firewall: IDS/IPS機能を持つ。ネットワークトラフィックの詳細検査が必要な大規模環境向け。

1-5. IAMとアクセス管理ドメイン

アクセス管理は、認証（Authentication）と認可（Authorization） の2つの層から成ります。各レイヤーでの選択が試験の重要論点です。

認証・認可の全体像

┌────────────────────────────────────────────────────────────┐
│                   認証層（Authentication）                   │
├────────────────────────────────────────────────────────────┤
│                                                              │
│  AWS内部ユーザー              → IAM Users / Root             │
│  一時的なセッション           → STS (AssumeRole)            │
│  クロスアカウント             → Cross-Account IAM Role      │
│  フェデレーション（SAML/OIDC）→ Identity Federation        │
│  組織管理（AWS内）            → AWS Identity Center        │
│  エンタープライズSSO          → Directory Service (AD)      │
│  モバイル/Webアプリ          → Amazon Cognito (User Pools) │
│  AWS API呼び出し              → AssumeRole + Credentials    │
│                                                              │
└────────────────────────────────────────────────────────────┘
                           ↓
┌────────────────────────────────────────────────────────────┐
│                   認可層（Authorization）                     │
├────────────────────────────────────────────────────────────┤
│                                                              │
│  IAM Policy Evaluation Engine                              │
│  (Explicit Deny → Default Deny → Allow評価)                │
│                                                              │
│  ┌──────────────────────┐  ┌──────────────────────┐        │
│  │ Identity-based       │  │ Resource-based       │        │
│  │ (ユーザー/ロール側) │  │ (リソース側)         │        │
│  │ - IAM Policy         │  │ - S3 Bucket Policy   │        │
│  │ - Permission Boundary│  │ - KMS Key Policy     │        │
│  │ - Session Policy     │  │ - Resource Policy    │        │
│  │ - SCP               │  │ - Trust Policy       │        │
│  └──────────────────────┘  └──────────────────────┘        │
│                           ↓                                  │
│  ┌─────────────────────────────────────┐                   │
│  │ ✅ Allow / ❌ Explicit Deny / △ Default Deny            │
│  └─────────────────────────────────────┘                   │
│                                                              │
└────────────────────────────────────────────────────────────┘

サービス選択マトリクス: IAM系サービス

ユースケース	最適サービス	理由	避けるべき選択
単一AWSアカウント内のアクセス制御	IAM Policy + Permission Boundary	セキュリティモデルの基本。精密制御可能	SCP（組織全体向け）
複数アカウント間の権限委譲	AssumeRole (クロスアカウントIAM Role)	一時認証情報を安全に交換。監査可能	ルートアカウント共有（✕絶対禁止）
組織全体のセキュリティポリシー強制	SCP (Service Control Policy)	すべてのアカウント・ユーザーに適用。上書き不可	IAM Policy（個別設定が必要）
AWS内エンタープライズSSO	AWS Identity Center	IAM Identity Center に統合。一元管理	個別IAMユーザー管理（スケール不可）
Cognito User Poolsの権限制御	Cognito User Groups / OIDC FedLink	モバイル・Web向けアプリの認可	IAM（アプリ層ユーザーに非対応）
Cross-Account + SAML/OIDC	Identity Federation via STS	エンタープライズディレクトリとの統合	手動IAMユーザー管理
一時認証情報の短期発行	STS AssumeRole	セッションベースの権限。自動失効	長期アクセスキー（セキュリティリスク）
リソースへの直接アクセス制御	Resource-based Policy (S3, KMS等)	リソース側で受け入れ元を指定	IAM Policy のみ（一方向）

1-6. データ保護ドメイン

データ保護は、「保存時」「転送時」「使用時」 の3つの状態で実装されます。

暗号化の全体像

┌─────────────────────────────────────────────────────────────┐
│                    保存時暗号化（Encryption at Rest）         │
├─────────────────────────────────────────────────────────────┤
│                                                               │
│  EC2 EBS Volume        → EBS Encryption (KMS Managed)       │
│  RDS Database          → RDS Encryption (KMS Managed)       │
│  DynamoDB Tables       → DynamoDB Encryption (KMS)         │
│  S3 Objects            → SSE-S3, SSE-KMS, SSE-C             │
│  ElastiCache           → ElastiCache Encryption (Redis)     │
│  Secrets Manager       → KMS (自動) + コンプライアンス      │
│  Parameter Store       → KMS Encryption (Secure String)     │
│                                                               │
│  KMS の役割: 中央集権的なキー管理・監査・ローテーション      │
│             ↓                                               │
│  CloudTrail → KMS API コール全監査（who, what, when）      │
│                                                               │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                    転送時暗号化（Encryption in Transit）      │
├─────────────────────────────────────────────────────────────┤
│                                                               │
│  クライアント → AWS           → HTTPS (TLS 1.2以上)         │
│  AWS内部通信（VPC）           → IPsec/TLS（デフォ）         │
│  S3へのアップロード           → HTTPSフォース + SigV4       │
│  RDS への接続                 → SSL/TLS（RDS Proxy推奨）   │
│  バックアップの転送           → Encryption in Transit自動   │
│  ECR プルイメージ             → HTTPS + 署名検証            │
│                                                               │
│  ACM の役割: SSL/TLS 証明書の自動発行・更新・管理           │
│             ↓                                               │
│  CloudFront, ALB, API Gateway に自動統合                   │
│                                                               │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                    使用時暗号化（Encryption in Use）          │
├─────────────────────────────────────────────────────────────┤
│                                                               │
│  CloudHSM             → ハードウェアベースの鍵管理           │
│  KMS Custom Key Store → オンプレミスHSM統合               │
│  Application-level Enc → アプリが暗号化・復号化             │
│                                                               │
└─────────────────────────────────────────────────────────────┘

KMS vs CloudHSM の選択

比較項目	KMS	CloudHSM
管理負荷	✅ マネージドサービス（AWS側で管理）	❌ 自己管理（ファームウェア更新等）
パフォーマンス	✅ 十分（API呼び出し）	✅ 高速（ローカル接続）
コスト	✅ 従量課金（低コスト）	❌ 専有ハードウェア（月額固定）
FIPS 140-2 L3	✅ キー格納のみ	✅ デバイス全体
カスタムキーストア	❌ KMS側で管理	✅ 完全な暗号化キー管理
Bring Your Own Key(BYOK)	△ カスタムキーストア経由	✅ ネイティブ対応
監査・コンプライアンス	✅ CloudTrailで全監査	✅ HSMログで可視化

選択ルール

デフォルト: KMS を使う。大多数のユースケースで十分。
FIPS 140-2 L3デバイス必須: CloudHSM 選択。
オンプレミスとの統合必須: CloudHSM + VPN/DirectConnect。

2. 試験頻出の「サービス選択問題」攻略

2-1. 検出サービスの比較: GuardDuty vs Inspector vs Macie vs Config

試験では 「どの脅威を、どのサービスが、どう検出するか」 という問題が頻出です。

検出対象の整理

脅威の種類	GuardDuty	Inspector	Macie	Config
ネットワークスキャン（未許可ポート接続）	✅ AI学習で異常検知	❌	❌	❌
EC2からの不正なAPI呼び出し	✅ CloudTrailデータ解析	❌	❌	❌
マルウェア感染の兆候	✅ VPC Flow Logs + CloudTrail	❌	❌	❌
暗号通貨採掘（CPU異常利用）	✅ CloudWatch Metrics + 学習	❌	❌	❌
未認可されたAPI呼び出し	✅ CloudTrail整形 + リスク評価	❌	❌	❌
EC2の未適用セキュリティパッチ	❌	✅ Systems Manager Inventory	❌	❌
EC2のポート公開（脆弱性）	❌	✅ ネットワーク設定スキャン	❌	❌
ラムダ関数の依存関係脆弱性	❌	✅ コード解析 + CVE照合	❌	❌
S3内の個人識別情報（PII）検出	❌	❌	✅ 機械学習で自動検出	❌
S3 ACL設定がPublic	❌	❌	❌	✅ Config Rules
KMS未暗号化EBS	❌	❌	❌	✅ Config Rules
SecurityGroup に0.0.0.0許可	❌	❌	❌	✅ Config Rules
CloudTrail未有効	❌	❌	❌	✅ Config Rules
不適切なタグが未付与	❌	❌	❌	✅ Config Rules + Custom Rules

試験での出題パターン

「EC2インスタンスから見たことのないIPアドレスへの接続が10回連続検出された」→ GuardDuty（通信異常検知）
「Amazon Linux 2 にセキュリティパッチが未適用」→ Inspector（脆弱性検査）
「S3バケット内にクレジットカード番号が含まれるファイルが存在」→ Macie（データ分類・検出）
「KMS暗号化されていないEBSボリュームが作成された」→ Config（リソース設定ドリフト）

2-2. ログ集約・監視サービスの比較: CloudWatch vs Security Hub vs Config

比較項目	CloudWatch Logs	CloudWatch Logs Insights	Security Hub
ログの受け取り元	CloudTrail, VPC Flow, ALB等	CloudWatch Logs の上に統計クエリ	GuardDuty, Inspector, Macie, Config等
リアルタイム処理	✅ Metric Filters + Lambda	△ Insights は事後分析	✅ リアルタイム統合
長期保存	CloudWatch Logs Retention設定	〃	S3 Findings 出力（別途設定）
分析機能	限定的（アラートのみ）	✅ SQL相当のクエリ	✅ Dashboard + Insight
コンプライアンス自動評価	❌	❌	✅ CIS/PCI-DSS/HIPAA自動チェック
Remediation自動実行	△ Lambda経由で可能	❌	△ Systems Manager Automation
マルチアカウント統合	△ 複雑（各アカウントから送信）	△ 〃	✅ Organization統合が標準
推奨コスト構成	リアルタイム層	中期分析層	統合・可視化層

試験出題パターン

「全AccountのGuardDuty検知を一箇所で可視化したい」→ Security Hub （複数アカウント統合の標準）
「CloudTrail内の特定イベント（例: IAM Policy変更）を時系列検索したい」→ CloudWatch Logs Insights （複雑なクエリ対応）
「アプリケーションログを記録し、ERROR行数でアラート発火」→ CloudWatch Logs + Metric Filters （シンプル）

2-3. 暗号化キー管理: KMS vs CloudHSM vs Secrets Manager

比較項目	KMS	CloudHSM	Secrets Manager
保存対象	暗号化キー	暗号化キー（HSM内）	シークレット（API Key, DB Password等）
キー作成・管理	AWS側で完全管理	ユーザーが完全管理	自動ローテーション可能
監査可能性	✅ CloudTrail全記録	✅ HSMログ	✅ CloudTrail + 変更履歴
コスト	✅ 従量課金（Key数 + API呼び出し）	❌ 月額固定	✅ シークレット数 + API呼び出し
複数リージョン	✅ Key Replication	✅ 独立	✅ レプリケーション設定
使用例	EBS/RDS/S3暗号化	FIPS L3 必須環境	DB パスワード、API キー保存

よくある間違い

Secrets Manager は「キー管理」ではなく「シークレット管理」。キーはKMS側で管理。
「DB パスワードを定期自動ローテーション」→ Secrets Manager。
「EBSボリュームの暗号化キー」→ KMS。

2-4. ネットワーク防御: WAF vs Shield vs Network Firewall

比較項目	WAF	Shield Standard	Shield Advanced	Network Firewall
防御対象	アプリ層（L7）	DDoS（L3/4）	DDoS（L3/4/7）	ネットワーク層（L3-7）
脅威	SQLi, XSS, CSRF, CC Bot	DNS Amplification, SYN Flood	Sophisticated DDoS	マルウェア, IDS/IPS
配置箇所	CloudFront, ALB, API GW	自動（全Edge）	自動（全Edge）	VPC境界
マネージド vs 自己管理	✅ マネージド	✅ マネージド	✅ マネージド	△ ルール定義は自己管理
コスト	リクエスト数 + ルール	✅ 無料	$3k/月 + DDoS時）	VPC Endpoint費用
導入難易度	✅ 簡単（CloudFront/ALB関連付け）	自動有効	$3k/月追加	△ ネットワーク設計が必要
ユースケース	すべてのWebアプリ	全AWS顧客（自動保護）	金融・大規模顧客向け	大規模VPC、IDS必須

試験出題パターン

「CloudFrontを使うWebサイトの SQLi 攻撃を防ぐには？」→ WAF at CloudFront
「多数の不正ボット（CC攻撃）を検出・遮断したい」→ WAF with Bot Control + Shield Advanced
「オンプレミスとのVPN経由のマルウェア通信を検知」→ Network Firewall with IDS

2-5. アクセス制御ポリシーの比較: SCP vs Permission Boundary vs IAM Policy

比較項目	IAM Policy	Permission Boundary	SCP
適用範囲	ユーザー/ロール	ユーザー/ロール	全体（Account内全員）
評価時点	リソースアクセス時	リソースアクセス時	API呼び出し前
Explicit Deny対応	✅ Deny優位	✅ Deny優位	✅ Deny優位
上書き可能性	ユーザー権限次第	Permission Boundary が上限	どのIAMでも上書き不可
ユースケース	日常的な権限付与	権限昇格の防止	組織全体ルール強制
例	EC2起動許可	ec2:RunInstances許可上限	ec2:* 禁止→EC2全く使用不可

よくある誤解

SCP はIAMPolicy ではない。評価順序が異なる。
SCP が Deny していても、IAM Policy で Allow すると、全体では Deny になる。
Permission Boundary は「許可」ではなく「上限設定」。実権限にはIAM Policy必須。

2-6. VPC エンドポイント: Gateway vs Interface

比較項目	Gateway Endpoint	Interface Endpoint
通信対象	S3 / DynamoDB のみ	全AWS Service + 3rd Party
実装方法	Route Table に追加	ENI（Elastic Network Interface）
DNS動作	Route Tableでリダイレクト	Route 53 プライベートホストゾーン
セキュリティ	Endpoint Policy制御	Security Group + Endpoint Policy
通信経路	AWS内部ネットワーク（無料）	AWS内部（ただしENI費用）
使用例	S3 from Lambda inPrivate Subnet	RDS, Kinesis,SNS等 from Private Subnet

出題パターン

「PrivateSubnetのLambdaからS3へアクセス、インターネット経由避けたい」→ Gateway Endpoint
「CloudFormation APIをPrivateSubnetから呼びたい」→ Interface Endpoint

2-7. Cognito: User Pools vs Identity Pools

比較項目	User Pools	Identity Pools
用途	ユーザー認証（サインアップ/ログイン）	AWS APIアクセス権限付与（認可）
入力	ユーザーID + パスワード	ID Token / 外部プロバイダトークン
出力	JWT Token（認証証明）	AWS アクセスキー + シークレット（一時）
連携	APIGateway, App Load Balancer	AWS SDK (S3, DynamoDB等)
使用例	モバイルアプリのサインアップ画面	Webアプリから S3 へのダイレクトアップロード

組み合わせ

ユーザーアプリ 
  ↓ (サインアップ)
Cognito User Pools (認証)
  ↓ (ID Token取得)
Cognito Identity Pools (IdP連携)
  ↓ (AWS認証情報取得)
S3 / DynamoDB へのダイレクトアクセス

3. 頻出シナリオ別・最適構成パターン

3-1. シナリオ: セキュリティインシデント検知と自動修復

問題: EC2 インスタンスから見たことのないIPアドレスへの SSH接続が複数回検出された。不正アクセスの可能性が高く、SecurityGroup を自動で修正する必要がある。

正解構成:

GuardDuty (脅威検知)
  ↓ Finding 生成
  
CloudWatch Events / EventBridge (リアルタイムルール)
  + Pattern Match (Finding Type = "NetworkFinding")
  
  ↓
  
Lambda (自動修復アクション)
  ├─ EC2 DescribeSecurityGroups
  ├─ SSH(22)の該当CIDR block を特定
  └─ RevokeSecurityGroupIngress (SSH block)
  
  ↓
  
SNS / メール通知 (修復完了通知)

各サービスの責務

GuardDuty: ネットワーク異常をリアルタイム検知。Finding を CloudWatch Events へ出力。
EventBridge: GuardDuty Finding をキャッチし、条件判定。
Lambda: SecurityGroup 修正ロジック実装。実行ロールに ec2:RevokeSecurityGroupIngress 権限必須。
IAM: Lambda 実行ロールに SecurityGroup修正権限を最小権限付与。

よくある誤解

❌ GuardDuty が自動で SecurityGroup を修正 → GuardDuty は検知のみ。修復は別途実装。
❌ CloudTrail で検知 → GuardDuty（AIで異常検知）が最適。

3-2. シナリオ: クロスアカウントアクセス制御

問題: 子アカウント(Account-B) のEC2が、親アカウント(Account-A) のS3 バケットにアクセスしたい。ルートアカウント共有は避け、最小権限原則で実装する。

正解構成:

┌─────────────────────────────────────────────────────────────┐
│ Account A (親)                                              │
│  S3 Bucket "parent-data"                                    │
│  ├─ Bucket Policy                                           │
│  │  └─ Allow: arn:aws:iam::AccountB:role/EC2Role           │
│  │     Action: s3:GetObject, s3:ListBucket                 │
│  │     Resource: arn:aws:s3:::parent-data/*               │
│  │                                                           │
│  └─ Block Public Access: ON                                 │
└──────────────────────────┬──────────────────────────────────┘
                           ↓ (Trust)
┌─────────────────────────────────────────────────────────────┐
│ Account B (子)                                              │
│  EC2 Instance Role (EC2Role)                                │
│  ├─ Trust Policy                                            │
│  │  └─ Allow: Service ec2.amazonaws.com                    │
│  │           Principal: arn:aws:iam::AccountB:root         │
│  │                                                           │
│  └─ IAM Policy (Inline)                                     │
│     └─ Allow: sts:AssumeRole                               │
│        Resource: arn:aws:iam::AccountA:role/...           │
│                                                              │
│     Allow: s3:GetObject, s3:ListBucket                     │
│     Resource: 〃                                             │
└─────────────────────────────────────────────────────────────┘

実装ステップ

Step 1: Account A (親) で IAM Role を作成

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::ACCOUNT-B:root"
    },
    "Action": "sts:AssumeRole"
  }]
}

Step 2: Account A の S3 Bucket Policy を設定

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::ACCOUNT-A:role/CrossAccountRole"
    },
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::parent-data", "arn:aws:s3:::parent-data/*"]
  }]
}

Step 3: Account B の EC2 Role に権限追加

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::ACCOUNT-A:role/CrossAccountRole"
  }]
}

Step 4: EC2 インスタンス内でAssumeRole実行

aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT-A:role/CrossAccountRole \
  --role-session-name session-name

ポイント

Trust Policy（Account A側）と IAM Policy（Account B側）の両方が揃う必要がある。
Account A の Resource-based Policy（S3 BucketPolicy）で Account B の role を明示的に Allow。
CloudTrail で「誰が何をいつ」か全監査可能。

3-3. シナリオ: マルチアカウント統制とコンプライアンス監視

問題: 組織の全 Account （10以上）で、常に以下をコンプライアンスチェック：

CloudTrail が有効化されているか
S3 Bucket が Public になっていないか
EBS Volume が KMS 暗号化されているか

正解構成:

┌──────────────────────────────────────────────────────────────┐
│ Management Account （親）                                    │
│                                                                │
│  AWS Config Aggregator                                        │
│  ├─ All Accounts / All Regions を集約                        │
│  │  (Authorization: Aggregation Account + Member Accounts)  │
│  │                                                             │
│  └─ Config Rules (Organization全体に展開)                   │
│     ├─ cloudtrail-enabled                                    │
│     ├─ s3-bucket-public-read-prohibited                      │
│     ├─ encrypted-volumes (EBS)                               │
│     └─ Custom Rules: 独自要件                                │
│                                                                │
│  ↓                                                             │
│                                                                │
│  AWS Config Remediation (自動修復)                           │
│  ├─ Public ACL のS3を Private に戻す                         │
│  ├─ CloudTrail をONに                                        │
│  └─ Non-Compliant EBS を削除 or リテープ                    │
│                                                                │
│  ↓                                                             │
│                                                                │
│  SecurityHub (統合ダッシュボード)                             │
│  ├─ Config Compliance 結果を可視化                           │
│  └─ CIS Benchmark チェック実施                               │
│                                                                │
│  ↓                                                             │
│                                                                │
│  S3 + Athena (ログ分析)                                      │
│  ├─ Config Snapshots を S3 に保存                           │
│  └─ 長期トレンド分析（Athena SQL）                          │
│                                                                │
└──────────────────────────────────────────────────────────────┘

設定ポイント

Config Aggregator: Management Account で All Accounts を集約。
Config Rules: Organization SCPs より細かい設定チェック（例: S3 ACL がPublic）。
Remediation: 違反を発見したら自動修復（Systems Manager Automation）。
SecurityHub: Config + GuardDuty + Inspector を統合ダッシュボード化。
長期保存: Config Snapshots を S3 に出力。Glacier へ遷移。

3-4. シナリオ: セキュアなデータ分類と PII 保護

問題: 社内で使われている S3 バケット（1000+ オブジェクト）に、クレジットカード番号や個人識別情報（PII）が誤包含されていないかを継続監視し、検出後は自動的にアクセスを制限したい。

正解構成:

┌────────────────────────────────────────────────────────────┐
│ Amazon Macie                                                │
│ ├─ S3 バケットのスキャン自動実行（日次）                  │
│ └─ 検出: PII (SSN, CC#, email等)                          │
│                                                              │
│    ↓ Finding 生成                                           │
│                                                              │
│ Amazon EventBridge                                          │
│ └─ Macie Finding → Pattern Match                          │
│                                                              │
│    ↓                                                         │
│                                                              │
│ AWS Lambda (自動修復)                                       │
│ ├─ 対象オブジェクトのメタデータ取得                       │
│ ├─ S3 Object ACL を Private に更新                         │
│ ├─ S3 Bucket Policy で該当オブジェクトへのアクセス制限   │
│ ├─ KMS で暗号化キーをローテーション                       │
│ └─ SNS で管理者に通知                                       │
│                                                              │
│    ↓                                                         │
│                                                              │
│ AWS Config                                                  │
│ └─ S3 Policy 変更を追跡                                    │
│                                                              │
│    ↓                                                         │
│                                                              │
│ SecurityHub                                                 │
│ └─ Macie + Config Findings を統合表示                      │
│                                                              │
└────────────────────────────────────────────────────────────┘

実装詳細

Macie スキャンアクション

日次/週次自動スキャン実行（Management Account 設定）
Machine Learning で PII パターンを学習・検出
カスタムデータ識別子定義可能（例: 社内ID形式）

Lambda アクション（修復)

import boto3
import json

s3 = boto3.client('s3')

def lambda_handler(event, context):
    # Macie Finding から対象オブジェクト抽出
    finding = json.loads(event['Records'][0]['Sns']['Message'])
    bucket = finding['resources'][0]['s3Bucket']['name']
    key = finding['resources'][0]['s3Object']['key']
    
    # S3 オブジェクト ACL をPrivateに
    s3.put_object_acl(
        Bucket=bucket,
        Key=key,
        ACL='private'
    )
    
    # Bucket Policy で該当オブジェクトへの外部アクセス禁止
    # (IAM Role 指定) 
    
    # SNS で通知
    sns = boto3.client('sns')
    sns.publish(
        TopicArn='arn:aws:sns:...:PII-Alert',
        Message=f'PII detected: {bucket}/{key}'
    )
    
    return {'statusCode': 200}

ポイント

Macie: データ分類の自動化。検出精度が高い。
EventBridge + Lambda: 検出から修復まで完全自動化。
Config: S3 ポリシー変更履歴を保持。監査証拠に。
SecurityHub: 全社的なセキュリティ状況を一元把握。

3-5. シナリオ: 多層 DDoS 防御設計

問題: グローバルアプリケーション（CloudFront + ALB + API Gateway）が DDoS 攻撃を受けるリスク。複数レイヤーで防御を設計する。

正解構成:

┌────────────────────────────────────────────────────────────┐
│ Layer 1: Edge (CloudFront + Shield Standard)               │
│  - AWS インフラで大規模DDoS自動緩和               │
│  - CloudFlare / Akamai 程度の防御                  │
│                                                             │
│     DDoS Attack                                             │
│            ↓ (blocked by Shield Standard)                  │
│                                                             │
│  ✅ SYN Flood, UDP Flood, DNS Amplification                │
│  ✅ Geo-blocking, Rate limiting (CloudFront)             │
│                                                             │
│     但し複雑な攻撃には無力 → 追加投資                     │
│                                                             │
└────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────┐
│ Layer 2: Application (WAF)                                  │
│  - SQLi, XSS, CSRF, Bot Detection 等                       │
│  - CloudFront, ALB, API Gateway に付与              │
│                                                             │
│     HTTP Request (Sophisticated Attacks)                   │
│            ↓ (WAF Rules)                                   │
│                                                             │
│  ✅ Rate-based Rule (IP/5分 100req超)                      │
│  ✅ Bot Control (AWS Managed)                              │
│  ✅ Custom Rule (SQL, XSS Pattern)                        │
│  ✅ Geo-blocking                                           │
│                                                             │
│     → 既知の攻撃 99% ブロック                             │
│                                                             │
└────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────┐
│ Layer 3: Advanced (Shield Advanced + DRT Support)          │
│  - DDoS Response Team (24/7/365 ライブ支援)              │
│  - 攻撃パターン分析 + リアルタイムルール追加          │
│  - 費用: $3k/月 + 攻撃時の追加費用なし                   │
│                                                             │
│     ０Day Attack (前代未聞の攻撃)                         │
│            ↓ (DRT Manual Tuning)                          │
│                                                             │
│  ✅ Real-time DDoS Intelligence                           │
│  ✅ CloudFront/Route 53 無制限保護                       │
│  ✅ 攻撃後のコスト控除                                   │
│                                                             │
└────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────┐
│ Layer 4: Network (AWS Network Firewall)                    │
│  - IDS/IPS 機能                                             │
│  - マルウェア検知、プロトコル異常検知                  │
│  - VPC 境界での East-West 監視                            │
│                                                             │
└────────────────────────────────────────────────────────────┘

選択フロー

デフォルト: Shield Standard （無料）+ WAF （リクエスト単位）
金融・大規模: Shield Advanced (24/7 DRT) 追加
Zero-Trust: Network Firewall で東西通信も監視

3-6. シナリオ: ログの一元管理と検索・分析

問題: 複数のAWSアカウント・リージョンからのログ（CloudTrail, VPC Flow, ALB Access, WAF等）を一箇所に集約し、セキュリティインシデント調査時に高速に検索・分析したい。

正解構成:

┌─────────────────────────────────┐
│ CloudTrail (API Audit)          │
│ - Management & Data Events      │
│ - JSON形式                      │
└────────────┬────────────────────┘

┌─────────────────────────────────┐
│ VPC Flow Logs                   │
│ - Accept / Reject               │
│ - Parquet形式（Athena最適）     │
└────────────┬────────────────────┘

┌─────────────────────────────────┐
│ ALB Access Logs                 │
│ - HTTP Status / Latency         │
└────────────┬────────────────────┘

┌─────────────────────────────────┐
│ WAF Logs                        │
│ - Blocked Request Details       │
└────────────┬────────────────────┘

┌─────────────────────────────────┐
│ GuardDuty Findings              │
│ - JSON形式                      │
└────────────┬────────────────────┘

│ Config Changes                  │
│ - Resource Configuration        │
└────────────┬────────────────────┘

         ↓ All → S3 (Central Bucket)

┌───────────────────────────────────────────────────────┐
│ S3 (Logging Aggregation Bucket)                      │
│ Structure:                                             │
│  s3://central-logs/                                  │
│  ├─ cloudtrail/account/region/YYYY/MM/DD/           │
│  ├─ vpcflowlogs/account/region/YYYY/MM/DD/          │
│  ├─ alb-logs/account/region/YYYY/MM/DD/             │
│  └─ guardduty/account/YYYY/MM/DD/                   │
│                                                        │
│ ✅ Versioning ON (監査証拠保護)                      │
│ ✅ MFA Delete ON (誤削除防止)                        │
│ ✅ Server-side Encryption (KMS)                      │
│ ✅ Lifecycle Policy (Glacier 30日後)                 │
│                                                        │
└────────────┬────────────────────────────────────────┘
             ↓

┌───────────────────────────────────────────────────────┐
│ Amazon Athena (クエリ分析)                            │
│ - S3 Parquet/JSON を SQL検索                         │
│ - CloudTrail: "root account from 1.1.1.1"           │
│ - VPC Flow: "Denied traffic to port 3389"            │
│ - GuardDuty: "C2 Beaconing patterns"                 │
│                                                        │
│ ✅ Ad-hoc 分析に最適                                 │
│ ✅ パフォーマンス: 秒～分単位                        │
│ ✅ コスト: スキャンGB単位                            │
│                                                        │
└────────────┬────────────────────────────────────────┘
             ↓

┌───────────────────────────────────────────────────────┐
│ Amazon QuickSight (BI可視化)                          │
│ - ダッシュボード: インシデント件数、ブロック件数等   │
│ - Alert機能で異常値通知                              │
│                                                        │
└─────────────────────────────────────────────────────┘

     並行: CloudWatch Logs Insights (リアルタイム)
             - 短期分析（数日～数週間）
             - Metric Filters でアラート発火

実装上の注意点

S3 Bucket ポリシー（各サービスからのログ受け入れ）

{
  "Sid": "CloudTrailWrite",
  "Principal": {
    "Service": "cloudtrail.amazonaws.com"
  },
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::central-logs/cloudtrail/*"
}

Athena テーブル定義（CloudTrail）

CREATE EXTERNAL TABLE IF NOT EXISTS cloudtrail_logs (
  eventVersion STRING,
  userIdentity STRUCT <
    type: STRING,
    principalId: STRING,
    arn: STRING,
    accountId: STRING,
    invokedBy: STRING,
    accessKeyId: STRING,
    userName: STRING,
    sessionContext: STRUCT <
      attributes: STRUCT <
        mfaAuthenticated: STRING,
        creationDate: STRING
      >,
      sessionIssuer: STRUCT <
        type: STRING,
        principalId: STRING,
        arn: STRING,
        accountId: STRING,
        userName: STRING
      >
    >
  >,
  eventTime STRING,
  eventSource STRING,
  eventName STRING,
  awsRegion STRING,
  sourceIPAddress STRING,
  userAgent STRING,
  errorCode STRING,
  errorMessage STRING,
  requestParameters STRING,
  responseElements STRING,
  additionalEventData STRING,
  requestId STRING,
  eventId STRING,
  resources ARRAY <
    STRUCT <
      arn: STRING,
      accountId: STRING,
      type: STRING
    >
  >,
  eventType STRING,
  recipientAccountId STRING,
  sharedEventID STRING,
  vpcEndpointId STRING
)
PARTITIONED BY (region STRING, year STRING, month STRING, day STRING)
ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://central-logs/cloudtrail/'

IAM ポリシー (Athena ユーザー向け)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::central-logs",
        "arn:aws:s3:::central-logs/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "athena:*",
      "Resource": "*"
    }
  ]
}

4. 試験直前チェックリスト: 各サービスの「これだけは覚えておく」

4-1. Identity & Access Management (IAM)

IAM は Global サービス。リージョン選択不要。
IAM Policy 評価順序: Explicit Deny → Organization SCP → Resource Policy → Identity Policy → Permission Boundary
Permission Boundary: 「許可」ではなく「上限」。IAM Policy 併用で初めて効果発揮。
SCP: Organization 内全体に強制。IAMPolicy で上書き不可。
AssumeRole: 一時認証情報（Access Key + Secret Key + Session Token）発行。自動失効。
Trust Policy: ロール側で「誰がこのロールを引き受けられるか」を定義。
MFA Delete: S3 で有効化するにはルートユーザー が必須。IAM ユーザーは不可。

4-2. Key Management Service (KMS)

KMS は Regional サービス。クロスリージョン利用は Replica Key が必須。
Customer Master Key (CMK): AWS Managed キーと Customer Managed キーの2種類。
Automatic Key Rotation: Customer Managed Key のみ有効化可能。AWS Managed は自動。
Key Policy: リソースベースポリシー。KMS キーへのアクセス制御。
Envelope Encryption: KMS でデータキーを暗号化。大容量データはこの方式。
CloudTrail 監査: KMS API すべて記録。暗号化/復号化も可視化。

4-3. CloudTrail

CloudTrail: AWS API の監査ログ。必ず有効化が推奨。
Management Events: IAM, EC2, S3等の制御系API。ほぼ全API。
Data Events: S3 GetObject/PutObject, Lambda Invoke等。オプション（コスト増）。
Insights: 通常と異なるAPI活動を自動検知（例: 異常な削除操作）。
Log Integrity: CloudTrail Digest で改ざん検知。必ずON推奨。
Organization Trail: 親アカウントで全子アカウントのログを一元収集。

4-4. GuardDuty

GuardDuty: ネットワークレベルの異常検知（通信パターン AI学習）。
検出対象: EC2 上のマルウェア、不正API呼び出し、DDoS攻撃者とのC2通信等。
CloudTrail と VPC Flow Logs の自動解析。有効化不要（自動取り込み）。
Finding タイプ: NetworkFinding, IAMFinding, EBS Finding等。
SecurityHub 統合: GuardDuty Finding を自動に集約・正規化。
False Positive: ホワイトリスト機能で既知の安全な通信を除外。

4-5. Inspector

Inspector: EC2/ラムダの脆弱性スキャン（コード・依存関係・設定）。
Systems Manager Agent 不要: Inspector エージェントが動作。
スキャン対象: CIS Benchmark, CVE, Network Reachability等。
結果: Findings（重大度別）→ SecurityHub に統合。

4-6. Macie

Macie: S3 内のセンシティブデータ検出（PII, 機密情報等）。
Machine Learning: パターン学習で精密な分類。
スキャン: 日次/週次自動 or オンデマンド。
カスタム Identifier: 会社固有の ID 形式も定義可能。
Finding: 検出レベル（CommonBehavior, SensitiveData等）で報告。

4-7. AWS Config

Config: インフラの設定ドリフト検知（期待値からの乖離）。
Config Rules: マネージド/カスタムルール。評価は継続的。
Remediation: 違反検出時に自動修復（Systems Manager Automation）。
Config Aggregator: 複数アカウント・リージョンを一元管理。
Snapshots: リソース設定の履歴。S3 に出力可能。

4-8. Security Hub

Security Hub: GuardDuty, Inspector, Macie, Config 等の統合ダッシュボード。
Standards: CIS Benchmark, PCI-DSS, HIPAA等を自動評価。
Insights: Security Hub 固有の分析視点（例: 最近のマルウェア検知）。
Organization Management: 親アカウントから全子アカウントを管理。

4-9. CloudWatch

CloudWatch Logs: VPC Flow, ALB Access等を収集・検索。
Metric Filters: ログ内の特定パターンを抽出してメトリクス化。
CloudWatch Logs Insights: SQL相当のクエリで事後分析。
Retention: ログ保持期間を設定。期限後は自動削除。
Log Groups: 同一形式のログをグループ化。

4-10. VPC & Network Security

Security Group: ステートフル（戻り通信は自動許可）。インスタンスレベル。
NACL: ステートレス（明示的な戻り規則必須）。サブネットレベル。
Network Firewall: IDS/IPS 機能。VPC 内のトラフィック詳細検査。
VPC Endpoint Gateway: S3 / DynamoDB のみ。ルートテーブル追加で利用。
VPC Endpoint Interface: 全AWS Service。ENI経由で VPN不要。

4-11. WAF & DDoS Protection

WAF: アプリ層攻撃（SQLi, XSS, Bot等）。CloudFront, ALB, API GW に付与。
Shield Standard: 無料。大規模DDoS自動緩和。
Shield Advanced: $3k/月。DDoS Response Team + 複雑攻撃対応。
Rate-based Rules: IP/時間単位のリクエスト制限。Bot対策に有効。
Geo-blocking: 地域単位でのアクセス制限。

4-12. Secrets Manager

Secrets Manager: データベースパスワード、APIキー等を安全に保存・ローテーション。
自動ローテーション: Lambda + Rotation Function で実装。
KMS 統合: シークレット自体も KMS で暗号化。
Resource Policy: リソースベースで受け入れ元 IAM を指定。
Audit: CloudTrail で取得・使用を全監査。

4-13. Parameter Store

Parameter Store: 設定値、パスワード（軽量版）、アプリケーション設定。
Tier: Standard (10KB) / Advanced (8KB, 無料枠あり)。
SecureString: KMS で自動暗号化。GetParameter時に復号。
Tags & VersionControl: パラメータのバージョン履歴保持。

4-14. KMS vs CloudHSM

項目	KMS	CloudHSM
管理	AWS管理	ユーザー管理
コスト	従量課金（低）	月額固定（高）
FIPS L3	✅	✅
API互換	✅	△

選択: デフォルト KMS。FIPS L3 必須 → CloudHSM。

4-15. Identity & Cognito

Cognito User Pools: ユーザー認証（サインアップ/ログイン）→ JWT Token。
Cognito Identity Pools: AWS API アクセス権限付与 → 一時AWS認証情報。
Federation: SAML 2.0, OpenID Connect で外部ディレクトリ統合。
AWS Identity Center: IAM Identity Center。複数アカウント・ユーザー管理。

5. 試験に出やすい落とし穴と対策

5-1. IAM Policy vs SCP の混同

落とし穴: SCP が Allow していても IAM Policy が Deny なら全体では Deny。逆も然り。

対策: 評価フローを暗唱：

API呼び出し
  ↓
① Organization SCP (Deny = 全体Deny）
  ↓
② Permissions Boundary （Allow上限設定）
  ↓
③ Resource-based Policy （リソース側の受け入れ）
  ↓
④ Identity-based IAM Policy （ユーザー/ロール側の権限）
  ↓
⑤ Session Policy （AssumeRole時の制限）
  ↓
結果: すべてが Allow → アクセス可, 1つでも Deny → アクセス不可

5-2. CloudTrail vs VPC Flow Logs の役割混同

落とし穴

CloudTrail は API（「誰が何を」）を記録。ネットワーク通信は記録しない。
VPC Flow Logs はネットワーク通信（「誰からどこへ」）を記録。API呼び出しは含まない。

対策

ログ種類	記録内容	使用例
CloudTrail	API呼び出し（IAM, EC2, S3等）	「root アカウントが S3 削除API」を検知
VPC Flow Logs	ネットワーク通信（Allowed/Denied）	「EC2 から不正IPへのSSH接続」を検知

5-3. Permission Boundary は「許可」ではない

落とし穴

Permission Boundary: Allow ec2:*
IAM Policy: Deny ec2:TerminateInstances
結果: ❌ Deny （Permission Boundary の上限内でも、IAM Deny優位）

対策: Permission Boundary は「最大許可範囲」。実際の権限は IAM Policy で定義。

5-4. KMS キーローテーション vs AWS Managed Key

落とし穴

AWS Managed キー: 自動ローテーション（3年）。手動設定不可。
Customer Managed キー: 年1回推奨。手動ON/OFF可能。

5-5. GuardDuty Finding vs Security Hub Finding

落とし穴: GuardDuty は検知のみ。修復は別途実装（Lambda等）。

対策:

GuardDuty Finding (検知)
  ↓ EventBridge
Lambda (修復ロジック実装)
  ↓
SecurityHub (結果を統合表示)

5-6. CloudHSM は HSMサービスではなく HSMマシン

落とし穴: CloudHSM は専有ハードウェア（月額固定）。軽い用途では KMS で十分。

対策

FIPS 140-2 Level 3 デバイス要件なし → KMS
FIPS Level 3 完全準拠 or オンプレHSM統合 → CloudHSM

6. 試験対策の最後のコツ

6-1. 読解力が勝敗を分ける

SCS-C03 は「複雑なシナリオ文 + 複数の正解っぽい選択肢」が特徴。

対策:

問題文で 「何を実現するか」 を明確にする（検出？修復？監査？）
「どのサービスの責務か」 を判定する
「なぜ他の選択肢がダメか」を言語化する

6-2. 時間管理

試験時間: 150分 （ちょっと長い）
65問 程度（1問あたり2~3分）
初見で分からない問題は飛ばす。後で戻る。

6-3. 出題形式の傾向

単一回答: サービス選択型（★大半）
複数回答: アーキテクチャ全体設計型（★難）
ドラッグ&ドロップ: フロー図、ポリシー評価順序等

最後に

SCS-C03は「セキュリティを体系的に理解し、複数サービスを組み合わせる判断力」を問う試験です。

暗記ではなく、「このシナリオでなぜこのサービスを選ぶのか、根拠を言えるか」 が合格の鍵になります。

本講で提示した ドメイン別マッピング、サービス比較表、シナリオ別構成パターン を何度も反復し、試験本番では落ち着いて問題文から必要なサービスを推測できる力を養ってください。

頑張ってください。SCS-C03合格を祈ります。

付録: よく出題される「あるあるシナリオ」集

Q1. 「ルートアカウントが XXX API を呼び出した」を検知したい

A: CloudTrail (Management Events)

API呼び出しを記録
ルートユーザーを特定可能
CloudWatch Events で自動アラート可能

Q2. 「EC2 から外部マルウェアサイトへの通信」を自動ブロック

A: GuardDuty (検知) + SecurityGroup (ブロック)

GuardDuty が通信パターン異常検知 → EventBridge
Lambda で SecurityGroup ルール追加（全HTTPS除外等）

Q3. 「複数アカウントの SecurityGroup 設定が全公開」

A: Config + Config Aggregator + Remediation

すべてのアカウント/リージョンを一元管理
自動修復で SecurityGroup を Private に

Q4. 「Cognito ユーザーが S3 バケットに直接アップロード」

A: Cognito User Pools → Identity Pools → S3 IAM Role

User Pools が認証
Identity Pools が AWS 認証情報発行
S3 IAM Role が PutObject 権限制限

Q5. 「Organization 全アカウントで CloudTrail を強制有効」

A: SCP + AWS Config + Remediation

SCP で cloudtrail:* 禁止（ただし例外設定）
Config Rules で有効化チェック
自動修復で有効化

本講で学んだ内容を整理し、試験に向けて実践演習を重ねてください。成功を祈ります。

横断整理・サービス選択・試験戦略

横断整理・サービス選択・試験戦略

1. SCS-C03 全体像: ドメイン別・サービス役割マッピング

1-1. 5つのドメインの全体像

SCS-C03 5ドメイン全体図

1-2. 脅威検出とインシデントレスポンス ドメイン

サービス役割の整理

各検出サービスの責務を言語化

1-3. セキュリティロギングとモニタリング ドメイン

ログの種類別・配信先マッピング

ロギングアーキテクチャの3つのレイヤー

1-4. インフラストラクチャセキュリティ ドメイン

多層防御の全体図

層ごとのサービス選択マトリクス

1-5. IAMとアクセス管理 ドメイン

認証・認可の全体像

サービス選択マトリクス: IAM系サービス

1-6. データ保護 ドメイン

暗号化の全体像

KMS vs CloudHSM の選択

2. 試験頻出の「サービス選択問題」攻略

2-1. 検出サービスの比較: GuardDuty vs Inspector vs Macie vs Config

検出対象の整理

2-2. ログ集約・監視サービスの比較: CloudWatch vs Security Hub vs Config

2-3. 暗号化キー管理: KMS vs CloudHSM vs Secrets Manager

2-4. ネットワーク防御: WAF vs Shield vs Network Firewall

2-5. アクセス制御ポリシーの比較: SCP vs Permission Boundary vs IAM Policy

2-6. VPC エンドポイント: Gateway vs Interface

2-7. Cognito: User Pools vs Identity Pools

3. 頻出シナリオ別・最適構成パターン

3-1. シナリオ: セキュリティインシデント検知と自動修復

3-2. シナリオ: クロスアカウント アクセス制御

3-3. シナリオ: マルチアカウント統制とコンプライアンス監視

3-4. シナリオ: セキュアなデータ分類と PII 保護

3-5. シナリオ: 多層 DDoS 防御設計

3-6. シナリオ: ログの一元管理と検索・分析

4. 試験直前チェックリスト: 各サービスの「これだけは覚えておく」

4-1. Identity & Access Management (IAM)

4-2. Key Management Service (KMS)

4-3. CloudTrail

4-4. GuardDuty

4-5. Inspector

4-6. Macie

4-7. AWS Config

4-8. Security Hub

4-9. CloudWatch

4-10. VPC & Network Security

4-11. WAF & DDoS Protection

4-12. Secrets Manager

4-13. Parameter Store

4-14. KMS vs CloudHSM

4-15. Identity & Cognito

5. 試験に出やすい落とし穴と対策

5-1. IAM Policy vs SCP の混同

5-2. CloudTrail vs VPC Flow Logs の役割混同

5-3. Permission Boundary は「許可」ではない

5-4. KMS キーローテーション vs AWS Managed Key

5-5. GuardDuty Finding vs Security Hub Finding

5-6. CloudHSM は HSMサービス ではなく HSMマシン

6. 試験対策の最後のコツ

6-1. 読解力が勝敗を分ける

6-2. 時間管理

6-3. 出題形式の傾向

最後に

付録: よく出題される「あるあるシナリオ」集

Q1. 「ルートアカウントが XXX API を呼び出した」を検知したい

Q2. 「EC2 から外部マルウェアサイトへの通信」を自動ブロック

Q3. 「複数アカウントの SecurityGroup 設定が全公開」

Q4. 「Cognito ユーザーが S3 バケットに直接アップロード」

Q5. 「Organization 全アカウントで CloudTrail を強制有効」

1-2. 脅威検出とインシデントレスポンスドメイン

1-3. セキュリティロギングとモニタリングドメイン

1-4. インフラストラクチャセキュリティドメイン

1-5. IAMとアクセス管理ドメイン

1-6. データ保護ドメイン

3-2. シナリオ: クロスアカウントアクセス制御

5-6. CloudHSM は HSMサービスではなく HSMマシン