【図解】アクセス制御モデル（DAC・MAC・RBAC）の違いを徹底解説！セキュリティの基礎から応用まで

「システムへのアクセス権限、どうやって管理していますか?」

この質問に対して、「Active Directoryで部署ごとのグループを作って管理している」と答える人もいれば、「ファイルサーバーのフォルダごとに担当者が設定している」と答える人もいるでしょう。あるいは、「機密情報のラベル付けをして厳格に制御している」という現場もあるかもしれません。

これらはすべて、セキュリティにおける「アクセス制御モデル」の実践例です。

アクセス制御は、情報セキュリティの3要素である機密性・完全性・可用性を守るための「門番」の役割を果たします。しかし、その手法にはDAC（任意アクセス制御）、MAC（強制アクセス制御）、RBAC（ロールベースアクセス制御）といった種類があり、それぞれの仕組みやメリット・デメリットを正しく理解していないと、組織の規模や守るべき情報のレベルに合わない運用をしてしまい、セキュリティ事故や業務効率の低下を招くことになります。

本記事では、これら3つの主要なアクセス制御モデルについて、なぜその仕組みが必要なのか、具体的にどのように動作するのかを、図解作成のヒントを交えながら徹底的に解説します。セキュリティ担当者やエンジニアとして、適切な設計判断ができるようになるための知識を深めていきましょう。

アクセス制御の基本概念と重要性

3段階のプロセス：識別・認証・認可

具体的なモデルの話に入る前に、アクセス制御が機能するまでの流れを整理しておきましょう。アクセス制御は、以下の3つのステップで構成されます。

1. 識別（Identification）

「あなたは誰ですか?」とID（識別子）を提示させるプロセスです。ユーザー名やメールアドレスなどがこれに当たります。この段階ではまだ、それが本人かどうかは確定していません。

2. 認証（Authentication）

「提示されたIDは本当にあなたのものですか?」を確認するプロセスです。パスワード、生体情報、ICカードなどを用いて、正当な利用者であることを検証します。

3. 認可（Authorization）

「あなたにはこのリソースを使う権限がありますか?」を判断するプロセスです。認証されたユーザーに対し、ファイルAの読み取りは許可するが、書き込みは許可しない、といった制御を行います。

今回解説するDAC、MAC、RBACは、この3番目の「認可（Authorization）」をどのようにルール化し、管理するかという「方式」の話です。

リファレンスモニタと最小特権の原則

アクセス制御システムの中核には、リファレンスモニタ（Reference Monitor）と呼ばれる概念が存在します。これは、主体（ユーザーやプログラム）から客体（ファイルやデータ）へのアクセス要求をすべて傍受し、許可・拒否を判断する機能のことです。OSのカーネルなどがこの役割を担っています。

リファレンスモニタは、すべてのアクセス要求に対して常に介在し、セキュリティポリシーに基づいて判断を下します。この仕組みがなければ、悪意あるプログラムや権限を持たないユーザーが、保護されるべき情報に自由にアクセスできてしまいます。

どのアクセス制御モデルを採用するにしても、目指すべきゴールは「最小特権の原則（Principle of Least Privilege）」の達成です。これは、業務を遂行するために「必要最低限の権限」のみを与え、それ以上の権限は一切与えないという考え方です。

例えば、Webサイトを閲覧するだけのユーザーにサーバーの設定変更権限を与えない、経理担当者に人事システムへのアクセス権を与えない、といった当たり前のことを指します。しかし、この「当たり前」を維持・管理し続けることが実務上非常に難しいため、効率的なモデル（RBACなど）が求められるのです。

最小特権の原則を徹底することで、万が一アカウントが乗っ取られた場合でも、被害を最小限に抑えることができます。攻撃者は奪取したアカウントの権限範囲内でしか活動できないため、機密情報への到達や重要システムの破壊といった深刻な被害を防ぐことが可能になります。

DAC（任意アクセス制御）：所有者の裁量による管理

DACの仕組みと特徴

DAC（Discretionary Access Control：任意アクセス制御）は、その名の通り、リソース（ファイルやディレクトリ）の所有者（オーナー）が、自分の裁量（Discretion）でアクセス権限を設定できる方式です。

最も身近な例は、WindowsやMac、LinuxなどのPC向けOSの標準的なファイル操作です。あなたが自分のPCでWord文書を作成したとします。そのファイルの所有者はあなたです。あなたは、そのファイルに対して「読み取り専用」に設定したり、特定の同僚に「編集権限」を与えたりすることができます。システム管理者が介入しなくても、所有者が自由に決められる点が最大の特徴です。

技術的には、ACL（Access Control List：アクセス制御リスト）を用いて実装されます。ファイルごとに「誰に、どの権限を与えるか」というリストを持たせる形です。

具体的な実装例を見てみましょう。

Linuxの例（パーミッション）: rwxr-xr-- という表記は、所有者は読み書き実行可、グループは読み実行可、その他は読み取りのみを意味します。
Windowsの例: ファイルのプロパティにある「セキュリティ」タブでユーザーを追加し、「フルコントロール」「変更」「読み取り」などをチェックボックスで選択します。

DACの利点は、現場の判断で迅速に権限を変更できることです。プロジェクトのメンバーが増えたとき、所有者がすぐに新メンバーに権限を付与できます。管理者の承認や複雑な申請手続きを経る必要がないため、業務のスピード感を損ないません。

DACにおけるセキュリティリスク：トロイの木馬

DACの最大の問題点は、「所有者が実行するプログラムは、所有者と同じ権限を持つ」という点にあります。これを利用した攻撃が「トロイの木馬」です。

例えば、あなたが悪意のあるゲームアプリをダウンロードして実行したとします。DAC環境下では、あなたがそのゲームアプリ（プログラム）を実行した瞬間、そのプログラムは「あなた」として動作します。つまり、そのプログラムは、あなたがアクセスできるすべてのファイル（写真、書類、メールなど）に対して、読み取りや削除を行うことができてしまいます。

さらに深刻なのは、そのプログラムがあなたの権限で他のファイルに対する権限設定を変更できることです。例えば、社外秘のファイルに対して「全員が読み取り可能」という設定に変更し、情報を外部に流出させることも可能です。所有者の意図しない形で、所有者の権限が悪用されてしまう。これがDACの構造的な弱点です。

この問題は、ユーザー教育だけでは解決できません。どんなに注意深いユーザーでも、巧妙に偽装されたマルウェアを完全に見抜くことは困難だからです。そのため、より高度なセキュリティが求められる環境では、DACだけに頼ることはできません。

DACのメリットとデメリットまとめ

メリット：

柔軟性が高い： 現場のユーザーが状況に応じて即座に権限を変更できるため、コラボレーションが円滑に進む。
直感的： 「自分のものは自分で管理する」という所有権の概念に基づいているため、理解しやすい。
導入コストが低い： 特別な設定やポリシー策定が不要で、OSの標準機能として提供されている。

デメリット：

管理が属人化する： 誰がどのファイルに権限を持っているか、全体像を把握するのが困難になる。
セキュリティレベルの統一が困難： ユーザーが面倒くさがって「全員にフルコントロール」を与えてしまうなど、セキュリティホールができやすい。
マルウェアに弱い： 前述の通り、所有者の権限で動作するマルウェアに対して無防備になりやすい。
監査が困難： 権限設定が分散しているため、コンプライアンス監査時に「誰がいつどのファイルにアクセスできたか」を追跡するのが非常に手間がかかる。

MAC（強制アクセス制御）：管理者による絶対的な統制

MACの仕組みとセキュリティラベル

MAC（Mandatory Access Control：強制アクセス制御）は、DACの「所有者任せ」に対するアンチテーゼとして生まれた、非常に厳格なモデルです。ここでいう「Mandatory（強制的）」とは、リソースの所有者であっても変更できない、という意味です。

MACでは、システム管理者（セキュリティ管理者）があらかじめ定めたセキュリティポリシーに従って、システムが自動的かつ強制的にアクセス可否を判断します。その判断基準となるのが「セキュリティラベル（機密ラベル）」です。

すべての主体（ユーザー）と客体（データ）には、以下のようなランク付け（ラベル）が行われます。

主体（ユーザー）のクリアランス（取扱認可）：

Top Secret（機密）
Secret（極秘）
Confidential（秘）
Unclassified（一般）

客体（データ）の分類（機密性）：

Top Secret（機密データ）
Secret（極秘データ）
Confidential（秘密データ）
Unclassified（一般データ）

システムは、アクセス要求があるたびに双方のラベルを比較します。「Top Secretのクリアランスを持つユーザーだけが、Top Secretのデータを読める」といったルールを、例外なく適用します。たとえファイルの作成者であっても、「このTop Secretファイルは特別に友人のBさんに見せよう」と設定を変更することはできません。

この厳格さこそが、MACの最大の特徴であり、強みです。人間の判断ミスや悪意による設定変更を完全に排除できるため、軍事機関や政府機関など、情報漏えいが国家安全保障に関わるような組織で採用されています。

Bell-LaPadulaモデル：機密性を守る鉄則

MACの実装において、試験や実務知識として頻出なのがBell-LaPadula（ベル・ラパドゥーラ）モデルです。これは「機密性（漏えい防止）」を守ることに特化したモデルで、以下の2つのルールで構成されます。

1. No Read Up（上を読み取ってはいけない）

一般レベルのユーザーは、機密レベルの情報を読めない。これは直感的に理解できるルールです。機密情報へのアクセスを制限することで、権限のない者による閲覧を防ぎます。

2. No Write Down（下へ書き込んではいけない）

ここが重要かつ、理解しにくい部分です。機密レベルのユーザーは、一般レベルのファイルへの書き込みが禁止されます。

なぜこのようなルールが必要なのでしょうか。理由は、機密レベルのユーザーが誤って（あるいはマルウェアに感染して）、機密情報を一般レベルのファイルにコピー＆ペーストしてしまうと、そこから情報が漏えいするからです。一般レベルのファイルは、より多くのユーザーがアクセスできるため、機密情報がそこに書き込まれると、本来知るべきでない人々の目に触れることになります。

情報の流れを「下から上」への一方通行にすることで、漏えいを物理的に防ぎます。機密情報は機密レベルのファイルにのみ書き込まれ、一般レベルに降りてくることがない。この仕組みにより、内部犯行やマルウェア感染時でも、機密情報の拡散を防ぐことができます。

なお、Bell-LaPadulaモデルは機密性に特化しているため、完全性（データの改ざん防止）を重視する場合には、Biba（ビバ）モデルという別のMACモデルが使用されます。Bibaモデルでは、逆に「No Write Up（上へ書き込んではいけない）」「No Read Down（下を読み取ってはいけない）」というルールが適用されます。

MACのメリットとデメリットまとめ

メリット：

強固な機密性： ユーザーのミスや悪意による設定変更を許さないため、情報漏えいリスクが極めて低い。
トロイの木馬対策： たとえマルウェアが所有者権限で動いたとしても、ラベルによる制限があるため、機密情報を外部（下位レベル）に書き出すことができない。
コンプライアンス対応： 政府規制や業界基準で求められる厳格なアクセス管理要件を満たせる。
監査の容易さ： セキュリティポリシーが一元管理されているため、誰がどのレベルの情報にアクセスできるかが明確。

デメリット：

運用コストが莫大： すべてのファイル、すべてのユーザーに適切なラベルを付与・管理する必要がある。
融通が利かない： 「上司の承認があれば一時的に見せる」といった柔軟な対応が難しく、業務効率を犠牲にする場合がある。
専門知識が必要： SELinuxなどのMAC実装は設定が複雑で、トラブルシューティングが難しい。
ユーザビリティの低下： 必要なファイルにアクセスできない、共同作業がしにくいなど、日常業務に支障をきたす可能性がある。

RBAC（ロールベースアクセス制御）：組織構造に適した現代の標準

「人」ではなく「役割」に権限を与える

RBAC（Role-Based Access Control：ロールベースアクセス制御）は、DACの管理の煩雑さと、MACの運用の硬直さを解消するために考案された、現代の企業組織に最も適したモデルです。

RBACの最大の特徴は、ユーザーと権限を直接結びつけないことです。間に「ロール（Role：役割）」というクッションを挟みます。

RBACの3つのステップ：

ロールの定義： まず、「経理担当」「営業マネージャー」「システム管理者」といった業務上の役割（ロール）を定義します。
権限の割り当て： 次に、そのロールに対して必要な権限（会計システムへの入力権、顧客データの閲覧権など）を割り当てます。
ユーザーの割り当て： 最後に、ユーザー（社員）を適切なロールに所属させます。

この3層構造により、「人」と「権限」を切り離すことができます。人事異動があっても、個別のリソースごとに権限を変更する必要がなく、ユーザーの所属ロールを変更するだけで、すべての権限が自動的に切り替わります。

なぜRBACが企業に選ばれるのか：人事異動のシナリオ

企業では、頻繁に人事異動が発生します。DACの場合、Aさんが営業部から経理部に異動すると、管理者は「営業フォルダからAさんを削除」し、「経理フォルダにAさんを追加」し、「会計システムのIDにAさんを追加」し、「CRMシステムからAさんを削除」し…と、リソースごとの設定変更に追われます。システムが10個あれば、10箇所の設定変更が必要です。これではミスが必ず起きます。

RBACならどうでしょうか。管理者は、Aさんの所属ロールを「営業担当ロール」から「経理担当ロール」に付け替えるだけです。それだけで、Aさんは営業データのアクセス権を失い、自動的に経理システムのアクセス権を得ます。

「人」が変わっても「役割」に必要な権限は変わらない、という企業組織の性質をシステムに落とし込んだのがRBACなのです。この効率性こそが、RBACが多くの企業で標準採用されている理由です。

また、新入社員の受け入れや退職処理も劇的に簡単になります。新入社員には「一般社員ロール」を付与するだけで、必要な全システムへのアクセス権が即座に設定されます。退職時は、そのロールを外すだけで、すべてのアクセス権を一括で剥奪できます。

RBACの高度な機能：階層化と職務分掌

RBACは単なるグループ管理以上の機能を持っています。

ロールの階層化（Hierarchy）

「課長ロール」は「一般社員ロール」の権限をすべて継承する、といった親子関係を定義できます。これにより、設定の手間をさらに減らせます。例えば、「部長ロール」は「課長ロール」の権限を継承し、「課長ロール」は「一般社員ロール」の権限を継承するという階層構造を作れば、上位職ほど多くの権限を持つという組織の実態を自然に表現できます。

職務分掌（Separation of Duties：SoD）

内部不正を防ぐための重要な機能です。「発注ロール」と「承認ロール」という2つのロールに対し、同一のユーザーが両方に所属することを禁止する（静的SoD）、あるいは同時に両方の権限を行使することを禁止する（動的SoD）設定が可能です。

例えば、経理部門では、請求書の入力担当者と承認者を必ず別の人にすることで、不正な支出を防ぎます。購買部門では、発注担当と検収担当を分離することで、架空発注を防ぎます。このような「牽制」の仕組みをシステムレベルで強制できるのが、RBACの職務分掌機能です。

RBACのメリットとデメリットまとめ

メリット：

管理効率の最大化： 人事異動、入社、退職に伴う権限変更（プロビジョニング）が劇的に楽になる。
ポリシーの一貫性： 組織図や職務規定に基づいて権限を設計できるため、セキュリティポリシーとの整合性が取りやすい。
最小特権の実現： 役割に必要な権限だけをセットにして渡すため、不要な権限の付与を防ぎやすい。
監査対応の容易さ： 「誰がどのロールに属しているか」「そのロールはどんな権限を持つか」が明確なため、コンプライアンス監査に対応しやすい。
スケーラビリティ： 組織が成長してユーザー数が増えても、ロール定義を変えなければ管理コストが増大しない。

デメリット：

ロール設計の難易度（Role Engineering）： 導入時に、社内の業務を洗い出し、適切なロールと権限のセットを定義する作業が非常に大変。業務フローの理解と、セキュリティの専門知識の両方が必要。
ロールの爆発（Role Explosion）： 細かな例外（「Aさんだけは特別にこのファイルも見たい」）に対応するために新しいロールを作り続けると、ロール数が数百・数千に膨れ上がり、管理不能になるリスクがある。
柔軟性の制約： プロジェクト単位での一時的な権限付与など、組織図に当てはまらない状況に対応しにくい場合がある。

3つのモデルの比較と使い分け

これまでの解説を表にまとめました。試験前の復習や、設計時の検討材料として活用してください。

比較項目	DAC（任意アクセス制御）	MAC（強制アクセス制御）	RBAC（ロールベースアクセス制御）
誰が決める?	リソースの所有者	システム管理者（ポリシー）	システム管理者（役割定義）
何に基づく?	ユーザーID（ACL）	セキュリティラベル	ロール（役割）
柔軟性	高い（高すぎる場合も）	低い（非常に硬直的）	中（組織変更に対応可能）
主な用途	個人PC、小規模な共有フォルダ	軍事、機密機関、高信頼OS	一般企業、ERP、AD環境
リスク・弱点	管理ミス、トロイの木馬	運用コスト大、使い勝手	設計の複雑さ、ロール爆発
代表的な実装	Windows NTFSアクセス権	SELinux, Trusted Solaris	Active Directory, AWS IAM

複合的な利用が現実解

実際のシステムでは、これらが組み合わせて使われることがほとんどです。例えば、Windows Serverのファイル共有では、基本的にはRBACの考え方で「Active Directoryのグループ」に対してアクセス権を設定します（技術的にはACLを使うのでDACの仕組みを利用してRBACを擬似的に実現しています）。

その上で、特定の極秘プロジェクトフォルダに関しては、専用の管理ツールでアクセスを厳格に制限する（MAC的な運用）といった具合です。また、個人のホームディレクトリについては、ユーザー自身が管理できるようにDAC的な運用を許可する、という使い分けもよく見られます。

また、最近では**ABAC（Attribute-Based Access Control：属性ベースアクセス制御）**という新しいモデルも普及しています。これはRBACの進化系で、「ユーザーの属性（部長、在籍3年以上など）」だけでなく、「環境の属性（社内ネットワークからアクセスしているか、平日の9時〜17時か、使用デバイスは会社支給か）」や「リソースの属性（作成日が1年以内、機密度レベル2など）」を組み合わせて動的に判断するものです。

例えば、「部長ロールで、かつ社内ネットワークから、かつ営業時間内にアクセスした場合のみ、顧客の個人情報を閲覧可能」といった、より細かく状況に応じた制御が可能になります。ゼロトラストセキュリティの文脈では、このABACが主流になりつつあります。

現場で役立つ記述式対策：シナリオ問題への適用

セキュリティ試験の記述問題や、実際の現場での設計レビューでは、「この状況にはどのモデルを適用すべきか?」という判断力が問われます。典型的なシナリオを見てみましょう。

シナリオ1：人の入れ替わりが激しいコールセンター

課題：

オペレーターの入退社が頻繁で、アカウント作成や権限付与の作業負荷が高い。設定ミスによる情報アクセス権の消し忘れも発生しており、退職者のアカウントが残り続けるというセキュリティリスクも顕在化している。

解法：

RBACを採用する。「オペレーター」というロールを作成し、必要なツール（CRMシステム、FAQ検索、チケット管理など）へのアクセス権を事前にセットしておく。入社時はユーザーをそのロールに追加するだけで、すべての必要なシステムへのアクセス権が一括で付与される。退職時はロールから外すだけで、すべての権限を即座に剥奪できる。

さらに、「オペレーター」「スーパーバイザー」「マネージャー」といった階層化されたロールを作ることで、昇進時の権限変更も容易になります。

シナリオ2：国家機密を扱う研究施設

課題：

研究員が意図せず機密データをUSBメモリに保存したり、メールで外部に送信したりするリスクをシステム的に完全に封じ込めたい。研究員の善意に頼るのではなく、技術的に不可能にしたい。

解法：

MACを採用する。データに「極秘」「秘」「一般」といったラベルを付与し、研究員にもクリアランスレベルを設定する。Bell-LaPadulaモデルの「No Write Down」ルールにより、極秘データを取り扱う研究員は、一般レベルのUSBメモリやメールシステム（外部送信可能）への書き込みがシステムレベルで禁止される。

たとえマルウェアに感染したとしても、ラベルによる制限があるため、機密情報を外部に持ち出すことは技術的に不可能になります。

シナリオ3：部門ごとのファイル共有サーバー

課題：

プロジェクト単位でメンバーが頻繁に入れ替わり、現場の判断で素早く情報の共有範囲を変えたい。管理者が毎回設定変更するのは現実的ではなく、業務スピードが低下している。ただし、完全に野放しにするとセキュリティリスクもある。

解法：

DAC（または、グループ管理権限を委譲したRBAC）を採用する。プロジェクトフォルダの所有者（プロジェクトリーダー）に権限管理を任せることで、業務スピードを優先する。ただし、以下の対策を併用する。

アクセスログを詳細に記録し、定期的に監査する
重要な機密情報は別の厳格な管理下に置く
所有者向けのセキュリティ教育を徹底する
定期的に権限設定をレビューし、不適切な設定を是正する

このように、単一のモデルに固執するのではなく、業務要件とセキュリティ要件のバランスを取りながら、適切な組み合わせを選択することが重要です。

シナリオ4：クラウドサービスのマルチテナント環境

課題：

複数の企業（テナント）が同じクラウド基盤を利用している。各企業のデータは完全に分離する必要があるが、企業内部では柔軟な権限管理も必要。

解法：

MACとRBACの組み合わせを採用する。まず、テナント間の分離はMACで実現する。各テナントのデータに「テナントA」「テナントB」といったラベルを付与し、クリアランスを持たないユーザーは絶対にアクセスできないようにする。

その上で、テナント内部の権限管理はRBACで実現する。各企業は自社のユーザーに対して「管理者」「一般ユーザー」「閲覧のみ」といったロールを割り当て、柔軟に管理できるようにする。

このように、セキュリティの要求レベルが異なる階層に対して、異なるモデルを適用することで、最適なバランスを実現できます。

理解度チェック！アクセス制御モデル練習問題

記事で学んだDAC、MAC、RBACそれぞれの特徴や違いを、クイズ形式で確認しましょう。知識の定着確認として、気軽に取り組んでみてください。

【演習】アクセス制御モデル（DAC/MAC/RBAC）理解度チェック

まとめ

アクセス制御モデルは、単なる用語の違いではありません。「組織が情報をどのように扱いたいか」「何を優先して守りたいか」というセキュリティポリシーそのものを反映したものです。

DACは「自由と性善説」のモデル。ユーザーの自律性を信頼し、柔軟な運用を可能にしますが、その分リスクも高まります。

MACは「統制と性悪説」のモデル。人間のミスや悪意を前提として、システムが強制的に制御します。最高レベルのセキュリティを実現できますが、運用コストと利便性を犠牲にします。

RBACは「効率と組織論」のモデル。企業組織の構造と業務の実態を反映し、管理効率とセキュリティのバランスを取ります。現代の企業システムにおいて、最も現実的な選択肢です。

これらを理解した上で、自社の環境や守るべき資産の性質に合わせて最適なモデルを選択・組み合わせることが、真にセキュアなシステム構築への第一歩となります。

重要なのは、「完璧なモデル」は存在しないということです。どのモデルにも長所と短所があり、組織の規模、業種、扱う情報の機密度、業務の特性によって、最適な選択は変わります。セキュリティ担当者には、これらのモデルの特性を深く理解し、状況に応じて適切な判断を下す能力が求められます。

しかし、どんなに完璧なアクセス制御モデルを構築しても、すべてを無に帰してしまう恐ろしいリスクが存在します。それが、システムに対してあらゆる操作が可能な「特権ID（管理者アカウント）」の乗っ取りです。

特権IDは、アクセス制御の「神の視点」を持ちます。DACの所有者制限も、MACのラベル制御も、RBACのロール分離も、特権IDの前ではすべて無効化されます。攻撃者にとって、特権IDの奪取は最終目標であり、一度手に入れれば、あらゆるデータの窃取、改ざん、削除が可能になります。

次回は、攻撃者の最終目標であるこの特権IDをどのように管理し、監視すべきか。一般ユーザーのID管理とは次元の異なる「特権ID管理」の世界について深掘りしていきます。特権IDの棚卸し、パスワードの定期変更、操作ログの監視、特権アクセス管理（PAM）ツールの導入など、具体的な対策手法を解説します。