2024年1月の製品アップデート情報にて、Catoからのアラートとシステム通知に関して Webhook を用いて、ServiceNow・Jira・Slack などのサードパーティ プラットフォームにアラートを送信できる機能がリリースされました。
アラートなどの通知が普段利用しているサービスで気づければ便利ですよね。
なので、Catoが提供しているWebhook機能を実際に試していきたいと思います!
Webhookとは?
Webhookとは、Webアプリケーションに対して、特定のイベントが発生した際に、別のWebアプリケーションに通知の発行が可能になる仕組みです。
Catoクラウドでは、セキュリティルールやSocketがダウンした場合、メール通知のサポートはしておりますが、今回のアップデートにてWebhook機能を用いて、ServiceNow・Jira・Slack などのサードパーティ プラットフォームにアラートを送信することが可能となりました。
CatoクラウドでWebhookを利用するには
CMA(Catoクラウドの管理画面)で行う操作としては
Webhookを機能させるためのルールを作成する
↓
作成したルールを設定し適用させる
といった流れとなります。
Webhookのルールを作成する際に、Webhook 経由でアラートを受信しているサービスの URL と、関連する認証情報をCMAにて入力する必要があるのでその準備が必要となります。
機能を実践してみる
今回行う内容は、Socketのダウンを検知をして、Webhookを介しSlackへ通知を送り、アラート内容の確認が可能であるかを実践していきたいと思います。
ルール作成
まずは、Webhookを機能させるためのルールを作成していきます。
該当箇所は、Administration > Subscriptions > Integrations にて行っていきます。
※機能が反映されていない場合、Administrationmの配下にSubscriptionsは表示されません。
本機能は順次展開されておりますので、反映までに時間がかかる場合がございます。
今回はSlackに通知を飛ばす設定をいれていきます。
Slackの他には現状ですと、ServiceNow・Jira、そしてWebhook 経由でアラートを受信しているサービスに対応しております。
「Connection Details」の項目に、通知させたいサービスのURLを入力します。
今回はSlackに連携させたいため、通知を確認したいチャンネルを作成し、URLの取得を行いました。
そして、取得したURLを「Connection Details」の項目に入力していきます。
入力したURLに対して接続性があるか、画面下にある「Test」にて確認が可能です。
問題ない場合は、「Test passed successfully」と表示が出てきます。
テスト接続は問題なく行えました。
また、アラート内容を下記 JSONのテンプレートにて任意で追加や削除できる項目があります。
今回はデフォルトの設定値にてアラート内容を確認していきたいと思います。
アラート内容に表示できる項目は以下が可能です。
Field | Description |
---|---|
account Id | アカウント ID。Cato管理アプリケーションのURLの番号 |
account Name | Cato管理アプリケーションにおけるCatoアカウントの名前 |
alert Type | アラートの種類 |
content | アラート コンテンツのフリー テキスト、サポートされている形式は以下となります。
|
end Date | 監視対象の問題が終了したタイム スタンプ |
level | アラートのレベルまたは優先度 |
policy Name | ルールのCato管理アプリケーションでのポリシー名 |
rule Id | アラートをトリガーしたポリシールールの一意のCato ID |
rule Name | アラートをトリガーしたルール名 |
site Name | アラートをトリガーしたサイト名 |
start Date | 監視対象の問題が開始されたタイム スタンプ |
subject | アラートの簡単な概要 |
time | アラートが送信されたタイム スタンプ |
title | アラートのタイトル |
設定する内容は以上となります。
作成したルールを設定する
実際にSocketのWANを落としてみて通知が来るか確認してみたいと思います。
Socketダウンの通知やフェイルオーバーが発生したなどの際に通知させたい場合は、
Network>Link Health Rules>Connectivity Health Rules にて設定が可能です。
今回は、Connectivityに関するイベントをすべて対象にし、ダウン状態が1分以上続いた際に、上記で作成したSlackに通知させるといったルールを設定していきます。
実際に、WANをダウンさせてみました。
CMAにて以下のようにDisconnectedのログを検知しました。
すると、Slackにも以下のようにDisconnectedを検知した通知が来ました。
対象サイト、発生時間、アラート内容、接続状況などの情報が確認できました。
通知内容についてカスタマイズでき、通知を即座に確認できるため問題解決の時間が短縮されるなと感じました。
今回行ってみたLink Health Rulesだけでなく、他にもセキュリティ・ネットワーク機能のルールでも通知先としてWebhookの指定することも可能ですので、すぐに気付きたいルールがございましたら、ぜひ活用いただければと思います。
2024年2月時点での、CatoクラウドにてWebhookとしてアラートを飛ばせる機能・設定は以下となります。
Webhook機能でのアラート一覧
Network | LAN Monitoring |
Remote Port Forwarding | |
Connectivity Health Rules | |
Quality Health Rules | |
Security機能 | Internet Firewall |
WAN Firewall | |
IPS | |
DNS Protection | |
Anti-Malware | |
Detection & Response | |
CASB | |
DLP | |
SaaS Security API |
Servicenow・Jira・Slack以外でのWebhook利用時の注意点
今回、SlackにてWebhook機能を確認してみましたが、Servicenow・Jira・Slack以外でのWebhookを送信する場合に設定内容について異なる部分がありますのでそちらを説明していきます。
④Custom Bodyの項目にて、送信先に合わせて Body のカスタマイズが行えます。
テンプレートを選択し、通知先に応じて必要な情報を書き込むことが可能となります。
また、Webhook機能全体の話ですが、1つのルールで複数の宛先(URL)の指定ができないため、通知を確認したいサービスが複数ある場合は通知先ごとにルールの作成が必要となります。
最後に
実際にWebhookの機能を試してみましたが、今回行った活用方法としてはSlackを用いてシステムの異常を検知した時、Webhookを介して即座に通知を送り、管理者が迅速に対応できるようにするという内容を行いました。
ただこういった対応だけではなく、Webhook機能には他にも良い活用方法があるかと思います。
例えば、Socketがダウンをしたことを履歴として残したい際、チケット管理システムやタスク管理ツールにWebhook機能を用いて通知を飛ばし、通知をトリガーにチケットを自動起票し管理の手間を省くなどが可能になっていくかと思います。
他にも、アラートを AWS Lambda に送信し、そこから Amazon Connect を使って担当者に架電するなども実現できるかもしれません。
Webhookの機能を実践してみて、有用性のある自動化や効率的なワークフローが実現できるかもしれないという期待が感じられ、これから有効活用していきたいと思いました。