前回の続きです。今回は Aggregate した情報のなかからrequired-tags に対し非準拠となっている情報を抽出し、 Slack channel に送信するという通知機能を実装してゆきます

前回までで、 Tag policies, required-tags という 2 つのソリューションを導入し、マネジメントコンソール上で俯瞰できるところまできました。しかし監査チームの人的資源には限りがあるのであり、マネジメントコンソールを開いて見張る、などとすると、運用負荷が増してしまうという問題が浮上します。あくまでも違反の発生時だけ Slack にその旨通知されるというのが理想です。

異なる 2 つのサービスですのでそれぞれの解決策が必要となりますが、まずは reqired-tags からです。 Tag policies のほうは後日にします

設計

前回の最後で触れたように、 当組織の Compliance account には既に Security Hub 用に構成した Chatbot が稼働しております。まず思いついたのは、これに便乗できないかというものでした
Aggregator -> sns -> Chatbot -> Slack みたいなイメージです。

しかし検索しても実装例は見当たりませんでした。どうやら 2020/12 時点ではそのような構成は難しい模様。

結論としてはイベントトリガーは諦めて Lambda function の定期実行で妥協することにしました。
定時起動した Lambda function の方から Advanced Query などで非準拠情報を抽出、成形して Slack に送るという構成です

定期実行の自作 Lambda function という点はあんまりエレガントではないと感じますが、Config Aggregator に依存を限定するという 簡潔性 を優先。
起動周期は一日〜数日に一度程度の想定ですが、これは許容します。だっていくらコンプライアンスと言って、タグがついてるついてないというだけの話ですからね。一分一秒を争って目くじらを立てることでもないかと思います（今のところは）

実装

上記の調査検討過程で、肝心の Aggregator の API は 把握済み でして、 Lambda function の基本的な仕様は固まりました。じゃさっさと書きましょうか
はいできました （笑）。でこいつを sam deploy しますと次のようになります

この画像では、ある Source account の ap-northeast-1 で 1個, us-east-1 で 2個 の EC2 インスタンスが非準拠だというメッセージが来ています

大量投稿抑止機能

上記の画像の例では検証環境のため、数えるほどしか通知は来てませんが、翻って多数のリソースを運用中の本番環境に展開した場合の配慮をします。

というのも、noncompliant resources の数が大量となればそのぶん通知も大量に Slack Channel に投稿されてしまうからです（そういう仕様にしてしまっています）。
いくら非準拠を遺漏なく報告させたいといって、あまりにも大挙して通知が押し寄せてきますと、受け取る方は人間ですから見落としたり、逆に対処する気が失せます。これじゃ本末転倒です。
また今回作成したスケジュールベースの仕様だと Lambda Function のタイムアウトによる制約にも要注意だと考えました。一回の起動で(required-tags 限定とはいえ)全 Source accounts の非準拠情報を網羅しようとしてますのでね。
そこで閾値を設けてそれを超える noncompliant resources 数となった場合は個別のメッセージを省略させるようにしました。この抑止機能が発動した場合は次のように Summary のみとなります

※意図的に抑止機能を効かせるためダミーデータを埋め込んで実行しています
この場合個別の詳細は素直に Aggregated View を見に行くことにします

その他

今回は sam で開発してみましたが楽でいいですね。 Advanced Query もなかなかよいです

次回は Tag policies の方の通知系をやろうと思います

この記事はこちらから 2021/06/22 に転記したものです