「VPN ログインが失敗したらメールで知らせて」という一文には二つの判断が隠れている。一つ目は通知の届け方で、イベントごとに一通、定期的なダイジェスト、収集器からのアラートのどれかだ。二つ目はメッセージに何を含めるか。一つ目を誤るとメールボックスがあふれ、二つ目を誤るとアラートを実用的にするフィールドが消える。どちらの判断も VPN ログカテゴリを抑止する必要はなく、それをやると監査証跡が静かに破壊される。

三つの配信形態とそれぞれが適する場面

形態適する場面コスト
イベントごとの自動化メール量が少なく、一つのチームが対応する試行が集中するとメールボックスがあふれる
定時ダイジェスト定例の確認、傾向の監視進行中の試行を誰も見ていない
相関を伴う収集器アラート量が多く、SOC を共有している養い調整し続けるシステムがもう一つ増える

選ぶ基準は、誰が対応し、どれだけ速く動けるかであって、どの選択肢が最も設定しやすいかではない。一つの拠点を守る FortiGate 一台なら、イベントごとのメールは正当化できる。同じ設定を、盗まれた認証情報の埋め込み試行を受けるゲートウェイに置くと、一日に数千通のメッセージが生まれ、誰も読まないフォルダに振り分けられる。

件名ではなくイベントレコードから始める

実際に運用しているリリースで、代表的な保存済みイベントを読む。FortiOS 7.4.8 のログリファレンスは SSL VPN へのログイン失敗をイベント 39426 として識別し、そのフィールドには action、user、remip、reason、tunneltype、そして vd がある。転送されたメールの件名からフィルタを設計すると、ファームウェアが別の綴りで書くフィールド名に照合してしまう。二つか三つの実際の失敗を開き、トリガを書く前に識別子が一致することを確認する。そこに掛かる五分は、誤ったイベントで発火する一週間のアラートより短い。

オートメーションステッチはイベントログのトリガをアクションに結びつけるもので、トリガこそがイベント選択を置く場所だ。要件に必要な追加のフィールド条件だけを加えること。少数のフィールドで絞るトリガでも、残りについては未検証の挙動を配ることになる。

対応する置換から簡潔な本文を組み立てる

メールアクション向けのログフィールド置換を文書化しているリリースでは、本文は短くても役に立つ。以下の形は例示であり、採用する前に属性名と置換構文をファームウェアのバージョンで確認すること。

config system automation-trigger
    edit "ssl-vpn-login-fail"
        set event-type event-log
        set logid 39426
    next
end

config system automation-action
    edit "mail-vpn-fail"
        set action-type email
        set email-to "[email protected]"
        set email-subject "SSL-VPN login failed"
        set message "Account: %%log.user%% | Source: %%log.remip%% | Reason: %%log.reason%%"
    next
end

空のフィールドを表示するテンプレートは、イベントにそのデータが無かったことを証明しない。まずフィールド名と置換構文を確認し、次に統制された一回の失敗で試して実際のメッセージを読む。どの装置がメールを送ったかを推測せずに担当者が完全なレコードを見つけられるよう、装置の識別情報と発生日時を加える。

レコードを消さずに量を静める

レート制御、グループ化、相関は配信層に属する。すべてのメールの最低重要度を上げるのは、無関係なイベントを隠す乱暴な手段であり、VPN ログカテゴリを無効にするのはさらに悪い。イベントがまったく書かれなくなる。 承認済みのログ出力先と保存ポリシーを以前のまま正確に保つ。そして代わりに通知経路の方を静かにする。何を抑止したかを記録すること。次の担当者はメールボックスの空白に気づき、それが意図的だったと知る必要がある。

新しい経路が検証できたら、重複する旧メールルールをレビュー済みの変更で廃止する。二つの経路が両方発火したまま終わる、あるいは旧経路を先に無効にしたためにどちらも発火しない、というのはテスト前に片付けをしてしまう典型的な結果だ。

失敗を失敗として読む

認証に失敗したイベントは成功した VPN セッションではないし、イベント内のユーザー名は個人への検証済みの帰属ではない。アカウントが侵害されたと宣言する前に、理由を成功したログイン、既知の利用者行動、繰り返される試行と相関させ、そのどれを確認したかをアラートに書く。

通知は認可された受信者だけに送る。アカウント名、内部の装置識別子、送信元アドレスは運用上機微であり、便宜で肥大する配布リストは漏えい経路になる。実行可能な経路が一つと無傷の監査証跡、それが目的のすべてだ。

関連記事