Kenta Takeuchi

Posted on Mar 15 • Originally published at bmf-tech.com

Exploring Permission Management Design

#abac #acl #rbac #permissionmanagement

This article was originally published on bmf-tech.com.

Overview

I researched case studies on permission management design and took notes.

Research Notes

I organized the information I researched, but there are still things I don't fully understand, so it's not completely organized.

Elements Composing Permissions

Permissions seem to be composed of the following elements:

Who (Principal)
What (Resource)
What actions (Action) are allowed (ALLOW) or not allowed (DENY)

Permission Design Methods

The following methods are generally considered for design:

ACL (Access Control List)
- Set permissions for each user
- Permissions are managed in a list
RBAC (Role Based Access Control)
- Assign roles to users and assign permissions to roles
ABAC (Attribute Based Access Control)
- Set permissions based on attributes of users, resources, environments, etc.

The flexibility of permissions and the complexity of implementation are ACL < RBAC < ABAC.

Perspectives on Permission Design

The following perspectives seem relevant for permission design:

Scope of Permission Application
- How far do permissions apply?
- Functional scope
- Can target a single function or a specific group of functions
- ex. Whether the user information retrieval API can be used
- Data scope
- The most primitive scope of permission application
- ex. Viewing permissions for user information → Can see name and age but not address
- Sometimes both need to be considered, while other times only one is sufficient, but flexible design is required
Control Targets of Permissions
- On what basis are permissions applied?
- Content
  - Apply permissions to specific functions, data, etc.
- Context
  - Apply permissions based on whether specific conditions are met
  - ex. Only users with a transaction amount of 1 million yen or more can access
  - Is it even a target managed as a permission? If managed as a permission, how is the state managed?
- Time
  - Apply permissions only during specific time periods
  - ex. Accessible only on weekdays
  - Access permissions are also within the scope of permissions
Constraints of Permissions
- Constraints such as priority of permissions and dependencies between permissions
- Conflicting permissions
- If a user has permissions to view only specific data but also has permissions to view all data, which takes precedence?
- How to express the relationship of conflicting permissions?
  - Considerations for implementation include evaluating manually when adding new permissions, defining priorities based on attributes or roles, or using a set-theoretic approach
  - May need to consider from the perspective of user experience and security (principle of least privilege)
Layers of Permission Application
- Which layer of the system is permission applied to?
- Application, database, network, OS, etc.
- From where is permission application necessary?
- The layer seems to be determined by the functional and data scope settings
Handling of Administrator Permissions
- How to set administrator permissions
- Administrator permissions pose a security risk
- Need to consider risk management perspectives such as the principle of least privilege, separation of duties, audit logs, and emergency operations
Operational Flow of Permission Management
- Need to consider an operational flow for proper permission management
- Principle of least privilege
- Grant only the minimum necessary permissions
- Regular audits and reviews
- Regularly check permission settings and remove unnecessary permissions
- Centralized management
  - Provide an interface that makes it easy to understand the types of permissions and their application status
  - Consistent permission application flow
  - If permission management is uniquely implemented in each system, consistency is likely to be disrupted (I think)
  - Separation of permissions
  - Flexible permission settings should be possible
  - The control target of a single permission should not be too broad

Required System Characteristics

Considered the system characteristics required for a system that manages permissions.

Extensibility
- Can add permissions with any flexibility
Scalability
- A highly flexible permission design is likely to increase system complexity and data volume
- Consider capacity when users and permissions increase linearly
Reliability
- Ensure that adding or changing permissions does not adversely affect existing permissions
Security
- Adhere to the principle of least privilege, minimize blast radius, and prepare emergency operations for failures

Impressions

Although it's a general impression as it depends on the industry and business domain of the service, I think permission management is particularly demanded in B2B services.

It seems like there isn't a well-established body of information or best practices.

It seems like a field where you could write a whole book, but there don't seem to be many related books.

I feel like I've identified the perspectives to consider, but the particularly challenging part seems to be how much flexibility to allow in permissions. I thought it would be necessary to expand the design while considering future business requirements to some extent.

DEV Community