10年前なら、ワープロ化する文書というのはある程度限られていた。ワープロ自体、高かったし、重かったし、使い勝手もいまいちだった。ところが今や殆どの文書がワープロ化されている。手書きでなければ認められないなどというものは、役所関連を除けば相当少ないんじゃないかなあ。
システム開発関係のドキュメント類なんて、特にワープロ化される傾向が強い。プログラム修正の度に全部手で書き直すなんて非効率だし、差分だけを書いて綴じていくと今度は一覧性が無くなる。したがって書き直しが容易なドキュメントのワープロ化のメリットが大きい。さらにはこの業界、キーボードアレルギーの人が皆無。それなりにコンピュータの操作も慣れている。
ドキュメントの全ワープロ化のためには、パソコンの一人一台体制が不可欠であるが、さすがにコンピュータ業界、その辺の普及は速い。
そんなこんなでドキュメントワープロ化はどんどん完成に近づいてきた。それどころか表計算ソフトなどというのも普及した。おかげでドキュメントは電子化されるのが普通になった。それ自体は全然悪いことではない。これが一つの社内でのことであれば、さほど問題とはならなかったはずだ。しかし電子化されたドキュメントが複数の会社でやりとりされるようになると、やや面倒な話になる。特に請負契約の場合。プログラムとドキュメントの修正を依頼するということは、電子データ、早い話がフロッピーディスクあたりを受け渡しして仕事を依頼することになる。
本来はフロッピーであっても、手書きドキュメントであっても取扱時に留意することに特に違いはないはずである。だからフロッピーの受渡による情報漏洩対策は基本的なことながらしっかりやっている。例えば協力会社にドキュメントの作成／修正を依頼する場合には、同じフロアや建物に常駐してもらって、そこで作業をやってもらっていることが多い。
ところが、データはコピーしやすい、とかいう理由により、やたらマークされるようになった。人知れず持ち出しやすいんだそうだ。言いがかりとも言い切れない。電子メールやイントラネットが普及して、かつPHSなどで接続できるようになると、こちらの提供ドキュメントもワイヤレスで人知れず送信されてしまう可能性はある。元々ドキュメント等の外部送信は許可していないし、実際行われていないわけであるが、これが守秘義務契約上禁止されているかというと、実はグレーである。
ドキュメントが手書きの時代は、ドキュメントを貸し出すときに貸出簿につけてもらうなどして秘密情報であることが分かるような管理形態をとることができていたが、ドキュメントがデータになってから、この辺があいまいになっている。電子データに「対外秘」の表示をすることは難しい。修正前にバックアップをとるのは基本であるが、バックアップファイルが多くなると、やがてそれらの管理はずさんになってゆく。半年前の仕事のバックアップなんて、もともと秘密データだったかなどと気にしていたりなどしないことも多い。
現在のところは、きっちりと管理された手書きドキュメントを扱っていた人が残ってくれているため、文書データでもそれなりに管理してもらえているが、次第次第に世代交代が進んできた。そして新しい人は、良くも悪くも電子メール等のテクノロジーに馴染んでいる。ネットワークを通じたデータ転送にそれほどの抵抗感を感じまい。そこに大きな情報漏洩の落とし穴が生まれてしまったわけである。さらには、個人情報保護法が成立し、個人情報の漏洩が生ずると大きく取り上げられるようになってきた。すると例え「個人」情報でなくとも、普通の内部情報漏洩も同じように問題視されるようになってきたのである。個人情報は個人のものであり、企業はその管理を受託しているだけなので漏洩したら個人に対する大問題、内部情報は企業の者であるから、漏洩しても企業内部の問題というふうに、本来両者は大きく違うものなのだが、同じように取り扱われる以上、生ずるレピュテーショナルリスクは同等となってしまっている。従って、設計書・仕様書といったドキュメントのファイルの流出も個人情報と同程度の「絶対」さで防がなければならない、こととなった。（まあいずれにせよ「絶対」流出禁止なのだが、なんでも「絶対」というと「絶対」にランクができてくるという凄いことになる。まあ「無限」にも大小があるんだからいいかな。うーん球の表面の点の数と平面上の点の数は共に無限なのだが引き算すると１が残るというのは感銘。）
ここで求められる電子化されたドキュメントの流出防止は、最近のソリューションの一つのテーマとなっており、製品もいろいろと出回っている、日立の秘文、トリニティのpirates Buster for Document Enterprise、ハミングヘッズのSecurity Platform、さらにはMicrosoft Office 2003のIRMといったところである。
ただし、これらのソリューションには共通の前提がある。各PCがネットワークで繋がっていることだ、いわばネットワークで共有されたファイルのみを保護するのである。ところが、請負契約を結んだ協力会社が常駐している場合、そこで使用されているファイルを保護することはできない。協力会社の使用するパソコンはネットワークに繋がっていないし、つなげたとしても請負契約であるから内部を監視するわけにはいけない。
また複数の協力会社がある場合、それらのパソコンを同一ネットワークに繋ぐと協力会社の情報資産を危険にさらすことにもなる。
さらにはネットワークに繋がったファイルサーバーに関連するファイルがそろっていることになるから、クラックされたときの被害は極めて大きくなる。隣り合うサブシステムを別の協力会社に依頼すれば、おのおののドキュメントが漏洩したときの被害はある程度限定できるが、ひとかたまりで抜かれてしまえば利用価値は大きくなる。つまりその分、クラックの誘因も増える。従って、このような場合に情報漏洩を防ぐには、提供したファイルのバックアップ、コピー、メール添付を不能とする必要がある。しかも提供ファイルを編集中は、これが重要情報であるとの表示をしておかなければならない。
たった一つの条件を満たしてくれれば、これらはそんなに難しいことではない。提供先の協力会社が、進んで提供ファイルの情報を守ろうとしてくれることである。この場合であれば、情報漏洩防止策自体必要ない。せいぜい先方が過失で情報漏洩してしまうことを防げばよいのだから、機能制限ソフトを常駐させてもらえばよい。そして実際これが「情報漏洩防止」とうたわれているソリューションのいくつかが実施していることなのだ。プログラムと連動して、ロックをかけることができるUSBデバイスなんかがこれだ。
でもそんなこと期待できるかあ？ウィルスチェックプログラムさえ「重くなる」と嫌われるというのに。いや、それ以前に「使用者が協力的とは限らない」ことを前提に情報を守るというのがスタンスだろう。従って否応なく機能制限してしまわなければならない。まあいくつかやり方はある。妨害電波を常時出して通信を妨害してしまうというのもアイディア。でもそうなると業務上必要な通信もできなくなる。常駐している協力会社の業務を妨害するわけにはいけない。さあ、どうしよう。
実は暗号化は情報漏洩対策ではない、情報が漏れたときに防護壁となるものにすぎない。しかし、情報漏洩対策というと暗号化、という先入観を持っている人は多い。だったらそれを利用しよう。これがそもそもの思いつきの発端。かくして情報漏洩防止プログラムを書き始めた。MS-Windows限定となるが、それはお約束。
暗号化を許してくれるとすれば、ファイルを暗号化して渡しても復号化のためのソフトを抵抗なく立ち上げてくれるはず。ならばそのプログラムの中でセキュリティ措置をとればよい。
デバイスドライバレベルのプログラムが書ければ、コピー禁止とかいうのもできるかもしれないが、そういうテクニックは自分にはない。せいぜいレジストリをいじれる程度。それにコピーを禁止するデバイスドライバを立ち上げずとも、ファイルを渡した媒体に暗号化されたファイルがあるのは見えてしまう。暗号化されたままコピーしてしまうことはできる。すぐに復号化できるという訳ではないが気持ちが悪い。
（ほんとに腕のいい奴が作れば、ファイルを渡した媒体のフォーマットをFATとかNTFSというMS-Windowsがサポートしているものではなく、独自フォーマットにしてしまい、専用のデバイスドライバを使わなければ、ファイルがあるということすら関知できないようにしてしまうだろうが。）
解決策は安易。ファイルが保管された媒体のシリアル番号を取得して、それをファイル復号化キーの一部にしてしまうのである。従って、別の媒体にコピーしてしまえば、入力パスワードが正しくとも、複合化できない。あとはネチネチとセキュリティホールをふさぐ。電子メールの添付ファイルにされないようファイルの編集中は電子メールソフトが起動できないようにする。クリップボードの使用を制限すると編集作業が大変になるが、他のアプリケーションに貼り付けられないようにする。いろいろ考えたが、結果はシンプルになった。
プログラムを立ち上げると、レジストリのバックアップをまず取得。それからレジストリを書き換えまくる。起動できるプログラムを例えばMS-OFFICEとペイントブラシ、メモ帳に限る。全てのドライブを不可視にする。デスクトップに何も表示させない。そして次回起動時に本プログラムを自動的に起動するようにして、一回ログオフ。再起動すると、パスワードの入力を促す。入力されるとテンポラリディレクトリを作りそこにファイルを解凍。更に復号化。実用性を考えて、ファイルは暗号化した後、パスワード付きアーカイブファイルにしたのである。ここでのポイントは、暗号化のキーおよびアーカイブファイルのパスワードは使用者が入力したパスワードとは異なるということだ。入力したパスワードと媒体のシリアルナンバーから演算によって導き出す。このおかげで二つの機能が実現できる。
結局目くらましといえば目くらましなのだが、これだけでもずいぶん違うはずだ。
- 特定の媒体にファイルがないと開けない。（さっきも書いた奴）
- パスワードを知っている人でも、このプログラムを経由しないと解凍／復号化できない。
そしてコモンダイアログボックスのようなウィンドウが一つ開く。画面にあるのはこのウィンドウだけ。解凍・復号化したファイルのアイコンが並んでいる。がディレクトリの上にも下にもいけない。で、フォーム上にしっかりと「このファイルは秘密情報です。取扱には十分注意願います」と表記している。
そしてプログラム起動時に、「ファイル名を付けて保存」というダイアログボックスが出ていないかどうか監視して、出ればすぐに消す、というスレッドを一つ作っておく。このおかげで内容を他のファイルとして保存することができなくなる。クリップボード経由で中身をごっそり抜いても、画面キャプチャをしても貼り付けるところがなくなる。当然メールソフトなどあげようもない。機能としてはまあ要件を満たしているかな。もっとも手抜きをした点もあって、これは正直私のプログラミング技術の限界です。
ファイルの編集が終わって、プログラムを終了させると、ファイルを暗号化＆圧縮し、レジストリを元に戻して自動でログオフ。何事もなかったかのようにパソコンの環境は元に戻ります。
- 圧縮・解凍プログラムは他人の作ったものを使っている。（パスワードエラーになったとき、媒体のシリアル番号が違うのか、入力したパスワードが違うのか分からない。）
- 暗号化・復号化プログラムは他人の作ったものを使っている。（ロジックが丸わかりなので、時間をかければクラックされる。）
- 復号化したファイルはハードディスク内に置いてしまっている。（つまり、電源をぶちっとやれば、高確率でファイルはハードディスクに残ってしまう。解決策としては、復号化をMS-ExcelならMS-Excelのアドオンとして作り込み、ファイルだけを見てもどうしようもなくしてしまう、などが考えられる。RAMディスクを使うのも一案。）
- 「ファイル名を付けて保存」ダイアログボックスが一瞬ではあるが出てしまう。（本来は、ダイアログボックスの存在確認をするのではなく、ダイアログボックスを表示する旨のメッセージをフックして「出せません」という表示をすべき。）
実運用としてはこんなのを考えた。
要するに電子データを物理的に分離することによって、紙データ並みにしっかり管理できるようにするということ。
- 編集してほしいファイルを暗号化＆圧縮してUSBメモリなどの媒体に入れる。
- USBメモリを協力会社に貸し出す。（ちゃんと貸出簿を付ける）
- 協力会社はファイルを編集して返す。
- 退社時にUSBメモリの在高をチェックして、夜間は鍵のかかるところにしまう。
さて、このプログラム、折角作ったのに不幸である。とりあえず自分ところでは使う予定がない。かといってフリーで公開するわけにもいかない。もしどっかでこのプログラムを使ったにも拘わらず情報が漏洩したとしてみなさい。間違いなくロジックを知っている私が疑われる。それとも使用条件に「私を疑わないこと」とつけるかね？それを読んでなおかつ使う人というのはちょっと大胆すぎます。それにDelphiの6で作ってしまった。これは評価用なので変に配布するとライセンスに抵触しかねない。
まあ、ここまでできるよ、というデモとして作ったと思えば、、、少なくともこのプログラムを見せられた協力会社の皆さんは「あんなの強制されたらたまらん、これは絶対情報が漏洩しないように気を遣わないと」と身の引き締まる思いだけはしてくれるだろう。プログラム名のKurdamm、以前も書いたように旧西ベルリンの繁華街の名称です。壁に囲まれた中、別世界のように繁栄しているあそこです。あちこち軍隊が駐留しているというのに気にしていないかのような、実に美しい街でした。
このプログラムを書いていて、一つ賢くなったことがある。パスワードと暗号キーの区別がつくようになった。パスワードは間違えるとエラーを返すが、暗号化／復号化キーは間違えても原則正常終了する。
古典的な暗号化手法であるカエサル法を例に出してみよう。例えば”ＡＢＣ”という文字列を３つずらすと”ＤＥＦ”になる。ところがこれを２つずらしたものだと思いこんで復号化しても復号化そのものはできてしまう。ただし”ＢＣＤ”という別の文字列になり意味をなさないわけだが。
パスワードを破るときは辞書攻撃その他で文字列を絨毯爆撃する。入力したパスワードが正しいかどうかすぐに分かるからだ。ところが、こういう理由から暗号化キーを破るときは絨毯爆撃は殆ど役に立たない。復号化した文字列が意味をなすかどうか、いちいち確認しなければならないからである。従って暗号解読は、暗号化された文のくせを見てキーを割り出すことになる。有名な例がシャーロック＝ホームズの「踊る人形」。一番多い文字がＥ、というのから手をつけて復号化した。
言われてみれば当たり前のことであるが、自分でやってみると納得。となると使用者がパスワードの入力ミスした場合、それを通知するためには、暗号化だけでは駄目で、どこかで（ここでは圧縮・解凍）にパスワードを使わないと実用上問題がありまくる、ということになったのである。