横断整理 — 24レッスンを頭の中で繋げる
全サービスの関係性、試験での選択パターン、最終チェックを講義形式で総整理
さあ、最終回です。
24 回にわたって AWS セキュリティを学びました。IAM、暗号化、ログ、ネットワーク、ハイブリッド接続。膨大な知識が頭に詰まっています。でも、それらが断片化していないでしょうか。
「暗号化で KMS が出たけど CloudHSM との違いは？」「検出サービスは何個ある？」「ログは CloudTrail か CloudWatch Logs か？」こうした細部の関連性を見落としがちです。
今日は、全部を 1 つの統合された物語で繋ぎ直すことをします。これが試験本番での強力な武器になります。複数サービスの関係性を理解した時、初めて難しい問題も解けるようになるのです。
統合的なセキュリティシナリオ——セキュリティ課長の朝
AWS セキュリティ課長の朝のシナリオで、各サービスの関連性を理解しましょう。
朝 7 時、異常検知アラートが届きます。「東京リージョン RDS インスタンスで通常と異なるアクセスパターンが検出」。何がこれを見つけたのか。Amazon Macie？GuardDuty？Inspector？
ここが重要。これら 3 つは「検出の三者」と呼ばれ、役割が全く異なります。
GuardDuty はネットワークトラフィックと API ログを監視し、不正な IP からのアクセスやハッカー的な API 呼び出しを AWS の脅威インテリジェンスと照合して検出します。
Macie はデータそのものを監視し、特に S3 内の PII（個人識別情報）を検出してアラートを出し、データ流出を防ぎます。
Inspector は EC2 や Lambda の脆弱性を検査し、古いパッケージバージョンの CVE を特定したり、ネットワークアクセス可能性を評価します。
RDS へのアクセス異常検知は GuardDuty による検出です。ネットワークアクティビティだからです。「過去 2 時間、シンガポール IP から禁止ツールで RDS 接続」といった詳細が分かります。
次のステップは、CloudTrail で API レベルの詳細を確認し、CloudWatch Logs でデータベースレベルのログを調査し、VPC Flow Logs でネットワークレベルの通信を追跡する、という多層的な検査が始まるのです。
朝、課長はアラートを見て、「あ、これは何か起きてる」と直感する。
朝8時 — 原因調査。
GuardDuty がアラートをくれた。でも、「何をされた？」を詳しく知りたい。
ここで出てくるのが、CloudTrail。AWS API の呼び出しログ。「誰が、いつ、どの API を呼んだ」をすべて記録。S3 に保存されてる。
RDS への異常なアクセス。CloudTrail で確認する。「あ、RDS 修正操作？ ModifyDBInstance が呼ばれてた。バックアップが無効化されてた」。
さらに詳しく。RDS インスタンス内で何が起きた？これは CloudWatch Logs。RDS の error log、slow log。アプリケーションが吐いてるログ。SELECT * FROM users が連発されてた。つまり、全ユーザーのデータを抜き出そうとしてた。
ネットワークレベルでは何が起きた？VPC Flow Logs。RDS インスタンスの ENI を通過するトラフィック。送信元 IP、ポート、許可/拒否。すべて記録。「あ、シンガポール IP は確かにセキュリティグループ 拒否。でも、なぜ RDS に繋がってた？」
あ、待。もしかして、オンプレミスからの踏み台サーバー？Transit Gateway 経由？おかしい。ルートテーブルを見直し。「あ、東京オンプレから Singapore オンプレへのルート。これ、誤設定。Singapore オンプレに侵入されてた？」
このように、ログの4層から全体像を把握。
4つのログの層
- CloudTrail — AWS API 呼び出し（誰が何をしたか）
- CloudWatch Logs — アプリケーション・RDS の詳細ログ（データレベル）
- VPC Flow Logs — ネットワークトラフィック（誰と誰が通信したか）
- VPC Traffic Mirroring — 本当のパケット（フォレンジック用）
課長は、この4層を同時に見ながら、事件を再構成する。
朝9時 — 対応方針決定。
原因が分かった。Singapore 支社が侵入されてた。その支社から、Transit Gateway 経由で日本の RDS に攻撃。
対応：
- アクセス権限の取り消し（IAM ポリシー削除）
- シンガポール オンプレの隔離（Transit Gateway Route Table で通信NG）
- RDS バックアップの復元（何分かかる？）
- 侵入調査（foren sick 用に VPC Traffic Mirroring でパケットキャプチャ）
- 外部セキュリティ企業に報告（必要に応じて）
ここで、暗号化の話が出る。RDS に保存されてたデータ。それ、暗号化されてた？
シーン2 — 暗号化の選択肢
暗号化って、簡単に言うけど、4つのレイヤーがある。
- 保存時の暗号化（Encryption at Rest）
RDS で暗号化。誰が鍵を持つ？
AWS KMS（Key Management Service） — AWS が鍵を管理。AWS が鍵を保存。簡単。でも、AWS に「この鍵で何を暗号化してる」を知られてる。 CloudHSM（Cloud Hardware Security Module） — あなたが鍵を持つ。AWS 上の、あなたの専用ハードウェア。AWS 従業員も鍵にアクセスできない。暗号化のすべてがあなたの手の中。
どっち選ぶ？「この情報は、AWS にも見せたくない」なら CloudHSM。「AWS が管理してくれる方が楽」なら KMS。
さらに、SSE-S3 や SSE-KMS の話。
SSE-S3（Server-Side Encryption with S3-managed keys） — S3 が暗号化鍵を持つ。簡単。でも鍵を自分で回転できない。 SSE-KMS — KMS が鍵を管理。鍵の回転ができる。監査ログも KMS に記録。高い。
誰が鍵を持つかで、暗号化方式が決まる AWS に任せる → KMS（無料枠あり） 自分で持つ → CloudHSM（月額 3,250 ドル） S3 のデフォルト → SSE-S3（最小限） 監査重視 → SSE-KMS（コスト高い）
- 転送中の暗号化（Encryption in Transit）
データベースからアプリケーションサーバーへ。この通信を暗号化。
TLS/SSL — データベース接続を暗号化。RDS なら デフォルト。 VPN / Direct Connect MACsec — ネットワーク層で暗号化。
- アプリケーション層の暗号化
信用しない。アプリケーションで、データベースに保存する前に暗号化。クライアントサイド暗号化。
KMS で暗号化鍵を取得 → アプリケーションで暗号化 → 暗号化されたデータをデータベースに保存。
AWS さえ見られない。ただし、複雑。
今朝のインシデント。RDS データ抜き出されてた。でも、データが暗号化されてたら？被害なし。「顧客の個人情報は暗号化。ハッカーが見ても、ただの文字列」。
これ、責任の問題に変わる。「情報流出事故が起きました」から「暗号化されてたので、情報流出の影響はありません」へ。
暗号化が対応の分岐点。データ流出 → 被害ゼロ（暗号化済み）。
課長は、すべての重要データの暗号化が設定されてることを確認。「よし、影響は限定的だ」。
シーン3 — ネットワーク防御の多層構造
では、そもそも「シンガポール IP からの攻撃をどうやって防ぐ」か？
ネットワーク防御の5階層。インターネットから VPC 内のリソースまで、段階的にフィルタリング。
- AWS Shield（DDoS 対策）
インターネットの最前線。DDoS 攻撃（大量のトラフィック）を自動的に検出・遮断。Shield Standard は無料。大企業は Shield Advanced。
ただし。Shield は「ボリューム系」の DDoS しか防げない。100 Gbps のトラフィック爆撃は防ぐ。でも、1つ 1つの正当なリクエストにしか見えない攻撃？防げない。
- AWS WAF（Web Application Firewall）
レイヤー7（アプリケーション層）。HTTP/HTTPS のリクエストを見て、ルールで許可/拒否。
例えば、「SQL インジェクションっぽいリクエストはブロック」「特定の国 IP は拒否」「User-Agent が不正なフォーマット」。ルール数が多い。
WAF は CloudFront、ALB（Application Load Balancer）、API Gateway に付けられる。
- Network Firewall（ネットワークレベルの FW）
VPC の入口に配置。すべてのインバウンド・アウトバウンドトラフィックをスキャン。DPI（Deep Packet Inspection）で、プロトコルレベルで検査。
例えば、「SSH が開かれてたけど、実は Trojan 通信」。Network Firewall は中身を見て、「あ、これ危ない」って判定。
- NACL（Network ACL）
サブネット単位のステートレスファイアウォール。IP / ポート単位。粗い。
例えば、「オンプレ 192.168.1.0/24 からは 443 ポートのみ許可」。シンガポール IP 全体は拒否。
- セキュリティグループ
インスタンス単位のステートフルファイアウォール。細かい。
例えば、「このデータベースは、このアプリサーバーからだけアクセス許可」。
この5層。すべて正しく設定される必要がある。1つ落とすと、攻撃が通り抜ける。
今朝のシンガポール攻撃。Network Firewall でも、NACL でも、セキュリティグループでも、どこかで止めるべきだった。「なぜ通った？」を調査する。
ネットワーク防御の5層
- Shield — DDoS ボリューム攻撃
- WAF — アプリケーション層攻撃
- Network Firewall — プロトコル検査
- NACL — サブネット単位フィルタリング
- SG — インスタンス単位フィルタリング
シーン4 — 認証・認可の全体像
ここまで、「攻撃の検出」「ログ調査」「ネットワーク防御」を学びました。
でも、そもそも「正当なユーザーは誰か？」を決めなきゃ。認証・認可。
認証（Authentication） — あなたは本当に本人ですか？
認可（Authorization） — あなたが本人なら、何ができますか？
IAM — AWS の基本。ユーザー、ロール、ポリシー。「この人は EC2 を起動できるけど、削除はできない」。細かい権限制御。管理ユーザーが設定。
AWS STS（Security Token Service） — 一時的なクレデンシャルを発行。「この API 呼び出しは、1時間だけ有効」。セッションベース認証。
Amazon Cognito — 外部ユーザー向けの認証。「Facebook でログイン」「Google でログイン」。モバイルアプリ、Web アプリ。IAM より簡単。
AWS IAM Identity Center — 企業向け。Active Directory と連携。「会社の LDAP で認証」「複数の AWS アカウントを一括管理」。SSO。
今朝のシンガポール攻撃。侵入された理由。IAM ポリシーが甘かった？例えば：
このIAMポリシーは最悪です。あるユーザーがRDSのすべての操作をすべてのインスタンスでできるという設定になっています。侵入されたら、このユーザーになりすまされて、データが抜き出される可能性があります。
最小権限の原則。「必要な操作だけ、必要なリソースだけ」。
例えば：
このポリシーでは、rds:DescribeDBInstancesとrds:CreateDBSnapshotアクションのみを許可し、リソースはproduction-dbというデータベースに限定しています。つまり、このユーザーはproduction-dbのスナップショット取得と参照だけができて、修正はできないわけです。
認証・認可の層 IAM — AWS 管理者向け。細かい権限制御。 STS — 一時的なアクセス。セッション制御。 Cognito — 外部ユーザー向け。ソーシャルログイン。 Identity Center — エンタープライズ向け。SSO、Active Directory 連携。
課長は、すべての IAM ポリシーを見直す。「これ、強すぎる」「これ、不必要」。権限を最小化。
シーン5 — コンプライアンス・監査
朝からずっと対応してる。でも、対応だけじゃ足りない。
「なぜ侵入されたんだ？」「セキュリティ対策は十分だったのか？」
監査・コンプライアンス。
AWS Config — AWS リソースの状態を監視。「このセキュリティグループ、誰かが誤って 0.0.0.0/0 を開いてないか？」「RDS が暗号化されてるか？」。継続的に確認。ルール違反が見つかったら、アラート。
AWS CloudFormation — インフラをコード化。「このセキュリティグループは、こういう状態である」を宣言。アクシデントで誰かが手作業で変えても、CloudFormation で自動修正。Infrastructure as Code。
CloudTrail の監査ログ — すべての API 呼び出しを記録。「誰が RDS を修正した？」「いつ IAM ポリシーを変えた？」。長期保存（通常、90 日。S3 に長期保存可能）。
AWS Security Hub — セキュリティ関連サービス（GuardDuty、Inspector、Macie、Config 等）の結果をすべて集約。「今、セキュリティ的に何が問題か？」を一目で分かる。
課長は、Security Hub を開く。「あ、Config で ‘RDS 暗号化チェック’ が 5 個失敗。これらは暗号化されてない」。すぐに修正依頼。
CloudTrail を見直し。「これ、誰がした？」。API 呼び出しの履歴から、その日のアクティビティ。「あ、Singapore オンプレのユーザー ID（侵害されたユーザー）が RDS パスワード変更をしてた。7日前」。
監査・コンプライアンスの層 Config — リソース状態の継続監視。ルール違反検出。 CloudFormation — インフラコード化。自動修正。 CloudTrail — API 呼び出し履歴。長期監査。 Security Hub — セキュリティ統合ダッシュボード。
シーン6 — データ保護とプライバシー
朝から対応してるが、もう1つ大事なこと。
「顧客の個人情報が、どうなったか？」
GDPR（EU の規制）、個人情報保護法。セキュリティインシデントは、規定期間内に顧客に通知する義務がある。
でも、データが暗号化されてたら？あるいは、PII が Macie で検出・分類されてたら？「個人情報はこのデータベースの、このテーブルの、この列にある」が分かってれば、被害範囲を限定できる。
Amazon Macie が S3 をスキャン。「あ、このバケットには、クレジットカード番号が平文で保存されてる」。アラート。
すぐに修正。アクセス権限を制限。データを暗号化。
「もし侵入されてたら、どこまで見られた可能性があるか」を判定。「このテーブルだけ」。顧客への通知は、「このテーブルの 500 件が影響」という限定的な報告。
プライバシー・規制対応 Macie — PII 検出。データ分類。 Config — コンプライアンスルール（暗号化必須等）。 KMS ログ — 誰が何を暗号化・復号化したか記録。監査証跡。
試験でやりがちな5つの間違い
さあ、ここまで、セキュリティの全体像を学びました。最後に、試験でやりがちな間違いを列挙します。
間違い 1 — 「暗号化」と言ったら、KMS と思う。
違います。暗号化は 4 層。保存時、転送時、アプリレベル、ネットワークレベル。どの層の暗号化か、理解する。
間違い 2 — GuardDuty は何でも検出する。
違います。GuardDuty はネットワーク・API 異常。データ内容は見てない。データの異常は Macie。脆弱性は Inspector。役割が違う。
間違い 3 — CloudTrail と VPC Flow Logs の違いが分からない。
CloudTrail は「API」。VPC Flow Logs は「ネットワークトラフィック」。別物。同時に見る。
間違い 4 — セキュリティグループで「0.0.0.0/0 を拒否」すれば安全。
セキュリティグループだけじゃ足りない。NACL、Network Firewall、WAF も見る。多層防御。
間違い5：IAMポリシーのResourceを全リソースアスタリスクで指定することは大丈夫だと思うこと。
最悪。最小権限の原則。必要なリソースだけ指定。
試験 TIP — 選択肢を見たときの判断
Q: 「攻撃がありました。原因を特定するには？」 → CloudTrail（API），VPC Flow Logs（ネットワーク），CloudWatch Logs（アプリ）の3つ同時
Q: 「顧客の個人情報の流出を防ぐには？」 → Macie（検出）+ 暗号化 + IAM 権限制限の3つ同時
Q: 「東京オンプレとシンガポール AWS 間の通信を保護するには？」 → Direct Connect MACsec か VPN（転送中）+ セキュリティグループ（インスタンス）+ Transit Gateway セグメンテーション（ルーティング）の3つ同時
SCS-C03 の正答は、たいてい「複数サービスの組み合わせ」。1つのサービスだけで完結する問題は少ない。
試験直前チェックリスト
試験 1 時間前。何を確認します？
□ IAM ポリシー — 最小権限か？Root アカウント使ってないか？
□ 暗号化 — 何が暗号化されてるか。KMS か CloudHSM か。鍵は誰が持つ。
□ ログ — CloudTrail を有効化。CloudWatch Logs を見てるか。VPC Flow Logs は。
□ ネットワーク防御 — WAF、NACL、SG が多層で設定されてるか。
□ 検出 — GuardDuty、Macie、Inspector。各々何を見てるか言えるか。
□ Transit Gateway / VPC ピアリング — 通信できるか。セグメンテーションはか。
□ ハイブリッド接続 — Direct Connect と VPN。両方知ってるか。
□ 監査 — Config、CloudTrail、Security Hub。履歴を取れるか。
□ Cognito vs IAM — 外部ユーザーは Cognito。AWS 管理者は IAM。
□ AWS Secrets Manager — パスワードを平文で保存してないか。
これら、すべてが「有機的に繋がってる」のを理解する。1つ1つのサービスじゃなく、「全体として何が起きてるか」を見る視点。
それが、SCS-C03 の力。
最後に — 激励メッセージ
24 回。長かった。
でも、ここまで来れば、あなたは AWS セキュリティの本質を理解してます。
IAM で権限を絞る。暗号化で情報を守る。ログで痕跡を残す。検出で異常を見つける。ネットワークで層を張る。
これ、AWS クラウドのセキュリティの全部です。
試験本番。「あ、これ習ったサービスだ」って思い出す。そして、「あ、このサービスと組み合わせるのか」って気づく。
複雑に見えるセキュリティも、根本は同じ。5ドメイン 70 のサービス。でも、考え方は一貫してる。
セキュリティの本質は、制御と可視性。
制御：IAM、SG、NACL で「できることを絞る」 可視性：CloudTrail、VPC Flow Logs で「何が起きたか分かる」
この 2 つで、セキュリティの 80% は実現。
試験、頑張ってください。
あなたは準備できてます。知識も、考え方も。
本番で焦ったら、「朝の課長の1日」を思い出す。複数のサービスが並行で動いてる。複合的に判断する。その視点を持てば、難しい問題も解ける。
では、いきましょう。