VPN のユーザー名はログパイプラインのどこで消えるのか

セッションはダッシュボードに表示されるのにユーザー名の列は空のままで、最初の反応はパーサを疑うことです。その反応は、値が失われた可能性のある三つの上流段階を飛ばしています。ゲートウェイはポリシーによって識別子をマスクでき、取り込みルールはインデックス前にそれを削除でき、検索時の抽出は単に名前を付けることに失敗することがあります。修正は、どの境界を責任者として証明できるかで決まるため、有用な作業は設定ではなく比較です。

ダッシュボードではなく、一つのイベントから始める

認証イベントを一つ選び、それを識別するもの、つまりゲートウェイのモデルとリリース、認証方式、イベント識別子、タイムスタンプ、送信元アドレスを書き留めます。ユーザー名は、大文字と小文字を区別する検索が存在するフィールドを隠すことがあるため、本人が入力したとおりに、大文字と小文字も含めて追加します。そのイベントを、以降のすべての比較の基準として扱います。

イベントの種類ごとにスキーマは共通ではありません。失敗した試行、クライアントなしの成功したログイン、トンネルの再接続はそれぞれ異なるフィールドを生成することがあり、試行がユーザー認証に到達しなかった場合に識別子を省略するゲートウェイもあります。したがって、一つのイベント種別で列が空であることは、パイプラインの問題の弱い証拠にすぎません。

実際の従業員アカウントではなく、承認されたテスト用の識別子で作業し、比較はログデータをすでに統制しているアクセスルールの内側に保ちます。サンプルを得るためだけに詳細な認証ログを広く有効化すると、測定しようとしているシステム自体が変わってしまいます。

四つの境界を順に比較する

値は四つの地点のいずれかで消える可能性があります。地点ごとに担当者も修正方法も異なります。

値が消える最初の境界で止めます。デバイスの表示と生コピーの不一致は転送またはコレクタ設定を示し、そこが一致していてインデックス済みイベントに値がない場合は変換を示し、インデックス済みイベントに値があるのにダッシュボードにない場合は抽出またはクエリを示します。

この順序が重要なのは、後段ほど情報を失うことしかできず、決して復元できないからです。正規表現は、上流の段階がプレースホルダに置き換えた文字列を取り戻せませんし、プライバシー設定は送られなかった値を説明できません。

送信元でのマスクはポリシーであり、パーサの不具合ではない

Cisco の ASA ログのドキュメントは、ユーザー名の非表示を設定可能な動作として説明しており、無効または不明なユーザー名がどう表現されるかも含んでいます。したがって、送信元イベントでマスクされた識別子は、プライバシーポリシーが求めるとおりの結果である可能性があり、それを解析の失敗として扱うと、制御を弱める要求につながります。

正確な表現はリリースとメッセージ種別によって異なります。あるイベントはプレースホルダを持ち、別のイベントはフィールドを完全に省略し、認証の失敗では名前がまったく含まれないこともあります。過去の不具合報告をすべての欠落した識別子に当てはめるのではなく、そのイベント固有の文書化された動作を確認してください。

マスクが意図的な場合、問いはフィールドをどう復元するかから、監査要件を別の方法で満たせるかへと変わります。セッション識別子、より小さなグループが保持する統制された識別子の対応表、より狭い範囲に限定された認可済みのイベントフィードは、試行されたすべてのユーザー名をすべてのログ閲覧者の前に置くことなく、要件を満たすことがよくあります。

インデックス前の匿名化は取り消せない

Splunk のイベント処理に関するドキュメントは、インデックス前にデータを書き換えたり削除したりする sed 式と変換による匿名化を説明しています。まさにその位置が要点であり、生のイベントは入ってくる時点で変更されるため、検索時の抽出には見つけるものが残りません。

インデックス時の秘匿化と検索時のフィールド抽出は、別の問題を解決します。秘匿化は誰がその値をそもそも見られるかを制限し、抽出はクエリがどの名前を使うかを決めるだけです。ハッシュ化は相関を保つ中間の選択肢ですが、小さなユーザー名空間に対する安定したハッシュは、誰かが候補名を照合できる場合には依然として識別可能です。

保存されたイベントにまだ識別子が含まれているなら、問題は下流、つまりソースタイプ、改行、区切り文字の扱い、フィールドの別名、あるいはクエリそのものにあります。これらは通常の解析の修正であり、プライバシーの境界には触れません。

境界に合った修正を選ぶ

三つの条件が対応を決めます。第一に、プライバシーポリシーは識別子を除外する意図か。第二に、監査や調査のプロセスは識別子、仮名、それともセッションだけを必要とするか。第三に、値は収集、保存、提示のどの境界で必要か。

ポリシーが除外を意図しているなら、制御ではなく要件や提示を変えます。ポリシーが識別子を許しているのに収集が落としているなら、コレクタを修正し、生のイベントを確認します。保存が無傷なら、抽出を修正し、最初に取得した承認済みのイベントに対して検証します。

変更記録に、送信元でマスクされたのか、取り込み中に削除されたのか、抽出で取りこぼされたのかという境界を明記して調査を閉じます。その一文が次のエンジニアに最初に見る場所を伝え、ダッシュボードの苦情が静かに無効化されたプライバシー機能に変わるのを防ぎます。