マルチアカウント環境におけるAWS IAM Access Analyzerの構成、通知方法、運用について考えてみた

平井裕二

2024.06.14

はじめに

マルチアカウント環境でのAWS IAM Access Analyzerの構成や通知方法、運用についてまとめました。

前提として、アナライザーは無料の外部アクセス検出のみを利用します。有料である未使用アクセスの検出用アナライザーは作成しません。

本ブログの内容は、あくまでも一つの参考例としてお考えください。

マルチアカウントの運用は、各組織の事情によって異なりますので、ご自身の環境に合わせて適宜アレンジしてください。

アナライザー導入前のマルチアカウント構成

以下のアカウント構成を想定しています。

  • 管理アカウント(AWS Organizationsの管理アカウント）
  • メンバーアカウント（管理アカウントを除く、組織内のアカウント）

IAM Access Analyzerの外部アクセス検出とは

IAM Access Analyzerの外部アクセス検出は、アカウント内のリソースにアタッチされているポリシーをチェックし、他のAWSアカウントや組織外からアクセス可能かどうかを検出する機能です。

アナライザーはリージョンごとに作成する必要があります。

アナライザーの作成時に選択した組織やアカウントを信頼ゾーンとし、その内部でのリソース共有は安全と見なされます。

一方、アナライザーと同じリージョン内のリソースが、信頼ゾーン外のプリンシパル（IAMユーザ・IAMロール・リソースなど）からアクセス可能な場合、アナライザーは外部アクセスを検出し、結果(Findings)を生成します。

この機能により、意図しない外部へのアクセス許可を特定し、セキュリティリスクを軽減できます。

IAM Access Analyzerの他の機能も含めて詳細は、以下の記事をご参照ください。

管理アカウントとメンバーアカウントでの信頼ゾーン

アナライザーを作成する際、管理アカウントとメンバーアカウントで選択できる信頼ゾーンは異なります。

管理アカウントがアナライザーを作成する場合、設定する信頼ゾーンは以下から選択できます。

  • 組織（Organizations内のアカウント全体）
  • アカウント（管理アカウントのみ）

組織を選択した場合、管理アカウントも含め組織内の全てのアカウントが分析対象です。

一方、個別アカウントを選択した場合、文字通り、1アカウントが分析対象です。

メンバーアカウントがアナライザーを作成する場合、設定する信頼ゾーンは以下のみです。（管理アカウントからの委任はしていないと仮定）

  • アカウント（作成するアカウントのみ）

信頼ゾーンが組織とアカウントでの違い

アナライザーの信頼ゾーンが組織とアカウントによる違いについて説明します。

信頼ゾーンが組織

信頼ゾーンが組織の場合、組織内の全アカウントのプリンシパルによるリソースへのアクセスは信頼ゾーンに含まれます。

そのため、リソースに対して、組織外のアカウントのプリンシパルにアクセス許可を付与した場合のみ、検出結果が生成されます。

例えば、アナライザーと同じアカウントが所有するS3バケットに対して、組織内の別のアカウントのIAM ロールにアクセス許可を付与するため、S3バケットのバケットポリシーにアクセス許可を追加したとします。この場合、アナライザーは結果を生成しません。

一方、組織外のアカウントのプリンシパルにアクセス許可を付与した場合は、アナライザーが検出結果を生成します。

例に挙げているS3バケットのバケットポリシーでプリンシパルの設定方法については、以下の記事をご確認いただくとイメージがしやすいです。

信頼ゾーンがアカウント

信頼ゾーンがアカウントの場合、アカウント内のプリンシパルによるリソースへのアクセスは信頼ゾーンに含まれます。

そのため、アナライザーと同じアカウントのリソースに対して、他のAWSアカウントや同じ組織内の別のアカウントのプリンシパルにアクセス許可を付与した場合、検出結果が生成されます。

例えば、アナライザーと同じアカウントが所有するS3バケットに対して、組織内の別のアカウントのIAM ロールにアクセスを許可するため、S3バケットのバケットポリシーにアクセス許可を追加したとします。この場合、アナライザーは結果を生成します。

組織外のアカウントも同様に結果を生成します。

信頼ゾーンが組織とアカウントの違いのまとめ

信頼ゾーンが組織の場合、組織内の全アカウントのプリンシパルによるアクセスは信頼され、組織外のプリンシパルに対するアクセス許可のみが検出されます。

一方、信頼ゾーンがアカウントの場合、そのアカウント内のプリンシパルによるアクセスのみが信頼され、他のアカウント（同じ組織内のアカウントを含む）のプリンシパルに対するアクセス許可が検出されます。

以上のアナライザーの信頼ゾーンによって、検知基準が異なる点を踏まえた上で構成を考えました。

構成

マルチアカウント環境におけるIAM Access Analyzerの構成は、以下の2つが考えられます。

  1. 管理アカウントのみ、信頼ゾーンが組織のアナライザーを作成し、メンバーアカウントにはアナライザーを作成しない。
  2. 管理アカウントを含め各アカウントごとに、信頼ゾーンがアカウントのアナライザーを作成する。

それぞれの構成の内容やメリット・デメリットを説明します。

前提として、IAM Access Analyzerは、AWS Security Hubと統合済みとします。

Security Hubのコンソール画面からIAM Access Analyzerと統合可能です。

1. 管理アカウントのみアナライザーを作成

以下の構成になります。

管理アカウントのリージョン毎にアナライザーを作成します。

管理アカウントも含め組織内の全てのアカウントが分析対象です。

検知結果は、管理アカウントの集約リージョンのSecurity Hubに集約されるため、集約リージョンのSecurity Hub上で、組織内の全アカウントの検知結果が確認できます。

メリット

「2. 各アカウントにアナライザーを作成」と比較した場合のメリットは以下の通りです。

  1. アナライザーとアーカイブルールは、管理アカウントのリージョンごとに作成するだけでよい
  2. 管理アカウント側から、全ての検知結果を確認やアーカイブ対応可能。
  3. 管理アカウント側から、検知から90日を経過した検知結果もアナライザーから確認できる

アーカイブルールを利用することで、ルールの作成時に定義した基準を満たす新しい検出結果を自動的にアーカイブできます。

アナライザーやアーカイブルールは、管理アカウント側だけで作成するとよいので、管理が楽です。

また、検知結果を解決せずにアーカイブしたい場合、管理アカウント側から全ての検知結果に対して対応可能です。

３点目のメリットに関しては、Security Hubでの結果は、最新の更新から90日後、または更新が行われない場合は、作成日から90日後に削除されてしまいます。

そのため、90日を経過した場合、Security Hub上からは見れなくなりますが、管理アカウントのアナライザーから確認できる点がメリットです。

デメリット

  1. メンバーアカウント側から、検知結果をアーカイブ対応できない。アーカイブルールも設定できない。
  2. メンバーアカウント側から、コンソール上で検知結果が確認できない。

アナライザーは、管理アカウントで作成しているので、メンバーアカウント側からアーカイブ対応やアーカイブのルール設定ができません。

管理アカウント側でのみ対応できる点が、メンバーアカウント側から操作できないというメリットでもあり、柔軟性にかけるというデメリットでもあります。

２点目のメリットに関しては、コンソール上では確認できませんが、検知結果をメンバーアカウントの担当者に通知することで、検知結果の共有はできます。通知方法については、次章「通知方法」で説明します。

2. 各アカウントにアナライザーを作成

以下の構成になります。

各アカウントに対して、リージョン毎にアナライザーを作成します。検知結果は、管理アカウントの集約リージョンのSecurity Hubに集約されます。

メリット

  1. メンバーアカウント側から、検知結果をアーカイブやアーカイブルールが設定できる
  2. メンバーアカウント側から、コンソール上で検知結果が確認できる

「1. 管理アカウントのみアナライザーを作成」のデメリットが、そのまま「2. 各アカウントにアナライザーを作成」のメリットとなります。

デメリット

  1. 各アカウントごとにアナライザーやアーカイブルールを作成する必要がある
  2. 各メンバーアカウント側で検知結果のアーカイブ対応をする必要がある
  3. 管理アカウント側で、検知から90日を経過したメンバーアカウントの検知結果は、確認できない

３点目に関して、管理アカウント側では、Security Hub上で組織内の全アカウントの検知結果を確認できますが、90日を超えると確認ができなくなります。

どちらがよいか

基本的には、「1. 管理アカウントのみアナライザーを作成」を採用するとよいと考えます。

管理アカウント側で一元管理できるため、運用が楽になるのが大きな理由です。

ただし、「1. 管理アカウントのみアナライザーを作成」と「2. 各アカウントにアナライザーを作成」では、アナライザーの検知基準が異なる点を抑える必要があります。

「1. 管理アカウントのみアナライザーを作成」は、組織を信頼ゾーンとみなすのに対し、「2. 各アカウントにアナライザーを作成」は、自身のアカウントのみを信頼ゾーンとみなします。

そのため、組織内の他アカウントへのアクセス許可の付与を外部アクセスとして検出するかどうかによって、「1. 管理アカウントのみアナライザーを作成」と「2. 各アカウントにアナライザーを作成」のどちらの構成を選択するかが決まります。

また、各メンバーアカウント側でアーカイブ操作やアーカイブルールを作成する必要があるかどうかが、重要な検討事項になります。

組織を信頼ゾーンにさせたくない場合や、メンバーアカウント側で柔軟に対応する必要性がある場合を除き、「1. 管理アカウントのみアナライザーを作成」がよいと考えます。

その他の構成

「管理アカウントで信頼ゾーンが組織のアナライザーを作成しつつ、全メンバーアカウントのアナライザーも作成する」という構成も考えられます。

ただし、管理アカウントのアナライザーで組織内の全アカウントを分析しつつ、メンバーアカウントのアナライザーでもアカウントの分析をするので、一部で重複した検知が発生してしまいます。

「1. 管理アカウントのみアナライザーを作成」と「2. 各アカウントにアナライザーを作成」に対して、大きなデメリットとなるため、おすすめしません。

クラスメソッドメンバーズの場合

弊社のクラスメソッドメンバーズでAWSアカウントをご利用の場合、セキュリティおよびサービス提供のためにいくつかのAWSサービスが自動的に有効化され、リソースが作成されます。

その中で、cm-access-analyzerという名前のアナライザーも自動で全リージョンに作成されます。信頼ゾーンはアカウントに設定されています。

したがって、「1. 管理アカウントのみアナライザーを作成」を採用する場合、管理アカウントを含む組織内の全アカウントで作成されたcm-access-analyzerを全リージョンで削除する必要があります。

全リージョンで削除するためのスクリプトを以下の記事で紹介していますので、ご参照ください。

通知方法

「1. 管理アカウントのみアナライザーを作成」においての通知方法を考えます。

IAM Access AnalyzerをSecurity Hub経由で通知する場合、集約リージョンでのみEventBridgeルールを作成することで、通知可能です。

通知先が以下のパターンによって、EventBridgeルールの数やEventBridgeルールのイベントパターンが異なります。

  • 通知先が同じ場合
  • メンバーアカウントごとに通知先が異なる場合

通知先が同じ場合

通知先が同じ場合は、EventBridgeルールは、以下の2つで済みます。

IAM ロール検知用とIAM ロール以外のリソース検知用の２つです。

IAM ロールは、検知のたびに全リージョンでイベントを発生させるため、IAM ロール検知用のEventBridgeルールは、1リージョンの通知のみ有効にする必要があります。

それぞれのEventBridgeルールのイベントパターン例は、以下の通りです。

IAM ロール検知用のEventBridgeルールのイベントパターン（リージョンは東京リージョンを指定。リソースはIAMロールを指定）

{
  "detail-type": ["Security Hub Findings - Imported"],
  "source": ["aws.securityhub"],
  "detail": {
    "findings": {
      "ProductName": ["IAM Access Analyzer"],
      "RecordState": ["ACTIVE"],
      "Region": ["ap-northeast-1"],
      "Workflow": {
        "Status": ["NEW"]
      },
      "Severity": {
        "Label": ["LOW", "MEDIUM", "HIGH", "CRITICAL"]
      },
      "Resources": {
        "Type": ["AwsIamRole"]
      }
    }
  }
}

IAM ロール以外のリソース検知用のEventBridgeルールのイベントパターン（リソースはIAMロール以外のリソース）

{
  "detail-type": ["Security Hub Findings - Imported"],
  "source": ["aws.securityhub"],
  "detail": {
    "findings": {
      "ProductName": ["IAM Access Analyzer"],
      "RecordState": ["ACTIVE"],
      "Workflow": {
        "Status": ["NEW"]
      },
      "Severity": {
        "Label": ["LOW", "MEDIUM", "HIGH", "CRITICAL"]
      },
      "Resources": {
        "Type": [{
          "anything-but": "AwsIamRole"
        }]
      }
    }
  }
}

EventBridgeルールのターゲットである通知方法は、SlackやTeams、Amazon SNS経由でメール通知が可能です。

通知先がメンバーアカウントごとに異なる場合

メンバーアカウントごとに、管理しているアカウント担当者が異なる場合、検知されたリソースを所有するアカウントごとに通知先を分ける必要があります。

その場合、以下の通り、メンバーアカウントごとに、EventBridgeルールを２つ作成する必要があります。

その際のEventBridgeルールのイベントパターン例は、以下の通りです。ResourceOwnerAccount(リソースを所有するAWSアカウントID)の値にアカウントIDを入れます。

IAM ロール検知用のEventBridgeルールのイベントパターン（リージョンは東京リージョンを指定。リソースはIAMロールを指定）

{
  "detail-type": ["Security Hub Findings - Imported"],
  "source": ["aws.securityhub"],
  "detail": {
    "findings": {
      "ProductName": ["IAM Access Analyzer"],
      "RecordState": ["ACTIVE"],
      "Region": ["ap-northeast-1"],
      "ProductFields": {
        "ResourceOwnerAccount": ["アカウントID"]
      },
      "Workflow": {
        "Status": ["NEW"]
      },
      "Severity": {
        "Label": ["LOW", "MEDIUM", "HIGH", "CRITICAL"]
      },
      "Resources": {
        "Type": ["AwsIamRole"]
      }
    }
  }
}

IAM ロール以外のリソース検知用のEventBridgeルールのイベントパターン（リソースはIAMロール以外のリソース）

{
  "detail-type": ["Security Hub Findings - Imported"],
  "source": ["aws.securityhub"],
  "detail": {
    "findings": {
      "ProductName": ["IAM Access Analyzer"],
      "RecordState": ["ACTIVE"],
      "ProductFields": {
        "ResourceOwnerAccount": ["アカウントID"]
      },
      "Workflow": {
        "Status": ["NEW"]
      },
      "Severity": {
        "Label": ["LOW", "MEDIUM", "HIGH", "CRITICAL"]
      },
      "Resources": {
        "Type": [{
          "anything-but": "AwsIamRole"
        }]
      }
    }
  }
}

通知先が同じであるメンバーアカウントが複数存在する場合、ResourceOwnerAccountに通知先が同じである複数のアカウントIDを指定することで、EventBridgeルールの数を減らすことができます。ただし、この方法はあまりおすすめしません。

担当者が変更した時や新規アカウント発行時、手動でアカウントIDの修正や追加の対応が必要になり、運用が複雑になるためです。

アカウントごとにEventBridgeルールを作成するCloudFormationテンプレートを作成し、新規アカウント発行時に、テンプレートでEventBridgeルールを作成するほうがシンプルだと考えます。

ただし、アカウントの増減や担当者の変更がない場合は、ResourceOwnerAccountに複数のアカウントIDを入れてEventBridgeルールの数を減らすのは有効な方法だと考えます。

IAM ロールの検知に対するアーカイブルールの利用

他の通知設定方法についても紹介します。

先ほど、「IAM ロールは、検知のたびに全リージョンでイベントを発生させるため、1リージョンの通知のみ有効にする必要がある」と説明しました。

通知はそれで問題ありませんが、Security Hub上では全リージョンの検知結果が出力されたままになってしまいます。

IAMロールの検出結果は1リージョンのみで十分なので、対策としては、1つのリージョンを除き全リージョンにアーカイブルールを作成し、アナライザーの検知結果をアーカイブする方法が考えられます。

以下の記事では、AWS CLIを使用して1つのリージョンを除いたアーカイブルールの作成方法がまとめられていますので、ご参照ください。

上記の方法で管理アカウント内でアーカイブルールを作成する場合、通知用のEventBridgeルールは1つで済みます。

通知先が同じ場合、EventBridgeルールのイベントパターンは以下になります。

{
  "detail-type": ["Security Hub Findings - Imported"],
  "source": ["aws.securityhub"],
  "detail": {
    "findings": {
      "ProductName": ["IAM Access Analyzer"],
      "RecordState": ["ACTIVE"],
      "Workflow": {
        "Status": ["NEW"]
      },
      "Severity": {
        "Label": ["LOW", "MEDIUM", "HIGH", "CRITICAL"]
      }
    }
  }
}

通知先がメンバーアカウントごとに異なる場合、EventBridgeルールのイベントパターンは以下になります。

{
  "detail-type": ["Security Hub Findings - Imported"],
  "source": ["aws.securityhub"],
  "detail": {
    "findings": {
      "ProductName": ["IAM Access Analyzer"],
      "RecordState": ["ACTIVE"],
      "ProductFields": {
        "ResourceOwnerAccount": ["アカウントID"]
      },
      "Workflow": {
        "Status": ["NEW"]
      },
      "Severity": {
        "Label": ["LOW", "MEDIUM", "HIGH", "CRITICAL"]
      }
    }
  }
}

通知用のEventBridgeルールは1つで済むメリットがありますが、この方法の考慮点は、新たなAWSリージョンが開設されたときに、管理アカウントで再度スクリプトの実行（削除と作成）が必要になることです。

そのため、EventBridgeルールを2つ利用する方法と比較して、それぞれにメリットとデメリットがあります。どちらを選択するかは、各々のニーズに合わせてご判断ください。

比較項目 EventBridgeルールを2つ利用 アーカイブルールを利用
EventBridgeルールの数 IAMロール用とIAMロール以外用の2つ 1つ
アーカイブルール 不要 1リージョンを除く全リージョンで作成(スクリプトでOK)
Security Hub上のIAMロールの結果の見え方 検知結果が全リージョン分表示 1リージョンの検知結果のみ表示
新リージョン対応 不要 スクリプトの実行（削除と作成）

それぞれのメリット・デメリットをまとめると以下のようになります。

  • EventBridgeルールを2つ利用する方法
    • メリット：運用がラク。
    • デメリット：IAMロールの検知結果が全リージョンで表示される。
  • アーカイブルールを利用する方法
    • メリット：EventBridgeルールが1つで済む。Security Hub上は、IAMロールの検知結果が1リージョンのみとなる。
    • デメリット：新リージョン対応時に管理アカウントでの再スクリプト実行が必要。

次章の「運用方法」では、EventBridgeルールを2つ利用する方法を採用した前提で解説します。

運用方法

「1. 管理アカウントのみアナライザーを作成」の運用において、以下の2点を考えます。

  • 通知後の対応
  • 新規アカウント発行時

通知後の対応

通知方法は「通知先がメンバーアカウントごとに異なる場合」を想定しています。

アナライザー検知時の対応の流れは以下のようになります。

登場人物は、メンバーアカウントの担当者と管理アカウントの管理者です。

  1. メンバーアカウントの担当者に検知の通知が送信され、担当者が通知内容を確認します。必要に応じて、リソースアカウントにログインしリソースを確認します。
  2. 担当者が問題がないと判断した場合
    • 管理者に相談し、管理者が管理アカウントのアナライザーに対して「アーカイブ」のステータスに変更し、必要に応じてアーカイブルールを作成します。
  3. 担当者が問題があると判断した場合
    • 担当者がリソースを修正します。
      • リソースを修正すると、再度アナライザーがリソースをスキャンし、問題が解決されている場合はステータスが自動で「解決済み」に変更されます。修正後も問題が残る場合は、再度検出され通知されます。挙動の詳細はAWSドキュメントをご参照ください。

通知方法が「通知先が同じ場合」であれば、管理アカウントの管理者が上記の対応をするだけです。

新規アカウント発行時

通知方法は「通知先がメンバーアカウントごとに異なる場合」を想定しています。

事前に、以下が作成されるCloudFormationテンプレートを用意します。

  • IAM ロール検知用とIAM ロール以外のリソース検知用のEventBridgeルール
  • EventBridgeルールのターゲットとなる通知用のリソース（メール送信の場合、Amazon SNSなど）

組織内で新規アカウントを発行後、管理アカウントでCloudFormationテンプレートをデプロイすることで、通知の仕組みを即導入できます。

新規アカウントは、組織内に入ると、自動で管理アカウントのアナライザーの分析対象となるため、アナライザーの設定変更は不要です。

通知方法が「通知先が同じ場合」であれば、新規アカウント発行時の対応は不要です。

最後に

本記事では、マルチアカウント環境におけるIAM Access Analyzerの構成、通知方法、運用について、私なりの考えをまとめました。

IAM Access Analyzerを適切に活用することで、意図しない外部アクセスを検知し、セキュリティリスクを軽減することができます。

ただし、本ブログで提案した内容はあくまでも一例です。組織の状況に合わせて、柔軟にアレンジしてください。

参考

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/what-is-access-analyzer.html

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access-analyzer-securityhub-integration.html

https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-internal-providers.html

AWS

関連記事

[オフライン世界最速？AWS re:Inforce 2024 re:Cap セミナー] 『IAM Access Analyzer のアップデートを語ります』というタイトルで登壇しました。#AWSreInforce

平木佳介

2024.06.19

[アップデード]IAM Access Analyzerのカスタムポリシーチェックでパブリックアクセスと重要リソースアクセスのチェックが追加されました！ #AWSreInforce

臼田佳祐

2024.06.16

[レポート] ワークショップ – GitHub Actionsを使ったIAMポリシーの検証と分析の自動化 #IAM452 #AWSreInforce

あしざわ

2024.06.14

[速報] IAM Access Analyzer が 未使用の IAM プリンシパルに対する推奨事項をプレビューで表示するようになりました #AWSreInforce

たかくに

2024.06.11