IAMインラインポリシーにおけるKMSキーで復号化と再暗号化アクションの使用について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。
今回は、IAMプリンシパル(ユーザー、グループ、ロール)が、KMSキーで復号化・再暗号化アクションを許可するIAMインラインポリシーを使用している状態について、そのリスクと対策を解説します。

リスク
AWS Key Management Service (KMS) は、暗号化キーを簡単に作成および管理するためのサービスです。IAMポリシーは、誰がどのアクションを実行できるかを定義する一方で、KMSキーポリシーは、誰がどのキーにアクセスできるかを定義します。セキュリティのベストプラクティスは、最小特権の原則に従うことであり、これは「IAMポリシーとKMSキーポリシーの両方で権限を制限する」という形で実装されます。
IAMプリンシパルが、KMSキーで復号化(kms:Decrypt
)や再暗号化(kms:ReEncrypt*
)を許可するインラインポリシーを使用している場合、以下のような重大なリスクが発生します。
- 過剰な権限の付与: IAMインラインポリシーは、特定のIAMプリンシパルに直接アタッチされます。このポリシーでKMSキーへのアクセスを広範に許可してしまうと、そのプリンシパルは、本来アクセスすべきでない機密データまで復号化できるようになる可能性があります。これにより、データ漏洩のリスクが高まります。
- 権限管理の複雑化: IAMポリシーとKMSキーポリシーの両方で権限を管理するのが最も安全な方法ですが、インラインポリシーで直接KMSアクションを許可すると、権限の管理が分散し、複雑になります。どのプリンシパルがどのキーにアクセスできるのかを追跡するのが難しくなり、セキュリティ監査が困難になります。
- 意図しないキーの使用: IAMインラインポリシーは、特定のKMSキーに限定されていない場合、ユーザーがデータに適さないキー(例えば、テスト環境のデータ用キーで本番環境のデータを復号化するなど)を意図せず使用してしまう可能性があります。これは、セキュリティの脆弱性や運用のミスにつながります。
- 特権昇格のリスク: インラインポリシーは、特定のユーザーやロールに固有の権限を付与するため、ポリシーの内容が見過ごされがちです。もし、このポリシーが、他のユーザーが引き受けることのできるロールにアタッチされている場合、そのロールを引き受けることで、不必要にKMSの復号化権限を獲得してしまうことになり、特権昇格につながるリスクがあります。
対策
IAMプリンシパルには、IAM管理ポリシーとKMSキーポリシーを組み合わせて権限を付与することが、上記のすべてのリスクを軽減し、セキュリティを強化するための重要なベストプラクティスです。
- IAM管理ポリシーとKMSキーポリシーの分離:
- IAMポリシーでは、特定のKMSキーをリソースARNとして指定し、必要なアクション(
kms:Encrypt
,kms:Decrypt
など)を許可します。 このポリシーは、複数のIAMプリンシパルで再利用可能な管理ポリシーとして作成します。 - KMSキーポリシーでは、特定のIAMプリンシパルに対して、そのキーへのアクセスを許可します。 これにより、「誰が、どのキーに対して」という二重のチェック体制が構築されます。
- IAMポリシーでは、特定のKMSキーをリソースARNとして指定し、必要なアクション(
- 最小特権の原則の徹底: IAM管理ポリシーで許可するアクションは、特定のKMSキーに限定し、必要なアクションのみを明示的に指定します。例えば、暗号化のみが必要な場合は
kms:Encrypt
のみを許可し、kms:Decrypt
は許可しません。 - インラインポリシーの回避: IAMインラインポリシーは、特定のプリンシパルにしか使われないため、追跡が困難です。可能な限りIAM管理ポリシーを使用し、管理を一元化することを推奨します。
- IAM Access Analyzerの活用: IAM Access Analyzerを使用して、KMSキーへの意図しないアクセス許可がないかを定期的にレビューします。
修復方法
AWSコンソールでの修復手順
AWSコンソールを使用して、IAMインラインポリシーを削除し、KMSキーポリシーを編集します。
ステップ 1: IAMインラインポリシーの削除
- IAMサービスへ移動: AWSコンソールにログインし、IAM サービスを開きます。
- プリンシパル(ユーザー、グループ、またはロール)を選択: 左側のナビゲーションペインで「ユーザー」や「ロール」を選択し、設定を変更したいプリンシパルを選択します。
- インラインポリシーを特定し、削除:
- プリンシパルの詳細ページで、「アクセス権限」タブに移動します。
- 「インラインポリシー」セクションを確認し、KMSへの広範な権限を許可しているポリシー(
kms:Decrypt
やkms:ReEncrypt
を含む)を特定します。 - そのポリシーを選択し、「ポリシーの削除」をクリックします。
ステップ 2: KMSキーポリシーの編集
- KMSサービスへ移動: AWSコンソールでKMS サービスを開きます。
- キーを選択: 左側のナビゲーションペインで「カスタマー管理キー」を選択し、該当するKMSキーを選択します。
- キーポリシーの編集:
- キーの詳細ページで、「キーポリシー」タブに移動します。
- 「編集」をクリックして、ポリシーを編集します。
- プリンシパルへの権限付与:
- JSON形式でポリシーが表示されます。ここに、対象のIAMプリンシパルが
kms:Decrypt
アクションを実行できるようにするステートメントを追加します。以下の例のように、Principal
にプリンシパルのARNを、Action
に必要なKMSアクションを指定します。
- JSON形式でポリシーが表示されます。ここに、対象のIAMプリンシパルが
{
"Sid": "Allow user to decrypt data",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/MySecureUser"
},
"Action": [
"kms:Decrypt",
"kms:ReEncryptFrom"
],
"Resource": "*"
}

- 変更内容を確認し、「変更の保存」をクリックします。
これで、権限の管理がKMSキーポリシーに一元化され、セキュリティが向上します。
Terraformでの修復手順
TerraformでIAMインラインポリシーを削除し、KMSキーポリシーで権限を管理するように修正します。
ステップ 1: IAMインラインポリシーの削除
# (既存の過剰な権限を持つIAMインラインポリシーの例)
# このリソース定義をHCLファイルから削除することで、ポリシーが削除されます
resource "aws_iam_user_policy" "overly_permissive_policy" {
name = "kms-inline-policy"
user = aws_iam_user.my_user.name
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow",
Action = "kms:*", # 過剰なワイルドカードアクション
Resource = "*"
}
]
})
}
上記のTerraformコードでは、aws_kms_key
リソースのpolicy
パラメータで、Principal
にaws_iam_role.my_app_role
のARNを指定し、Action
にkms:Decrypt
とkms:ReEncryptFrom
アクションを許可しています。
terraform apply
を実行すると、KMSキーポリシーが更新され、指定されたIAMロールのみが復号化権限を持つようになります。
最後に
この記事では、IAMインラインポリシーでKMSキーへの復号化・再暗号化アクションを許可することのリスクと、それをKMSキーポリシーで管理することの重要性について解説しました。権限の管理をKMSキーポリシーに一元化することで、最小特権の原則を徹底し、より安全で追跡しやすいセキュリティ体制を構築できます。
貴社のIAMプリンシパルは、KMSキーへのアクセスをインラインポリシーで許可していませんか?この機会にぜひ設定を確認・強化してみてください。
こちらの内容の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。運用が非常にラクに出来る製品になっていますのでぜひ興味がある方はお問い合わせお待ちしております。
最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。