【東京開催】AWS re:Inforce 2025 振り返り勉強会にて「IAM Access Analyzerの新機能 Internal Accessって何？使ってみました！」というタイトルで登壇しました

あしざわです。

【東京開催】AWS re:Inforce 2025 振り返り勉強会にて、「IAM Access Analyzerの新機能 Internal Accessって何？使ってみました！」というタイトルで登壇しました。

このブログでは、登壇資料の共有と話した内容をスライドと共に紹介します。

登壇資料

お話ししたこと

IAM Access Analyzer Internal Accessとは？

IAM Access Analyzerに、これまでの「未使用のアクセス (Unused Access)」と「外部アクセス (External Access)」に加え、新たに「 内部アクセス (Internal Access) 」が追加されました。

この新機能は、Amazon S3、Amazon RDS、Amazon DynamoDBなどのAWSリソースに対してアクセス権限を持つ 、同じAWSアカウント内または同じAWS Organizations 組織内のすべてのIAMプリンシパル（IAMユーザー、IAMロール）を検出するもの です。 これにより、組織内の予期せぬアクセス経路や過剰な権限設定を発見し、最小権限の原則に沿ったアクセス管理を強化することが可能 になります。

IAM Access Analyzerが提供する3つのアナライザーの簡単な違いは以下の通りです:

• 未使用のアクセス (Unused Access): 検査範囲内（現在のAWSアカウントまたはOrganizations組織）にある、しばらく使用されていないIAMプリンシパル(IAMロールなど)を検出します
• 外部アクセス (External Access): 設定した信頼ゾーンの範囲外からのリソースへのアクセスを検出します
• 内部アクセス (Internal Access): 検査範囲内（現在のAWSアカウントまたはOrganizations組織）に存在する、監視対象リソースへアクセス可能なIAMプリンシパル(IAMロールなど)を検出します

それぞれの違いをわかりやすく図解したものがこちらです。

シングルアカウントで試してみた

今回は、Organizationsではない単一のAWSアカウントで、Internal Access機能を実際に検証してみました。

検証の流れ

1. 事前準備（S3バケットとIAMロールの作成、検出結果の通知設定）
2. Internal Accessアナライザーの作成
3. 検出結果の確認と分析

全体の構成図はこちらです。

事前準備

まず、IAM Access Analyzerの分析対象となるリソースと、そのリソースにアクセスするIAMプリンシパルを作成します。

• S3バケット: internal-access-test-bucket-{AWSアカウントID} という名前で、デフォルト設定のバケットを作成

• IAMロール: internal-role という名前で、ReadOnlyAccess 権限を付与したIAMロールを作成

• S3バケットポリシー: 以下のようなバケットポリシーを設定

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowInternalRoleAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": "*"
        },
        "Action": [
          "s3:GetObject",
          "s3:ListBucket",
          "s3:PutObject",
          "s3:DeleteObject"
        ],
        "Resource": [
          "${bucket_arn}",
          "${bucket_arn}/*"
        ],
        "Condition": {
          "StringLike": {
            "aws:PrincipalArn": "arn:aws:iam::${account_id}:role/internal-*"
          }
        }
      }
    ]
  }
  

注意点 : このバケットポリシーは、ロール名がinternal-で始まるIAMロールからのアクセスのみを許可するように見えますが、検証結果のセクションで後述する重要なポイント があります。

• 通知設定: 検出結果をメールで受け取れるよう、Amazon SNSトピックとAmazon EventBridgeルールを設定しました。 EventBridgeのイベントパターンは以下の通りです。

  {
    "source": ["aws.access-analyzer"],
    "detail-type": ["Internal Access Finding"]
  }
  

Internal Accessアナライザーの作成と検出結果

上記のリソース準備が完了したら、IAM Access Analyzerで「内部アクセスの分析(アナライザー)」を作成します。

設定項目は以下の通りでした:

• 検出結果のタイプ: Resource analysis - Internal access
• 名前: internal-access-analyzer
• 信頼ゾーン: 現在のAWSアカウント (固定表示)
• 分析対象のリソース: internal-access-test-bucket-{AWSアカウントID} (作成したS3バケット)

内部アクセスのアナライザーを作成する際、「信頼ゾーン」を指定する枠があったため、内部アクセスも外部アクセスと同様信頼ゾーンの概念が存在するんだ、とこの時点で思っていました（そう、この時点では、です）

アナライザー作成後、しばらく待つと、なんと 35件もの検出結果 が検知されました。 「信頼ゾーン を現在のAWSアカウントに設定したのに、なぜこんなに多くの検出結果が出るのだろう？」という疑問が湧きました。

なぜこんなに検知したのか？

この予期せぬ多数の検出結果には、主に2つの原因がありました。
1点目は IAMの評価論理の仕様 です。

同一AWSアカウント内では、アイデンティティベースポリシー（IAMポリシーなど） と リソースベースポリシー（S3バケットポリシーなど）の どちらか一方に明示的な許可があれば、アクセスが許可されます

今回の検証では、IAMロール internal-role に ReadOnlyAccess 権限を付与していました。S3バケットポリシーで特定のロールからのアクセスのみを許可する設定にしていましたが、ReadOnlyAccessのような広範な権限を持つIAMロールがアカウント内に存在する場合、バケットポリシーで明示的に許可していなくても、同じアカウント内であればアクセスできてしまうケースがあるのです。特に サービスリンクロール のような権限を広めに持つロールも多数存在するため、それが大量の検出につながることが分かりました。

2点目は 「信頼ゾーン」という表示に対する誤解 です。

マネジメントコンソールで「信頼ゾーン」と表示されていましたが、内部アクセスには信頼ゾーンの概念は存在しない と考えられます

これはマネジメントコンソールの表示の誤植であると推測され、実際には「 選択されたアカウント」を指していると考えられます。 アナライザーの設定画面を確認すると「選択されたアカウント」という表記になっており、これは「未使用のアクセス」アナライザーと同じ仕様のようです。

再チャレンジと課題

上記で判明した課題を受けて、S3バケットポリシーをより厳密に制限して再度検証を試みましたが、今度は権限を絞りすぎてしまい、S3へのアクセス自体ができなくなるエラーが発生しました。

ポリシーを見直して再々チャレンジしたものの、検出結果が再スキャンされず、一向に更新されませんでした。 ドキュメントによると「アナライザーが更新された時は24時間以内に自動再スキャンされる」と記載されていますが、リソース側が更新された場合の動作は明確ではありませんでした。

また、Internal Accessアナライザーには手動スキャンを実行するボタンがありません でした。外部アクセスアナライザーには手動スキャンボタンがあるため、これはInternal Accessの運用上の大きな課題となりうると感じました。

Organizations組織での検出結果の例

シングルアカウント環境での再スキャン問題があったため、参考としてAWS Organizations組織の環境でInternal Accessアナライザーを試してみました。

Organizations環境では、検出結果が以下のように非常に分かりやすく表示されました:

• どのリソースポリシーによって許可されているか
• SCP (Service Control Policies) や RCP (Resource Control Policies) の影響があるか否か
• 実際に許可されているアクセス権限(Access Level)
• アクセスされるリソースとアクセス元のIAMプリンシパルの情報

これは、複雑なマルチアカウント環境やクロスアカウントアクセスを管理する上で、非常に大きなメリットになると感じました。

料金について

IAM Access Analyzer Internal Accessの料金は、分析対象リソース1つあたり月額9.00 USD です。 これは一見すると高価に感じるかもしれません。 例えば、S3バケットを5つ監視対象とすると、それだけで月額45.00 USDが発生します。

参考：AWS IAM Access Analyzer の料金

検証して、この料金が 有効化した初日に発生し 、月途中で停止しても日割り計算はされない ということがわかりました。 「未使用のアクセス」と同様の従量課金ではない仕様となっています。 このため、全リージョンや全アカウント、または全てのリソースに対して一律で有効化することは、コスト観点で非常に危険 です。

検証してわかったこと・注意点

今回の検証を通じて、IAM Access Analyzer Internal Access機能についていくつかの重要な学びと注意点が見えてきました。

1. 全リソースに対し一律で有効化する機能ではない
   • 前述の通り、分析対象リソース1つあたり月額9.00 USDと高価であり、有効化した時点で料金が発生します。
   • そのため、機微情報が含まれるS3バケットや、特に厳密な最小権限を適用したいRDSインスタンスなど、特定の重要なリソースに絞って適用すること が推奨されます。
2. 運用最適化までの難易度は高い
   • デフォルト設定や広範なIAMポリシーが存在すると、__サービスリンクロール__なども含め大量の検出結果が発生する可能性があります。
   • これを適切に運用するには、リソースベースポリシーとアイデンティティベースポリシーの両方をかなり制限し、かつアーカイブするためのルールとセットで運用していく必要があります。検出された過剰なアクセスを一つずつ見直し、改善していく手間がかかるため、運用には根気が必要です。
3. シングルアカウントよりマルチアカウント環境での活用にメリットがある
   • 今回の検証ではシングルアカウントで試しましたが、そのメリットを最大限に引き出すのは難しいと感じました。
   • AWS Organizations環境やマルチアカウント環境において、SCP (Service Control Policies) や Permission Boundary と併用する ことで、より効率的に 複雑なクロスアカウントアクセスや組織内での過剰な権限設定を検知・管理できる でしょう。 SCP/RCPの影響があるリソースのみを検知し、それをアーカイブすることも可能になります。

結び

今回は、IAM Access Analyzerの新機能「Internal Access」について、その概要から実際の検証、そして運用上の注意点までを解説しました。

個人的には、複雑なマルチアカウント環境でのクロスアカウントアクセス管理において、非常に強力なツールとなる可能性があるとわかりました。 ただし、コストや運用の難易度を考慮し、適用範囲を慎重に検討することが重要だと考えられます。

この記事が、皆さんのAWS環境のセキュリティ強化の一助となれば幸いです。

以上、あしざわでした。