目次
本当に久しぶりに記事書きました、那須です。
Japan APN Ambassador Advent Calendar 2020 の 4 日目のエントリです。昨日は AWS 相澤さんによる APN Ambassadorってなんだ？ でした。記事内の「オススメの勉強法」にも書かれていましたが、実際に手を動かして試すと言う行動が一番自分には合っていますね。やれる範囲はどうしても少なくなるのですが、やったことについては自信を持って説明することができる場面が増えました。
私も APN Ambassador の一人として活動していますが、最近 3 ヶ月ほど記事を書けていませんでした。アドベントカレンダーを機に、今日は久々に技術記事を書きます。
今回のネタ
お客様の AWS アカウントを多数運用されている方は多いと思います。さらに AWS アカウントごとにセキュリティ施策も実施しなくてはいけません。今では Security Hub を有効化すれば AWS の基本的なセキュリティのベストプラクティス標準などを簡単に取り入れることができるようになっています。
ただ、AWS アカウントごとにログを確認したり毎月の定例作業等で初めて状況を確認したりする運用だと、どうしても初動対応が遅れてしまいますよね。メールでもチャットでもなんでもいいので、何か異常を検知したら早めに通知だけは欲しい、といった要望はよく聞きます。
そこで、今回はいろんな AWS アカウントから Security Hub の結果をなるべく早めに Slack に通知するための仕組みをご紹介しましょう。
全体像
簡単に構成図を描くとこのようになります。左側がお客様、右側が自社の AWS アカウントです。
Security Hub の結果で指定した条件に引っかかるものがあれば、EventBridge で自社の EventBridge にその内容を渡します。その後、自社アカウント内で SNS や Chatbot を経由して Slack に通知する、といった流れです。実際には、左側の AWS アカウントはお客様の数やサービスの数だけ存在する形です。
すでにお気づきの方もいらっしゃると思いますが、Security Hub では複数の AWS アカウントから結果を集約して管理できます。なのでこのような EventBridge を使った仕組みは本当はいらないのですが、すでに複数アカウントで Security Hub を有効化して管理アカウントに集約している環境に対して、さらに自社の Security Hub 管理アカウントを経由して結果を通知するような場合にのみこの構成が使えると思います。
「じゃあすでにある管理アカウントとかお客様アカウントで Chatbot 使ったらええやん」といったご意見もあるかと思います。これにはちょっと個人的に抵抗がありまして、Chatbot を Slack ワークスペースと連携すると全てのパブリックチャンネル名が見えるようになります。IAM ユーザや IAM ロールの権限次第ではあるのですが、「突然チャンネルに全然関係ない何かが流れ始めたで！？」といったような混乱が発生することも考えられるので、Chatbot の利用は自社アカウント内のみにしたいと思ってこのような構成になりました。Lambda function で直接 Slack に通知すればいいとも思ったのですが、なるべく簡単かつシンプルな設定だけで実現したかったので、今回の案を考えてみました。
設定の流れ
自社の AWS アカウント設定
最初に自社の AWS アカウントでイベントを受け付けるための設定を行います。
まず、SNS Topic と Chatbot の関連付けを行いましょう。step-by-step で画面を貼ろうと思ったのですがほとんどの内容をお見せできないので、出来上がった画面だけお見せします。Chatbot コンソールで Slack ワークスペースと連携し、その後特定のチャンネルと SNS Topic を関連づければ OK です。
続いて EventBridge コンソールで「ルールを作成」を押します。
Security Hub で結果が追加された時に動くようにしましょう。こうすると何でもかんでも Slack に通知されるように思えますが、実際にはお客様側の AWS アカウントでフィルターを設定しますのでこれで OK です。
お客様ごとに通知先の Slack チャンネルを分ける想定なので、イベントバスをお客様ごとに作成して指定しています。分ける必要がなければ default でもいいのかもしれません。
Chatbot と関連付けた SNS Topic を指定しましょう。これでイベントバスに入ってきた情報を Slack に送ることができます。
これで自社の AWS アカウントの設定は完了です。次にお客様側 AWS アカウントを設定しましょう。
お客様側 AWS アカウント設定
EventBridge コンソールで「ルールを作成」を押します。
パターンを定義しましょう。ぴったりハマるパターンがなかったので、カスタムパターンを指定して自分で作成しました。
カスタムパターンの内容は↓こちらです。チェックに合格しなかった項目で、かつ重要度が「Critical」と「High」のものだけ通知するようにしています。ここでフィルタするようカスタムパターンを設定しないと、全ての結果が送られることになるので注意しましょう。
{
"source": [
"aws.securityhub"
],
"detail-type": [
"Security Hub Findings - Imported"
],
"detail": {
"findings": {
"Compliance": {
"Status": [
{
"anything-but": "PASSED"
}
]
},
"RecordState": [
"ACTIVE"
],
"Severity": {
"Label": [
"CRITICAL",
"HIGH"
]
}
}
}
}最後にターゲットとして自社の AWS アカウント内のイベントバスを指定しましょう。イベントバスに送信するための IAM ロールも必要になりますので、準備して指定します。デッドレターキューまでは設定していませんが、必要に応じて失敗した時の設計も行いましょう。
設定はこれだけで完了です。
テスト
最近はほとんど対応してしまったせいか検知するものがなくなっているので、過去に実際にお客様 AWS アカウントの Security Hub で重要度 High のものが定期的に出ていたのでそれを通知できるか試した時の画面を紹介します。検出されたらわりとすぐに Slack に通知されましたよ。
さいごに
AWS Organizations やそれ以外のサービスでアカウントの情報を集約するのがほぼ当たり前みたいな雰囲気になりつつありますが、お客様にてそのように AWS Organizations 等を活用している環境を我々が運用する場面もあります。そのような場合に今回ご紹介した仕組みが運用で役に立つんじゃないかなと思います。
今回は Security Hub の例でしたが、Chatbot がサポートしているサービスであれば同じようなことができると思いますので是非やってみてください。また、Slack のようなチャットじゃなくメールでの通知はもっと簡単（SNS Topic でメールアドレスをサブスクリプションに入れるだけ）なので、チャットが使えない環境にいる方でも応用はできると思います。
EventBridge はサーバーレスアーキテクチャ関連の資料でよく使用例が出てきますが、このようにシステム運用でも使い道がたくさんありますので皆さんも EventBridge を是非使ってみてください！
- カテゴリー
- タグ
この記事をシェアする
