Amazon DOP-C02: セキュリティ、コンプライアンス、ガバナンス — 学習ガイド

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS DevOps Engineer Professional DOP-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

AWSにおけるセキュリティ、コンプライアンス、ガバナンスは、配信速度を低下させることなく、アカウントやリージョンをまたいでスケールする決定論的なコントロールを基盤としています。堅牢な設計は、IDコントロール（IAM、アクセス許可の境界、サービスコントロールポリシー）、マルチアカウントガバナンス（AWS Organizations、Control Tower）、継続的な評価と修復（AWS Config）、脅威検出（Security Hub、GuardDuty、Inspector）、シークレットの衛生管理、AWS KMSによる暗号化、そしてネットワーク分離（VPCセキュリティグループ、NACL、エンドポイント、PrivateLink）を階層化します。その目的は、爆発半径を最小化し、コンプライアンスを継続的に証明し、最小権限と開発者の自律性を維持しながら、予防と修復を自動化することです。

ID、ポリシー、マルチアカウントガバナンス

IAMロール、ポリシー、アクセス許可の境界、そしてSCPは連携して実効権限セットを形成します。IAMロールのIDベースのポリシーは許可されるアクションを定義し、ロールの信頼ポリシーは誰がそのロールを引き受けられるかを定義します。アクセス許可の境界は、IDポリシーの内容にかかわらず、プリンシパルが実行できることの上限を定めます。AWS OrganizationsのSCPは、メンバーアカウント内のあらゆるプリンシパル（ルートユーザーを含む）に対する絶対的な最大値を設定します。リソースベースのポリシー（S3、KMS、Secrets Managerなど）はアカウント間のアクセスを許可することがありますが、これらもSCPやアクセス許可の境界によって課される上限を超えることはできません。実効権限は、IDポリシー ∩ アクセス許可の境界 ∩ セッションポリシー（存在する場合） ∩ リソースポリシー（該当する場合） ∩ SCP の積集合となり、いかなる明示的なDenyも優先されます。

単一アカウント内で安全なセルフサービスを可能にするには、アクセス許可の境界を使用します。例えば、開発者プロビジョニングパイプラインがロールを作成できるのは、特定のパターンを除きiam:PassRoleを拒否し、機密キーに対するkms:Decryptを拒否し、EC2インスタンスタイプを制限する境界をアタッチする場合のみ、といった設定が可能です。境界は、iam:PutRolePermissionsBoundaryを既に持つプリンシパルのみがアタッチできます。その権限は厳重に保護してください。

SCPは組織全体のガードレールです。一般的なガードレールには、AWS ConfigやCloudTrailの無効化の禁止、組織外からの招待の防止、IAM Identity Centerの委任管理者への変更の拒否、リージョンの制限などがあります。摩擦を最小限に抑えるため、条件付きの例外による明示的な許可パターン（例えば、中央管理者ロールによる変更を許可する）を優先してください。必要なサービスにリンクされたロール（例：GuardDuty、Inspector、Config用）の作成と使用は常に許可してください。さもないと、SCPが意図せずサービスのセットアップをブロックしてしまいます。

AWS Organizationsは、環境（例：サンドボックス、開発、本番）、ワークロードタイプ、例外レーンを分離するための階層的なOUを提供します。ポリシーのドリフトを避けるため、親OUからSCPを継承します。アカウントのセットアップを標準化するために、アカウントプロビジョニングを使用します。CI/CDに統合するには、AWS Control TowerのAccount Factory（コンソール）またはAccount Factory for Terraform（AFT）を利用します。AFTは、GitOpsスタイルのワークフロー、ドリフト検出、機能フラグ（例：エンタープライズサポートのプロビジョニング）を追加し、一貫したベースラインのガードレールを持つ数百のアカウントにスケールします。

AWS Control Towerは、規範的なガードレールを備えたランディングゾーンを自動化します。予防的ガードレールはControl Towerが管理するSCPであり、発見的ガードレールはControl TowerがデプロイするAWS Configルールです。Control TowerはIAM Identity Centerを統合し、SSOと許可セットを提供します。aws:PrincipalTagやID属性によってアクションの範囲を定めるために、ABACベースの許可セットと属性によるアクセスコントロールを使用します。ベースラインを拡張するには、Customizations for AWS Control Tower（CfCT）を使用して、CloudFormation、SCP、ConfigパックをOU/アカウントごとに自動的にデプロイします。グローバルなガードレールを弱めることなく、カスタマイズされたポリシーを必要とするワークロードをホストするために、例外OUを維持してください。

継続的なコンプライアンスと自動修復

委任管理者アカウントから、AWS Configを組織全体で有効化します。すべてのリージョンのすべてのリソースについて記録をオンにし、組織アグリゲーターを使用して組織全体の構成を集約します。一般的なコントロール（例：ebs-encryption-by-default、restricted-ssh、s3-bucket-level-public-access-prohibited）にはマネージドルールを使用し、独自のロジック（例：90日ポリシーに対するKMSローテーション頻度の検証や、デフォルトのタグと値の強制）にはLambdaをバックエンドとするカスタムルールを作成します。コンフォーマンスパックは、ルール、パラメータ、修復アクションを、バージョン管理されたデプロイ可能なバンドルとしてOUごとにグループ化します。これらをバージョン管理システムで維持し、一貫性と監査可能性のためにStackSetsやCfCT経由で展開します。

自動修復によってループを閉じます。各ルールの非準拠の評価を、ベースラインを強制適用するSSM Automationランブックにマッピングします。例えば、デフォルトのインスタンスプロファイルの適用、デフォルト値を持つタグの適用、S3パブリックアクセスブロックの切り替え、メンテナンスのためのEC2インスタンスの再起動などです。ランブックを汎用的に保つために、パラメータ化されたドキュメントと動的な入力（例：Configの検出結果から）を使用します。高リスクのリソースについては、修復が自動実行されるように設定します。機密性の高いアクションについては、EventBridgeとChatOpsを介した変更承認や手動実行を要求します。中央管理者以外によるレコーダーの停止や配信チャネルの削除を拒否するSCPで、Config自体を保護してください。

Firewall Managerは、Organizationsを使用してアカウント全体でpolicy-as-a-serviceを実現し、このレイヤーを補完します。中央管理者を委任し、インターネットに面したALB/API GatewayへのWAFウェブACLの関連付け、VPCセキュリティグループの監査とクリーンアップ、またはDNS Firewallルールの伝播に関するポリシーを作成します。これにより、将来の強制適用は、検出/修復から予防へとシフトします。

脅威検出、シークレットハイジーン、脆弱性管理

Security Hubは、複数のアカウントとリージョンにまたがる検出結果を一元的に表示するダッシュボードとして機能します。委任された管理者で有効化し、検出結果を集約し、関連するスタンダード（AWS Foundational Security Best Practices、CIS、該当する場合はPCI DSS）を有効化します。検出結果はAWS Security Finding Format (ASFF)に流れ込み、GuardDuty、Inspector、IAM Access Analyzer、Config、Macie、およびパートナーツールからの入力を正規化します。EventBridgeのパターンを設定して、重大な検出結果を修復オートメーション（SSM Automation、Lambda）や通知（SNS、チャット）にルーティングします。

GuardDutyは、データプレーンのログパイプラインを管理することなく、マネージドな脅威検出を提供します。CloudTrailの管理イベントとデータイベント、VPCフローログ、Route 53 ResolverのDNSクエリログ、EKS監査ログを分析し、異常な動作、認証情報の漏洩、暗号通貨マイニング、DNSトンネリングなどを検出します。疑わしいアクティビティに対して、S3およびEC2/EBSスキャン用のマルウェア保護を有効化します。組織全体での自動有効化を利用し、シグナルの弱い検出結果は抑制ルールで体系的にアーカイブして、実用的なものに集中できるようにします。

Amazon Inspectorは、EC2（SSMエージェント経由）のパッケージCVE、デプロイ前のECRコンテナイメージの脆弱性、Lambda関数のコードパッケージCVEを継続的に評価します。Inspectorを使用するには、EC2インスタンスにSSM Agentがインストールされ、インスタンスプロファイルでSSMのアクセス許可が与えられ、SSM/KMSエンドポイントへのアウトバウンド通信（インターネットが制限されている場合はVPCエンドポイント経由）が許可されている必要があります。Inspectorを設定して検出結果をSecurity Hubに送信し、Systems Manager Patch Managerやランブック駆動の修復によるパッチ適用ワークフローをトリガーします。タグを使用して、スキャン対象のリソースをスコープし、サンドボックスと規制対象のワークロードを分離します。

Secrets Managerは、シークレットの保存、ローテーション、アカウント間のアクセスを、強力な監査機能とともに一元化します。ローテーションが必要な認証情報には、Parameter StoreよりもSecrets Managerを優先し、RDS/Auroraには組み込みのローテーションを、外部システムにはLambdaベースのローテーションを活用します。ステージングラベル（AWSCURRENT、AWSPREVIOUS）により、ゼロダウンタイムでのローテーションが可能になります。ローテーション用のLambdaは、必要なエンドポイント（Secrets Manager、RDS、KMS）を持つVPC内で実行し、アウトバウンド通信を制限します。アカウント間で利用する場合、他のアカウントのプリンシパルにGetSecretValueを許可するリソースベースのポリシーをアタッチします。シークレットのCMKに対するKMSキーポリシーで、利用側のプリンシパルによる復号と、必要に応じてグラントの作成が許可されていることを確認します。ディザスタリカバリや地域性の制御のために、リージョン間でシークレットをレプリケートし、ローテーションのウィンドウを調整します。

データ保護とネットワークセキュリティ

明示的なキーポリシーを使用して、KMSによる暗号化を設計します。最終的にCMKでの暗号化オペレーションをプリンシパルに認可するのは、IAMポリシーだけではなく、キーポリシーです。最小権限のロールベースのキーポリシーモデルを採用します。管理権限を中央のKMS管理者ロールに委任し、使用権限をワークロードのロールに限定的に付与し、意図しない権限昇格を避けるためにワイルドカード kms:* を許可しないようにします。条件キー（kms:EncryptionContext:*）を使用して、復号を期待されるコンテキストにバインドします。マルチリージョンキーにより、データがリージョン間で複製されるアクティブ/アクティブ構成の暗号化が可能になります。

グラントは、キーポリシーを編集することなく、一時的または厳密にスコープを限定したキーの使用を委任するための適切なツールであり、一部のサービスフロー（例：暗号化された起動テンプレートを使用するEC2 Auto Scaling、アカウント間のAMI使用）で必須です。別のアカウントにグラントの作成を許可するには、キーポリシーでそのアカウントのプリンシパルに kms:CreateGrant を許可する必要があります。被付与者は、同じコールパスですぐに使用するためにグラントトークンを提供しなければなりません。アカウント間で暗号化されたAMIを使用する場合、AMIをコピーしてCMKで暗号化し、AMIを共有し、ターゲットアカウントがCMK上でグラントを作成することを許可し、ターゲットのサービスにリンクされたロールがグラントを受け取るようにします。

エンベロープ暗号化がデフォルトのパターンです。KMSでデータキーを生成し、プレーンテキストのデータキーでデータをローカルに暗号化し、暗号文と暗号化されたデータキーのみを保存します。読み取り時には、KMS Decryptを呼び出してプレーンテキストのデータキーをメモリに復元します。これにより、大きなペイロードに対するKMSの呼び出しを最小限に抑え、プレーンテキストキーの漏洩リスクを限定します。サポートされている場合、運用の簡素化のためにサービスマネージドのSSE-KMS（S3、EBS、RDS）を使用しますが、アカウント間のプロデューサー/コンシューマーのためにキーポリシーを整合させる必要があります。

VPCセキュリティは、最小権限のセキュリティグループから始まります。セキュリティグループはステートフルであり、戻りのトラフィックは暗黙的に許可されます。脆弱なIP許可リストを避け、インフラコードで意図を維持するために、CIDRベースのルールよりもセキュリティグループ参照を優先します。デフォルトのアウトバウンド許可はリスクが高いため、Egressを必要な宛先に明示的に制限し、AWSサービスへのアクセスにはVPCエンドポイントを使用します。NACLはステートレスで最初に評価されます。追加の境界を実装したり、規制要件を満たす必要がある場合にのみ、エフェメラルポートに対する明示的な戻りルールを持つ、粗いサブネットレベルの制御として維持します。それ以外の場合は、管理のしやすさからセキュリティグループを優先します。

VPCエンドポイントを使用して、インターネットへの依存を排除します。ゲートウェイエンドポイント（S3、DynamoDB）は、AWSネットワーク経由でプライベートにルーティングします。エンドポイントポリシーを関連付けて、アクセス可能なバケットやテーブルを制限します。インターフェイスエンドポイント（AWS PrivateLink）は、AWSサービス（Secrets Manager、KMS、SSM、ECR、CloudWatch）をプライベートIP経由で公開します。適切なセキュリティグループを持つサブネットにデプロイし、プライベートDNSを有効にして、標準のサービス名がプライベートアドレスに解決されるようにします。アカウント/VPCをまたがるプロデューサー/コンシューマー型のマイクロサービスでは、NLBをバックエンドに持つエンドポイントサービスを公開し、コンシューマーがPrivateLink経由でそれに接続するインターフェイスエンドポイントを作成することで、ピアリングやトランジットゲートウェイを避け、トラフィックをパブリックインターネットから隔離します。これらの制御を、NATなし、IGWなしのサブネット、およびインターネットアクセスが必要な場合の集中型Egress検査と組み合わせます。

実践的な問題シナリオ

エクスペディアグループは、複数のリージョンにまたがる数百のAWSアカウントに拡大しており、厳格なセキュリティベースラインを適用する必要があります。そのベースラインには、ワークロードのインターネットEgressの禁止、設定ミスの自動修復、脅威検出の集中管理、シークレットのローテーション、標準化されたゴールデンイメージ用の暗号化AMIの制御されたアカウント間共有が含まれます。

AWS OrganizationsとAWS Control Towerによるマルチアカウントガバナンスの確立

アクション: Sandbox、Dev、Prod、SecurityのOUを作成します。Control Towerをデプロイしてランディングゾーンを確立し、必須のガードレールを有効にし、IAM Identity Centerを統合します。Account Factory for Terraform (AFT) を使用して、GitOps経由でアカウントをプロビジョニングします。
理由: Control Towerは、継続的に適用されるターンキーのガードレール（SCPとConfigルール）を提供します。AFTは、大規模なアカウントプロビジョニングを標準化し、ベースラインをバージョン管理でコード化します。

例外付きのグローバルガードレールを適用するためのSCPの作成

アクション: CloudTrailとAWS Configの無効化を拒否し、リージョンを制限し、パブリックなS3 ACLを防止するSCPをアタッチします。Security OUのセキュリティ管理者ロールに対して、条件ベースの例外を含めます。必要なサービスにリンクされたロールの作成/使用を許可します。
理由: SCPは、ルートを含むすべてのプリンシパルの権限に上限を設定し、ドリフトを防ぎつつ、中央のオペレーションのための制御された例外を許可します。

自動修復機能付きのConfigコンフォーマンスパックのデプロイ

アクション: セキュリティの委任管理者アカウントから、組織全体でAWS Configを有効にし、アグリゲーターを作成します。デフォルトでのEBS暗号化、SSHの制限、デフォルト値を持つ必須タグ、パブリックなエントリーポイントでのWAFの必須化を強制するコンフォーマンスパックを展開します。各ルールをSSM Automationドキュメントにマッピングして、自動修正（例：デフォルトのインスタンスプロファイルの添付、欠落しているタグをweeklyに設定）を行います。
理由: コンフォーマンスパックは、一貫性があり監査可能なポリシー・アズ・コードを提供し、自動修復機能により、チケットのやり取りなしに環境をコンプライアンス準拠の状態に保ちます。

Security Hub、GuardDuty、Inspectorによる検出の集中管理

アクション: 委任管理者を使用して、組織全体でGuardDutyとInspectorを有効にします。Security Hubのスタンダード（AWS FSBPとCIS）を有効にし、検出結果を集約します。EventBridgeルールを作成し、重大度の高い検出結果をSSM Automationランブックとオンコール用のSNSトピックにルーティングします。
理由: マネージドな検出と脆弱性評価は、最小限の運用オーバーヘッドで継続的なカバレッジを提供し、Security Hubはシグナルを統合して、より迅速なトリアージと対応を可能にします。

アクセス許可の境界とABACによるIAMの最小権限の徹底

アクション: AFTでプロビジョニングされたアカウントでは、開発者が作成するロールに、厳選されたロール以外への iam:PassRole を拒否し、影響の大きいAPIを制限するアクセス許可の境界をアタッチすることを要求します。IAM Identity Centerの許可セットとABACを使用して、チームタグによってアクションのスコープを限定します。
理由: アクセス許可の境界は、権限昇格を防ぎながら安全なセルフサービスを可能にします。ABACはポリシーの乱立を減らし、ID属性と整合性を保ちます。

VPCエンドポイントとPrivateLinkによるネットワークパスの強化

アクション: アプリケーションサブネットからIGW/NATを削除します。KMS、Secrets Manager、SSM、ECR、CloudWatch用のインターフェイスエンドポイントと、制限的なエンドポイントポリシーを持つS3/DynamoDB用のゲートウェイエンドポイントを作成します。アカウント間の利用のために、PrivateLinkをバックエンドに持つNLBを介して内部プラットフォームサービスを公開します。
理由: プライベート接続はインターネットへの露出をなくし、ロックダウンされた環境でもサービスが到達可能であることを保証します。

アカウント間AMIのためのグラントを使用したKMSキー戦略の実装

アクション: 環境ごとに、ロールでスコープを限定したキーポリシーを持つCMKを作成します。イメージビルド用アカウントで、ゴールデンAMIを暗号化して共有します。CMKポリシーを更新して、ターゲットアカウントがグラントを作成できるようにし、その後、それらのターゲットアカウントのサービスにリンクされたロールに対してグラントを作成します。
理由: グラントは、コンシューマーごとにキーポリシーを編集することなく、スコープが限定され監査可能な委任を提供し、Auto Scalingがアカウントをまたいで暗号化されたAMIから起動できるようにします。

シークレットのローテーションとアカウント間アクセスの標準化

アクション: データベースとAPIの認証情報をSecrets Managerに保存します。RDS以外のターゲットにはLambdaによるローテーションを実装し、RDSには組み込みのローテーションを有効にします。共有プラットフォームのシークレットについては、他のアカウントのコンシューマーロールに GetSecretValue を許可するリソースベースのポリシーをアタッチし、CMKポリシーが復号を許可することを確認します。ローテーション用のLambdaを、必要なエンドポイントがあるVPC内に配置します。
理由: 自動ローテーションは認証情報のリスクを低減します。KMSと連携したリソースポリシーは、最小権限と監査証跡を維持しながら、安全なアカウント間での利用を可能にします。

このアーキテクチャは、エクスペディアグループに、強制力のあるガードレール、証明可能なコンプライアンス、自動修正、厳密に制御されたデータアクセスパスを提供します。これらすべてを、安全なセルフサービスとプライベート接続を通じて開発者のベロシティを維持しながら実現します。

← モニタリング、ロギング、可観測性 · すべてのドメイン · コンテナとサーバーレスオペレーション →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →