IPsecをShadowsocksに置き換える前に、失われる仕事を書き出す

Webアプリ、データベース、ファイル共有という三つのサービスを一本のトンネルがまとめている。実行が簡単だからと、IPsecをShadowsocksに替えようという声が上がる。その後に続く暗号の議論は、トンネルが同時にいくつもの仕事をしており暗号に関わるのはそのうちの一つにすぎないという点を見落としている。製品を比べる前に、その仕事を書き出そう。一覧は短く、どの項目が一つ欠けても入れ替えは成立しない。

通信がどう取り込まれるかから始める

このプロトコルには二つの半分がある。ローカル側のコンポーネントが接続を受け、宛先アドレスで始まるストリームを暗号化して、リモート側のコンポーネントへ送る。リモート側はその宛先への接続を開き、バイトを中継する。UDPもデータグラムで同じ形をたどる。これは取り込んだフローに対する転送であり、取り込まないフローについては何も語らない。プロキシを明示的に話せるアプリは簡単だが、それ以外はアダプターかルーティング規則がなければ取り込まれない。

何よりも先に、アプリごとの取り込み方法を文書化する。取り込まれない通信は通常の経路で外に出て、サービスが社外で違う振る舞いをするまで誰も気づかない。

宛先とプロトコルをすべて名指しする

リモート側は社内の各サービスに到達できなければならない。そのホストへの暗号化セッションが通っていても、そこからデータベースへの経路が増えるわけでも、クライアントで社内名が解決されるわけでもない。LANを含むと書く代わりに、アドレス、ポート、プロトコルを列挙する。

整った設計を壊す事例として、社内DNS、プロキシ設定を無視するアプリ、サーバーからクライアント向けに開始しなければならないフローを加える。どれも想定ではなく、明示的な取り決めが要る。

暗号化は認可ではない

Shadowsocksの文書化されたAEAD方式は認証付き暗号を提供するので、一族全体を危険だと切り捨てるのは誤りだ。その事実にアクセスの問いを答えさせるのも同じくらい誤りだ。誰がどのサービスに届くのか、人が去ったときにアクセスをどう外すのか、秘密をどこに置くのか、どのコンポーネントが境界を強制するのかを、誰かが決めなければならない。共有の秘密が一つだけなら、保持者全員が同じ範囲を持ち、一人の退場が全員のローテーションになる。

現在のIPsec構成も同じ物差しで測る。その名称は規則が正しいことを証明しないし、一方の設計の磨かれた版と他方の曖昧な版を比べても何も決まらない。

今日の両側にある統制を列挙し、そのうえでどの隙間なら許容できるかを判断する。

運用の仕事を数える

どの置き換えにも、クライアントパッケージ、サーバー更新、資格情報のローテーション、障害対応の担当者が要る。トンネルが使えないとき各アプリがどうするか、失敗するのか、ローカル経路で再試行するのか、待つのかを書き留める。その振る舞いは導入の仕方から来るもので、プロトコルの名前から来るものではない。

Webアプリ一つなら細いプロキシで足りることもある。人ごとの権限を持つ全社ネットワーク接続では、追加の部品が置き換えたトンネルより高くつくのが普通だ。

判断すべきは、どの製品が安全に聞こえるかではない。並べた仕事を、チームが実際に維持できる統制で終わらせられる設計はどれかだ。