STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

SecurityHubを利用したAWSサービスのSlack通知

こんにちは。hey セキュリティ本部の清水です。

hey ではAWS Organization を利用して複数の AWS アカウントをまとめて管理しています。AWS Organization と連携できるサービスは年々増えており、hey では Amazon GuardDuty, AWS IAM Access Analyzer, AWS CloudTrail などのサービスを AWS Organization と連携させています。

AWS Organization と連携させることで、各 AWS アカウントのサービスからの通知を AWS Security Hub 経由で一括に管理できるようになります。本記事では、AWS Security Hub を利用したアラート通知の設計と実装の概要を紹介します。AWS Security Hub を利用したアラート通知システムの構築を検討されている組織の参考になれば幸いです。

背景

なぜ Security Hub によるアラート通知システムを設計・実装したのか、その背景を少し記載します。hey の AWS アカウントの運用には、以下の課題がありました。

AWS アカウント毎に通知設定に差がある

  • ある AWS アカウントでは Amazon GuardDuty の Finding を Slack 通知しているが、別アカウントではSlack 通知していない状態では、アカウントの監視状態に差が生じてしまいます。外部からの脅威に対応するためには全ての AWS アカウントについて一定以上の監視状態を維持することが重要です。

開発チームがそれぞれで通知の設計・実装をしている

  • 開発チームがそれぞれでAWSサービスの通知の設計・実装していては、AWS アカウントの数だけ会社全体の開発工数が増えてしまいます。共通化できる通知は共通化した方が、会社全体での開発工数は削減できます。

これら課題を解決するために、セキュリティ本部で AWS Organization の全ての AWS メンバーアカウントを対象にしたアラート通知の設計・実装を行いました。

設計

アラート通知のシステムを設計するにあたって、考慮した点は以下となります。

拡張性

AWS では毎年のように新しいサービスが登場します。hey で利用される AWS アカウント数も今後増加する予定です。通知対象が拡大してもシステム設定に修正を少し加えるだけで対応できる、拡張しやすい構成を心がけました。

柔軟性

以下のように、開発チームのSlackで受けたい通知内容は運用するにつれて変化することが予想されます。

  • Amazon Inspector からの通知は CRITICAL の通知のみ受けたいけど、AWS IAM Access Analyzer からの通知は CRITICAL から LOW のものまで全て受けたい。

通知を受ける対象となる通知内容に対してある程度柔軟に対応できるように、通知フィルタをSlackチャンネルごと個別に設定出来るように設計しました。

集約性

全ての AWS アカウント・サービスの通知を1つの Slack チャンネルに集約すると、通知が増え過ぎて閲覧されなくなります。デフォルトではAWS アカウント別にサービスの単位でチャンネルを作成しています。例えば、AWS アカウント A の Amazon GuardDuty のアラートを通知するチャンネルは a-alert-guarddutyAWS アカウント B の AWS IAM Access Analyzer のアラートを通知するチャンネルは b-alert-iam-access-analyzer といった粒度でチャンネルを作成しています。

場合によっては、2サービス以上を1個のSlackチャンネルにまとめて通知したい要望なども出てくることが想定されるので、1個の Slack チャンネルへの通知の集約度合いを調整できるようにしました。

実装

構成

システム構成は以下の図のようになります。

  1. AWS メンバーアカウント内の各サービス(Amazon GuardDuty, Amazon Inspector など)は、メンバーアカウントの AWS Security Hub に通知情報を送る。
  2. AWS メンバーアカウントの AWS Security Hub から、セキュリティ本部の AWS アカウントの AWS Security Hub に Findings 情報を集約する。
  3. AWS Security Hub に送られた Findings 情報は、Amazon EventBridge => Amazon Simple Notification Service (Amazon SNS) => AWS Chatbot を経由して各 Slack チャンネルに通知される。

AWS Security Hub 通知構成図

通知処理は、3 のコンポーネントとなります。

実装

通知のハブ

通知システムを構築しようと考えた当初は、AWS Security Hub を介さずにサービスごとに通知の仕組みを実装する予定でした。

Amazon GuardDuty では新しく Finding が検知されると、Amazon Event Bridge に通知することが可能です。

AWS Security Hub なし

GuardDuty からの通知のみを Slack で受ける場合はこのフローでも良いですが、Amazon GuardDuty と Amazon CloudWatch Events の結びつきが強いので、他サービスへの使い回しが少しやりにくくなります。AWS Security Hub を利用すると、以下のように通知フローが変わります。

AWS Security Hub あり

Amazon Event Bridge が AWS Security Hub から通知を受けることで以下のメリットがあります。

  • AWS Security Hub からの通知フォーマットはどのサービスからのものでも揃っているので、通知の振り分け処理の実装を他サービスにも使いまわしやすくなる。

このように、AWS Security Hub を通知のハブとすることで、他サービスにも展開しやすい構成を実現できるようになります。実際、先月 AWS Health が AWS Security Hub に対応しましたが、AWS Security Hub 〜 Slack の実装を使い回すことで AWS Health の通知も Slack で受けられるように直ぐに設定できました。

振り分け処理

今回構築した通知システムでは、通知内容に応じて通知を送る Slack チャンネルを振り分けています。この振り分け処理は、Amazon Event Bridge の Rule にある Event Pattern を利用して実施しています。

以下は、Event Pattern による振り分け設定の一例です。AWS アカウント(123456789012)の GuardDuty の通知のうち、Severity が MEDIUM 〜 CRITICAL のものが Amazon SNS に通知されます。

{
  "detail": {
    "findings": {
      "AwsAccountId": ["123456789012"],
      "ProductName": ["GuardDuty"],
      "RecordState": ["ACTIVE"],
      "Severity": {
        "Label": ["CRITICAL", "HIGH", "MEDIUM"]
      },
      "Workflow": {
        "Status": ["NEW"]
      }
    }
  },
  "detail-type": ["Security Hub Findings - Imported"],
  "source": ["aws.securityhub"]
}

もう少し複雑な、Amazon GuardDuty の通知は LOW 〜 CRITICAL まで全ての通知が欲しいけど、Amazon Inspector の通知は HIGH 〜 CRITICAL までが欲しい要件の場合は、1つのEvent Pattern で表現することは難しいので、Amazon Event Bridge の Rule の設定を複数作成して対応しています。

このように、Amazon Event Bridge の Rule の Event Pattern を利用することで、柔軟な振り分け設定を実現可能です。

Slack 投稿

AWS ChatBot は、Security Hub の通知をサポートしているので、Amazon SNS から AWS ChatBot に送るだけで以下のように Slack 上にメッセージを表示してくれます。

Slack の通知例

AWS Lambda を利用すればより柔軟に通知メッセージを表現可能ですが、開発と運用(AWS Lambda の実行環境の更新など)の工数が増加するので採用を止めました。

Terraform

heyでは Terraform でインフラ環境を構築する開発者が多いので、実装には Terraform を利用しています。Terraform で AWS Chatbot や、Slack の設定を表現できるか少し心配でしたが、提供されているモジュール(chatbot-slack-configuration)とプロバイダ(slack)を利用することで、表面上は Terraform で実装することが出来ました(chatbot-slack-configuration は、内部的には AWS CloudFormation を利用している)。

運用

費用

今回構築した通知システムの費用ですが、AWS Security Hub => Amazon Event Bridge => Amazon SNS => AWS ChatBot => Slack の通知処理のコンポーネントについては1ヶ月あたり数ドルの費用で済んでいます。もちろん、 Amazon Inspector や Amazon GuardDuty などのサービス個別の費用は別で発生していますが、通知機能自体は数ドルの費用で済みます。現在10アカウントほどの通知を処理しており、今後アカウントが増えても通知コンポーネントの費用はそこまで大きく増えないのではないかと思います。

通知量の調整

AWS アカウントの設定状況により Slack の通知量は変わります。リソース設定の多い AWS アカウントで通知を有効にすると、Security Hub の Security Standards などから大量に通知を受けることもあります。 Security Hub の Security Standards からの通知量をコントロールするために、Event Pattern の設定を調整して通知量を減らしたり、AWS Step Functions を利用して Slack に通知の来た Finding のステータスを自動的に NOTIFIED に変更したりなど、試行錯誤をしているところです。

今後

今後は以下の点に取り組んで、通知環境の整備を進めていく予定です。

  • 他プロダクト(AWS Firewall Manager など)の通知対応
  • まだ追加されていない AWS アカウントを AWS Organizations に追加
  • Slack 通知から対応用の GitHub チケットを作成

採用絶賛募集中!!

今回はAWSで構築したシステムの設計・実装の話でしたが、 hey ではセキュリティエンジニアを募集しています。脆弱性診断やSIEM環境の整備など取り組むべき課題はいろいろとあります。もしご興味ありましたら、カジュアル面談からで構いませんのでお気軽にご連絡ください。

herp.careers

hello.hey.jp