破壊を防ぐ「最後の砦」：CloudFormationスタックポリシーをコードの指先まで制御する極意
インフラ自動化の聖杯を追い求める諸君。TerraformやCDKによる宣言的構成管理が常識となった今、なぜわざわざ「CloudFormationスタックポリシー」などという古臭い機能に焦点を当てるのか？
答えは単純だ。「人間は必ずミスをする」というハードウェアレベルのバグを、ソフトウェアの設計で封じ込めるためだ。
CI/CDパイプラインがどんなに洗練されていても、コンソールからの悪魔の囁きや、権限を過剰に持ったCI/CDユーザーによる「意図しない破壊」は避けられない。本稿では、スタックポリシーを単なる「拒否リスト」としてではなく、堅牢なインフラガバナンスを構築するための「防御的プログラム」として極限まで活用する知見を共有する。
—
1. スタックポリシーの真髄：宣言的防御の設計思想
スタックポリシーは、単なる権限付与（IAM）の補完ではない。IAMが「誰が操作できるか」を定義するのに対し、スタックポリシーは「そのリソースのライフサイクルに誰が干渉できるか」を定義する。
特に、RDSやDynamoDB、S3バケットといったステートフルなリソースにおいて、スタックポリシーは最強の防壁となる。
究極の防御：全拒否から始めるホワイトリスト戦略
まず、何もかもを禁止し、必要なオペレーションのみを許可する「ネガティブ・セキュリティ」を推奨する。以下は、本番環境のデータベースを一切の更新（Update）から守るためのポリシーだ。
{
“Statement”: [
{
“Effect”: “Deny”,
“Action”: “Update:”,
“Principal”: “”,
“Resource”: “LogicalResourceId/ProductionDatabase”
},
{
“Effect”: “Allow”,
“Action”: “Update:”,
“Principal”: “”,
“Resource”: “”
}
]
}
この設計の肝は、`LogicalResourceId`の指定にある。スタックテンプレート内のリソース名と同期させることで、DR（ディザスタリカバリ）時や緊急パッチ時以外、IaCによる変更すらも「明示的な解除」を必要とさせる。
—
2. APIを用いた「動的ポリシー注入」の自動化
スタックポリシーを静的なファイルとして管理する段階は卒業すべきだ。CI/CDパイプラインの中で、スタックのデプロイ前にポリシーを動的に生成・適用する仕組みこそが、真の自動化である。
Goによるスタックポリシー制御スクリプト（抜粋）
SDK（AWS SDK for Go v2）を使い、パイプラインの途中でポリシーを適用するハックを紹介する。
// SetStackPolicy は、デプロイ前にセーフティネットを張るためのユーティリティ
func SetStackPolicy(ctx context.Context, client cloudformation.Client, stackName string, policyBody string) error {
_, err := client.SetStackPolicy(ctx, &cloudformation.SetStackPolicyInput{
StackName: aws.String(stackName),
StackPolicyBody: aws.String(policyBody),
})
return err
}
このコードをパイプラインの`Pre-Deploy`フェーズに組み込む。これにより、「変更が不要なリソース」を一時的にReadOnly状態にし、パイプラインの暴走による破壊を即座にブロックする運用が可能になる。
—
3. 実践：IaCの暴走を止める「トリガー・ガード」
大規模なマイクロサービス構成では、一つのスタックが数百のネストされたリソースを持つ。ここで「誤ってS3バケットを消去した」という事故は、企業の存続に関わる。
ベストプラクティス：リソースタイプによる制限
スタックポリシー内で特定の `ResourceType` を指定し、更新を厳格に制限する。
{
“Statement”: [
{
“Effect”: “Deny”,
“Action”: [“Update:Replace”, “Update:Delete”],
“Principal”: “”,
“Resource”: “”,
“Condition”: {
“StringEquals”: {
“ResourceType”: [“AWS::RDS::DBInstance”, “AWS::S3::Bucket”]
}
}
}
]
}
なぜこれが必要か？
CDKやCloudFormationは、プロパティの変更を「Update」と解釈するが、裏側で「一度削除して再作成（Replacement）」が発生する場合がある。このポリシーがあれば、たとえテンプレートの記述ミスであっても、「物理的なデータ削除を伴う再作成」を強制的かつ物理的に防ぐことができる。
—
4. エキスパートとしての警告：運用上のアンチパターン
多くのエンジニアが陥る罠が、「スタックポリシーを過信し、解除の手順をブラックボックス化すること」だ。
1. 解除の自動化（Anti-pattern）: パイプライン内で「ポリシー解除→アップデート→ポリシー再適用」を一気通貫で行うと、障害発生時に「ポリシーが解除された状態のまま」になるリスクがある。
2. 推奨する運用: ポリシーの更新は「手動（または特権を持つ別パイプライン）」によるトリガーを必須とし、「変更の重み」を可視化すること。
—
結びに：コードは裏切る、ポリシーは守る
IaCは魔法ではない。それは単なる設定の記述に過ぎない。しかし、スタックポリシーをコードとして扱い、CI/CDパイプラインという自動化のインフラに組み込むことで、システムは「自律的な免疫機能」を持つに至る。
本当のエンジニアリングとは、順調に動くコードを書くことではない。「致命的なエラーが起きたとき、いかにしてシステムを保護し、損害をゼロに抑えるか」という負の領域への設計力こそが、真に価値あるアーキテクトの証なのだ。
さあ、今すぐ全環境のRDSとS3にスタックポリシーを適応せよ。君のインフラに、強固な盾を授けよう。