CooSのセキュリティ機構には従来のモデルの他に新しい※仕組みを導入しようと思っています。
※まー研究レベルではわんさかあるかもしれない。
IxDは近年多発している情報漏洩のための仕組みです。IxDを適切に設定することによって、情報漏洩を完全に無くすことができます。
現在、情報漏洩を完全に抑えるための手法として、仮想端末によるものがあります。これは、コンピュータをダム端末として用い、画面出力以外の処理はすべてサーバで行う方法です。しかしこれは「情報漏洩の対策」というよりは、単に機能制限による抑止であり、問題の解決策とは言い難いものです。
実際、この解決策ではサーバに（クライアントがあるにも関わらず）投資が必要な上に、データのやり取りについて著しい制限を課さざるを得ません。機密情報に重い制限が掛かることは当然なのですが、この手法ではあらゆるデータに重い制限を掛ける必要があります。
IxDの内容と効果はACLとよく似ています。ACLにはアカウントが並ぶのと同様、IxDの内容には複数の「情報ドメイン」が列挙されます。IxDもACLと同様、許可されないアカウントからのアクセスを拒否します。
たとえば、あるファイルの情報ドメインは「経理部」「人事課」「開発部」だとします。そうするとこのファイルは挙げた３つのドメインに属するアカウントからはアクセスできますが、それらに属していないアカウントからはアクセスできません。
このように、IxDはACLとアクセスを制限するという点でよく似ています。しかし、ACLはファイルとディレクトリに設定できるのに対し、少なくともCooSの実装ではIxDはディレクトリにしか設定できません。これは "Simple is best." の精神に依りますが、このあとの議論によってある程度の妥当性も見えてくるはずです。
IxDがACLと大きく異なる点は、コピーの時の動作に現れます。ACLの場合はファイルをコピーすると、新しく作成されたふぁぃるのACLはコピー先のディレクトリのACLから生成されます。一方IxDでは、コピー元ファイルのディレクトリのIxDとコピー先ディレクトリのIxDが「AND」され、その結果がそのファイルのIxDになります。ただし、前述のようにCooS実装ではファイルへのIxD設定はできない予定なので、実際には「コピー元⊇コピー先」のときにのみコピー操作を許すということになります。
たとえば、開発部の開発者が、勤務時間をExcelで作成するとします。そのためのファイルはあるディレクトリに保管されていて、開発部の人間は自分の記録を書き込みます。このファイルは月末に人事・経理向けのフォルダ（IxD：人事・経理）にコピーされます。このときにファイルのIxDからは開発が消え、開発部の人間はアクセスできなくなります。
このように、IxDでは常にアクセスできる許可セットが減少します。（ただし、許可セットがゼロ（φ）になることはありません。）
ストレージデバイスにコピーされたファイルは実質的にどのようにでも扱えてしまうため、ACLにおける「フルコントロール」のような特別な許可セットを必要とします。
これは、たとえば、会社で個人的なファイルを作り、個人用のディレクトリに保存したとしましょう。このファイルには「開発部」「横浜太郎」というIxDがつくことになります。
これをストレージにコピーできてしまうと、ストレージから再びコンピュータに書き戻す作業によってどのようにでもIxDを設定できるため、ストレージへのコピーは実質的にIxDの無制限拡大であると言えます。このような操作は一般的には許されません。
しかし、個人的に作成したファイルであればストレージへのコピーでも問題ないはずです。そこで、「横浜太郎」というIxDにおいては、「横浜太郎」アカウントにフルコントロールを与えることにします。（名前の重複に注意してください。）この権限によって、横浜太郎アカウントのユーザは、開発太郎IxDに属するファイルについて権限の無制限拡大を行うことができるようになり、ストレージデバイスへのコピーも可能になります。
さて、この「個人的なフルコントロール」によって、情報漏洩に影響しないのでしょうか。
ひとつの例は会社組織にある共有のデータを、横浜太郎アカウントがどのような影響を及ぼせるか考えてみます。横浜太郎アカウントがフルコントロール操作を行えるのは横浜太郎IxDが付与されたファイルのみですが、共有フォルダにあるファイルに個人向けIxDが付与されることはありません。また、フルコントロールはあくまで付与済みのものに対してであり、付与されていない情報に対して権利を取得することはできません。ですから、共有のようなデータに対しては全く問題ないことになります。
もうひとつの問題は職務で作成したデータをそもそも個人的なストレージにコピーされるのは好ましくないかもしれません。これについては、エンタープライズポリシーなどで、個人用のIxDを付与しないという機能を実装し、設定すればよいと思います。
ファイルごとにIxDが異なるということは、同じユーザがIxDの異なる複数の情報を動じ扱うということです。このとき、現状のモデルのままでは、次のような問題があります。
これには、OS実装系に改良が必要で、さらに「スマート」な解決方法と、「イージー」な解決方法があります。また、主な問題点はクリップボードとネットワークに集約されているので、以後はそれを念頭に置くことにします。
クリップボードがなぜ問題かと言えば、それはクリップボードへのコピーがストレージと同様に「IxDの無制限拡大」になってしまっているからです。そのため、クリップボードにコピーされて時点で情報ドメインをコントロールできなくなります。
これを解決するのは簡単で、単にクリップボードにも「情報ドメイン」の情報を持たせれば十分です。基本的に、貼り付け先が貼り付け元より広い権限を持つ場合には、コピーを拒否するようにします。
スマートな方法ではアプリケーションが対応する必要があります。しかし、ひとつのアプリケーションインスタンスで複数の情報ドメインに属する情報を同時に扱うことができます。
対応アプリでは、クリップボードの例と同じく、内部の情報が情報ドメインを超えて交換されないようにしなければなりません。これはアプリ側の責任で実装されるため、基本的にはOSが自動的に信頼するたぐいのものではなく、エンタープライズ管理者が事前に認証しておく種類のものです。たとえば、もし対応しているとして、MS-WordやMS-Excelなどの電子証明書と共に「スマートなアプリとしての動作を認める」とOSに教えるのです。
イージーな解決策では、アプリケーションに特別な対応は不要ですが、インスタンスが同時に扱える情報ドメインは一種類になります。
イージーな解決策を適用されて起動したアプリケーションは、ひとつの情報ドメインが割り当てられます。この情報ドメインより広いIxDを持つファイルや、クリップボードのデータは扱うことができますが、狭いIxDを持つ情報にアクセスしようとしたときはIxD実装により拒否されます。これにより、そのアプリケーションで扱う情報は最低でもあるIxDドメインを持つことが保証されますので、内部のどのようなデータ交換も問題ありません。
また、アプリケーションからの出力は、入力に関係なく、そのアプリケーションのIxDが付与されているものとして処理されます。ですから、IxDが拡大するディレクトリに保存できたり、クリップボードを経由して情報が漏洩する心配もありません。