アカウント名:
パスワード:
組織のプライベートネットワーク内の通信を覗くためという話ですが、たぶんプライベートネットワーク内ではなく、外部との通信内容を覗き見るために使われたのでしょう。あくまで、覗き見した場所がプライベートネットワーク内だったというだけで。そうでなくては、Google関連のドメインが不正に使われた理由が不明。
内部統制で社員がどんな動画を見てんだ、どんなファイルをクラウドにアップロードしてるんだ、というような検査をする場合にSSLを使われると内容がわかりません。
最近は内部統制はもちろん、標的型攻撃による情報盗難に対抗するため出口対策をとっているところも多いと思いますが
単にhttp以外通さなきゃ良いんじゃないの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
内部統制として不都合なSSL (スコア:0)
組織のプライベートネットワーク内の通信を覗くためという話ですが、
たぶんプライベートネットワーク内ではなく、外部との通信内容を覗き
見るために使われたのでしょう。
あくまで、覗き見した場所がプライベートネットワーク内だったという
だけで。
そうでなくては、Google関連のドメインが不正に使われた理由が不明。
内部統制で社員がどんな動画を見てんだ、どんなファイルをクラウドに
アップロードしてるんだ、というような検査をする場合にSSLを使われる
と内容がわかりません。
最近は内部統制はもちろん、標的型攻撃による情報盗難に対抗するため
出口対策をとっているところも多いと思いますが
Re: (スコア:1)
単にhttp以外通さなきゃ良いんじゃないの?
Re:内部統制として不都合なSSL (スコア:0)
1. 社内の全てのコンピュータに、「中間者攻撃用証明書」をインストールしておく
2. プロキシサーバなり外向きのゲートウェイなりは、https通信を検出したら、中間者攻撃用証明書の元になった秘密鍵を使って、
リクエストのあった通信先の証明書をでっち上げ、その証明書で自分自身がクライアントとhttpsで通信を開始
3. ゲートウェイは本来の接続先に通常のhttpsで接続してデータをやりとり、クライアントに転送する
と、やれば、社外から見ると元通り。
社内的にも、ルータまでhttpsで保護されているので、社内のハブやらに何かを仕込んでデータを盗み出す事も出来ない。
少なくとも、https直結の場合と同じセキュリティは保てる。
唯一、ゲートウェイが乗っ取られると、全部の通信がだだ漏れだけど、
まあ、これは、通信データを総チェックしたいという要望からしてしょうがない。