fu3ak1's tech days

何事もシンプルに。主にAWS関連の記事を書いています

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ~5. GuardDuty~

Organizationsシリーズ第五弾、Amazon GuardDuty編です。

Organizationsの紹介(はじめに編)はコチラ

前回はコチラ

GuardDutyとは

マネージド型の脅威検出サービスです。AWSアカウント内で発生している脅威を検出してくれます。たとえば以下のような事象を検知してくれます。

  • ルートユーザの使用
  • IAMユーザーの不正利用(大量の操作実行など)
  • EC2の不正通信

検知する仕組みはAWS側で管理されるので、利用者はそれをどう検知、管理していくか運用面を検討して利用すればOKです。 デフォルトで有効にしたいサービスの1つですね。

Organizationsを使用したマルチアカウント設定

GuardDutyもAWS Configと同じく、アカウントの委任に対応しています。よって以下のようにauditアカウントに情報を集約できます。

f:id:fu3ak1:20210107224929p:plain

手順の流れは以下のとおりです。

  1. メンバーアカウントへ委任
  2. メンバーアカウントのGuardDuty有効化、新規アカウントの自動有効化
  3. (Option) 検知の設定

設定手順

実際にやっていきます。

1.メンバーアカウントへ委任

マネジメント(親)アカウントへログインし、GuardDuty画面へ遷移します。

まだマネジメント(親)アカウントでGuardDutyが有効でない場合は有効化しておきます。

f:id:fu3ak1:20210107225835p:plain

有効にした後、設定>委任された管理者欄に委任先のアカウントIDを入力し、委任ボタンを押します。

f:id:fu3ak1:20210107230152p:plain

委任が完了すると以下のような画面表示になります。

f:id:fu3ak1:20210107230315p:plain

2.メンバーアカウントのGuardDuty有効化、新規アカウントの自動有効化

委任後、委任したアカウントauditにログインしてGuardDuty画面へ遷移します。すると、audit以外のアカウントが表示されます。

組織単位でGuardDutyを有効にできるボタンが表示されるので、有効化を押します。

※なお、auditアカウントはGuardDuty無効状態でしたが、委任をした時点で自動的に有効化されました。

f:id:fu3ak1:20210107230914p:plain

確認が以下のように出るので有効化します。有効にすることで今後新規で追加されるAWSアカウントもGuardDutyが有効になります。

f:id:fu3ak1:20210107231019p:plain

しばらくすると以下のように各アカウントのステータスが有効になります。

f:id:fu3ak1:20210107231337p:plain

GuardDutyにはS3へのデータアクセスに対する脅威も検出できる(最近できるようになった)のですが、この有効化は別管理となっています。これの自動有効化も同画面からできそうなのでやってみます。

f:id:fu3ak1:20210107231633p:plain

チェックを入れて更新。

f:id:fu3ak1:20210107231742p:plain

と、これで既存のアカウントも有効になると思ったのですが、そうではないようです。新規アカウントの自動有効設定でした。

既存アカウントはS3保護の設定から有効化します。

f:id:fu3ak1:20210107232003p:plain

できました。

f:id:fu3ak1:20210107232052p:plain

アカウント側にも反映されています。

f:id:fu3ak1:20210107232312p:plain

GuardDuty有効の設定はここまでです。

なお、ここまでの設定では東京リージョンのみ有効となっています。脅威はどのリージョンでも発生する可能性があるため、可能であれば全リージョンでの有効も検討したほうが良いでしょう。具体的なやり方は自動化の検討をする機会があれば書いてみたいと思います。(全サービス書き終えて余裕があれば書いてみる予定です)

3. 検知の設定

有効化しただけではGuardDutyの本来の脅威検出の機能が見れないので、サンプルイベントの検知を行ってみます。

通知の設定はEventBridgeから行います。

f:id:fu3ak1:20210107233354p:plain

イベントパターンで以下のようにGuardDuty Findingを設定します。これによりGuardDutyのすべての検知がイベントとしてトリガーされます。

f:id:fu3ak1:20210107233509p:plain

ターゲットに通知用のSNSを指定して、ルールを作成します。今回はあらかじめChatbotを設定しておいたSNSを指定します。(Chatbotの設定方法は本記事では割愛)

メールを設定したSNSでもOKです。

f:id:fu3ak1:20210107233615p:plain

ルールができました。

f:id:fu3ak1:20210107233756p:plain

サンプルイベントを発行してみます。全アカウントのGuardDuty検知がauditアカウントに集約されて検知されるはずなので、今回は別アカウントのsystem01でサンプルイベントを発行してみます。

system01アカウントにログインし、GuardDuty画面からサンプルイベントを発行します。

f:id:fu3ak1:20210107234038p:plain

しばらくすると以下のように通知が飛んできます。Accountのところに対象のアカウント、今回でいうとsystem01のアカウントIDが表示されます。

f:id:fu3ak1:20210107235016p:plain

つまり、以下のように、集約されたauditアカウント経由で通知されたことになります。

アカウントが増えても自動的に有効になるので組織単位の通知運用が可能になりますね。

f:id:fu3ak1:20210108000746p:plain

すべてのFindingを通知すると量も多くなりますのでフィルタの検討も必要にはなるかと思います。

以上、検知も含めた設定の検証はここまでです。

さいごに

AWS Config、CloudTrailに比べてすんなり設定できた印象です。マルチアカウントの要望が強いサービスなのかもしれませんね。

GuardDutyは有効にするだけで、AWSが裏側で色々動いて色々な脅威を検知してくれるので、私もとても好きなサービスです。 この機能を使ってうちの組織はデフォルトでONだから!といった管理運用も良いですね。

次回はIAM Access Analyzerの予定です。

次回はコチラ