Skip to main content

Access Control Model for Regulated Documents

Use RBAC as the backbone, with classification- and attribute-based constraints. Many regulated organizations approach MAC-like behavior for high-sensitivity content.

Base Model: RBAC + ABAC Hybrid​

RBAC (Role-Based Access Control)​

Roles mapped to permission sets over document types and classifications.

RolePermissions
cliniciandoc.read, doc.view_phi (facility-scoped)
billingdoc.read (billing docs only)
traderdoc.read, doc.write (desk-scoped)
compliance_officerdoc.read, doc.approve, doc.audit
records_managerdoc.read, doc.archive, doc.destroy
adminAll permissions

ABAC (Attribute-Based Access Control)​

Attributes from metadata (document) and user profile refine decisions.

Document Attributes:

  • jurisdiction
  • business_unit
  • classification
  • contains_phi
  • contains_financial

User Attributes:

  • location
  • org_unit
  • clearance_level
  • certifications

Classification-Aware Rules​

PHI Documents​

  • Readable only by roles with phi_access = true
  • Must be within same facility/jurisdiction
  • Access logged for HIPAA audit

Trading Procedures​

  • Limited to specific desks
  • Plus compliance and audit roles
  • Requires trading_desk attribute match

Confidential Documents​

  • Requires security_clearance >= confidential
  • Manager approval for external sharing

Example Policy Rules​

# PHI Access Rule
allow(user, "doc.read", doc) if:
  user.roles contains "clinician" AND
  user.permissions contains "doc.view_phi" AND
  doc.contains_phi == true AND
  user.facility == doc.facility

# Trading Desk Rule
allow(user, "doc.read", doc) if:
  user.roles contains "trader" AND
  doc.domain == "trading" AND
  user.desk in doc.allowed_desks

# Compliance Override
allow(user, "doc.read", doc) if:
  user.roles contains "compliance_officer"

Least Privilege and Segregation of Duties​

Least Privilege​

  • Enforce at role definition
  • Regularly review role-permission mappings
  • Remove unused permissions

Segregation of Duties​

  • Author cannot finally approve own policy
  • Different reviewers at each stage
  • Dual control for destruction

Implementation Pattern​

Central Policy Engine​

Use OPA, Cedar, or custom PDP:

allow(user, action, doc) → boolean

Components​

ComponentDescription
Policy Decision Point (PDP)Evaluates access requests
Policy Information Point (PIP)Provides user/resource attributes
Policy Enforcement Point (PEP)Enforces PDP decisions
Policy Administration Point (PAP)Manages policy rules

Example Flow​

  1. User requests access to document
  2. PEP intercepts request
  3. PIP loads user roles + attributes from DB
  4. PIP loads document metadata from DB
  5. PDP evaluates policy
  6. PEP enforces allow/deny
  7. Audit log records decision

High-Sensitivity Content (MAC-like)​

For highly sensitive subsets (special PHI, financial records):

  • System-enforced clearances
  • Non-bypassable rules
  • Layered on top of RBAC

References​