「システムへのアクセス権限、どうやって管理していますか?」
この質問に対して、「Active Directoryで部署ごとのグループを作って管理している」と答える人もいれば、「ファイルサーバーのフォルダごとに担当者が設定している」と答える人もいるでしょう。あるいは、「機密情報のラベル付けをして厳格に制御している」という現場もあるかもしれません。これらはすべて、アクセス制御の「方式」の違いです。
私はCIOとして自社のIT統制を担っていた頃、機密情報の格付けが未整備だったため、情報分類の定義から着手しました。区分を確立するまでに多くの時間を要し、その後のアクセス権付与の設計・実装にも時間がかかりました。Active Directoryだけで実装しようとすると煩雑で限界があり、サードパーティ製のアクセス管理製品を使えばより精度高く制御できたと振り返っています。アクセス制御モデルの違いを先に整理しておくと、設計の見通しが立てやすくなります。
本記事では、代表的なアクセス制御モデルであるDAC（任意アクセス制御）、MAC（強制アクセス制御）、RBAC（ロールベースアクセス制御）、そしてゼロトラスト時代に注目されるABAC（属性ベースアクセス制御）の4つを比較します。まず冒頭で4モデルの違いを一覧表と選定基準で整理し、そのうえで各モデルの仕組み・メリット・デメリットを深掘りします。「どのモデルを選べばよいか」で迷っている方も、SC試験でこの4つの区別を問われる方も、この記事で判断軸を固めていきましょう。
アクセス制御モデルの比較一覧（DAC・MAC・RBAC・ABAC）
まず結論から示します。アクセス制御モデルは「誰が権限を決めるのか」「何を基準に許可・拒否を判断するのか」で性格が大きく変わります。下の比較表は、DAC・MAC・RBAC・ABACの4モデルを同じ観点で並べたものです。詳しい解説を読む前の全体像として、また試験直前の総復習として活用してください。
| 比較項目 | DAC（任意） | MAC（強制） | RBAC（ロール） | ABAC（属性） |
|---|---|---|---|---|
| 誰が決める? | リソースの所有者 | システム管理者（ポリシー） | システム管理者（役割定義） | ポリシー管理者（属性ルール） |
| 判断の基準 | ユーザーID（ACL） | セキュリティラベル | ロール（役割） | 主体・客体・環境の属性 |
| 制御の粒度 | ファイル単位 | 機密レベル単位 | 役割単位 | 属性の組み合わせ（動的） |
| 柔軟性 | 高い（高すぎる場合も） | 低い（非常に硬直的） | 中（組織変更に対応可能） | 非常に高い（条件を動的に評価） |
| 主な用途 | 個人PC、小規模な共有フォルダ | 軍事、機密機関、高信頼OS | 一般企業、ERP、AD環境 | ゼロトラスト、クラウド、きめ細かい制御 |
| リスク・弱点 | 管理ミス、トロイの木馬 | 運用コスト大、使い勝手 | 設計の複雑さ、ロール爆発 | ポリシー設計・属性管理が複雑 |
| 代表的な実装 | Windows NTFSアクセス権 | SELinux、Trusted Solaris（現Solaris Trusted Extensions） | AD（グループによるRBAC的運用）、Kubernetes RBAC | XACML、AWS IAM（条件・タグ） |
4モデルを一言で言い分けると
比較表を頭に入れやすくするために、それぞれの性格を一言で表現しておきます。
DAC＝「所有者の裁量」： ファイルを作った人が、誰に何を許すかを自分で決める。柔軟だが統制が効きにくい。
MAC＝「管理者の強制」： 機密ラベルに基づき、システムが問答無用で許可・拒否を決める。所有者でもルールを変えられない。
RBAC＝「役割に権限」： 「経理担当」「営業マネージャー」といった役割に権限をまとめ、人を役割に割り当てる。企業の標準。
ABAC＝「属性で動的判断」： 誰が・いつ・どこから・どんな端末で、といった属性の組み合わせでその都度判断する。ゼロトラストの中核。
学び始めの人がつまずきやすいのが、RBACとABACの境目です。RBACは「役割」という静的なくくりで権限を渡すのに対し、ABACは役割に加えて「時間・場所・端末の状態」といった動的な条件を評価します。「部長ロールだから常に閲覧可」がRBAC、「部長ロールで、かつ社内ネットワークから、かつ営業時間内なら閲覧可」がABACだと押さえておくと混同しません。
選定基準：どのモデルを選ぶべきか
「結局、自社ではどれを使えばいいのか」という問いには、守るべき情報の性質と組織の運用実態から逆算するのが近道です。選定の目安を整理します。
DACを選ぶ場面： 個人PCや小規模な共有フォルダなど、現場の判断でスピーディに共有範囲を変えたいとき。ただし監査ログと定期レビューの併用が前提。
MACを選ぶ場面： 軍事・政府・研究機関など、情報の持ち出しを「善意に頼らず技術的に不可能」にしたいとき。機密度の分類が明確な環境。
RBACを選ぶ場面： 一般的な企業システム。組織の役割構造が明確で、人事異動や入退社が頻繁な場合に管理効率が最大化する。
ABACを選ぶ場面： ゼロトラストやクラウド環境で、アクセス元・時間帯・端末状態まで加味したきめ細かい制御が必要なとき。
重要なのは、これらは排他的な選択肢ではないという点です。実際のシステムでは複数のモデルを組み合わせて運用するのが現実解であり、その具体例は後半の「4モデルの使い分けと複合運用」で詳しく扱います。まずは各モデルの仕組みを一つずつ理解していきましょう。
テンプレート集
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
アクセス制御の基本概念と重要性
アクセス制御は、情報セキュリティの3要素である機密性・完全性・可用性を守るための「門番」の役割を果たします。各モデルの違いを正しく理解しないまま運用すると、組織の規模や守るべき情報のレベルに合わない設計になり、セキュリティ事故や業務効率の低下を招きます。個別モデルの話に入る前に、すべてのモデルに共通する土台を整理しておきましょう。
3段階のプロセス：識別・認証・認可
具体的なモデルの話に入る前に、アクセス制御が機能するまでの流れを整理しておきましょう。アクセス制御は、以下の3つのステップで構成されます。
1. 識別（Identification）
「あなたは誰ですか?」とID（識別子）を提示させるプロセスです。ユーザー名やメールアドレスなどがこれに当たります。この段階ではまだ、それが本人かどうかは確定していません。
2. 認証（Authentication）
「提示されたIDは本当にあなたのものですか?」を確認するプロセスです。パスワード、生体情報、ICカードなどを用いて、正当な利用者であることを検証します。
3. 認可（Authorization）
「あなたにはこのリソースを使う権限がありますか?」を判断するプロセスです。認証されたユーザーに対し、ファイルAの読み取りは許可するが、書き込みは許可しない、といった制御を行います。
今回解説するDAC、MAC、RBAC、ABACは、この3番目の「認可（Authorization）」をどのようにルール化し、管理するかという「方式」の話です。学び始めの頃に多いのが、認証（本人確認）と認可（権限判断）を混同するつまずきです。パスワードが合っていること（認証）と、そのファイルを開けること（認可）は別の話だと切り分けて理解しておきましょう。
リファレンスモニタと最小特権の原則
アクセス制御システムの中核には、リファレンスモニタ（Reference Monitor）と呼ばれる概念が存在します。これは、主体（ユーザーやプログラム）から客体（ファイルやデータ）へのアクセス要求をすべて傍受し、許可・拒否を判断する機能のことです。OSのカーネルなどがこの役割を担っています。
リファレンスモニタは、すべてのアクセス要求に対して常に介在し、セキュリティポリシーに基づいて判断を下します。この仕組みがなければ、悪意あるプログラムや権限を持たないユーザーが、保護されるべき情報に自由にアクセスできてしまいます。
どのアクセス制御モデルを採用するにしても、目指すべきゴールは「最小特権の原則（Principle of Least Privilege）」の達成です。これは、業務を遂行するために「必要最低限の権限」のみを与え、それ以上の権限は一切与えないという考え方です。
例えば、Webサイトを閲覧するだけのユーザーにサーバーの設定変更権限を与えない、経理担当者に人事システムへのアクセス権を与えない、といった当たり前のことを指します。しかし、この「当たり前」を維持・管理し続けることが実務上非常に難しいため、効率的なモデル（RBACなど）が求められるのです。
最小特権の原則を徹底することで、万が一アカウントが乗っ取られた場合でも、被害を最小限に抑えることができます。攻撃者は奪取したアカウントの権限範囲内でしか活動できないため、機密情報への到達や重要システムの破壊といった深刻な被害を防ぐことが可能になります。
DAC（任意アクセス制御）：所有者の裁量による管理
DACの仕組みと特徴
DAC（Discretionary Access Control：任意アクセス制御）は、データの所有者が、誰にどの権限を与えるかを自らの裁量で自由に（任意に）決めることができる方式です。技術的にはACL（アクセス制御リスト）を用いて管理されます。柔軟な運用が可能ですが、所有者の設定ミスによる情報漏えいリスクがあるため、現在は「最小特権の原則」に基づいた運用が求められます。
最も身近な例は、WindowsやMac、LinuxなどのPC向けOSの標準的なファイル操作です。あなたが自分のPCでWord文書を作成したとします。そのファイルの所有者はあなたです。あなたは、そのファイルに対して「読み取り専用」に設定したり、特定の同僚に「編集権限」を与えたりすることができます。システム管理者が介入しなくても、所有者が自由に決められる点が最大の特徴です。
技術的には、ACL（Access Control List：アクセス制御リスト）を用いて実装されます。ファイルごとに「誰に、どの権限を与えるか」というリストを持たせる形です。
具体的な実装例を見てみましょう。
Linuxの例（パーミッション）:
rwxr-xr--という表記は、所有者は読み書き実行可、グループは読み実行可、その他は読み取りのみを意味します。厳密には、これは所有者・グループ・その他の3区分だけを指定するモード（パーミッションビット）で、ユーザーごとのリストであるACLとは別の仕組みです。特定のユーザーやグループを個別に追加したい場合は、setfaclコマンドで設定するPOSIX ACLを使います。どちらも所有者が自分で変更できるため、DACの実装にあたります。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 ＞ Secret ＞ Confidential ＞ Unclassified の順で、Top Secretが最上位、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（下を読み取ってはいけない）」というルールが適用されます。この「機密性のBell-LaPadula」「完全性のBiba」の対比は、SC試験で狙われやすいポイントです。
MACのメリットとデメリットまとめ
メリット：
強固な機密性： ユーザーのミスや悪意による設定変更を許さないため、情報漏えいリスクが極めて低い。
トロイの木馬対策： たとえマルウェアが所有者権限で動いたとしても、ラベルによる制限があるため、機密情報を外部（下位レベル）に書き出すことができない。
コンプライアンス対応： 政府規制や業界基準で求められる厳格なアクセス管理要件を満たせる。
監査の容易さ： セキュリティポリシーが一元管理されているため、誰がどのレベルの情報にアクセスできるかが明確。
デメリット：
運用コストが莫大： すべてのファイル、すべてのユーザーに適切なラベルを付与・管理する必要がある。
融通が利かない： 「上司の承認があれば一時的に見せる」といった柔軟な対応が難しく、業務効率を犠牲にする場合がある。
専門知識が必要： SELinuxなどのMAC実装は設定が複雑で、トラブルシューティングが難しい。
ユーザビリティの低下： 必要なファイルにアクセスできない、共同作業がしにくいなど、日常業務に支障をきたす可能性がある。
RBAC（ロールベースアクセス制御）：組織構造に適した現代の標準
「人」ではなく「役割」に権限を与える
RBAC（Role-Based Access Control：ロールベースアクセス制御）は、DACの管理の煩雑さと、MACの運用の硬直さを解消するために考案された、現代の企業組織に最も適したモデルです。標準としてはANSI/INCITS 359（NISTモデル）で体系化されています。
RBACの最大の特徴は、ユーザー個人ではなく、職務に基づいた「ロール（役割）」に対して権限を割り当て、ユーザーをそのロールに紐付ける方式です。単なる人の集まりである「グループ」とは異なり、職務（仕事の内容）に基づいて権限を管理する点が特徴です。これにより、人事異動や退職時の設定漏れを防ぎ、「最小特権の原則」を効率的に実現できます。
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さんだけは特別にこのファイルも見たい」）に対応するために新しいロールを作り続けると、ロール数が数百・数千に膨れ上がり、管理不能になるリスクがある。
柔軟性の制約： プロジェクト単位での一時的な権限付与など、組織図に当てはまらない状況に対応しにくい場合がある。
ABAC（属性ベースアクセス制御）：ゼロトラスト時代の動的制御
「属性」の組み合わせで動的に判断する
ABAC（Attribute-Based Access Control：属性ベースアクセス制御）は、ロールも属性の一つとして扱えるため、RBACを包含・拡張できるモデルです。NISTのガイドライン SP 800-162 で定義されています。RBACが「役割」という静的な単位で権限を渡すのに対し、ABACは複数の属性（Attribute）を組み合わせて、アクセス要求のたびに動的に許可・拒否を判断します。
ABACが評価する属性は、大きく3種類に分けられます。
主体（ユーザー）の属性： 役職（部長など）、部署、在籍年数、保有資格。
客体（リソース）の属性： データの機密度レベル、作成日、所有部門、データの分類。
環境の属性： アクセス時刻、接続元ネットワーク、使用デバイスが会社支給か、位置情報。
例えば、「部長ロールで、かつ社内ネットワークから、かつ営業時間内にアクセスした場合のみ、顧客の個人情報を閲覧可能」といったルールを組めます。RBACでは「部長ロールなら常に閲覧可」までしか表現できませんが、ABACは「いつ」「どこから」「どんな端末で」という状況（コンテキスト）まで条件に加えられる点が本質的な違いです。
なぜゼロトラストでABACが主流になるのか
「社内ネットワークだから信頼する」という境界型の前提を捨て、すべてのアクセスをその都度検証するのがゼロトラストの考え方です。この「その都度、状況を評価して判断する」という要求は、まさにABACの動的な属性評価と一致します。そのため、ゼロトラストアーキテクチャの認可エンジンでは、ABAC的なポリシー評価が中核を担います。
ただし、ABACには「ポリシー設計と属性管理が非常に複雑になる」という現実的な弱点があります。誰の・どのデータの・どんな環境の属性を、どう組み合わせて判断するかを設計・維持するのは重い作業です。そのため実務では、まずRBACで役割ベースの土台を作り、そこに環境属性（接続元・時刻・端末状態）の条件を重ねてABAC的に拡張する、という段階的な導入がよく採られます。
4モデルの使い分けと複合運用
ここまでDAC・MAC・RBAC・ABACの4モデルを個別に見てきました。冒頭の比較表で全体像を掴んだうえで、ここでは「実務ではどう組み合わせるのか」という現実的な運用に踏み込みます。単一のモデルだけで完結する現場はむしろ少数派です。
複合的な利用が現実解
実際のシステムでは、これらが組み合わせて使われることがほとんどです。例えば、Windows Serverのファイル共有では、基本的にはRBACの考え方で「Active Directoryのグループ」に対してアクセス権を設定します（技術的にはACLを使うのでDACの仕組みを利用してRBACを擬似的に実現しています）。
その上で、特定の極秘プロジェクトフォルダに関しては、専用の管理ツールでアクセスを厳格に制限する（MAC的な運用）といった具合です。また、個人のホームディレクトリについては、ユーザー自身が管理できるようにDAC的な運用を許可する、という使い分けもよく見られます。さらにクラウドやリモートワーク環境では、これらにABACの環境属性（接続元・時刻・端末状態）を重ねて、条件付きアクセスとして仕上げるのが近年の主流です。
学び始めの人がやりがちなのが、「一番安全そうだからMACで統一しよう」といった極端な設計です。しかしMACを全社適用すれば運用が破綻し、逆に面倒になった現場が「Allow All（全面許可）」に逃げてセキュリティの根本を崩す、という悪循環に陥ります。守るべき情報の性質ごとにモデルを使い分けるのが、実務における正解です。
現場で役立つ記述式対策：シナリオ問題への適用
セキュリティ試験の記述問題や、実際の現場での設計レビューでは、「この状況にはどのモデルを適用すべきか?」という判断力が問われます。典型的なシナリオを見てみましょう。
シナリオ1：人の入れ替わりが激しいコールセンター
課題：
オペレーターの入退社が頻繁で、アカウント作成や権限付与の作業負荷が高い。設定ミスによる情報アクセス権の消し忘れも発生しており、退職者のアカウントが残り続けるというセキュリティリスクも顕在化している。
解法：
RBACを採用する。「オペレーター」というロールを作成し、必要なツール（CRMシステム、FAQ検索、チケット管理など）へのアクセス権を事前にセットしておく。入社時はユーザーをそのロールに追加するだけで、すべての必要なシステムへのアクセス権が一括で付与される。退職時はロールから外すだけで、すべての権限を即座に剥奪できる。
さらに、「オペレーター」「スーパーバイザー」「マネージャー」といった階層化されたロールを作ることで、昇進時の権限変更も容易になります。
シナリオ2：国家機密を扱う研究施設
課題：
研究員が意図せず機密データをUSBメモリに保存したり、メールで外部に送信したりするリスクをシステム的に完全に封じ込めたい。研究員の善意に頼るのではなく、技術的に不可能にしたい。
解法：
MACを採用する。データに「極秘」「秘」「一般」といったラベルを付与し、研究員にもクリアランスレベルを設定する。Bell-LaPadulaモデルの「No Write Down」ルールにより、極秘データを取り扱う研究員は、一般レベルのUSBメモリやメールシステム（外部送信可能）への書き込みがシステムレベルで禁止される。
たとえマルウェアに感染したとしても、ラベルによる制限があるため、機密情報を下位レベル（外部送信可能な媒体・システム）へ書き出す操作はシステムが拒否します。
シナリオ3：部門ごとのファイル共有サーバー
課題：
プロジェクト単位でメンバーが頻繁に入れ替わり、現場の判断で素早く情報の共有範囲を変えたい。管理者が毎回設定変更するのは現実的ではなく、業務スピードが低下している。ただし、完全に野放しにするとセキュリティリスクもある。
解法：
DAC（または、グループ管理権限を委譲したRBAC）を採用する。プロジェクトフォルダの所有者（プロジェクトリーダー）に権限管理を任せることで、業務スピードを優先する。ただし、以下の対策を併用する。
アクセスログを詳細に記録し、定期的に監査する
重要な機密情報は別の厳格な管理下に置く
所有者向けのセキュリティ教育を徹底する
定期的に権限設定をレビューし、不適切な設定を是正する
このように、単一のモデルに固執するのではなく、業務要件とセキュリティ要件のバランスを取りながら、適切な組み合わせを選択することが重要です。
シナリオ4：クラウドサービスのマルチテナント環境
課題：
複数の企業（テナント）が同じクラウド基盤を利用している。各企業のデータは完全に分離する必要があるが、企業内部では柔軟な権限管理も必要。
解法：
MACとRBACの組み合わせを採用する。まず、テナント間の分離はMACで実現する。各テナントのデータに「テナントA」「テナントB」といったカテゴリ（区分）ラベルを付与し、ユーザー側のカテゴリと一致しない限りアクセスを認めない。ラベルは利用者の判断では付け替えられないため、テナントの境界を利用者の判断で越えさせない仕組みになる。
その上で、テナント内部の権限管理はRBACで実現する。各企業は自社のユーザーに対して「管理者」「一般ユーザー」「閲覧のみ」といったロールを割り当て、柔軟に管理できるようにする。さらに、外部からの管理コンソールへのアクセスにはABACの環境属性（接続元IP・多要素認証済みか）を条件として加えることで、テナント越境のリスクをさらに下げられます。
このように、セキュリティの要求レベルが異なる階層に対して、異なるモデルを適用することで、最適なバランスを実現できます。
SC試験での出題パターンと対策
情報処理安全確保支援士（SC）試験では、アクセス制御モデルは科目A-2（旧午前Ⅱ）の定番テーマです。ここでは、どのような形で問われ、どこにひっかけが仕込まれるかを整理します。
科目A-2で狙われる「モデルの区別」
科目A-2では、DAC・MAC・RBACの定義を入れ替えた選択肢から正しいものを選ばせる形で問われます。特に狙われるのが、次の区別です。
MAC＝管理者が定めたラベルとポリシーをシステムが強制し、所有者でも変更できない制御（「所有者が決める」はDACのひっかけ）。
RBAC＝役割単位の権限付与（「個々のユーザーが自由に設定」はDACのひっかけ）。
ABAC＝主体・客体・環境の属性で動的に判断（「役割のみで静的に判断」はRBACのひっかけ）。
また、Bell-LaPadulaモデルは「機密性」を守るモデルで「No Read Up／No Write Down」、Bibaモデルは「完全性」を守るモデルで「No Write Up／No Read Down」という対比が頻出です。特に「No Write Down」がなぜ必要か（機密情報が下位レベルへ流出するのを防ぐため）を説明できると、記述式でも対応できます。
科目Bでの問われ方と定番のひっかけ
科目B（旧午後）では、具体的な業務シナリオを提示し「この要件にはどのモデルが適切か、理由とともに述べよ」という形で問われます。ここでの定番のひっかけは、認証（本人確認）と認可（権限判断）の混同です。「パスワードを強化する」は認証の話であり、アクセス制御モデルの選定とは論点が別だと切り分けましょう。もう一つの罠は、職務分掌（SoD）とロールの階層化の取り違えです。「発注者と承認者を別人にする」がSoD、「部長は課長の権限を継承する」が階層化だと区別してください。
【演習】アクセス制御モデル（DAC/MAC/RBAC/ABAC）理解度チェック（全10問）
アクセス制御モデルは科目A-2で4択の区別問題として、科目Bでは業務シナリオに適したモデルを選ぶ形で問われます。定番のひっかけは「所有者が決める（DAC）／管理者が強制（MAC）／役割で付与（RBAC）／属性で動的判断（ABAC）」の入れ替えと、認証と認可の混同です。以下の練習問題で本記事の理解度を確認してみましょう。
まとめ：守る情報の性質からモデルを選ぶ
アクセス制御モデルは、単なる用語の違いではありません。「組織が情報をどのように扱いたいか」「何を優先して守りたいか」というセキュリティポリシーそのものを反映したものです。
DACは「自由と性善説」のモデル。ユーザーの自律性を信頼し、柔軟な運用を可能にしますが、その分リスクも高まります。MACは「統制と性悪説」のモデル。人間のミスや悪意を前提として、システムが強制的に制御します。RBACは「効率と組織論」のモデル。企業組織の構造と業務の実態を反映し、管理効率とセキュリティのバランスを取ります。そしてABACは「動的なコンテキスト評価」のモデル。ゼロトラスト時代に、属性の組み合わせで状況に応じた判断を下します。
CIOとして情報区分とアクセス権の設計に時間をかけた立場から言えば、「完璧なモデル」は存在しません。どのモデルにも長所と短所があり、組織の規模、業種、扱う情報の機密度、業務の特性によって最適な選択は変わります。だからこそ、冒頭の比較表と選定基準に立ち返り、守るべき資産の性質に合わせてモデルを選択・組み合わせることが、真にセキュアなシステム構築への第一歩になります。
しかし、どんなに完璧なアクセス制御モデルを構築しても、すべてを無に帰してしまう恐ろしいリスクが存在します。それが、システムに対してあらゆる操作が可能な「特権ID（管理者アカウント）」の乗っ取りです。特権IDは、アクセス制御の「神の視点」を持ちます。DACの所有者制限も、MACのラベル制御も、RBACのロール分離も、特権IDでポリシーや設定そのものを書き換えられてしまえば、すべて無効化されかねません。
次回は、攻撃者の最終目標であるこの特権IDをどのように管理し、監視すべきか。一般ユーザーのID管理とは次元の異なる「特権ID管理」の世界について深掘りしていきます。特権IDの棚卸し、パスワードの定期変更、操作ログの監視、特権アクセス管理（PAM）ツールの導入など、具体的な対策手法を解説します。
本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。
参考資料
NIST, "Role-Based Access Control (RBAC)" / ANSI INCITS 359（RBACの標準モデル）: https://csrc.nist.gov/projects/role-based-access-control
NIST SP 800-162, "Guide to Attribute Based Access Control (ABAC) Definition and Considerations": https://csrc.nist.gov/pubs/sp/800/162/upd2/final
NIST SP 800-207, "Zero Trust Architecture"（ゼロトラストにおける認可）: https://csrc.nist.gov/pubs/sp/800/207/final
IPA 情報処理安全確保支援士試験（過去問・シラバス）: https://www.ipa.go.jp/shiken/index.html
テンプレート集
＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。
