IAMの「信頼ポリシー」こそが現代の城門である：Condition句で防ぐ権限昇格とクロスアカウントの罠
多くのエンジニアが「IAMポリシーは最小権限の原則に従え」と教わる。しかし、現場の最前線でインシデント対応を繰り返していると、この「最小権限」という言葉が、いかに甘美で、かつ無防備な言葉であるかを痛感する。
権限を付与するだけでは不十分だ。その権限が「どの文脈（Context）で」行使されるのか。物理メモリ上の暗号鍵が漏洩せずとも、認証されたセッションが乗っ取られれば、攻撃者は「正当なユーザー」として振る舞う。本稿では、IAMにおける Condition 句の深淵と、それがクロスアカウント環境でいかに防波堤となるかを、実務の視点から掘り下げる。
—
1. 認証の文脈を固定せよ：Condition句の真価
IAMのポリシーにおいて、Action や Resource を絞り込むのは基本中の基本だ。だが、プロの防衛者はその一歩先、Condition による「実行環境の縛り」に注力する。
特に、攻撃者が狙うのは「盗まれたセッション」だ。セッションが漏洩しても、それが「特定のネットワーク境界内」や「MFAで保護された通信」でなければ無効化されるべきだ。
実践的な「MFA強制」と「IP制限」の組み合わせ
以下のポリシーは、たとえ認証情報が漏洩しても、攻撃者の環境からのアクセスを物理的に遮断するための記述例だ。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictAccessByContext",
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24" // 自社のVPNゲートウェイ等のIPに限定
},
"Bool": {
"aws:MultiFactorAuthPresent": "true" // MFA認証が完了しているセッションのみ許可
}
}
}
]
}ここで重要なのは、aws:SourceIp が「プロキシを経由した先のIP」ではなく、通信経路のどこで終端されているかを正確に把握することだ。TLS終端やリバースプロキシを挟む場合、X-Forwarded-For の偽装リスクを考慮したアーキテクチャ設計が必要になる。
—
2. クロスアカウントアクセスの「Confused Deputy（混乱した代理人）」問題
クロスアカウントの信頼関係を構築する際、最も多いミスが ExternalID を省略することだ。これは、SaaSプロバイダー等へ権限を委譲する際、攻撃者が「自分のアカウントID」を使って被害者アカウントへのアクセス権を奪い取る、いわゆる「Confused Deputy問題」を引き起こす。
セキュリティアーキテクトが課すべき「Condition」
他アカウントのロールを引き受ける信頼ポリシー（Trust Policy）には、必ず sts:ExternalId を含めるべきだ。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "SecretUniqueStringForThisPartner" // 双方で共有する秘密鍵的な文字列
}
}
}
]
}この ExternalId は、パケット構造上の「合言葉」のようなものだ。これがないと、攻撃者は自身の持つIAMリソースを悪用し、貴社の環境に対して「なりすまし」の AssumeRole リクエストを執拗に送りつけることが可能になってしまう。
—
3. 次世代の防衛へ：耐量子暗号とガードレイルの設計
今後、我々が直面する最大の脅威は、RSAやECCを無効化する量子コンピュータの台頭ではない。それ以前に、生成AIによる「プロンプトインジェクション」を介した、認証情報（IAMのセッション情報）の動的抽出だ。
生成AIに対するガードレイルの考え方
LLMを業務システムに統合する場合、そのLLMが実行するIAMロールは「データ読み取りのみ」に限定し、Condition 句で「LLMのモデルID」を制限するようなアプローチが求められる。
"Condition": {
"StringLike": {
"iam:AWSServiceName": "bedrock.amazonaws.com",
"aws:PrincipalTag/Project": "SecureAI-Engine" // 特定のワークロードからのみアクセス可能にする
}
}暗号技術がどれほど強固であっても、その鍵を扱うアプリケーション自体が「プロンプト」によって汚染されていれば、城門の鍵は内側から開けられる。パケットを解析し、TLS 1.3のハンドシェイクを監視するだけでは不十分だ。アプリケーション層のガードレイル、そしてIAMポリシーによる「振る舞いの強制」こそが、これからのゼロトラストにおける要諦となる。
—
結びとして
セキュリティとは、魔法の杖を探すことではない。Condition 句のような地味な設定を積み重ね、攻撃者が「コストに見合わない」と判断するまで、多層的な障壁を築き続ける執念のことだ。
皆さんの設計するシステムが、今日からより強固な要塞へと進化することを願っている。もし、現在のポリシーに Condition が書かれていないなら、それは今すぐにでも見直すべき「脆弱性の種」だ。
コメント