Amazon SCS-C02: ガバナンス、構成、自動化 — 学習ガイド

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

サービスコントロールポリシーと組織レベルのガードレール

サービスコントロールポリシーは、AWS Organization内のあらゆるプリンシパルが実行できることの最も外側の境界を形成します。SCPはIAMポリシーではありません。SCPは何も許可せず、OUや組織全体に属するアカウントで利用可能な最大の権限を定義するだけです。IAMポリシー、リソースポリシー、またはアクセス許可境界でのAllowは、SCPがそのアクションを拒否している場合、完全に無効になります。この非対称性こそが、リージョン制限、禁止サービスの指定、中央管理IAMロールの保護、リソース作成時の暗号化強制といった、組織全体のガードレールとしてSCPが適切なツールである理由です。

暗号化されていないDynamoDBテーブルとS3バケットの作成を拒否する典型的なSCPは次のようになります。

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

よくある落とし穴は、「組織内の誰もus-east-2を使えないようにする」や「誰もCloudTrailを無効化できないようにする」といった制約を、各アカウントにアタッチされたIAMポリシーで強制しようとすることです。アクセス許可境界とアイデンティティポリシーを整合させたとしても、ローカルの管理者は自身に抜け道を与えることができてしまいます。ルートまたはOUに適用されたSCPだけが信頼できます。なぜなら、それは（ごく一部の制限不可能なアクションという狭い例外を除き）メンバーアカウントのルートユーザーさえも制約するからです。

SCPは、ブレークグラスロールや委任管理ロールも保護すべきです。OrganizationAccountAccessRoleやSecurityAuditといったロールを対象とするアクションには、呼び出し元のaws:PrincipalArnが承認済みリストと一致しない限り、明示的なDenyを追加します。

AWS Config、コンフォーマンスパック、マルチアカウントでの強制

AWS Configは、SCP（防止）を、検出（逸脱を監視・報告）によって補完する継続的な評価レイヤーを提供します。コンフォーマンスパックとは、s3-bucket-server-side-encryption-enabledのようなマネージドルールと、LambdaやGuardをバックエンドとするカスタムルールの両方を含むConfigルールのバンドルであり、オプションの修復アクションと共に単一のデプロイ可能なYAMLアーティファクトとしてパッケージ化されたものです。

標準的なベースラインを組織全体に展開するには、2つのメカニズムを組み合わせます。

• 管理アカウントからのCloudFormation StackSets：サービスマネージド型のアクセス許可とAutoDeployment: Enabledを設定し、組織に参加する新しいアカウントがConfigレコーダーと配信チャネルを有効にするスタックを自動的に受け取るようにします。これによりブートストラップ問題が解決します。つまり、Configが有効になっていないアカウントをコンフォーマンスパックで評価することはできないという問題です。

• 委任管理者アカウントからのコンフォーマンスパックのデプロイ：例えばsecurity-01のようなアカウントからPutOrganizationConformancePackを使用してデプロイします。これにより、各アカウントに手動で触れることなく、現在および将来のすべてのアカウントに一貫したルールセットを伝播させることができます。

委任管理者＋アグリゲーターパターンは重要です。これにより、セキュリティチームはすべてのアカウントのコンプライアンスを1か所で確認できると同時に、アプリケーションチームがローカルで独自のルールを追加することも可能になります。同じルールを管理アカウントから直接デプロイすることも可能ですが、それは最小権限の原則に違反し、職務分掌の監査を妨げます。

CloudFormation Guard、StackSets、Service Catalog

予防はシフトレフトすべきです。CloudFormation Guard (cfn-guard) は、CloudFormationテンプレート（または任意のJSON/YAML）をパースし、デプロイ前に宣言的なルールに照らして評価するポリシーアズコードエンジンです。Guardルールは次のようになります。

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

これをCI/CDステージに組み込むことで（通常はcfn-guard validate -r rules.guard -d template.yamlを実行するDockerコンテナのステップとして）、非準拠のリソースが作成される前にパイプラインを失敗させます。違反があった場合、パイプラインはセキュリティチームがサブスクライブしているSNSトピックに発行し、手動承認のボトルネックになることなく可視性を提供します。セキュリティチームへの通知をStackSetsやCloudFormationの変更セットレビューだけに頼るのは罠です。どちらのサービスもリソースごとのコンプライアンス検出結果を出力せず、スタックが作成された時点ではリソースはすでにアカウント内に存在してしまっているからです。

Service Catalogは、ラストマイルでGuardを補完します。開発者に任意のCloudFormationを書かせる代わりに、プラットフォームチームは検証済みの製品（VPCベースライン、RDSパターン、EKSクラスターなど）をService Catalogポートフォリオとして公開し、AWS RAM経由でアカウント間で共有します。開発者は制約されたパラメータでそれらを起動し、起動制約IAMロールが、開発者自身が持たない昇格された権限でリソースをプロビジョニングします。これにより、基盤となるテンプレートがすでにGuardのチェックをパスしている、監査可能でセルフサービスのデプロイモデルが実現します。

StackSets自体も適切な設定が必要です。組織の管理アカウントからデプロイする際はSERVICE_MANAGEDアクセス許可モデルを使用し、OrganizationsでCloudFormationの信頼されたアクセスを有効にし、実行ロールを慎重に設定します。AdministrationRoleARN/ExecutionRoleNameのペア（セルフマネージドモードの場合）またはサービスにリンクされたロール（サービスマネージドモードの場合）は、実際にリソースを作成するCloudFormationサービスロールに対してiam:PassRoleを許可している必要があります。CloudFormationサービスロールをアタッチし忘れて、代わりにデプロイするユーザーの認証情報に依存すると、iam:PassRoleに関する断続的なAccessDeniedエラーが発生します。これはStackSetオペレーションが失敗する一般的な原因です。正しいパターンは、宣言されたリソースタイプを作成するために必要な権限のみを持つ、スタックごとに1つの専用サービスロールを使用することです。

自動修復パイプライン

Configが非準拠を検出した場合、安全に自己修復できるものはすべて自動的に修復する必要があります。イベントフローは次のとおりです。

• ConfigがデフォルトのイベントバスにCompliance Changeイベントを発行します。

• EventBridgeルールが特定のルールに関するNON_COMPLIANTの検出結果をフィルタリングし、Systems Manager Automationドキュメント（S3暗号化の有効化など、単純でべき等な修正）、Lambda関数（APIレベルの修正）、またはStep Functionsステートマシン（承認、リトライ、またはサービス間のオーケストレーションを必要とする複数ステップのワークフロー）のいずれかをターゲットとします。

たとえば、s3-bucket-public-read-prohibitedがトリガーされると、SSM AutomationランブックAWS-DisableS3BucketPublicReadWriteがそれを修復します。より複雑なフロー、たとえば、KMSキーポリシーがドリフトし、所有チームに通知しながら修正する必要がある場合、Step Functionsが調整します。現在のポリシーを読み取り、ゴールデンバージョンとの差分を確認し、kms:PutKeyPolicyを呼び出し、その後SNSに投稿します。修復ロジックを単一のLambdaではなくStep Functionsに保存することで、各ステップの可観測性が得られ、クリーンなリトライセマンティクスが実現します。

IAM Access Analyzerとポリシー検証

IAM Access Analyzerは2つの異なる問いに答えます。第一に、外部アクセスアナライザーは、定義された信頼ゾーン（アカウントまたは組織）外のプリンシパルへのアクセスを許可するポリシーを持つリソース（S3、KMS、IAMロール、Lambda、SQS、Secrets Manager）を特定します。検出結果を中央で集約するために、委任管理者アカウントから組織レベルでアナライザーを有効にします。

第二に、Access Analyzerのポリシー検証とポリシー生成はオーサリング中に実行されます。aws accessanalyzer validate-policyは、セキュリティ警告、エラー、および提案（たとえば、機密性の高いアクションと組み合わせた過度に広範なResource: "*"のフラグ付け）を返します。これをcfn-guardと同じCI/CDステージに統合し、CloudFormationに埋め込まれたIAMポリシーがデプロイ前にチェックされるようにします。Access Analyzerは、CloudTrailの履歴から最小権限ポリシーを生成することもでき、ワイルドカードポリシーをロールが実際に使用した正確なアクションに置き換えます。これは、「データアクセスに対する最小権限の強制」に対する機械的な答えであり、呼び出し元のサービスがkms:ViaService条件を介してS3、DynamoDB、Lambda、またはEKSである場合にのみkms:Decryptを許可する、スコープを限定したKMSキーポリシーと並行して使用されます。

実践的な問題：ユースケースシナリオ

シナリオ： Meridian Financialは、本番、ステージング、サンドボックス、および中央集権的なセキュリティアカウントを含むマルチアカウントのAWS Organizationを運営しています。彼らは、CloudFormationテンプレートと、サンドボックスでの開発者主導のテンプレートを組み合わせてワークロードをデプロイしています。所有権はチーム間で連合されており、データ暗号化と最小権限アクセスに関する内部ガバナンスを満たす必要があります。

課題： サンドボックスの開発者が誤ってパブリックなS3バケットや過度に寛容なIAMポリシーを作成し、それが他のアカウントに伝播してしまいました。セキュリティチームには、Organization全体で一貫した自動的な強制とテンプレート検証が欠けています。

推奨アプローチ：

1. 組織レベルのサービスコントロールポリシー（SCP）を作成し、パブリックS3を拒否し、バケット暗号化を強制し、特権的なIAMアクションをOrganizationルートで制限して、予防的なガードレールを提供します。
2. 中央のセキュリティアカウントから、CloudFormation StackSetsを使用してAWS Configアグリゲーターと適合パックをすべてのアカウントとリージョンにデプロイし、S3のパブリックアクセス、IAMポリシーのアタッチパターン、暗号化のコンプライアンスを継続的に評価します。
3. CloudFormation Guard（cfn-guard）ルールをCI/CDパイプライン（CodePipeline/CodeBuild）に統合し、承認されたインフラストラクチャに対してService Catalog製品を必須とすることで、テンプレートが検証され、準拠したスタックのみがプロビジョニングされるようにします。
4. 優先度の高い検出結果（パブリックS3の自動ブロック、過度に広範なIAMポリシーの修復）に対して、SSM AutomationドキュメントまたはLambdaランブックを使用したAWS Configの自動修復を有効にし、EventBridgeを介して追加のワークフローをトリガーします。
5. IAM Access Analyzerとポリシー検証を中央で実行し、検出結果をSecurity Hubに取り込み、発見されたクロスアカウントポリシーや過度に寛容なポリシーに対して、チケット作成や修復プレイブックを自動化します。

論理的根拠： このアプローチは、予防的な組織全体のガードレール（SCP）、継続的な検出（Config/適合パック）、シフトレフトのテンプレート検証（cfn-guard/Service Catalog）、およびIAM Access Analyzerによる自動修復を組み合わせることで、最小権限を強制し、AWSのベストプラクティスに従って一貫したマルチアカウントガバナンスを実現します。

AWS Config: 組織ルール、アグリゲーター、委任管理者

AWS Configは、AWSにおける発見的コンプライアンスの基盤です。リソース設定を継続的に記録し、AWSマネージドルール（例: restricted-ssh、vpc-flow-logs-enabled、encrypted-volumes）またはカスタムルール（LambdaやGuardを利用）に照らして評価します。エンタープライズ規模では、ルールそのものよりも、ルールのデプロイ方法、検出結果の集約方法、そして誰がそのツールを所有するかという3つのアーキテクチャ上の決定が重要になります。

AWS Organizations配下のマルチアカウント、マルチリージョン環境では、正しいパターンは、aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.comを使用して委任管理者アカウント（通常は管理アカウントではなく、セキュリティまたは監査アカウント）を指定することです。そのアカウントからPutOrganizationConfigRuleまたはPutOrganizationConformancePackを使用して、すべてのメンバーアカウントとリージョンにルールを展開（fan out）します。委任管理者を設定しない場合、各アカウントで手動でConfigを有効にするか、管理アカウントからすべてを実行する必要に迫られます。後者は職務の分離に違反し、前者は数アカウントを超える規模ではスケールしません。

組織ルールは単一のルール定義をプッシュし、アグリゲーターがその評価結果を収集します。委任管理者アカウントに、すべてのアカウントとリージョンを対象とするOrganizationAggregationSourceを持つアグリゲーターを作成します。これにより、アグリゲーターのダッシュボードで「200のアカウント全体で、どのVPCにフローログが設定されていないか？」といった問いに、アカウントをまたいだロールの切り替えなしで答えることができます。アグリゲーターは読み取り専用であることに注意してください。コンプライアンス状態を表面化させますが、それ自体が修復を行うわけではありません。

ベースライン適用のためのコンフォーマンスパック

コンフォーマンスパックは、Configルールとその修復アクションを単一のYAMLテンプレートにバンドルしたものです。AWSは、PCI DSS、HIPAA、NIST 800-53、CISなどのフレームワークに対応したパックを提供しています。委任管理者から組織コンフォーマンスパックをデプロイすることで、特定のOUをターゲットにできます。例えば、Sandbox OUよりもProd OUに厳格なパックを適用するといったことが可能です。これは、単一のAPIコールでルールセットとその修復の仕組みを一度にすべての場所に伝播させるため、数百のアカウントにわたって一貫したベースラインを適用する最も効率的な方法です。

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

自動修復のパターン

標準的な修復パスは2つあり、どちらを選択するかはレイテンシーと複雑性の要件に依存します。

Configネイティブの修復パスでは、AWS::Config::RemediationConfigurationを使用して、ルールがNON_COMPLIANTを報告するたびにSSM Automationのランブックを呼び出します。AWSはAWS-EnableVPCFlowLogs、AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules、AWSConfigRemediation-EncryptSNSTopicなどの事前構築済みランブックを提供しています。このパスは宣言的で、コンフォーマンスパックとクリーンに統合でき、数分の遅延が許容できる場合に理想的です。

EventBridge駆動のパスは、レイテンシーが重要であるか、カスタムのオーケストレーションが必要な場合に求められます。Configは、すべての状態遷移時にConfig Rules Compliance Changeイベントを発行します。EventBridgeルールはdetail.newEvaluationResult.complianceType = NON_COMPLIANTでフィルタリングし、Lambda関数（またはStep Function、あるいは直接SSMランブック）をターゲットにします。EventBridgeは評価から数秒以内に発火するため、1分未満の修復ウィンドウが実現可能になります。

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

そしてLambdaハンドラーが、問題のあるSGに対してRevokeSecurityGroupIngressを呼び出します。どちらのパスを選択するにせよ、自動化はターゲットリソースを変更するための最小限の権限を持つIAMロールを引き受ける必要があります。よくある失敗モードは、修復ランブックがAccessDeniedでエラーになるために、ConfigルールのコンプライアンスステータスがNON_COMPLIANTとCOMPLIANTの間を無期限に反転し続けることです。Configは呼び出しを記録しますが、サイレントに処理を続行します。常にSSM Automationの実行履歴を検査し、ランブックのロールに必要な特定の変更権限（例: ec2:CreateFlowLogs、フローログ配信ロールのためのiam:PassRole、logs:CreateLogGroup）を付与してください。

Systems Manager AutomationとPatch Manager

SSM Automationのランブックは、命令的な修復における主力ツールです。これらはバージョン管理されたYAML/JSONドキュメントであり、指定したIAMロールによって実行されるステップ（APIコール、承認、分岐）を記述します。Configによってトリガーされる修復以外にも、アクセスキーのローテーション、アタッチされていないEBSボリュームのタグ付け、30日後に停止したインスタンスを終了させるなど、スケジュールされた衛生タスクを実行します。

Patch ManagerはSSMのサブシステムで、オペレーティングシステムをパッチベースライン（承認されたパッチ、分類、および重要度フィルターのセット）に準拠させ続けます。インスタンスはPatch Groupタグを介してパッチグループにグループ化されます。そしてメンテナンスウィンドウが、それらのインスタンスに対してAWS-RunPatchBaselineドキュメントの実行をスケジュールします。コンプライアンスステータスはConfigとSecurity Hubにフィードバックされ、OSレベルの状態と組織的なレポート作成のループを閉じます。

Service Catalog、CloudFormation StackSets、および予防的ガードレール

検知と修復はリアクティブ（事後的）です。コンプライアンス違反を防ぐには、予防的統制を使用します。

• Service Catalogは、キュレートされ、パラメータ化されたCloudFormationテンプレートを製品として公開します。開発者は、基盤となるサービスへのIAM権限を必要とせずに、承認されたパターン（強化されたVPC、暗号化されたRDSクラスターなど）を起動できます。これにより、プラットフォームチームと利用者との間の職務の分離が強制されます。

• CloudFormation StackSetsは、複数のアカウントやリージョンにまたがって同一のスタックをデプロイします。サービスマネージド型のアクセス許可とOUをターゲットにすることで、1回のオペレーションで、組織内のすべてのアカウント（自動デプロイによって新しく作成されたアカウントも含む）にConfigレコーダー、IAMロール、またはGuardDutyディテクターを配置できます。

• **サービスコントロールポリシー（SCP）**は、組織の境界でAPIコールを完全に拒否できる唯一のメカニズムです。ConfigやSSMは、暗号化されていないRunInstancesコールを防ぐことはできず、事後に検知して修復することしかできません。「パブリックなS3バケットは絶対に許可しない」といった厳格な禁止事項をConfigルールのみで強制しようとすると、リソースの作成から修復までの間に隙間が生まれます。Configの検知ルールとs3:PutBucketPublicAccessBlockの拒否などのSCPを組み合わせることで、このギャップを埋めることができます。

災害復旧：バックアップ、テンプレート、ソース管理

RPO/RTOの目標を達成するには、データとインフラストラクチャ定義の両方が回復可能である必要があります。AWS Backupは、EBS、RDS、DynamoDB、EFS、FSxにまたがるバックアップポリシーを一元化します。組織のバックアップポリシーはメンバーアカウント全体でプランを強制し、クロスリージョン、クロスアカウントのコピーはリージョンの喪失やアカウントの侵害から保護します。RPOはバックアップの頻度によって設定され、RTOは復元メカニズムに依存します（DynamoDBのPITR復元は数分、リージョンをまたいだRDSスナップショットの復元は1時間かかる場合があります）。

インフラストラクチャの復旧は、信頼できる唯一の情報源（single source of truth）としてCodeCommit（または他のGitプロバイダー）に保存されたCloudFormationテンプレートに依存します。バージョン管理されたテンプレートからStackSetを再デプロイすることで、復旧リージョンにVPC、IAM、およびアプリケーションスタックを数分で再構築できます。テンプレートをリポジトリなしでコンソールにのみ保持すると、再現可能なアーティファクトが存在しないため、RTOが予測不能になります。

陥りやすい罠の分析

3つの誤解が、一貫して誤答を導きます。第一に、Configを予防的統制として扱うことです。ConfigはCloudTrailが変更を記録した後に評価するため、真の禁止にはSCPが必要です。第二に、適切にスコープされたIAMロールなしで修復を構成することです。SSMドキュメントが存在し、Configルールがトリガーされても、ランブックは権限エラーでサイレントに失敗します。第三に、委任管理者を登録せずに管理アカウントから組織全体のサービスを実行することです。これにより、アカウントごとの手動有効化が強制され、組織全体のアグリゲーターが正しく機能しなくなります。

実践的な問題：ユースケースシナリオ

シナリオ： Meridian Financialは、AWS Organizationsの下で本番、開発、セキュリティの各アカウントを分離したマルチアカウントAWS環境を運用しています。セキュリティチームは、複数のリージョンにまたがる数百のEC2インスタンス、S3バケット、Lambda関数を管理しながら、内部統制と規制当局に対する継続的なコンプライアンスを証明する必要があります。

課題： 最近の監査で、パッチが適用されていないEC2インスタンス、パブリックなS3バケット、アカウント間でのベースライン適用の不整合が発見されました。修復は手動で遅く、予防的統制は一様に適用されていません。

推奨アプローチ：

1. セキュリティアカウントをAWS Configの委任管理者として指定し、CloudFormation StackSetsを介してAWS Configアグリゲーターをデプロイして、すべてのアカウントとリージョンから設定データとコンプライアンスデータを収集します。
2. セキュリティアカウントから組織レベルのAWS Config適合パックを（StackSetsを使用して）デプロイし、ベースラインコントロール（S3のパブリックアクセス、暗号化、タグ付け）をコード化して、同じルールが一貫して適用されるようにします。
3. リスクの高いルールにAWS Configの自動修復アクションをアタッチし、AWS Systems Manager Automationドキュメント（修復ランブックとして登録）を呼び出すことで、違反がSSM AutomationまたはRun Commandによる修復を自動的にトリガーするようにします。
4. AWS Systems Manager Patch ManagerをSSMパッチベースラインおよびState Managerと共に使用して、パッチグループを定義し、アカウント全体のOSパッチ適用を自動化します。パッチコンプライアンスの結果をConfigアグリゲーターにフィードします。
5. 承認されたCloudFormationテンプレートをAWS Service Catalogに発行し、CloudFormation StackSetsを使用してコンプライアンスに準拠したスタックをデプロイまたは更新します。AWS Organizationsのサービスコントロールポリシーで予防的ガードレールを適用し、許可されていないリソース作成（例：パブリックS3バケット作成の無効化）をブロックします。
6. Amazon EventBridge（CloudWatch Events）とSNSを設定して、コンプライアンス違反時にセキュリティチームに通知し、複雑なインシデントに対して追加のSSM Automationワークフローをトリガーします。

論理的根拠： Configアグリゲーターと適合パックによる検知の一元化、SSMによる修復の自動化、Service Catalog/StackSetsおよびSCPによる予防的ガードレールの適用は、セキュリティ、コンプライアンス、最小権限に関するAWSのベストプラクティスに沿った、一貫性のある監査可能な統制と迅速な修復を提供します。

← エッジとアプリケーションセキュリティ · すべてのドメイン · 脆弱性、パッチ、ホストセキュリティ →

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

Amazonを閲覧 →