オフィスの Wi-Fi にいるのに VPN を求められるのはなぜか

ノート PC は社内 SSID につながり、証明書の確認も承諾済みなのに、Web アプリは依然として VPN を要求します。二重の手間に見えますが、実際にそうであることもあります。二つのログインは通常、別々の判断を強制し、二つ目がその場所に値するかどうかを知る唯一の方法は、それが何を変えるのかを尋ねることです。

ネットワークへの参加は受け入れの判断である

802.1X の導入は、この端末または利用者がこのネットワークに接続してよいのかという一つの問いに答えます。アクセス ポイントは資格情報を RADIUS サーバーに渡し、応答はセッションを特定の VLAN に置いたり、フィルタを適用したりする属性を含められます。それは受け入れと分割であり、特定のアプリケーションに対する認可ではありません。

セッションが受け入れられると、クライアントとアクセス ポイントの間の無線リンクが暗号化されます。保護はそこ、有線ネットワークの境界で終わります。

その先にあるのは建物内の通常のルーティングで、セグメントが許す内部到達性の範囲に限られます。

EAP-TTLS が実際に保護するもの

EAP-TTLS は認証の際に TLS トンネルを構築し、その中で内部方式を実行します。内部方式はしばしば PAP ですが、設計にそれが現れることは、運んでいるのが TLS トンネルである以上、パスワードが平文で空中を通過することを意味しません。クライアントは依然としてサーバーの身元を検証し、正しい CA を信頼する必要があり、見慣れた SSID はその検証ではありません。内部方式の選択は、資格情報の形式として読むべきで、外側の暗号化についての主張として読むべきではありません。

これは認証のやり取りであり、ノート PC の後続トラフィックのためのデータ トンネルではありません。

認証が終わると TLS トンネルは消え、クライアントのパケットは受け入れられたセグメントを通ります。この二つを混同することが、Wi-Fi の暗号化がすでに VPN の仕事をしているという思い込みの根です。

VPN は二つ目のもっと狭い判断である

VPN は別の問いに答えます。この ID はどの私的リソースに到達してよく、どのような条件で許されるのか。VPN は独自のポリシー、独自の ID チェック、そして多くの場合独自の端末状態の要件を持つゲートウェイで終端し、トンネルが上がった後の到達可能な集合は通常、建物の内部ネットワークより小さく、役割に固有です。

だからこそ、保守の役割は他の誰と同じように Wi-Fi に受け入れられながら、管理サブネットに到達するためにトンネルを必要とします。Wi-Fi の判断はアクセス ポイントで行われ、この判断はゲートウェイで行われます。

どちらの段階も暗号化されていながら、無関係なポリシーを適用できます。

位置に基づく信頼が崩れるところ

オフィス ネットワークを暗黙に信頼できるものとして扱うのは、ネットワーク上の位置が接続の性質であり、人の性質ではないという単純な理由で失敗します。NIST のゼロトラストの指針はそれを直接述べており、リソースへのアクセスが建物単位ではなく要求ごとに決まるのはそのためです。同じ SSID に参加する者は誰でも同じ位置を継承します。職員ネットワーク上の侵害されたノート PC が、ゲスト ネットワーク上のものと同じ懐疑に値するのも同じ理由です。

実際の帰結は、アプリケーションの認可が依然として必要だということです。サブネット全体を許可する VPN に、そのサブネットからのあらゆる要求を信頼するアプリケーションが加われば、悪い日の一歩手前です。

どちらの層も、異なる範囲の問いに答えているため、他方を置き換えません。

二つ目のログインがその場所に値するかを見分ける方法

ネットワークの所有者に、VPN が接続した後に何が到達可能になるのか、そしてそれを許可するためにどの ID や端末の条件が確認されるのかを尋ねてください。次に、実際に何が応答するかを試して答えを検証します。トンネルが到達性も保証も変えないなら、それは制御ではなく運用上の習慣かもしれず、それは利用者が回避すべきものではなく所有者の判断です。

トンネルなしで到達できるリソースはトンネルを飾りにしてしまうため、意図しない直接経路も探してください。

あらゆる境界とその目的を記録すれば、次の人はなぜログインが二つあるのかを推測せずに済みます。