IAM 顧客管理ポリシーでのサービスのワイルドカードアクションの許可について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。
今回は、IAMのカスタム管理ポリシーが、特定のサービスでワイルドカードアクション(Service:*
)を許可している状態について、そのリスクと対策を解説します。

ポリシーの説明
Security Hub コントロール AWS Identity and Access Management – AWS Security Hub
[IAM.1] IAM ポリシーでは、完全な「*」管理者権限を許可しないでください
このコントロールは、IAM ポリシー (カスタマー管理ポリシーとも呼ばれます) のデフォルトバージョンに、
"Action": "*"
が"Resource": "*"
に対して規定された"Effect": "Allow"
ステートメントを持つ管理者アクセス権があるかどうかをチェックします。このようなステートメントを含む IAM ポリシーがある場合、コントロールは失敗します。
リスク
AWS Identity and Access Management(IAM)は、AWSリソースへのアクセスを安全に管理するためのサービスです。IAMポリシーは、誰がどのリソースに対してどのような操作を実行できるかを定義します。最小特権の原則に従い、ユーザー、グループ、またはロールに付与する権限は、そのタスクを遂行するために必要な最小限のものに限定すべきです。
IAMカスタム管理ポリシーで、"Action": "s3:*"
のように特定のサービスの全アクションを許可するワイルドカードを使用している場合、以下のような重大なセキュリティリスクが発生します。
- 特権昇格のリスク:
s3:*
のようなワイルドカードは、s3:GetObject
といった必要な権限だけでなく、s3:DeleteBucket
のような破壊的な操作や機密性の高い操作もすべて許可してしまいます。もしこのポリシーが、本来はオブジェクトの読み取りしか必要としないIAMプリンシパル(ユーザーやロール)にアタッチされている場合、意図せずして過大な権限を与えてしまい、特権昇格につながる可能性があります。 - 意図しないデータ漏洩: ワイルドカードを使用すると、将来的にそのサービスに追加される新しいアクションも自動的に許可されます。もしその新しいアクションが機密データを公開する機能であった場合、ポリシーを更新しなくても意図しないデータ漏洩の脆弱性が生じる可能性があります。
- 誤操作による被害の拡大: ユーザーが誤って、本来許可されるべきではない破壊的なアクションを実行してしまう可能性があります。例えば、
s3:*
を許可されたユーザーが、誤って重要なS3バケットを削除してしまうと、取り返しのつかないデータ損失につながります。 - 監査と追跡の困難さ:
s3:*
のような包括的なアクションを許可していると、AWS CloudTrailのログを分析する際に、どの具体的なアクションが実行されたかを正確に把握するのが難しくなります。これにより、セキュリティインシデント発生時の原因究明や監査証跡の追跡が困難になります。
対策
IAMカスタム管理ポリシーでワイルドカードアクションを避けることは、最小特権の原則を遵守し、IAMのセキュリティ体制を強化するための重要なベストプラクティスです。
- 最小特権の原則を徹底: ポリシーで許可するアクションは、業務遂行に真に必要なものだけを明示的にリストアップします。
- 例: S3バケットからのオブジェクト読み取りのみが必要な場合、
"Action": "s3:GetObject"
だけを許可します。
- 例: S3バケットからのオブジェクト読み取りのみが必要な場合、
- プレフィックスワイルドカードの活用: アクション名のプレフィックス(接頭辞)が同じで、特定の機能群に絞り込める場合は、
ec2:Describe*
のようなプレフィックス付きのワイルドカードを使用することを検討します。これにより、不要なアクションを許可することなく、簡潔なポリシーを維持できます。ec2:Describe*
は、ec2:DescribeInstances
、ec2:DescribeVolumes
などの読み取り専用アクションのみを許可し、ec2:RunInstances
のような書き込みアクションは許可しません。これはセキュリティと利便性のバランスを取る良い方法です。
- AWS管理ポリシーからのコピーは注意: AWS管理ポリシーは、広範なユースケースをカバーするために、多くのワイルドカードアクションを含んでいることがあります。これらのポリシーをそのままコピーしてカスタマイズする際には、不要なワイルドカードを削除し、必要なアクションのみに絞り込むことが重要です。
- IAM Access Analyzerの利用: IAM Access Analyzerは、外部からアクセス可能なリソースや、未使用のアクセス権限を特定するのに役立ちます。これを活用して、過剰な権限を持つポリシーを定期的にレビューし、改善します。
- IAMポリシーシミュレータの活用: IAMポリシーを作成または変更する際には、ポリシーシミュレータを使用して、そのポリシーが意図した通りの権限のみを付与しているかテストします。
修復方法
IAMカスタム管理ポリシーでワイルドカードアクションを修正する方法は、AWSコンソールまたはTerraformで行えます。ここでは、"Action": "s3:*"
を"Action": ["s3:GetObject", "s3:ListBucket"]
に修正する例を挙げます。
AWSコンソールでの修復手順
AWSコンソールを使用して、IAMカスタム管理ポリシーを編集し、ワイルドカードアクションを必要なアクションに置き換えます。
- IAMサービスへ移動: AWSコンソールにログインし、IAM サービスを開きます。
- ポリシーを選択: 左側のナビゲーションペインで「ポリシー」を選択します。 検索バーで、修正したいカスタム管理ポリシーを検索し、選択します。
- ポリシーの編集:
- ポリシーの詳細ページで、「ポリシーの編集」をクリックします。
- 「ビジュアルエディタ」または「JSON」タブを選択します。JSONタブの方がより詳細な制御が可能です。
- JSON形式でポリシーを編集:
- 以下のJSONポリシーを例とします。JSON
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::my-secure-bucket" } ] }
- このポリシーを、必要なアクションのみを許可するように修正します。例えば、オブジェクトの読み取りとリストアップのみが必要な場合は、
"Action": "s3:*"
を以下のように変更します。JSON{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::my-secure-bucket", "arn:aws:s3:::my-secure-bucket/*" ] } ] }
- 注意: リソースARNは、アクションに応じて複数指定する必要があります(例:
ListBucket
はバケット自体に、GetObject
はバケット内のオブジェクトに適用される)。
- 注意: リソースARNは、アクションに応じて複数指定する必要があります(例:
- 以下のJSONポリシーを例とします。JSON
- 変更のレビューと保存:
- 編集したJSONを確認し、「次へ」をクリックします。
- 変更内容に問題がなければ、「変更の保存」をクリックします。
これで、IAMポリシーは最小限の権限に制限され、セキュリティが向上します。
Terraformでの修復手順
TerraformでIAMカスタム管理ポリシーのワイルドカードアクションを修正するには、aws_iam_policy
リソースの policy
パラメータで指定するJSONドキュメントを更新します。
# (既存の過剰な権限を持つポリシーの例)
resource "aws_iam_policy" "overly_permissive_policy" {
name = "overly-permissive-policy"
description = "An IAM policy with a wide range of permissions"
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = "s3:*" # 過剰なワイルドカードアクション
Resource = "arn:aws:s3:::my-secure-bucket"
}
]
})
}
# --- 修正後のポリシーの例 ---
# IAM ポリシー
resource "aws_iam_policy" "my_secure_policy" {
name = "my-secure-policy"
description = "A secure IAM policy with least privilege permissions"
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
# **重要: 必要なアクションのみを明示的に指定**
Action = [
"s3:GetObject",
"s3:ListBucket"
]
Resource = [
aws_s3_bucket.my_secure_bucket.arn,
"${aws_s3_bucket.my_secure_bucket.arn}/*"
]
},
{
Effect = "Allow"
Action = "s3:GetBucketLocation"
Resource = aws_s3_bucket.my_secure_bucket.arn
}
]
})
}
# 関連するS3バケットのリソース
resource "aws_s3_bucket" "my_secure_bucket" {
bucket = "my-secure-bucket-2025-unique" # グローバルに一意な名前
tags = {
Name = "MySecureBucket"
}
}
# IAMロールに修正後のポリシーをアタッチ
resource "aws_iam_role_policy_attachment" "my_secure_attachment" {
role = aws_iam_role.my_app_role.name
policy_arn = aws_iam_policy.my_secure_policy.arn
}
# 関連するIAMロール
resource "aws_iam_role" "my_app_role" {
name = "my-app-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Principal = {
Service = "ec2.amazonaws.com"
}
Action = "sts:AssumeRole"
}
]
})
}
上記のTerraformコードでは、aws_iam_policy
リソースで policy
パラメータ内のJSONドキュメントを更新し、"Action": "s3:*"
のようなワイルドカードを、"Action": ["s3:GetObject", "s3:ListBucket"]
のような具体的なアクションのリストに置き換えています。
Action = ["s3:GetObject", "s3:ListBucket"]
: 最小限の権限を付与するための修正例です。必要なアクションをすべてリストアップします。Resource
: 権限のスコープを絞り込むため、ワイルドカードを使用せず、具体的なリソースARNを指定します。
この変更を適用することで、Terraformは既存のポリシーを更新(または新しいポリシーを作成して既存のポリシーを削除)し、よりセキュアなポリシーに置き換えます。
最後に
この記事では、IAMカスタム管理ポリシーでサービスのワイルドカードアクションを許可することのリスクと、それを修正するための方法について解説しました。最小特権の原則に従ってポリシーを記述することは、AWS環境全体のセキュリティを向上させる上で最も基本的ながらも重要なステップです。 貴社のIAMポリシーは、最小限の権限のみを付与するように適切に設定されていますか?この機会にぜひ設定を確認・強化してみてください。 こちらの内容の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。運用が非常にラクに出来る製品になっていますのでぜひ興味がある方はお問い合わせお待ちしております。
最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。