Vault × AWS KMS Auto Unseal: IAM設計と運用の実務

AWS KMS Auto Unsealは、Vaultの起動時にKMSへ復号リクエストを出して自動でアンシールする仕組み。手動アンシールの運用負荷を大きく下げられます。

本稿は、IAMロール・KMSキー・起動パスの設計から、監査・DR・ローテーションまでを実務目線で解説します。バージョン差異が出やすい箇所は注意点として記載します。

AWS KMS Auto Unsealの仕組みと前提

Vaultはストレージ暗号化のために内部マスターキーを持ちます。Auto Unseal構成では、このマスターキーをAWS KMSで包み（暗号化）保管し、起動時にKMSの復号APIを用いて自動アンシールします。これにより、Shamir方式の手動アンシールを省略できます。

前提として、対称暗号のKMSキー（カスタマーマネージドキー）、そのキーに対する最小権限のIAMロール、VaultサーバからKMSエンドポイントへの到達性が必要です。権限は一般にkms:Decrypt/kms:Encryptが中核で、環境やバージョンによりkms:DescribeKeyやkms:GenerateDataKey系が参照されることがあります。

• Vaultのawskmsシールは、KMSの復号に失敗すると起動フェーズで止まる
• KMSキーは無効化・削除保留状態だとアンシール不能
• 暗号化コンテキスト（kms_context）を使うと鍵の誤用リスクを抑えられる
• Auto Unsealでも初回Root Tokenの取り扱いと監査は依然重要

Auto Unsealの高レベルフロー

Vaultサーバ設定例（awskmsシール）

seal "awskms" {
  region      = "ap-northeast-1"
  kms_key_id  = "arn:aws:kms:ap-northeast-1:111122223333:key/abcd-ef01-2345-6789-abcdef012345"
  # 必要に応じてロール引受け
  role_arn    = "arn:aws:iam::111122223333:role/vault-unseal"
  # 誤用防止のための暗号化コンテキスト（推奨）
  kms_context = "App=vault-prod"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}

storage "raft" {
  path = "/opt/vault/data"
  node_id = "vault-1"
}

IAMロールとKMSキーの設計（最小権限とマルチアカウント）

基本は、Vault実行環境（EC2/VM/コンテナ）にアタッチするIAMロールを用意し、対象KMSキーに対する最小権限を付与します。単一アカウントならIAMポリシー側の許可だけで成立しますが、キー側のキーポリシーにPrincipalsを明示する運用も安定的です。

クロスアカウントでは、VaultアカウントのロールがKMSアカウントのロールをAssumeRoleするか、KMSキーポリシーでVaultアカウントのロールをPrincipalに許可します。どちらにせよ、kms:Decrypt/kms:Encryptが鍵、DescribeKeyは健全性確認に有用です。暗号化コンテキスト（kms_context）を併用し、キー誤用を条件で防ぎます。

• 最小権限の中心: kms:Decrypt, kms:Encrypt（必要に応じてkms:DescribeKey, kms:GenerateDataKey系）
• キーポリシー側にPrincipalを明記すると、アカウント境界を超える運用で意図が明確になる
• 暗号化コンテキストをIAM条件に使い、誤用や過剰権限を抑止
• クロスアカウントはAssumeRoleかKey PolicyのPrincipal指定で整理

最小権限に寄せたIAMポリシー例（暗号化コンテキスト併用）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VaultKmsCore",
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:ap-northeast-1:111122223333:key/abcd-ef01-2345-6789-abcdef012345",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:App": "vault-prod"
        }
      }
    }
  ]
}

認証情報の供給と起動パスの安定化

Vaultのawskmsシールは、AWS SDKの標準クレデンシャル探索順序を利用します。一般的には、EC2インスタンスプロファイルやEKSのIRSAからのロール認証、もしくは環境変数（AWS_ACCESS_KEY_ID等）を参照します。

起動順制御は実務で重要です。ネットワークスタックとメタデータサービス（IMDS/STS）へ到達できる前にVaultが起動すると、KMS復号に失敗します。systemdの依存関係設定、リトライ（Restart=on-failure）、バックオフなどで安定化します。

• 優先: ローテーション容易なロール認証（インスタンスプロファイル/IRSA）
• 環境変数はテストや一時用途に限定し、永続化は避ける
• 起動時にKMSリージョンやVPCエンドポイントの疎通を事前チェック
• Cloud-Initやユーザーデータでの一回限り設定は監視と組で運用

systemdユニット例（依存と環境の供給）

[Unit]
Description=HashiCorp Vault Server
After=network-online.target
Wants=network-online.target

[Service]
User=vault
Group=vault
EnvironmentFile=-/etc/vault.d/aws.env
ExecStart=/usr/local/bin/vault server -config=/etc/vault.d/vault.hcl
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

運用: 可用性・DR・ローテーションの勘所

マルチAZは前提として、DRやリージョン障害に備えるならKMSのマルチリージョンキーを検討します。複製キーは同一キーID系統で復号互換を維持しやすく、Vaultクラスタが別リージョンで起動しても同一論理キーでアンシール可能に設計できます。

KMSの自動ローテーション（対称キー）は過去の暗号文の復号互換を保つ設計なので、通常はVault側の再設定は不要です。逆に、キーを無効化・削除保留にするとアンシール不可になるため、変更管理とメンテナンスウィンドウの定義が必須です。

• マルチリージョンキーでDR設計を簡素化
• ローテーションは互換性維持の前提で安全だが、変更管理は厳格に
• VPCエンドポイントでプライベートにKMSへ到達する設計も有効
• CloudTrailとメトリクスでkms:Decryptの動向を監視

運用で使う代表的CLI（例）

# ローテーション有効化（対称キー）
aws kms enable-key-rotation --key-id arn:aws:kms:ap-northeast-1:111122223333:key/abcd-ef01-2345-6789-abcdef012345

# マルチリージョンキーのレプリカ作成（例）
aws kms replicate-key \
  --key-id arn:aws:kms:ap-northeast-1:111122223333:key/abcd-ef01-2345-6789-abcdef012345 \
  --replica-region us-west-2

セキュリティ強化と監査（暗号化コンテキスト/CloudTrail）

暗号化コンテキスト（kms_context）を設定し、IAMやキーポリシーの条件で一致を必須化することで、同一キーを用いた他用途の誤用を抑止できます。Vault側とポリシー側の文字列一致が鍵です。

監査はCloudTrailでkms:Decrypt/kms:Encryptを可視化し、異常頻度や拒否イベントを検出します。Vaultの監査ログと突き合わせると時系列の整合が取りやすく、根因分析に有効です。

• kms_contextは運用環境名などの固定値で管理（例: App=vault-prod）
• CloudTrailのInsightsやアラートでDecrypt失敗を即時検知
• キーポリシーはPrincipalの最小化と条件付き許可を徹底
• テスト用キーと本番キーを厳密に分離（タグとポリシーで管理）

KMSキーポリシー例（暗号化コンテキスト必須）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowVaultRoleWithContext",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:role/vault-unseal"},
      "Action": ["kms:Decrypt", "kms:Encrypt", "kms:DescribeKey"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:App": "vault-prod"
        }
      }
    }
  ]
}

他方式との比較と移行時の注意

Auto Unsealは起動自動化と監査容易性で優れますが、KMS到達性と権限に依存します。Shamir手動アンシールは外部依存が少ない反面、運用負荷が高い。Transit Auto-Unseal（Vault Transit）を使うとKMS非依存の自動化も可能ですが、Transit中枢の可用性が新たな前提になります。

既存クラスタからの移行は、事前にテスト環境で同一構成を再現し、KMS権限・疎通・コンテキスト条件を検証してから段階的に適用します。バージョン差異で許可APIが追加される場合があるため、許可アクションは監査ログを見ながら最小化・調整してください。

• 本番移行は計画停止で一台ずつ切替→クラスタ安定性確認が安全
• 必ずロールバック手順（旧設定復元・手動アンシール手段）を準備
• クロスリージョン/クロスアカウントは事前にCloudTrailでDecrypt成功を確認

移行前の疎通・権限テスト例（暗号/復号）

# 1) テスト用の暗号化・復号（コンテキスト一致）
aws kms encrypt \
  --key-id arn:aws:kms:ap-northeast-1:111122223333:key/abcd-ef01-2345-6789-abcdef012345 \
  --plaintext "test" \
  --encryption-context App=vault-prod \
  --query CiphertextBlob --output text > /tmp/ctxt.b64

aws kms decrypt \
  --ciphertext-blob fileb:///tmp/ctxt.b64 \
  --encryption-context App=vault-prod \
  --query Plaintext --output text | base64 -d

# 2) Vaultの状態確認（起動後）
vault status

問題で確認

よくある質問