Central LoggingとEvent Notification

1. レコードプレーンとイベントプレーンを分ける

ログを保存したことと即時通知できることは別です。イベント通知だけでも長期監査レコードの代わりにはなりません。

2. ログアーカイブと運用アカウントの責任を分離する

ワークロードアカウント
   │
   ├─ 監査記録 ─────→ 専用ログアーカイブ
   │
   └─ 運用上のイベント → 運用アカウント

ログアーカイブは証拠保全と調査、運用アカウントはイベントフィルター・通知・自動化を担当します。職務分離や運用所有責任が異なる場合、責任をアカウント単位で分けるとガバナンスを明確にできます。

3. 中央ログ記録は監査ベースラインとして利用する

マルチアカウント環境では組織証跡などを使って必要なCloudTrail監査イベントを中央ログアーカイブへ保存し、アカウント追加時にも監査ベースラインが外れにくい構成にします。

AWS Organizations
      ↓
組織の証跡
      ↓
専用ログアーカイブ

中央ログ記録側の目的は長期保存・改ざん耐性・調査可能性です。日常の通知ワークフローをログアーカイブに詰め込む必要はありません。

組織の証跡は、Organizationsの管理アカウントまたはCloudTrailの委任管理者から作成・管理できます。日常のCloudTrail管理を専用メンバーアカウントへ委任しても、組織のCloudTrailリソースの所有者は管理アカウントのままです。管理アカウントの日常利用を減らしつつ、中央監査の運用責任を分離できます。

4. イベントプレーンは各アカウントのEventBridgeから始まる

多くのAWSサービスイベントは、そのイベントを生成したアカウントのデフォルトイベントバスへ送られます。マルチアカウントで中央処理したい場合は、送信元アカウントのルールから運用アカウントの中央イベントバスへルーティングします。

アカウント A ─┐
アカウント B ─┼─→ 運用アカウント / 中央イベントバス
アカウント C ─┘

中央化の目的は、イベントを1か所へ集めること自体ではなく、通知・自動化・インシデントワークフローを一貫して適用することです。

5. 送信元側で中央処理が必要なイベントだけフィルターする

全アカウントの全イベントを無条件に転送すると、ノイズ・コスト・ルール複雑さが増えます。送信元側EventBridgeルールで、送信元 / 詳細タイプ / 重要度 / リソース / アカウントなどを使って中央処理対象を絞ります。

重要 / 高
→ 中央運用

情報
→ ローカル処理

6. クロスアカウントイベントバスは受信側ポリシーと送信側ロールを見る

別アカウントのイベントバスへイベントを送る場合、受信側イベントバスにはリソースベースのポリシーで送信を許可します。送信側ではルールの対象として中央イベントバスを指定し、EventBridgeが利用するIAMロールを構成します。

送信元イベントバス
  ルール + IAMロール
        ↓
中央イベントバス
  リソースポリシー

「中央イベントバスを作っただけ」でクロスアカウントルーティングが成立するわけではありません。

7. 組織単位の許可はaws:PrincipalOrgIDで絞る

同一AWS Organizations内の多数アカウントから中央イベントバスへ送信させる場合、受信側イベントバスポリシーでアカウントIDを大量列挙する代わりに、条件でaws:PrincipalOrgIDを使用できます。

中央イベントバスポリシー
Condition:
aws:PrincipalOrgID = o-xxxxxxxxxx

組織境界を使うことで、アカウント増減に対するポリシー保守を減らせます。

8. 中央イベントバスではワークフローごとに再フィルターする

送信元側では「中央へ送るべきか」を判断し、運用アカウント側では「どのワークフローへ送るか」を判断します。

中央イベントバス
├─ 重要セキュリティ → インシデントワークフロー
├─ 運用上の障害 → 運用キュー
└─ コンプライアンスイベント → チケット / 自動化

収集条件と対応ルーティングを分けることで、ルール責任を整理できます。

9. ネイティブマルチアカウント集約があるなら再利用する

セキュリティサービスによっては管理者 / 委任管理者アカウントへメンバーアカウントの検出結果がすでに集約されています。その場合、各メンバーアカウントから同じ検出結果を再転送する前に、集約先アカウントのEventBridgeをイベント送信元として利用できないか確認します。

メンバー検出結果
↓ サービスネイティブ集約
セキュリティ管理者アカウント
↓ EventBridge
運用ワークフロー

同じシグナルを複数経路で中央化すると重複通知の原因になります。

10. 単純な通知ならクロスアカウントサービス対象も評価する

中央イベントバスで再分類する必要がなく、送信元アカウントから別アカウントの特定対象へ直接届けたい場合、EventBridgeのクロスアカウントサービス対象を評価できます。

現行仕様では同一リージョンで、次の対象が対応しています。

• Amazon API Gateway
• Amazon Kinesis Data Streams
• AWS Lambda
• Amazon SNS
• Amazon SQS

この方式では、送信側に実行ロール、対象側にリソースポリシーが必要です。

11. イベントバスの多段中継を前提にしない

EventBridgeでは、別イベントバスから受信したイベントをルールでさらに第三のイベントバスへ送る多段中継はできません。

誤った前提
アカウントAのイベントバス → アカウントBのイベントバス → アカウントCのイベントバス

基本
送信元アカウント → 最終中央イベントバス → 処理対象

中央化では送信元から最終中央イベントバスへ直接送る1ホップ構成を基本にします。

12. イベントでインシデントを開始し、ログで事実を調査する

イベントプレーンとレコードプレーンは分離しますが、インシデント対応では連携します。

重要イベント
↓
通知 / インシデント開始
↓
ログアーカイブのCloudTrailレコードを確認
↓
誰が・いつ・何を変更したか調査

イベントは対応を開始するシグナル、ログは事実を確認するレコードという役割分担です。

13. 障害モード

中央ログを保存すれば即時通知も成立すると思う

長期保存とイベントルーティングは別パイプラインです。

すべてのイベントを中央へ送る

送信元側で中央処理が必要なイベントをフィルターします。

中央イベントバスを作ればクロスアカウント送信できると思う

受信イベントバス リソースポリシーと送信側ルール / IAMロールを確認します。

サービスネイティブ集約済みの検出結果を各メンバーから再送する

集約先アカウントをイベント送信元にできないか先に評価します。

イベントバスを何段でも中継できると思う

受信イベントを別のイベントバスへ中継する構成は前提にしません。

14. SAP-C02判断フロー

マルチアカウント環境
        │
        ├─ 後から調査するレコード？
        │      ↓
        │   中央ログアーカイブ
        │
        └─ 今すぐ対応するイベント？
               ↓
          送信元のEventBridge
               ↓
       中央処理が必要なイベントだけフィルター
               ↓
      中央イベントバスが必要？
        ┌──────┴──────┐
        │             │
       はい      いいえ
        │             │
 中央イベントバス  直接クロスアカウント対象
        │             │
        ▼             ▼
 通知 / 自動化
        │
        ▼
 インシデント発生時はログアーカイブで調査

15. まとめ

マルチアカウントガバナンスでは、レコードプレーンとイベントプレーンを分けて中央化します。

レコードプレーン
組織の証跡 → ログアーカイブ

イベントプレーン
送信元のEventBridge → 中央運用 → 通知 / 自動化

クロスアカウントイベントバスでは受信イベントバスのリソースポリシー + 送信側ルール / IAMロールを確認し、組織単位の許可にはaws:PrincipalOrgIDを利用できます。

中央イベントバスで再分類が不要なら、同一リージョンの対応AWSサービスへ直接クロスアカウント受け渡しする設計も候補です。イベントはインシデントを開始し、ログアーカイブはその後の事実確認に使います。

16. 主要AWS公式資料

• AWS CloudTrail — 組織の証跡
• AWS CloudTrail — セキュリティのベストプラクティス
• Amazon EventBridge — AWSアカウント間でのイベント送受信
• Amazon EventBridge — イベントバスのアクセス許可
• Amazon EventBridge — 別アカウントのAWSサービスへのイベント送信
• AWS Security Hub — EventBridgeイベントタイプ
• Amazon GuardDuty — EventBridgeによる検出結果の処理