マネージドサービス部 佐竹です。
本日のブログでは、Amazon GuardDuty の 検出結果で「漏らさずにリアルタイムで確認したい Severity が High の検出結果」のみを Slack チャンネルに連携し通知する設定方法を具体的に記載します。
はじめに
Amazon GuardDuty はフルマネージドの脅威検出サービスです。本サービスは、AWS アカウントのセキュリティを向上させるためには必ず有効化しておきたい機能です。
特にマルチアカウント運用下においては、漏れなく設定しておきたいサービスの1つとなっています。
また、Amazon GuardDuty の Severity が「High (高)」となっている検出結果は、その通知の発生理由を解明し、問題がないことを確認する運用が合わせて必要になってきます。
そこで、GuardDuty のコンソールにわざわざ見に行かなくても、Slack だけを見ていれば問題ない状況を作るために、今回は GuardDuty の検出結果において、Severity が High のものだけを AWS Chatbot を利用して Slack へと連携する具体的な設定方法について記載します。
関連するドキュメントのご紹介
本ブログを記載するにあたり、参考となるドキュメントとブログをご紹介します。
Creating custom responses to GuardDuty findings with Amazon CloudWatch Events
以下のブログは、AWS 公式ドキュメントにおいて Amazon CloudWatch Events を利用した通知設定が記載されておりますが、今回はより新しいサービスである、Amazon EventBridge を利用していきます。
Monitoring AWS services using AWS Chatbot
AWS Chatbot を利用して Slack への通知を行う想定ですが、AWS Chatbot には対応しているサービスと、対応していないサービスが存在します。
このため、以下のドキュメントで対応しているサービスかどうか確認をしますが、Amazon GuardDuty は AWS Chatbot に対応済となります。
AWS 環境における暗号通貨採掘悪用に備える
Amazon GuardDuty の有効性については以下のブログにも記載しておりますため、未読の方は是非ご確認ください。
全体の流れ
今回の全体の流れは「Amazon GuardDuty → Amazon EventBridge → Amazon SNS → AWS Chatbot → Slack Channel」となります。
設定は以下の順で行っていきます。なお、Amazon GuardDuty は既に有効化されている前提で話を進めていきます。
- Amazon SNS Topic を作成する
- AWS Chatbot （Slack） と SNS Topic を紐づける
- Amazon EventBridge で検出結果の絞り込みと、SNS への通知設定を行う
AWS Organizations に関連する補足
今回通知を設定する AWS アカウントは、AWS Organizations における「セキュリティツーリング」を担うアカウントで行っていきます。
セキュリティツーリングアカウントについては以下に詳しく記載しておりますので、合わせてご覧ください。
また、セキュリティツーリングアカウントに Amazon GuardDuty を委任（delegation）している状態で本設定を行うと、全アカウントの Slack 通知がセキュリティツーリングアカウントから行われるため、1 つのアカウントに行うだけで全アカウントの Slack 連携が完了します。
このように通知設定が非常に楽になりますので、設定の観点からもセキュリティツーリングアカウントの作成と各セキュリティツールの委任を行われることを推奨します。
Amazon SNS Topic を作成する
まずは、今回の通知に利用する目的で、Amazon SNS Topic を新たに作成します。また今回、GuardDuty の通知を行いたいのは東京リージョンになりますため、東京リージョンで作業をしていきます。
画像の通り、Topic の Type は Standard、Name は Amazon-GuardDuty としました。
その他の設定は特に変更する必要がありませんため、デフォルトのまま Topic を作成します。
AWS Chatbot （Slack） と SNS Topic を紐づける
AWS Chatbot （Slack） と SNS Topic を紐づけるために、まずは Slack のワークスペースを AWS Chatbot へと連携していきます。
AWS マネジメントコンソールの画面右上「Chat client」から「Slack」を選択し「Configure client」で先に進みます。
Slack との連携を促されるため「Allow」します。
※権限不足の場合は「Allow」ができないため、Slack のワークスペース管理者等に問い合わせて下さい
画面が遷移し「Slack successfully authorized AWS Chatbot.」と表示されたら、Slack ワークスペースとの連携は完了です。
続いて、右下にある「Configure new channel」を押下してチャンネルを登録していきます。
まず「Configuration name」には、Slack のチャンネル名をそのまま記載するのが明確ですので、お勧めです。
「Logging - optional」は、設定しておくことで CloudWatch Logs にログを出力できますが、今回は設定しません。上手く動作しない場合は出力設定をされると良いでしょう（少額の費用が発生します）。
「Channel ID」は、各 Slack チャンネルの「About」の最下部に記載がありますので、これをコピーしてペーストしてください。
Permissions は、上図の通りとしました。
AWS Chatbot 用の IAM Role (Channel role) を「AWSChatbot-role」として新規に作成する想定です。
基本的にはこの Role 権限だけで問題ないのですが、「Channel guardrail policies」という設定も必要です。
これは今回「AmazonSNSFullAccess」としています。このポリシーの立ち位置は、IAM Role の上位に存在する AWS Organizations の SCP のようなもので、ここで許可されていてかつ Channel role でも許可されたもののみが、AWS Chatbot で動作させることが可能となります。
AWS の権限については以下の AWS 公式ドキュメントを参照ください。
最後に、「Notifications」で SNS Topic と紐づけを行います。
東京リージョンを選択した後、先ほど作成した SNS Topic を一覧から選択して紐づけます。
このように、SNS Topic への AWS Chatbot との連携設定は AWS Chatbot 側から行いますため、先に SNS Topic の作成が必要でした。
最後に「Configure」を押下してここまでの設定を完了します。
Slack チャンネルに aws APP を招待する
「@aws」などとして、画像の通り AWS Chatbot 用の対話 APP を通知対象の Slack チャンネルに招待します。
この作業をし忘れると、Slack に AWS からの通知が行われませんので注意してください（よく失念される設定です）。
AWS Chatbot の動作確認
「You successfully configured the Slack channel.」と表示され、Slack チャンネルの設定が完了した後は動作確認を行います。
最下部のチャンネル一覧から作成されたチャンネルを選択し、「Send test message」を押下します。
マネジメントコンソールに「Dispatched 1 messages」と表示された後、以下のテストメッセージが、Slack チャンネルに投稿されます。
「AWS Chatbot Notification | Test Message | Account: 123456789012」というテストメッセージが届きましたら、Slack チャンネルと AWS Chatbot との連携は正しく行えていることになります。
ここまで動作が確認できたら、次に進みます。
Amazon EventBridge で検出結果の絞り込みと、SNS への通知設定を行う
Amazon EventBridge のコンソールを開き、ルール設定をしていきます。こちらも、東京リージョンで設定をしていきます。
コンソールから、「Create rule」を押下して進めていきます。
Rule detail の Name には今回「Amazon-GuardDuty-Severity-High」を記載しました。Description は任意です。
Name を記載したら次の画面に進みます。
Build event pattern の設定を行います。最上部の Event source は 「AWS events or EventBridge partner events」のままで問題ありません。Sample event は任意のためスキップします。
「Creation method」の設定に移ります。ここが本ブログの設定の肝（本題）なのですが、Event pattern で GuardDuty findings における Severity が High に値するものだけを通知したいので、本項目での JSON をカスタマイズして記載が必要です。
なお、マネジメントコンソールから「Use pattern form」を利用して生成することも可能ですが、以下の通りの JSON までしか作成できません。
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"]
}
これでは、全ての Severity を通知してしまいます。ですので、Severity で設定を絞り込む必要があります。
上記公式ドキュメントに記載されている通り、[High] (高) は「8.9～7.0」間の値を取ることがわかっています。
さらにこちらの公式ドキュメントに CloudWatch Event でのサンプル JSON の記載があります。以下が公式ドキュメントに記載されている Event Pattern で、これは注釈にある通り Severity が [Medium] (中) のものと、[High] (高) とが対象の設定です。
{
"source": [
"aws.guardduty"
],
"detail-type": [
"GuardDuty Finding"
],
"detail": {
"severity": [
4,
4.0,
4.1,
4.2,
4.3,
4.4,
4.5,
4.6,
4.7,
4.8,
4.9,
5,
5.0,
5.1,
5.2,
5.3,
5.4,
5.5,
5.6,
5.7,
5.8,
5.9,
6,
6.0,
6.1,
6.2,
6.3,
6.4,
6.5,
6.6,
6.7,
6.8,
6.9,
7,
7.0,
7.1,
7.2,
7.3,
7.4,
7.5,
7.6,
7.7,
7.8,
7.9,
8,
8.0,
8.1,
8.2,
8.3,
8.4,
8.5,
8.6,
8.7,
8.8,
8.9
]
}
}
非常に縦長になっていますが、これを [High] (高) の「8.9～7.0」間だけを通知するように修正します。また、改行は除外できますため、以下の通りに短縮可能です。
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [7, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 8.9]
}
}
これを入力するために「Custom pattern (JSON editor)」を選択後、Event pattern にコピー＆ペーストしてください。
その後「JSON is valid」と表記が出ていることを確認し、「Next」を押下して次に進みます。
Select target(s) に進みます。ここで先ほど作成した SNS Topic を選択して連携することになります。
Target types は AWS service のままとし、Select a target から「SNS topic」を選択後、先ほど作成したトピックである「Amazon-GuardDuty」を選択しましょう。
Additional settings は特に設定不要のため、「Next」を押下して次に進みます。
この後の設定の Configure tags でタグを付与できますが、今回は特に設定は不要です。
最後の Review and create で確認し、問題がなければ右下の「Create rule」を押下して設定を完了します。
画面最上部に「Rule Amazon-GuardDuty-Severity-High was created successfully」と表示されたことを確認して作業は完了です。
Severity 9.0 から 10.0 に対応した Event pattern を記載する場合
AWS 公式ドキュメントをよく確認していくと、Severity に関して以下の通りの記載があります。
[Note] Values 0 and 9.0 to 10.0 are currently reserved for future use.
値 0 と 9.0 から 10.0 が将来使用するために現在予約されています。
https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html
現在、Severity = High の数値を全て列挙するように記載していますが、そこには予約されている 9 以上の値が存在していません。
このため、将来的にこれらの数字が High に追加もしくはそれ以上の重要度の Severity として追加された場合に、重要な検出結果を見逃してしまう可能性があります。
この懸念に対応するため、Event pattern は以下の通り「numeric」で不等号指定とし、7 以上の全てを検出するほうがより良いでしょう。
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [{
"numeric": [">=", 7]
}]
}
}
既存の Event pattern は後からも Edit が可能ですため、将来的な対応を見越して上記 JSON もご利用頂けたらと存じます。
実際にアラートが来るか Sample findings を実行する
設定が正しく動作するのか確認するためには、実際に High のアラートを発生させると良いのですが、それが後々意図したものなのか本当の脅威なのか見分けが付きにくくなることを鑑みて、今回は Sample findings の機能を利用します。
なお、Sample findings をセキュリティツーリング以外のアカウントから実行することで、Amazon GuardDuty の Findings が正しく委任されたアカウントに集約されているかもテストすることが可能です。以下の手順は、実際はセキュリティツーリング以外の AWS アカウントで実施しています。
まずは、Amazon GuardDuty のマネジメントコンソールで、「Settings」を選択します。
その後、Sample findings の項目内にある「Generate sample findings」ボタンを押下します。
ボタン押下後のレスポンスが特にないため分かりにくいですが、このボタンを押下すると「Successfully generated sample findings」という文字列が画面最上部に表示されますので念のため確認してください。
ボタンを押下するとすぐに GuardDuty の Findings ページに全ての Findings の Sample が登録されます。
その後、数分間待つと（今回は3分程度待ちました）この Sample Findings のうち、High の Findings のみが Slack へ連携されます。
全ての High の Findings が Slack へと連携されるためかなりの数（今回は 60 個通知がありました）になりますが、画像の通り問題なく Slack へ連携されたことが確認できました。
これで実際に high のアラートが検出された場合の動作確認も完了しましたので、これにて今回ご紹介した全設定の完了とします。
まとめ
本ブログでは、Amazon GuardDuty の 検出結果のうち「漏れなくリアルタイムで確認したい Severity が High の検出結果」を Amazon EventBridge と AWS Chatbot を活用し Slack チャンネルへと連携する設定方法について記載しました。
また設定方法については AWS マネジメントコンソールから行い、手順書として利用可能なレベルで記載させて頂きました。
SNS ＆ AWS Chatbot の Slack 連携を利用することで、可読性が向上し、また通知にも気付かれやすくなりますため、Slack を利用されているエンドユーザ様にお勧めの監視設定となっています。
ただ、AWS Chabot では Slack メンションはご利用いただけません。もしメンションが必要な場合は、AWS Lambda を間に挟む形で通知をカスタマイズする必要があるでしょう。
それでは、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
