DPI (SSL インスペクション) は暗号化の性質に反するものですが、企業はそれを導入しています

信頼の連鎖。 CC BY-SA 4.0 ヤンパス

SSL トラフィック検査 (SSL/TLS 復号化、SSL または DPI 分析) は、企業部門でますますホットな話題になっています。 トラフィックを復号化するという考えは、暗号化の概念そのものと矛盾しているように思えます。 しかし、事実は事実です。DPI テクノロジを使用する企業が増えています。これは、マルウェアやデータ漏洩などのコンテンツをチェックする必要性によって説明されています。

そうですね、そのようなテクノロジーを実装する必要があるという事実を受け入れるのであれば、少なくとも可能な限り最も安全で最も適切に管理された方法で実装する方法を検討する必要があります。 少なくとも、たとえば DPI システム サプライヤーが提供する証明書などには依存しないでください。

実装には誰もが知らない側面が XNUMX つあります。 実際、この話を聞いて驚く人も多いでしょう。 これは民間の認証局 (CA) です。 トラフィックを復号化および再暗号化するための証明書を生成します。

自己署名証明書や DPI デバイスからの証明書に依存する代わりに、GlobalSign などのサードパーティ認証局の専用 CA を使用できます。 しかしその前に、問題自体の概要を少し説明しましょう。

SSL インスペクションとは何ですか?なぜ使用されるのですか?

HTTPS に移行する公開 Web サイトがますます増えています。 たとえば、次のように Chrome の統計, 2019 年 83 月初めの時点で、ロシアにおける暗号化トラフィックのシェアは XNUMX% に達しました。

残念なことに、特に Let's Encrypt が自動化された方法で数千の無料 SSL 証明書を配布しているため、トラフィック暗号化は攻撃者によって使用されることが増えています。 したがって、HTTPS はあらゆる場所で使用され、ブラウザのアドレス バーの南京錠はセキュリティの信頼できる指標として機能しなくなりました。

DPI ソリューションのメーカーは、次のような立場から自社製品を宣伝しています。 これらはエンド ユーザー (Web を閲覧している従業員など) とインターネットの間に埋め込まれ、悪意のあるトラフィックをフィルターで排除します。 現在、このような製品が多数市場に出回っていますが、プロセスは基本的に同じです。 HTTPS トラフィックは検査デバイスを通過し、そこで復号化され、マルウェアがないかチェックされます。

検証が完了すると、デバイスはエンドクライアントとの新しい SSL セッションを作成し、コンテンツを復号化して再暗号化します。

復号化/再暗号化プロセスの仕組み

SSL 検査アプライアンスがパケットをエンド ユーザに送信する前に復号化して再暗号化するには、オンザフライで SSL 証明書を発行できる必要があります。 これは、CA 証明書がインストールされている必要があることを意味します。

企業 (または中間者) にとって、これらの SSL 証明書がブラウザーによって信頼される (つまり、以下のような恐ろしい警告メッセージが表示されない) ことが重要です。 したがって、CA チェーン (または階層) はブラウザーのトラスト ストア内に存在する必要があります。 これらの証明書は公的に信頼された認証局から発行されたものではないため、CA 階層をすべてのエンド クライアントに手動で配布する必要があります。

Chrome の自己署名証明書に関する警告メッセージ。 ソース： BadSSL.com

Windows コンピュータでは、Active Directory とグループ ポリシーを使用できますが、モバイル デバイスの場合、手順はより複雑です。

企業環境で、Microsoft の証明書や OpenSSL ベースの証明書など、他のルート証明書をサポートする必要がある場合、状況はさらに複雑になります。 さらに、秘密キーの保護と管理により、キーが予期せず期限切れになることがなくなります。

最良のオプション: サードパーティ CA からのプライベートの専用ルート証明書

複数のルート証明書または自己署名証明書の管理に魅力がない場合は、サードパーティ CA に依存するという別のオプションもあります。 この場合、証明書は次から発行されます。 プライベート 企業専用に作成された専用のプライベート ルート CA に信頼のチェーンでリンクされている CA。

専用クライアントルート証明書の簡素化されたアーキテクチャ

この設定により、前述の問題の一部が解消されます。少なくとも、管理する必要があるルートの数が減ります。 ここでは、任意の数の中間 CA を使用して、すべての内部 PKI ニーズに対して XNUMX つのプライベート ルート認証局だけを使用できます。 たとえば、上の図は、中間 CA の XNUMX つが SSL 検証/復号化に使用され、もう XNUMX つが内部コンピュータ (ラップトップ、サーバー、デスクトップなど) に使用されるマルチレベル階層を示しています。

この設計では、トップレベルの CA が GlobalSign によってホストされるため、すべてのクライアントで CA をホストする必要はありません。これにより、秘密キーの保護と有効期限の問題が解決されます。

このアプローチのもう XNUMX つの利点は、理由を問わず SSL 検査権限を取り消すことができることです。 代わりに、元のプライベート ルートに関連付けられた新しいルートが作成されるだけで、すぐに使用できます。

あらゆる論争にもかかわらず、企業は社内またはプライベート PKI インフラストラクチャの一部として SSL トラフィック検査を導入することが増えています。 プライベート PKI のその他の用途には、デバイスまたはユーザー認証用の証明書の発行、内部サーバー用の SSL、および CA/ブラウザ フォーラムで要求されている信頼できるパブリック証明書では許可されていないさまざまな構成が含まれます。

ブラウザも反撃中

ブラウザ開発者はこの傾向に対抗し、エンドユーザーを MiTM から保護しようとしていることに注意してください。 たとえば、数日前、Mozilla 決断をした Firefox の次のブラウザ バージョンのいずれかで、デフォルトで DoH (DNS-over-HTTPS) プロトコルを有効にします。 DoH プロトコルは DNS クエリを DPI システムから隠すため、SSL 検査が困難になります。

類似企画について 10年2019月XNUMX日 発表した ChromeブラウザならGoogle。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

企業には従業員の SSL トラフィックを検査する権利があると思いますか?

• はい、同意を得た上で

• いいえ、そのような同意を求めることは違法および/または非倫理的です

122 人のユーザーが投票しました。 15名のユーザーが棄権した。

出所： habr.com