VPNのルールが一つのファイルのアップロードを止められない理由
サービスに到達することと、そこから出ていくファイルを制御することは、二つの要件です。ルールはファイルが見える場所に置きます。メール、アプリケーション、エンドポイントエージェントです。
小さなチームが業務システムへのリモートアクセスを求め、同じ息で、特定の添付ファイルが社外に出るのをやめさせたいと求める。どちらの要求も一つのVPN変更のように聞こえる。実際には適用点の異なる二つの要件であり、前者を満たすルールは後者には何もしない。まず行為とデータに名前を付け、それを実際に見られるコンポーネントを選ぶ。
一つの要求、二つの要件
第一の要件は到達性についてである。どのユーザーとデバイスが、どのサービスへの接続を開けるか。第二はその接続が存在した後の振る舞い、つまりどの文書を添付・貼り付け・アップロードできるかについてである。トンネルは前者に作用し、設計上、後者には盲目である。
IPレベルの制御はパケットを転送する。マルチパートのアップロードを解析せず、PDFを検査せず、表計算に口座番号が含まれるかも判断しない。それを期待するのは設定ミスではなく、カテゴリーの誤りである。
製品を探す前に、その形のまま要件を声に出す。「ユーザーはファイルポータルに到達できる」と「ユーザーは顧客リストをファイルポータルにアップロードできない」は別の文であり、内容ポリシーを説明しているのは後者だけである。
ファイルを見られるコンポーネントを選ぶ
適用はファイルが読める場所で行わなければならない。メールなら通常はメール基盤かゲートウェイで、すでに添付ファイルを扱い、配信前に評価できる。承認済みサービスへのブラウザーからのアップロードでは、アプリケーション自身が内容を見る唯一の当事者かもしれない。管理されたノートPCがファイルをリムーバブルメディアにコピーする場合、エンドポイントエージェントがその操作を見る。
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
一部の商用リモートアクセススイートは、エンドポイントエージェント、ウェブ制御、データ損失防止モジュールをまとめている。それらのコンポーネントは内容ポリシーを適用できるが、能力はトンネリングではなくモジュールに属する。結果を約束する前に、スイートに実際に何が含まれるかを読むこと。
比較に役立つモデルはMicrosoftの Purviewのデータ損失防止の概要 である。これはポリシーを機密情報の種類、場所、活動で説明している。その語彙は内容と行為についてのもので、IPプレフィックスの話ではない。
TLSはトンネルを越えて生き残るので、そこを計画する
アプリケーションの暗号化はクライアントとサービスの間で交渉され、VPNトンネルはそのバイトを開かずに運ぶ。したがって経路上のゲートウェイは、経路のどれだけを所有していても、添付ファイルを分類する能力を自動的に得るわけではない。
通過中の内容を検査するには、信頼できる証明書でTLSを終端するコンポーネントが必要であり、これはプライバシーと運用の独自の結果を伴う重大なアーキテクチャ上の決定である。VPNプロファイルのチェックボックスではない。クライアントは検査証明書を信頼しなければならず、証明書をピン留めするアプリケーションは壊れ、運用者は以前は読めなかったトラフィックを読む能力を得る。だからこそこの決定はトンネルを運用する者ではなく、セキュリティの責任者に属する。
だからこそ「VPNはこのアップロードを止められるか」への正直な答えは通常ノーであり、その後に具体的な代替案が続く。代替案はアプリケーション水準の制限、メールのルール、エンドポイントポリシーでありえ、それぞれに変更できる担当者がいる。
ルールの前に受け入れテストを書く
内容ルールには一つではなく二つの例、つまり動作し続けなければならない許可された行為と、止めなければならない禁止された行為が必要である。対象範囲のアプリケーションとデバイスから両方を試すこと。一つのブラウザーでしか動かないポリシーは、誰かが求めたポリシーではない。
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload最初の要求はルールを持つコンポーネントが拒否すべきで、二番目は成功すべきである。両方成功するなら、制御は経路上にない。両方失敗するなら、サービスを守るのではなく壊しており、許可された例なしに書かれたルールのより一般的な結果である。
ユーザーが何を見るか、誰が例外を認められるか、管理者が後でどこで決定を確認するかを前もって決める。メッセージのないブロックされたアップロードはサポートチケットを生み、誰も監査できないルールは議論を生む。どちらも、ポリシーが有効になる前に書かれた一文の文書で避けられる。
最後に、二つの要件を別々のチケットと別々の担当者に保つ。「VPN」の下にまとめれば、ネットワークチームが内容の問題を解くよう求められ、トンネルが上がった時点で内容の問題は解決済みと宣言されることが保証される。