現場で戦うエンジニア諸君。セキュリティ・バイブルへようこそ。
今日は、AWSの「心臓部」であるIAM（Identity and Access Management）について語ろう。多くのエンジニアが「動けばいい」と軽視しがちなIAMポリシーのワイルドカードだが、これは戦場では「自爆スイッチ」に等しい。
「最小権限の原則」という言葉は教科書で飽きるほど聞いたはずだ。だが、実際にそれをコードベースでどう実装し、どうやって攻撃者の侵入経路を断つか。今日はその核心に触れる。
—
1. なぜ「ワイルドカード（*）」は悪夢の始まりなのか
IAMポリシーにおいて、Resource: "*" や Action: "s3:*" を書くのは、家の鍵をかけた上で玄関のドアを全開にしておくようなものだ。
特に危険なのは、iam:PassRole 権限とワイルドカードの組み合わせだ。攻撃者は、開発者が設定したガバガバなポリシーを見逃さない。一度EC2インスタンスの権限を奪取すれば、PassRole を悪用して自分の権限を昇格させ、最終的には組織全体のAWS環境を掌握（ルート権限奪取）する。これがインシデントの黄金ルートだ。
攻撃者視点の PoC（概念実証）
攻撃者が最初に探すのは、以下のような「権限の穴」だ。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*"
}
]
}この設定がある状態で、攻撃者はあらかじめ用意した「管理者権限を持つロール」を自身のEC2インスタンスに割り当てる。その結果、EC2内部から aws sts get-caller-identity を叩くと、本来持っているはずのない管理者権限でコマンドが実行できてしまう。
—
2. 脱・ワイルドカード：セキュアなIAMポリシーの実装
解決策は明確だ。「具体的であること」。
AWS Access Analyzerを活用して、過去90日間のアクセスログを分析し、実際に使用された権限のみに絞り込むのが定石だ。以下に、特定のS3バケットのみにアクセスを許可する「最小権限ポリシー」のテンプレートを示す。
推奨されるセキュアなIAMポリシー（Terraform形式）
# 悪例: Resource: "*" は厳禁。以下のようにスコープを限定する
resource "aws_iam_policy" "secure_s3_policy" {
name = "AppSpecificS3Access"
description = "特定のバケットへの限定的なアクセス許可"
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = [
"s3:GetObject",
"s3:PutObject"
]
# ワイルドカードを排除し、具体的なリソースARNを指定する
Resource = [
"arn:aws:s3:::my-production-app-data/*"
]
}
]
})
}—
3. IAM Access Analyzerを「武器」にする
現場の泥臭い運用で最も信頼できるのは、人間が書いたドキュメントではなく、機械が吐き出す「事実」だ。
AWS Access Analyzerを有効化すると、外部からアクセス可能なリソースや、未使用の権限を即座に特定してくれる。運用フローに以下のステップを組み込んでくれ。
1. IAM Access Analyzerの有効化: 全リージョンで有効化せよ。
2. アクセスアドバイザーの確認: IAMコンソールの「アクセスアドバイザー」タブで、「最終アクセス」が長い間更新されていないアクションを特定する。
3. ポリシーの縮小: 未使用のアクションを削除し、デプロイする。
—
4. エンジニアへのラスト・アドバイス
「最小権限の原則」を適用すると、最初は必ずエラーが出る。「あれも動かない、これも動かない」とチームから不満が出るだろう。だが、そこで妥協して Resource: "*" に戻してはいけない。
インシデントが起きた時、最後に責任を取るのは「動くコードを書いた自分」だ。
セキュリティとは、利便性と防御のせめぎ合いだ。しかし、IAMに関して言えば、まずは「拒否（Deny）」から入り、必要最小限の「許可（Allow）」を重ねていくホワイトリスト方式こそが、唯一の正解である。
コードを書くとき、設定ファイルをいじるとき、常に自問してほしい。
「このアクションは、本当にこのリソースに対して必要か？」
その問いが、君たちのシステムを、そして君たち自身を、大惨事から救うことになる。現場からは以上だ。次回の講義では、暗号鍵のローテーションとKMS管理の勘所について話そう。健闘を祈る。
コメント