第3章: DAC と MAC — 古典的モデルの設計思想と限界

DAC（任意アクセス制御）— 所有者が権限を握る

DAC（Discretionary Access Control） は「リソースの所有者が、誰にどのアクセスを許可するかを任意に決定できる」モデルです。 「Discretionary（裁量的・任意的）」という言葉が示す通り、ポリシーの設定権限が個々のリソース所有者の判断に委ねられています。 現代のOSで最も広く採用されており、UNIXのchmodやWindows NTFSのACLはその直接的な実装です。

UNIXパーミッション（chmod）の仕組み

UNIXではすべてのファイルに owner・group・others の3層と、read(r)・write(w)・execute(x) の3種類のビットが割り当てられます。chmod 755 script.sh はオーナーに rwx、グループと他者に r-x を付与するものです。 この9ビットが 1970年代から現在まで維持されているのは、実装の単純さゆえです。

しかし単純さには代償が伴います。グループの粒度が荒く、「特定のユーザーAだけ書き込みを許可したいが他のグループメンバーには禁止したい」という要求をネイティブに表現できません。 POSIXのACL拡張（setfacl）はこの問題を緩和しましたが、管理対象が増えると可視性が失われます。

Windows NTFS ACL の仕組み

Windowsは DACL（Discretionary ACL）と SACL（System ACL）を分離した、より細粒度な設計を採用しています。 DACL には ACE（Access Control Entry） が列挙され、各エントリが「Userまたはグループ、操作、Allow/Deny」を記述します。 ACE の評価順序は重要で、Deny エントリが Allow エントリよりも優先されます。 この設計はUNIXよりも表現力が高い一方、継承と上書きの複雑なルールが監査を困難にします。

DACの強みと弱み

Confused Deputy Problem（混乱した代理人問題）

DACの本質的な脆弱性を示す有名な思考実験が Confused Deputy Problem（1988年、Hardy）です。 コンパイラプログラム（Deputy）がユーザーの依頼でコードをコンパイルするシナリオを考えます。 コンパイラは課金のために請求ファイル（/etc/billing）への書き込み権限を持っています。 悪意あるユーザーが出力先として /etc/billing を指定した場合、コンパイラは「混乱した代理人」として ユーザーの代わりにシステムファイルを上書きしてしまいます。

コンパイラ自身はポリシー違反をしていません。しかし、コンパイラが持つ権限と、コンパイラを呼び出したユーザーの意図が分離されていないため、 ユーザーの権限を超えた操作が可能になります。DACはこの「呼び出し元の権限と代理人の権限の混同」を構造的に防げません。

MAC（強制アクセス制御）と Bell-LaPadula モデル

MAC（Mandatory Access Control） では、個々のリソース所有者ではなく、システム全体の管理者が定めたポリシーによってアクセスが強制されます。 所有者であっても、そのポリシーを回避することはできません（Mandatory = 強制）。

Bell-LaPadula モデルの背景（1973年）

Bell-LaPadula（BLP）モデル は1973年、MITREコーポレーションの David Bell と Leonard LaPadula が、 Roger Schell の指導のもと米国国防総省（DoD）向けに策定したものです。 DoDが抱える「Top Secret / Secret / Confidential / Unclassified」という多段階セキュリティ（MLS: Multi-Level Security）を 数学的に形式化することが目的でした。

モデルの核心は、すべての主体（Subject）と客体（Object）に セキュリティラベル を付与し、 そのラベルが形成する 格子（Lattice）構造 の上でアクセスを制御することです。 格子は「≦ で半順序関係が成立する集合」であり、ラベル間の「支配（dominate）」関係を定義します。

graph BT
  UC[Unclassified] --> C[Confidential]
  C --> S[Secret]
  S --> TS[Top Secret]
  style TS fill:#ef4444,stroke:#b91c1c,color:#fff
  style S fill:#f97316,stroke:#ea580c,color:#fff
  style C fill:#eab308,stroke:#ca8a04,color:#fff
  style UC fill:#22c55e,stroke:#15803d,color:#fff

BLPの2つの主要ルール

BLPモデルは機密性を保護するため、2つの基本プロパティを定義しています。

この2ルールが組み合わさることで、機密情報は常に同等以上のクリアランスを持つ主体しかアクセスできず、 低位ラベルへの「漏れ落ち」が構造的に防止されます。 Bell と LaPadula は、これら2プロパティを満たすすべての遷移が機密性を維持することを証明した Basic Security Theorem（BST） を示しました。

McLeanの批判と Tranquility Property

1985年、John McLean は BSTに対して致命的な反例 System Z を提示しました。 「全ラベルを Unclassified に再分類するポリシーは BSTを満たすが、明らかに安全でない」というものです。 この批判は、BLPが静的なラベル変更を制約していないことの問題を浮き彫りにしました。

この欠缺に対応するために追加されたのが Tranquility Property（静穏性） です。 セキュリティラベルはシステム稼働中に変更されないことを要求します（Strong Tranquility）。 実務的に非現実的なため、「ラベルを下げる変更は禁止するが上げる変更は許可する（Weak Tranquility）」 という緩和版も提案されています。

Biba モデル — 完全性の守護

Biba モデル（1975〜1977年、Kenneth Biba / MITRE Corp.）は、BLPが手つかずにした完全性（Integrity）の保護に特化して設計されました。 その構造は BLP の「数学的双対」と呼ばれます — 読み書きの方向ルールが正確に反転しているからです。

Biba における「完全性レベル」は信頼度のランクを意味します。 高完全性レベルのデータ（検証済み財務データなど）は、低完全性レベルのソース（外部入力や未検証データ）から汚染されてはなりません。No Read Down はこの汚染経路を、No Write Up は逆方向の偽データ注入を防ぎます。

BLPとBibaを同時に満たせない問題

BLPとBibaを同じシステムに同時適用しようとすると、深刻なジレンマが生まれます。 例えば、高機密・高完全性の主体が低機密・低完全性のオブジェクトと相互作用する場合、 BLPの「No Write Down」とBibaの「No Write Up」が矛盾します。 現実のシステムでは、機密性と完全性のどちらを優先するかを明示的に設計判断する必要があり、 多くの場合ユースケースに応じてどちらかを主軸に選択します。 軍事系では BLP、金融・医療系では Biba（またはClark-Wilson）が重視されます。

Clark-Wilson モデル — 商業的完全性の設計

1987年、David Clark と David Wilson は Clark-Wilson モデル を発表しました。 DoDを対象とした BLP/Biba とは異なり、商業環境（金融・会計）における完全性保護を目的として設計されています。

Well-Formed Transaction と職務分離

Clark-Wilson の核心概念は Well-Formed Transaction（適正トランザクション）です。 データへの変更は、システムが定めた TP（Transform Procedure: 変換手続き）を通じてのみ行われなければなりません。 データへの直接アクセスは禁止され、必ずTPが完全性チェックを伴うトランザクションとして実行されます。

もう一つの柱が 職務分離（Separation of Duties）です。 「発注者と承認者は別人でなければならない」「帳簿入力者と監査者は別人」という会計の原則をシステムポリシーとして強制します。 これにより単一の悪意ある内部者がシステムを不正操作することを困難にします。 Clark-Wilson は医療・金融・製造業の ERP システムに広く影響を与え、SOX コンプライアンスの技術的基盤の一つとなっています。

Orange Book（TCSEC）とその遺産

1983年から1985年にかけて米国国防総省（DoD）が発行した TCSEC（Trusted Computer System Evaluation Criteria）、 通称 Orange Book（表紙の色に由来）は、セキュリティ評価の最初の標準化試みでした。

Orange Book は評価レベルを以下のように分類しました。

Orange Book は DAC と MAC という用語を公式に定義した最初のドキュメントとして重要です。 ネットワーク環境への対応力不足（「Red Book」で補完）や商業システムへの適用困難さから、 2000年代以降は国際標準 Common Criteria（CC / ISO/IEC 15408） に主役を譲りましたが、 DACとMACという概念的枠組みは現代まで継承されています。

MACの現代的実装

古典的な理論モデルは、現代のOSとクラウド基盤に形を変えて生き続けています。

SELinux の Type Enforcement

SELinux（Security-Enhanced Linux） は、NSA（米国家安全保障局）が開発し 2001年にLinuxカーネルにマージされたMACフレームワークです。 BLPの軍事的MLS概念に加え、より実用的な Type Enforcement（TE） を中心に設計されています。

TEでは、すべてのプロセスに ドメイン（domain）、すべてのファイル/リソースに タイプ（type）というラベルを付与し、ポリシーファイルで「どのドメインがどのタイプに対してどの操作を許可するか」を宣言します。 デフォルト拒否（default deny）の原則により、ポリシーに記述のない操作はすべてブロックされます。

AppArmor のプロファイル方式

AppArmor（Ubuntu/SUSE標準）は SELinux よりも簡易な設計で、 各プログラムに プロファイル を作成し、アクセス可能なファイルパスと操作を列挙します。 SELinuxがラベルベースなのに対し、AppArmorはパスベースのため理解・管理が容易ですが、 ハードリンクやsymlink経由の攻撃に対してはSELinuxより弱いとされます。

Linux Capabilities による細粒度特権制御

従来のUNIXでは特権操作は「root（uid=0）かどうか」という二値判断でした。Linux Capabilities（カーネル2.2以降）はこのスーパーユーザー権限を約40の細粒度な ケーパビリティ に分割しました。 たとえば CAP_NET_BIND_SERVICE（1024以下のポートにバインド）だけを付与すれば、 フルのrootを与えずにWebサーバーを80番ポートで起動できます。 コンテナ環境（Docker, Kubernetes）では securityContext.capabilities でケーパビリティを削除・追加することが 最小権限原則の実践として標準化されています。

古典的なBLP・Biba・Clark-Wilsonは「どういう原則でアクセスを制御すべきか」という設計思想を与え、 SELinux・AppArmor・Linux Capabilities はその思想を現代のOS上で実装する道具です。 次章ではより実用的かつ現代的なモデルである RBAC（役割ベースアクセス制御） を詳しく扱います。