アカウント名:
パスワード:
ただし、例えば、以下のように、二次被害の防止の観点から公表の必要性がない場合には、事実関係などの公表を省略しても構わないものと考えられる。(中略) ・高度な暗号化等の秘匿化が施されている場合
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
対策としての暗号化 (スコア:3, 興味深い)
http://www.truecrypt.org/ [truecrypt.org]
1.暗号化したボリューム
2.暗号化したデバイス(ドライブまるごと)
3.ブートセクタも含めたシステムごとの暗号化
の3通り。更に隠しボリューム機能があり、
何物かに脅されてパスフレーズを入力させられる状況になった時に隠し通せるとか。
ファイル削除後の残留磁気対策機能まであったり、
どこのスパイ映画だよと思っていましたが、JAXAあたりは必要かもね。
暗号化されていても漏洩 (スコア:4, 参考になる)
漏洩したが、暗号化していたので、情報を取り出すことは難しいだろう、といった発表にしかなりません。
経産省のガイドラインで、そのように明文化されています。
http://motivate.jp/archives/2006/06/post_92.html
いいえ、その部分は平成19年3月30日に改正されました (スコア:3, 参考になる)
一方 (スコア:0)
なんで半世紀も前の不祥事から学習できないのかねぇ？
Re:暗号化されていても漏洩 (スコア:2, すばらしい洞察)
これって昔から不思議だったんだけど、ちゃんとしたパスワードを設定して実質
解読される恐れがない場合にも、暗号化していないのと同じように漏洩として
報道・非難されるのはおかしいんじゃないのかな、と思います。
暗号化するインセンティブが小さくなってしまうのではないかと。
物理的に媒体を盗まれても、情報として漏洩する心配をなくしておくのも重要
だと思うので。
Re: (スコア:0)
・個人情報が漏洩したか否か
ではなく、
・個人情報を漏洩させた事実を、公表しないとならないか否か
である、という点です。
何かの製造方法等の企業秘密だったら、漏洩した情報が競合他社に渡ることがダメージになりますが、
個人情報漏洩の場合、その事実が公表され、情報の当事者および大衆の心象が悪くなる、というのがダメージです。
>暗号化するインセンティブが小さくなってしまうのではないかと。
暗号化していたら、漏洩を公表しなくて良い、または、漏洩に該当しない、となると、
今度
Re: (スコア:0)
>実質解読される恐れがない場合
こちらを規定できないからでしょう。
文字長や複雑さなど、どんなに強固なパスワードが設定されていたとしても、
「別の場所から漏洩した情報」にパスワード自体が含まれている可能性もあるわけです。
あるいは、「今後、漏洩するかもしれない情報」にパスワード自体が含まれている可能性もあるわけです。
※ そういう意味では、暗号化強度が十分高いという前提はありますが、
トークンを使ったハードディスク暗号化などの場合には、
>実質解読される恐れがない場合
と言ってしまって良いのかもしれません。
可能性という言葉は曖昧なので、範囲は限りなく広がってしまいますが、
ハードウェアを盗まれたということはそのくらいインパクトが大きい話題なんです。
Re: (スコア:0)
最悪の事態を想定して動いてもムダという発想はどうかと。
VPN、SSHやSSL含めて個人情報の取り扱いについては
一切ネット使ってませんって企業はあるのかね。