IAMは、AWSの操作権限を管理する仕組みです。「ユーザー」「グループ」「ロール」に「ポリシー（許可の内容をJSONで記述）」を与えて制御します。安全のため、権限は必要最小限にする「最小権限の原則」が基本です。

用語のキホン：認証と認可

アクセス管理は「認証」と「認可」の2段階で考えます。認証（Authentication）は「あなたが誰か」を確かめること（ログイン）、認可（Authorization）は「その人が何をしてよいか」を決めることです。IAMは主にこの認可（ポリシーによる操作の許可・拒否）を担い、多要素認証（MFA）などで認証も強化できます。

ロールと一時認証

特に重要なのが「IAMロール」です。EC2・Lambdaなどにロールを付与すると、STSが発行する一時的な認証情報が自動で供給され、アクセスキーをコードに埋め込まずに安全にアクセスできます。外部IdP（Google等）と連携する「フェデレーション」やクロスアカウントアクセスもロールで実現します。

ポリシー評価と保護

ポリシーには識別ベース・リソースベース・権限境界・SCPなどがあり、評価では明示的な拒否が最優先されます。重要操作にはMFA（多要素認証）を必須にでき、ルートユーザーは極力使わないのが鉄則です。

ある操作が実行できるかどうかは、関係するすべてのポリシーを突き合わせて判定されます。この順序を理解していないと、権限まわりの問題は解けません。

用語のキホン：暗黙のDeny・明示的Allow・明示的Deny

何も書かれていない状態は拒否です。これを暗黙のDenyと呼びます。ポリシーでAllowを書くと許可され（明示的Allow）、Denyを書くと必ず拒否されます（明示的Deny）。優先順位は明示的Deny ＞ 明示的Allow ＞ 暗黙のDenyであり、明示的Denyはどれほど強い権限を持つ相手であっても覆せません。「管理者なのに操作できない」という状況は、たいていどこかに明示的Denyがあるためです。

複数のポリシーが重なる場合

SCP、アイデンティティベースポリシー（ユーザーやロールに付ける）、リソースベースポリシー（S3バケットなどに付ける）、アクセス許可境界（そのIAMエンティティに与えられる権限の上限を別途定める仕組み）、セッションポリシーが関わることがあります。原則として、これらすべてで許可されて初めて実行できます。裏を返せば、どれか1つでもDenyがあれば拒否されます。

STS（Security Token Service）は、有効期限のある一時的な認証情報を発行します。期限が切れれば自動的に使えなくなるため、期限のない長期アクセスキーを配るより格段に安全です。

用語のキホン：ロールの引き受けと信頼ポリシー

AssumeRoleとは、「一時的にそのロールになりきる」操作のことです。ロールには2種類のポリシーがあり、信頼ポリシーが「誰がこのロールを引き受けてよいか」、アクセス許可ポリシーが「引き受けたら何ができるか」を定めます。クロスアカウントアクセスは、相手アカウントのIDを信頼ポリシーに書き、相手側にはAssumeRoleの権限を与える、という二者の合意で成立します。

混乱した代理人問題とExternalID

外部のベンダーに自社ロールを引き受けさせる場合、そのベンダーが他の顧客と取り違えて自社のリソースを操作してしまう危険があります。これを混乱した代理人問題と呼び、対策としてExternalIDという合言葉を信頼ポリシーに設定し、正しい相手だけが引き受けられるようにします。

IAM Identity Centerは、Organizations配下の多数のアカウントに対して、利用者が一度のログインで必要なアカウントと権限に切り替えられるようにするサービスです。ユーザーはIdentity Center内に作ることも、Active Directoryや外部IDプロバイダーと連携することもできます。

用語のキホン：シングルサインオンとフェデレーション

シングルサインオン（SSO）とは、1回の認証で複数のシステムを使えるようにすることです。フェデレーション（IDフェデレーション）とは、自社や外部サービスで管理しているIDを信頼し、AWS側にユーザーを作らずにログインさせる仕組みを指します。そして与える権限のまとまりを許可セットと呼び、「この人はこのアカウントでは読み取りのみ」といった割り当てを1か所で管理します。

IAMユーザーとの違い

アカウントごとにIAMユーザーを作ると、退職時の削除漏れや権限のばらつきが起きます。Identity Centerは都度一時的な認証情報を発行するため、期限のない長期アクセスキーを配布せずに済み、誰がどこに入れるかの棚卸しも1か所で完結します。

多くの企業はユーザーアカウントや端末をActive Directoryで一元管理しています。AWSへ移行する際にこの仕組みをどう扱うかが設計上の論点となり、Directory Serviceがその選択肢を提供します。

用語のキホン：ディレクトリサービスとドメイン参加、信頼関係

ディレクトリサービスとは、社員・端末・共有フォルダといった組織内の資源を階層構造の名簿として管理し、ログイン認証やアクセス権の付与を一元的に行う仕組みです。その代表がActive Directory（AD）で、管理範囲の単位をドメインと呼びます。サーバーやPCをそのドメインの管理下に置くことをドメイン参加といい、参加すると社員は自分のADアカウントでそのサーバーにログインできます。異なるドメイン同士でアカウントを相互に認め合う設定が信頼関係で、これを使うとオンプレミスのADアカウントのままAWS上の資源を利用できます。

3つの選択肢の使い分け

AWS Managed Microsoft ADは本物のADをAWSが運用するもので、信頼関係やグループポリシーなどAD本来の機能をフルに使えます。AD ConnectorはAWSにアカウントを保持せず、認証要求をオンプレミスのADへそのまま転送する橋渡し役で、既存のADをそのまま使い続けたい場合に選びます。Simple ADは小規模向けの互換実装で、信頼関係などの高度な機能は使えません。試験では「オンプレミスADとの信頼関係が必要」ならManaged Microsoft AD、「アカウントはオンプレミスに残したまま」ならAD Connectorが解答になります。

GuardDutyは、CloudTrailやVPCフローログ、DNSログなどを自動で分析し、疑わしい挙動（不審なアクセス、マルウェア通信、既知の悪性IPとの通信など）を検知して知らせるサービスです。機械学習と脅威情報を使うため、自分で細かいルールを作らなくても脅威検知を始められます。

用語のキホン：検出結果と重要度、そして自動対応

GuardDutyが見つけた事象は検出結果（Findings）と呼ばれ、重要度（Low・Medium・High）が付きます。検知の材料になるのは、CloudTrailの操作履歴、VPCフローログ、DNSクエリログなどで、これらを利用者が有効化しなくてもGuardDutyが直接読み取る点が特徴です（そのため導入が数クリックで済みます）。検出結果はEventBridgeのイベントとして流れるため、「Highの検出結果が出たらLambdaを起動して該当EC2を隔離用セキュリティグループに付け替える」といった自動対応（オートリメディエーション）を組めます。

他の検知系サービスとの関係

検出結果はSecurity Hubへ集約して一元管理できます。役割としては、GuardDutyが「脅威の検知」、Inspectorが「脆弱性の検査」、Macieが「機密データの発見」、Detectiveが「検知後の深掘り調査」を担当します。

セキュリティ関連サービスは種類が多く、それぞれの画面を個別に見るのは現実的ではありません。Security Hubは検出結果を集約し、優先度を付けて一覧できるようにします。

用語のキホン：セキュリティ標準とASFF

セキュリティ標準とは、「ルートユーザーにMFAが設定されているか」といったチェック項目をまとめたもので、CIS AWS Foundations BenchmarkやAWS基礎セキュリティのベストプラクティスなどが使えます。Security Hubはこれらを自動採点し、達成率をセキュリティスコアとして示します。また、各サービスがそれぞれ異なる形式で出す検出結果を、ASFF（AWS Security Finding Format）という共通フォーマットに揃えて取り込むため、出どころの違うアラートを同じ物差しで扱えます。

組織全体での運用

Organizationsと連携し、全アカウントの検出結果を管理アカウントへ集約できます。集約結果はEventBridge経由でチケット管理システムや通知へつなぎ、対応漏れを防ぐ運用が定番です。

GuardDutyが「何かおかしい」と教えてくれても、なぜそれが起きたのか、どこまで被害が及んだのかは別途調査が必要です。Detectiveはこの調査工程を支援します。

用語のキホン：検知と調査、そして根本原因分析

セキュリティ運用は大きく、異常を見つける検知と、その事象を掘り下げる調査に分かれます。調査で行うのが根本原因分析で、「いつ、どのアカウントの、どの権限が使われ、どこへ通信したか」を追跡します。Detectiveは複数のログを自動で収集し、リソース同士の関係をグラフモデル（点と線で関係性を表現したデータ構造）として保持します。これにより、あるIPアドレスから始まった一連の操作を、アカウントやインスタンスをまたいで一続きに辿れます。分析対象は数十日分がさかのぼれる形で保持されます。

GuardDutyやSecurity Hubとの関係

3つは役割分担の関係にあります。GuardDutyが検知し、Security Hubが結果を集約して一覧し、Detectiveが個別の事象を深掘りします。GuardDutyの検出結果の画面から直接Detectiveの調査画面へ遷移でき、この連携が試験で問われます。「検知後の調査を効率化したい」「侵害の範囲を特定したい」という文言があればDetectiveが答えです。

InspectorはSystems Managerのエージェントを通じてインストール済みソフトウェアを把握し、既知の脆弱性情報と突き合わせます。ECRのコンテナイメージやLambda関数も対象です。

用語のキホン：脆弱性・CVE・CVSS

脆弱性とは、ソフトウェアに存在する「悪用されうる欠陥」のことです。世界中で発見された脆弱性にはCVEという共通の識別番号（例：CVE-2021-44228）が割り当てられ、どの製品のどの欠陥かを一意に指せます。そして深刻さを0から10の数値で表す指標がCVSSで、数値が大きいほど危険です。Inspectorはこれに加えて「インターネットに公開されているか」といった実際の状況も加味した独自スコアで優先順位を示すため、対応すべき順番が分かります。

継続的スキャンという考え方

従来のように「年1回まとめて検査する」のではなく、新しい脆弱性情報が公開された時点で、既存のリソースを自動的に再評価します。検出結果はSecurity Hubへ集約できます。

CloudTrailは、AWSアカウント内で行われた操作（API呼び出し）を記録するサービスです。「いつ・誰が・どの操作をしたか」を追えるため、監査やインシデント調査の基盤になります。組織全体の証跡をS3へ集約することもできます。

用語のキホン：管理イベントとデータイベント

CloudTrailが記録するイベントは2種類あります。管理イベントは「EC2を起動した」「IAMユーザーを作った」といったリソースそのものへの操作で、既定で記録されます。一方データイベントは「S3のこのオブジェクトを読んだ」「Lambdaを実行した」といったデータへの操作で、量が膨大になるため既定では記録されず、明示的に有効化します。「誰がファイルを持ち出したか」を追うにはデータイベントの有効化が必要——これが試験の頻出ポイントです。また、記録の設定単位を証跡（トレイル）と呼びます。

4つのサービスの役割の違い（頻出）

混同しやすい4つを整理しましょう。CloudTrail＝監査証跡（誰が何をしたか）、CloudWatch＝監視（今どういう状態か）、AWS Config＝構成評価（設定がどう変わり、ルールに適合しているか）、GuardDuty＝脅威検知（不審な挙動がないか）です。改ざん防止のため、証跡の保存先S3にはオブジェクトロックやログファイル検証を設定するのが定石です。

CloudWatchは、AWSリソースやアプリの状態を監視するサービスです。CPU使用率などの「メトリクス」、アプリの「ログ（CloudWatch Logs）」、変化を表す「イベント（EventBridge）」を扱います。

用語のキホン：メトリクス・ログ・イベント

メトリクスは「CPU 70%」のような数値の時系列データ、ログはアプリやOSが出す文字の記録、イベントは「インスタンスが起動した」のような状態変化の通知です。CloudWatchはこの3つを扱い、メトリクスがしきい値を超えたら「アラーム」、イベントが起きたら「EventBridge」で、それぞれ次のアクションにつなげます。

アラームと自動化

「アラーム」でしきい値超過を検知し、SNS通知やAuto Scaling起動、Lambda実行などの自動アクションにつなげられます。OSの中の情報（メモリ使用率など）を取るには「CloudWatchエージェント」を入れます。ログを検索・分析する「Logs Insights」、状況を一覧化する「ダッシュボード」も便利です。

似たサービスとの違い

CloudWatchは「監視・メトリクス・ログ」、CloudTrailは「誰が何をしたかの監査証跡」、Configは「構成の評価」と目的が異なります。混同しやすいので区別しましょう。

AWS Configは、EC2やS3などの設定内容を記録し続け、変更の履歴を残します。さらに「S3バケットは暗号化必須」といった基準をConfigルールとして定義し、違反しているリソースを継続的に検出できます。

用語のキホン：構成項目・構成履歴・コンプライアンス

構成項目とは、あるリソースの、ある時点における設定内容ひとまとめのことです。それを時系列に並べたものが構成履歴で、「先月の末日、この設定はどうなっていたか」を遡って確認できます。そして定めた基準を満たしているかどうかの状態をコンプライアンスと呼び、適合ならCOMPLIANT、違反ならNON_COMPLIANTと判定されます。CloudTrailが「誰がどんな操作をしたか」を記録するのに対し、Configは「設定が今どうなっていて、どう変わったか」という状態を記録する点が決定的な違いです。

自動修復と組織展開

違反を検知したら、Systems Manager Automationを呼び出して自動修復できます（例：意図せず公開されたS3バケットを自動的に非公開へ戻す）。また、複数のルールをまとめたコンフォーマンスパックを組織全体へ一括適用することもできます。

VPC・サブネット・ENI（ネットワークカード）の単位で有効にでき、記録はCloudWatch Logs、S3、Kinesis Data Firehoseへ出力できます。

用語のキホン：何が記録され、何が記録されないか

記録されるのは、送信元・宛先のIPとポート、プロトコル、パケット数・バイト数、そしてACCEPT（許可）かREJECT（拒否）かといったメタデータだけです。通信の中身（ペイロード）は記録されません。中身まで見たい場合は後述のトラフィックミラーリングを使います。切り分けでは、REJECTが記録されていればSGやNACLが原因、そもそもログが1行も出ていなければ通信がそのENIまで到達していない（ルーティングの問題）、と当たりを付けられるのが実務上の要点です。

分析のしかた

S3へ出力してAthenaでSQL分析する、あるいはCloudWatch Logs Insightsでクエリする方法が一般的です。長期保管はS3、即時調査はCloudWatch Logsと使い分けます。

VPCは、AWSの中に自分専用のネットワーク空間を作る仕組みです。まず「CIDR（例：10.0.0.0/16）」でIP範囲を決め、その中を「サブネット」に区切ります。インターネットに公開する層（パブリック）と、DBなど外に出さない層（プライベート）に分けて構築します。

用語のキホン：CIDRとサブネット

CIDR（例：10.0.0.0/16）は、使えるIPアドレスの範囲を表す書き方です。末尾の数字が小さいほど範囲は広く、大きいほど狭くなります。サブネットは、そのIP範囲をさらに小さく区切った区画で、AZごとに作成します。インターネットゲートウェイへの経路を持つ区画をパブリックサブネット、持たない区画をプライベートサブネットと呼び、この2つを分けることがVPC設計の出発点になります。

経路とゲートウェイ

通信の経路は「ルートテーブル」で決めます。インターネットとの出入り口には「インターネットゲートウェイ」、プライベートからの外向き通信だけを許す「NATゲートウェイ」を使います。AWSサービスへ非インターネット経由で繋ぐ「VPCエンドポイント」（S3等向けのゲートウェイ型、その他のインターフェース型）も重要です。

接続と可視化

VPC同士は「ピアリング」や「Transit Gateway」で接続します。通信の記録は「VPCフローログ」で確認できます。ほぼ全てのAWS設計の土台になるため、パブリックとプライベートの分離は必ず理解しておきましょう。

セキュリティグループ（SG）は、EC2などインスタンス単位のファイアウォールです。ステートフルで、許可した通信の戻りは自動で通ります。書けるのは「許可」ルールだけで、デフォルトは全拒否から必要な通信を足していきます。SGは他のSGを参照でき（例：「このWeb-SGからのみ許可」）、柔軟に設計できます。

用語のキホン：ステートフルとステートレス

ステートフルとは、通信の「行き」を覚えていて、その「戻り」を自動的に許可する方式です（セキュリティグループ）。一方ステートレスは、行きと戻りをそれぞれ別の通信として扱うため、両方のルールを書かないと通信が成立しません（ネットワークACL）。NACLで「行き」だけ許可して戻り（エフェメラルポート）を書き忘れ、通信できない——というのが典型的なつまずきポイントです。

NACLとの違い・使い分け

ネットワークACL（NACL）は、サブネット単位のファイアウォールです。ステートレスで、行きと戻りの両方を明示する必要があります。「許可」と「拒否」の両方を番号順に評価するため、特定IPを丸ごとブロックする用途に向きます。SGを主に使い、NACLはサブネット全体の粗い制御として併用する「多層防御」が定石です。

通常、S3やDynamoDBはインターネット側のエンドポイントを持つため、プライベートサブネットからのアクセスにはNATゲートウェイが必要でした。VPCエンドポイントを作ると、その通信をAWS内部のネットワークだけで完結させられます。

用語のキホン：ゲートウェイ型とインターフェース型

ゲートウェイ型は、ルートテーブルに「S3宛はこちら」という経路を追加する方式です。対象はS3とDynamoDBのみで、追加料金はかかりません。インターフェース型（PrivateLink）は、サブネット内にENI（仮想的なネットワークカード）を作り、そのプライベートIP宛に通信する方式です。多くのAWSサービスや他社SaaSにも対応しますが、時間課金と転送量課金が発生します。

閉域化のメリット

インターネットゲートウェイもNATゲートウェイも経由しないため、通信がVPCの外に出ません。「社外に通信を出さないこと」が要件となる金融・医療などの環境で有効です。加えて、NATゲートウェイの処理量が減るぶん料金の削減にもつながります。

AWS Network Firewallは、VPC内を通る通信を検査する、マネージドなネットワーク侵入検知・防御の仕組みです。専用のサブネットにファイアウォールのエンドポイントを配置し、ルートテーブルで通信をそこへ通すように設計します。ルールはステートレスとステートフルの2種類を組み合わせて記述します。

用語のキホン：ステートレスとステートフルの検査

ステートレスな検査とは、パケット1つ1つを前後の文脈と無関係に評価する方式です。処理が軽く高速ですが、「行きを許可したから帰りも許可する」という判断ができないため、往復の両方向にルールが必要になります。対してステートフルな検査は、通信の一連のやり取り（コネクション）を記憶したうえで判断します。行きの通信を許可すれば戻りの通信も自動的に許可され、さらに通信の流れ全体を見るため、接続先のドメイン名による制御や、既知の攻撃パターンとの照合も可能になります。AWSのセキュリティグループはステートフル、ネットワークACLはステートレスという対応関係を思い出すと理解しやすいでしょう。

他のサービスとの使い分け

セキュリティグループとネットワークACLはIPアドレスやポート番号の単位でしか制御できず、しかも設定はリソースごと、サブネットごとに分散します。AWS Network FirewallはVPC単位で通信を集約して検査でき、「許可した特定のドメインへの通信だけ外部に出す」といった要件に応えられます。一方、Webアプリケーションへの受信リクエストの中身を判定するのはAWS WAFの役目です。試験では「VPCから外部への通信を、許可リストのドメインだけに限定したい」という要件でAWS Network Firewallが選ばれます。

AWS WAFは、HTTPやHTTPSのリクエストの中身を見て、通すか遮断するかを判断するサービスです。ネットワーク層のファイアウォールでは見抜けない、アプリケーションの作りを悪用する攻撃に対応します。ルールを自分で書くほか、AWSやセキュリティベンダーが用意した管理ルールグループをそのまま適用することもできます。

用語のキホン：L7攻撃とレート制限

通信は役割ごとに階層に分けて考えられ、いちばん上のアプリケーション層はL7（レイヤー7）と呼ばれます。ここを狙う攻撃がL7攻撃で、見た目は正常なWebアクセスなのに、中身に不正な命令が仕込まれていたり、大量に繰り返されてサーバーを消耗させたりします。代表例がSQLインジェクション（入力欄にデータベースへの命令文を紛れ込ませ、情報を抜き取る攻撃）やクロスサイトスクリプティング（他人のブラウザで動く不正なスクリプトを埋め込む攻撃）です。これに対してレート制限（レートベースルール）は、同じ送信元からの一定時間内のリクエスト数を数え、しきい値を超えた送信元を一時的に遮断する仕組みです。中身が正常に見える攻撃でも、量の異常さで捉えられる点が特徴です。

ルールの構成と試験ポイント

ルールはWeb ACL（ルールをまとめた入れ物）に登録し、それを保護対象のリソースに関連付けて有効化します。判定条件にはIPアドレス、国（地理的一致）、URLのパス、ヘッダー、ボディの内容などを使え、動作は許可・ブロック・カウント（記録のみ）から選べます。試験では「特定の国からのアクセスを遮断したい」「1つのIPからの過剰なリクエストを止めたい」「SQLインジェクション対策をしたい」といった要件が出たらAWS WAFが答えになります。Shieldがネットワーク規模の飽和攻撃を担うのに対し、AWS WAFはリクエスト単位の中身の判定を担う、という役割の違いを押さえてください。

AWS Shieldは、AWS上のリソースをDDoS攻撃から保護する専用サービスです。Standardは申し込み不要で常時働いており、一般的なネットワーク層の攻撃を自動的に緩和します。Advancedは追加契約が必要で、より大規模な攻撃への対応、詳細な可視化、専門チームによる支援が受けられます。

用語のキホン：DDoS攻撃

DDoS攻撃（分散型サービス妨害攻撃）とは、多数の端末から一斉に大量の通信を送りつけ、対象のサーバーや回線を処理しきれない状態にしてサービスを止める攻撃です。大きく分けると、回線の帯域を埋め尽くすボリューム型、通信の接続手順の不備を突くプロトコル型、正常に見えるリクエストを大量に送るアプリケーション層型があります。攻撃元が世界中に分散しているため、単純に1つのIPアドレスを遮断しても止まりません。防御の基本は、攻撃の通信を利用者のサーバーに届く手前で吸収・振り分けること、そして正常な通信と攻撃通信を見分けて捨てることです。AWSの場合、CloudFrontやRoute 53のような世界中に分散した拠点を持つサービスを前段に置くこと自体が、攻撃を分散して受け止める効果を持ちます。

StandardとAdvancedの使い分け

Standardは全AWS利用者に自動適用され、代表的なネットワーク層・トランスポート層の攻撃を防ぎます。Advancedでは、対象リソースを指定した高度な検知、攻撃時の詳細なメトリクスや通知、AWSのDDoS対応チームへのエスカレーション、そして攻撃に起因して急増した利用料金の補填申請といった仕組みが利用できます。Advancedを契約するとAWS WAFの一部機能を追加費用なしで使える点も、試験では「大規模攻撃を受けても止まらない構成」を問う設問の判断材料になります。

アカウントが数十に増えると、各アカウントで個別にWAFのルールを設定するのは現実的ではなく、設定漏れも生じます。Firewall Managerは中央のセキュリティ管理者が一度ポリシーを定義すれば、対象すべてに反映される仕組みを提供します。

用語のキホン：ファイアウォールとポリシーの一元管理

ファイアウォールとは、通信を検査して許可するか遮断するかを判断する仕組みの総称です。AWSでは、Webアプリへの攻撃を防ぐAWS WAF、大規模なDDoS攻撃から守るAWS Shield Advanced、VPCの通信を検査するAWS Network Firewall、そしてセキュリティグループがこれにあたります。Firewall Managerはこれらの設定をセキュリティポリシーとしてまとめ、適用範囲をアカウント単位やタグ単位で指定します。前提としてAWS Organizations（複数アカウントを組織として束ねる仕組み）が有効になっている必要があり、これは試験でよく問われる条件です。

試験での位置づけ

「複数アカウントにまたがって」「新規リソースにも自動的に」「セキュリティ設定の準拠状況を継続的に確認したい」という要件が並べばFirewall Managerです。単一アカウント・単一アプリの保護だけならAWS WAFを直接設定すれば足ります。設定の準拠監査という点でAWS Configと似ていますが、Firewall Managerはファイアウォール系に特化し、適用まで自動で行う点が異なります。

セキュリティグループ、ネットワークACL、ルートテーブル、各種ゲートウェイが積み重なると、人間の目で「本当に外部から到達できないか」を確認するのは困難になります。Network Access Analyzerは、この確認を機械的に行うための機能です。

用語のキホン：到達可能性の静的解析

静的解析とは、システムを実際に動かさず、設定や構成の情報だけを読み取って性質を判定する手法です。Network Access Analyzerは、VPC内の全リソースの設定を数学的なモデルに変換し、「この条件を満たす経路が存在するか」を網羅的に調べます。テストパケットを1つずつ送る方法では試した経路しか分かりませんが、静的解析ならすべての可能性を一度に検証できます。検証したい内容はアクセススコープという定義で表現し、送信元・宛先・プロトコルなどの条件を指定します。AWSはよくある監査項目をテンプレートとして用意しています。

VPC Reachability Analyzerとの違い

両者は目的が逆向きです。VPC Reachability Analyzerは「このEC2からあのRDSに通信できるはずなのに、なぜ届かないのか」という1対1の経路をトラブルシューティングする機能で、送信元と宛先を1つずつ指定し、どこでブロックされたかを示します。一方Network Access Analyzerは「インターネットゲートウェイに到達できるリソースをすべて列挙せよ」といった1対多の網羅的な監査を行い、意図しない経路の発見が目的です。トラブル対応ならReachability Analyzer、セキュリティ監査ならNetwork Access Analyzerと覚えると整理しやすくなります。

KMSは、暗号化に使う鍵（KMSキー／CMK）の作成・保管・アクセス制御をまとめて行うサービスです。S3・EBS・RDS・Secrets Managerなど多くのサービスと連携し、保管中データ（at rest）を簡単に暗号化できます（例：S3のSSE-KMS）。

用語のキホン：保管中と通信中の暗号化

暗号化は2つの場面で考えます。ディスクやS3に「置いてある」データを守るのが保管中の暗号化（at rest）で、これを担うのがKMSです。ネットワークを「流れている」データを守るのが通信中の暗号化（in transit）で、こちらはTLS（HTTPS）が担います。またKMSの鍵には、暗号化と復号に同じ鍵を使う「対称鍵」（一般的）と、別々の鍵を使う「非対称鍵」があります。

仕組みと権限

実データは「データキー」で暗号化し、そのデータキー自体をKMSキーで暗号化する「エンベロープ暗号化」が使われます。鍵の利用可否は「キーポリシー」で制御し、鍵の利用にはIAMの許可とキーポリシーの両方が必要な点が重要です。キーは自動ローテーションでき、細かな委任は「グラント」で行います。暗号化は「保管中＝KMS」「通信中＝TLS」と分けて理解しましょう。

Secrets Managerは、パスワードやAPIキーなどの秘密情報を暗号化して保管し、アプリから安全に取り出せるようにするサービスです。RDSなどと連携して、定期的に自動でパスワードを変更（ローテーション）でき、漏えいリスクを下げます。

用語のキホン：シークレットとローテーション

シークレットとは、漏れると被害が出る情報（DBパスワード、APIキー、トークンなど）の総称です。ローテーションとは、それを定期的に新しい値へ入れ替えることを指し、万一漏えいしても使える期間を短く限定できます。Secrets ManagerはLambda関数を使ってこの入れ替えを自動化し、RDSなどは対応する関数が用意済みです。切り替えの瞬間にアプリが失敗しないよう、新旧の値にAWSCURRENT・AWSPREVIOUSというラベルを付けて段階的に切り替える仕組みになっています。

Parameter Storeとの使い分け

Systems ManagerのParameter Storeは設定値の保管庫で、標準パラメータなら無料で使えます。対してSecrets Managerは有料ですが、自動ローテーションとクロスアカウント共有に対応します。「無料で設定値を置きたいだけ」ならParameter Store、「ローテーションが要件」ならSecrets Manager、が選択の分かれ目です。

暗号化の安全性は、鍵をいかに守るかにかかっています。CloudHSMは鍵を物理的な耐タンパー装置に閉じ込め、その装置の利用者はお客様専有となります。AWSの運用担当者であっても鍵の内容にアクセスできない構成を実現できる点が最大の価値です。

用語のキホン：HSMとシングルテナント、KMSとの違い

HSM（Hardware Security Module、ハードウェアセキュリティモジュール）とは、暗号鍵の生成・保管・演算を専用装置の内部だけで行い、鍵そのものを外部に取り出せないように設計された機器です。不正に開封されると鍵を自動消去する耐タンパー性を備えます。CloudHSMはこの装置を1顧客が占有するシングルテナント方式で、VPC内に配置され、装置の管理ユーザーもお客様が設定します。一方AWS KMSは複数顧客で基盤を共有するマルチテナントのマネージドサービスで、鍵の操作はAPIとIAMで制御しますが、鍵の管理主体はAWSと共同になります。KMSは他のAWSサービスとの統合が容易で安価、CloudHSMは鍵の完全な単独管理と特定の規格準拠が可能、という違いです。

試験での判断基準

問題文に「鍵をお客様が完全に管理」「FIPSの高いレベル準拠」「規制上AWSに鍵を預けられない」「独自の暗号処理をアプリから呼び出す」とあればCloudHSMです。逆に「S3やEBSの暗号化を簡単に」「キーローテーションを自動で」であればKMSを選びます。両者の中間として、KMSのカスタムキーストアとしてCloudHSMを裏側に置き、KMSの使いやすさとHSMの管理性を両立させる構成もあります。

ACMで発行した証明書は、ELB・CloudFront・API Gatewayなどに関連付けて使います。有効期限が近づくと自動で更新されるため、証明書切れによる障害を防げます。

用語のキホン：TLS証明書と暗号化の終端

TLS証明書は、「このドメインは確かにこの運営者のものである」ことを第三者が保証する電子的な証明書で、これを使ってブラウザとサーバー間の通信が暗号化されます。そして暗号化の終端（SSL終端・TLSターミネーション）とは、暗号化された通信をどこで復号するかという設計上の位置を指します。ロードバランサーで復号すれば、その先のEC2は暗号化処理の負荷から解放され、ALBがHTTPの中身を見た振り分けもできるようになります。

使ううえでの注意点

ACMの証明書は秘密鍵を取り出せないため、EC2に直接インストールする用途には使えません（その場合はIAMやACM Private CAを併用します）。またCloudFrontで使う証明書はバージニア北部リージョンで発行する必要がある点が頻出の注意事項です。

大量のファイルが置かれたS3では、どこに機密情報があるか把握できなくなりがちです。Macieはバケットの中身を検査し、機密データの所在とリスクを可視化します。

用語のキホン：機密データ検出とデータ分類

機密データ検出とは、ファイルの中身を読み取り、氏名・住所・マイナンバー・カード番号・アクセスキーなど「守るべき情報」のパターンを見つけ出すことです。データ分類とは、見つけた情報を種類ごとに仕分け、重要度を判定することを指します。あらかじめ用意されたマネージド識別子で一般的な形式は検出でき、社内独自の形式はカスタムデータ識別子（正規表現）で追加できます。

他サービスとの役割の違い

Macieはデータの中身を見る点が特徴です。GuardDutyは「不審な挙動」、Inspectorは「ソフトウェアの脆弱性」、Macieは「機密情報の所在」と、対象が明確に分かれます。

企業では、部門ごと・環境ごとにAWSアカウントを分けるのが一般的です。アカウントを分けると影響範囲を隔離できますが、数が増えると管理が煩雑になります。Organizationsはその管理を一元化します。

用語のキホン：OU・SCP・ガードレール

OU（Organizational Unit、組織単位）とは、アカウントをグループ化するための入れ物で、フォルダのように階層構造を作れます。SCP（Service Control Policy、サービスコントロールポリシー）は、OUやアカウントに対して「これ以上のことはできない」という上限を定めるポリシーです。ここで重要なのは、SCPは権限を与えるものではなく、あくまで許可の上限を絞るものだという点です。実際に操作できるかどうかは、SCPの上限とIAMポリシーの許可の両方を満たすかで決まります。ガードレールとは、利用者の自由をある程度残しつつ、危険な操作だけを組織的に禁止する考え方を指す言葉です。

一括請求と試験ポイント

一括請求（Consolidated Billing）により、組織内の全アカウントの利用料をまとめて支払えます。使用量が合算されるため、ボリューム割引やリザーブドインスタンスの割引を組織全体で共有しやすくなります。試験では「全アカウントで特定リージョン以外の利用を禁止したい」といった要件はSCP、「アカウントごとの権限設定」はIAMと切り分けて考えます。

Systems Managerは単一の機能ではなく、複数の機能の集合体です。EC2だけでなく、オンプレミスのサーバーや他クラウドの仮想マシンも管理対象にできます。

用語のキホン：マネージドノード・エージェント・ドキュメント

マネージドノードとは、Systems Managerの管理下に置かれたサーバーのことです。管理対象になるには、サーバー上でSSM Agentという常駐プログラムが動作し、かつそのサーバーにSystems Managerへのアクセスを許可するIAMロールが付与されている必要があります。ドキュメント（SSM Document）は、実行したい作業手順を記述した定義ファイルで、これを指定することでコマンドや自動化処理を実行します。重要なのは、エージェントがAWS側へ外向きに通信して指示を取りに行く方式のため、サーバー側で受信ポートを開ける必要がないという点です。

主な機能と試験ポイント

Session Managerは、SSHの鍵や踏み台サーバーなしでシェル接続できる機能で、ポート22を閉じたままの運用を可能にします。Patch ManagerはOSパッチの適用を定期実行し、Run Commandは多数のサーバーへ同じコマンドを一括投入します。Parameter Storeは設定値やパスワードを保管する場所で、暗号化にも対応します。なお、パスワードの自動ローテーションが要件に含まれる場合はSecrets Managerが適切です。

各種の認証や法令対応では、「本当に決められた設定になっているか」を示す証拠の提出が求められます。Audit Managerはこの証拠を継続的に自動収集し、監査担当者へ渡せる形に整えます。

用語のキホン：コンプライアンスと証跡、フレームワーク

コンプライアンスとは、法令や業界基準、社内規程に沿って運用できている状態を指します。それを示す記録が証跡（エビデンス）で、たとえば「暗号化が有効である設定内容」や「特定の操作が誰によって行われたかの記録」が該当します。Audit Managerは監査基準ごとの要求事項をまとめたフレームワークという雛形を持ち、PCI DSSやHIPAA、各種のセキュリティ基準に対応した既成のものを選ぶか、自社独自のものを作成できます。フレームワークを選んでアセスメント（評価）を開始すると、CloudTrailやConfig、Security Hubから関連データが自動で集められ続けます。

AWS Configとの違い

AWS Configはリソース設定の変更履歴を記録し、ルールへの準拠状況を評価するサービスで、いわば技術的なチェックの実行役です。Audit Managerはその結果を含む各種情報を、監査基準の項目に紐づけて証拠として整理し、報告書を生成する役です。「監査レポートの作成を自動化したい」とあればAudit Manager、「設定変更を追跡し準拠を判定したい」ならAWS Configと切り分けます。

AWSは長年の運用で得られたベストプラクティスを蓄積しており、Trusted Advisorはそれを自分の環境に照らして自動チェックしてくれます。コンソールを開くだけで結果が確認でき、追加の設定はほとんど不要です。

用語のキホン：5つのチェックカテゴリ

Trusted Advisorの点検は、コスト最適化、パフォーマンス、セキュリティ、フォールトトレランス（障害耐性）、サービスクォータ（利用上限）という5つのカテゴリに分かれています。フォールトトレランスとは、一部が壊れてもシステム全体が動き続ける性質のことで、たとえばEC2が単一のアベイラビリティゾーンに偏っていないかが点検されます。サービスクォータとは、アカウントごとに定められた各リソースの作成上限のことで、上限に近づくと警告が出ます。なお、全カテゴリの全チェックを利用できるのはビジネス以上のサポートプランで、基本のプランでは一部のチェックに限定されます。

試験ポイント：他サービスとの使い分け

Trusted Advisorは「幅広く浅く、既定のベストプラクティスに照らして助言する」ツールです。より深く設計思想まで踏み込んで評価したい場合はWell-Architected Tool、EC2などのサイズが適切かを実測値から判断したい場合はCompute Optimizerが適します。