【SC試験 用語解説】アクセス制御モデル — DAC・MAC・RBAC・ABACの仕組みと使い分け

概要

アクセス制御モデルは「誰が」「どのリソースに」「どのような操作を」行えるかを定義・管理する仕組みです。SC試験では主要な4つのモデル（DAC・MAC・RBAC・ABAC）の特徴と適用場面、古典的なセキュリティモデル（Bell-LaPadula・Biba）が問われます。

4つの主要アクセス制御モデル

DAC（Discretionary Access Control：任意アクセス制御）

リソースの所有者が自分のリソースへのアクセス権を自分で設定する方式です。

例：LinuxのファイルシステムとACL
-rw-r--r-- alice:users config.txt
→ 所有者（alice）が読み書き可、グループ（users）・その他は読み取りのみ

特徴：
- 所有者が自由に権限を委譲できる（Discretionary = 任意）
- 権限の管理が分散するため一元管理が困難
- ウイルス感染等でユーザ権限が悪用されやすい

適用例：一般的なOSのファイルシステム・共有フォルダ

MAC（Mandatory Access Control：強制アクセス制御）

システム（管理者）が設定したセキュリティラベルに基づいてアクセスを強制する方式です。ユーザは自分のリソースへの権限を変更できません。

セキュリティラベルの例（機密度）：
Top Secret > Secret > Confidential > Unclassified

原則（Bell-LaPadulaモデル）：
- 読み取り：自分のラベル以下のみ（No Read Up）
- 書き込み：自分のラベル以上のみ（No Write Down）
→ 機密情報が低いラベルのユーザに漏れることを防ぐ

適用例：政府・軍事機関の情報システム・SELinux（Linuxのセキュリティモジュール）

RBAC（Role-Based Access Control：役割ベースアクセス制御）

ユーザに「役割（ロール）」を割り当て、役割に権限を設定する方式です。

RBAC の構造：
ユーザ → ロール → 権限

例：
Alice → [経理担当ロール] → [請求書閲覧、仕訳入力]
Bob  → [管理者ロール]   → [ユーザ管理、全データ閲覧]

特徴：
- ユーザ数が多くても役割で権限を一元管理できる
- 職務分離の実現が容易（会計記入と承認を別ロールに）
- 「ロールの爆発（Role Explosion）」：業務が複雑になるとロール数が増えすぎる問題

適用例：多くの業務システム・クラウドIAM（AWS IAM Roles等）

ABAC（Attribute-Based Access Control：属性ベースアクセス制御）

ユーザ・リソース・環境の「属性」を組み合わせてアクセスを制御する方式です。

属性の例：
ユーザ属性：部署=経理、役職=課長、勤務地=東京
リソース属性：機密レベル=機密、データ種別=給与情報
環境属性：アクセス時刻=9:00-18:00、場所=社内ネットワーク

ポリシー例：
「経理部門の課長以上が、社内ネットワークから、勤務時間内に給与情報にアクセスできる」

適用例：きめ細かいアクセス制御が必要なシステム・ゼロトラスト環境

古典的セキュリティモデル

Bell-LaPadula モデル（機密性重視）

軍事情報システムの機密性保護のために設計されたモデルです。

ルール	内容	目的
Simple Security Property（No Read Up）	自分のラベルより高い機密情報は読めない	低権限ユーザによる高機密情報の閲覧防止
*（Star）Property（No Write Down）	自分のラベルより低い場所への書き込み禁止	高機密情報を低いラベルに書き出して漏洩させることを防止

Bibaモデル（完全性重視）

Bell-LaPadulaの完全性版です。機密性より完全性（改ざん防止）を重視します。

ルール	内容	目的
No Write Up	自分のラベルより高い場所への書き込み禁止	低信頼度のユーザが高信頼度データを改ざんすることを防止
No Read Down	自分のラベルより低い信頼度のデータを読めない	低信頼データへのアクセスによる高信頼データへの影響を防止

職務分離（Separation of Duties）

重要な操作を複数の担当者に分割することで、内部不正や誤操作のリスクを軽減する原則です。

例：経理業務の職務分離
仕訳入力担当 ≠ 承認担当（同一人物が入力と承認を行えない）

例：システム管理の職務分離
開発者 ≠ 本番環境デプロイ担当（開発者が本番環境に直接アクセスできない）

RBACでこれを実現する場合、「仕訳入力ロール」と「承認ロール」を同一ユーザに付与しないように制御します。

SC試験での頻出ポイント

• DACとMACの最大の違い：DACは所有者が権限を設定、MACはシステムが強制的に制御
• RBACのメリット：ユーザ数が多くてもロールで権限を一元管理できる。職務分離も容易
• Bell-LaPadulaの2つのルール：No Read Up（上を読めない）・No Write Down（下に書けない）
• ABACとRBACの違い：ABACは属性の組み合わせで動的に判断（時間・場所・機密レベル等）。RBACは役割のみ
• 職務分離（SoD）の目的：重要処理を複数担当者で分割して内部不正・誤操作を防止

よくある誤問・ひっかけパターン

誤り① 「MACは管理者が全アクセス権限を設定する必要があるため運用負荷が高い」→ 正しい（MACの短所として認識すること）

誤り② 「Bell-LaPadulaモデルはデータの完全性を保護する」→ 誤。Bell-LaPadulaは機密性（Confidentiality）を保護するモデルです。完全性重視はBibaモデルです。

誤り③ 「RBACはすべての状況でABACより優れている」→ 誤。RBACはシンプルで管理しやすいが、時間・場所・文脈などの動的条件には対応できません。複雑な要件にはABACが適しています。

関連用語

• LDAP・Active Directory — ADではRBACをセキュリティグループで実現
• 特権アクセス管理（PAM） — 特権ロールへのアクセスをRBACで制御
• ゼロトラストアーキテクチャ — ABACを活用した継続的な認可の実現

重要キーワード

用語	説明
DAC	任意アクセス制御。リソース所有者が権限を設定
MAC	強制アクセス制御。セキュリティラベルに基づいてシステムが強制
RBAC	役割ベースアクセス制御。役割に権限を割り当てる
ABAC	属性ベースアクセス制御。ユーザ・リソース・環境の属性で制御
Bell-LaPadula	機密性重視のセキュリティモデル。No Read Up・No Write Down
職務分離	重要操作を複数担当者で分割して内部不正を防止する原則