提案は妥当だ。十数台のノートPCに散らばった五本のパートナートンネル、五組のクライアントバージョン、五つのヘルプデスク手順、そしてそれらがどう噛み合うかを知るエンジニアが一人。管理されたアクセス層へ移せば、エンドポイントの乱立は解消する。同時にアーキテクチャに新しい対象が生まれる。独自の認可モデルを必要とする共有アクセスサービスであり、誰もが過小評価する障害は、すべてのトンネルを有効にした中央装置が、隣人になることに同意した覚えのない組織間の通過ネットワークに静かになってしまうことだ。そのリスクは設計上の選択であり、ハードウェアが勝手に起こすものではない。以下の作業は、意図しない副作用を受け入れずに利便性を保つ方法である。

各パートナーがすでに署名した契約から始める

設定の前に、そのパートナーが共有ゲートウェイやサイト接続をそもそも許可しているか確認する。個人のリモートアクセスアカウント、端末の状態要件、対話型のMFAフローは、無人の共有トンネルに移せないことがあり、コピーした一つのクライアントIDの背後に従業員をまとめるのは、パートナーがログを監査するまで生き残る近道だ。許可された接続ごとに、宛先範囲、プライベートDNSドメイン、許可された内部ソース、認証の責任者、トンネル障害時の動作を記録する。共有接続を書面で確認するようパートナーに求め、受け入れるソース範囲も含める。口頭の承認は、相手のセキュリティチームが入れ替わる週に意味が変わりやすい。

その記録こそが成果物だ。一社のために書けないなら、そのパートナーは集約の準備ができていない。

宛先だけでなくコンテキストで経路を選ぶ

どの組織も同じRFC 1918空間から選ぶため、二つのパートナーはやがて同じプライベート範囲を使う。通常の経路表一つでは宛先アドレスだけで正しいパートナーを選べないので、重複する範囲には別々のルーティングコンテキストか別の合意済み設計が必要だ。RFC 4364 のフォワーディングドメインのモデルは、この分離がなぜ重要かを説明している。導入側は、ゲートウェイ基盤に同じ性質を求めるためにMPLSを動かす必要はない。

基盤に率直に問う。二つのパートナーが同じ宛先プレフィックスを共有し、なおかつセッションがどの従業員コンテキストから来たかで区別できるか。答えが否なら、その制約はどのベンダーの機能一覧よりも設計を規定する。

答えが是の箇所では、ルーティングコンテキストが文書化し試験する対象になる。traceroute では見えないからだ。

従業員が入力するものとパートナーが記録するものを決める

パートナーの仕事の一部は、アプリケーションプロキシやそのパートナーのコンテキスト内で開くリモートワークスペースに合う。別の仕事は承認済み従業員セグメントからのルーティングされたネットワークアクセスを必要とし、両者は遠端で異なる送信元アドレスと異なる監査証跡を生む。共有された変換後の送信元アドレスは許可リストを満たしつつ、どの端末が何をしたかを隠すので、従業員とセッションの対応を確実に記録し、ゲートウェイのアドレスをIDとして扱うのではなくアプリケーションの認証を残す。それが楽なのは、パートナーが誰がやったのかと尋ねる瞬間までだ。

次に従業員側から実際の作業を一つたどる。何をクリックし、何を求められ、パートナーがログ項目を求めたら何が見えるか。その手順が再現できないなら、設計は未完成だ。

パートナー間の通過を明示的に拒否する

共有ハードウェアは共有された信頼を意味してはならない。拒否は、設定漏れの事故ではなく、名前のある責任者を持つ意図的な規則として加え、そうでなければ成功するはずの要求で両方向から試験する。試験が重要なのは、単に不在の許可は、無関係な苦情を直すために経路を足す次のエンジニアが復活させられるからだ。

拒否を許可の隣にパートナー記録へ書き、人の入れ替わりを越えて意図が残るようにする。

より大きなノートPCではなく共有サービスとして運用する

トンネルの更新、資格情報のローテーション、容量、ゲートウェイの入れ替えは、いまやすべて共有サービスの変更になる。つまり、個々のノートPCには決して必要なかった日程と連絡経路が要る。土曜に失効するパートナー証明書は、もはや一人の利用者の障害ではない。そのパートナーのすべてのセッションが同時に止まる。

パートナー間で拒否された要求が意図どおりに失敗し、許可された従業員の要求が正しい送信元で正しい宛先に届いて初めて、その層を受け入れる。ノートPCの競合を取り除きつつ各パートナーの境界を保つことが要点であり、すべての遠隔プレフィックスがすべての机から届く設計は、問題を移しただけだ。

パートナー、コンテキスト、許可範囲、責任者の小さな表を保つ。障害のとき、誰もが最初にそれを求める。

関連記事