1.5アクセス制御モデル

アクセス制御は「誰が・何に・どこまで触れてよいか」を決める仕組みで、選ぶモデルを誤ると過剰な権限（漏えいの温床）か、逆に業務を止める過小な権限を生みます。この節では、所有者の裁量に任せるDACから、組織が強制するMAC、役割で束ねるRBAC、文脈まで見るABACまでを、要件（機密度・規模・柔軟性・監査）から選び分ける判断として学び、認証・認可・記録をつかさどるAAAの枠組みで締めます。

1.5.1主要な制御モデル

• DAC（任意アクセス制御）＝リソースの所有者が誰に許可するかを裁量で決める（一般的なファイル共有の権限設定が典型）。柔軟だが、所有者が甘く設定すれば権限が過剰になりやすく、組織全体の統制が効きにくい。
• MAC（強制アクセス制御）＝組織が定めたラベル（機密区分/クリアランス）に基づきシステムが強制する。所有者が勝手に許可を広げられず、軍事/政府など高機密環境に向く。柔軟性は低いが統制が固い。
• RBAC（ロールベース）＝ユーザ個々にではなく役割（ロール）に権限を束ね、ユーザをロールに割り当てる。「経理ロール」「人事ロール」のように大規模組織で権限管理を単純化・監査容易化できる。異動時はロールの付け替えで済む。
• ABAC（属性ベース）＝ユーザ属性・リソース属性・環境（時刻・場所・端末・リスク）などの条件を組み合わせて動的に判定する最も柔軟なモデル。「経理部門かつ社内ネットワークから業務時間内なら許可」のようなきめ細かい文脈依存の制御ができる。

1.5.2ルール/時間ベースとAAA

• ルールベース＝管理者が定めた共通のルールを全員に一律適用する（例：ACLで「この送信元からこのポートは拒否」）。時間ベースは許可を時間帯/期間で制御する（例：業務時間外は特定システムへのアクセスを拒否）。両者はABACの条件の一部としても現れる。
• AAA＝認証（Authentication・誰か）→認可（Authorization・何をしてよいか）→アカウンティング（Accounting・何をしたかの記録）の3本柱。アクセス制御モデルは主に認可の意思決定を規定し、AAAはそれを認証と監査記録で挟む運用の枠組み。RADIUS/TACACS+等で実装される。

あなたは病院の情報システムでアクセス制御を設計しています。要件は複雑です：(1) 患者カルテは極めて機密で、担当外の職員が勝手に閲覧を広げられては困る、(2) 数千人の職員がいて異動も多く、個人ごとに権限を設定するのは非現実的、(3) 当直医は夜間の緊急時のみ通常はアクセスできない病棟のデータに触れる必要がある。これを1つのモデルで無理に賄おうとするのが失敗のもとです。まず(2)の規模と異動の多さはRBACが素直で、「医師」「看護師」「医事課」などの役割に権限を束ねれば、異動時はロールの付け替えで済み監査もしやすい。しかし(1)の「担当外が勝手に閲覧を広げられない」という強い統制要件は、所有者裁量のDACでは危うく（現場の判断で共有が広がる）、機密区分をシステムが強制するMAC的な発想＝職員が自分で許可範囲を広げられない仕組みが要ります。そして(3)の「夜間の緊急時のみ」という条件は、役割だけでは表せず、時間ベース（当直時間帯）や、より一般にはABACで「役割=医師 かつ 当直フラグ=真 かつ 時刻=夜間」を組み合わせて動的に許可するのが妥当です。実運用では、RBACを土台にABACの文脈条件を重ねるハイブリッドが現実解になります。最後に、誰がいつどのカルテを開いたかはAAAのアカウンティングで必ず記録し、後からの監査・インシデント調査に備える——医療情報のような規制対象では「認可（見てよいか）」だけでなく「記録（誰が見たか）」が同じくらい重要です。ここでの学びは、要件のキーワードを1つずつモデルに逆引きし、単一モデルに固執せず組み合わせるという設計判断です。

1.5.3この節のまとめ

• DAC＝所有者裁量（過剰権限に注意）、MAC＝ラベルでシステム強制（高機密向き）。要件の機密度と統制の強さで選ぶ
• RBACは役割で束ね大規模/異動を単純化、ABACは属性+環境で動的・きめ細かい。時間ベースは当直等の時間条件に使う
• 単一モデルに固執せずRBAC+ABAC等の組み合わせが現実解。AAA（認証→認可→アカウンティング）で記録まで残し監査に備える