IP許可リストと承認済みノートPC：二つの異なる統制

承認済みのノートPCだけが接続できるというルールの要望は、多くの場合、オフィスのパブリックアドレスに対するファイアウォールのエントリとして片づきます。そのルールはいまや、そのアドレスの背後にあるすべてのデバイスを通します。要件と実装は同じものではありません。ポリシーが望むものと、アドレスが証明できるものを分けてください。

一つのポリシー要望に含まれる三つの問い

要望を三つに分けます。接続がどこから来るのか、どのサービスに到達できるのか、どのコンピューターが資格情報を提示するのか。送信元アドレスのルールは一つ目に答え、宛先サービスのルールは二つ目に答えます。どちらも物理マシンを特定しません。どちらも多くのデバイスが共有するネットワーク上の項目で動くからです。三つ目には、そのデバイスに発行され、黙って再利用できない資格情報が必要です。

三つの答えを別々に書き出します。ファイアウォールの一行では、三つを名指しする要件を満たせません。

送信元アドレスから分かること

アドレス変換は、ネットワーク送信元のルールが過剰に許可する通常の理由です。一つのオフィス出口の背後のすべてが同じパブリックアドレスとして見えるため、ルールはグループ全体を許可します。VPN内部の固定アドレスにも別の場所で同じ弱さがあります。それはセッションに結びついた割り当てであり、ハードウェアの性質ではありません。受け入れられた資格情報を持つデバイスならどれでもそのセッションを開けます。アドレスはネットワークの制限として扱い、そう説明してください。

それは露出を抑えるのに今も役立ちますが、デバイスの認証ではありません。

アクセスを登録済みの資格情報に結びつける

要件がデバイスの制限なら、VPNが対応するデバイスごとの登録を使い、各コンピューターに別々の識別子を与えます。

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

ストアの一覧は証明書と秘密鍵の有無を示し、検証はチェーンが意図したアンカーに至るかを示します。証明書は、設定されたポリシーの下で受け入れられた秘密鍵の所持を証明しますが、その鍵をエクスポートして複製できる場合、どの物理マシンが持っていたかは証明しません。プロファイルをノートPCの名前にしても、秘密の持ち運びやすさは変わりません。プラットフォームが対応する場合、ハードウェアで保護された鍵と証明ポリシーがより強い結びつきを与えますが、誰が資格情報を受け取れるかは登録側で決める必要があります。

境界を試し、その後で削除を計画する

二つのケースを評価します。承認済みのノートPCとユーザーは接続できるべきで、ユーザーのアカウントだけを持つ別のデバイスは接続できないべきです。設計がユーザーとデバイスの両方の確認を求めるなら、選んだ方法が同じセッションで両方を強制するかを確認します。二つの独立した設定が組み合わさると仮定するのは避けてください。

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

取り消しは受け入れられたデバイスの識別子を削除しなければならず、アクティブなセッションの扱いは独自のテストに値します。TPMや管理対象デバイスのフラグは、マシン上のすべてのプロセスに対する健康証明ではありません。

ネットワークの制限、デバイスの資格情報、登録の判断を、三人の所有者を持つ三つの統制として記録します。それによって境界はレビュー可能になり、アドレスだけでは決して提供できないものになります。