AWS Security Hub のカスタムアクションで勘違いしてた話
あけましておめでとうございますー那須です。
今年もマイペースで記事を書いていきます。
Security Hub 知ってますか? 昨年の re:Invent 2018 で発表された新サービスで、セキュリティデータを収集して複数のアカウントのセキュリティ状況を一元的に見ることができます(雑ですまん
どんなふうに触ればいいのかは、クラスメソッドさんのブログを見てくださいませ。
セキュリティ基準は何?
CIS (Center for Internet security) のベストプラクティスを基準にして AWS アカウントのセキュリティ評価をしてくれます。 CIS の中身は↓ここからいろいろ見てください。 AWS に限らず、Azure や GCP、Linux や Windows といった観点でセキュリティのベストプラクティスを提供してくれています。
以前に勉強会で LT した時の資料も載せておきます。
今回お題のカスタムアクション
カスタムアクションは、Security Hub で検知した findings に対して実行できるアクションのことです。 例えば、ある finding についてメール送信したり Slack に通知したり、といった具合です。
Security Hub を調べててカスタムアクションを知った時、「お!これでセキュリティ基準にひっかかったらすぐに通知できて自動修正できるんちゃん?」って思いました。
よしやってみよう!
実際に動かして確かめてみました。
まず Slack の Webhook URL を準備します(画面はないです
そして↓このサンプルスタックで、CloudWatch イベント、Lambda ファンクション、その他もろもろを作成します。
これで準備 OK です。
最後に、カスタムアクションを作成して対象の findings を選択してカスタムアクションを実行します。
↑カスタムアクションを実行すると、このように Slack に通知されました。
めでたしめでたし。。
え?自動でカスタムアクション実行してないやんって?
そうなんです。
カスタムアクション実行する方法はあるんですが、トリガーを設定する箇所がないんですよね。。
(実はあるけど私が見つけられてないだけやでって人がいればマジで教えてください)
なのでカスタムアクションの使いどころとしては、
- どこかに通知する(マニュアルアクションなので用途は限られそう
- 自動で修復する Lambda ファンクションに渡して手作業での運用を減らす(トリガーは手だけど修復作業は自動化
かなーと思ってます。
findings をトリガーにできるように期待しよう
手作業でカスタムアクションを実行するでもいいんですが、findings をトリガーにカスタムアクションを自動実行してくれると嬉しいですねー
そもそも私の使い方が根本的に間違ってる、という可能性はもちろんあります。。