VPN ユーザーにはサブネットではなく一つのサービスへのアクセスを

ある請負業者が必要としているのは社内ウェブアプリケーション一つだけでほかには何も要らず、簡単な答えは、その人にサーバーサブネットへのトンネルを渡すことです。それは相手がスキャンする日まで機能します。到達可能性、ルーティング、アプリケーションの許可は、一致させる必要のある三つの別個の制御だからです。

要件はサブネットではなくサービスとして書く

宛先ホスト、プロトコル、ポートから始め、そこへ到達すべきユーザーまたはデバイスのグループを加えます。プライベート DNS ゾーンは、アプリケーションが名前を解決する場合にのみ含め、ID プロバイダーは、サインインフローが必要とする場合にのみ含めます。それ以外はすべて、まだ正当化していない依存関係です。

サブネットはネットワークチームの実装詳細であり、サービスはビジネスが求めたもので、レビューして廃止できる単位です。

依存関係の一覧が三項目を超えるなら、そのアプリケーションには独自の設計議論が必要でしょう。

狭くルーティングし、強制は別の場所で行う

狭いルートやセレクターは、トンネルがどのパケットを運ぶかを伝えるものであり、認可ポリシーではありません。ゲートウェイのフィルター、宛先ホストのファイアウォール、アプリケーション自身の許可モデルが、アクセスを決める場所です。一つのアドレスだけをカバーするルートは良い出発点ですが、決意のあるユーザーを止める制御ではありません。その分離があるからこそ、トンネルを再設計せずにフィルターを変更できます。

逆に、厳格なフィルターを伴う広いルートが正当な場合もありますが、関係者全員がどちらが強制を担うかを知っているときに限ります。

強制の地点を明示的に文書化しないと、次の変更がそれを誤って動かします。

サービスが実際に見る送信元を確認する

宛先が見るのは、変換するかどうかに応じて、クライアントのプールアドレスかゲートウェイのアドレスです。ホストのファイアウォール規則とログは、実際の送信元と一致しなければなりません。複数のユーザーが変換された送信元を共有している場合、そのホスト上のユーザー単位の規則では彼らを区別できず、これは設計上の制約であって不具合ではありません。

変換は、ルーティングを単純にする一方で送信元の同一性を破壊し、監査とユーザー単位の規則にとって重要な点なので、意図的に選んでください。

二つのうちどちらを選んだかを、それに依存する規則の隣に書き留めてください。

アプリケーションの認可は任意ではない

ポートに到達してもロールは付与されません。アプリケーションには、ネットワーク層がユーザーの編集可能なレコードを表現できないため、依然として独自のログインと独自の権限が必要です。社内サブネットからのあらゆる要求を信頼するサービスは、狭いトンネルを一つの侵害された資格情報に対する完全なアクセスに変えてしまいます。トンネルは誰がソケットを開けるかを決め、アプリケーションはそれで何ができるかを決めます。

到達可能なホストが少なければアプリケーション層の誤りを悪用できる場所も少なくなるため、ここで狭い設計は二重に報われます。

ネットワーク規則とアプリケーションのロールは別のシステムに保ち、別々に廃止してください。

許可された経路と拒否された経路の両方を証明する

許可されたユーザーとして接続し、無害な代表的操作を一つ実行してから、到達できないはずの宛先を試します。前半だけをテストする設計はテストされておらず、設計を証明するのは拒否のテストです。規則を変更するたびに新しいセッションでテストし、要求は届くが応答が届かない場合は戻り経路を確認してください。

受け入れテストを通すために転送フィルターを無効にするとテスト対象が変わってしまうので、やめてください。

ユーザーがサービスを必要としなくなったら、リモート ID とアプリケーションのロールをそれぞれのシステムで廃止し、両方を記録します。strongSwan の転送ガイドは経路のゲートウェイ側を扱っています。