マルチアカウント環境の野良スイッチロールを検出する

はじめに

こんにちは、Hibikiです。
マルチアカウント環境を設計する際に躓いたポイントがあったため、紹介したいと思います。

マルチアカウント環境ではIAM Identity Center(IIC)による権限の統合管理が一般的です。一方で、IAMロールは多くのサービスで最小権限のために都度作成することも多く、IAMロールの作成を制限することは難しいと思います。

しかし、IIC管理外のクロスアカウントスイッチロールは、アクセス権限管理の観点から禁止もしくは検出する必要があります。

本記事では、IAM Access Analyzerを使ってOrganization内のスイッチロールを検出する方法をご説明します。

構成紹介

前提知識：IAM Access Analyzerの信頼ゾーン

IAM Access Analyzerには信頼ゾーンの設定により2つの分析方法があります。

• 組織

  • 信頼ゾーン：Organizations全体
  • 検出対象：Organizations外部からのアクセス
  • Organizations内のアカウントは「信頼済み」として扱われるため、Organizations内アカウント同士のアクセスは検出されない

• アカウント

  • 信頼ゾーン：個別のアカウント
  • 検出対象：自アカウント以外のすべてのアクセス
  • 同一Organization内アカウント同士のアクセスも検出する

以上から、本構成では信頼ゾーンをアカウントとして利用していきます。

アーキテクチャ

CloudFormation StackSetsを利用して、各アカウントにIAM Access Analyzerとアーカイブルール(※)をデプロイします。

※アーカイブルール：検出される結果の内、正当なアクセスはアーカイブとすることで検出結果から除外することができます。除外条件をアーカイブルールとして記述します。

各AnalyzerがリソースをスキャンしてFindingsという検出結果をSecurity Hubに送信することで、委任管理者アカウントで一元確認できます。

アーカイブルールとしては、以下を設定します(実際の環境に合わせてください)

• IAMロール以外
  • IAM Access Analyzerはバケットポリシーなども検出します
  • スイッチロールの検出が目的のため、IAMロール以外は検出しないようにします
• IIC管理下のロール(AWSReservedSSO_*)
  • IICのアクセスも実態としてはIAMロールを作成しアクセスするため、正当なロールとして除外します
  • IICで作成されるロールは全て同じ接頭辞から始まるため、IICの命名規則を活用して除外します
  • AWSReservedSSO_*から始まるIAMロールはIIC以外からは作成できないのでバイパスにはなりません
• Organizations特定のアカウント
  • Organizations内で特別な役割を持つアカウント(管理アカウントや監査アカウント)からのアクセスを正当なものとします
  • ベストはIAMロールを直接指定することですが、StackSetsやControl Tower、SecurityHubなど多岐にわたるクロスアカウントのサービスを利用している場合指定が困難なため、アカウント全体を指定します
  • IAMロールの信頼ポリシーに特定のアカウントを含めたうえで他のアカウントも追加する場合、正しく検出されるのでバイパスにはならないことは検証済みです

また、デプロイするリージョンは一つとしています。IAM Access Analyzer自体はリージョンごとに作成するサービスですがIAMはリージョンがないサービスなので、どのリージョンでデプロイしてもIAMロールを検査できます。

(余談)なぜIAM Access Analyzerなのか

SCPやRCPでは防げない

Service Control Policy (SCP)のiam:CreateRoleで作成を禁止すればよいのでは？と思われるかもしれません。しかし、SCPではIAMロールの信頼ポリシーの内容で制御できません。そのため、SCPで禁止することはできません。

SCP はリソースベースのポリシーには直接影響しません。

Resource Control Policy (RCP)なら信頼ポリシー(=リソースベースポリシー)で制御できるのではという気もしますが、IAMロールはRCPの対象外のため、RCPでも禁止することはできません。

Configカスタムルールとの比較

管理外のスイッチロールを検出する方法として、Configカスタムルールもあると思います。(デフォルトのConfigルールにはスイッチロール検出がないため)

以下の通り、Lambdaの実装・管理の観点からIAM Access Analyzerを採用しています。
Configカスタムルールで設定できる自動修復機能については、IAMロールの削除は影響が大きいため検出(必要に応じて通知)ができればよいという考えで、今回はメリットにならないと判断しています。

• Config カスタムルール
  • Lambda関数の実装・管理が必要
  • ランタイムのEOL対応やセキュリティパッチ管理が必要
  • 実行に費用発生
  • 自動修復機能あり
• IAM Access Analyzer
  • マネージドサービスなので、CloudFormationテンプレートの管理だけでOK
  • 本構成で使用する外部アクセス分析は無料

実装してみる

マルチアカウント構成として以下は実装済みとしています。

• AWS Organizationsが設定済み
• IAM Identity Centerが設定済み
• Security Hub委任管理者アカウントが設定済み
• CloudFormation StackSets委任管理者アカウントが設定済み

1. CloudFormationテンプレートの作成

Account Analyzerとアーカイブルールを定義するCloudFormationテンプレートを作成します。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'IAM Access Analyzer for cross-account switch role detection'

Parameters:
  TrustedAccountIds:
    Type: CommaDelimitedList
    Description: "Comma-separated list of trusted account IDs"
    Default: "xxxxxxxxxxxx,yyyyyyyyyyyy"

Resources:
  AccountAnalyzer:
    Type: AWS::AccessAnalyzer::Analyzer
    Properties:
      AnalyzerName: CrossAccountSwitchRoleDetection
      Type: ACCOUNT
      ArchiveRules:
        - RuleName: exclude-non-iam-roles
          Filter:
            - Property: resourceType
              Neq: ['AWS::IAM::Role']
        - RuleName: exclude-identity-center
          Filter:
            - Property: resource
              Contains: ['AWSReservedSSO_']
        - RuleName: exclude-trusted-accounts
          Filter:
            - Property: principal.AWS
              Contains: !Ref TrustedAccountIds

TrustedAccountIdsの値は、ご自身の管理アカウントIDや監査アカウントIDなどにに置き換えてください

2. StackSetsでのデプロイ

作成したテンプレートをStackSetsで組織全体にデプロイします。

以下の点に注意して実行します。

• アクセス許可モデル：サービスマネージドアクセス許可
• デプロイターゲット：対象OU
• 自動デプロイ：アクティブ

3. Security Hub結果確認

各アカウントのIAM Access Analyzer Findingsは自動的にSecurity Hubに送信されるので結果を確認します。

まずは個別アカウントのIAM Access Analyzerが正しく動作しているか見てみます。

検出結果ですが、別アカウントをプリンシパルに指定しているIAMロールを検出できています。

アーカイブされたリソースも確認できるので見てみると、管理アカウントからのアクセスロール(IIC用ロール、StackSets用ロール等)が正しくアーカイブされています。

最後に委任アカウントのSecurity Hubから確認します。
フィルターを製品名：IAM Access Analyzerとして確認すると、検出できていることを確認できました。

(おまけ)運用上の考慮事項

ご紹介した構成ではCloudFormation StackSetsにてIAM Access Analyzerとアーカイブルールを管理しています。IaCの観点からアーカイブルールを更新する際はCloudFormationテンプレートで更新を書ける必要があります。
アーカイブルールの更新方法は以下の流れがあるかなと思ってます。

• 不要な検出結果はマネコン上の各検出結果からアーカイブに設定
  [ここにキャプチャ]
• アーカイブにするIAMロールの共通点が見えてきたタイミングでCloudFormation StackSetsを更新
• テスト用アカウントから試して、段階的に更新する

まとめ

本記事ではIAM Access Analyzerを使用して、Organizations内でのスイッチロールを検出する方法ご紹介しました。
ユースケースとしてはあるあるかなと思いましたが、調べても実装例は出てこなかったので誰かの助けになれば幸いです。
CloudFormation StackSetsなんて使わずにもっと楽に実装できたらいいのに。。。と思ってます。