クラウドの「信頼」をハックする：クロスアカウント攻撃の深淵とアーキテクチャの陥穽
多くのクラウドアーキテクトは、「IAMロールの信頼関係」を単なるアクセス制御のリストだと誤解している。だが、レッドチームの視点から見れば、それは「攻撃者がピボット（足場）を確保するための、最も効率的な高速道路」に他ならない。
今回は、AWSのクロスアカウントアクセス、特に sts:AssumeRole を軸にした信頼関係の悪用と、外部ID（External ID）の設計上の盲点について、実戦的な視点から解剖する。
—
1. 信頼関係の「暗黙の了解」に潜む攻撃ベクトル
クロスアカウントアクセスを構成する際、多くのエンジニアは Principal にアカウントIDを直書きし、それで安全だと錯覚する。だが、攻撃者は「そのアカウント内での権限昇格」を突破口にする。
攻撃のロジック：コンプロマイズの連鎖
1. 初期侵入: 被害者のアカウントAで、EC2インスタンスメタデータや、開発者のローカルPCからIAMクレデンシャルを奪取。
2. 偵察: aws sts get-caller-identity で権限を確認後、list-roles を実行し、信頼関係を持つターゲット（アカウントB）への AssumeRole パスを特定。
3. ピボット: アカウントBのロールに対して sts:AssumeRole を実行。ここで「外部ID」が設定されていなければ、攻撃は成功する。
ここで重要なのは、「信頼関係は一方通行ではない」ということだ。アカウントAの管理者が「アカウントBを信用する」と決めた瞬間、アカウントBの管理者（あるいはBを乗っ取った攻撃者）に、アカウントAの権限を明け渡したことになる。
—
2. 外部ID（External ID）の真の価値と「見せかけの防御」
AWSが提唱する「外部ID」は、いわゆる「Confused Deputy（混同された代理人）」問題を防ぐための鍵だ。しかし、現場ではこの外部IDが「ただのパスワード」として扱われ、推測可能な値（例：company-name-123など）に設定されているケースが後を絶たない。
脆弱な信頼関係ポリシー（アンチパターン）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "StaticExternalID"
// 外部IDが静的かつ推測可能だと、総当たり攻撃や情報漏洩で即座に突破される
}
}
}
]
}レッドチームの監査ポイント：
外部IDは、予測不可能なランダムなUUIDを使用し、かつ「そのロールで何ができるか」を最小権限（Least Privilege）で厳密に制限しなければならない。もし sts:AssumeRole された先が AdministratorAccess であれば、クロスアカウント攻撃は「全権奪取」と同義となる。
—
3. 防御の最前線：ガードレイルとリアルタイム監査
生成AIが台頭する現在、攻撃者はプロンプトインジェクションを用いて、クラウド環境のIAM情報や設定ファイルを読み出そうと躍起になっている。防御側は、ポリシーを「書く」だけでなく「監視」するフェーズに移行する必要がある。
推奨される防御アーキテクチャ（ガードレイル）
1. SCP (Service Control Policies) による遮断:
組織全体で、特定のアカウント以外への AssumeRole を明示的に拒否するガードレイルを敷く。
2. CloudTrailを用いた異常検知:
AssumeRole イベントの requestParameters を監視し、本来の運用フローから逸脱した principalId や送信元IPアドレスを検知する。
監視用クエリ例（CloudWatch Logs Insights）
# クロスアカウントアクセスを追跡し、異常なアクセス元を特定する
fields @timestamp, @message
| filter eventName = "AssumeRole"
| parse requestParameters.roleArn "arn:aws:iam::*:role/*" as targetAccount, roleName
| filter targetAccount != "自身の信頼するアカウントID"
| display @timestamp, userIdentity.arn, targetAccount, roleName, sourceIpAddress
| sort @timestamp desc—
4. 未来への備え：耐量子暗号とゼロトラストの融合
今後、耐量子計算機（PQC）の出現により、現在の通信プロトコル（TLS 1.3）や署名アルゴリズムが脅かされる可能性がある。AWSは既にKMSでのハイブリッド鍵交換を導入し始めているが、我々アーキテクトは「IAMの信頼関係」自体を、「物理的なデバイス認証（FIDO2/WebAuthn）とリンクした一時的なセッション」に置き換える設計を検討すべきだ。
「信頼」とは、証明書やトークンが発行された「瞬間」にのみ存在する。その後の継続的なアクセスは、継続的なリスクスコアリング（コンテキストベースの評価）によってのみ許可されるべきだ。
結論：プロフェッショナルとしての心得
攻撃者は、あなたが「設定したつもり」になっている場所を正確に突き刺す。信頼関係を定義する際は、単に動く設定を作るのではなく、「もしこのアカウントが完全に陥落したら、被害はどこまで波及するか？」という最悪のケースを常にシミュレーションしてほしい。
セキュリティは静的な壁ではない。動的な脅威に対する、絶え間ないアーキテクチャの最適化そのものである。
コメント