RBAC Role Based Access Control or DRM?
What is role based access control (RBAC) and how effective is it for document control?
A comparison of RBAC, ABAC, ACL, and DRM to help you choose the best document access control method for your organization.
What is RBAC (Role-Based Access Control)?
Role-based access control (RBAC) is an access control system used by millions of businesses to restrict access to computer and network resources. It’s a relatively simple system to grasp: roles are created for various job functions, and those roles are granted certain permissions.
For example, a CEO could be granted an executive role, giving them the authorization to view and edit sensitive information but no critical network access. A network admin role could include system access to a company’s server infrastructure but not sensitive user data or confidential documents. A visitor or intern role would likely only have access to a small set of non-sensitive files, and so on.
In this way, an enterprise can use role-based access control to quickly build out a set of granular permissions without having to worry about managing individual users. If a user changes department, an admin can just assign them a pre-existing role. If an account is compromised, only the resources they have available to them are forfeited.
There are three types of RBAC access control:
- Core RBAC: The core RBAC model provides the foundation for the other modes. There are three core principles that it adheres to:
- Role assignment: Users should only be able to exercise privileges when assigned to roles with those rights. Access is denied by default.
- Role authorization: Users cannot join a rule unless they are authorized to. Ideally, there should be some kind of governance process surrounding this.
- Permission authorization: Changing a role or permission requires authorization from relevant parties.
- Hierarchical RBAC: Introduces a role hierarchy, providing a clear structure for complex organizations, as well as sharing and inheritance between roles.
- Constrained RBAC: Adds either static or dynamic separation of duties:
- Static Separation of Duties (SSD): Users can’t have mutually exclusive roles. For example, be a part of a group that writes a contract and approves it.
- Dynamic Separation of Duties (DSD): Users can be in mutually exclusive roles but can’t perform both roles in a single session. For example, a user may be part of the contract creation and approval roles but won’t be able to approve their own contract.
RBAC sounds like an obvious, natural, and uncomplicated way of doing things, with services such as Azure RBAC simplifying things further. But how good is it at controlling access to documents specifically? This blog will examine the effectiveness of RBAC for document control.
RBAC’s implementation challenges
If you have ever deployed RBAC, you probably spent a lot of time figuring out what roles should be defined and who they should be assigned to. You might have even decided that some users require multiple roles and created a well-thought-out hierarchy to account for that. But as the saying goes, “no plan survives first contact with the enemy”. In this case, your biggest adversary is often your own users.
Though RBAC starts out simple, it tends to balloon into an unwieldy mess. A VP will tell IT that some people in the marketing team need access to PDFs containing usage stats to make an infographic. They’ll also require access to Adobe Illustrator to make the graphic. IT looks at their roles and realizes none match this use case without granting other unnecessary permissions.
So, they make a new role and add those users to it. The next week, it happens again, or dozens of employees need to be onboarded to a new team in a department. Sooner or later, there’s a mess of new roles and old roles that were only supposed to be temporary. Everything is a mess, and there are users everywhere with outdated and excessive permissions.
Ensuring roles are proportional and effective requires regular and in-depth auditing, but due to the vast amount of logs businesses accrue, doing so effectively can be difficult and daunting. On top of this, role-based access is labor-intensive and expensive to implement. After initial setup, there are often unplanned requirements that balloon costs, such as duplication of servers and infrastructure.
In other words, RBAC can aid security, but it isn’t as flexible or scalable as you might think. To maintain security and simplicity, you must be willing to let your admins take a slow and measured approach that may not keep up with the pace of business. Even then, there’s a good chance mistakes will be made.
How secure are RBAC document controls?
When using RBAC for document control, you are naturally dependent on the restrictions you are able to enforce via your document management software and APIs. Some common document management tools that offer RBAC include Google Workspace, Microsoft SharePoint, and Dropbox Business. The security each of these solutions offers is not particularly effective, failing to prevent unauthorized access, editing, copying, and sharing.
As we have mentioned in How Secure Are Google Docs?, the browser’s developer mode is a powerful tool in bypassing the controls enforced by cloud-based document management systems. Users can modify or disable JavaScript and HTML code in their browser to remove watermarks, copy-paste from documents, or print to file drivers.
When it comes to API checks, users are often able to bypass them by modifying URLs, the HTML page, or using a custom API attack tool. Additionally, vulnerabilities in third-party APIs can allow attackers to gain unauthorized access to documents. If authentication methods are implemented incorrectly, attackers can compromise authentication tokens or exploit implementation flaws to temporarily or permanently assume other user’s identities.
What is ABAC (Attribute-Based Access Control)?
Instead of a role-based approach, ABAC focuses on the user and the resource, granting or rejecting access based on a series of attributes. These attributes might include the user’s usual responsibilities, seniority level, security clearance, etc.
ABAC can also consider environmental factors such as the time of day, the user’s location, the location of the resource, and the device being used. This can be used to determine which action attributes are available, such as view, read, write, copy, edit, transfer, delete, and approve. Azure RMS for example, seeks to address this.
The advantage of this approach is that you can control individual users’ level of access and how they can use specific documents based on multiple factors. This is typically more secure than just relying on the user’s assigned role. For example, John from accounting might be able to edit financial statements from the office but only view them when remote.
The downside is that the time required to define these variables and rules is colossal, particularly in the beginning. Additionally, poorly defined rules or implemented controls can create major vulnerabilities/policy conflicts that lead to unauthorized access. Effectively enforcing action attributes across a range of services and applications is still difficult.
What is ACL (Access Control List)?
An access control list (ACL) is a table of rules that tells the operating system which users have access to which resources and what they can do with them. For example, a file with an access control list might contain permissions that allow one user to read and write and another only the ability to read. This kind of control can also be applied to network resources, directories, and databases.
The advantage of ACLs is that admins get control down to the level of the individual user. However, this also means they are not very scalable or dynamic, and the fact that ACLs can be implemented across several different layers (network, filesystem etc.) only exacerbates this.
Traditional ACLs are also ultimately a simple system with a lack of fine-grained controls. File system ACLs rely on basic read/write/execute permissions and are not context-aware regarding access. This doesn’t provide enough granularity for most modern businesses. You need to control not just whether a user can write but specifically which actions they can take and which they can’t.
RBAC vs ABAC
RBAC
RBAC, with its role-centric approach, focuses on assigning permissions based on predefined roles within an organization. This model is relatively simpler to configure and maintain, as it groups users into roles based on their job functions, making it easy to assign and manage permissions. However, RBAC’s simplicity comes at a cost: it can be challenging to maintain security as an organization changes and grows. Increasing numbers of roles can lead to ‘role explosion’, where the number of roles becomes unwieldy and hard to manage effectively. Additionally, RBAC offers limited flexibility as it cannot easily accommodate complex access control scenarios based on dynamic conditions or user attributes.
ABAC
ABAC is often billed as a more secure alternative to RBAC, and it offers more granularity. Its attribute-based approach allows for more precise and adaptable access control policies that can reflect real-world conditions more effectively. For instance, access rights can be dynamically adjusted based on context, such as time of day or location, enhancing security and operational efficiency.
However, in the real world, its effectiveness is determined by the quality of its implementation and maintenance. ABAC’s strengths also make it more complex to set up. A badly implemented or audited ABAC system can lead to security loopholes, and ABAC is hard to audit comprehensively to combat this.
RBAC vs ABAC – which is best?
The choice between RBAC and ABAC is not a simple one. It often comes down to what is feasible for the business and what the requirements are. RBAC is typically better suited to small companies that are organized into small, static teams. ABAC is often a better choice for teams that are geographically distributed, large, or flexible – provided the talent is available to implement and maintain it. Large organizations also commonly combine RBAC and ABAC for greater flexibility.
RBAC vs ACL
The choice between RBAC and ACL usually comes down to the levels of access control you need and how much influence you need over individual resources. RBAC is generally easier to manage, more dynamic, has higher scalability and is generally more secure. However, it is also more broad and less granular. ACL provides control over individual resources and the specific actions users can make. It’s usually used in simple or legacy environments.
Why Choose DRM Over RBAC for authorization & document control? |
Whether you choose ABAC, RBAC, or both, you must be aware that attackers (including malicious internal users) still have various routes to compromise and share sensitive data:
- Attackers can compromise user credentials to gain access to resources, or users can intentionally share this information.
- Users are also vulnerable to password and phishing/spearphishing attacks, as well as session hijacking.
- If using ABAC, there are plenty of ways for attackers to spoof location, IP address, and other attributes to fulfill access conditions
- Services and applications may be vulnerable to forced browsing, API vulnerabilities, URL tampering, SQL injection, XSS, etc.
- Both systems are usually poor at preventing specific actions inside a document (i.e. printing, screenshots, copy-paste). They either just deny read/write access or rely on third-party services such as Google Docs or Microsoft Word, which are insecure.
Due to these weaknesses, organizations that primarily want to prevent the misuse of confidential and sensitive documents should consider a DRM solution. This can be used in tandem with your existing security model or, in situations where the primary goal is document control, a replacement for it.
The benefits of using DRM for document access & control
DRM (Digital Rights Management) offers simple but powerful document controls that deliver much of what organizations are trying to achieve when they implement RBAC or ABAC without the complexity and management overheads. It also provides additional document controls (preventing printing, editing, copying, sharing, etc.) regardless of where documents are located.
Locklizard’s DRM protection starts with the document itself:
- You protect the document in the DRM application and choose the restrictions you want to apply to it (disable printing, screenshot prevention, expiry, etc.).
- The document is encrypted and the DRM controls are applied. Nobody can edit, save, copy, and paste from, or share it.
- You add users in your admin portal and assign them access to documents. Unauthorized users cannot open documents.
- Users can only interact with the document under the restrictions you set earlier. These restrictions are enforced by a secure viewer application and cannot be bypassed or removed. You can even add country and IP restrictions to prevent confidential documents being accessed in unauthorized or unsecure environments.
- Decryption keys are securely transmitted to authorized user’s devices and are locked to the device. There are no passwords to share, and decryption keys cannot be accessed or shared.
- You can expire documents when certain conditions are met or manually revoke users and documents when necessary.
Locklizard Safeguard and Enterprise DRM:
- Is quick and simple to implement
- Easy to automate protection and user access with our command-line tools and API
- Allows secure offline use and distribution
- Provides a streamlined user and management experience
- Offers a variety of pricing models, including yearly, perpetual, and on-premise licenses
Locklizard DRM is not a substitute for having a good information security strategy – it only protects documents in the PDF format, not databases or network access. What it does deliver, however, is invaluable: granular, effective control over how documents are used and who by regardless of their location. All at a reasonable cost and with a high degree of flexibility.
How to use Locklizard DRM to protect your documents
The process to protect a PDF document from unauthorized access and control its use is simple:
- Right-click on the PDF and choose “Make secure PDF”.
- Select the copy protection controls you want to apply. By default, editing, copying, and printing are disabled. We also recommend adding a watermark with user-identifying information to your digital and printed documents. This deters users from taking a picture with their phone or scanning a copy and running it through an OCR recognition tool.
- Press the Publish button to protect the PDF. Your secured PDF will output it as a .pdc file in the same folder as the original PDF.
- Add a user account and send them their license via the Safeguard admin portal. See how to add a new user and grant them document access.
- The Safeguard Viewer enforces your DRM restrictions and nobody will be able to edit your protected PDF files.
Start a 15-day free trial of our PDF DRM software to see how it can replace RBAC in your organization for controlling access to and use of confidential and sensitive documents. Get complete control over how internal users and third parties can access and use your documents.
FAQs
How does access control protect data?
Access control protects data by ensuring only authorized users can access specific resources (devices, information, etc.). DRM extends access controls by providing persistent controls that enforce permissions regardless of where resources are located.
What is an RBAC rule?
There are several best practices that RBAC systems adhere to:
- Role assignment: Users should only be able to exercise privileges when assigned to roles with those rights. Access is denied by default.
- Role authorization: Users cannot join a rule unless they are authorized to. Ideally, there should be some kind of governance process surrounding this.
- Permission authorization: Changing a role or permission requires authorization from relevant parties.
How does RBAC work?
An admin assigns the roles of individual users. Each role is associated with specific permissions that define access to resources within a system. When a user is assigned a role, they inherit the permissions linked to that role, thereby streamlining the process of managing user permissions.
What is an example of RBAC permissions?
For example, in a corporate setting, a “Manager” role group may be granted permissions to approve budget requests, access employee performance reports, and modify schedules, while an “Employee” role is limited to viewing schedules and submitting time-off requests.
What is an RBAC role?
An RBAC role is a collection of permissions that represents a set of actions and responsibilities within an organization. It acts as a template for access rights, and users assigned to a role receive all the permissions that the role embodies. Roles are typically aligned with job functions, like ‘Administrator’, ‘Manager’, or ‘Clerk’, simplifying the management of user privileges.
What is Zero Trust and how does it relate to RBAC and DRM?
Zero Trust is a security approach that involves the belief that organizations should not blindly trust any device, system, or user, whether inside or outside their network perimeter. Instead, they must verify and authenticate every attempt to connect to their systems before granting access. This approach differs from Role-Based Access Control (RBAC), which grants access based on predefined roles within an organization.
How does Identity Access Management (IAM) work with RBAC?
Identity Access Management (IAM) is an approach to managing digital identities and controlling user access to resources within an organization. IAM systems typically use Role-Based Access Control (RBAC) principles, which involve assigning users to specific roles based on their job functions and granting permissions accordingly. This integration helps simplify access management and helps to ensure that users have the appropriate level of access based on their roles.
What is a discretionary access control (DAC) system?
Like any security solution, it depends on what you are trying to control. DAC is an access control model where a user’s access to a resource is determined by its owner (it is at their discretion). It often goes hand-in-hand with an ACL. Typically, DAC uses authentication such as usernames and password access, which are vulnerable to attack. DAC is also vulnerable to trojans, malicious internal users, and more.