Contents
想定ユースケースと設計ポイント
この節では代表的な通知パターンと運用設計上の基本方針を示します。
重要度に応じて通知経路を分離し、即時通知／集約通知を使い分けることが設計の基本です。
想定ユースケース
代表的な通知パターンを列挙します。運用設計の参考にしてください。
- マルウェア検知（検出・隔離・ブロック）の即時通知
- 検疫や自動対応（クリーン・削除）結果の報告
- エージェントのアップデート失敗や定義同期異常のアラート
- 未接続端末（長期オフライン）の発見通知
- ライセンス期限やサーバヘルスのアラート
- 特定ポリシー違反や高リスクイベントの通知（例: 特定アプリ検出）
設計ポイント
運用設計で優先すべき考え方を示します。短いルールをまず決めてから実装してください。
- 重大イベントは専用チャンネルへ即時通知し、運用チームで対応する。
- 高頻度になりうるイベントは集約または間引きを行う（例: ホスト単位で 10 分間に 1 通に抑止）。
- 低重要度は日次レポートへ集約し、Slack では要約だけを表示する。
- 機密情報はメッセージ本文に含めず、コンソールやチケットへのリンクだけ掲載する。
対応環境と前提条件
導入前に確認すべき環境・権限・ネットワーク要件を整理します。ESET の Cloud/オンプレで差が出る点に注意してください。
対象環境と権限
該当する環境と管理者権限を確認してください。
- 対象：ESET Protect Cloud およびオンプレミスの双方に対応。UI や変数名はバージョン差があるため確認が必要です。
- ESET 側権限：通知／配布（Notifications／Distribution）を作成・編集できる管理者権限が必要です。
- Slack 側権限：Incoming Webhooks を有効にするかアプリをインストールできるワークスペース管理者または承認済みアプリ運用権限が必要です。企業ポリシーで申請や承認が必要になる場合があります。
ネットワークと TLS
ネットワーク接続と TLS 設定の確認点です。
- オンプレ版 ESET から hooks.slack.com（TCP 443）への outbound HTTPS が許可されていること。プロキシ経由の場合は ESET 側に適切なプロキシ設定を行ってください。
- TLS 検証は必ず有効にします。検証無効化は推奨しません。中間 CA 検査（プロキシの TLS 中間解読）がある場合は信頼チェーンの整備が必要です。
バージョン互換性（ESET 変数）
ESET のプレースホルダ（変数）はバージョンによって異なります。管理コンソールの「利用可能な変数」を必ず確認してください。
公式ドキュメント（配信設定）も参照してください。
https://help.eset.com/protect_cloud/ja-JP/admin_ntf_distribution.html
Slack 側の準備とセキュリティ
Slack 側の構成選択（Incoming Webhooks と Bot＋chat.postMessage）と、それぞれの運用上の違いを整理します。セキュリティとトークン管理が特に重要です。
Incoming Webhooks の作成
Incoming Webhooks は最も簡単に Slack に通知を送れる方法です。設定手順の概要を示します。
- https://api.slack.com/apps にアクセスし、アプリを作成します。
- 左メニューから「Incoming Webhooks」を開き、有効化します。
- 「Add New Webhook to Workspace」で通知先チャンネルを選び、許可します。
- 発行された Webhook URL（hooks.slack.com/...）をコピーして安全に保管します。
- Incoming Webhooks の公式ドキュメントを参照してください。
https://api.slack.com/messaging/webhooks
注意点：Incoming Webhooks は URL ベースの認証で、着信側の署名検証がありません。送信元の真正性を担保する必要がある場合はミドルウェアや IP フィルタを検討してください。
Bot を使う設計（chat.postMessage）
双方向操作や署名検証、細かい投稿制御が必要な場合は Bot 経由で chat.postMessage を使います。必要な手順と注意点です。
-
Slack アプリを作成し、OAuth スコープを付与します。最低限のスコープ例：chat:write（メッセージ送信）。チャンネル探索が必要なら channels:read、パブリックチャネルに Bot が入っていない場合は chat:write.public などを追加検討します。スコープ一覧／OAuth は以下を参照してください。
https://api.slack.com/scopes
https://api.slack.com/authentication/oauth-v2 -
アプリをワークスペースにインストールすると Bot トークン（xoxb-...）が発行されます。これを API 呼び出し Authorization: Bearer トークンとして使用して chat.postMessage を呼びます。
https://api.slack.com/methods/chat.postMessage -
Bot トークンは機密扱いです。Secrets Manager 等に保管し、最小権限の原則でスコープを絞ってください。定期ローテーションと監査ログを必ず設けます。
- ミドルウェア経由にすると、ESET の未エスケープ文字を正しく処理したり、レート制御や集約が実装しやすくなります。
Webhook URL / トークンの保管とローテーション
Webhook URL と Bot トークンは企業のシークレットストアへ保存してください。取り扱いの具体例を示します。
- 保管先例：AWS Secrets Manager、Azure Key Vault、GCP Secret Manager、HashiCorp Vault。
- 環境分離：dev/stage/prod で別々の Webhook/トークンを用意する。
- ローテーション手順（例）：
- 新しい Webhook/トークンを作成する。
- ステージ環境でシークレットを更新し、テスト送信を行う。
- 本番で切替後、旧シークレットを取り消す。
- 変更記録（誰が、いつ、なにを変更したか）を残す。
- ロギング時はWebhookを完全出力しない。マスキング例（Bash / sed）：
|
1 2 3 4 |
# Webhook の末尾だけをマスクする例 masked=$(echo "$WEBHOOK_URL" | sed -E 's#(https://hooks.slack.com/services/[^/]+/[^/]+/)[A-Za-z0-9_-]+#\1****#') echo "$masked" |
- 高度な要件がある場合は、Incoming Webhooks の代わりにミドルウェアを挟み、署名検証や IP 制限を実装してから Slack に中継する運用を検討してください。
ESET 側の配信設定とプレースホルダ
ESET 側での配信設定手順と、Slack で使うフィールドへのマッピング例を示します。変数は管理コンソールで必ず確認してください。
配信設定手順
ESET の管理コンソールで配信を設定する一般手順です。UI はバージョンによって異なります。
- 管理者で ESET Protect の管理コンソールにログインします。
- 「通知／配布（Notifications／Distribution）」で新規配信を作成します。
- イベントタイプ（検知、隔離、アップデート失敗等）と重要度フィルタを指定します。
- 配信方法に「Webhook（HTTP/HTTPS）」を選び、HTTP メソッドは POST を指定します。
- ヘッダは Content-Type: application/json を設定し、Accept: application/json を推奨します。
- カスタムペイロード欄に Slack 用 JSON テンプレートを貼り付け、テスト送信で検証します。
- 再試行ポリシー（リトライ回数・間隔）を設定しておくと配信信頼性が向上します。
ESET の配信設定に関する公式ドキュメント：
https://help.eset.com/protect_cloud/ja-JP/admin_ntf_distribution.html
プレースホルダと Slack へのマッピング
運用で使う典型的な ESET 変数と Slack 表示先の割当例を示します。
| 用途（ESET） | プレースホルダ例 | Slack での表示先（推奨） |
|---|---|---|
| 検知日時 | {{detection_time}} | section の日時 / context |
| 端末名（ホスト） | {{computer_name}} | title / fields |
| 検出名（脅威名） | {{detection_name}} | 強調テキスト / title |
| 重要度 | {{severity}} | emoji / color 表示（説明参照） |
| 対応アクション | {{action}} | fields |
| イベント ID | {{event_id}} | context にリンク（コンソール参照用） |
| 検出ファイルパス | {{file_path}} | 短縮またはリンク化 |
| ログオンユーザー | {{user_name}} | fields |
注意：プレースホルダ展開後にダブルクォートや改行が含まれると JSON が壊れる可能性があります。ESET が自動エスケープしない場合はミドルウェアで JSON エンコードしてから Slack に送信してください。
ESET の変数一覧（バージョン別検証）
管理者は利用可能な変数一覧を必ず確認してください。バージョン差による変数名の違いでテンプレートが壊れることがあります。管理コンソール内の「利用可能な変数」表示を参照し、必要なら ESET サポートやリリースノートで差分を確認してください。公式ヘルプは以下。
https://help.eset.com/protect_cloud/ja-JP/admin_ntf_distribution.html
ペイロード設計、JSON エスケープと Block/Attachments の制限
Slack 表示の崩れを防ぐための JSON エスケープ手法と、Block Kit と Attachments の違い、制限事項を実務目線でまとめます。
JSON エスケープの具体例と自動化
プレースホルダ展開後に JSON が壊れる典型例と、その自動エスケープ方法を示します。自動化ツールを使うと安全です。
例：プレースホルダの変換（前 → 後）
- 元の変数（未エスケープ、生データ）
|
1 2 3 4 |
C:\Program Files\Av\scan.exe User: "admin" New line here |
- JSON に埋め込む際に正しくエスケープした文字列（出力例）
|
1 2 |
"C:\\Program Files\\Av\\scan.exe\nUser: \"admin\"\nNew line here" |
自動エスケープ例（jq を利用した Bash）：
|
1 2 3 4 5 6 |
raw='C:\Program Files\Av\scan.exe User: "admin" New line here' payload=$(jq -nc --arg txt "$raw" '{"text":$txt}') curl -X POST -H 'Content-Type: application/json' --data "$payload" 'https://hooks.slack.com/services/XXX/YYY/ZZZ' |
Python（requests + json で自動エスケープ）：
|
1 2 3 4 5 |
import json, requests raw = 'C:\\Program Files\\Av\\scan.exe\nUser: "admin"' payload = {"text": raw} resp = requests.post(WEBHOOK_URL, json=payload, headers={'Content-Type':'application/json'}) |
ポイント：ESET がプレースホルダをエスケープしない場合は、ミドルウェアで必ず JSON エンコード（または jq 等でエスケープ）してから Slack に送ることを推奨します。制御文字は削除または正規化してください。
Block Kit と Attachments の違いと制限
Block Kit が推奨です。Attachments（旧スタイル）は互換性はありますが表示が異なる場合があります。主な注意点を示します。
-
Block Kit は表現力が高く、推奨される最新フォーマットです。詳しくは Block Kit ドキュメントを参照してください。
https://api.slack.com/block-kit -
attachments はレガシーで、attachments.color はアタッチメント部分の色バーには反映されますが、Block と組み合わせた場合に期待どおりに見えないことがあります。Block 自体に色プロパティはありません。
-
Block の上限：1 メッセージあたり最大 50 ブロックまでです。テキストオブジェクトは要素ごとに文字数制限があるため長文は避けてください。詳細は Slack のドキュメントを参照してください。
https://api.slack.com/docs/rate-limits -
全体の HTTP ペイロードサイズや Web API のメソッドごとの制限も存在します。大きなログやスタックトレースは外部ストレージに置き、Slack には要約を送る設計にしてください。
ペイロードテンプレートとテスト送信
Block Kit の最小テンプレート例（フォールバック用の text を必ず含める）:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
{ "text": "ESET: {{detection_name}} on {{computer_name}}", "blocks": [ { "type": "section", "text": { "type": "mrkdwn", "text": "*ESET Protect* :warning: *{{severity}}*\n*日時:* {{detection_time}}\n*端末:* {{computer_name}}" } }, { "type": "section", "fields": [ { "type": "mrkdwn", "text": "*検出名:*\n{{detection_name}}" }, { "type": "mrkdwn", "text": "*対応:*\n{{action}}" } ] }, { "type": "context", "elements": [ { "type": "mrkdwn", "text": "Event ID: {{event_id}} <{{event_link}}|コンソールで開く>" } ] } ] } |
Attachments（互換性を重視する簡易例）:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
{ "text": "ESET alert: {{detection_name}}", "attachments": [ { "color": "{{color}}", "fallback": "ESET: {{detection_name}} on {{computer_name}}", "fields": [ { "title": "端末", "value": "{{computer_name}}", "short": true }, { "title": "検出名", "value": "{{detection_name}}", "short": true }, { "title": "重要度", "value": "{{severity}}", "short": true }, { "title": "対応", "value": "{{action}}", "short": true } ] } ] } |
テスト送信手順の要点：
- 検証用 Slack チャンネルを作る（例：#eset-test-alerts）。
- Incoming Webhook を作成してシークレットストアに登録する。
- ESET の配信テンプレートはテスト用の固定値で検証する。
- curl や requests を使って実際に POST し、表示崩れ・エスケープ問題を確認する。
- Slack 側で表示崩れや改行、リンクの挙動を必ず確認する。
運用・トラブル対応とスケール設計
運用でよく起きる問題と、スケール時の具体的な設計例（レート制御、監査、ローテーション）を示します。
レート制限とスケール設計（429 対応）
Slack の Web API や Incoming Webhooks はレート制限に従います。429 応答時の実装方針と集約設計の例を示します。
- 429 発生時はレスポンスヘッダの Retry-After を尊重して再試行する。指数バックオフ（例：1s→2s→4s、最大 60s）と最大試行回数を設けます。
- 高頻度イベントの設計例（実例）：
- CRITICAL：即時通知、同一ホストで 10 分間は重複を抑止。
- HIGH：即時だがデデュープを 10 分で行う。
- MEDIUM：5 分ごとの集約サマリ（件数と代表サンプルを送信）。
- LOW：日次ダイジェストに集約。
- バースト対応：ESET → キュー（SQS 等）→ ワーカー → Slack の非同期フローにして、ワーカーでレート制御を行うと堅牢です。
429 ハンドリング（Python 例）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
import time, requests def post_with_backoff(url, payload, max_attempts=6): backoff = 1 for attempt in range(max_attempts): r = requests.post(url, json=payload, headers={'Content-Type':'application/json'}) if r.status_code == 429: retry = int(r.headers.get('Retry-After', backoff)) time.sleep(retry) backoff = min(backoff * 2, 60) continue return r return r |
参考：Slack のレート制限ドキュメント
https://api.slack.com/docs/rate-limits
トラブルシュートとログ収集
障害時に優先的に確認すべきログと手順です。
- 取得すべきログ（優先順）：
- ESET の通知配信ログ（時刻、配信先、HTTP ステータス、レスポンスボディ）
- 該当イベントの生データ（event_id、検知詳細）
- ESET サーバのアプリログと OS ログ（proxy 経路含む）
- プロキシ／FW のアクセスログ（送信元IP、送信先、応答コード）
- Slack 側のアプリログ、Enterprise Grid 利用時は Audit Logs
- ネットワーク診断コマンド（例）：
|
1 2 3 4 5 6 |
curl -v -X POST -H 'Content-Type: application/json' \ --data '{"text":"ESET 到達性テスト"}' \ 'https://hooks.slack.com/services/XXXX/XXXX/XXXXX' openssl s_client -connect hooks.slack.com:443 -servername hooks.slack.com |
セキュリティ運用と変更管理
Webhook/トークンの漏洩や誤用を防ぐ実務的なフロー例を示します。
- マスキング例：ログに Webhook を出力する際は末尾だけ表示する、またはトークン部分を伏せ字にする。上記 sed 例を参照してください。
- ロール分離の例：申請者 → 承認者 → オペレータ → 監査者。トークン作成・配布・削除は必ず承認ワークフローを経る。
- ローテーション（定期／緊急）フロー：
- 新トークン作成 → シークレットストア登録。
- ステージングで動作検証。
- 本番切替 → 旧トークンを無効化。
- 変更履歴を記録し、監査ログを保存する。
- 緊急対処：トークン漏洩が疑われる場合は即時無効化し、新トークンを発行、関係者に通知する。
まとめ
設定から運用までの要点を整理します。ここで示した通りに実装すれば運用開始直後のトラブルを減らせます。
- ESET 側で配信テンプレートを作り、プレースホルダは管理コンソールで必ず確認する。
- プレースホルダ展開後の文字列は必ず JSON エンコード／エスケープして Slack に送る。
- 簡易なら Incoming Webhooks、柔軟性が必要なら Bot＋chat.postMessage（chat:write 等のスコープ）を選ぶ。
- Block Kit を基本とし、ブロック数（最大 50 ブロック等）やテキスト長の制約に注意する。
- レート制限（429）に対しては Retry-After を尊重するバックオフ実装と、集約／デデュープ設計を行う。
- Webhook/トークンはシークレットストアで管理し、ローテーションと承認フローを整備する。
参考リンク（公式）：
-
Slack Incoming Webhooks / Block Kit / chat.postMessage / OAuth：
https://api.slack.com/messaging/webhooks
https://api.slack.com/block-kit
https://api.slack.com/methods/chat.postMessage
https://api.slack.com/authentication/oauth-v2 -
ESET 配信設定（公式ヘルプ）：
https://help.eset.com/protect_cloud/ja-JP/admin_ntf_distribution.html