トップ > AWS re:Inforce 2025 > 【AWS re:Inforce 2025】Internal Access: 組織の誰がリソースにアクセスできるか (IAM307-NEW)

【AWS re:Inforce 2025】Internal Access: 組織の誰がリソースにアクセスできるか (IAM307-NEW)

AWS re:Inforce 2025 セキュリティ IAM Access Analyzer
記事タイトルとURLをコピーする

マネージドサービス部 佐竹です。
AWS re:Inforce 2025 に現地参加してきましたので、そのログを順番に記述しています。

はじめに

reinforce.awsevents.com

2025年6月16日から18日にかけて、ペンシルベニア州フィラデルフィアで AWS のセキュリティに特化したカンファレンス「AWS re:Inforce 2025」が開催されました。

参加したセッションのレポートを「1日のまとめ」に書いていこうとしたらあまりにも文章量が増えすぎてしまったので小分けにしています。

本ブログは「【AWS re:Inforce 2025】現地参加レポート 3日目 6月18日(火) 佐竹版」より IAM307-NEW Understand who in your organization can access your AWS resources のセッションレポート（解説）です。

私の感想やコメントは解説の邪魔になると感じたので「脚注」として記載しています。

IAM307-NEW Understand who in your organization can access your AWS resources 解説

翻訳すると「組織内の誰があなたの AWS リソースにアクセスできるかを理解する」となります。

ようは IAM Access Analyzer の新機能である Internal Access（内部アクセス）についてのセッションです。

概要

本セッションは、「誰が (Who)、何に (What)、アクセスできるか (Can Access) を理解する」という、「AWS におけるアクセス管理自体の理解」がテーマです*1。

本セッションは以下の4つのステップで構成されていました。

  1. Scope out the landscape (現状の把握):
    AWS のアクセス制御の仕組みとその複雑さを理解する
  2. Use investigative tools (調査ツールの活用):
    IAM Access Analyzer が提供する既存の機能をレビューする
  3. Upgrade your tools (ツールのアップグレード):
    基調講演で発表された、新しい Access Analyzer の機能を知る
  4. Complete the mission (ミッションの達成):
    デモを通じて、新機能がどのように課題を解決するかを具体的に学ぶ

前提：なぜ、アクセス管理は複雑なのか

最初、多くの組織が直面する「アクセス管理の複雑さ」について、その背景が解説されました。

アクセス制御で利用できるポリシー自体の種類の多さ

※画像のRCPの略称がSCPになっているのはミスです

AWS のアクセス制御の仕組み自体も、複数のポリシーが階層的に組み合わさって機能するため、本質的に複雑です。

  • データ境界 (Data perimeter): SCP (サービスコントロールポリシー) や RCP (リソースコントロールポリシー) のような、組織やアカウント全体に適用される「粗粒度」のガードレールです。これらは許可される権限の最大範囲を定めます。
  • 最小権限 (Least privilege): アイデンティティベースポリシー (IAM ロールやユーザーにアタッチするもの)、リソースベースポリシー (S3 バケットなどリソース側にアタッチするもの)、そしてアクセス許可の境界 (Permissions Boundary) といった「細やか」な権限設定です。

最終的なアクセス可否は、これらすべてのポリシーが評価され、そのロジックが組み合わさって決定されます。例えば、アイデンティティポリシーで Allow されていても、SCP で Deny されていればアクセスはできません*2。この評価ロジックを人間がすべて正確に追跡し、把握することは非常に困難です。

ペルソナごとのミッションの違い

このスライドは、組織内に存在する役割（ペルソナ）の違いと、それぞれのミッションを示しています。

  • 中央集権的なチーム (Centralized):※左側
    CISO やセキュリティチームがここに分類されます。彼らのミッションは、組織全体のセキュリティを大規模に管理し、ガバナンスを効かせ、全社的なセキュリティのベストプラクティスを徹底することです。
  • 分散したチーム (Decentralized):※右側
    アプリケーションを開発する開発者チームが該当します。彼らのミッションは、ビジネスの要求に応じて迅速にアプリケーションを開発し、デプロイすることです。そのため、権限設定においては、セキュリティの厳密さよりも「アプリケーションが問題なく動作すること」を優先する傾向があります。

このように、立場によってミッションや優先順位が異なることが、組織全体で一貫したアクセス管理を難しくする一因となります。

①：IAM Access Analyzer による最小権限への道のり

この複雑なアクセス管理を支援し、「最小権限」への道のりをガイドするのが IAM Access Analyzer の役割です。

ここからは、IAM Access Analyzer の機能について深堀していきます。

継続的な改善サイクル「Set, Verify, Refine」

アクセス管理は、一度設定して終わりではありません。「設定 (Set) → 検証 (Verify) → 洗練 (Refine)」という継続的なサイクルを回し続けるジャーニー（旅）であると強調されました。

サイクルの各段階を支援する機能群

IAM Access Analyzer は、このサイクルの各フェーズを支援する具体的な機能を提供しています。

  • 設定 (Set) フェーズ:
    権限を定義する最初のステップから、Access Analyzer は開発者を支援します。

    • IAM Policy Generation: アプリケーションをテスト環境で実行し、その CloudTrail ログを分析することで、実際に使用されたアクションのみを許可する最小権限のポリシー案を自動生成します。これにより、過剰な権限を最初から含めないようにできます。
    • IAM Policy Validation & Custom Policy Checks: 作成した、あるいは既存のポリシーを静的にチェックします。ポリシーの構文エラーや AWS のベストプラクティスからの逸脱を警告するほか、「このアクションは禁止」といった組織独自のルールを定義し、それに準拠しているかを検証できます。

  • 検証 (Verify) と 洗練 (Refine) のフェーズ:
    設定した権限が意図通りかを確認し、不要な権限を削ぎ落としていくステップです。

    • 未使用のアクセス分析 (Unused access findings): 一定期間使われていない IAM ロール、ユーザー、アクセスキー、さらにはロールに付与されているものの実際には一度も使われていない特定の権限までを検出します。セッションでは「権限の断捨離を助けるこんまり (Marie Kondo) アナライザー」と表現されており、攻撃者に悪用される可能性のある不要なアクセス経路を継続的にクリーンアップするのに役立ちます*3。
    • 外部アクセス分析 (External access findings): こちらが IAM Access Analyzer の元祖ともいえる中核機能です。S3 バケットなどが意図せずパブリックに公開されていたり、信頼する組織外の第三者からアクセスされたりしていないかを継続的に監視し、検出結果を報告します。

特に「未使用のアクセス分析」は、上のようなダッシュボードで未使用の権限などを可視化し、不要な権限を削除するための具体的な推奨事項まで提供してくれます。

これにより、攻撃者に悪用される可能性のある不要なアクセス経路を継続的にクリーンアップできます。

さて、これらの既存機能は非常に強力ですが、パズルの重要なピース、すなわち「組織内部のアクセス」が欠けていました。

②：新機能「内部アクセスアナライザー」とブレークスルー

その最後のピースを埋めるのが、今回発表された新機能「内部アクセスアナライザー (Internal Access Analyzer)」です。

残された最後のピース：組織内部のアクセス

このスライドは、新機能がもたらす4つの主要な価値を示しています。

  • 証明可能なセキュリティ保証による理解:
    組織内の誰が重要リソースにアクセスできるかを、数学的に証明可能なレベルで正確に理解できます。「推測」ではなく「証明」である点が重要です。
  • 日々の監視と通知による保護:
    重要なリソースを毎日監視し、新しいアクセス経路が許可された場合に即座に通知することで、意図しない変更に迅速に対応できます（Amazon EventBridge を使用）。
  • 統合ダッシュボードによる一元的なレビュー:
    すべてのアクセス（内部および外部）を一元的にレビューできるリソース中心のダッシュボードにより、最小権限への取り組みを後押しします。
  • リソース選択によるコスト最適化:
    この詳細な分析は有料機能ですが、分析対象を真に重要なリソースに絞ることで、セキュリティとコストを最適化できます。

なぜ内部アクセス分析はこれほど困難なのか

この「内部アクセス分析」の技術的な困難さを説明するパートでは宇宙スケールに話が発展しました。何故「証明」となっているか、という点の補足でもあります。

前述の通り、内部アクセスを正確に分析するには、アイデンティティポリシー、リソースポリシー、SCP など、あらゆるポリシーの組み合わせを考慮する必要があります。その組み合わせの総数は、天文学的な数字になります。

以下はその語りの抜粋です。

この分析で考慮すべき組み合わせの総数は、およそ"10の160乗"に達します。
この数字がどれほど大きいかというと、既知の宇宙に存在する原子の総数が約"10の80乗"と推定されています。つまり、このスライドが示すように「宇宙を丸ごとコピーしてもう一つ用意し、その2つの宇宙から特定の原子を1つずつペアで選び出す組み合わせの数」に匹敵するのです。

このすべての組み合わせを力任せに計算することは不可能です*4。

IAM Access Analyzer のブレークスルーは「自動推論 (Automated Reasoning)」と呼ばれる数学的なアプローチとアルゴリズムです。これにより、膨大な組み合わせの大部分を探索することなく、効率的かつ正確に「誰が何にアクセスできるか」という問いへの答えを導き出しています*5。

デモで見る具体的なユースケース

デモでは、ブティックケーキ店のセキュリティ管理者が、この新機能を使って具体的な課題を解決していく様子が示されました。

  • シナリオ1: S3バケットのアクセス棚卸し 「秘伝のケーキレシピ」が保存された S3 バケットを分析。すると、本来アクセス不要なはずの「配送担当ドライバー」ロールに読み取り権限があることが判明します。これは情報漏洩のリスクです。さらに、レシピを開発する「パティシエ」ロールには、レシピを変更・削除できてしまう過剰な書き込み権限があることも明らかになりました。

  • シナリオ2: 有効な権限の正確な把握 財務情報が入った DynamoDB テーブルに対し、CFO のロールには DynamoDBFullAccess ポリシーが付与されていました。しかし、ユーザーから「書き込みができない」という問い合わせがあり、調査が必要な状況でした。内部アクセス分析を実行すると、このロールには同時に「書き込みを禁止するアクセス許可の境界 (Permissions Boundary)」がアタッチされており、最終的な有効権限は「読み取りのみ」であることが即座に証明されました。これにより、複雑な調査を行うことなく、問題の原因を特定できました。

パートナー連携

セッションの最後には、この新機能がサードパーティのセキュリティパートナーとも連携していくことが発表されました。

例えば、ID 管理ソリューションを提供する Savion などのパートナーは、内部アクセス分析の結果を取り込むことで、AWS の IAM ロールを、ID プロバイダー（IdP）の実際のユーザーアイデンティティと紐づけることが可能になります。これにより、「どの部署の、誰が、どの重要データにアクセスできるのか」といった、よりビジネスに即したレベルでの可視化と棚卸しが実現します。

関連記事等

セッションの動画

この概要を読んで興味が出た方は YouTube に既に動画がアップロードされているので是非ご覧ください。

新しい IAM Access Analyzer 機能で重要な AWS リソースへの内部アクセスを検証する

aws.amazon.com

まとめ

さて、最後に「この機能がなぜ必要だったのか」、その存在理由に焦点を当ててまとめます。

これまでの中核機能であった「外部アクセス分析(External Access)」は、いわば「リソース視点」でセキュリティを検証するものでした。オフィスで例えると、出入り口の鍵、重要種類入れのキャビネットのようなものです。

「この S3 バケットは、インターネットに公開されていないか？」「信頼できない外部アカウントからアクセスされていないか？」といった調査から、各リソースを守るための境界を監視する役割を担っていました。

これは「不用意にアクセスが外部へと公開されていないか？」という「守り」の観点から、監査視点でも有効な機能となっています。なお、「External Access」の対象となるリソースは以下の通りです。

  1. Amazon Simple Storage Service buckets
  2. Amazon Simple Storage Service directory buckets
  3. AWS Identity and Access Management roles
  4. AWS Key Management Service keys
  5. AWS Lambda functions and layers
  6. Amazon Simple Queue Service queues
  7. AWS Secrets Manager secrets
  8. Amazon Simple Notification Service topics
  9. Amazon Elastic Block Store volume snapshots
  10. Amazon Relational Database Service DB snapshots
  11. Amazon Relational Database Service DB cluster snapshots
  12. Amazon Elastic Container Registry repositories
  13. Amazon Elastic File System file systems
  14. Amazon DynamoDB streams
  15. Amazon DynamoDB tables

ただし、これはあくまで「外部」からのアクセス経路を検証するものです。

では、アカウント「内部」の IAM ユーザーが、IAM ポリシーのみによってアクセスできる状態になっていた場合はどうでしょうか？ この経路は「外部アクセス」ではないため、External Access のスコープ外となり、これまで簡単に知る術がありませんでした。

また仕様として、同一 AWS アカウント内では「S3 (リソース側) のバケットポリシー」または「アイデンティティ側の IAM ポリシー」のどちらか一方で許可されていればアクセスが成立してしまいます。この場合、リソース側のポリシーだけを棚卸しても、正しいアクセス権限の把握となりません。

この複雑さが、内部のアクセス経路を見えにくくしていました。

そこで今回の新機能「内部アクセスアナライザー(Internal Access)」なのですが、先の逆方向となる「アイデンティティの視点」でアクセスパスを検証します。オフィスで例えると、従業員のアクセス権、出入りの業者に渡している鍵をターゲットとしているようなものです。

「この開発者ロールは、意図せず本番の機密データにアクセスできてしまっていないか？」「この IAM ユーザーは、本当にこのデータベースに到達する必要があるのか？」といった、組織内部のプリンシパル（アイデンティティ）を起点とした問いに答える役割を持ちます。

ただ、この「証明」を可能にする「自動推論」は極めて高度な分析を必要とします。そのためか、現時点（2025年6月）で内部アクセス分析が可能な対象リソースは、発表の通り*6、機密データが保管されることの多い以下の3つに限定されています。

  • Amazon S3
  • Amazon DynamoDB
  • Amazon Relational Database Service (RDS)

AWS 公式ドキュメントでは以下の通りの記載となりますが、実質的には3つで正しいです。

  1. Amazon Simple Storage Service buckets
  2. Amazon Simple Storage Service directory buckets
  3. Amazon Relational Database Service DB snapshots
  4. Amazon Relational Database Service DB cluster snapshots
  5. Amazon DynamoDB streams
  6. Amazon DynamoDB tables

また、有料機能であることからも、最重要リソースから適用していくことが推奨されるでしょう。加えて、今後の対象リソース拡大にも期待したいと思います。

では、これにて本ブログは終了となります。

また、お会いしましょう。

余談

IAM ポリシーの分析だけに集中しての調査であれば、これまで通り「IAM ポリシーシミュレーター」での調査が有効な場面もまだまだ多いと存じます。

*1:現在の AWS のアクセス管理機能を理解すると同時に、そもそものアクセス管理自体の難しさや、複雑さが語られます

*2:これは AWS の権限の基礎となる"明示的な拒否と暗黙的な拒否の違い"の話でもあります https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.html

*3:アメリカでは「KonMari」という英語(動詞)になるほどに知られています https://en.wikipedia.org/wiki/Marie_Kondo

*4:これは組合せ爆発/Combinatorial explosion と言われる事象です。全ての AWS アカウントに存在する全てのリソースとプリンシパルを全てかけ合わせるだけでも膨大な組み合わせのパターンとなります

*5:「自動推論 (Automated Reasoning)」はポリシーを数学的な論理式に変換し、「この条件を満たすアクセス経路は、論理的に存在しうるか？」という問いを、組み合わせを一つ一つ試すことなく証明するものです。例えるなら、無数の鍵の束を一つ一つ試すのではなく、鍵穴の形を解析して「この鍵穴に合う鍵は、この束の中に存在する可能性があるか？」を解き明かすようなものです。

*6:IAM Access Analyzer、AWS 組織内の誰が AWS リソースにアクセスできるかを識別できるように https://aws.amazon.com/jp/about-aws/whats-new/2025/06/iam-access-analyzer-aws-organization-access-resources/

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。