CloudFormationのセキュリティをSCS視点で完全理解する

この記事はAWS公式ドキュメントを前提に、AWS Certified Security - Specialtyで問われやすいCloudFormationのセキュリティ設計を整理します。

CloudFormationはInfrastructure as Codeのサービスです。ただしSCS視点では「テンプレートでリソースを作る便利サービス」ではありません。CloudFormationは、IAM、ネットワーク、KMS、S3、CloudTrail、Config、Organizations配下の複数アカウントに対して、強い変更権限を集中させる インフラ変更の制御面 です。

だからCloudFormationのセキュリティで見るべき問いは、テンプレートが正しいかだけでは足りません。

• 誰がスタック操作を開始できるか
• CloudFormationはどのIAM権限でリソースを作るか
• IAM RoleやPolicyを作る変更は明示的にレビューされているか
• 本番DB、KMS key、S3 bucketなどの重要リソースが置換や削除されないか
• テンプレートに秘密情報を埋め込んでいないか
• 手作業変更によるドリフトを検知できるか
• 組織標準違反をデプロイ前または実行時に止められるか

画像解説: 左からテンプレート作成、静的検証、Change Set、スタック実行、監査検知へ進む流れです。SCSでは「CloudFormationを許可する」だけではなく、CloudFormationが使うサービスロールと iam:PassRole、Change Setで見える置換、Stack PolicyやTermination Protectionで止める削除、Drift Detectionで見つける手作業変更を分けて考えます。

まず結論

CloudFormationセキュリティの判断軸は7つです。

SCSの問題文では、これらが単独ではなく組み合わせで出ます。たとえば「本番RDSが意図せず置換されないようにしたい」ならChange SetだけでなくStack PolicyやDeletionPolicyも候補になります。「組織全体で暗号化なしS3を禁止したい」ならレビューだけでなくGuard/Hooks、AWS Config、SCPのどこで止めるかを読みます。

CloudFormationの権限モデル

CloudFormationの権限は、呼び出しユーザーの権限だけで終わりません。ここを間違えるとSCSで落ちます。

CloudFormationがスタックを作成、更新、削除するとき、次のどちらかの権限でAWS APIを呼びます。

1. サービスロールを指定していない場合: スタック操作を開始したIAM principalの権限をもとにCloudFormationが操作する
2. サービスロールを指定している場合: CloudFormationがそのサービスロールの権限を使う

サービスロールを使うと、利用者にEC2やRDSを直接作る権限を渡さず、CloudFormation経由だけで作成させる設計ができます。これは最小権限に使えます。一方で、サービスロールが強すぎると権限昇格になります。

重要なのは iam:PassRole です。ユーザーがCloudFormation stackに強いサービスロールを指定できるなら、そのユーザーは直接権限を持っていなくても、CloudFormation経由で強い操作を実行できる可能性があります。

悪い例:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*"
}

改善例:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/cfn-network-deploy-role",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "cloudformation.amazonaws.com"
    }
  }
}

この条件により、渡せるロールと渡す先サービスを限定できます。実務では、ネットワーク用、アプリ用、セキュリティ基盤用、本番用のようにCloudFormationサービスロールを分けます。

CAPABILITY_IAMとCAPABILITY_NAMED_IAM

CloudFormationテンプレートがIAMリソースを作成または変更する場合、CAPABILITY_IAM または CAPABILITY_NAMED_IAM の指定が必要になることがあります。

これは「IAMを作れる魔法の許可」ではありません。意味は、テンプレートがIAM権限に影響することを呼び出し側が明示的に承認することです。

SCSでは次のように読みます。

たとえばSAMや独自Macroを使う場合、レビュー時のテンプレートと実際に展開されるリソースが違うことがあります。SCSで「Macro」「Transform」「予期しないリソース作成」が出たら、展開後のテンプレート、Change Set、レビューの流れを見ます。

Change Setは本番更新の安全装置

Change Setは、スタック更新を実行する前に、CloudFormationがどのリソースを追加、変更、置換、削除するかを表示する機能です。

特に見るべき項目は Replacement です。

Modify AWS::RDS::DBInstance
  Replacement: True

これは「設定を少し変える」ではなく、リソースの作り直しが起きる可能性を示します。RDS、OpenSearch、ElastiCache、EFS、KMS key、S3 bucket、IAM roleなどで置換や削除が起きると、可用性、データ、暗号化、信頼関係に直接影響します。

SCSでの判断:

• 本番DBの名前、エンジン、ストレージ、サブネット関連変更があるならChange Setで置換有無を確認する
• SecurityGroupのIngressが広がるなら差分をレビューする
• IAM Role/Policy追加は権限昇格としてレビューする
• KMS key policyやbucket policy変更はresource policyの影響を見る
• Change Setは「確認」であり、組織標準違反を自動で止めるものではない

Stack Policyで重要リソースを守る

Stack Policyは、スタック更新時に特定リソースへの更新を拒否する仕組みです。典型的には、本番RDSやKMS key、重要S3 bucketなどを不用意な更新から守ります。

例:

{
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "LogicalResourceId/ProductionDatabase"
    },
    {
      "Effect": "Allow",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "*"
    }
  ]
}

Stack Policyのポイントは、削除や置換の影響が大きい論理リソースを守ることです。変更が必要な場合は、一時的に更新ポリシーを緩める運用にします。

ただし、Stack Policyは万能なガバナンスではありません。テンプレートの品質検査、IAM最小権限、Change Set確認、バックアップ、DeletionPolicyと組み合わせて使います。

Termination ProtectionとDeletionPolicy

Termination Protectionは、スタック全体の削除を防ぐ機能です。誤ってDeleteStackしても、保護されていれば削除は失敗します。

ただし重要な注意点があります。Termination Protectionはスタック削除を防ぎますが、スタック更新によってリソースが削除されるケースをすべて防ぐわけではありません。リソースをテンプレートから消す、置換が起きる、条件分岐で作成対象外になる、といった場合は別途守る必要があります。

リソース側では DeletionPolicy と UpdateReplacePolicy を使います。

Resources:
  ProductionDatabase:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Snapshot
    UpdateReplacePolicy: Snapshot
    Properties:
      DBInstanceClass: db.m7g.large
      Engine: postgres
      AllocatedStorage: 100

SCSで「誤削除」「本番データ保護」「置換前にスナップショット」が出たら、Termination Protectionだけでなく DeletionPolicy: Retain や Snapshot、UpdateReplacePolicy も確認します。

機密情報をテンプレートに埋め込まない

CloudFormationテンプレートにDBパスワード、APIキー、秘密鍵を直書きしてはいけません。Git、S3 template bucket、Change Set、イベント、レビュー履歴に残るリスクがあります。

よくある誤解は NoEcho: true です。NoEcho はパラメータ値の表示を抑制しますが、テンプレートやMetadata、Outputsなどに秘密情報を露出させないことを保証するものではありません。

推奨はDynamic referencesです。

Resources:
  AppDatabase:
    Type: AWS::RDS::DBInstance
    Properties:
      MasterUsername: appadmin
      MasterUserPassword: "{{resolve:secretsmanager:prod/db/password:SecretString:password}}"

使い分け:

CloudFormation GuardとHooks

cfn-guard は、CloudFormationテンプレートやJSON/YAML構造に対してポリシーを検査するツールです。たとえば「S3 bucketは暗号化必須」「SecurityGroupで22番を0.0.0.0/0に開けない」「RDSはStorageEncrypted必須」といったルールを書けます。

例:

let buckets = Resources.*[ Type == "AWS::S3::Bucket" ]

rule s3_bucket_encryption when %buckets !empty {
  %buckets.Properties.BucketEncryption exists
}

これはCIでテンプレートを落とすのに向いています。より強く、CloudFormationのスタック操作時にサーバー側で検査したい場合はCloudFormation Hooksを使います。Guard HooksならGuardルールをHookとして有効化し、非準拠リソースを警告または失敗にできます。

SCSでの使い分け:

• 開発者の手元やCIで早く落とす: cfn-lint、cfn-guard
• CloudFormation実行時に組織標準を強制する: CloudFormation Hooks / Guard Hooks
• デプロイ後の継続監視: AWS Config managed/custom rules
• アカウント全体でサービス操作を禁止する: SCP

画像解説: この図は「デプロイ前」「実行前」「実行時」「実行後」に分けたガードレールです。cfn-lintやGuardはテンプレート段階で落とし、Change Setは実際の置換や削除を確認し、Hooksはスタック操作中に非準拠リソースを止め、Drift DetectionやCloudTrailは実行後の説明責任を支えます。SCSでは、問題文がどの時点の制御を求めているかを読むのが近道です。

Drift Detectionは手作業変更の検知

CloudFormation管理下のリソースを、コンソールやCLIで直接変更すると、テンプレート上の期待状態と実リソースの状態がずれます。これがドリフトです。

Drift Detectionは、スタックやリソースの現在状態をテンプレートと比較し、ずれを検知します。

ただし制限があります。

• すべてのリソースタイプやプロパティがドリフト検知に対応するわけではない
• テンプレートで明示されていないデフォルト値は比較対象にならないことがある
• Lambda関数コードなど、CloudFormationが戻し比較できない性質の値もある

SCSで「手作業変更を検知」「CloudFormation外で変更された」「次回更新で上書きされるリスク」と出たらDrift Detectionが候補です。さらにAWS Configで継続監視し、CloudTrailで誰が直接変更したかを追います。

StackSetsのセキュリティ

StackSetsは、複数アカウント、複数リージョンにスタックを展開します。SCSではOrganizations配下の共通セキュリティ基盤、CloudTrail、Config、GuardDuty、Security Hub、IAM baseline、VPC Flow Logsなどで出ます。

重要なのは、展開範囲と権限です。

• Organizations連携のservice-managed permissionsを使うか
• 管理アカウントや委任管理者からどのOUへ配るか
• 自動デプロイで新規アカウントへ配るか
• リージョン追加時に対象外リージョンへ展開しないか
• StackSetの失敗許容数や同時実行数をどうするか

SCSでは「全アカウントへ統制を展開」「新規アカウントにも自動適用」「各アカウントに手作業でロールを作りたくない」と出たらStackSetsとOrganizations連携が強い選択肢です。

CloudTrailと監査

CloudFormationの操作はCloudTrailに残ります。見るべきイベントは、たとえば次のようなものです。

CreateStack
UpdateStack
DeleteStack
CreateChangeSet
ExecuteChangeSet
SetStackPolicy
UpdateTerminationProtection
DetectStackDrift

インシデント調査では、次の対応関係を追います。

誰がUpdateStackを呼んだか
  -> どのテンプレートURL / パラメータだったか
  -> どのサービスロールを使ったか
  -> Change Setで何が変わったか
  -> 実際にどの下位サービスAPIが呼ばれたか

CloudFormationを使うと、実リソースのAPI呼び出しはCloudFormationサービスロール経由に見える場合があります。だから、CloudTrailではスタック操作イベントと下位リソース操作の両方を関連付けて読む必要があります。

よくあるユースケース別の正解

本番RDSをCloudFormation管理にしたい

使うもの:

• Change Setで置換の有無を確認
• DeletionPolicy: Snapshot または Retain
• UpdateReplacePolicy: Snapshot
• Stack Policyで重要DBの更新を制限
• Termination Protectionでスタック削除を防ぐ
• バックアップと復旧手順を別途確認

Change Setだけでは「見える」だけです。止めるにはStack PolicyやDeletionPolicyが必要です。

開発者にVPCやEC2を作らせたいがIAMは触らせたくない

使うもの:

• CloudFormation service roleを限定
• 開発者には cloudformation:CreateStack などを限定
• iam:PassRole は特定のCloudFormation service roleだけ許可
• IAMリソースを含むテンプレートは別パイプラインに分離
• Guard/HooksでSecurityGroupや公開設定を検査

「開発者にAdministratorAccessを渡す」はSCSでは弱い選択肢です。

テンプレートにパスワードを入れたくない

使うもの:

• Secrets ManagerまたはSSM Parameter Store
• Dynamic references
• KMS key policyの確認
• Outputs、Metadata、UserDataへの秘密値露出を避ける

NoEcho だけでは不十分です。

手作業変更を発見したい

使うもの:

• CloudFormation Drift Detection
• AWS Config
• CloudTrail LookupEvents / Lake
• 必要に応じてドリフト修正用Change Set

Drift DetectionはCloudFormation管理リソースの期待状態との差分を見る機能です。Configは継続的な設定評価に向いています。

組織標準違反をデプロイ前に止めたい

使うもの:

• CIで cfn-lint
• CIで cfn-guard validate
• CloudFormation Hooks / Guard Hooks
• AWS Config Conformance Packs
• SCPで禁止すべきAPIを明示的にDeny

SCSでは、どのレイヤーで止めるかが問われます。CIは回避される可能性があります。HooksはCloudFormation実行時に効きます。SCPはCloudFormation以外のAPI呼び出しにも効きますが、細かいリソースプロパティ検査には向きません。

試験での落とし穴

「CloudFormationに権限を与える」は曖昧

実際には、呼び出し側権限、サービスロール、iam:PassRole、作成されるリソースのresource policyが絡みます。AccessDeniedの場所を切り分けます。

Change Setはブロック機能ではない

Change Setは変更内容を確認する機能です。非準拠を自動で止めたいならGuard/Hooksや承認ワークフローを組み合わせます。

Termination Protectionだけでは更新削除を防げない

スタック削除には効きますが、更新でリソースが削除または置換されるケースは別対策が必要です。

Drift Detectionは万能な差分検知ではない

対応していないリソースやプロパティがあります。テンプレートに明示していないデフォルト値の扱いにも注意します。

NoEchoは秘密管理ではない

秘密値はSecrets ManagerやSSM Parameter Storeに置き、CloudFormationではDynamic referencesで参照します。

まとめ

CloudFormationセキュリティは、IaCの静的チェックだけでは完結しません。

SCSでは次の形で覚えると安定します。

作成前: cfn-lint / cfn-guard / review
実行前: Change Set / capability確認
実行時: service role / iam:PassRole / Hooks / Stack Policy
保護: Termination Protection / DeletionPolicy / UpdateReplacePolicy
事後: Drift Detection / CloudTrail / AWS Config

CloudFormationは、AWS環境を安全に標準化するための強力な入口です。同時に、権限昇格や誤削除の入口にもなります。SCSでは「テンプレートを安全に書く」だけでなく、「変更権限を安全に運用する」視点で読むのが正解です。

参考

• AWS CloudFormation best practices
• CloudFormation service role
• Detect unmanaged configuration changes to stacks and resources with drift detection
• Using drift-aware change sets
• What are CloudFormation Hooks?
• What is AWS CloudFormation Guard?