はじめに

　Amazon GuardDutyはAWSのリージョン別脅威検出サービスです。
　CloudTrailログ、VPCフローログ、DNSログなど複数のAWSデータソースにより何百億件ものイベントを分析します。
　今回はGuard Dutyがどのようなものかコンソールにより有効化してみて、最後にCloudFormationでも作成してみます。

GuardDuty有効化（コンソール）

　サービスロールのアクセス権限を見てみます。

　分析するのに、権限がこれだけでいいのでしょうか？
　とりあえず有効化してみます。

　最初の画面です。
　GuardDutyは有効化されると、分析をすぐに開始するようです。
　時間を置いても何も検出されていないので、潜在的に悪意のあるアクティビティは検出されていないことがわかりました。
　また、抑制ルールを作成して対処する必要のない脅威検出結果を自動的にアーカイブでき、影響を与える脅威検出結果を簡単に認識できるようにできます。

　コストが可視化されているようです。
　私が有効化しているデータソースはCloudTrailとVPCフローログですが、両方とも保留中となっています。
　使用日数が7日未満の新しく有効になったGuardDuty,データソースの場合はコストは保留中と表示されるからです。
　なお、この画面に表示されている見積もりは、過去7から30日間の使用料に基づく1日の平均コストになります。

　ところで、S3データイベントとは何でしょうか？
　他のデータソースはイメージできますが、これがよくわからなかったので調べてみました。
　簡単に言うと、S3に対するデータアクセスイベントのようで、S3に対する悪意あるアクティビティを検出できるようです。
　GetObject、ListObjects、DeleteObject、およびPutObjectAPI操作がS3データイベントの例です。

　なぜかサービルロールの権限がパワーアップしています。
　また、結果のサンプルを生成をクリックすることで、検出結果のサンプルが見られます。

　GuardDutyは検出結果に重大度が付されており、青が低、黄が中、赤が高です。
　数字で表すと0.1から８．９の範囲で、大きいほどセキュリティリスクが高いことを示します。

　信頼しているIPリストと悪意あるIPリストを作成できるみたいです。
　DNSログやVPCフローログの分析の際に活用できそうです。

　S3保護はデフォルトで有効になっています。
　S3保護により、オブジェクトレベルのAPIオペレーションを監視して、S3バケット内のデータの潜在的なセキュリティリスクを特定するようです。

　こちらは、複数アカウントを管理するための画面です。
　GuardDutyの管理者アカウントになり、メンバーアカウントを管理することができます。
　管理者アカウントは、メンバーアカウントのGuardDutyの有効化・一時停止や、抑制ルール・IPリストなどを作成管理できます。
　メンバーアカウントは、これらの機能にアクセスできなくなります。

S3バケットのブロックパブリックアクセスをオフにして検出するか試してみる

　空のS3バケットを新規作成して検出されるか試してみます。
　結果は検出されましたが、15分かかりました。

GuardDuty有効化（CloudFormation）

　めちゃくちゃ短いです。

AWSTemplateFormatVersion: 2010-09-09
Description: Enable Amazon GuardDuty

Resources:
  GuardDuty:
    Type: AWS::GuardDuty::Detector
    Properties:
      Enable: true

　EventBridgeとSNSを組み合わせて検出された重要度によって通知をすることもできますが、今回はしません。
　GuardDutyを有効化していない場合は作成に成功しますが、GuardDutyを停止している場合に作成すると、既にDetectorが存在すると言われてエラーになります。

おわりに

　簡単に全リージョンに有効化できそうです。
　それにしても途中からサービスロールのアクセス権限が増えたのはどうしてでしょうか。