アカウント全体を無効にせず、VPN から特定の端末だけを遮断する

従業員が一人、ノート PC が二台、そのうちの一台だけがアクセスを失うべき状況を考えます。アカウントを無効にするのは明白な手段ですが、範囲を誤って罰することになります。一方、端末に保存されたプロファイルを削除するのは制御ではなく提案にすぎません。判断は三つの条件に集約されます。VPN が検証できる端末の識別情報が存在するか、この特定の接続が実際にそれを評価しているか、そして人ではなく端末に何を起こしたいか。この順に答えれば、たいてい実施方法はおのずと決まります。

第一の条件：VPN が検証できる端末の証拠はあるか

送信元アドレスは社内 NAT の背後で共有され、モバイル網では変わります。ホスト名は端末の自称にすぎず、MAC アドレスは簡単に偽装でき、レジストリの値はローカル権限を持つものなら何でも書き込めます。どれも、何かが検証するまでは識別情報ではありません。その端末に対して発行された証明書のような、別個に登録された端末資格情報だけが、アカウントより狭い対象に失効を向けられる唯一の選択肢です。

資格情報は、接続がそれで認証し、試行のたびに証明書チェーンを検証する場合にのみ意味を持ちます。端末のストアに置かれたファイルだけでは何も証明できません。

第二の条件：この接続はそれを評価しているか

端点の属性は万能ではありません。ASA では、Cisco の ASDM DAP ガイド がユーザーの AAA 情報と端点評価の属性を分けており、どの属性が使えるかは使用中のリモートアクセスプロトコル、導入済みの posture ツール、ライセンスによって変わります。レジストリ検査には対応する収集経路が必要で、仮に使えても報告されるのは端点ツールが見た内容であり、そのマシンが信頼できるものだという保証ではありません。

したがって実務的な問いは狭くなります。このトンネルで、このクライアントとこの posture エージェントのもとで、どの属性が埋まった状態で信頼できる形で届くのか。答えがどれも届かないなら、それに依存するポリシーは何にも一致しないか、すべてに一致します。どちらも、避けようとしていたアカウントロックより悪い結果です。

第三の条件：拒否か、修復か、より狭いアクセスか

三つの結果があり、互いに置き換えられません。セッションを終了すればアクセスは完全に失われます。端末を隔離して修復用リソースにしか到達できない状態にすることもできます。あるいはセッションを維持したまま、その端末にまだ必要な少数のものへリソース ACL を削ることもできます。DAP のセッションアクションとリソース ACL は別の問いに答えるものなので、選択は本人にどれだけの巻き添えを負わせるかという話になります。

紛失や盗難のノート PC なら、通常はセッション終了です。posture 検査に失敗したマシンなら、修復のほうが穏やかで、しかも同じくらい効果的です。

証拠が欠けたときに何が起きるかを決める

正常な場合に書いたルールより、既定の経路のほうが重要です。posture エージェントが壊れていて期待した属性が届かないと、それを必須にするポリシーはセッションを許可する既定値に落ちるかもしれません。既定の結果を読み、証拠がない場合を意図的に試験してください。エージェントを外した攻撃者が見せるのは、まさにその状態だからです。

一致する複数の DAP レコードは、単純な先勝ちの順序で解決されるのではなく集約され、ACL の優先順位はレコード選択とは別の仕組みです。厳しいレコードが勝つと決めつける前に、ガイドの集約の説明を読んでください。

既存のセッションを扱い、そのうえで両方の端末を試験する

受け入れルールの変更や資格情報の失効は、すでに確立して通信を流しているセッションに何が起きるかを記述していません。即時の除去が要件なら、次の再接続を待つのではなく、実装が対応するセッション終了と再評価の手順に従ってください。これはインシデント時に最も飛ばされやすい手順であり、ポリシーと結果の分かれ目です。

承認された検査のもとで、同じ許可済みユーザーを使って両方のマシンで試験します。遮断された端末は意図したとおりの拒否または修復の結果を受け、もう一方は認可されたリソースだけを保持するはずです。これにより、本人の他の承認済みアクセスを取り消すことなく端末の境界を検証できます。

この二つの結果を違うものにできないなら、問題はポリシーではなく証拠にあり、ルールの調整では直りません。