VPN から VLAN へのアクセス: ルールより先にマトリクスを作る

役割を一方に、サービスを他方に。五つの確認で、曖昧な VPN から VLAN へのアクセス設計を、ファイアウォール担当者が実装できる表に変える。

ファイアウォールの構文ではなく、マトリクスから始める。役割を一方に、サービスを他方に置いた表なら、アプリケーションの担当者が確認し、セキュリティの担当者が議論し、ゲートウェイを持つ誰かが実装できる。その確認は、誰も合意していないルールをデバッグするより安い。

一時間書けば、あとで一週間分のルール考古学を省ける。設計が語るのは誰がどのサービスに届くかであり、そこが再採番のあとも残る部分だ。

ステップ 1: ネットワークより先に役割を名づける

スイッチではなく人から始め、遠隔から接続する各グループと、そのグループが何をするかを述べる一文を書く。たとえば在庫水準を読む倉庫担当者や、一つの連携を保守する請負業者だ。二つのグループが同じアクセスを受け取るなら、この目的では一つの役割である。

組織図のためだけに存在する役割があれば、ここで止める。独自のサービス需要がない役割は同じセルの行になり、同じ行は後で便利だからという理由でサブネット全体を渡す誘いになる。人々が何をするかで分け、誰が経費を承認するかで分けない。小さなオフィスでは六つの役割はたいてい多すぎ、三つが正しいことが多い。

ステップ 2: 各セルをサービスの記述に変える

「アプリケーション」と書かれたセルは検証できないが、「スタッフプールから ERP ホストへの 443 番の HTTPS」と書かれたセルは検証できる。ネットワーク名をすべて宛先、プロトコル、ポートに置き換え、そのうえでサービスがそれなしでは動かない依存関係を加える。内部リゾルバや ID プロバイダなどだ。

CheckPasses whenStop if
Destination namedHost and port appear in the cellCell names a VLAN or a subnet
Direction statedInitiator and responder are both clearCell implies two-way access
Dependency listedDNS or identity path is explicitWhole infrastructure range is granted
Negative case writtenAt least one denied pair is recordedOnly allow rules exist

方向の列が最も高くつく間違いを捕まえる。スタッフがアプリケーションを開く許可は、アプリケーションサーバーがスタッフのノート PC へ戻る接続を開く許可を意味せず、最初の方向を許すステートフルなルールは二つ目の方向も許すものとして読まれがちだ。

ステップ 3: ID がポリシーになる場所を決める

誰かが 認証済みセッションをゲートウェイが強制できる役割に変換する必要がある。対応する選択肢には、認証バックエンドが配るグループポリシー、信頼されたセッション属性、役割ごとに分けたアドレスプールがある。三つとも機能するが、クライアントが送るラベルは機能しない。フォーラムの投稿が説明する方式ではなく、自分のゲートウェイが文書化している方式を選ぶ。

VLAN に属しているように見えるだけのアドレスを割り当てるのは、別の衣装を着た同じ無回答だ。OpenVPN のファイアウォールルールに関する Netgate のガイドはその分離を明快にしており、トンネルを立ち上げさせることと、その中を通信が通ることを許すのは別の判断だ。

どの方式を選び、どこで設定されているかを書き留める。役割が変わるとき、そのメモが一つの編集と三つのインターフェースを探し回る手間の差になる。監査人に最初にどこを見るべきかも伝える。

ステップ 4: 宛先が見る送信元アドレスに注意する

転送ポリシーは境界での実際の送信元と一致していなければならない。ゲートウェイが VPN クライアントを自分のアドレスに変換するなら、下流のファイアウォールはすべて一つの送信元を見ることになり、役割ごとの判断を失う。クライアントのアドレスを保つなら、そのプールの戻り経路が必要だ。

最終的なルールを書く前に両方向を試し、観測された送信元を各セルの横に記録する。同じ確認を二つの異なる役割から実行し、結果を比べる。どちらもゲートウェイのアドレスを示すなら、役割の区別はすでに失われている。ゲートウェイが送信元変換を行っているのにアドレスが保たれると仮定したマトリクスは、最初の下流 ACL で失敗する。

ステップ 5: 出す前に各セルを試す

許可された各セルを代表的な操作一つに、拒否された各セルを否定的なケースに変える。どちらも、試している経路を迂回するゲートウェイのコンソールからではなく、実際の役割のクライアントから実行する。

# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health

# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22

# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'

つながってしまう否定的なケースは偶然ではなく発見であり、ルールが直るまで失敗したセルとしてマトリクスに残す。テスト用のコマンドは表のそばに置き、次のレビュー担当者が推論を組み直すのではなく再実行できるようにする。

完成した表は、それが書かれたゲートウェイより長く生きる。ルールはファームウェアやベンダーとともに変わるが、請負業者が一つのプロジェクトサービスに届くという行は、その仕事が変わるまで正しいままだ。

関連記事