強制アクセス制御

コンピュータセキュリティにおいて、強制アクセス制御（MAC ）とは、セキュリティで保護された環境（オペレーティングシステムやデータベースなど）がサブジェクトまたはイニシエーターによるオブジェクトまたはターゲットへのアクセスや変更の能力を制限するアクセス制御の一種を指します。^[1]オペレーティングシステムの場合、サブジェクトはプロセスまたはスレッドであり、オブジェクトはファイル、ディレクトリ、TCP / UDPポート、共有メモリセグメント、またはIOデバイスです。サブジェクトとオブジェクトはそれぞれ一連のセキュリティ属性を持っています。サブジェクトがオブジェクトにアクセスしようとすると、オペレーティングシステムカーネルはこれらのセキュリティ属性を調べ、設定されている承認ルール（ポリシーとも呼ばれる）を調べて、アクセスを許可するかどうかを決定します。データベース管理システムのアクセス制御メカニズムでは、強制アクセス制御を適用することもできます。この場合、オブジェクトはテーブル、ビュー、プロシージャなどです。

強制アクセス制御では、セキュリティ ポリシーはポリシー管理者によって集中管理され、原則としてすべてのユーザーに対して適用されることが保証されます。ユーザーはポリシーを上書きできず、たとえば、本来は制限されているファイルへのアクセスを許可することはできません。一方、任意アクセス制御(DAC) では、サブジェクトがオブジェクトにアクセスする権限も制御され、ユーザーはポリシーを決定したり、セキュリティ属性を割り当てたりすることができます。

歴史的にも伝統的にも、MAC はマルチレベル セキュリティ(MLS) や特殊な軍事システムと密接に関連しています。この文脈では、MAC は MLS システムの制約を満たすための高度な厳密性を意味します。しかし最近では、 ^{[いつ? ] MAC は MLS のニッチから逸脱し、より主流になり始めています。Linux の}SELinuxやAppArmor、 Windows のMandatory Integrity Controlなどの最近の MAC 実装により、管理者は MLS の厳密性や制約なしに、ネットワーク攻撃やマルウェアなどの問題に集中できます。

歴史的に、MACは米国の機密情報を保護する手段としてのマルチレベルセキュリティ（MLS）と強く結び付けられてきました。このテーマに関する先駆的な研究であり、オレンジブックとしても知られるTrusted Computer System Evaluation Criteria（TCSEC）は、MACを「オブジェクトに含まれる情報の機密性（ラベルで表される）と、そのような機密情報にアクセスするための主体の正式な承認（つまり、許可）に基づいて、オブジェクトへのアクセスを制限する手段」と定義しました。^[2] HoneywellのSCOMP、USAFのSACDIN、NSAのBlacker、BoeingのMLS LANなどのMACの初期の実装は、軍事向けのセキュリティ分類レベルを堅牢な施行で保護するためにMLSに重点を置いていました。

MAC の「必須」という語は、軍事システムでの使用から派生した特別な意味を獲得しました。この文脈では、MAC は、制御メカニズムがあらゆる種類の破壊行為に抵抗できることを保証する極めて高度な堅牢性を意味し、それによって、行政命令 12958などの政府命令によって義務付けられたアクセス制御を実施できるようになります。施行は、商用アプリケーションよりも強制的であると考えられます。これにより、ベスト エフォート メカニズムによる施行は排除されます。MAC では、義務の絶対的またはほぼ絶対的な施行を提供できるメカニズムのみが受け入れられます。これは困難な要求であり、高保証戦略に精通していない人にとっては非現実的であると思われる場合があり、精通している人にとっては非常に困難です。

一部のシステムでは、ユーザーは他のユーザーにアクセスを許可するかどうかを決定する権限を持っています。これを可能にするために、すべてのユーザーはすべてのデータに対する許可を持っています。これは必ずしも MLS システムに当てはまるわけではありません。システム環境内のいずれかのデータへのアクセスを拒否される可能性のある個人またはプロセスが存在する場合、システムは MAC を実施するために信頼される必要があります。データ分類とユーザー許可にはさまざまなレベルがあるため、これは堅牢性の定量化された尺度を意味します。たとえば、分類された「最高機密」情報と許可されていないユーザーを含むシステム環境は、「機密」情報と少なくとも「機密」に許可されたユーザーを含むシステム環境よりも堅牢性が高くなります。一貫性を促進し、堅牢性の程度における主観性を排除するために、このトピックの広範な科学的分析とリスク評価により、システムのセキュリティ堅牢性の機能を定量化し、さまざまなセキュリティ環境で保証される信頼度にマッピングする画期的なベンチマーク標準化が作成されました。結果は CSC-STD-004-85 に文書化されました。^[3]堅牢性の 2 つの比較的独立したコンポーネント、保証レベルと機能が定義されました。どちらも、これらの基準に基づく認証に大きな信頼性を保証する程度の精度で指定されました。

Common Criteria規格^[4]はこの科学に基づいており、保証レベルをEAL レベルとして、機能仕様をProtection Profilesとして保存することを目的としていました。客観的な堅牢性ベンチマークのこれら 2 つの必須コンポーネントのうち、EAL レベルのみが忠実に保存されました。1 つのケースでは、TCSEC レベル C2 ^[5] (MAC 対応カテゴリではない) が、Controlled Access Protection Profile (CAPP) として Common Criteria にかなり忠実に保存されました。^[6] MLS Protection Profiles (B2 に似た MLSOSPP など) ^[7]は、B2 よりも一般的です。これらは MLS に準拠していますが、Orange Bookの前身のような詳細な実装要件がなく、目的に重点を置いています。これにより、認証者は、評価対象製品の技術的機能が目的を適切に達成しているかどうかを判断する際に、より主観的な柔軟性を持つようになり、評価対象製品の一貫性が損なわれ、信頼性の低い製品でも認証を取得しやすくなる可能性があります。これらの理由から、Protection Profile の技術的詳細の重要性は、製品の適合性を判断する上で非常に重要です。

このようなアーキテクチャは、特定の分類または信頼レベルで認証されたユーザーまたはプロセスが、異なるレベルの情報、プロセス、またはデバイスにアクセスするのを防ぎます。これにより、既知と未知の両方のユーザーとプロセスの封じ込めメカニズムが提供されます。未知のプログラムは、システムがデバイスやファイルへのアクセスを監視または制御する必要がある信頼できないアプリケーションで構成される場合があります。

UnisysのBlackerプロジェクトなど、いくつかの MAC 実装は、前世紀後半に、極秘と非機密を区別できるほど堅牢であると認定されました。その基盤となるテクノロジは時代遅れになり、更新されませんでした。現在、そのレベルの堅牢性があるとTCSECによって認定された実装はありません。ただし、堅牢性が低い製品もいくつか存在します。

Microsoft は、Windows VistaおよびServer 2008以降、実行中のプロセスに整合性レベル(IL) を追加する必須整合性制御(MIC) を Windows オペレーティングシステムに組み込んでいます。その目的は、信頼性の低いプロセスによる機密情報へのアクセスを制限することです。MIC は、低、中、高、システム、信頼されたインストーラーの 5 つの整合性レベルを定義します。^[8]既定では、プロセスは中 IL で開始されます。昇格されたプロセスは高い IL を受け取ります。^[9]既定では、子プロセスは親の整合性を継承しますが、親プロセスはより低い IL で子プロセスを起動できます。たとえば、Internet Explorer 7 は、低い IL でサブプロセスを起動します。Windows は、 IL に基づいてオブジェクトへのアクセスを制御します。ファイル、レジストリキー、またはその他のプロセスやスレッドなどの名前付きオブジェクトには、オブジェクトを使用できるプロセスの最小 IL を示すエントリがACLに含まれています。MIC は、プロセスの IL がオブジェクトの IL と等しいかそれよりも高い場合にのみ、プロセスがオブジェクトに書き込みまたは削除できるように強制します。さらに、メモリ内の機密データへのアクセスを防ぐため、プロセスは読み取りアクセスのためにより高いILを持つプロセスを開くことができません。^[10]

Apple社は、 iOSおよびmacOSオペレーティングシステムにTrustedBSDフレームワークの実装を組み込んでいます。^{[11] （「macOS」の「mac」は「} Macintosh 」の略語であり、「強制アクセス制御」の略語とは何の関係もありません）。コマンドライン機能は、限定された高レベルのサンドボックスインターフェースを提供します。^[12]sandbox_init

Googleが開発したAndroidオペレーティングシステムのバージョン5.0以降では、SELinuxを使用して、元のUIDベースのDACアプローチに加えてMACセキュリティモデルを適用しています。^[13]

Linuxや他の多くのUnixディストリビューションには、CPU (マルチリング)、ディスク、メモリ用の MAC があります。OS ソフトウェアは権限を適切に管理できない可能性がありますが、Linux は 1990 年代に非 Unix の代替品よりも安全ではるかに安定していることで有名になりました。^{[引用が必要]}

Amon Ott のRSBAC (ルール セット ベース アクセス制御) は、Linux カーネルに複数の異なるセキュリティ ポリシー/決定モジュールを許可するフレームワークを提供します。実装されているモデルの 1 つは、強制アクセス制御モデルです。RSBAC 設計の一般的な目標は、(廃止された) Orange Book (TCSEC) B1 レベルに到達することです。RSBAC で使用される強制アクセス制御のモデルは、Unix System V/MLS、バージョン 1.2.1 (1989 年に米国国立コンピュータ セキュリティ センターによって開発され、分類は B1/TCSEC) とほぼ同じです。RSBAC には、ストック カーネルへの一連のパッチが必要ですが、これはプロジェクト所有者によって非常に適切に保守されています。

Smack (Simplified Mandatory Access Control Kernel) は、Linuxカーネルの セキュリティモジュールであり、一連のカスタム強制アクセス制御ルールを使用して、データとプロセスの相互作用を悪意のある操作から保護します。その主な設計目標はシンプルさです。^[14] Linux 2.6.25リリース以降、正式に統合されています。^[15]

TOMOYO Linuxは、 NTTデータ社が開発したLinuxおよび組み込みLinux向けの軽量なMAC実装である。2009年6月にLinuxカーネルメインラインバージョン2.6.30に統合された。^[16] SELinuxが使用するラベルベースのアプローチとは異なり、TOMOYO Linuxはパス名ベースの強制アクセス制御を実行し、システムの動作を記述するプロセス呼び出し履歴に応じてセキュリティドメインを分離する。ポリシーはパス名で記述される。セキュリティドメインは単にプロセス呼び出しチェーンによって定義され、文字列で表されます。無効、学習、許可、強制の4つのモードがあり、管理者はドメインごとに異なるモードを割り当てることができます。TOMOYO Linuxは「学習」モードを導入しました。このモードでは、カーネル内で発生したアクセスが自動的に分析され、MACポリシーを生成するために保存されます。このモードはポリシー作成の最初のステップとなり、後で簡単にカスタマイズできます。

SUSE LinuxとUbuntu 7.10には、Linux 2.6のLinuxセキュリティモジュール（LSM）インターフェースを利用するAppArmorと呼ばれるMAC実装が追加されました。LSMは、カーネルコードのモジュールがACL（DAC ACL、アクセス制御リスト）を管理できるようにするカーネルAPIを提供します。AppArmorはすべてのプログラムを制限することはできず、バージョン2.6.36のLinuxカーネルではオプションです。^[17]

grsecurityLinuxカーネルのパッチであり、MAC実装（正確にはRBAC実装）を提供する。LSM APIgrsecurity経由では実装されていない。^[18]

ロシア軍向けに開発されたAstra Linux OSには、独自の強制アクセス制御機能が搭載されている。^[19]

FreeBSD は、TrustedBSD プロジェクトの一部として実装された強制アクセス制御をサポートしています。これは FreeBSD 5.0 で導入されました。FreeBSD 7.2 以降、MAC サポートはデフォルトで有効になっています。フレームワークは拡張可能で、さまざまな MAC モジュールがBibaやマルチレベル セキュリティなどのポリシーを実装しています。

Sun のTrusted Solaris は、セキュリティ ポリシーを強制するためにクリアランスとラベルを使用する、必須かつシステム強制のアクセス制御メカニズム (MAC) を使用します。ただし、ラベルを管理する機能は、マルチレベル セキュリティモードで動作するカーネルの強度を意味するものではないことに注意してください^{[引用が必要]}。ラベルと制御メカニズムへのアクセスは、カーネルによって維持される保護されたドメイン内での破損から^{[引用が必要]}強固に保護されていません。ユーザーが実行するアプリケーションは、ユーザーがセッションで作業するセキュリティ ラベルと組み合わされます。情報、プログラム、デバイスへのアクセスは、弱く制御されます^{[引用が必要]}。

• PA Loscocco、SD Smalley、PA Muckelbauer、RC Taylor、SJ Turner、JF Farrell。「障害の必然性：現代のコンピューティング環境におけるセキュリティの誤った想定」。第 21 回全国情報システム セキュリティ会議の議事録、303 ～ 314 ページ、1998 年 10 月。
• PA Loscocco、SD Smalley、「セキュリティが強化された Linux で重要なセキュリティ目標を達成」、Wayback Machineに 2017-07-08 にアーカイブ、2001 年オタワ Linux シンポジウムの議事録。
• ISO/IEC DIS 10181-3、情報技術、OSI セキュリティ モデル、セキュリティ フレームワーク、パート 3: アクセス制御、1993
• Robert NM Watson. 「OS アクセス制御拡張性の 10 年」。Commun. ACM 56、2 (2013 年 2 月)、52–63 ページ。

• 仮想化を使用して強制アクセス制御を実装する方法に関するブログ投稿。
• Microsoft 社員によるブログ投稿で、Mandatory Integrity Control の詳細と、それが MAC 実装とどのように異なるかが説明されています。
• GWV 形式セキュリティ ポリシー モデル 分離カーネル形式セキュリティ ポリシー、David Greve、Matthew Wilding、W. Mark Vanfleet。