各リージョンで有効化したGuardDutyの検出結果を管理者に通知する

TECH記事

こんにちは。ダントーです。

今回は、セキュリティ施策のために東京リージョン以外の各リージョンでGuardDurtyを有効化したけど検出結果をどうやって管理者に通知するかで悩んでいる方向けの記事です。

簡素ではありますが、いくつかある選択肢を比較考量していく中で自分の環境に最適な構成を選ぶ材料となれば幸いです。

では、いきましょう。

想定検索ワード：GuardDuty 検出結果 通知 東京リージョン以外

TL;DR;

1. 可能なオプションについて考える

まずは各リージョンの検出結果を管理者に通知するにあたって、どのようなオプションが可能なのか考えていきます。

① 各リージョンにEventBridgeルールとSNSトピックを作成する

簡単な構成図を書くとこのようになります。

かなり愚直な選択肢ではありますが、構成上の統一感という意味ではこの選択肢も悪くないのかもしれません。

しかし各リージョンにEventBridgeルールやSNSトピックを作る必要があり、またSNSトピックについては都度サブスクライブを行わなくてはいけない点はデメリットとなります。

加えて、検出結果をフィルタリング&整形しようとすると各リージョンのEventBridgeルールに同一設定を入れなくてはいけない点もやや微妙と言えるでしょう。

まとめると…

メリット

  • 構成上の統一感あり
  • 構築自体の難易度は低め(同一設定の繰り返しとなるためとっつきやすい)

デメリット

  • SNSを各リージョンごとにサブスクライブしなくてはいけない
  • リソースの作成が冗長的になる(同一リソース・同一設定の繰り返しとなるため)

② 東京リージョンCustom event busで集約する

先ほどの①のパターンから東京リージョン以外のSNSトピックを削除します。

つまり、全リージョンの検出結果を一度東京リージョンに集約し、東京リージョンのSNSトピックから管理者に通知を行います。

構成図としては以下のようになります。

フローとしては、全リージョン(東京リージョンを含む)での検出結果を東京リージョンのカスタムイベントバスに送信し、カスタムイベントバスに紐づけたルールでファイルタリング&整形を行います。

①と比較すると、東京リージョン以外ではSNSトピックが無くなり、東京リージョンではカスタムイベントバスとフィルタリングルールが増えています。

つまり各リージョンでサブスクライブする必要が無くなった一方で、東京リージョンでは検出結果を集約するカスタムイベントバスとフィルタリング&整形用のルールを作成する必要が生じているということです。

まとめると…

メリット

  • 東京リージョン以外でSNSトピックを作成する必要がない
  • フィルタリング&整形用の同一設定を入れなくて済む

デメリット

  • 構築難易度は低くはない(①と比較してですが)

③ AWS Security Hubのリージョン集約を有効化する

3つ目の選択肢は、AWS Security Hubでのクロスリージョン集約機能を有効化し、各リージョンの検出結果をメインの東京リージョン(=ホームリージョン)に集めるというものです。

構成図は以下のようになります。

Security Hubを使うことで東京リージョン以外にEventBridgeのリソースを作る必要がない点が、これまでの構成とは異なっています。

この場合だと、各リージョンの検出結果を(東京リージョンの)SecurityHubコンソール上から一挙に確認できるという視認性の良さはメリットになるはずです。

一方で、全リージョンでSecurity Hubを有効化しなくてはならないという点はデメリットになるかもしれません。

(これについては、セキュリティ要件として全リージョンですでにSecurity Hubを有効化していた場合はデメリットにはならないでしょう。)

まとめると…

メリット

  • 構築難易度は低い(設定を有効化するだけ)
  • 検出結果の視認性が良い

デメリット

  • 全リージョンでSecurity Hubを有効化する必要がある

以上で、選択肢の比較考量は終わりです。

実装については、また別の機会に記事にしたいと思います。

2. 参考記事

コメント

タイトルとURLをコピーしました