概要
当エントリーでは、Trend Micro Cloud One Conformity(以後C1C)でEmailとSlackへ通知する設定手順についてご紹介します。
正常に受信できるEmailアドレス、利用できるSlackテナントおよび通知先のチャンネルが設定されている事を前提に記載します。
GUIの製品画面は、執筆時点(2021/10)の内容となっており最新のものと一部異なる可能性があります。
C1Cの通知設定とは
CSPM(Cloud Security Posture Management)製品である C1Cでは設定ミス等のリスクを検知した際に、管理コンソール上で確認が取れるのは当然として、検知時に外部へ通知をする機能も有しています。
今回紹介する「通知」とは、以下C1Cの Communication 機能の Notifications を指します。 登録しているAWSやAzureアカウントでルールのチェックに失敗(Failed)した内容について通知するといった内容になります。
詳細は以下オフィシャルサイトの Communication頁を参照ください。
記載のある通り、通知(Notifications)は、Channelと呼ばれる単位で管理され、その通知設定はユーザー側で行う必要があります。
なお、通知できるサービスは以下がサポートされています。
- SMS
- Slack
- PagerDuty
- Jira
- Zendesk
- ServiceNow
- Amazon SNS
- Microsoft Teams
- Webhooks
今回はよくある例として、EmailとSlackで通知設定を行っていく手順をご紹介します。
(参考) C1Cに関する設定変更の通知
AWSやAzureのルールに関する通知ではなく、C1Cの設定変更などの通知については、暗黙で管理者として登録されているEmailアドレス宛に通知がされます。
例: botの実行タイミングを 1h毎 -> 2h毎に設定変更した際のEmail通知
手順
1. 登録アカウントの Settings画面へ遷移
通知は登録されているパブリッククラウドのアカウント単位での設定 となります。
複数アカウントのグループ単位での設定はできません。
C1C管理コンソールにサインインしたら、Accounts の左ペインから対象アカウントを選択した状態で 画面右の [Settings...] を押下します。
2. Communication設定項目のアップデート
Settings画面にて Communication settings 項目にある [Update access settings...] を押下します
3. 通知設定したいサービスの選択
通知で連携できるサービス一覧が表示され、各項目の右に [Configure...] ボタンが表示されるので設定を行いたいサービスのものを押下します。
Email通知の場合
以下手順で Emailの通知設定を行います。
E1. Email通知のChannel作成
[Create an Email channel] を押下します。
E2. 通知する内容の設定
[Configure triggers...] を押下する事で通知する内容の詳細を指定可能です。
こちらの設定は全通知共通となっているので下に記載する 通知する内容を指定する(共通手順) を参照して設定してください。
E3. 通知先の指定
Email通知先を設定する為、[Configure now...] を押下します。
宛先は、手入力でメールアドレスを設定は出来ず、Trend Micro Cloud One で登録しているユーザー情報のメールアドレスを選択する形となりますのでチェックをつける事で指定をして [Save] を押下します。
ここでもし通知先に指定したいEmailアドレスがない場合は、Trend Micro Cloud Oneのユーザー追加を検討してください。
E4. 通知の有効化
Automatic notifications を [ON] に変更すれば通知が有効化されます。 このタイミング以降に検知され尚且つ、トリガーの条件を満たした場合はEmailで通知がされるようになります。
E5. (任意) Channelの追加
[Create another Email channel]を押下すると下に異なるChannel設定の項目がカードのように追加されます。複数Channelを作成し組み合わせる事で通知の条件や宛先によって振り分けるといった設定が可能となります。
Email 通知の実サンプル
指定条件を満たした場合に以下のEmailが通知されます。
- From: support@cloudconformity.com
- Subject: New rule violations
今回は偶然、対象AWS環境にサインインしていない状態にも関わらず少々面白いものが通知されてきたのでご紹介します。
ap-southeast-2(シドニーリージョン)にて、DirectoryService operational issue が通知されたという内容です。
AWSマネジメントコンソールにサインインした状態にて、当該EmailにあるURIを押下すると、 AWS Service Health Dashboard(SHD)の画面の当該Eventが選択された状態の画面へと遷移し、すぐにオフィシャルの当該イベントログを確認する事ができました。
(参考) 対象ルール: Health Events (HEALTH-001)
以下blogを参考に設定するのも良いですが、C1Cを導入したなら活用してこのルールかつ利用リージョンだけを特定のEmailアドレス宛に通知したりSlackで例えば notification-aws-shd のような チャンネルを作成して飛ばす設定を加えるのも良いかもしれません。
Slack通知の場合
以下手順で Slackの通知設定を行います。
S1. Slack通知のChannel作成
[Create an Slack channel] を押下します
S2. 通知する内容の設定
[Configure triggers...] を押下する事で通知する内容の詳細を指定可能です。
こちらの設定は全通知共通となっているので下に記載する 通知する内容を指定する(共通手順) を参照して設定してください。
S3. Slack通知先の設定
Slack通知先を設定する為、[Configure now...] を押下します
(参考) Slackの通知先の設定画面
以下の通りとなっており、先にSlackテナントにてWebhookのアプリを追加し、設定する必要があります。
S4. SlackにてWebhookアプリを追加
当該Slackテナントのアプリ追加より、Incoming Webhook を追加します。
S5. Webhook通知先チャンネルの設定
チャンネルの投稿に通知先のSlackチャンネル名を指定して、[Incoming Webhook インテグレーションの追加]を押下します。 実際には通知先に好ましいSlackチャンネル名称としてください。
Webhook のURIが表示されるのでコピーします。 画面で確認できますが、必要に応じてアプリの名前やらアイコンやらをカスタマイズできるのでお好みで設定してください。
S6. 通知先の指定画面の設定
先程コピーしたURIをペーストし、Channnelに 通知先のSlackチャンネル名を入力して、[Save]します。
どのような内容を通知に含めるか、4つチェックボックスから指定が可能となっていますので、下で紹介する通知サンプルを参照し、通知に加えたい情報にのみチェックをしてください。
S7. 通知の有効化
Automatic notifications を [ON] に変更すれば通知が有効化されます。
このタイミング以降に検知され尚且つ、トリガーの条件を満たした場合はSlackで通知がされるようになります。
S8. (任意) Channelの追加
[Create another Email channel]を押下すると下に異なるChannel設定の項目がカードのように追加されます。
複数Channelを作成し組み合わせる事で通知の条件や宛先によって振り分けるといった設定が可能となります。
Slack 通知の実サンプル
以下がS3バケットをパブリック公開した際に通知されたサンプルとなります。
対象AWSアカウントのAWS マネジメントコンソールにサインインした状態で、[View resource]を押下すると 対象リソース(今回は対象S3バケットの画面)へと遷移し、すぐに実環境の確認が出来るので大変便利です。
通知する内容を指定する(共通手順)
各種通知設定画面から[Configure triggers...] を押下すると、以下の様な画面が表示され、どの条件を満たしたら通知をするかを指定する事が可能となっています。
順に設定できる項目を見ていきます。
Services
通知するものをAWSサービス単位で指定出来ます。
サービスに関連する文字列を入力するとサジェストされるので対象サービスを選択し、[Enter]を押下する事で、通知を受け取るサービスを選択する(厳密には絞る)事が可能です。
(AWSの正式名称ではなく、それっぽい略称となっている点に少々癖がありますが...)
(参考) サービスの複数選択
複数サービスを指定すると以下画面のように選択された状態となります。
Regions
上の Services と同様に通知を受け取るリージョンを絞る事ができます。
Rules
上の Services サービスと同様に通知を受け取るルールを絞る事ができます。
ちなみにC1Cのルールは以下のような一意のIDが付与され管理されています。
AWSサービス略称-XXX(数値連番)
(参考) オフィシャルのルール一覧
Filter tags partial match
挙動を確認中
追ってアップデートします
Filter tags partial match
部分一致のフィルタリング機能です。 DEPRECATEDとなっているので、これから新規で設定を検討していく場合は使わないのが無難です。
Categories
AWS Well Architected Framework 5つの柱と同様の項目から通知を受け取るカテゴリーを指定できます。
例えば、複数Channel設定すればSecurityはこの通知先、Reliablitiyはこの通知先のように分けるような指定が可能となります。
Standards & Frameworks
C1Cで対応している主要フレームワークからそれに該当するルールのみ通知するような指定が出来ます。
組織として準拠に明確な目標があるフレームワークがある場合、例えば金融系の PCI DSS 準拠に関して問題になりそうなリスクを検知した際は内容やレベル問わずこの通知先に飛ばすといった設定が可能です。
Risk Level
C1Cの各ルールに定義されている以下リスクレベルから受け取るレベルを指定できます。
| No. | Risk Level |
|---|---|
| 1 | Extreme |
| 2 | Very High |
| 3 | High |
| 4 | Medium |
| 5 | Low |
以上のデフォルト設定をサマると
全カテゴリー、全フレームワークのチェック項目つまりは C1Cで用意されているルール全てのチェック項目で何らかのFailedが出た場合に通知がされる設定となっています。
大量のルールを通知する内容となっているので、個人検証環境とか特殊な本番環境等を除き多くの環境の場合はデフォルト設定のままでの利用は現実的ではありません。
イメージがつきやすいように例を書くとデフォルト通知設定の状態で、「S3バケットを新規作成しパブリック公開する」といったオペレーションを実施しただけでSlack通知が14件も飛んできました。 (Very High以上に通知設定をした場合は2件です)
管理者視点で通知を受け取りたい内容に絞るべき設定項目とご理解頂き対応を検討ください。
まとめ
C1Cでの通知設定について2例ご紹介しました。
せっかくCSPMを導入したのであれば、管理者として把握しておきたいリスクについては Real-time Threat Monitoring設定に加え、通知設定を是非とも加えたいものです。
ただ重要な通知設定を行っても、それに気が付かなかったりまたは埋もれてしまっては元も子もないので、通知すべき内容と通知された先での対応については、継続的に運用しながら調整や改善を実施していく事も大切です。
