Loading article…
マルチレベルセキュリティまたはマルチレベルセキュリティ（MLS）とは、コンピュータシステムにおいて、互換性のない分類（つまり、異なるセキュリティレベル）を持つ情報を処理し、異なるセキュリティクリアランスと知る必要性を持つユーザーによるアクセスを許可し、権限のないユーザーが情報にアクセスすることを防止するための仕組みです。
多層セキュリティの利用には2つの文脈がある。1つは、システム自体が改ざんから保護され、情報領域を分離するための堅牢なメカニズムを備えている、つまり信頼できるシステムを指す場合である。もう1つは、コンピュータが改ざんから保護されるのに十分な強度を持ち、情報領域を分離するための適切なメカニズムを備えている必要がある、つまり信頼しなければならないシステムを指す場合である。この区別は重要である。なぜなら、信頼する必要があるシステムが必ずしも信頼できるとは限らないからである。
MLSオペレーティング環境では、多くの場合 MLSオペレーティング システム(OS) 上に構築された、非常に信頼性の高い情報処理システムが必要となるが、必ずしもそうではない。ほとんどの MLS 機能は、信頼できないコンピュータのみで構成されたシステムでもサポートできるが、ハードウェア セキュリティに準拠したチャネルでリンクされた複数の独立したコンピュータが必要となる (信頼されたネットワーク解釈、NCSC-TG-005のセクション B.6.2 を参照)。ハードウェアで強制される MLS の例としては、非対称分離がある。[ 1 ] 1 つのコンピュータが MLS モードで使用される場合、そのコンピュータは信頼できるオペレーティング システムを使用する必要がある。MLS 環境内のすべての情報は物理的に OS からアクセスできるため、情報へのアクセスが厳密に制御されるように、強力な論理制御が存在する必要がある。通常、これには、ベル・ラパデュラ モデルなどのセキュリティ ラベルを使用する強制アクセス制御が含まれる。
信頼できるオペレーティングシステムを導入する顧客は通常、製品が正式なコンピュータセキュリティ評価を完了することを要求します。評価は、システムが処理できる最低および最高の分類レベルであるセキュリティ範囲が広いほど厳しくなります。信頼できるコンピュータシステム評価基準(TCSEC) は、コンピュータシステムの MLS を評価するために開発された最初の評価基準でした。この基準の下では、セキュリティ要件と MLS セキュリティ範囲の広さの間に明確で統一されたマッピング[ 2 ]がありました。歴史的に、機密解除から最高機密までのセキュリティ範囲で MLS 処理が可能であることが認証された実装はほとんどありませんでした。その中には、Honeywellの SCOMP、USAF SACDIN、NSAのBlacker、Boeingの MLS LAN があり、すべて TCSEC の下で、1980 年代のIntel 80386ベースでした。現在、MLS 製品は共通基準の下で評価されています。 2008 年後半、最初のオペレーティングシステム (詳細は後述) が、高脅威環境におけるマルチレベル セキュリティを要求する米国政府プログラムの下で、評価保証レベル(EAL) - EAL 6+ / 高堅牢性という高い評価保証レベルの認証を受けました。この保証レベルは、形式手法など、旧オレンジ ブック A1 と多くの類似点がありますが、機能要件は、ベル・ラ・パドゥラなどの高レベル ポリシーではなく、基本的な分離と情報フロー ポリシーに重点を置いています。共通基準が TCSEC の保証 (EAL) と機能 (保護プロファイル) のペアリングを切り離したため、共通基準がレインボー シリーズに取って代わったときに、CSC-STD-004-85 に文書化されていたセキュリティ要件と MLS セキュリティ範囲機能の間の明確で統一されたマッピングがほぼ失われました。
MLSをサポートする機能を備えた無料で利用可能なオペレーティングシステムには、Security-Enhanced Linux機能が有効になっているLinuxやFreeBSDなどがあります。[ 3 ]これらの無料のMLS実装では、セキュリティ評価が3つの理由から問題になると考えられていました。
このような憶測にもかかわらず、Red Hat Enterprise Linux 5 は 2007 年 6 月に EAL4+ で LSPP、RBACPP、および CAPP の認証を取得しました。[ 4 ]これは Security-Enhanced Linux を使用して MLS を実装しており、Security-Enhanced Linux を使用して TOE セキュリティ特性を強制する最初の Common Criteria 認証でした。
ベンダーの認証戦略は、一般の人々を誤解させる可能性があります。一般的な戦略は、一般の人々が EAL レベルを過度に重視する傾向を利用し、EAL 3 の保護プロファイル (CAPP など) [ 5 ]を EAL 4 や EAL 5 といった高いレベルに認証するなど、過剰な認証を行うことです。また、MLS 対応の保護プロファイルとして評価されていないカーネルに、ロールベース アクセス制御保護プロファイル (RBACPP) やラベル付きセキュリティ保護プロファイル (LSPP) などの MLS サポート機能を追加して認証することも、別の戦略です。これらの機能はカーネル上で実行されるサービスであり、カーネルがそれらを破損や改ざんから保護することに依存しています。カーネルが MLS 対応の保護プロファイルとして評価されていない場合、デモがどれほど印象的であっても、MLS 機能は信頼できません。特に注目すべきは、CAPP はMLS に不可欠な自己保護機能を明確に除外しているため、MLS 対応のプロファイルではないということです。
General Dynamics は、信頼性の高い MLS オペレーティングシステムであるPitBullを提供しています。PitBull は現在Red Hat Enterprise Linuxの拡張版としてのみ提供されていますが、以前は Sun Microsystems Solaris、IBM AIX、および SVR4 Unix 用のバージョンが存在していました。PitBull は、Bell LaPadulaセキュリティ メカニズム、Biba整合性メカニズム、スーパーユーザーの特権代替、およびその他多くの機能を提供します。PitBull は、2009 年以来、General Dynamics の Trusted Network Environment (TNE)製品のセキュリティ基盤となっています。TNEは、さまざまな機密レベルで運用されている国防総省および情報コミュニティのユーザー向けに、マルチレベルの情報共有とアクセスを可能にします。また、マルチレベル連合共有環境である Battlefield Information Collection and Exploitation Systems Extended [ 6 ] (BICES-X) の基盤でもあります。
Sun Microsystems (現Oracle Corporation) は、商用 OS SolarisおよびOpenSolarisの統合機能としてSolaris Trusted Extensionsを提供しています。Trusted Extensions は、制御アクセス保護プロファイル (CAPP) およびロールベースアクセス制御(RBAC) 保護プロファイルに加えて、ラベル付きセキュリティ保護プロファイル (LSPP) に対して EAL4 の認証も取得しています。[ 7 ]セキュリティ ターゲットには、デスクトップ機能とネットワーク機能の両方が含まれます。LSPP では、ユーザーがカーネルおよびX Window System (X11 サーバー) によって強制されるラベル ポリシーを上書きすることを許可しないことが義務付けられています。この評価には、隠蔽チャネル分析は含まれません。これらの認証は CAPP に依存しているため、Common Criteria の認証では、この製品が MLS に対して信頼できることを示唆するものはありません。
BAE Systemsは、ベンダーが「高信頼性」と称するレベルでMLSをサポートする商用システムであるXTS-400を提供しています。前身製品（XTS-300を含む）は、MLS対応のTCSEC B3レベルで評価されていました。XTS-400は、CAPPおよびLSPP保護プロファイルに対して、EAL5+のCommon Criteriaで評価されています。CAPPとLSPPはどちらもEAL3保護プロファイルであり、本来MLS対応ではありませんが、この製品のCommon Criteria評価のセキュリティターゲット[ 8 ]には、MLS機能を提供する強化されたセキュリティ機能セットが含まれています。
MLSシステムにとって、データのサニタイズは問題領域です。ベル・ラパデュラモデルなどで定義されているようなMLS制限を実装するシステムでは、セキュリティ制限に明らかに違反しない場合にのみ共有が許可されます。低いセキュリティクリアランスのユーザーは、高いセキュリティクリアランスを持つユーザーと簡単に作業を共有できますが、その逆はできません。最高機密ユーザーが最高機密ファイルを編集し、すべての最高機密情報を削除してから、機密以下のセキュリティクリアランスを持つユーザーに配布する効率的で信頼性の高いメカニズムは存在しません。実際には、MLSシステムは、信頼できるユーザーがMLSメカニズムをバイパスしてファイルのセキュリティ分類を変更できる特権関数を使用してこの問題を回避しています。しかし、この手法は信頼性に欠けます。
隠蔽チャネルは、 MLSシステムにとって別の問題となります。MLSシステムが機密情報を完全に保持するためには、最高機密プロセスが機密プロセスまたはそれ以下のプロセスにいかなる種類の信号も送信できないようにする必要があります。これには、利用可能なメモリやディスク容量の変化、プロセスタイミングの変化などの副作用も含まれます。プロセスがこのような副作用を利用してデータを送信する場合、それは隠蔽チャネルを利用していることになります。実際のコンピューティングシステムで全ての隠蔽チャネルを閉じることは非常に困難であり、実際には不可能かもしれません。全ての隠蔽チャネルを特定するプロセス自体が困難なものです。市販されているほとんどのMLSシステムは、全ての隠蔽チャネルを閉じようとはしていません。しかし、これは高セキュリティアプリケーションでの使用を非現実的なものにしています。
バイパスは、システム高レベルのオブジェクトをMLS信頼済みであるかのように扱う手段として導入されると問題が生じます。よくある例として、機密性の高いシステム高レベルのオブジェクトからデータを抽出し、機密性の低い宛先に送信する際に、データの何らかの特性（例えば「厳密な」フォーマット）を、それが「本当に」機密性が低いことを示す信頼できる証拠として挙げるケースがあります。システム高レベルのシステムは、信頼できる証拠を保持することが保証されないため、結果として、安全に仲介する論理的な方法がないまま、公然としたデータパスが開かれてしまいます。バイパスは、悪用が困難な狭帯域幅の隠蔽チャネルとは異なり、システム内に容易に悪用可能な大きな公然の漏洩を引き起こす可能性があるため、危険です。バイパスは多くの場合、セキュリティドメインをその発生源まで継続的に分離するために信頼できるオペレーティング環境を使用できなかったことが原因で発生します。その発生源がシステム境界外にある場合、発生源までの信頼できる分離を検証できない可能性があります。その場合、データフローが本当に不可欠な場合は、バイパスのリスクは避けられない可能性があります。
回避不可能なバイパスの一般的な例として、信頼できない送信元から秘密のIPパケットを受け取り、ヘッダーではなく秘密のユーザーデータを暗号化し、その結果を信頼できないネットワークに送信する必要のある対象システムが挙げられます。送信元は対象システムの影響範囲外にあります。送信元は信頼できない（システムレベルが高いなど）にもかかわらず、非分類ヘッダーと秘密の平文ユーザーデータ（MLSデータ構造）を持つパケットを提供するので、MLSであるかのように信頼されています。送信元は信頼できないため、破損していて非分類パケットヘッダーに秘密情報が含まれている可能性があります。破損したパケットヘッダーは意味不明な内容である可能性がありますが、対象システムがそれを合理的な信頼性で判断することは不可能です。パケットユーザーデータは暗号的に十分に保護されていますが、パケットヘッダーには読み取り可能な秘密情報が含まれている可能性があります。対象システムが破損したパケットを信頼できないネットワークに渡した場合、ルーティングできない可能性がありますが、ネットワーク内の協力的な不正プロセスがパケットを傍受して確認応答し、対象システムが漏洩を検出できない可能性があります。これは、検出が困難な大規模な情報漏洩となる可能性があります。機密扱いのパケットを、本来のMLS構造ではなく、非機密扱いのヘッダーを持つシステム高構造として扱うことは、非常に一般的ではあるものの深刻な脅威となります。
ほとんどのバイパスは回避可能です。回避可能なバイパスは、システム設計者がセキュリティを正しく考慮せずにシステムを設計し、後からアドオン機能としてセキュリティを適用しようとした場合に発生することがよくあります。このような状況では、バイパスがシステムを機能させる唯一の（簡単な）方法のように見えます。バイパスされたデータに秘密情報が含まれていないことを立証するために、バイパスされたデータの内容を検査する擬似的なセキュリティスキームが提案され（そして承認されました！）。これは、データの形式など、データに関する何らかの情報を信頼しない限り不可能であり、ソースがソースデータの特性を保持することを信頼していないという前提に反します。バイパスを透過的に実装するいわゆる高保証ガード（HAG）と同様に、確実な「安全なバイパス」は神話です。これらのリスクは以前から認識されており、既存のソリューションは技術的なものではなく、最終的には手続き的なものです。バイパスの悪用によってシステムからどれだけの機密情報が持ち出されているかを確実に知る方法はありません。
素人の中には、安全なコンピューティング システムを設計し、MLS は存在しないという結論を出している人もいます。その理由としては、COMPUSEC の専門家が減少していること[ 9 ]と、MLS という用語が2 つの異なる意味 / 用途で過剰に使用されていることが考えられます。これらの 2 つの用途とは、処理環境としての MLS と機能としての MLS です。MLS が存在しないという考えは、MLS環境またはモードで動作するように認証された製品がなく、したがって機能としての MLSが存在しないという考えに基づいています。一方が他方を意味するわけではありません。多くのシステムは、セキュリティ レベルが異なるデータを含む環境で動作しており、コンピュータ セキュリティ中間値定理 (CS-IVT) [ 10 ]により MLS となります。 この混乱の結果はより深刻です。NSA 認証の MLS オペレーティングシステム、データベース、ネットワークは 1970 年代から運用されており、MLS 製品は引き続き構築、販売、展開されています。
一般の人々は、システムがMLS環境で動作していることを認める（MLSの環境中心の意味）と、 MLSソリューションが存在しない問題を抱えているという認識（MLSの機能中心の意味）に追い込まれると結論づけることが多い。MLSは見かけによらず複雑であり、単純な解決策が明らかでないからといって、存在しないと結論づけるのは正当化されない。このため、COMPUSECに関する深刻な無知が生じ、「MLSについて語るべきではない」「MLSなどというものは存在しない」といったささやき声として現れる。こうしたMLS否定の構図は急速に変化するため、対処することができない。そこで、MLS環境とMLS対応能力の区別を明確にすることが重要である。
MLSという用語は、元々はセキュリティ環境、つまりセキュリティモードを指すために用いられていました。この混乱を解消する一つの方法は、MLSの本来の定義を維持し、その文脈で使用される場合にはMLS対応であることを明記することです。
多重独立セキュリティレベル（MILS）は、MLSのドメイン分離コンポーネントに対応するアーキテクチャです。なお、UCDMO（米国政府におけるクロスドメインおよびマルチレベルシステムの主導機関）は、国防総省および情報機関の認定システムに関する基準の中で、 「クロスドメインアクセス」というカテゴリを作成しましたが、このカテゴリは基本的にMILSと類似していると言えます。
Bibaモデル（完全性）やBell-LaPadulaモデル（機密性）などのセキュリティモデルは、本来分離されているはずの特定のセキュリティドメイン間での一方向フローを許容します。MILSは、上記のモデルで扱われるドメイン間の制御された相互作用には対応せずに、MLSの基盤となる分離性に対処します。前述の信頼できるセキュリティ準拠チャネルは、MILSドメインをリンクして、より多くのMLS機能をサポートすることができます。
MILSアプローチは、MSL（マルチプルシングルレベル）という古い用語で特徴付けられる戦略を採用しており、各レベルの情報を独自のシングルレベル環境（システムハイ）内に分離します。
MILSが提供する厳格なプロセス通信と分離は、MLSよりも超高信頼性ソフトウェアアプリケーションにとって有用である可能性があります。MILSは、セキュリティレベルの概念によって具現化される階層構造には対応していません。そのため、各ドメイン間に特定のインポート/エクスポートアプリケーションを追加し、それぞれを適切に認証する必要があります。したがって、MILSは「複数の独立したセキュリティドメイン」と呼ぶ方が適切かもしれません（MILS上でMLSをエミュレートするには、MLSアプリケーションに対して同様の認証済みアプリケーション群が必要になります）。Bell-La Padulaの階層関係に沿ったレベル間の相互作用を標準で実装しないことで、MILSは（一見すると）実装は簡単ですが、実際のMLSアプリケーションに期待される豊かさと柔軟性を実現するには、複雑な追加のインポート/エクスポートアプリケーションが必要になります。
MILSとMLSを比較する際には、よりシンプルな輸出申請群の認証取得が、より複雑なMLSカーネル1つの認証取得よりも容易かどうかを検討する必要がある。この問題は、関係者が求める輸出入のやり取りの程度によって部分的に左右される。MILSの利点としては、すべての輸出申請に最大限の保証が求められるわけではないという点が挙げられる。
このような問題を解決する別の方法として、マルチプルシングルレベル（MLS）と呼ばれるものがあります。各セキュリティレベルは、信頼できない個別のドメインに分離されます。ドメイン間の通信手段がないため、相互作用は一切発生しません。この分離のメカニズムは通常、別々のコンピュータによる物理的な分離です。これは、Microsoft WindowsのようにMLSをサポートできないアプリケーションやオペレーティングシステムをサポートするためによく使用されます。
信頼できるオペレーティングシステムなどのインフラストラクチャは MLS システムの重要な構成要素ですが、 CNSSI 4009による MLS の定義 (この記事の冒頭で言い換えられている) で要求される基準を満たすには、システムは、ユーザーが 1 つのシステムから複数の分類レベルのコンテンツにアクセスして処理できるユーザー インターフェイスを提供する必要があります。UCDMO は、 2009 年のNSA情報保証シンポジウムで MLS に特化したトラックを実施し、その中で、認定された (運用中の) MLS システムと新興の MLS システムをいくつか紹介しました。SELinux での MLS の使用に注目してください。[ 11 ]
MLSシステムとして分類されるデータベースはいくつか存在する。OracleにはOracle Label Security（OLS）という製品があり、 Oracleデータベースの各テーブルに「ラベル」列を追加することで、強制アクセス制御を実装すると謳っている。しかし、これらは基盤となるOSの強制メカニズムとは無関係な、恣意的なラベルである。OLSは、JWICSおよびSIPRNetネットワークにまたがる「全情報源」インテリジェンスデータベースの基盤として、米陸軍INSCOMに導入されている。この場合、システムハイアクセスや専用モードアクセスなどの物理的手段を用いて、連邦基準に準拠した強制アクセス制御を強制している。Trusted Rubixは、MLS UNIXポート上で動作し、パッケージ版として購入できた唯一のMLS実装である。実際、Trusted Rubixは、NSAの認可セキュリティ製品情報センター（ASPIC）から入手可能な唯一のリレーショナルDBMS製品であった。
MLSのエンドユーザーアプリケーションもいくつかあります。現在UCDMOベースラインにあるもう1つのMLS機能は、Wayback Machineに2013年3月17日にアーカイブされたMLChatと呼ばれ、 XTS-400オペレーティングシステム上で動作するチャットサーバーです。これは米国海軍研究所によって作成されました。異なるドメインのユーザーからのコンテンツがMLChatサーバーを通過するため、機密コンテンツを保護するためにダーティワードスキャンが採用されており、これが本当にMLSシステムなのか、それともクロスドメイン転送データガードの一種なのかについて議論があります。必須アクセス制御は、XTS-400とアプリケーション固有のメカニズムの組み合わせによって維持されています。 [ 12 ]
現在 UCDMO ベースラインに含まれていない MLS アプリケーションには、BlueSpaceのアプリケーションがいくつかあります。BlueSpace には、MLS メール クライアント、MLS 検索アプリケーション、MLS C2 システムなど、複数の MLS アプリケーションがあります。BlueSpace は、ミドルウェア戦略を使用して、アプリケーションがプラットフォームに依存しないようにし、複数のWindows OS インスタンス (仮想化またはリモート ターミナル セッション) にわたって単一のユーザー インターフェイスをオーケストレーションします。米国海軍研究所も、 Ruby on Rails フレームワークとSQLite3に基づくマルチレベル データベースを統合した MLWeb と呼ばれるマルチレベル Web アプリケーション フレームワークを実装しています。
今日のマルチレベルセキュリティ分野で起こっている最大の変化は、MLSと仮想化の融合と言えるでしょう。多くの信頼できるオペレーティングシステムが、ファイルやプロセスへのラベル付けから、UNIXコンテナや仮想マシンへと移行しつつあります。その例としては、 Solaris 10 TXのゾーン、 Green HillのIntegrityプラットフォームやCitrixのXenClient XTなどのシステムにおけるパデッドセルハイパーバイザなどが挙げられます。General DynamicsのTrusted Virtualization Environment （TVE）に実装されているNSAのHigh Assurance Platformもその一例です。これはコアにSELinuxを使用し、複数のドメインにまたがるMLSアプリケーションをサポートできます。
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）リファレンスポリシー[...]マルチレベルセキュリティ（MLS）は、より洗練されたセキュリティアクセス方法を追加します。MLSは、リソースにセキュリティレベル値を追加します。
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）（別名TCSECまたは「オレンジブック」）が必要です。{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）（別名 TNI または「レッドブック」）が必要です。{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ) CS1 メンテナンス: 複数の名前: 著者リスト (リンク)が必要です