🐥

Amazon GuardDuty のアラートテスト用検証環境の構築方法 - part1【事前準備・構成確認編】

2024/03/06に公開

マネージド型脅威検出サービスの 「Amazon GuardDuty」 。

「検出結果サンプルの生成」からサンプルアラートを生成することができますが、サンプル量が多いのでアーカイブ化するのが大変だったり、インスタンスやリソース名が実際に存在する名前ではなかったりして、リアリティに少し欠けたりします。

なので、もっとリアリティのあるアラートを生成したく、以下の GitHub のリポジトリを参考に環境を構築し、検証用のサンプルアラートを生成しました。

近々業務の方でも再度環境構築しないといけないので振り返りも兼ねつつ、この記事をご覧の方の参考になればと思います。

ただし情報量も多くなるので、何回かに分けて共有していく予定です。

今回は、この検証環境を構築していく上での、前提条件、構成図、発生予定のアラート内容を確認していこうと思います！

（part2【環境構築・実行編】も公開しました！良かったらご覧ください。）

前提条件

まず初めに、GitHub のリポジトリにも記載がある通り、以下の状態を確認していく必要があります。（詳しい前提条件の確認はこちら）

特にIAMポリシーに関しては、最小限に抑えることを心掛けておきましょう。（※以前構築時、権限が足りなかったような気がしています。次回の記事で再検証する際に不足している権限があれば、その記事で詳しく記載する予定です）

また念のためですが、間違ってもAdmin権限にしてしまわないように、十分注意しておきましょう。

（図は GitHub リポジトリからそのまま参照）

構成図については、大まかに上記のようになります。構成としては、よくあるパターンですね！

パブリックサブネットには踏み台（Bastion）が設置されており、プライベートサブネット側には攻撃される可能性のある Windows や Linux 環境があります。

ただし、今回の踏み台へは EIC（EC2 Instance Connect）を使用して接続していく予定です。そのため、この構成図にはエンドポイント関連のリソースが追加されます。

また、構成図にはないですが、ECS 関連のアラートも発生するため、ECS 関連のリソースも構成に加わります。

AWS リソースの利用における金額は、フル稼働すると月に約7,000円を想定しています。（2024年3月現在）

主に費用がかさむのは NAT Gateway ですね。これは避けられない部分ですね。

実際はアラートの確認ができれば良いので、確認後は CloudFormation を削除して対応することをお勧めします。

今後のリソース構築後のスクリプト実行結果、生成される予定の GuardDuty 検出タイプは以下の7つです。（詳しいアラート内容の確認はこちら）

どの検出結果も実際に起きたら困るアラートで、実際に起きるのは避けておきたい内容となっていますね。

なお、今回の環境構築とは異なってしまいますが、このアラートが起きた場合にすぐに対応できるように、最終的に SNS / Chatbot 経由で Teams や Slack に通知したり、チケットとして起票したりできたら良いですね！

今回は Amazon GuardDuty のアラートテスト用の環境構築について、事前準備や構成確認を中心に整理してみました。

次回は実際に環境する手順をご紹介していきたいと思います。ただし、その環境構築も CloudFormation が既に完成しているので、比較的簡単にできるかと思うので、楽しんでいきましょう！

AWS セキュリティ関連は奥深くて面白いですね！