【小ネタ】 Amazon Detective を Organizations 統合でセットアップしたらちょっと躓いた話

クラウド事業本部 コンサルティング部のいたくらです。

はじめに

新規 Organization 環境で Amazon Detective を Audit アカウント委任構成でセットアップする機会がありました。基本的にはドキュメント通りに進めれば問題なく動くサービスなのですが、ちょっと躓いた箇所が 2 つあったので共有します。

• メンバーアカウントの 1 つが ACCEPTED_BUT_DISABLED 状態のまま停滞してしまう
• 大阪リージョン（ap-northeast-3）でエンドポイント接続エラーが出る

「Detective を Organizations 統合構成でセットアップしたら同じところで詰まった」という方の参考になれば幸いです。

三行まとめ

• メンバーアカウントが ACCEPTED_BUT_DISABLED で止まったら、委任管理者から start-monitoring-member を明示的に叩くと ENABLED に遷移します
• Amazon Detective は大阪リージョン（ap-northeast-3）で非サポートなので、対象リージョンから除外する必要があります
• Detective は GuardDuty / Security Hub の検出結果をデータソースとして使うため、事前にこれらの有効化が必要です

前提

• 委任管理者: Audit アカウント
• 対象リージョン: 東京（ap-northeast-1）/ バージニア北部（us-east-1）/ オレゴン（us-west-2）
  • もともとは大阪（ap-northeast-3）も含めて 4 リージョンを想定していましたが、後述の理由で大阪は除外しました
• メンバー数: 3 アカウント（管理 / LogArchive / メンバー）
  • 委任管理者の Audit アカウント自体もビヘイビアグラフに参加するため、合計 4 アカウント構成
• AutoEnable: true（新規アカウントを自動的に Detective に組み込む設定）
• GuardDuty は事前に組織全体で有効化済み
  • Detective は GuardDuty / Security Hub の検出結果をデータソースとして利用するため、先行して有効化されている必要があります

やってみた

1. 通常のセットアップフロー

まずは委任管理者（Audit アカウント）で以下のコマンドを実行しました。

# Audit アカウントで実行
aws detective create-graph --region ap-northeast-1

aws detective update-organization-configuration \
  --graph-arn ${GRAPH_ARN} \
  --auto-enable \
  --region ap-northeast-1

# 既存メンバーを登録
aws detective create-members \
  --graph-arn ${GRAPH_ARN} \
  --accounts "file://members.json" \
  --region ap-northeast-1

members.json は Organizations のメンバー一覧から動的に生成しています（Audit アカウント自身は委任管理者なので除外）。

aws organizations list-accounts \
  --query "Accounts[?Status=='ACTIVE' && Id!='${AUDIT_ACCOUNT_ID}'].{AccountId:Id,EmailAddress:Email}" \
  --output json > members.json

ここまでは特にエラーも出ず、順調に進んだように見えました。

2. 躓きポイント その 1: メンバーアカウントが ACCEPTED_BUT_DISABLED で停滞

しばらく経ってからメンバーの状態を確認すると、メンバーアカウントだけ Status が ACCEPTED_BUT_DISABLED で止まっていました。

+----------------+-------------------------+----------------+---------------------+
|  AccountId     |  Status                 |  DisabledReason|  VolumeUsageInBytes |
+----------------+-------------------------+----------------+---------------------+
|  Audit ID      |  ENABLED                |  None          |  3405200            |
|  管理 ID       |  ENABLED                |  None          |  None               |
|  LogArchive ID |  ENABLED                |  None          |  None               |
|  メンバー ID   |  ACCEPTED_BUT_DISABLED  |  None          |  None               |
+----------------+-------------------------+----------------+---------------------+

DisabledReason が None のため、コンソールや CLI 上では何が原因で止まっているのか分かりません。

公式ドキュメントの MemberDetail には次のように書かれています。

The account accepted the invitation, or was enabled by the Detective administrator account, but is prevented from contributing data to the behavior graph.

ざっくり訳すと「招待は受諾されているが、ビヘイビアグラフへのデータ寄与が阻止されている」状態とのことです。要するに「メンバーアカウントとしての登録自体は終わっているが、データの取り込みが始まっていない」ということですね。

解決策: start-monitoring-member を叩く

委任管理者から start-monitoring-member API を呼ぶことで、ENABLED に遷移できました。

aws detective start-monitoring-member \
  --graph-arn ${GRAPH_ARN} \
  --account-id <メンバーアカウントID> \
  --region ap-northeast-1

実行直後に Status が ENABLED に変わりました。

なぜ自動有効化（AutoEnable）が効かなかったのかは特定できませんでしたが、複数のメンバーアカウントを一括で create-members した際にタイミング依存で発生する可能性がありそうです。再現性が取れなかったため、本記事では「もし発生したらこのコマンドで復旧できる」というナレッジとしてまとめます。

3. 躓きポイント その 2: 大阪リージョン非サポート

続いて、東京リージョンで動作確認できたスクリプトをそのまま大阪リージョン（ap-northeast-3）で実行したところ、以下のエラーで失敗しました。

aws: [ERROR]: Could not connect to the endpoint URL:
"https://api.detective.ap-northeast-3.amazonaws.com/graph"

エンドポイントへの接続自体ができていない、つまりサービスがそのリージョンに存在しないというエラーです。

原因: Detective は大阪リージョン非対応

ここで「あっ」となりました。Amazon Detective は AWS の全リージョンで利用できるわけではなく、現時点で 大阪リージョン（ap-northeast-3）は非サポート です。普段触っている Security Hub や GuardDuty は大阪でも利用できるため、Detective も同じ感覚で対象に含めてしまっていました。完全にうっかりです。

公式のリージョン一覧は Detective Endpoints and quotas にまとめられています。今回検討対象だったリージョンの状況は以下の通りです。

解決策: 対象リージョンから大阪を除外する

スクリプトの実行対象リージョンから大阪を除外して、3 リージョン構成に変更しました。

DETECTIVE_REGIONS=("ap-northeast-1" "us-east-1" "us-west-2")

for REGION in "${DETECTIVE_REGIONS[@]}"; do
  # 前述の create-graph / update-organization-configuration / create-members を実行
done

設計上の影響

地味ですが、設計面での影響もあります。

• Security Hub / GuardDuty / IAM Access Analyzer などのセキュリティ系サービスは、東京・大阪・バージニア北部・オレゴンの 4 リージョンで利用できることが多いです
• 一方、Detective は大阪が外れるため、他のセキュリティサービスとリージョン構成が揃わないケースが出てきます
• 大阪リージョンで発生したセキュリティイベントは、GuardDuty や Security Hub では検出できますが、Detective による相関分析は対象外になります

「全サービスを 4 リージョン横並びで有効化」という設計を素朴にやると、Detective だけ違和感が出てしまうため、設計時点で意識しておくとよさそうです。

補足: Detective を有効化する前に必要なこと

Detective は GuardDuty と Security Hub の findings をデータソースとして使います。事前に以下を整えておく必要があります。

• 同一リージョンで GuardDuty が有効化されていること（組織のメンバーとして）
• Security Hub も推奨（必須ではないが、相関分析の幅が広がる）

特に GuardDuty の組織加入が完了していないと、Detective の create-members 自体が失敗するケースもあるので、サービス間の依存関係には注意が必要です。

まとめ

今回の躓きポイント 2 点と対処を整理します。

参考ドキュメント

• What is Amazon Detective? - Amazon Detective
• Amazon Detective endpoints and quotas - AWS General Reference
• StartMonitoringMember - Amazon Detective
• MemberDetail - Amazon Detective

さいごに

Amazon Detective を Organizations 統合でセットアップした際の、ちょっとした躓きポイントを共有しました。

ACCEPTED_BUT_DISABLED は DisabledReason が出ないため気づきにくく、大阪リージョン非サポートも「他のセキュリティサービスは使えるから」と思い込んでいると見落としがちです。同じ構成を組まれる方は、ぜひ事前に押さえておいていただけるとスムーズかと思います。

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