VPNログインアラート：実際にどのイベントで通知すべきか
認証成功、確立されたトンネル、RADIUS accounting Start は三つの異なる主張です。受信者が行動できる主張を一つ選び、それから相関させてください。
認証成功、確立されたトンネル、RADIUS accounting Start は三つの異なる主張であり、ログインのメールはそのどれか一つを選んで初めて意味を持ちます。ほとんどの VPN アラートの設計は三つを混ぜ合わせ、誰も信頼しない受信箱を作り出します。判断の分かれ目は、誰がアラートを読み、次の五分で何ができるかです。ここを誤ると、アラートは本当に必要だった一つのイベントを隠す雑音になります。
三つの問いがトリガーを決める
誰が受け取るのか、その人が何をするのか、その行動はどれだけ速く必要かを問います。資格情報の悪用を監視するセキュリティチームは、一つのアカウントから数分以内に失敗してから成功するパターンを求めます。容量を監視する運用チームは、ログインではなくセッション時間と切断理由を求めます。ヘルプデスクはチケットと照合できるよう、セッションの識別情報を求めます。
それらの答えは異なるイベントを指し、単一のルールでは三つすべてを満たせません。受信者の行動が「利用者に電話する」なら、認証だけで十分です。行動が「ライセンスを解放する」や「トンネルが通信を運んだか確認する」なら、確立か accounting Start しか使えません。行動が「時間を請求する」なら、ログインではなく Stop レコードが必要です。
何かを設定する前に、答えを一文で書き出します。「このメールは、アカウント X が時刻 Z にネットワーク Y からトンネルを開いたことを当番エンジニアに伝え、保守時間帯が使われたかを確認できるようにする。」すべての欄を埋められないなら、トリガーはまだ選ばれていません。
イベントを自分の主張に合わせる
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
この表は依存関係を隠しています。各行が信頼できるのは、ゲートウェイが確実にそれを出力し、収集側が必要なフィールドを保持している場合だけであり、そのため実行している正確なリリースのイベント定義を読む必要があります。「セッション確立」という名前はバージョン間で変わり、意味は名前よりも頻繁に変わるので、定義が曖昧なときはラベルから推測せずセッションのキャプチャを求めてください。
Access-Accept をその後のすべての完了と見なすのが最もよくある間違いです。それは資格情報についての判定であり、セッションではありません。逆の間違いは、ポリシーの一致を承認の証拠として読むことであり、ルールが一致しても次の手順が失敗することがあります。
一つのセッションに一つの通知
一つのアカウント、複数の端末、再送と再接続といった状況では、イベントごとに一通のメールを送ると両方向に誤りが生じ、あるセッションを重複させながら別のセッションを分割します。通知のキーはゲートウェイとセッション識別子にし、アカウント名はキーではなく属性として扱います。ノート PC とスマートフォンを持つ利用者は同時に二つのトンネルを持てるので、どちらもそれぞれの行に値します。
会計レコードの再送は正常なので、メッセージを描画する前にセッション ID とタイムスタンプで重複を除きます。同じ端末からの連続セッションは別々のままにし、保守時間帯の再接続は前のセッションに畳み込まずに可視のままにします。収集側が取り込み時にタイムスタンプを書き換える場合は、保存された値ではなく元のレコードのフィールドで重複を除いてください。
Stop レコードの欠落は不確実性であり、永続的なセッションではありません。ゲートウェイの再起動、収集側の停止、UDP の損失はいずれも隙間を残すため、アラートには、トンネルがまだ稼働中だと誰かが結論づける前にライブのセッションテーブルへ問い合わせる照合経路が必要です。
監査と通知を分ける
監査ストリームとアラートストリームでは役割が異なります。アカウント、ゲートウェイ、セッション ID、タイムスタンプ、終了理由を含む生のレコードは、定型メールがまとめられ、抑制され、小さな当番リストに送られる場合でも保持してください。重大度のしきい値は配信のフィルタであり、告知したいライフサイクルイベントの選択ではありません。
受信者が保護されたレコードを見つけるのに必要な最小限の文脈だけを送ります。アカウント名、内部アドレス、セッションの詳細は機密であり、うまく転送できるメールはうまく漏えいするメールです。
そして端から端まで証明します。通常のログインとログアウト、再接続、同時に二つのセッション、強制的な配信失敗を実行し、一つのイベントをゲートウェイから収集側を経て配信されたメッセージまで追跡します。セッション ID なしでメールが届くなら、契約は不完全です。二つのメールが一つのセッションを説明するなら、相関は壊れています。メール配信が動くことだけを試しているとき、どちらの問題も現れません。