IPsec が落ちたとき、予備ルートは代替ポリシーではない

ある拠点がトンネルを失っても、ルーティングテーブルにはインターネット経由で宛先へ向かう完全に使用可能な経路がまだ表示されている。誰かがそこへ切り替えることを提案し、その変更をルーティングの修正と呼ぶ。パケットはその道を通れたかもしれない。誰も尋ねなかった問いは、保護なしで到着してよいのかということだ。これは別のテーブルから出た別の答えであり、両者を混同することが障害をインシデントに変える道である。

ルーティングテーブルでは同じに見える二つの結果

到達可能性は、パケットに行き先があると言う。セキュリティポリシーは、そのパケットが途中でどうなるべきかを言い、両者は別の仕組みで強制される。ポリシーが破棄を義務づけられているフローに対しても経路は存在しうるし、その組み合わせは設定ミスではない。二つの問いを切り分けることこそが、障害計画を検討可能にする。

したがって障害時の経路は、認められた結果のどれが当てはまるかを誰かが決めて初めて設計になる。その決定が存在しない間、予備ルートは計画ではなく誘惑である。

ポリシーモデルの判定は二つではなく三つ

IPsec のアーキテクチャは、破棄すべきトラフィック、保護を迂回してよいトラフィック、保護すべきトラフィックを分ける。これは三つの別々の指示であり、真ん中は失敗モードではなく意図的な免除である。これを二つ組として読むことが、トンネルと開かれた道という偽の二択を生む。

存在しない関連付けは、保護ルールを黙って迂回へ昇格させない。ポリシーは依然として保護と言うので、パケットは待つか死ぬ。その振る舞いは書かれたとおりに機能する制御であり、ポリシーが壊れている証拠ではない。

自分のフローの要件を三つの文のどれかとして書け。保護された経路ができるまで止める、別の保護された経路へ切り替える、あるいは IPsec なしで動くことを別途認められた経路を使う、のいずれかである。セキュリティ契約を変えるのは三つ目だけで、それには署名できる所有者が要る。その文は変更記録に残すもので、誰かの記憶に残すものではない。レビュー担当は二つ目を承認し三つ目を拒否するが、どちらも見えていれば妥当な判断である。

迂回は両端が署名する契約である

代替経路には、ルーティング可能なアドレス、到着する場所での明示的な受け入れ、両方向で機能する戻り経路が必要である。拠点のプライベートアドレスは、デフォルトルートがどこかを指しているからといって到達可能になるわけではない。

認証はアドレッシングと同じくらい重要である。トンネルを飛ばして保護を期待する境界に届いたトラフィックは、正しいインターフェースに着地しても拒否されるので、受信側のポリシーがその形を意図的に受け入れる必要がある。遠端が決して同意していない免除は、手順が増えただけの障害である。

フェイルオーバーを機能させるためにセレクタを外したりマップを緩めたりすることは、制御された免除ではない。免除される範囲を広げ、遠端には別のものを強制させたままにし、どの変換規則がフローに一致するかを変えうる。

変換と受け入れは計算を変える

変換は別のアドレスの見え方を提示できるが、順方向と逆方向のマッピングは代替経路と一致していなければならない。片方向のマッピングは、開いてからぶら下がる接続を生む。半分のマッピングは何もないより悪い。進歩のように見えるからだ。

受け入れが後半である。受信側にはこのトラフィックのための明示的な規則、独自のログ、そして午前三時に承認済みの免除と誤りを見分ける手段が必要である。

復旧は設計の一部である

障害がどう検出され、どのポリシーが代替を選び、発生時に稼働していたセッションがどうなるかを記録せよ。フェイルオーバー後に新しい接続は成功しても、古い接続はもはや当てはまらないアドレスに結びついた状態を保つことがある。

要件が継続的な保護であるなら、常に別の保護された経路を優先せよ。保護なしの例外が本当に必要な場合は、送信元、宛先、サービス、期間で境界を定め、それがどう撤回されるかを書き留めよ。

障害だけでなく両方の状態を試験せよ

受け入れはトンネル故障の場合と復旧した場合の両方を対象とし、それぞれにアプリケーション検査を伴う。興味深い結果はパケットが動き続けたことではなく、組織が選んだ契約のもとでのみ動いたことである。

撤回の試験も加えよ。誰も止められない免除は、静かに恒久的なポリシーになっており、それこそが元の規則が防いでいたものだ。有効期限と名前のあるレビュー担当を付けよ。そうしなければ、免除はそれを理解した全員より長く生き残る。