[Chalk talk] Threat modeling for AWS identity: From federation to resource access に参加しました #SEC335 #AWSreInvent

こんにちは、クラウド事業本部 コンサルティング部のいたくらです。
AWS re:invent 2025 は現地参加しています。

「Threat modeling for AWS identity: From federation to resource access」に参加したのでレポートします。
Chalk talk セッションはスピーカーと参加者がインタラクティブにやりとりするため、聞き取れなかった部分もありますがご了承ください。

3行まとめ

• STRIDE フレームワークと脅威ステートメント構文で脅威を体系的に分類・評価
• Identity Federation のデータフロー図（DFD）を作成し、信頼境界を越えるポイントの脅威を特定
• 脅威モデリングは「Early, Often, Never too late」、多様な役割の人が参加して継続的に更新

セッション概要

• セッションID: SEC335
• タイトル: Threat modeling for AWS identity: From federation to resource access
• スピーカー
  • Meg Peddada, Senior Partner Solutions Architect, AWS
  • Alex Waddell, Sr EMEA Security Specialist SA, Amazon Web Services
• レベル: 300 – Advanced

Identity is key to a strong security foundation. In this interactive session, learn about threat modeling methodologies tailored for AWS IAM architectures and external IdPs. Explore strategies to systematically evaluate federation flows, assess trust boundaries, and implement defense-in-depth strategies to secure human and workload identity management at scale using IdP conditional and risk-based authentication, IAM Identity Center, IAM policies, SCPs, RCPs, declarative policies, tags and multi-account models. Using common customer scenarios, discover techniques to strengthen your identity architecture and maintain continuous authentication and authorization controls.

（機械翻訳）
アイデンティティは強固なセキュリティ基盤の鍵です。このインタラクティブなセッションでは、AWS IAM アーキテクチャと外部アイデンティティプロバイダー向けに調整された脅威モデリング手法について学びます。フェデレーションフローを体系的に評価し、信頼境界を評価し、アイデンティティプロバイダーの条件付きおよびリスクベース認証、IAM Identity Center、IAM ポリシー、SCP、RCP、宣言的ポリシー、タグ、マルチアカウントモデルを使用して、人間とワークロードのアイデンティティ管理を大規模に保護するための多層防御戦略を実装する方法を探ります。一般的な顧客シナリオを使用して、アイデンティティアーキテクチャを強化し、継続的な認証および認可制御を維持するための技術を発見します。

セッション内容

脅威モデリングとは

脅威モデリングの第一人者 Adam Shostack 氏が提唱する4つの質問がベースです。

1. What are we working on? - 私たちは何に取り組んでいるのか？
2. What could go wrong? - 何がうまくいかない可能性があるか？
3. What are we going to do about it? - それに対してどう対処するか？
4. Did we do a good enough job? - 十分にうまくできたか？

STRIDEフレームワーク

脅威モデリングで広く使われるフレームワークSTRIDEの紹介がありました。

頭文字	英語	日本語
S	Spoofing	なりすまし
T	Tampering	改ざん
R	Repudiation	否認
I	Information Disclosure	情報漏洩
D	Denial of Service	サービス拒否
E	Elevation of Privilege	権限昇格

脅威ステートメントの構成

有用な脅威ステートメントは以下の要素で構成されます。

• Threat Source + Pre-requisites - 誰が、どのような前提条件で脅威を引き起こすのか
• Threat Action - どのような攻撃を行うか
• Threat Impact - 攻撃が成功した場合の影響
• Goal + Impacted Assets - 攻撃者の目的と影響を受けるアセット

Threat Composer

AWS が提供するオープンソースツール「Threat Composer」の紹介がありました。STRIDE フレームワークを使用して脅威モデルのワークフローを構築し、ブレインストーミングを支援するツールです。GitHub で公開されており、ダッシュボードで脅威の優先度やステータスを可視化したり、アーキテクチャ図と脅威モデルを関連付けて管理できます。

Identity Federation のデータフロー図（DFD）

Identity Federation の典型的なアーキテクチャをデータフロー図（DFD）に変換するデモが行われました。

• 構成要素
  • ユーザー
  • 外部 IdP（Entra ID、Okta など）
  • IAM Identity Center
  • IAM
  • S3 バケット（リソース）
• データフローの流れ
  1. ユーザーが IdP で認証
  2. SCIM プロトコルでユーザー・グループが Identity Center に同期
  3. Identity Center が IAM ポリシーをプロビジョニング
  4. ユーザーが S3 バケットにアクセス時、S3 が IAM に認証・認可を問い合わせ

信頼境界を点線で描き、境界を越えるデータフローに対して「何がうまくいかない可能性があるか」を検討します。

脅威ステートメントの例

セッションで作成された脅威ステートメントの例：

「過剰に許可された IdP マッピングへのアクセスを持つ悪意のあるユーザーは、幅広い権限を持つAWSアカウントのロールを引き受けることができ、その結果、過度なアクセスや不正アクセス、さらには権限昇格が発生し、機密データの流出につながる可能性があります。」

• このステートメントの構成要素
  • Threat Source + Pre-requisites - 過剰に許可された IdP マッピングへのアクセスを持つ悪意のあるユーザー
  • Threat Action - AWSアカウントで広範な権限を持つロールを引き受ける
  • Threat Impact - 過度なアクセス、不正アクセス、権限昇格
  • Goal + Impacted Assets - 機密データへの不適切なアクセスや漏洩

Threat Technique Catalog for AWS（AWS TTC）

AWS の Customer Incident Response Team が MITRE ATT&CK フレームワークと連携して開発した Threat Technique Catalog for AWS の紹介がありました。AWS 固有のコントロールとサービスに関する脅威情報が含まれており、各脅威に対する具体的な緩和策が記載されています。フレームワークに紐づいているため、緩和策の重要性を説明しやすいのが利点です。

識別された脅威シナリオと緩和策

1. 侵害された IdP

• 緩和策
  • Break Glass IAM ユーザーの実装（ IdP がダウンした場合のバックアップ）
  • バックアップ用の AWS アカウントレベルIAMフェデレーションの構成
  • IdP フェデレーションを無効化する手順の整備
  • CloudTrail によるログ記録
  • IAM Access Analyzer の活用

2. アクセス権限の蓄積

従業員が役割変更を重ねるたびにアクセス権限が蓄積されていく問題です。セッション中、Meg さんが「アカウント A へのアクセスが必要」 「このリソースへのアクセスも必要」 「書き込み権限も必要」と次々に Alex さんに依頼し、Alex さんが全部承認してしまうというロールプレイを通じて、この問題を分かりやすく説明していました。

• 緩和策
  • IAM Access Analyzer で未使用アクセスを検出
  • Permission Boundary の実装
  • タグベースのアクセス制御

3. 合併・買収（M&A）時のアカウント統合

買収した企業の AWS アカウントを組織に統合する際のリスクです。参加者からも「買収したアカウントですべてが問題があった」という声が上がっていました。

• 緩和策
  • ステージング OU にアカウントを配置し、SCP で制御
  • External Access Analyzer で外部アクセスを事前に把握
  • アカウント統合前にセキュリティ評価を実施

4. 誤設定されたリソース

S3 バケットなどのリソースが誤ってパブリックアクセス可能になるリスクです。

• 緩和策
  • Resource Control Policy（RCP）
  • Declarative Policy
  • パブリックアクセスブロックの強制

脅威モデリングのベストプラクティス

• タイミング
  • Early: できるだけ早い段階で始める
  • Often: API の変更や新機能追加のたびに更新
  • Never too late: 既存のワークロードでも今から始められる

AWS ではすべての API に脅威モデルが作成されており、API の変更や新機能導入のたびに更新しているとのことでした。

• 適切な参加者
  • 脅威モデリングはセキュリティ担当者だけでなく、多様な役割の人が参加すべき
    • 開発者・アーキテクト
    • ビジネス担当者・プロダクトマネージャー
    • アプリケーションセキュリティ担当
    • SOCチーム・脅威対策チーム

セキュリティ担当者だけでは人数が足りないこと、アプリを作った本人でないと何をしているか分からないことから、開発者がオーナーシップを持ち、セキュリティ担当者はファシリテーターの役割を担うのが良いとのことでした。

• Key Takeaways
  • JML（Joiner/Mover/Leaver）のリクエストプロセスを考慮する
  • 脅威モデリングは継続的に実施する - 状況は常に変化する
  • アイデンティティチェーンのすべての部分を検討する - HRシステムから進める
  • SCP、RCP、Permission Boundaryを使ってガードレールを実装する
  • IAM Access Analyzerを活用して最小権限を目指す

さいごに

緊急時専用のアクセス手段として用意しておく IAM ユーザーのことを「Break Glass IAM ユーザー」と呼ぶことを初めて知りました。個人的には、Threat Composer や Threat Technique Catalog for AWS といったツールの存在を知らなかったのでとても勉強になりました。

この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部 コンサルティング部のいたくら（＠itkr2305）でした！