こんにちは。インフラの現場で「自動化」という名の聖域を守り続けているエンジニアです。
今日は、多くのエンジニアが「怖いから」という理由で後回しにしがちなAWS KMS（Key Management Service）のライフサイクル管理についてお話しします。
KMSキーはインフラの心臓部です。ここをTerraformで「正しく」制御できるようになると、あなたは手動オペレーションという泥沼から一生抜け出せます。今日は、単なる設定方法ではなく、事故を防ぐための「設計思想」を伝授しましょう。
—
1. KMSをコードで管理する真の理由
なぜKMSをわざわざTerraformで書くのか？ それは「暗号化キーを紛失・破壊するリスクを排除するため」です。
コンソールからポチポチ設定したキーは、誰がいつ変更したか、どんなポリシーが適用されているのかブラックボックスになりがちです。IaC（Infrastructure as Code）化することで、キーの権限管理をGitで履歴管理し、誰が暗号化・復号できるのかをコードとして明示化できます。これがSREとしての第一歩です。
2. 環境構築：まずは「守り」の土台を作る
TerraformがAWSを操作できるように、最小権限のIAMユーザーを用意しましょう。
- Install: [Terraform公式サイト](https://www.terraform.io/)からバイナリをダウンロードし、パスを通すだけです。
- Setup: `.tf`ファイルを用意し、`provider`を定義します。
provider “aws” {
region = “ap-northeast-1”
}
動作確認用のHelloWorld的KMSキー
resource “aws_kms_key” “my_first_key” {
description = “My Production Key”
enable_key_rotation = true # これが自動ローテーションの要
rotation_period_in_days = 365 # 1年ごとの更新
tags = {
Environment = “Production”
}
}
これで `terraform apply` を実行してみてください。AWS上に暗号化キーが生成されます。これが「精度高いHelloWorld」です。
—
3. 【深淵】デプロイ失敗を防ぐための「キーポリシー」の設計術
KMSで最も恐ろしいのは、「ポリシーを変更してしまい、自分自身がキーを使えなくなる（締め出される）」という事態です。これを防ぐには、Terraformの記述に「逃げ道」を作ることが鉄則です。
良い設計例：管理者権限を分離する
キーポリシーの中に、必ず「キーの管理を許可するロール（Administrator）」と「データを利用するロール（App）」を明確に分けましょう。
data “aws_iam_policy_document” “kms_policy” {
# 1. ルートユーザーには管理権限を（保険）
statement {
sid = “EnableRootAccess”
effect = “Allow”
principals {
type = “AWS”
identifiers = [“arn:aws:iam::123456789012:root”]
}
actions = [“kms:”]
resources = [“”]
}
# 2. アプリケーションサーバーからの利用を許可
statement {
sid = “AllowAppUsage”
effect = “Allow”
principals {
type = “AWS”
identifiers = [“arn:aws:iam::123456789012:role/app-role”]
}
actions = [
“kms:Encrypt”,
“kms:Decrypt”,
“kms:GenerateDataKey”
]
resources = [“”]
}
}
resource “aws_kms_key” “main” {
policy = data.aws_iam_policy_document.kms_policy.json
}
ポイント： `resource` に直接ポリシーをベタ書きせず、`data` 文で外出ししましょう。これにより、ポリシー変更時に `terraform plan` で破壊的な変更がないか事前にチェックできます。
—
4. 万が一の削除リカバリ：deletion_windowの魔法
AWS KMSは削除時に「7日〜30日の待機期間」を設ける必要があります。Terraformではこれを `deletion_window_in_days` で指定します。
resource “aws_kms_key” “critical_key” {
# 削除までの猶予を最大30日に設定（誤操作防止の安全装置）
deletion_window_in_days = 30
enable_key_rotation = true
}
もし誤って `terraform destroy` を実行しても、この30日間はキーが「削除保留中」になるだけで、AWSコンソールやCLIから「キャンセル」可能です。「失敗を前提とした設計」こそが、一流のエンジニアの流儀です。
—
最後に：あなたへのアドバイス
KMSの管理は、一度マスターしてしまえば、インフラ全体の「信頼の基盤」になります。
1. 自動ローテーションは常にONにする（セキュリティの基本）。
2. ポリシーは権限最小化の原則に従う（過剰な権限は事故の元）。
3. 削除待機期間を必ず設ける（心に余裕を持つため）。
これを完璧に行えば、あなたが寝ている間にKMSキーが勝手に更新され、安全に運用され続けます。インフラを自動化し、自分自身の時間を創り出しましょう。
何か詰まったら、いつでもコードを見返してください。Terraformは、あなたの最も誠実な相棒になってくれるはずです。応援しています！