認可モデル：RBAC、MAC、DAC

アクセス制御モデルは、どの主体（ユーザー、プロセス）がどのオブジェクト（ファイル、システム、データ）にアクセスできるかを定めるルールとポリシーです。選択したモデルによって、アクセスを許可できる人物、権限の割り当て方法、適用の仕組みが決まります。Security+試験では、主に4つのモデルを扱います。任意アクセス制御（DAC）、強制アクセス制御（MAC）、ロールベースアクセス制御（RBAC）、ルールベースアクセス制御です。それぞれの強みと適切な利用場面を理解することは、効果的な認可システムを設計するうえで不可欠です。

任意アクセス制御（DAC）では、リソースの所有者が、そのリソースにアクセスできる人物を決定し、他のユーザーにアクセスを許可したり取り消したりできます。「任意」とは、所有者が決定するという意味です。システムは所有者の決定を適用しますが、決定内容を指示することはありません。これは、一般的な個人向けコンピューティング環境（Windows NTFSのファイルアクセス許可、Linux/Unixのファイルアクセス許可）で使われているモデルです。DACのセキュリティ上の制約は、すべてのリソース所有者が正しくアクセスを判断する必要があることです。ファイルへのアクセス権を受け取ったユーザーは、管理者の関与なしに他のユーザーへその権限を付与できるため、機密データが意図した範囲を超えて拡散する可能性があります。

DACには、固有のセキュリティリスクが2つあります。推移的アクセスでは、ユーザーAがユーザーBにアクセスを許可し、ユーザーBがユーザーCにアクセスを許可します。その結果、元の所有者は、ユーザーCが自分のリソースにアクセスできることさえ把握していない可能性があります。混乱した代理人問題とは、権限の低いユーザーの代わりに動作する特権プログラムが、そのユーザーには直接実行できない方法で、意図せず自らの権限を使用してしまう問題です。DAC環境では、1つのアカウントが侵害されると、そのユーザーに付与されたすべてのリソースへアクセスされる可能性があり、侵害が検知される前に他のユーザーへアクセス権を付与されることもあります。DACは便利である一方、情報を厳格に封じ込めるうえで課題になります。

強制アクセス制御（MAC）では、オペレーティングシステムが、主体（ユーザー）とオブジェクト（データ）の両方に割り当てられたセキュリティラベルに基づいてアクセス制御ポリシーを適用します。ユーザーがポリシーを上書きしたり変更したりすることはできず、変更できるのはシステム管理者またはセキュリティポリシーだけです。MACは、データを厳密に区画化する必要がある政府や軍の機密環境で使用されます。「Secret」のクリアランスを持つユーザーは、データ所有者がアクセスを許可したいと考えていても、「Top Secret」とラベル付けされたデータにはアクセスできません。Bell-LaPadulaモデル（上位の読み取り禁止、下位への書き込み禁止）とBibaモデル（上位への書き込み禁止、下位の読み取り禁止）は、MACを形式化した実装です。

2つの形式的なMACモデルは、セキュリティ目標を数学的なルールとして表します。Bell-LaPadulaは機密性に重点を置きます。主体は自分の分類レベルより上位のデータを読み取ることができず（上位の読み取り禁止）、下位の分類レベルへデータを書き込むこともできません（下位への書き込み禁止）。これにより、機密情報が権限のないユーザーへ流出するのを防ぎます。Bibaは完全性に重点を置きます。主体は、より高い完全性レベルへ書き込むことができず（上位への書き込み禁止）、より低い完全性レベルから読み取ることもできません（下位の読み取り禁止）。Bibaは、完全性の低い入力によって完全性の高いデータが汚染されるのを防ぎます。SELinuxなどの実際のMACシステムは、両モデルの要素を組み合わせています。

ロールベースアクセス制御（RBAC）では、個々のユーザーに直接権限を割り当てるのではなく、ロールに権限を割り当て、その後ユーザーをロールに割り当てます。これにより、大規模環境で個別の権限を割り当てる管理上の課題を解決できます。企業環境で一般的なロールには、admin、auditor、developer、HR_manager、finance_analystがあります。新しい従業員が入社したら、適切なロールに追加するだけで、そのロールに必要なすべての権限を直ちに継承できます。従業員が異動した場合はロールを変更すれば、権限も自動的に調整されます。RBACは、企業のIAMシステムで主流となっているモデルです。

RBACの主な利点は管理上の拡張性です。ロールの権限を変更すると、そのロールに属するすべてのユーザーに直ちに反映されるため、何百ものシステムにわたって個々のユーザーレコードを更新する必要がありません。RBACは、1つのロールに競合する権限を持たせないことで、自然に職務分掌をサポートします（たとえば、金融取引の作成と承認の両方を実行できるロールを作らないようにします）。また、監査担当者は何千もの個別ユーザーへの割り当てを監査するのではなく、ロールとその権限を確認すればよいため、コンプライアンス対応も簡素化されます。制約は、ロールの増殖です。組織が細かすぎるロールを作りすぎると、管理が複雑になり、拡張性という利点が損なわれることがあります。

ルールベースアクセス制御（RBACと混同しないでください）は、IDやロールだけではなく、一連の条件付きルールに基づいてアクセスを許可または拒否します。ファイアウォールルールが典型的な例です。「192.168.1.0/24から任意の宛先のポート443へのTCPを許可し、それ以外のすべてのトラフィックを拒否する」といったルールです。アクセスはルールと順番に照合され、一致するルールが見つかるまで評価されます。ルールベース制御は、他のモデルと組み合わせて使われることが一般的です。MACはセキュリティラベルをルールとして使用し、属性ベースアクセス制御（ABAC）はルールベースのロジックを拡張して、複数の属性（ユーザーの部署、デバイスの種類、時刻、リソースの分類）を同時に評価し、きめ細かな判断を行います。

ABAC（属性ベースアクセス制御）は、最も柔軟で細粒度なアクセス制御モデルです。アクセスの判断では、複数の属性を同時に評価します。主体の属性（ユーザーの部署、クリアランスレベル、場所）、オブジェクトの属性（データの分類、所有者の部署、保持ラベル）、環境属性（時刻、デバイスの種類、ネットワークの場所）、アクション属性（読み取り、書き込み、削除）などです。ポリシーには、「user.department = Finance AND resource.classification = Internal AND device.type = corporate AND time.hour BETWEEN 8 AND 18の場合にアクセスを許可する」と記述できます。ABACによってゼロトラストのポリシー判断が可能になり、XACMLやクラウドIAMのポリシーエンジンなどの製品で実装されています。

適切なアクセス制御モデルは、セキュリティ要件と組織の状況によって異なります。DACは、厳格な制御より利便性を優先する個人向けコンピューティングや小規模チームに適しています。MACは、情報を厳密に区画化する必要がある政府や軍の機密環境で必要です。RBACは、管理上の拡張性が重要で、ロールと職務機能を明確に対応付けられる企業に適しています。ABACは、コンテキストを認識した細粒度のポリシーが必要なクラウド環境やゼロトラストアーキテクチャに適しています。実際には、多くの組織が複数のモデルを組み合わせ、RBACを基盤とし、コンテキストに応じたアクセス判断にABACを使用しています。

アクセス制御モデルにかかわらず、アクセス制御リスト（ACL）は最も一般的な技術的実装メカニズムです。リソースに付加されたACLによって、どのサブジェクトがどのアクションを実行できるかを指定します。ファイルシステムACL（Windows NTFS、Linux POSIX ACL）は、ファイルやディレクトリへのアクセスを制御します。ネットワークACLは、ルーターまたはクラウドネットワークのレベルでトラフィックの流れを制御します。データベースACLは、テーブルおよび行レベルのアクセスを制御します。ACLは、ここまでに説明したどのモデルも実装できます。たとえば、所有者が制御するファイルのACLはDACを実装し、ラベルによってエントリが決まるセキュリティシステムのACLはMACを実装し、エントリがロールを参照するアプリケーションのACLはRBACを実装します。

このレッスンで扱ったCompTIA Security+（SY0-701）の概念について、理解度を確認しましょう。

このレッスンでは、次のことを学びました。DACではリソース所有者がアクセスを制御します（柔軟ですがリスクがあります）。MACではシステムが適用するセキュリティラベルを使用します（厳格で、機密環境で使用されます）。RBACでは権限をロールに割り当て、エンタープライズ環境での拡張性を確保します。ABACでは複数の属性を評価し、きめ細かなゼロトラストの判断を行います。次は、フェデレーションID：SAML、OAuth、OpenID Connectについて説明します。