HTTP証拠の選び方：ゲートウェイ記録かアプリログか

ウェブ監視は目的から始まり、捕捉点からは始まらない。アクティブなクライアントの計数、API呼び出しの計測、メッセージ本文の読解は、それぞれ異なる証拠と異なるプライバシー判断を必要とする。保護されたHTTPSを転送するゲートウェイは、ページ内容ではなく接続を見る。誤った層を選ぶと、豊かに見えて何も答えないデータが得られる。

データ源より先に問いを名づける

データが支えるべき運用判断から始めよう。可用性の問いには計数と時間が、リクエストの問いには経路とステータスコードが、内容の問いにはメッセージ本文が必要だ。内側への各段階は、機微性とエンジニアリングの複雑さを加える。収集を始める前に、トンネルの運用はその判断ではないのだから、サービス責任者とセキュリティ責任者に対象・目的・取扱いを承認させよう。

問いを一文で書き、収集計画の隣に置こう。それが唯一の信頼できる範囲管理だ。

ゲートウェイが示せるものと示せないもの

正しく保護されたHTTPSを転送するゲートウェイは、通常、アドレス、ポート、量を見ており、リクエスト行や本文は見ない。

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

conntrackの一覧はフローと変換を示し、短い捕捉は読めるアプリ内容のないパケットを示す。トラフィックが流れているか、どれだけか、どの端点間か、に答えるには十分だ。これはURLの一覧ではなく、通常のCONNECTプロキシはアプリのTLSを終端せずに暗号化されたやり取りを転送する。その位置からリクエスト経路を約束する人がいるときは、どの構成要素が復号し、誰の信頼の下で行うのかを尋ねよう。

アプリログはほとんどのリクエストの問いに答える

自分で運用するアプリでは、そのアプリ自身が対応するログ記録が、他の誰かの接続を復号せずに、通常はリクエスト水準の問いに答える。

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

ヘルスリクエストはクライアントの位置から可用性を測り、アクセスログはサーバーがすでに保持すると選んだ項目を記録する。URLでさえ機微なパラメータを運びうるので、作業に必要な項目を選び、残りは外に出そう。ログの一行はそのサービスについての証拠であり、利用者がトンネル経由で到達した他のあらゆるサービスの証拠ではない。収集を狭く保つことは保持の問いも小さく保つので、要件を生んだ思考実験より短い期間を設定しよう。

傍受は別個の信頼設計

メッセージ水準の検査が本当に必要なら、TLS傍受は新しい信頼できる端点と、配布・維持すべきクライアント信頼の取り決めを生む。証明書をピン留めするアプリは壊れ、運用者は今や、どのサーバー鍵にも劣らない保護を要する秘密鍵を持つ。証明書検証を弱めることや、証明書をピン留めするアプリに修正を当てることで収集を成り立たせるのは、セキュリティ管理をログ一行と引き換えることだ。信頼の配布がすでに管理されている文書化された検査設計を選び、当局の秘密鍵は共有される何物からも外に置こう。

収集期間の終わりに、設定とその信頼材料を所有者を通じて撤去し、保持した証拠を合意した方針の下で処分しよう。述べた目的に足る信頼できる情報が成功の基準であり、可能な限り大きな捕捉ではない。