クライアント、サーバ、ディレクトリ
ILMはどこに置かれているかではなく、誰がアクセスしたかでアクセスの可否を判断する、という話を前回いたしました。それを実現するには、まずは信頼のおけるクライアントソフトウェアが必要になります。このクライアントソフトウェアを通して、ドキュメントへのアクセスを行います。
クライアントソフトウェアは利用者が「誰が」を知るために何らかの認証を行います。このとき、認証情報に密接に結びついたサーバーソフトウェアへアクセスします。
そしてサーバーは、「誰か」を識別するためにユーザ情報の集まったもの、ディレクトリサービスと連携を取る必要があります。
ディレクトリに存在するユーザ情報を元にサーバーとクライアントの間で認証が行われ、ドキュメントに設定された権限を応じたアクセスが可能になります。このとき、権限にない行為を防ぐためにもドキュメントが暗号化されている必要があります。また、暗号化を解除(復号)するための鍵の管理も一工夫必要が必要です。ILMによる保護されたドキュメントへのアクセスをするだけではなく、自分のドキュメントにILMをかけて安全に共有したいという要望も出てきます。クライアントソフトウェアはそうした ILMを適用する機能も提供しなければなりません。
さらに、ドキュメントのフォーマットにも注意が必要です。そう、ILMの適用と暗号化の枠組みは、そのドキュメントのファイルフォーマットそのものに組み込まれている必要があります。
例えば HTMLによるドキュメントとパスワードで暗号化したZIPファイルを考えてみましょう。受け取った利用者がZIPを展開し、生のHTMLドキュメントだけを取り出し、第三者に渡すことができてしまいます。そうすると暗号化やILMといった仕組みを通り抜けられてしまうのです。前回、例として取り上げた Azure RMS による ILM では、docx, xlsx, pptx といったオフィスのファイルフォーマットの中にILMと暗号化の仕組みが組み込まれています。受け取ったユーザは「中身だけを取り出して、渡す」という行為ができない、RMSの適用されたままの Office ドキュメントを渡すしかないわけです。
ILMを実現するには、これだけの枠組みが必要になります。
