KMSの「絶対死」を回避せよ：Terraformで構築する堅牢な鍵管理ライフサイクル
KMS（Key Management Service）の運用において、最も恐ろしいのは「鍵の消失」と「権限のデッドロック」だ。多くのエンジニアが「なんとなく」terraform applyを実行し、ある日突然、暗号化されたデータへのアクセス権を永久に喪失する。
本稿では、IaCの深淵を知る者として、KMSの運用を「手作業の残滓」から解放し、完全自動化されたライフサイクル管理へ昇華させるための極限のアーキテクチャを提示する。
—
1. 宣言的ライフサイクルと自動ローテーションの真実
AWS KMSの自動ローテーションは強力だが、Terraformで管理する場合、`deletion_window_in_days`の設定とローテーションポリシーの整合性を疎かにしてはならない。
単に `enable_key_rotation = true` を設定するだけでは不十分だ。鍵のライフサイクルをTerraformで「定義」する際は、「削除を許可するが、即座には消さない」という安全装置をコードに埋め込むことが必須となる。
resource “aws_kms_key” “master_key” {
description = “Production Data Encryption Key”
deletion_window_in_days = 30 # 万が一の削除操作に対するセーフティネット
enable_key_rotation = true
# キーポリシーは別リソースに切り出すのが原則。
# 破壊的変更を検知しやすくし、Policyの衝突を避けるため。
policy = data.aws_iam_policy_document.kms_policy.json
tags = {
ManagedBy = “Terraform”
Purpose = “High-Availability-Storage”
}
}
【深淵の知見】なぜPolicyを別リソースに分けるのか
`aws_kms_key` リソースの中にインラインで `policy` を書くと、Terraformのプラン実行時に、キー自体の変更とポリシーの変更が混在し、依存関係の解決が複雑化する。特にAWSのIAM Policyは非同期で反映されることが多く、「Keyが存在するが、アクセス権がない」という過渡期にCI/CDがコケる事故が多発する。`aws_kms_key_policy` リソースを独立させることで、キー構築後の権限付与という明確な順序を強制できる。
—
2. デプロイ失敗を防ぐ「ポリシー分離」の極意
KMSのポリシー変更は、`Effect: Deny` を誤って適用した場合、即座に全サービスが停止するリスクを孕む。これを防ぐには、「管理者によるセーフガード」をポリシー自体に埋め込む必要がある。
data “aws_iam_policy_document” “kms_policy” {
# Rootユーザーには常に制御権を残す（ロックアウト回避）
statement {
sid = “EnableRootAccountAccess”
effect = “Allow”
principals {
type = “AWS”
identifiers = [“arn:aws:iam::${data.aws_caller_identity.current.account_id}:root”]
}
actions = [“kms:”]
resources = [“”]
}
# ここに各サービス用のアタッチメントを記述する
}
resource “aws_kms_key_policy” “key_policy” {
key_id = aws_kms_key.master_key.id
policy = data.aws_iam_policy_document.kms_policy.json
}
この「Rootアクセスの固定」は、IaC運用における「最後の砦」だ。Terraformのstateが壊れ、誤ったポリシーがデプロイされたとしても、AWSコンソールからRoot権限でリカバリが可能になる。
—
3. 鍵が削除された場合の「完全復旧」パイプライン
KMSの鍵が `PendingDeletion` 状態になった際、Terraformから `cancel_key_deletion` を呼ぶ機能は（執筆時点では）ネイティブなプロバイダには存在しない。
これを自動化するには、Terraformの `external` データソースまたは `null_resource` を用いたトリガーを仕込む必要がある。
削除待機状態のキーを検知して復旧するシェルスクリプトの呼び出し
resource “null_resource” “recovery_trigger” {
triggers = {
key_id = aws_kms_key.master_key.id
}
provisioner “local-exec” { このスクリプトはAPIコールを伴うため、頻繁な `plan` を行うとレート制限に抵触する。大規模環境では、Terraform内で完結させようとせず、EventBridge + Lambdaによる「削除イベント検知 → Slack通知 → 即時復旧」の非同期フローを推奨する。IaCは「あるべき姿」を記述するものであり、「動的なリカバリ」のすべてを担わせるのはメモリ消費と実行時間の観点から非効率だ。 — KMSとTerraformの統合は、単なる設定作業ではない。それは「組織のデータに対する生存権」をコード化する行為だ。 1. Policyの分離: 破壊的な変更を切り離す。 これら3点を守るだけで、あなたのインフラは「壊れない」のではなく、「壊れても即座に、かつ自律的に復旧できる」強靭なシステムへと進化する。 真のエンジニアとは、ツールを使いこなす者ではない。ツールの限界を見極め、その隙間を高度なロジックで埋められる者こそが、この先も生き残る。健闘を祈る。
command = <4. 結び：インフラエンジニアの矜持
2. Rootアクセスの死守: 最後の救済ルートを確保する。
3. ローテーションの自動化: 人為的ミスを排除する。