VPN分類をキャッシュし、その鮮度を可視化する

キャッシュした分類はルックアップを一度節約し、昨日の見解を今日の判断に凍結する。本当に比べるべきはキャッシュの有無ではない。観測とその鮮度、そしてサイトが選んだ応答である。この三つの境界を失えば、最適化が勝手に方針を作り始める。直すべきは帳簿づけであって、より良いフィードではない。

三つの異なる時計を持つ三つの記録

観測とは、受け取ったフィールド、それが来たフィード、その背後にあるデータセットの版である。鮮度はキャッシュ項目の性質で、ルックアップが走った時刻、項目が信頼されなくなる時刻、最後の更新が何かを返したかどうかからなる。応答は、このリクエスト、このアカウント、この操作に対してサイトがそれについて何をするかである。これらは別々の所有者が作り、別々の速さで劣化する。だからblockedという一つの行にまとめると、その区別が壊れる。

特に注意すべき時計が二つある。ルックアップが走った瞬間は提供者がデータセットを公開した瞬間ではなく、後で行を読む運用者は、それぞれの値がどちらから来たのかを知る必要がある。有効期限と更新は、フィードの文書化された更新モデルと、間違えたときのコストから決めるべきで、他のサイトから借りた数値から決めてはならない。

評決ではなくフィールドを残す

MaxMindの匿名IPに関するドキュメントは、匿名VPN、ホスティング事業者、公開プロキシ、Tor出口を別々のフィールドに分けるフィードの具体例である。登録されていないVPNサブネットが代わりにホスティングの印の下に現れることも記している。これを一つの真偽値に潰すと、運用者が後で監査できる唯一の部分を捨てることになる。

推論はどちらの向きも安全ではない。ホスティングの印はトンネルが使われたことを証明せず、VPNの印がないことはクライアントとサービスの間に何もなかったことを証明しない。これは二つの別の主張であり、一つの真偽値ではどちらも表せない。

項目を検証したアドレスに結びつける

リバースプロキシの背後では、アプリケーションは配備が承認したクライアントアドレスの扱いを使わなければならない。呼び出し側が供給した転送ヘッダーで他人のキャッシュされた評判を選べてはならない。

この失敗は正確性のバグでありセキュリティのバグでもある。ヘッダーを制御する攻撃者は信頼された項目を引き継いだり、被害者を悪い項目に固定したりできるからだ。鍵は自らの基盤が終端した接続から導出し、どの導出を使ったかを記録する。前に複数のプロキシがある場合は、もっともらしく見える最初のヘッダーを信じるのではなく鎖を文書化する。鎖が曖昧なら、導出した鍵と拒否したヘッダーを記録する。インシデントのレビューが尋ねるのは後者だからだ。

証拠がないことは清潔な結果ではない

タイムアウト、壊れた応答、利用できないデータベースは、どれも何にも一致しなかった成功したルックアップとは違う意味を持つ。それらを別々の結果として表し、証拠がまったくないときに保護された操作が何をするかをあらかじめ決めておく。読み取り専用のページとサインイン済みアカウントの操作は、そこで別の規則に従うのが妥当である。

通常の認証を保つこと、または対応済みの検証を求めることは、障害を包括的な許可やサイト全体の禁止として扱うより通常は良い答えである。ルックアップの実行時間を制限し、統合が対応する仕組みで更新の嵐を止める。障害中に古い値を使う場合は、判断の地点でそれを古いと表示し、更新の最後の失敗を見えるようにして、長引く障害が健全な項目に見えてしまわないようにする。選択が何であれ、ルックアップの隣のコメントではなく、方針が適用される場所に書く。

保持も同じ判断に属する。この機能が必要とするフィールドとその背後のレビュー記録だけを残し、それ以上は残さない。IPキャッシュが閲覧履歴になる必要はない。

修正を含む四つのケースを受け入れる

新鮮な結果、期限切れの結果、失敗したルックアップ、後で修正された分類を試す。それぞれが別の分岐を通り、最後の一つだけが誤った制限を取り消せるかどうかを示す。

次に、誤ったブロックの後に通常の利用者がレビューを求める経路があることを確認する。フィードは時に間違うし、待ち行列は設計の一部だからだ。四つのケースを方針の所有者の名前とともにrunbookに書く。設計は、冗長なルックアップを取り除きながら不確実性を保ち、判断が人の手にあることが見えるときに、その場所を得る。