Loading article…
マルチプルシングルレベルまたはマルチセキュリティレベル（MSL）は、各レベルに個別のコンピュータまたは仮想マシンを使用することで、異なるレベルのデータを分離する手段です。[ 1 ]これは、OSやアプリケーションに特別な変更を加えることなく、マルチレベルセキュリティの利点の一部を提供することを目的としており、追加のハードウェアが必要になるという欠点があります。
MLSオペレーティングシステムの開発は、 1990年代初頭のデータ処理コストの劇的な低下によって大きく阻害された。デスクトップコンピューティングが登場する以前は、機密処理を必要とするユーザーは、専用コンピュータに多額の費用をかけるか、MLSオペレーティングシステムを搭載したコンピュータを使用するかのどちらかを選択する必要があった。しかし、1990年代を通じて、国防・情報機関の多くの部署は、コンピューティングコストの低下を利用して、組織内で使用されている最高機密レベルでのみ動作するように機密指定されたデスクトップシステムを導入した。これらのデスクトップコンピュータはシステムハイモードで動作し、コンピュータと同じレベルのトラフィックを伝送するLANに接続されていた。
このようなMSLの実装は、MLSの複雑さを巧みに回避したが、技術的な簡素さを犠牲にして、スペースの非効率的な使用という代償を伴った。機密環境のほとんどのユーザーは非機密システムも必要としていたため、多くの場合、少なくとも2台、場合によってはそれ以上のコンピュータ（非機密処理用と、処理する各機密レベルごとに1台）を使用していた。さらに、各コンピュータは適切な機密レベルで独自のLANに接続されていたため、複数の専用ケーブル配線設備が組み込まれていた（設置と保守の両面で相当なコストがかかった）。
MSLの明らかな欠点（MLSと比較した場合）は、様々な機密レベルの混在を一切サポートしていない点です。例えば、機密ファイルから取得した機密データストリームと、極秘ファイルから読み取った極秘データストリームを連結し、その結果得られた極秘データストリームを極秘ファイルに書き込むといったことはサポートされていません。本質的に、MSLシステムは、それぞれが1つのセキュリティレベルでのみ動作するように制限された、並列（かつ同一場所に配置された）コンピュータシステムの集合体と考えることができます。実際、個々のMSLオペレーティングシステムは、単一レベルのシステムとして動作するため、セキュリティレベルの概念すら理解していない可能性があります。例えば、同じ場所に設置された複数のMSL OSのうちの1つが、すべての出力に「SECRET」という文字列を付加するように構成されている場合でも、そのOSは、すべての出力に「UNCLASSIFIED」という文字列を付加するもう1つのOSが処理するデータと、そのデータの機密性や重要度を比較することはできません。
したがって、2つ以上のセキュリティレベルにまたがって運用する場合、MSLの「オペレーティング システム」自体の範囲外であり、人間の介入を必要とする方法、すなわち「手動レビュー」を使用する必要があります。たとえば、複数のMSLピア間でのデータ移行をサポートするために、独立したモニター（Brinch Hansenの用語の意味ではない）が提供される場合があります（たとえば、UNCLASSIFIEDピアからSECRETピアへのデータ ファイルのコピー）。連邦法による厳密な要件は、この懸念に特に対処していませんが、このようなモニターは非常に小規模で、専用に構築され、ファイルのインポートとエクスポート、出力ラベルの設定、およびすべてのMSLピアを個別の単一レベル システムとしてではなく、ユニットとして扱う必要があるその他の保守/管理タスクなど、厳密に定義された少数の操作のみをサポートすることが適切です。VMwareなどのハイパーバイザソフトウェアアーキテクチャを利用して、ピアMSLの「OS」セットを、基盤となるOSによってサポートされる個別の仮想化環境として提供することも適切でしょう。この基盤となるOSは、ピアによって管理されるすべてのデータへのアクセス権限を持つ管理者のみがアクセスできます。ユーザーの視点から見ると、各ピアは、基盤となる「メンテナンスOS」ユーザー環境と論理的に区別できないログインセッションまたはXディスプレイマネージャセッションを提供します。
各機密レベルごとに個別のネットワークを維持するのに伴うコストと複雑さから、国家安全保障局（NSA）は、複数のネットワークとコンピュータに必要な物理的投資を削減しつつ、専用システム高システムというMSLコンセプトを維持する方法の研究を開始した。この分野における最初の進歩は、ピリオド処理であり、機関がコンピュータをある機密レベルのネットワークに接続し、情報を処理し、システムを消去し、別の機密レベルの別のネットワークに接続できるプロトコルを確立した。ピリオド処理モデルは単一のコンピュータで済むという可能性を示したが、複数のケーブル配線を削減することはできず、ユーザーにとって非常に不便であることが判明したため、その採用は限定的であった。
1990年代、仮想化技術の台頭により、MSLシステムの状況は一変した。独立したコンピュータのように動作しながらも、共通のハードウェアプラットフォーム上で動作する仮想マシン（VM）を作成することが可能になったのだ。仮想化によって、NSAは処理期間を仮想レベルで維持する方法を見出した。もはや物理システムをサニタイズする必要はなく、専用のシステムレベルのVM内で全ての処理を実行できるようになった。しかし、MSLを仮想環境で機能させるには、仮想セッションマネージャを安全に制御し、あるVMに対する不正行為が他のVMに影響を与えないようにする方法を見つける必要があった。
NSAは、仮想化技術を活用した実用的で安全なMSL技術の開発を目指し、複数のプログラムを推進してきた。現在までに、3つの主要なソリューションが実現している。
NetTopとTrusted Multi-Netの両ソリューションは、使用が承認されています。さらに、Trusted Computer Solutionsは、NSAとのライセンス契約に基づき、NetTopの技術コンセプトを基にしたシンクライアント製品を開発しました。この製品はSecureOffice® Trusted Thin Clientと呼ばれ、Red Hat Enterprise Linuxバージョン5（RHEL5）のLSPP構成上で動作します。
競合する3社がMILS分離カーネルを実装した。
さらに、専用ハードウェアの使用による非仮想化MSLシステムの開発が進展し、少なくとも1つの実現可能なソリューションが実現した。
MSLの「解決策の道」の哲学的意味合いを考察するのは興味深い。従来のOS内でMLS機能を提供するのではなく、選択された方向性は、基盤となる実際のOSによって個別に、また集合的に管理できる「仮想OS」ピアのセットを構築することである。基盤となるOS（ここでは保守オペレーティングシステム、またはMOSという用語を導入しよう）が、極秘MSLピアから非機密MSLピアへのデータのコピーなどの重大なエラーを防ぐためにMLSセマンティクスを十分に理解する必要があるならば、MOSは次の機能を備えている必要がある。ラベルを表現する。ラベルをエンティティに関連付ける（ここでは「主体」と「対象」という用語は厳密に避ける）。ラベルを比較する（「参照モニター」という用語は厳密に避ける）。ラベルが意味を持つコンテキストと意味を持たないコンテキストを区別する（「信頼できるコンピューティングベース」[TCB]という用語は厳密に避ける）。リストは続く。 MLSのアーキテクチャと設計上の問題は解消されたわけではなく、単に別のソフトウェア層に委ねられただけで、そのソフトウェア層が必須アクセス制御に関する問題を目に見えない形で管理することで、上位層がそれらの問題に対処する必要がなくなっただけであることは容易に理解できる。この概念は、そもそも国防総省スタイルの信頼できるシステムを支える、アンダーソン報告書から引用した根本的なアーキテクチャ概念に他ならない。
MSLピアの抽象化によって確かに達成されたのは、MAC対応ソフトウェア機構の範囲を、下位のMOSという小さな領域にまで大幅に制限できたことである。しかし、この成果は、最も基本的な機能でさえ、実用的なMLS機能を排除するという代償を伴うものであった。例えば、機密情報取扱資格を持つユーザーが、機密情報取扱資格のないファイルから取得した機密情報取扱資格のない段落を、機密情報取扱資格のあるレポートに添付する場合などである。MSLの実装では、明らかに、再利用可能なリソース（この例では機密情報取扱資格のないファイル）を、有用と思われるすべてのMSLピアに複製する必要がある。つまり、二次記憶装置を無駄に大量に消費するか、ユーザーからの要求に応じて複製を実行できる資格を持つ管理者にとって、耐え難い負担となるかのどちらかである。 （もちろん、SECRET ユーザーはログアウトして UNCLASSIFIED システムを新たに起動する以外にシステムの UNCLASSIFIED 提供物を「閲覧」できないため、機能性と柔軟性にまた別の重大な制限が生じます。） あるいは、機密性の低いファイルシステムを NFS マウントして読み取り専用にすることで、より信頼できるユーザーがそのコンテンツを閲覧することはできますが、変更することはできません。 ただし、MLS OS ピアは、NFS マウントされたリソースがローカル リソースとは異なるレベルの機密性を持っていることを (ディレクトリ一覧コマンドなどを介して)実際に区別する手段がなく、読み取り専用の NFS マウントという総当たりのオール・オア・ナッシング方式以外に、機密情報の不正なアップヒルフローを防止する厳密な手段もありません。
この「クロスレベルファイル共有」の大幅な実施が実際にどれほどの障害となるかを説明するために、UNCLASSIFIED、SECRET、およびTOP SECRETデータをサポートするMLSシステムと、そのレベルでシステムにログインするTOP SECRETクリアランスを持つユーザーのケースを考えてみましょう。MLSディレクトリ構造は包含の原則に基づいて構築されており、大まかに言えば、より高い機密レベルはツリーのより深いところに存在することを規定しています。一般的に、ディレクトリのレベルはその親のレベルと一致するか、またはそれよりも上位である必要があり、ファイル（より具体的には、それへのリンク）のレベルは、それをカタログ化するディレクトリのレベルと一致する必要があります。 （これは厳密には MLS UNIX にのみ当てはまります。ディレクトリ、ディレクトリ エントリ、i ノードなどの異なる概念をサポートする代替システム（ディレクトリ パラダイムに「ブランチ」抽象化を追加するMulticsなど）は、より幅広い代替実装を許容します。） /tmpやC:\TEMPなどの公開共有ディレクトリとスプール ディレクトリには直交するメカニズムが提供され、これらは OS によって自動的に（目に見えない形で）パーティション化され、ユーザーのファイル アクセス要求は自動的に適切なラベルの付いたディレクトリ パーティションに「転送」されます。 TOP SECRET ユーザーはシステム全体を自由に閲覧できますが、唯一の制限は、そのレベルでログインしている間は、特定のディレクトリまたはその子孫内にのみ新しい TOP SECRET ファイルを作成できるという点です。 MSL方式では、閲覧可能なコンテンツはすべて、完全なセキュリティクリアランスを持つ管理者によって、該当するすべてのレベルにわたって個別に、かつ手間をかけて複製する必要があります。つまり、この場合、すべてのSECRETデータはTOP SECRET MSLピアOSに複製され、すべてのUNCLASSIFIEDデータはSECRETとTOP SECRETの両方のピアに複製される必要があります。そのため、ユーザーのセキュリティクリアランスが高いほど、タイムシェアリングコンピューティングの体験がより不満の残るものになることは容易に理解できます。
古典的な信頼システム理論の観点からすると（信頼コンピューティングの基盤であるオレンジブックから引用した用語と概念に基づくと）、MSLピアをサポートするシステムは（B1）を超えるレベルの保証を達成することはできません。これは、（B2）基準では、とりわけ、TCB境界の明確な識別と、ADPシステムのアクセス可能なすべてのリソース全体にわたって表現されるすべてのデータへのアクセスを裁定する能力と権限を持つ、識別可能な単一のエンティティの存在が要求されるためです。したがって、非常に現実的な意味では、「高保証」という用語をMSL実装の説明として適用することは無意味です。なぜなら、「高保証」という用語は、（B3）および（A1）システム、そして多少の緩みはあるものの（B2）システムに限定されるべきだからです。
MSLシステムは、仮想システムであれ物理システムであれ、異なる分類レベル間の分離を維持するように設計されています。したがって、（MLSシステムとは異なり）MSL環境には、あるレベルから別のレベルへデータを移動させる固有の機能はありません。
異なる機密レベルで動作するコンピュータ間でのデータ共有を可能にするため、このようなサイトではクロスドメインソリューション（CDS）が導入されます。これは一般的にゲートキーパーまたはガードと呼ばれます。ガードは、多くの場合MLS技術自体を活用し、ネットワーク間を流れるトラフィックをフィルタリングします。ただし、商用インターネットファイアウォールとは異なり、ガードははるかに厳格な保証要件に基づいて構築されており、異なるセキュリティレベルで動作するLAN間で機密情報が不適切に漏洩することを防止するようにフィルタリングが慎重に設計されています。
データダイオード技術は、レベル間でデータフローを一方向に制限し、逆方向へのデータフローを確実に防止する必要がある場面で広く用いられています。一般的に、これらの技術は、他のMLSソリューションと同様に、厳格なセキュリティ評価と、分類間で情報を移動するための規定ポリシーの電子版を提供する必要性という制約を受けます。（分類レベルを下げることは特に難しく、通常は複数の担当者の承認が必要となります。）
2005年末時点で、多数の高信頼性プラットフォームおよびセキュリティアプリケーションが機密環境での使用を承認されています。なお、ここで使用されている「高信頼性」という用語は、機密情報を処理するさまざまなシステムの構築と展開に関する準技術ガイドであるDCID 6/3 （「ディー・スキッド・シックス・スリー」と読みます）の文脈で評価されるべきであり、オレンジブックの基準のような厳密な法的厳格さや、その根底にある数学的な厳密さは欠いています。 （オレンジブックは、以下のように構築された論理的な「推論の連鎖」に動機づけられ、そこから派生しています。[a]「安全な」状態が数学的に定義され、数学モデルが構築されます。このモデルに対する操作は安全な状態を維持するため、安全な状態から始まる考えられるあらゆる操作のシーケンスが安全な状態を生成します。[b] 慎重に選択されたプリミティブをモデルに対する操作のシーケンスにマッピングします。[c] ユーザーインターフェースで実行可能なアクション（システムコールなど）をプリミティブのシーケンスにマッピングする「記述的なトップレベル仕様」を作成します。ただし、[d] 実際のソフトウェア実装が上記のアクションのシーケンスを正しく実装することを正式に実証すること、または[e] 実行可能で「信頼できる」システムが、正しく信頼できるツール（コンパイラ、ライブラリアン、リンカなど）によって生成されたことを正式に論証することは行いません。）