「HDE、添付ファイルをパスワード付きZIPに変換して安易な外部流出を防止」
NTTcomに続いて、またも「他人の不安心理に付け込んで意味の無いモノを売って金を毟ろうとするIT版壷売り」ですか~(^^;
添付ファイルで情報流出する場合を考えてみると
1: 悪意を持った社内の人間が送信してしまう
2: 送るべきでない相手に間違えて送ってしまう
3: 送るべきでないファイルを間違えて添付してしまう
4: 通信経路の途中で傍受されてしまう
と、大きく別けて4種類あります。
まず簡単な所から、1:の場合は暗号化しても防ぎようが無い。
まぁ、これは議論の余地無いからスルー(^^;
次に2:の場合ですが、更に分類して
2-1: 何度か添付ファイルをやり取りしている相手に間違える(A社に送るべきだったメールを間違えてB社に送ってしまったという場合。A,B両社とも取引先などで日頃からメールのやり取りをしている)
2-2: これまで添付ファイルを送った事の無い相手に間違える(固定パスワードを設定していない相手に間違えて送る)
となりますが、
>パスワードは、宛先や送信者、宛先と送信者のペアごとに固定のものをあらかじめ設定できる
という運用(以下、「固定パスワードで運用」と記述)では2-1の場合は守れません。相手はパスワードを知ってますから。
>変換するたびに自動的にランダムパスワードを生成することが可能
という運用(以下、「ランダムパスワードで運用」と記述)でも、パスワード通知者を「受信者」にしているとご丁寧にパスワードまで送ってくれますから(^^;防げません。
2-1の場合で流出を防げるのは「ランダムパスワードで運用」で「パスワード通知者は送信者」となっている場合に限られます。
2-2の場合、「固定パスワードで運用」であれば防げますが、「ランダムパスワードで運用」でパスワード通知者が「受信者」であれば2-1同様防げません。
3:の間違えたファイルを添付する場合ですが、これも分類して
3-1: 元々添付ファイルは無いメールだったのに誤って添付してしまった
3-2: 添付ファイルを取り違えた。または、余分なファイルを添付してしまった
となります。
「固定パスワードで運用」の場合、相手が固定パスワードを知っていればどちらも防げません。
相手が固定パスワードを知らなくて(設定していなくて)3-1の場合だけ防げます。
3-2の場合は正当な(送信者が送ろうとした)添付ファイルを開くために相手が固定パスワードを知っている必要がありますから、当然知っているはずです。
「ランダムパスワードで運用」の場合、パスワード通知者が「受信者」であれば2:の場合と同様防げません。
3-2でパスワード通知者が「送信者」で、パスワードを通知するまでに間違いに気付けば防げますが、それまでに気付かなければパスワードを知らせてしまいますから防げません。
3-1でパスワード通知者が「送信者」なら、来るはずの無いパスワード通知が来るので気付くでしょう。
最後に4:の場合ですが、「固定パスワードで運用」で、パスワードが漏洩していなければ有効でしょう。
また、「ランダムパスワードで運用」でパスワード通知者が送信者になっており、パスワードをメール以外の方法で受信者に通知すれば有効です。
しかし、「ランダムパスワードで運用」で通知者が受信者の場合、または、送信者であっても、パスワードをメールで送ってしまうと、防げないと考えた方が良いでしょう。
「添付ファイルのあるメールは傍受できるが、パスワードのメールは傍受できない」
というのはかなり限定された状況です。
ここまでは流出パターンでの分類でしたが、逆に運用パターンで分類すると
A: 固定パスワードで運用
B-1: ランダムパスワードで運用で、パスワード通知は受信者
B-2-1: ランダムパスワードで運用で、パスワード通知は送信者。パスワードは送信者がメールで送る
B-2-2: ランダムパスワードで運用で、パスワード通知は送信者。パスワードは送信者がメール以外で送る
と4通りあります。
Aで防げるのは流出パターンの2-2:、 3-1:の一部、4:となり、おおまかに言って「取引先への流出は防げないが、赤の他人への流出は防げる」という運用です。
B-1で防げるのは4:の場合の内、メール本文は傍受できるがパスワードのメールは傍受できないという、かなり限られた状況のみ。
B-2-1で防げるのは、B-1に加えて、送信者がパスワードをメール送信するまでに間違いに気付いた時
B-2-2では、1:、3-2:以外のほぼ全ての場合に防げる。
という事になります。
結局の所、意味のある運用形態はB-2-2か、取引先への流出はアキラメてAの形態にするかの2択でしょう。
で、実際そういう運用ができますか?
B-2-2のように、いちいち添付ファイルを送る度に電話するなんてのは現実的には無理でしょう。
受け取る方だって迷惑。
Aの場合でも、相手がパスワード忘れたらどうすんだ?とか、社外の相手にパスワード管理を徹底できるのか?とか、取引先なら流出しても止むを得ないで済むのか?という問題もある。
そもそも、これだけの手間を送信者/受信者双方が対応できるぐらいなら、S/MIMEでもgpgでも使った方がマシ。
ってか、そういう手間をかけられない/かけたくない相手に売ろうとしてるんだから、そういう運用形態で使われる可能性はかなり低いでしょう。
結果「役に立たないモノを何となく安全な気がして入れてしまいました」というオチかと(^^;
IT版壷売りの見分け方:
暗号化してるから安心!と言いながら、鍵を一緒に送ってしまうような運用を許している製品は、ほぼ間違いなく壷(^^;
「鍵を一緒に送らない運用もできます」という言い訳を信じてはいけない。
壷売りが「この壷で梅干も漬けられます。どうです実用性だってあるでしょう!」と言ってるのと一緒。
十分に安全を考慮した製品であれば、技術的には容易に可能であっても、決してそういう運用は許さないはず。
最近のコメント