Slide 1

Slide 1 text

2026/04/23 JAWS-UG東京 ランチタイムLT会 #34 Control Tower LZ 4.0 環境で⾒えた CT 作成管理 SNS と EventBridge のいま

Slide 2

Slide 2 text

AWS Control Tower とは 2 ● AWS 上でマルチアカウント環境を安全かつ効率的に構築‧管理するための マネージドサービス ● 主な機能 ○ ベースライン適⽤(アカウント作成時の設定⾃動化) ○ コントロール (SCP / Config Rules / CFn hook 等による予防‧検知‧プロアクティブ) ○ ドリフト検知 (CT が管理する設定が意図せず変更されたことを検出) ● 2025 年に LZ 4.0 がリリース。ひとつ前は LZ 3.3 ※AWS Black Belt Online Seminar AWS Control Tower 基礎編 より引用

Slide 3

Slide 3 text

なぜ今⽇は SNS と EventBridge の話? 3 ● CT の「ドリフト検知」は 検知するだけ でなく 通知を送る仕組み とセット ● LZ 3.3 までの通知経路 ○ CT → SNS トピック(CT ⾃動作成)→ サブスクライバー(購読は⼿動設 定) ● LZ 4.0 からの通知経路 ○ CT → EventBridge にシフト(公式) ● アップグレード後、既存の SNS はどうなる?EventBridge に流れるドリフ ト通知はどこで受け取る? → これを検証環境で確かめたのが今⽇の話

Slide 4

Slide 4 text

前提: LZ 4.0 移⾏ガイドによる主な変更点 4 公式ドキュメント Key changes in landing zone v4.0 からの引⽤ AWS Control Tower will stop sending drift notifications to SNS topic for all customers on landing zone 4.0 without the AWSControlTowerBaseline enabled, and will start sending drift notifications to EventBridge in the management account instead. 機械翻訳 ドリフト通知: AWS Control Tower は、AWSControlTowerBaseline が有効になっていな いランディングゾーン 4.0 上のすべてのお客様に対して、SNS トピックへのドリフト通知 の送信を停⽌し、代わりに管理アカウントの EventBridge にドリフト通知の送信を開始 します。 ● 要約すると「ドリフト通知は SNS → EventBridge(管理アカウント) に移 る」ってことか?🤔 ● 「SNS はもう使わないのかな?」「管理アカウントに EventBridge 関連のリ ソースができるってことかな?」と思いませんか?

Slide 5

Slide 5 text

検証環境で⾒てみた 5 LZ 3.3 から LZ 4.0 へアップグレードした結果、 実際の挙動は⾃分が考えていたのと少し違った

Slide 6

Slide 6 text

発⾒ ① : SNS トピックは消えていない 6 アップグレード後の Audit アカウント ● aws-controltower-SecurityNotifications → 残存 ● aws-controltower-AggregateSecurityNotifications → 残存 ● aws-controltower-AllConfigNotifications → 残存 アップグレード後の Log Archive アカウント ● aws-controltower-SecurityNotifications → 残存 ● aws-controltower-CentralizedLoggingNotifications → 新規追加 Audit Topic × 3 Log Archive Topic Topic NEW

Slide 7

Slide 7 text

発⾒ ② : EventBridge は SNS の 前段 に⼊る 7 Before (LZ 3.3): Config イベント → SNS → 既存サブスクライバー After (LZ 4.0): Config イベント → EventBridge ルール → SNS → 既存サブスクライバー ● EventBridge が SNS を 置き換えた のではなく ルーティング層として前段に挟まった ● 既存の SNS サブスクライバー(メール通知、Lambda 等)は 引き続き動作する ● アップグレード後の既存運⽤への影響が⼩さい設計 Topic Rule Event Email Lambda function Config NEW

Slide 8

Slide 8 text

発⾒ ③ : EventBridge ルールは統合アカウントに置かれる 8 Audit / Log Archive に同じ 2 種のルールが作成される ● AWSControlTowerManagedRule ● aws-controltower-ConfigComplianceChangeEventRule 管理アカウントには CT 関連 EventBridge ルールは追加されない ● 公式⽂章の「EventBridge in the management account」は ドリフト通知の送 信先 を指しているのであって、ルールが管理アカウントに作られる という意味 ではない ● ドリフト通知を受け取りたい場合、管理アカウントにルールを ⾃分で作成する

Slide 9

Slide 9 text

発⾒ ④ : ルールを作るまで誰も拾ってくれない 9 アップグレード直後の管理アカウント ● CT 関連の⾃動作成 EventBridge ルール: なし ● でも、CT のドリフトは発⽣しうる ● じゃあ、そのドリフト通知はどこへ? Control Tower ドリフト発⽣ Event Rule ドリフト通知はどこへ…?

Slide 10

Slide 10 text

EventBridge の基本挙動 10 ● EventBridge 対応の AWS サービスがイベントを発⽣させると、動作してい るアカウントの default event bus に配信される ● ルールがマッチしなければ、イベントは 拾われずに消える ● 「通知が来ない」≠「イベントが発⾏されていない」 つまり イベントは流れているが、拾うルールがない という状況があり得る Control Tower ドリフト発⽣ Event ルールが無いので拾われずに消える!

Slide 11

Slide 11 text

検証: 管理アカウントにルールを⾃作 11 作成したルール ● 配置先: 管理アカウント / default event bus ● ターゲット: CloudWatch Logs(イベントの中⾝を確認するため) イベントパターン { "source": ["aws.controltower"], "detail-type": ["Drift Detected"] }

Slide 12

Slide 12 text

検証: 管理アカウントにルールを⾃作 12 届いたイベント(抜粋) { "detail-type": "Drift Detected", "source": "aws.controltower", "account": "111122223333", "time": "2026-04-22T14:30:12Z", "region": "ap-northeast-1", "detail": { "driftType": "ACCOUNT_MOVED_BETWEEN_OUS", "accountId": "444455556666", "sourceId": "ou-xxxx-workload", "destinationId": "ou-xxxx-default", "remediationStep": "..." } } → default event bus にドリフトイベントが流れていた証拠

Slide 13

Slide 13 text

統合アカウントの⾃動作成ルールは別物 13 発⾒③で確認した 2 つの⾃動作成ルール ● AWSControlTowerManagedRule: Security Hub Findings を CT サービスへルーティング ● aws-controltower-ConfigComplianceChangeEventRule: Config Rule のコンプライアンス変化を SNS へルーティング いずれも CT ドリフト⽤ではない。 ⽤途が違うだけで、CT ドリフトが「来ていない」わけではない → ドリフト通知を拾う仕組みは ユーザー側で⽤意する必要がある

Slide 14

Slide 14 text

おまけ: OU 移動でもドリフトにならないケース 14 検証中に気づいた点 ● CT 登録済み OU 間の移動は ドリフトにならない ● CT 登録済み OU → CT 未登録 OUへの移動 ドリフトになる ○ ドリフト種別 ACCOUNT_MOVED_BETWEEN_OUS は 「CT 管理階層を跨いだ移動」で検出される

Slide 15

Slide 15 text

なぜ EventBridge を挟んだのか(考察) 15 ① AWS 各サービスのイベント発⾏パターンとの⼀貫性 ● GuardDuty / Security Hub / Config は 2019 年頃には EventBridge 対応済み ● CT は LZ 4.0(2025 年)で 対応 ● 横断的な⾃動化がやりやすくなり、他サービスと同じ要領で扱えるようになった ② ルーティング‧フィルタリングの柔軟性 ● SNS: サブスクライバーは全部受け取る(細かいフィルタは購読側で実装) ● EventBridge: イベントパターンで送信前に絞れる、複数ターゲットに分岐可能 ● 例: ドリフトは Lambda、コンプラ違反は SNS、他は CloudWatch Logs …と使い 分けできる ※ AWS の公式⾒解ではなく、検証環境での観察からの考察です

Slide 16

Slide 16 text

まとめ: LZ 4.0 の CT 作成管理 SNS と EventBridge のいま 16 ● 「SNS → EventBridge」は単純な置換ではなく、SNS はそのまま、前段に EventBridge が追加された ● 既存の SNS サブスクライバーは そのまま動き続ける ● CT ⾃動作成 EventBridge ルールは Audit / Log Archive にある ● 管理アカウントでドリフト通知を拾うには ルールをユーザー側で作成する 必要がある ○ CT に限らず、管理アカウントのあらゆる AWS サービスのイベントが同じ

Slide 17

Slide 17 text

No content