Permissions & RBAC

Access Control (permissions management) is a mechanism that governs who can perform what operations on which resources within a system. Without proper access control, wrong users access sensitive data, leading to data breaches and unauthorized operations.

Access Control Models

There are four major access control models used in enterprise systems.

1. DAC (Discretionary Access Control)

DAC lets the owner of a resource freely set access permissions. Linux file permissions (chmod) are a typical example. DAC is flexible but any mistake by the owner directly becomes a security risk.

2. MAC (Mandatory Access Control)

MAC has the system enforce access policies centrally. Resources are labeled with sensitivity levels (e.g., “secret,” “top secret”), and only users with the corresponding clearance can access them. Used in government and military systems.

3. RBAC (Role-Based Access Control)

RBAC assigns roles to users and permissions to roles. It is the most widely adopted model in enterprise environments.

4. ABAC (Attribute-Based Access Control)

ABAC evaluates policies based on attributes of the user, resource, and environment. Fine-grained control such as “department=sales AND region=Tokyo AND time=business hours” is possible, but implementation complexity increases.

RBAC Structure

RBAC is expressed as a four-layer structure: User → Role → Permission → Resource.

graph LR
    U[User: Alice] --> R[Role: admin]
    R --> P1[Permission: read]
    R --> P2[Permission: write]
    R --> P3[Permission: delete]
    P1 --> Res[Resource: customer-data]
    P2 --> Res
    P3 --> Res

Layer	Description	Example
User	An individual person or service account	alice@example.com
Role	A name representing a job function	admin, editor, viewer
Permission	Authorization for a specific operation	read, write, delete, execute
Resource	The data or service being operated on	customer-data, invoices

Principle of Least Privilege

The Principle of Least Privilege is the design principle of granting users and services only the minimum permissions necessary to carry out their work.

Practical examples:

• An accountant who only needs to view data gets read permission only (write is unnecessary)
• A backup script gets read-only access to its target bucket
• A CI pipeline has no write access to the production database

Access Control Model Comparison

Item	DAC	MAC	RBAC	ABAC
Complexity	Low	Medium	Medium	High
Flexibility	High	Low	Medium	High
Auditability	Low	High	High	Medium
Enterprise fit	Low	Medium (special)	High	Medium–High
Typical use	Personal PC, filesystems	Government, military	General enterprise	Finance, healthcare, cloud

Applying RBAC to AI Systems

Access Control for RAG

In a RAG (Retrieval-Augmented Generation) system, RBAC controls which documents a user can search.

• “General employee” role: may search internal policies and FAQs only
• “Sales representative” role: may also search customer records and contracts
• “Executive” role: may also search financial data

Assign an access_level metadata tag to each document and include the user’s role in the search query to filter results.

API Key Scope Management

Set scopes on LLM API access:

Scope	Target users	Permitted operations
inference:read	General users	Inference requests only
inference:admin	Engineering team	Model configuration, log access
billing:read	Executives	Usage and cost visibility

Model Access Tiers

Restricting access to high-cost models (e.g., claude-opus) to specific roles enables cost management and security at the same time.

Role Design Patterns

Flat Roles (Small teams)

admin  → all permissions
editor → read and write
viewer → read only

Function-Based Roles (Medium teams)

sales-manager  → customer data write
sales-rep      → customer data read
engineering    → code repos, infrastructure
hr-admin       → HR data

Hierarchical Roles (Large teams)

Higher-level roles inherit permissions from lower-level roles. For example, senior-engineer inherits all engineer permissions plus production deployment rights.

Common Design Mistakes

• Role explosion: Roles become too granular to manage. Start with generic roles and refine as needed
• Admin role overuse: “Let’s just use admin for now” violates the principle of least privilege
• Overlooking service accounts: Apply least privilege to CI/CD pipelines and background job accounts too
• Insufficient periodic review: Unnecessary permissions linger after transfers or departures

Periodic Permission Auditing

Permissions must not be set and forgotten. Regular reviews are necessary:

• Review unused permissions quarterly
• Establish an immediate deactivation flow for departed employees
• Record last access time and review accounts inactive for 90 days or more

Frequently Asked Questions

Q: How many roles should I have?

Start with 3 to 5 roles (admin, editor, viewer, etc.) and add more as actual business workflows require. Exceeding 50 raises the risk of role explosion. AWS IAM best practices also recommend the minimum number of necessary roles.

Q: How should I handle temporary privilege escalation (e.g., admin tasks)?

Use a pattern called JIT (Just-In-Time) access. Grant permissions only for the time needed and automatically revoke them when the task is complete. AWS IAM Identity Center and Okta support this approach. Always record the reason for escalation and the timestamp in the audit log.

Q: How do I choose between RBAC and ABAC?

RBAC is appropriate for basic access control. Consider ABAC when dynamic policies such as “only during specific hours” or “only from a specific region” are needed. In most cases, a hybrid approach that uses RBAC as a foundation with selective ABAC elements is practical.

See the references for the external specifications and background sources used on this page.[1][2][3]

References

1. NIST RBAC Standard (SP 800-162)
2. AWS IAM Best Practices
3. OWASP Access Control Cheat Sheet