はじめに

こんにちは、大林です。今回はマルチアカウント管理におけるAmazon GuardDutyの活用方法について説明していきたいと思います。
GuardDutyはアップデートによって機能が増えており、最近ですとRuntime Monitoringという保護プランが新たに追加されました。 Runtime Monitoring以外の保護プランは、マネジメントコンソールやCLIなどで保護プランの有効化をすれば自動で脅威の検出をしてくれます。一方で、Runtime Monitoringは自動と手動の2種類の設定方法があり、他の保護プランよりもユースケースに応じた細かい設定方法が可能となっています。ここから、アップデートによって増えている機能を、マルチアカウント管理をする上でどのように活用していけばいいのか詳しく説明していきます。

Amazon GuardDutyはどんなサービス？

GuardDutyは機械学習を活用して、AWSアカウントやAWSリソースに対する不正アクティビティや潜在的な脅威を検出するサービスです。GuardDutyのデータソースには、VPCフローログ、CloudTrail、DNSクエリログなどがあります。また、GuardDutyには保護プランという機能が用意されています。この保護プランは、EC2、Lambda、RDSなどの個々の AWSリソースに特化した機能を提供しています。これについては、いくつかのプランがあるので以下で説明していきます。
GuardDutyのコストについてはこの記事では扱いませんので、公式ドキュメントを参照してください。

S3 Protection

GuardDuty S3 Protection は、AWSのS3バケットに特化した保護機能です。このサービスは、特定のIPアドレスやコンピュータからのAPI実行を監視し、不審なアクセスを検出します。また、データ削除などの重要なデータ操作を行うAPIの使用を追跡します。さらに、パブリックに公開されるなどの危険な設定変更も検出することが可能です。これにより、S3バケットに対するセキュリティリスクを効果的に管理できます。

EKS Protection

GuardDuty EKS Protectionは、Amazon EKSクラスター内の活動を監視し、不正なアクセスや疑わしい動きを検出する機能です。この保護機能は、Kubernetesの監査ログを利用して、ユーザーやアプリケーションがKubernetes APIを通じて行う活動を追跡します。特に、不正なIPアドレスからのデータアクセスや、認証されていないユーザーによるAPI呼び出しを識別することが可能です。

Malware Protection

GuardDuty Malware Protectionは、Amazon EBSボリュームに対するマルウェアスキャンを提供しています。Malware Protectionは、「GuardDutyによって自動的に開始されるマルウェアスキャン」と「オンデマンドマルウェアスキャン」の2種類のマルウェアスキャンを提供しています。それぞれのマルウェアスキャンの特徴は以下です。

スキャン方法	特徴
GuardDutyによって自動的に開始されるマルウェアスキャン	・マルウェアの挙動に関連性のあるイベントをトリガーに実行される・24 時間に 1 回だけ自動的に開始される・除外タグ(GuardDutyExcluded : true)が付与されているリソースはスキャンされない
オンデマンドマルウェアスキャン	・EC2インスタンスまたはコンテナに関連付けられているリソースのARNを指定してスキャンを実行できる・任意のタイミングで実行できるが、前回のスキャンから1時間空ける必要がある・除外タグ(GuardDutyExcluded : true)が付与されているリソースはスキャンされない

Malware Protectionは、包含タグまたは除外タグを使用してスキャン対象を管理することができます。どちらのタグも利用者側がタグのキーとバリューを設定できますが、包含タグ、除外タグの⽚⽅しか設定できないので注意が必要です。両方のタグを設定しようとすると、もともと設定してあったタグ設定がクリアされます。また、最優先の除外設定に使用できるタグとして、「GuardDutyExcluded : true」が用意されています。
スキャンは、暗号化されているEBSボリュームにも対応しており、AWS KMSのカスタマーマネージドキーやAWS管理キーで暗号化されたボリュームも含まれます。しかし、デフォルトのKMSキーで暗号化されたボリュームはスキャンの対象外です。
マルウェアが見つかった場合、スナップショットの保持がオプションとして提供されており、スナップショットは自動的にAWSアカウントに保持されます。スナップショット保持の設定が無効の場合やマルウェアが検出されなかった場合は、スナップショットは削除されます。
また、Malware ProtectionはGuardDutyの利用者側のAWSアカウントでスキャンを実行するのではなく、AWS側が管理するAWSアカウントでスキャンが実行されるようになっています。そのため、GuardDutyの利用者側のアカウントに対する負荷を抑える仕様になっていると言えます。

RDS Protection

GuardDuty RDS Protectionは、Amazon Auroraデータベースのログインイベントを分析し、潜在的なアクセス脅威を特定するための機能です。このサービスは、異常なログイン試行や不正アクセスなどの疑わしい活動を検出します。

Aurora DBエンジン	サポートされているバージョン
Aurora MySQL	2.10.2以降、3.02.1以降
Aurora PostgreSQL	10.17以降、11.12以降、12.7以降、13.3以降、14.3以降、15.2以降、16.1以降

Lambda Protection

GuardDuty Lambda Protectionは、Lambda関数が呼び出された際のネットワークアクティビティログを監視し、潜在的なセキュリティ脅威を監視する機能です。この保護機能は、Lambda関数が実行される際に生成されるVPCフローログを含むネットワークアクティビティを監視しますが、Lambda@Edge関数のログは監視対象に含まれません。また、VPC内のLambda関数とVPC外のLambda関数のどちらも監視対象です。

Runtime Monitoring

GuardDuty Runtime Monitoringは、EC2、ECS、EKSのランタイム動作を監視し、OSレベルの潜在的な脅威を検出する機能です。この機能を有効化するには、GuardDutyエージェントとVPCエンドポイントの作成が必要であり、これによりポートスキャン活動や既知の悪意のあるIPアドレス、ドメインへのアクセスを検出することが可能です。
エージェント管理タイプ(エージェントの管理方法)は、手動と自動管理の2つがあります。エージェント管理タイプが手動になっている場合は、エージェントのバージョンアップを手動で実施する必要があります。また、自動管理になっている場合は、GuardDutyがエージェントを管理してくれている状態なので自動でエージェントのバージョンアップを実施してくれます。

Runtime Monitoring 自動エージェント設定

自動エージェント設定を有効化すると、アカウント内に存在するEC2やECSがデプロイされているVPCにVPCエンドポイントが自動で作成され、EC2などの監視対象リソースにGuardDutyエージェントが自動でデプロイされます(ECSの場合はGuardDutyのサイドカーコンテナがデプロイされる)。ここでの注意点は、監視対象リソースのIAMロールにSSMの権限( AmazonSSMManagedInstanceCore )が付与されている必要があることです。SSM権限を付与しないと、「No Agent Reporting : Waiting for SSM notification」というエラーが表示され、Runtime Monitoringが正常に機能しません。
自動エージェント設定によって作成されるVPCエンドポイントの利用にコストはかかりません。また、自動エージェント設定によってデプロイされたGuardDutyエージェントのエージェント管理タイプは自動管理です。監視対象リソースのIAMロールにSSMの権限が付与されていることを確認した上で、マネジメントコンソールやCLIで自動エージェント設定を有効化すると、Runtime Monitoringによる監視が始まります。

自動エージェント設定は有効化しておきたいが、一部のリソースをRuntime Monitoringの監視対象から除外したい場合もあると思います。そういった場合に使用できるのが、除外タグ(GuardDutyManaged : false)です。除外タグをリソース作成の際に設定してからデプロイすると、エージェントのデプロイとVPCエンドポイントの作成はされません。注意しておきたいのが、自動エージェント設定を有効化した環境で既にデプロイしてあるリソース(既にRuntime Monitoringで監視しているリソース)に除外タグを設定しても、VPCエンドポイントとGuardDutyエージェントは削除されないことです。GuardDutyエージェントは動作し続け、エージェント管理タイプが手動に変更されます。

Runtime Monitoring 手動エージェント設定

手動エージェント設定は、Runtime Monitoringの利用者がGuardDutyエージェントのデプロイとアップデート、VPCエンドポイントの作成を手動で実施する方法です。手動エージェント設定を選択した場合のRuntime Monitoringの監視対象リソースは、GuardDutyエージェントのデプロイとVPCエンドポイントの作成が行われているリソースのみです。そのため、自動エージェント設定よりもRuntime Monitoringの監視対象リソースを絞りたいケースに有効な設定だと言えます。
手動エージェント設定にすると、GuardDutyエージェントを手動でデプロイしたり、VPCエンドポイントの作成をしなくてはならないため運用負荷が増加します。そういった場合に活用したいのが、包含タグ(GuardDutyManaged : true)です。手動エージェント設定を有効化した環境でリソースに包含タグを付与すると、自動でGuardDutyエージェントのデプロイとVPCエンドポイントが作成されます。手動エージェント設定を有効化した環境では、包含タグが付与されているリソースにデプロイされているGuardDutyエージェントのエージェント管理タイプは自動管理になり、包含タグが付与されていなければエージェント管理タイプは手動になります。

信頼されているIPリスト/脅威IPリスト

GuardDutyには、信頼されているIPリストと脅威IPリストを用いて脅威を判定する機能があります。信頼されているIPリストに登録されたIPアドレスからのアクセスは、安全とみなされるため脅威として検出されません。一方、脅威IPリストに登録されたIPアドレスからのアクセスは、脅威行動として判定されるようになります。
ユースケースとしては上記で説明したS3 Protectionと組み合わせた場合だと、自社オフィスや信頼できるパートナー企業のIPアドレスを信頼されているIPリストに追加します。これにより、これらのIPアドレスからのアクセスは安全とみなされ、警告が出ません。脅威と判断しているIPアドレスがあれば、脅威IPリストに追加してS3に対するアクセスを監視することができます。
この機能は便利ですが、作成できる数に制限があります。デフォルトでは信頼されているIPリストは1つまで、脅威IPリストは6つまでです。

マルチアカウント管理におけるAmazon GuardDutyの活用

Amazon GuardDutyを活用したマルチアカウント設計・運用のポイント

①全てのAWSアカウント、全ての利用リージョンで有効化する

GuardDutyは利用する全てのAWSアカウントで有効化することがベストプラクティスです。マルチアカウント環境で利用する場合、Organizationsと組み合わせることでセキュリティ状況を管理しやすくなります。AWSアカウントで利用しないリージョンは、サービスコントロールポリシーでリージョン拒否設定をして、GuardDutyを有効化していないリージョンでのリソース作成を禁止するとよいです。

②検出結果を定期的に確認する

検出結果は常に変化するため、定期的な検出結果の確認が必要です。GuardDutyにおける検出結果の更新頻度はデフォルトだと6時間に設定されていますが、最も高頻度の更新設定である15分間隔に設定することがおすすめです。さらに、検出結果を効率的に管理するためには、GuardDutyのマネジメントコンソールから直接調査を行うことも可能ですが、コストに余裕があればAWS Detectiveを利用して詳細な調査を検討してもよいです。検知して終わりではなく、アラートの詳細情報を確認して、潜在的な脅威を早期に発見することが大切になってきます。

③Security Hubとの連携

GuardDutyはリージョンごとのサービスのため、マネジメントコンソールから検出結果を確認する際に1つずつリージョンを切り替えて検出結果を確認しなくてはなりません。 Organizationsを活用したマルチアカウント環境の場合、Security Hubと連携することで、Security HubのホームリージョンからGuardDutyの検出結果をリージョンとアカウントを跨いで確認することができます。

④世界観、コスト、体制を考慮したGuardDutyの活用

これはGuardDutyの活用のみに言えることではありませんが、最終的にどうなっていきたいかという世界観、準備できるコスト、確保できる運用体制を考慮した設計が最も良いものだと言えます。例えば、最終的に目指すべき理想の状態があって、それを実現するためにRuntime Monitoringのエージェント設定は自動にするのか、それとも手動にするのか、GuardDutyで重要度の高い検知が来た場合にどのような対応をしていくのかなどを決めていく必要があります。これらのポイントを考慮して設計をすることで、効率的でセキュアなマルチアカウント管理につながります。

Amazon GuardDutyを活用したマルチアカウント設計例

上記が、GuardDutyを活用したマルチアカウント設計例です。今回のマルチアカウント設計では監査アカウントにGuardDutyの管理を委任して、組織内のAWSアカウントを一元的に管理できるようにしています。監査アカウントのGuardDutyに管理を委任している理由は、社内でセキュリティ担当者や監査の担当者がいる場合、それらの人がアカウント内の情報を確認しやすくするためです。

検知・通知・検知後の対応例

GuardDutyと他のAWSサービスと連携することで、検知結果に基づいて自動化された対応を実行することもできます。例えば、EventBridge、Lambda、SNSを使用してGuardDutyの検出結果を通知したり、検出結果に応じてリソースの設定を変更することができます。アカウントの運用体制に十分な人員を確保できない場合は、このような自動修復機能を採用してもよいと思います。ただ、自動修復してくれるからといって、検出結果を見なくていいわけではありません。検出内容や各アカウントでどのような検出結果が多いのかといった傾向を分析して、各アカウントの利用者と対応策を考え、実施していくことでセキュアなアカウント管理につながります。

おわりに

GuardDutyは、アップデートによって機能が増え続けていて、AWSリソースのセキュリティを強化できるサービスです。今回のブログでご紹介したように、マルチアカウント環境においても、各種保護プランや信頼されているIPリスト/脅威IPリストを活用することで、効率的かつ効果的なセキュリティ管理が可能となります。これからもGuardDutyの新機能やアップデートに注目し、効率的なセキュリティ管理をしていきましょう！