攻撃者は「権限の過剰付与」を一番の好物にする：IAM最小特権化の生存戦略
現場のエンジニア諸君、お疲れ様。今日もクラウドのコンソール画面と格闘していることだろう。
多くのエンジニアは「動けば正義」という開発フェーズの魔力に負け、IAMポリシーに AdministratorAccess や s3:* といった「全能の鍵」を渡してしまう。君たちが書いたWebアプリにたった一行のSQLインジェクションや、依存ライブラリの脆弱性が入り込んだ瞬間、攻撃者はその「過剰な鍵」を使って裏口から本丸まで全てを掌握する。
今日は、AWSを例に「IAM Access Analyzer」を活用した泥臭い最小特権化のライフサイクルについて、現場でそのまま使える知見を共有しよう。
—
なぜ「全能の鍵」が即死フラグになるのか？
想像してほしい。君のアプリがWebサーバー上で動いていて、S3バケットへの画像アップロード機能があるとしよう。ここで開発者が「面倒だから」と s3:* を付与したとする。
もし、アプリのコードに Path Traversal（ディレクトリトラバーサル）の脆弱性があれば、攻撃者はこう動く。
1. GET /download?file=../../../../etc/passwd でサーバーの素性を探る。
2. 次に GET /download?file=config.php でクラウドのIAMクレデンシャル（環境変数など）を盗む。
3. 盗んだ権限で aws s3 ls を実行し、バケット内の顧客データや全バックアップを吸い出す。
たったこれだけで、君たちのサービスは「データ漏洩事故」の当事者になる。IAMの権限は、攻撃者にとっての「横展開（Lateral Movement）」のためのプラットフォームなんだ。
—
IAM Access Analyzer による自動監査の極意
IAM Access Analyzerは、単に「未使用の権限」を教えてくれるだけの親切なツールではない。これは、攻撃対象領域（Attack Surface）を削り落とすための「メス」だ。
1. 未使用権限の抽出を自動化する
手動でポリシーを直すのは時代遅れだ。AWS CLIを使って、直近90日間のアクセス履歴に基づき、使用されていないアクションを洗い出すスクリプトをCI/CDに組み込もう。
以下は、Pythonで未使用アクションを特定するための実用的なスクリプトの断片だ。
import boto3
def get_unused_actions(role_name):
client = boto3.client('accessanalyzer')
# IAM Access Analyzerのポリシー生成機能を利用して、
# 過去のアクティビティに基づく「必要最小限」のポリシーを生成させる
response = client.generate_policy(
policyDetails={
'iamRoleArn': f'arn:aws:iam::123456789012:role/{role_name}'
}
)
# ここで生成されたポリシーを現在のアタッチ済みポリシーと比較し、
# 乖離（＝不要な権限）をCI上で警告するロジックを組むのが「プロ」の流儀だ
return response['generatedPolicyResult']['generatedPolicies']
# 運用上の注意:
# 90日間のログがない環境では精度が落ちるため、開発環境で最低1ヶ月は
# 負荷試験を行ってからこのスクリプトを適用すること。—
最小特権を維持するための「インフラ・コード」設計
ポリシーを修正する際は、Managed Policy をそのまま使うのではなく、Customer Managed Policy を定義し、Terraform や CloudFormation で厳格に管理する。
以下は、S3バケットに対して「特定のパスへの書き込みのみ」を許可する、堅牢なポリシー定義のサンプルだ。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificS3Upload",
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::my-secure-bucket/uploads/*"
]
},
{
"Sid": "DenyAllOtherAccess",
"Effect": "Deny",
"NotAction": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-secure-bucket/*"
}
]
}*ポイント: Deny ステートメントを明示的に加えることで、将来誰かが誤って s3:* を追加しようとしても、IAMの評価ロジックがそれを拒絶するようにしておく。これが多層防御だ。*
—
現場のエンジニアへ送る「守りの鉄則」
最後に、一つだけ覚えておいてほしい。セキュリティは「一度設定したら終わり」ではない。
- 「とりあえず開発中はフル権限」を禁止せよ： 開発環境と本番環境でIAMロールを分けるのは基本中の基本。開発環境ですら、必要最低限の権限以外は与えるな。
- IAM Access Analyzer の結果をアラート化せよ： 未使用アクションの検知をSlackに流す設定を今日中にやれ。
- コードレビューのチェックリストに「権限」を入れろ： プルリクを見る際、新しく追加されたライブラリがIAM権限を必要としていないか、常に疑う姿勢が君たちを救う。
インシデントは派手な攻撃から始まるのではない。君たちが何気なく書いた * （ワイルドカード）一つから始まる。その責任の重さを自覚し、泥臭く、しかし理知的にシステムを守り抜いてくれ。
何か不明点があれば、またいつでも聞きに来てほしい。現場の最前線で戦う君たちを、私はいつでも応援している。
コメント