KMSキー管理の「死の淵」を歩かないために：Terraformによる自動ローテーションと破壊的変更の完全制圧
クラウドインフラの深淵において、KMS（Key Management Service）の管理は「聖域」だ。ここを誤れば、データは永遠に暗闇へ消え、リカバリ不可能な絶望がチームを襲う。
多くのエンジニアがTerraformでのKMS管理を「ただのリソース定義」と考えているが、それは甘い。これは「データの生死を司る契約」だ。今回は、現場で血を流しながら学んだ、KMSを安全かつ堅牢に自動化する極意を授ける。
—
1. KMS自動ローテーションの「真の設計」
AWS KMSの自動ローテーションは便利だが、Terraformで管理する際は「いつ有効化すべきか」というタイミングが重要だ。既存キーに対して事後的に適用する場合、TerraformのStateとAWS側の実態が乖離してデプロイがスタックするリスクがある。
堅牢なHCL定義
resource “aws_kms_key” “master_key” {
description = “Production Master Key for Sensitive Data”
deletion_window_in_days = 30
enable_key_rotation = true # 必須：これを忘れるとコンプライアンスが死ぬ
rotation_period_in_days = 365 # 運用に合わせて調整
# ポリシーを別ファイル管理し、誤編集を防ぐ
policy = templatefile(“${path.module}/policies/kms_key_policy.json”, {
account_id = data.aws_caller_identity.current.account_id
})
tags = {
ManagedBy = “Terraform”
Purpose = “Security-Critical”
}
}
プロの教訓：
`deletion_window_in_days` は必ず最大値の30日に設定せよ。もし誰かが誤ってキーを削除しても、30日間は復旧の猶予がある。この「セーフティネット」がないKMS運用は、命綱なしで崖を登るようなものだ。
—
2. キーポリシーの「デプロイ失敗」を防ぐ魔法
KMSポリシーの更新で最も恐ろしいのは、「自分自身（Terraform実行ユーザー）の権限を消し飛ばしてしまい、二度とポリシーを更新できなくなる」ことだ。これを防ぐには「最小権限」と「管理者保護」を分離する。
推奨されるJSON構造（テンプレート）
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “Enable IAM User Permissions”,
“Effect”: “Allow”,
“Principal”: { “AWS”: “arn:aws:iam::${account_id}:root” },
“Action”: “kms:”,
“Resource”: “”
},
{
“Sid”: “Allow Use for App”,
“Effect”: “Allow”,
“Principal”: { “AWS”: “arn:aws:iam::${account_id}:role/app-role” },
“Action”: [“kms:Encrypt”, “kms:Decrypt”, “kms:GenerateDataKey”],
“Resource”: “”
}
]
}
鉄則： ポリシー変更時は、必ず `Sid` を変更せずに内容だけを更新せよ。また、AWSコンソールでポリシーを直接いじるのは厳禁だ。TerraformのStateと不整合が起きれば、リカバリには手動でのポリシー修正が必要となり、最悪の場合キーそのものの再作成（＝全データ復号不可）という悪夢が待っている。
—
3. テックリードが教える「生産性底上げ」の神テクニック
① VS Codeの神プラグイン
- HashiCorp Terraform: 言わずもがな。
- TFLint: Terraformのベストプラクティスを強制する。特に `aws_kms_key` の設定ミスをCI前に弾く。
- Error Lens: エラー箇所をエディタ上に即座に表示。デバッグ時間を30%削減する。
② 現場で役立つ「隠れたキーボードショートカット」
- `Ctrl + Shift + P` -> `Terraform: Format`：保存時に自動フォーマットを走らせる設定は必須だが、手動で整える癖もつけよ。
- Vimを使っているなら： `ci”` で引用符の中身を置換し、`vi{` でブロック全体を選択する。IaCコードの修正速度が段違いになる。
③ チームでの設定共有ルール
- `terraform.tfvars` の管理: 個人用変数と環境変数（staging/prod）を明確に分ける。`.auto.tfvars` を活用し、環境ごとの差異をコードで宣言的に管理する。
- Terragruntの導入: もしプロジェクトが中規模以上なら、迷わず Terragrunt を入れろ。DRY（Don’t Repeat Yourself）なコード設計が可能になり、KMSキーのような共通リソースの参照が圧倒的に楽になる。
—
4. もし「キーを削除してしまった」ら？（リカバリの知見）
万が一、キーを削除スケジュールに入れてしまった場合、リカバリは「削除処理のキャンセル」のみだ。
緊急時のリカバリコマンド
aws kms cancel-key-deletion –key-id
しかし、Terraform管理下では、Terraform側も `aws_kms_key` リソースを「破棄」とみなしてStateを更新してしまう。
1. 即座に `terraform apply` を止める。
2. `terraform state rm` で管理から外す（あるいは `import` で再紐付けを試みる）。
3. AWS CLIで削除をキャンセルする。
このリカバリ手順をドキュメント化し、チーム全員がいつでも叩けるようにしておくこと。それが、真のSREの仕事だ。
—
最後に：Terraformは単なる「設定ファイル」ではない
TerraformでKMSを管理するということは、データの命運をコードに委ねるということだ。
「動けばいい」コードを書くのはジュニアエンジニアだ。「5年後、自分が深夜3時に呼び出されても確実に復旧できる」コードを書くのが、プロのエンジニアである。
君たちのインフラが、堅牢で、自動化され、そして何より「恐れずに破壊できる」状態にあることを願っている。さあ、今すぐコードを磨け。