Organizations を利用した GuardDuty の有効化手順

記事タイトルとURLをコピーする

こんにちは。技術課の加藤ゆです。
久しぶりブログを書きました。最近は30度近い日が続いて、アイスコーヒーがおいしい季節ですね。

本記事では、単一リージョンでのGuardDuty有効化手順を記します。
Organizations環境では、 組織内のすべてのアカウントへ GuardDuty設定を行うことが出来ます。

Amazon GuardDutyとは

AWS環境のログ等を継続的にチェックし、機械学習技術を活用して脅威を検出してくれるAWSサービスです。
実際のログをみて、「悪意がある」と疑われる挙動を機会学習で検知して教えてくれます。
(具体的なデータソースは、VPC Flow Logs・CloudTrailのイベントログ・DNSクエリログ等)
基礎データソース - Amazon GuardDuty

脅威を判断/識別し、その脅威リスクの影響度に応じてHIGH/MEDIUM/LOWに分類した上で検出結果を出します。

Organizationsとは

AWS Organizationsとは、複数のAWSアカウントを一元管理できるAWSのサービスです。 Organizations組織上のアカウントを以下のように呼びます。
本記事でもこの後登場しますので、覚えておいてください。

※上図は、組織(OU)の記載を含めていません。

名称 説明
マネジメントアカウント 組織の長となるAWSアカウントを示します
メンバーアカウント その他のAWSアカウントを示します

詳細はこちらのブログをご覧ください。

blog.serverworks.co.jp

Organizationsを利用したGuardDutyの有効化とは

Organizations組織内の GuardDuty設定を一括で設定することが出来ます。
アカウント1つ1つに手動でポチポチせずとも、この組織では自動で有効化ね!とすれば、以降組織内にアカウントが追加されても勝手に有効化されています。

以下の通り、AWSとしては すべてのリージョンで GuardDuty を有効することが推奨です。

AWS は、サポートされているすべてのリージョンで GuardDuty を有効にすることを強くお勧めします。このように設定することで、GuardDuty はアクティブに使用されていないリージョンでも、許可されていないアクティビティや異常なアクティビティに関する検出結果を生成できます。
GuardDuty の開始方法 - Amazon GuardDuty

手順

本手順により、東京リージョンのすべてのアカウントで有効化されます。
docs.aws.amazon.com

マネジメントアカウントで作業します。
まずGuardDutyのサービスページへ遷移し、「今すぐ始める」を押下

1.委任された管理者

通常は、Organizations の統合によって集約されたAWSサービスの管理者は、マネジメントアカウントです。
その管理者をメンバーアカウントに移すことが出来るのがこの「委任」の機能です。

ここでは、GuardDutyの管理を担うメンバーアカウントを指定します。

作業後のマネジメントコンソール画面

委任された管理者を指定すると、そのアカウントに対し現在のリージョンで GuardDuty が有効になります。

GuardDuty管理者を、マスターアカウントとする

通常の設定のまま、GuardDuty管理者を、マスターアカウントとすることは可能です しかし、AWSのベストプラクティスからは推奨されていませんのでご理解ください。

組織の管理アカウントを委任された管理者として設定することは推奨されません。
組織の管理アカウントは委任された管理者になることはできますが、これは最小特権の原則に従う AWS セキュリティのベストプラクティスに基づいて推奨されません。
AWS Organizations を使用した GuardDuty アカウントの管理 - Amazon GuardDuty

AWSのベストプラクティスでは、 最小権限の原則というものがあります。
「何でもかんでも権限与えるんじゃないよ。必要な対象に必要な権限のみ与えなさいよ。」という話です。

マネジメントアカウントは組織内でもっとも強い権限を持つアカウントになります。
となると、その中でログインして作業をすると組織の全アカウントに影響が及ぶ可能性がありますね。

マネジメントアカウントでは必要な操作のみ操作させるために、「委任」の機能を上手く利用することが推奨されます。

2.GuardDuty 有効化

2-1. マスターアカウントのGuardDutyを有効化

マスターアカウントでGuardDutyを有効化します。
※この作業は、管理者を委任した場合も必須で必要です。

2-2. 組織の東京リージョンでGuardDuty 有効化

GuardDutyの管理アカウントで作業を行います。
(マスターアカウント or 委任したメンバーアカウント)

インフォメーションバーの「有効化」ボタンを押下
(※2023年7月現在は、この操作をしないと、既存メンバーアカウントで自動有効化されません)

アカウントのGuardDutyは有効化されました。
しかし、この状態では自動有効化は有効ではありません。

2-3. 組織でのGuardDuty 自動有効化設定

今後追加されるAWSアカウントでも、GuardDutyが有効化されるよう設定します。

「自動有効化がオフ」のラベルを押下

GuardDuty の自動有効化とソース設定の設定
既存・新規すべてのアカウントで有効化するため、今回は「すべてのアカウント」を選択します。

GuardDuty のデータソースは、基本的にAWS CloudTrail イベントログ・AWS CloudTrail 管理イベント・VPC Flow Logs・DNS ログ の4種です。
その他オプションで以下をデータソースに含むことが出来ますので、必要に応じて有効化下さい。

  • S3 Protection
  • EKS Audit ログのモニタリング
  • Malware Protection
  • RDS ログインアクティビティ
  • EKS ランタイムモニタリング
  • EKS ランタイムモニタリング エージェントを自動的に管理
  • Lambda ネットワークアクティビティモニタリング

作業後のマネジメントコンソール画面

これにて、
現在のリージョン(東京リージョン)の、すべてのメンバーアカウントで、GuardDutyが自動有効化されます

全リージョンのすべてのアカウントで有効化するには?

GuardDutyはリージョナルサービスです。
リージョン毎に設定が必要なので、上記の作業を全リージョンで実施しましょう!

とするのは実際つらいので、一般的にはAWS StackSets or AWS CLI で実行いただくのが現実的と思います。

1.StackSetsの利用

StackSetsはリージョン・アカウントをまたがって一括設定を行う機能です。
今回のような単一リージョン毎で操作が必要なサービスには打って付けのサービスですね。

一方で、CloudFormationでテンプレートを流すことになるので、テンプレートの作成が必要になります。
本記事ではテンプレートの用意はしておりません。あしからず。

2.AWS CLIの利用

GuardDutyの管理アカウントにて、CloudShell等で実行します。
ここでは、ドキュメントリンクの紹介に留めます。

おわり

以上、マネジメントコンソール上の有効化手順でした!
全リージョン向けの有効化手順は、今後書くかも・・しれません(希望)

最後までご覧いただきありがとうございました。

加藤 由有希 エンジニアブログの記事一覧はコチラ

エンタープライズクラウド部 所属

2020年4月に新卒入社