AWS SCS-C02 試験ガイド徹底解説：ドメイン別重要ポイントとサービス

最終更新日 2025年11月1日

はじめに：ドメインごとの重点対策が合格のカギです

AWS認定セキュリティ専門知識 (SCS-C02) 試験に合格するためには、試験ガイドに示された6つのドメインそれぞれで問われる重要ポイントを確実に押さえることが重要です。

私は実際に学習を進める中で、「脅威検出」「ログ管理」「インフラセキュリティ」「IAM管理」「データ保護」「ガバナンス」という各分野ごとに頻出サービスやベストプラクティスがあることを痛感しました。

各ドメインの代表的なAWSサービス（IAM、KMS、GuardDutyなど）の実務レベルの知識と、セキュリティ設計上のベストプラクティスを身につけることで、SCS-C02の高難度なシナリオ問題にも対応できるようになります。

本記事では、AWS公式の試験ガイドを徹底的に読み解き、ドメイン1～6それぞれについて重要サービスや頻出テーマを解説します。私自身の実体験や現場での知見も交え、「どんな問題が出るのか」「どのように対策すべきか」をドメイン別にまとめました。

特に新試験SCS-C02で追加されたドメイン6（管理とセキュリティガバナンス）にも注目し、見落としがちなガバナンス領域のポイントもフォローしています。

先に結論を述べると、SCS-C02合格には各ドメインの理解度をバランス良く高めることが不可欠です。

あるドメインだけが極端に苦手だと致命傷になりかねません。セキュリティ専門知識試験では、AWSが提供するあらゆるセキュリティサービスの横断的な知識が求められるため、広範囲に学習する必要があります。

ただし心配はいりません。それぞれのドメインで特に問われるポイントはある程度パターンが決まっています。

これから解説する内容を踏まえて学習すれば、「何を重点的に覚えるべきか」が明確になり、効率良く試験対策を進められるでしょう。それではドメインごとの解説に入ります。

スポンサーリンク

ドメイン1：脅威検出とインシデント対応 (14%)

• Amazon GuardDuty 不正アクセスや異常通信を自動検知。まずは停止せず「隔離」と「証拠保全」が鉄則。
• AWS Security Hub GuardDutyやMacieの検出結果を一元管理。CIS準拠チェックにも対応。
• Amazon Macie S3内の個人情報・機密データを検出。不審アクセスを早期発見。
• Amazon Detective GuardDutyの検出結果をグラフ分析し、根本原因を特定。
• NIST対応プロセス 検知→分析→封じ込め→根絶→復旧の流れを理解。初動は「被害拡大の防止」。
• 自動化対応 EventBridge＋LambdaでGuardDuty検出時に自動隔離や通知を実行。
• IAMキー対応 不正利用時は即無効化・ローテーションし、CloudTrailで影響範囲を追跡。
• 出題パターン 「どのサービスで検知し、次にどれで分析？」の連携理解が鍵。GuardDuty→Security Hub→Detectiveの順。

ドメイン1では、AWS上での脅威検知サービスの理解と、インシデント発生時の対応力が問われます。

実システムでセキュリティインシデントが起きた際、どのように検知し、いかに早く対処するかがテーマです。

たとえば Amazon GuardDuty や Amazon Macie などのマネージドサービスで脅威を検出し、AWS Security Hub で集中管理する流れがよく出題されます。

また、検知後のインシデント対応プロセスについて、NISTサイクル（検知→分析→封じ込め→根絶→復旧）のどのステップで何をすべきか、といった判断も求められます。

私も業務でGuardDutyのアラートを受けたことがありますが、その際はまず対象インスタンスをネットワーク隔離し、ログを収集して原因分析を行いました。

このような初動対応のベストプラクティスを知っているかどうかが試験のポイントになります。

脅威検出の部分では、GuardDuty・Security Hub・Macie といったサービスの特徴を押さえましょう。

GuardDutyは不正なAPIコールやマルウェア通信など脅威の自動検出サービス、Security Hubは各種サービスの検出結果を集約し統一フォーマット(ASFF)で管理・通知するハブ役です。

MacieはS3内の機密データ検出に特化しており、不審なデータアクセスも検知します。また、AWS CloudTrail や AWS Config を使った変更検知もインシデント兆候把握に役立つ知識です（例：IAMポリシーの急な変更はCloudTrailログで追跡）。

さらに、Amazon Detective を使ってGuardDutyの検知結果を深掘り分析する流れも覚えておくと安心です。

試験では「あるサービスで脅威検知→次にどのサービスで調査するか」といった連携を問う問題が出ます【例えばGuardDuty検知→Security Hub経由でDetective分析】。

インシデント対応に関しては、AWSセキュリティインシデント対応ガイドに沿ったベストプラクティスが問われます。

具体的にはIAMアクセスキーの無効化、キーのローテーション、証跡の保存（CloudTrailログを別リージョンへ複製など）といった対策です。

また、インシデント対応を自動化するために Amazon EventBridge（旧CloudWatch Events） と AWS Lambda を組み合わせ、GuardDuty検出イベントに応じてスクリプトで隔離措置を取るような仕組みも頭に入れておきましょう。

以下に、ドメイン1で重要となるサービスやトピックを「重要サービス」「出題例」「対策ポイント」の形式で整理します。

重要サービス/トピック	出題例（シナリオ）	対策ポイント（学習の要点）
Amazon GuardDuty	「EC2インスタンスから異常なAPIコール検知。対応は？」	不審な動きを自動検出するサービス。 初動は対象リソースの隔離（SG変更など）と証拠保全（スナップショット取得等）。
AWS Security Hub	「複数アカウントの検出結果を集中監視しアラートをまとめるには？」	複数サービスの検知結果を統合管理。 標準のセキュリティ基準(CISなど)に対する遵守チェックも可能。
Amazon Macie	「S3バケット内の機密情報漏えいリスクを検出するには？」	S3の機密データ検出サービス。 PIIや秘密情報の検出により、不審なデータアクセスや漏洩リスクを発見。
Amazon Detective	「GuardDutyのアラートについて詳細な関連分析を行う方法は？」	セキュリティイベントをグラフ分析し、根本原因や影響範囲を調査。 GuardDutyやCloudTrailと連携し調査を効率化。
インシデント対応計画	「インシデント対応の手順を問う問題（検出→分析→封じ込め→…）」	NIST推奨のインシデント対応プロセスを理解。 封じ込め＝隔離、根絶＝脆弱性修正、復旧＝サービス再開と覚える。

ドメイン1では、とにかく「検知してから何をするか」の判断力がカギです。

サービスごとの役割と、インシデント発生時の優先度（まず封じ込めか、ログ取得か等）を明確にイメージしておきましょう。過去問でも「GuardDutyが○○を検知。最初に取るべき行動は？」のように出ていますので、即座に「被害拡大の防止策」が出てくるよう準備してください。

スポンサーリンク

ドメイン2：セキュリティロギングとモニタリング (18%)

• AWS CloudTrail すべてのAPIコールを記録。組織のTrailで全アカウント集中管理。
  ログファイル検証を有効化し、S3保存で改ざん防止。
• Amazon CloudWatch（Logs／Alarms） メトリクス監視・ログ監視の中心。
  特定パターン検知でアラーム発砲→SNS通知などの自動対応。
• VPC Flow Logs／DNSクエリログ ネットワーク通信を可視化。
  Flow Logsで許可/拒否履歴を追跡し、DNSログで怪しいドメインを検知。
• ログ分析ツール（Athena／Logs Insights） S3上のCloudTrailログをAthenaでSQL検索。
  Logs Insightsでリアルタイム分析し、特定イベントを素早く特定。
• AWS Config（設定変更監視） リソース構成変更を自動記録。
  例：セキュリティグループの0.0.0.0/0設定を検知→非準拠警告を出す。
• 統合運用ポイント CloudTrailで操作履歴を取得→CloudWatchで監視→Athenaで分析。
  「全方位でログを集め、見張る」設計が試験の鍵。

ドメイン2では、AWS環境のセキュリティログ収集とモニタリング体制について問われます。

AWS上のあらゆる操作やネットワークトラフィックをログとして記録・監視し、異常を検知するしくみを理解する必要があります。

具体的には AWS CloudTrail を用いたAPIコール履歴の追跡、Amazon CloudWatch を用いたメトリクス監視とアラーム発砲、VPCフローログやDNSクエリログによるネットワーク監視などが代表例です。

私自身、あるプロジェクトで誤って重要なセキュリティグループを変更してしまった際、CloudTrailログを確認することで原因究明と影響範囲の把握がスムーズにできた経験があります。

このように「何をログに残し、どう分析するか」が日頃の運用でも試験でもポイントになります。

ログとモニタリングでは、まずCloudTrailの詳細を理解しましょう。

CloudTrailは誰がいつ何をしたか（AWS APIコール）の記録で、すべてのAWSアカウントで組織のTrailを集中管理することも可能です。

試験では「全アカウントのCloudTrailログを一元的に集約する設定」や「ログを改ざんから保護する方法」を問う問題が出ます。正解はOrganizationsの組織的なCloudTrailやS3ログファイルの暗号化・検証です。

次にCloudWatch系サービス。CloudWatch Logsは各種サービスやOSからのログを取り込み保存する仕組みで、特定のパターンを検知するログフィルタや、CloudWatch Alarmsと連動した通知が可能です。

例えば「IAMポリシー変更イベントがCloudTrailログに現れたらアラームを出す」という設定は定番です。またCloudWatch MetricsでCPU利用率やネットワーク流量などから異常兆候を捉えることも含めて押さえてください。

ネットワークモニタリングも重要です。

VPC Flow LogsはVPC内のネットワークインターフェース単位で通信の許可/拒否履歴を出力します。例えば「特定IPからの不審なアクセスを検知する」にはFlow Logsの分析が必要です。

またRoute 53 Resolver Query Logsにより内部DNSクエリを記録する設定も試験範囲に含まれています（マルウェアが怪しいドメイン名を引いていないか等の監視）。

さらに、蓄積したログを分析・検索するスキルも問われます。Amazon Athenaを使ってS3上のログをSQLクエリで検索したり、CloudWatch Logs Insightsでログデータをインタラクティブに分析したりする方法です。

実際の問題では「数百万行のCloudTrailログから特定イベントを迅速に見つけるには？」といった形でAthenaの利用が答えになるケースがあります。

最後にAWS Configにも触れておきます。Configはリソース構成の変更を記録・評価するサービスで、例えば「セキュリティグループに0.0.0.0/0が設定されたら検知する」ようなルールベース監視が可能です。

ドメイン2とドメイン6の境界に位置するサービスですが、ログとしての観点（設定変更の履歴記録）でも重要です。

Configの履歴から「いつどの設定が変わったか」を追跡する能力はモニタリングの一部と言えます。

以上を踏まえて、ドメイン2の重要ポイントを整理した表を示します。

重要サービス/トピック	出題例（シナリオ）	対策ポイント（学習の要点）
AWS CloudTrail	「全アカウントのAPIログを集中管理し改ざん検知する方法は？」	APIコール履歴を記録するサービス。 組織のCloudTrailでマルチアカウント対応。 S3にログ保存＋ログファイル検証有効化で改ざん防止。
Amazon CloudWatch (Logs/Alarms)	「特定イベント発生時にリアルタイム通知を行うには？」	メトリクス監視とログ監視の統合サービス。 Logsにフィルタ設定し、条件一致でアラーム+SNS通知。 重要メトリクス（CPU変動等）にもアラーム設定。
VPC Flow Logs・DNSログ	「あるIPアドレスからの不審な通信を検知・解析するには？」	ネットワークトラフィックの記録。 Flow LogsでVPC内通信の許可/拒否履歴を取得。 DNSクエリログで怪しいドメイン問い合わせを監視。
ログ分析ツール (Athena 等)	「大量のCloudTrailログから特定操作のみ抽出する最適な方法は？」	Amazon AthenaでS3保存ログにSQLクエリ可能。 CloudWatch Logs Insightsでインタラクティブ検索。 ログ分析の効率化サービスを理解。
AWS Config （設定変更監視）	「セキュリティ設定の変更をリアルタイム検知するには？」	リソース設定の変更履歴を記録し、ルールに基づき評価。 例：SGの0.0.0.0/0許可を検知→非準拠アラート。 コンフォーマンスパックで標準遵守チェックも。

ドメイン2では、「あらゆるログを漏れなく集めて見張る」発想が重要です。

CloudTrailだけでなくネットワークや設定変更のログも含め全方位でログを取得し、それらをCloudWatchやAthena等で分析・通知する一連の流れをイメージできれば万全でしょう。

また、ログデータの保存期間や保管場所も問われることがあります（例えばCloudTrailログを一定期間Glue/Athenaで分析可能に保持など）。

自社運用のつもりで、ログの集約・長期保存・分析基盤まで設計できる知識を身につけてください。

スポンサーリンク

ドメイン3：インフラストラクチャのセキュリティ (20%)

• セキュリティグループとNACL SGはインスタンス単位・ステートフルで許可のみ。
  NACLはサブネット単位・ステートレスで許可/拒否ルール両方設定可能。
• VPC設計の基本 重要サーバはプライベートサブネットに配置し、NAT経由で外部通信。
  VPC Reachability AnalyzerやNetwork Access Analyzerで経路検証。
• AWS WAF / AWS Shield WAFはL7層の攻撃（SQLi, XSS）を防御。
  ShieldはDDoS対策で、Advancedで高度防御＋補償サポートを提供。
• AWS Network Firewall VPC内に設置できるマネージドFW。
  ステートフル検査・IP/ドメイン単位のフィルタリングに対応。
• Amazon Inspector EC2やECRの脆弱性を自動スキャン。
  CVEベースの検知結果をSecurity Hubと連携して通知。
• AWS Systems Manager（SSM） Patch Managerで自動パッチ適用、Session Managerで安全なリモートアクセス。
  SSH不要・ポート22閉鎖運用が可能。
• 責任共有モデルの理解 AWSはクラウド“of”セキュリティ（基盤側）、利用者はクラウド“in”セキュリティ（設定・OS管理）を担当。
  「OSパッチ適用は利用者責任」が定番問題。

ドメイン3は、AWSインフラ全般のセキュリティ対策がテーマです。

ネットワークレベルからホストレベルまで、インフラを堅牢化する知識が求められます。

具体的には VPCネットワーク設計（サブネット分離、セキュリティグループやNACLの適切な利用）、ネットワーク境界での防御（WAFやAWS Network Firewallなど）、システムへのパッチ適用や脆弱性管理（Amazon InspectorやSystems Manager）、安全なリモートアクセス方法（例えばSSHの代わりにSSM Session Managerを使う）など幅広いです。

私はこれまで数多くのVPC設計に携わってきましたが、「どこまでがAWS側で、どこからが自分たちで守るべき範囲か」を意識することが大切でした。

この責任共有モデルの理解も含め、AWSインフラを守る全方位の施策が問われるのがドメイン3です。

まずネットワーク層のセキュリティです。

AWSではVPC（仮想プライベートクラウド）がネットワークの基本単位となり、その中でパブリックサブネット（インターネットアクセスあり）とプライベートサブネット（内部のみ）を使い分けて設計します。

試験では「重要なサーバはプライベートサブネットに配置し、NAT経由でのみ外部通信させる」といったベストプラクティスが前提として問われます。

セキュリティグループ(SG)とネットワークACL(NACL)も頻出です。前述のとおりSGはインスタンスレベルの仮想ファイアウォールで、ステートフルにイン/アウト通信を制御します。

NACLはサブネット全体に作用しステートレスなため、特定ポート/IPをブロックする用途に適します。問題で「全インスタンス共通で特定IPからのアクセスを拒否したい」→NACL、逆に「あるWEBサーバだけ80番を許可」→SG、と使い分けられるようにしましょう。

ネットワークの可視性と検証も論点です。

VPC Reachability AnalyzerやNetwork Access Analyzerといったツールで、ネットワーク経路の到達可能性をチェックする機能があります。

SCS-C02ではNetwork Access Analyzer（ネットワークアクセスアナライザー）が新たに範囲入りしており、意図しないアクセス経路の検出に使えるサービスとして知っておきましょう（例えば「このS3エンドポイントがインターネットから実は到達可能だった」等の洗い出し）。

次に境界防御とアプリケーション層のセキュリティです。

AWS WAF（Web Application Firewall）はL7レベルで悪意あるHTTPリクエストをブロックするサービスで、OWASP Top10に代表される攻撃（SQLインジェクションやXSSなど）からアプリケーションを守ります。

AWS Shieldは主にDDoS対策で、Standardは無料でAWSサービスに組み込まれている基本防御、Advancedは有料で高度なL3～L7 DDoS軽減と保険的サポートが受けられます。

試験では「大規模DDoS攻撃に備えるには？」と問われ、答えはShield Advancedの有効化となるでしょう。

また AWS Network Firewall はVPC内にデプロイできるフルマネージドのネットワークフィルタリングサービスで、ステートフル検査やカスタムルール（ドメイン名やIPベースの許可・拒否）を実現します。

例えば「複数AZに跨る集中管理型のファイアウォールを構築するには？」という問題でNetwork Firewallが正解になります。

ホストおよびOSレベルのセキュリティも欠かせません。
Amazon EC2などの仮想サーバでは、パッチ適用やウイルス対策といった従来型のOS管理も必要です。

試験ではAWS Systems Managerが提供する機能（Patch Managerで自動パッチ適用、Session Managerでエージェント経由の安全なシェルアクセスなど）や、Amazon Inspectorによる継続的な脆弱性スキャンが取り上げられます。

InspectorはSCS-C02で重視されており、EC2インスタンスやECRコンテナイメージにCVEベースの脆弱性診断を自動で実施します。

たとえば「新しくリリースされたEC2AMIに既知の脆弱性がないか確認する方法は？」に対しInspectorの活用を答える問題です。

安全なリモートアクセスもトピックです。SSHで直接サーバにログインする代わりにSSM Session Managerを使えば、ポート22を開放せずに内部からセッションを確立できます。これは踏み台サーバを無くすソリューションとしても出題されます。

「サーバへの直接SSHを禁止しセキュアに運用するには？」→Session Managerを使用、といった具合です。

以上をまとめ、ドメイン3の主なポイントを表に整理します。

重要サービス/トピック	出題例（シナリオ）	対策ポイント（学習の要点）
セキュリティグループ & NACL	「特定IPからのアクセスだけVPC全体でブロックしたい。対策は？」	SG: インスタンス単位の状態保存ファイアウォール（許可のみ設定）。 NACL: サブネット単位のステートレスACL（許可・拒否可）。 IPブロックなど広域制限はNACLを適用。
AWS WAF / AWS Shield	「アプリ層の攻撃やDDoSに備えるには？」	WAF: Web攻撃からの防御（SQLi/XSS対策など）。 Shield: DDoS対策。Standardは自動付帯、Advancedで高度防御＋サポート。
AWS Network Firewall	「複数AZにまたがる統合ファイアウォールでIP/ドメインフィルタしたい」	VPCに配置するマネージドネットワークFW。 ステートフル検査やカスタムルール（URLフィルタ等）が可能。 オンプレのUTMのように集中管理のFWをクラウドで実現。
Amazon Inspector	「EC2インスタンスの脆弱性を継続的に検出する方法は？」	脆弱性スキャナサービス。 EC2やECRのソフトウェアを自動チェックしCVE情報を報告。 問題検出時はSecurity Hubにも通知される。
安全なリモートアクセス	「踏み台サーバー無しでEC2に接続し管理するには？」	Systems Manager Session Managerを使用。 エージェント経由でシェルアクセスし、ポート開放不要。 SSH鍵管理負荷や踏み台のリスクを低減。

ドメイン3は範囲が広い分、AWSの責任共有モデルも念頭に置いて整理すると理解しやすいです。

すなわち、クラウド“of”セキュリティ（AWS側）とクラウド“in”セキュリティ（利用者側）の境界です。

AWSはデータセンターやハイパーバイザのセキュリティを担い、利用者はゲストOSやネットワーク設定を適切に守る責任があります。

その利用者責任部分を埋めるサービス群がここで学ぶべき内容です。試験では「EC2のOSパッチ適用は誰の責任か？」（答：利用者）など、暗黙的に責任範囲を理解していることが前提の設問もあります。

インフラの堅牢化策を総合的に身につけ、AWS上で「安全な城を築く」イメージで学習すると良いでしょう。

スポンサーリンク

ドメイン4：アイデンティティ管理とアクセス管理 (16%

• AWS IAM Identity Center（旧SSO） 社内ディレクトリ（例：Azure AD）と連携し、一元的にAWSアクセスを管理。
  IAMユーザーを個別管理せず、フェデレーションによる一時認証が推奨。
• IAMユーザーとロールの使い分け 人間ユーザーにはIdentity Center、システム間アクセスにはIAMロールを使用。
  長期キーではなく一時クレデンシャル（AssumeRole）を利用。
• IAMポリシーと最小権限の原則 必要最小の権限のみ許可。
  条件キー（aws:SourceIp、aws:MultiFactorAuthPresentなど）でアクセスをさらに制限。
• アクセス許可バウンダリ IAMロール作成時に付与できる「権限の上限」。
  開発者が過剰な権限を設定しないようガードレールを設置。
• クロスアカウントアクセス アカウントAに信頼ロールを作成し、アカウントBがAssumeRoleで引き受け。
  S3などではバケットポリシーで他アカウントARNを許可。
• IAM Access Analyzer 外部公開リソースや過剰権限を検出。
  検出結果から最小権限ポリシーを自動生成できる。
• MFAと認証強化 ルートユーザー・管理者にはMFA必須。
  ポリシー条件で「MFA利用時のみ許可」も設定可能。
• AWS OrganizationsのSCP 組織全体でサービス利用を制限する「ガードレール」。
  IAMポリシーより上位で制御し、例：特定OU配下ではEC2起動禁止など。
• 理解の軸 「誰が（ID）」「何に（リソース）」「どんな操作を（アクション）」「どの条件で」を制御できるかを問う。
  ポリシー構造を正確に理解しておくこと。

ドメイン4では、AWSにおけるアイデンティティとアクセス制御（IAM）の知識が問われます。

身分（ユーザーや役割）の管理方法から、きめ細かなアクセス許可ポリシーの書き方、シングルサインオンやフェデレーションの活用まで、認証・認可に関する設計力が試されます。

AWS環境では「誰が何にアクセスできるか」を厳密に制御することがセキュリティの基本です。私も以前、手動で作成したIAMポリシーのミスでストレージへのアクセス権を誤って広く与えてしまったことがあり、痛い教訓を得ました…。

この領域では、そうしたアクセス権限の最小化（最小権限の原則）や中央集権的なID管理の重要性が試験でも強調されています。

まず基本としてIAMの構成要素を整理しましょう。

IAMユーザーはAWSにログイン可能な長期認証情報を持つエンティティですが、人間ユーザーにはなるべく使わない方向です。

代わりにIAMロールを用意し、必要時にスイッチロール（AssumeRole）させるのが推奨です。特に組織内ユーザーはAWS IAM Identity Center（旧AWS SSO）を使ったフェデレーションログインが一般的です。

例えばActive DirectoryやGoogle Workspaceと連携し、社員は企業の認証情報でAWSにシングルサインオンし、裏で一時的なIAMロール資格情報が発行されます。

試験では「社内ユーザーのAWSアクセスを集中管理する方法」=「IAM Identity Centerを使う」が正解となるでしょう。

IAMポリシーについては、その文法（JSON構造）と種類を理解します。

特にインラインポリシーとマネージドポリシーの違い、アイデンティティベースポリシー（ユーザー/ロールにアタッチ）とリソースベースポリシー（S3バケットポリシーなどリソース側に記載）の違いは定番です。

また、最近のトピックであるセッションポリシー（STS発行トークンに付与する一時的ポリシー）やアクセス許可バウンダリ（権限の上限を設定するメカニズム）も専門試験では問われ得ます。

例えば「開発者に任せるIAMロール作成作業で、権限を逸脱しないようにするには？」との問いにアクセス許可バウンダリを使う答えなどです。

クロスアカウントアクセスも重要テーマです。

AWSではアカウント間でリソース共有する場合、片側で信頼されたロールを用意し、他方のアカウントからsts:AssumeRoleで引き受ける形を取ります。

試験では「アカウントAのS3バケットにアカウントBからアクセスさせるには？」→アカウントAのバケットポリシーにアカウントBのロールArnを許可、といったリソースベースポリシーとロールの組み合わせ設定が正解になります。

またIAM Access Analyzerも知っておきましょう。これは組織やアカウント内で外部（他アカウントやパブリック）に開かれたリソースを検知するツールです。

例えば「誰でもアクセスできるS3バケットがないか調べる」ときに有効で、試験でも「Access Analyzerで検出された内容から最小権限ポリシーを生成する」などの使い方が取り上げられます。

MFA（多要素認証）はセキュリティ強化策の定番として理解しておくべきです。

特にルートユーザーへのMFA適用や、IAMユーザーのコンソールログインMFAは基本中の基本です。加えて、プログラムアクセスについてもAWS CLIでMFAを要求する仕組み（条件文でaws:MultiFactorAuthPresentをポリシーに入れる）も試験に出ることがあります。

AWS OrganizationsのSCP（サービスコントロールポリシー）もアクセス管理の一環として関わります。

SCPはドメイン6寄りの内容ですが、複数アカウント運用時に各アカウントで有効化できるサービスを制限するものです。「ルートユーザーでもこれ以上の権限は持てない」ガードレールなので、IAMポリシーとの違い（許可ではなく拒否の上限設定的役割）を理解しましょう。「特定OU配下ではEC2起動禁止」といったシナリオにSCPを使う問題が考えられます。

それでは、ドメイン4の重要項目を表形式で確認します。

重要サービス/トピック	出題例（シナリオ）	対策ポイント（学習の要点）
AWS IAM Identity Center (SSO)	「社内ユーザをADアカウント連携でAWSにログインさせるには？」	シングルサインオンによるフェデレーションを提供。 AD等と連携しユーザを一元管理。 IAMユーザーを極力使わず一時クレデンシャルでアクセス。
IAMポリシーと最小権限	「開発者に必要最小の権限のみ付与するには？」	管理ポリシーとカスタムポリシーの使い分け。 最小権限の原則で必要なアクションだけ許可。 ポリシーに条件(aws:SourceIp等)を付けさらなる絞り込み。
クロスアカウントアクセス	「アカウント間でリソース共有する設定方法は？」	IAMロールの信頼ポリシーとリソースポリシーを組み合わせ実現。 例：アカウントAにロール作成→アカウントBからAssumeRole。 S3等ではバケットポリシーに他アカウント許可を記述。
IAM Access Analyzer	「過剰な権限を持つポリシーを特定し、最小権限案を得る方法は？」	外部アクセス可能なリソースを検出する分析ツール。 未使用の権限や公開設定を洗い出し。 アクセス履歴からポリシー自動生成機能も提供（最小権限化）。
MFAと認証強化	「ルートユーザーや重要ユーザーの認証を強化する方法は？」	多要素認証の有効化。 ルートユーザーMFAは必須級。 IAMポリシー条件でMFA要求可能（aws:MultiFactorAuthPresent）。

ドメイン4では、「誰が（ID）」「何に（リソース）」「どのような操作を（アクション）」「どの条件で」を制御するかを突き詰めて学習しましょう。

試験ではポリシーのJSON読み取り問題も出ますが、構文丸暗記よりはポリシーが意図する効果を論理的に判断できるかが重要です。また、現実のAWS運用で推奨される「人は極力キーを持たず都度AssumeRole」「権限は一か所で集約管理」といった流れを理解していれば、選択肢で迷った時に正しい方向を選べるはずです。

IAMは奥が深いですが、一度原理が分かれば応用が効くので、実際に自分でポリシーを書いたりロールを作ったりして体験的に習得するのがおすすめです。

スポンサーリンク

ドメイン5：データ保護 (18%)

• AWS KMS（Key Management Service） 暗号鍵の作成・管理を行う中心サービス。
  CMKを使いSSE-KMSで暗号化。キーのポリシー設定でアクセスを制御。
• S3の暗号化方式 SSE-S3：AWS管理鍵で自動暗号化。
  SSE-KMS：自社KMSキーを利用し権限管理可能。
  SSE-C：ユーザー提供の鍵を使用。
• Secrets Manager DB認証情報やAPIキーを安全に保存・暗号化。
  IAM制御でアクセスを制限し、自動ローテーションも設定可能。
• データ転送と通信の保護 AWS Certificate Manager（ACM）でTLS証明書を管理。
  ELBやCloudFrontに適用しHTTPS通信を実現（TLS1.2以上推奨）。
• S3の公開制御 Block Public Accessで誤公開を防止。
  暗号化ヘッダ強制（aws:kms指定）で非暗号化アップロードを拒否。
• データライフサイクル管理 S3ライフサイクルで自動削除・アーカイブ設定。
  長期保存にはGlacier Deep Archive、改ざん防止にはObject Lockを活用。
• 耐久性・バックアップ AWS Backupで複数サービスのバックアップ統合管理。
  EBSスナップショットも暗号化して保管可能。
• 試験の要点 保存時（暗号化）・転送時（TLS）・整合性（署名・ハッシュ）をセットで理解。
  「どの暗号化方式を選ぶか」が頻出テーマ。

ドメイン5では、AWS上のデータをいかに保護するか（暗号化・機密管理・耐久性確保）がテーマです。

データ保護はクラウドセキュリティの要であり、保存データの暗号化、転送時の保護、キー管理、機密情報の取り扱い、データライフサイクルなど多岐にわたります。

私もSCS-C02の勉強でKMSや暗号化設定を重点的に学び直し、日々の業務でも「ここは顧客データだからKMS CMKで暗号化しよう」など判断できるようになりました。

試験においても、KMSキーを使った暗号化方式の違いやSecrets Managerによるシークレット管理、S3データの公開制御などが頻出ポイントです。

AWSではデータ暗号化を非常に重視しており、ほぼ全てのサービスで保存データを暗号化するオプションがあります。

中心となるのがAWS Key Management Service (KMS)です。

KMSは鍵の作成・管理・使用を一元化するサービスで、対称暗号キー（CMK）を用いたサーバ側暗号化を主に扱います。試験では、KMSを使った暗号化モードの違いを押さえる必要があります。

例えばS3のサーバサイド暗号化には「SSE-S3（AWSが内部管理するキー使用）」「SSE-KMS（自分のKMSキー使用）」「SSE-C（カスタマー提供キー使用）」の3種類がありますが、どの方式が適切かを判断する問題が典型です。

要は自分で鍵管理・アクセス制御が必要ならKMS、そうでなければAWS管理キーに任せる、という考え方です。

またKMSについてはキーのポリシー（キー使用を誰に許可するか定義するドキュメント）も理解が必要です。キーはデフォルトで作成者（マスターアカウント）にフル権限があり、別アカウントや別ユーザーに使わせるにはキーのポリシーに追記します。

このクロスアカウントでのKMSキー利用はやや複雑なので、過去問に目を通しておくと良いでしょう。

データの機密管理も重要です。例えばデータベースの認証情報やAPIキーなどシークレットは、AWS Secrets Managerで集中安全に保管・自動ローテーションするのが推奨です。

Parameter Store（Systems Managerの一機能）も暗号化パラメータを保存できますが、試験ではより高度なSecrets Managerのほうが話題に上がりやすいです。

「RDSのパスワードを安全にアプリケーションに渡すには？」との問いにSecrets Managerを使うが答えになります。またSecrets ManagerはLambda連携でシークレット自動ローテーションを実装できる点も押さえましょう。

暗号化のアルゴリズムやハッシュに関する知識も求められます。

例えばTLS1.2以上の使用（これはAWS Certificate Manager経由で証明書発行すればOK）や、メッセージの整合性検証にSHA-256などのハッシュを使うこと、署名付きURLでデジタル署名を活用する仕組みなどです。

具体的な暗号プロトコルの深い知識までは不要ですが、AWS上でデータ転送時の保護（HTTPS/TLS）、保存時の保護（暗号化）、改ざん検知（ハッシュ・署名）の3点セットは意識してください。CloudTrailログ検証にデジタル署名を使うのもこの原理です。

データアクセス制御では、S3バケットの公開設定や、オブジェクト単位のポリシー、Amazon S3 Block Public Access機能などが問われます。

例えば「S3バケットの中身を第三者と安全に共有するには？」という問題で事前署名付きURLを使うとか、「すべてのオブジェクトをデフォルト暗号化しつつ、暗号鍵へのアクセス権でデータアクセスを制御する」といったKMSキー＋S3連携の知識が問われます。

S3バケットポリシーで暗号化ヘッダを強制する設定（"x-amz-server-side-encryption":"aws:kms"を要求）もありますので、選択肢に出てきたら理解できるようにしましょう。

データライフサイクルと耐久性についても注意が必要です。

AWSではデータを長期間安全に保持・削除する仕組みとして、S3のライフサイクルポリシー（一定期間後にアーカイブや削除）やObject Lock（WORM設定による削除不可化）、AWS Backupサービス、Glacier Deep Archiveによる長期保管などが提供されています。

試験では「ログデータを改ざん不可かつ一定期間保存するには？」→S3 Object Lockを有効にする、や「規制で7年間保管義務があるデータに対し低コストに保存するには？」→Glacier Deep Archiveを使う、といった問題が考えられます。

またRDSの自動バックアップ保持や、EBSスナップショットの暗号化＆保管について触れられることもあります。

それではドメイン5の主要ポイントを表にまとめます。

重要サービス/トピック	出題例（シナリオ）	対策ポイント（学習の要点）
AWS KMS（キー管理）	「機密データを自社管理の鍵でサーバ側暗号化するには？」	鍵管理サービス。 CMKで対称暗号化、キーにポリシー設定可。 SSE-KMSによる暗号化でアクセス制御を強化（CloudTrailで利用履歴も監査可能）。
S3暗号化設定と公開制御	「S3バケット内の全ファイルを自動で暗号化し、公開ブロックするには？」	S3のバケット設定でデフォルト暗号化を有効化。 方式はSSE-S3 or SSE-KMS選択可（要件次第）。 Block Public Access機能で誤公開を一括防止。
Secrets Manager	「データベースのパスワードを安全にアプリから利用するには？」	シークレット管理サービス。 暗号化保管+必要時に取得（IAMでアクセス管理）。 自動ローテーションも設定可能で、ハードコーディング回避。
データライフサイクル管理	「ログを改ざん不可で1年間保持し、その後削除するには？」	S3 Object LockでWORM設定し改ざん防止。 ライフサイクルポリシーで保存期間を管理（例: 365日後に削除）。 長期保存はGlacier系ストレージ活用。
ACM（証明書管理） ※TLS通信	「自社ドメインのSSL/TLS証明書をAWS上で管理・更新するには？」	AWS Certificate Managerで証明書を無料発行・管理。 ELBやCloudFrontに適用しHTTPS化。 TLS1.2以上の利用で強力な暗号化通信を実現。

ドメイン5攻略のポイントは、「暗号化できるものはすべて暗号化する」くらいの姿勢で各サービスの設定を確認することです。

AWSは「お客様のデータはお客様がコントロールする」が原則なので、KMSキーの権限設定やSecrets Managerによる認証情報の隔離など、データに対する細かな主導権を握る仕組みを提供しています。

試験では、それらを使いこなして「データ漏えいリスクを最小化する設計」ができるかを見ています。

実際のシナリオをイメージし、「このデータが漏れたら大変だ→KMSでしっかりガード」「このキーがバレたらまずい→Secrets Managerで安全に保管」などと考えながらサービスを組み合わせる練習をしておきましょう。

スポンサーリンク

ドメイン6：管理とセキュリティガバナンス (14%)

• AWS Organizations & SCP マルチアカウントを一元管理。
  SCPでOU単位に利用可能サービスを制限し、全体のガードレールを設定。
• AWS Control Tower 推奨ベストプラクティスに沿ったマルチアカウント基盤を自動構築。
  標準SCPやConfigルールを適用し、統制の取れた環境を即時展開。
• コンプライアンス管理 AWS ArtifactでSOC/ISO等の監査レポートを入手。
  Security HubでCIS・PCI準拠状況をスコア化し、Audit Managerで継続監査を実施。
• AWS Config（組織統制） 全アカウントに共通ルールを適用して設定遵守を確認。
  Conformance Packで複数ルールをまとめて配布。
• リスク管理と設計原則 Well-Architectedセキュリティの柱に沿い、攻撃対象領域の縮小・自動化・継続改善を実践。
  IaCやタグ付けもガバナンス強化策。
• 監査・証跡管理 CloudTrail・Config・Security Hubで操作証跡を確保。
  Audit Managerで監査証跡を蓄積し、準拠証明を容易化。
• 継続的改善と訓練 インシデント対応演習（ゲームデイ）やDRテストを定期実施。
  Well-Architectedレビューで改善サイクルを継続。
• 試験の要点 技術対策だけでなく「組織的な統制・証跡・継続的改善」を理解。
  Security Hub・Organizations・Audit Managerの連携が重要。

ドメイン6は、組織的なクラウドセキュリティ管理とガバナンス（統制）に関する知識が問われます。 SCS-C02新試験で追加された領域であり、リスク管理やコンプライアンス遵守、全社的なセキュリティ統制など、技術要素だけでなく運用ポリシー面も含まれる点が特徴です。

私自身、クラウド利用が拡大する中で「技術ソリューションだけではなくポリシー・教育・組織体制も重要だ」と感じていたので、このドメインが増えたのは納得でした。

試験でも「AWS Organizationsを使ったマルチアカウント戦略」や「セキュリティ基準の実践」などが問われ、エンジニアにもガバナンス視点が必要であることを実感しました。

マルチアカウント戦略はクラウドガバナンスの核と言えます。

AWSでは組織（Organizations）サービスを使って複数アカウントを一元管理できますが、試験では「どのようにアカウントを分離すべきか」「ガードレール（SCP）をどう設計するか」が論点になります。例えば「開発用・本番用は別アカウントに分離する」のは基本中の基本ですし「セキュリティ専用アカウントを設けCloudTrailやConfigの集約先にする」といったベストプラクティスも押さえてください。

SCPについては先述の通り、OU単位でサービス使用を禁止したり制限したりできます。問題例としては「あるOU配下ではAmazon S3以外使わせないようにしたい。どう実現する？」→SCPでS3以外Denyとなります。

セキュリティガバナンスでは、クラウド上で業界規制や社内規程に準拠するための仕組みを問う問題が多いです。

例えば、コンプライアンス標準（PCI-DSSやHIPAA、ISO27001など）に対しAWSが提供する支援策を知っておく必要があります。AWS Artifactというサービスでは、各種コンプライアンスの監査レポート（SOC2報告書等）を入手できます。

AWS ConfigやSecurity HubはCIS AWS Foundationsなどの基準に沿ってリソース設定をチェックできますし、AWS Audit Managerは自社のコントロールを継続監査・証跡収集するサービスです。試験でも「PCI-DSS準拠状況を継続的に評価するには？」→Security HubでPCI標準を有効化などの問題が予想されます。

リスク管理とセキュリティプランニングもテーマです。

AWS Well-Architectedフレームワークのセキュリティの柱では、リスクを低減する設計原則（例：単一障害点を無くす、攻撃対象領域を最小化する）がまとめられています。

試験では直接「Well-Architectedのセキュリティ原則は？」と聞かれることは無いかもしれませんが、裏にはそうしたベストプラクティスの考え方が流れています。

例えば「攻撃対象領域の縮小」の実装例として不要なポート閉鎖・サービス停止が挙がったり、「自動化による対応」原則としてEventBridge+Lambdaによる自動修復が選択肢に出たりします。タグ付けの徹底やInfrastructure as Codeの活用も、運用ミス削減やガバナンス強化につながる施策として試験範囲です。

監査への対応も見逃せません。企業でクラウドを使う際、内部監査や外部監査がありますが、AWSにはCloudTrail/Configによる証跡があること、AWS Security Hubの標準スコアレポートが使えること、Audit Managerで日々のコントロール実施記録を蓄積できることを覚えておきましょう。

またセキュリティインシデント対応訓練（ゲームデー）など、組織としての準備や継続的改善もガバナンスの一部です。

試験のシナリオに「企業ポリシーでは年1回DRテストとインシデントレスポンス訓練をすることになっている」等と書かれていれば、そうした文脈を読み取って適切なサービス（例えばAWS BackupやAWS Fault Injection Simulatorを用いた演習）を提案する答えが求められるでしょう。

では、ドメイン6のポイントを表にまとめます。

重要サービス/トピック	出題例（シナリオ）	対策ポイント（学習の要点）
AWS Organizations & SCP	「開発環境では利用サービスを制限し経費やリスクを抑えたい。方法は？」	マルチアカウント管理サービス。 組織単位でアカウントをグループ化。 SCPで特定サービス利用禁止などガードレール設定（ルートユーザにも適用）。
AWS Control Tower	「マルチアカウント環境をガイドラインに沿って簡単に構築するには？」	複数アカウントのセットアップ自動化サービス。 ベストプラクティスOU構成と標準SCP/Configルール（ガードレール）を適用。 迅速に統制の取れた基盤を構築可能。
コンプライアンス管理	「AWS上の環境が業界基準に準拠しているか確認・証明するには？」	AWS Artifactで各種監査レポート入手（SOC, ISOなど）。 Security HubでCISやPCI基準に対する自環境評価。 Audit Managerで社内コントロール遵守状況を継続監査。
AWS Config（組織一括管理）	「全アカウントでリソース設定のポリシー違反を検出するには？」	組織単位のConfigルールで全アカウントに一貫適用。 例：タグ未設定リソース検出など統制強化。 Conformance Packで複数ルールを基準セットとしてデプロイ。
継続的ガバナンス改善	「セキュリティインシデント対応力を組織的に向上させる施策は？」	定期的訓練とレビュー。 インシデント対応のゲームデイ演習、DRテスト実施。 Well-Architectedレビューで問題点洗出し→改善サイクルを回す。

ドメイン6は技術寄りでない分ハードルを感じるかもしれませんが、「クラウド利用を全社レベルで統制し安全に保つ」ための仕組みと考えれば腹落ちします。AWSは単なる技術プラットフォームではなく、大企業のセキュリティ・コンプライアンス要求にも応えられるよう豊富なガバナンス機能を備えています。

試験では、そのことを理解しているかをケーススタディ形式で確認してきます。

最後の仕上げとして、AWSが公開しているセキュリティ白書やベストプラクティス集（例えば「AWS Well-Architected セキュリティの柱」や「クラウド環境のためのセキュリティモニタリング戦略」等）に目を通し、全体観を掴んでおくのも有効です。

スポンサーリンク

まとめ：ドメインごとの重要ポイントを網羅して合格へ

AWS SCS-C02試験では、以上のように6つのドメインそれぞれからバランス良く出題がなされます。

脅威検出からガバナンスまで領域は広いですが、裏を返せば各ドメインの頻出サービスや概念を押さえれば効率的に得点できます。私の実感では、「この分野は捨てよう」というのが通用しない試験でした。

どのドメインも出題割合が15～20%程度あり、満遍なく学習する必要があります。

そこで、まず本記事で触れたドメイン別の重要ポイントをベースに、自分の弱点領域を洗い出してみてください。

例えばIAMや暗号化に苦手意識があるなら重点補強が必要ですし、逆に得意分野でも新サービス（Network Access AnalyzerやAudit Manager等）には目を通すようにしましょう。

また、各ドメイン内容は相互に関連しています。例えばCloudTrailログ（ドメイン2）から脅威検知（ドメイン1）に繋がりますし、IAMベストプラクティス（ドメイン4）を実践することでインフラ全体のリスク低減（ドメイン3,6）にもなります。単なる丸暗記ではなく、実践的にサービス同士を組み合わせて使うイメージを持つことが合格への近道です。

最後に一つアドバイスですが、SCS-C02は専門知識試験とはいえ実務経験が非常に活きる試験です。

もし可能であれば、自分のAWS環境でGuardDutyやConfigを有効化してみたり、KMSでカスタムキーを作ってS3を暗号化してみたり、ハンズオンで体感してみてください。

私も実際に試したサービスほど問題文を読んだとき具体的な情景が浮かび、落ち着いて回答できました。ドメインごとの学習を進めつつ、適宜AWSのドキュメントやホワイトペーパーで裏付けを取りながら、総合力を高めてください。

6つのドメイン知識が揃った暁には、きっと高得点での合格が見えてくるはずです。健闘を祈ります！

スポンサーリンク

参考資料：AWS公式リンク集

• AWS Certified Security – Specialty (SCS-C02) 試験ガイド（公式ドメイン範囲と解説）
• AWS セキュリティインシデント対応ガイド（クラウドにおけるインシデント対応ベストプラクティス）
• AWS Well-Architected フレームワーク – セキュリティの柱（セキュリティ設計原則とベストプラクティス集）
• AWS Key Management Service ベストプラクティス（AWS KMSの安全な利用方法と推奨事項）
• IAM におけるセキュリティベストプラクティス（アイデンティティ管理の推奨事項まとめ）
• 責任共有モデル – AWSクラウドにおけるセキュリティ責任の分担（クラウド利用者とAWSの責任範囲解説）

スポンサーリンク