私の会社は新しいVPNポリシーを導入しました。接続すると、すべてのトラフィックが会社のネットワークにルーティングされます。これにより、データ盗難の監視を改善できます。
このポリシーは、HTTPSトラフィックに対する中間者攻撃も実行するようです。これが私にとって実際に意味することは、 " https://google.com "にアクセスすると、証明書エラーが発生することです。証明書を検査すると、会社の(自己署名)証明書によって署名されます。
私にとって、これはある領域のセキュリティを損ない、別の領域でそれを助けることになります。これは大企業で一般的なことですか?誰かがISO標準を指摘することはできますか?
これは大企業でよくあることですか?
はい。この機能は、ほとんどのエンタープライズファイアウォールだけでなく、小規模企業向けのいくつかのファイアウォールでも使用できます。 無料のWebプロキシSquidでも利用できます 。そして、いくつかのパーソナルファイアウォールもそれを実装しています。
ますます多くのサイト(無害および有害の両方)がhttps://
、SSLインターセプトの使用が増えることを期待します。暗号化されたトラフィックに関してブラインドであるため、システムの保護に失敗するファイアウォールは誰も好まないためです。
誰かがISO標準を指摘することはできますか?
SSLインターセプトは、既存のSSLおよびPKI標準を利用するだけです。 SSLインターセプトの動作を定義する新しい標準を用意する必要はありません。
Cyber Security Standards については、SSLインターセプトを明示的に必要とするものについては知りませんが、これらの種類の標準についてはあまり知識がありません。ただし、明示的に要求されていない場合でも、SSLサイトへのアクセスをブロックするか、標準でトラフィックの監視が要求されたときにSSLインターセプトを実行することが暗黙的に予想される場合があります。
証明書エラーが発生します。
SSLインターセプトでは、インターセプトするCAを信頼する必要があります。ほとんどの企業では、これらのCA証明書は集中管理され、すべてのコンピューターにインストールされますが、Firefoxのようなブラウザーを使用する場合、Firefoxには独自のCAストアがあり、システムCAストアを使用しないため、役に立たない場合があります。
私にとって、これはある領域のセキュリティを損ない、別の領域でそれを助けることになります。
はい、暗号化された接続を使用するマルウェアとデータ漏洩を検出するために、エンドツーエンドの暗号化を破っています。しかし、エンドツーエンドの暗号化の破綻は会社の完全な管理下で行われるため、外部に暗号化されたままなので、これはほとんどの会社が進んで受け入れるトレードオフです。
ただし、過去には いくつかのSSLインターセプト製品でバグが検出されました (異なる会社間の同じCAのように、失効チェックは行われません...)これにより、セキュリティがさらに弱まりました。
この慣行は、組織がより多くのものを制御しようとするにつれて、またメーカーがユーザーアクティビティをスパイできるように機能を販売するにつれて、より一般的になっています。
私にとって、これはある領域のセキュリティを損ない、別の領域でそれを助けることになります。
はい、ただし、このMITMは、組織が気にしない領域(従業員/顧客などにきちんとしているなど)で、気になる領域(できるようになるなど)に集中するためにセキュリティを損なう可能性があります制御)。
おそらく、会社が発行した証明書をインストールすることで、これらのWebブラウザーエラーの発生を停止できます。私が SSL証明書を要求する大学についてのチャットルーム で述べたように、これは問題にさらされる可能性があります。その場合、証明書は次の脆弱性があるCyberoamからのものでした。「Cyberoamデバイスの犠牲者からのトラフィックを他のCyberoamデバイスで傍受したり、デバイスからキーを抽出して他のDPIにインポートしたりすることが可能です。デバイス」。 (DPI = "Deep Packet Inspection")したがって、その証明書をインストールすることはお勧めしません。
より良いオプションは、VPNに接続しているときにWebを閲覧しないことです。 Webを閲覧しないと不便な場合があります。回避策は、VPNに接続する時間を最小限にすることです。暗号化する必要のある機密性の高い通信のみにVPNを簡単に使用し、使用を停止します。それがあまりにも不便になったら、トラブルを報告してください。十分な苦情がある場合、おそらくVPNは現在のポリシーに問題が多すぎると認識され、ポリシーの変更を検討することにつながる可能性があります。
他のコメント(Arlixによるコメントなど)によると、ISOはこれに関する標準を提供しない場合があります。ただし、これに対応した標準組織はIETFであり、この「ベストカレントプラクティス」のドキュメントに言及しています IETF BCP 188(現在はRFC 7258:「Pervasive Monitoring Is a Attack」) 。これを行うべきではない理由を説明する公式のリソースを探している場合は、これが最善の策かもしれません。このMITM攻撃を実行している企業は、標準に準拠していません。
SSLインターセプト機能の採用に対する2つの最大の障害は次のとおりです。
企業または公共のプライバシー要件(ポリシー)-使用するすべてのSSLインターセプトソリューションがポリシーベース(URL分類およびホワイトリスト機能)を許可していることを確認して、監視したくないサイトを除外できるようにする必要があります。バンキングは良い例ですが、ネットワークまたはデバイスがハッキングされ、従業員/友人のバンキング資格情報が危険にさらされた場合に、責任を負いますか?その議論の一部として、アーカイブおよびコンプライアンス要件を検討してください。
将来のSSLの変更-別名証明書の検証。例-多くのWebサイトがコードでの証明書検証に移行します。これは、クライアントが使用している証明書が実際に送信する証明書と実際に一致することをWebサイトが確認する場所です。これは、コア機能としてMITMを実行するほとんどすべてのSSLインターセプト実装を完全に破壊します。今後の標準の変更やこのような業界のベストプラクティスは、SSLインターセプトの費用や実行可能性に影響を与える可能性があります。