いくつかのデータ漏洩/損失防止スイートを調べてきましたが、それらのドキュメントでは、HTTPS をどのように処理するかがわかりません。
「漏洩ベクトル」の 1 つは、HTTPS 経由で Web アプリケーションに情報を送信することです。この場合、漏洩を検出する唯一の方法は、情報を復号化することです。
しかし、それを実行するには、中間者攻撃のように、偽の証明書を使用してリモート サーバーを偽装する必要があります。ユーザーが疑ったり苦情を申し立てたりしないようにするには、企業が所有するデバイスのブラウザーに有効な CA として証明書を挿入する必要があると思います。
私の質問は次のとおりです:
- このようなシナリオを直接体験した人はいますか? どのように実装したか教えていただけますか?
- 私の考えは正しいでしょうか、それとも HTTPS を管理する別の方法 (たとえば、エージェントを使用してデスクトップ レベルで使用中のデータを検出するなど) があるのでしょうか?
答え1
これは中間者攻撃「のような」ものではなく、中間者攻撃そのものです。
これを実装するには、リモート証明書を自分の証明書に置き換えるプロキシ サーバーを使用します。その過程で、証明書が有効でないというエラーがブラウザーに表示されます。これが HTTPS と証明書の目的です。そのため、知識のあるユーザーがいれば、情報を傍受していることに気付くでしょう。
ユーザーのアクティビティを記録するプロキシを使用して、何が起こっているのか、どこを閲覧しているのかを記録することもできますが、実際には、可能性誰かがあなたの情報を盗んでいるとしたら、あなたはおそらく、そもそも従業員にとって、そのような行為を正当化するような態度を育む職場を作っているのでしょう。また、携帯電話（カメラで録画）や USB ドライブの使用を禁止する人事ポリシーも必要でしょうし、暗記もさせないようにする必要があるかもしれません。
いずれにせよ、ファイアウォール ルールまたはプロキシ フィルターを使用してそのポートへの送信アクセスを単純にブロックしない限り、何らかの方法で検出されることなく HTTPS 監視を破る「簡単な方法」はありません。そうでなければ、HTTPS の全体的なポイントは無意味です。
答え2
しかし、そのためには、偽の証明書を使ってリモートサーバーを偽装する必要がある。
はい。クライアントが受け入れ可能な機関によって署名された証明書が必要になるだけでなく、クライアントの DNS をポイズニングするか、IP パケット ストリームをリダイレクトする必要もあります。
ローカル CA によって署名された証明書をオンザフライで生成し、それを使用してリクエストをプロキシする HTTPS プロキシを実装することは技術的には可能かもしれませんが、非常に困難だと思います。
HTTPS 経由のデータ漏洩が懸念される場合は、ユーザーに HTTPS へのアクセスを許可しないでください。
紙に何かを書き留めるという問題は解決されません。
唯一の現実的な解決策は、できればハニーポットを使用して、適切な監査証跡を保持することです。
答え3
https の問題は、MiM タイプのソリューションによって実際に解決されます。通常、これはプロキシが発信 https セッションをキャッチし、独自の SSL 証明書で署名されたユーザーにそれらを提供し、外部への https 通信を独自に実行することを意味します。
無料の myDLP ソリューションは、独自の squid 構成を使用してこれを実行できます。また、Websense や symantec などのより複雑なソリューションは、少し強力ではあるものの、同じことを実行します (プロキシ間の負荷分散、きめ細かい証明書管理など)。