You might think it’s unimportant, and you may not understand how it’s done, but your IT organisation spends a lot of time thinking about who can see and do what. This is important because it costs your IT a lot of time and money. There are opportunities to make your organisation much more efficient, and most organisations have some sort of legal requirement to manage privacy and confidentiality. If you are in health or finance, you will also have a raft of regulatory compliance concerning sensitive data. In short, this probably matters more than you think, and it needs to be done well.
What’s (probably) happening now
Most organisations use Role-Based Access Control. This restricts access to the network, its systems and data according to a user’s job role. For example, lower-level employees usually do not have access to any sensitive data that they don’t need to see in order to do their jobs. It can work well if people fit nearly into distinct roles, such as a call-centre operative, accounting clerk, or lawyer, and where all the people in a given role can see the same information and do the same things. But how often is this actually the case? Do different lawyers need access to different clients, for example? If they do, you’ll need to create more roles to accommodate this, and update your security policies to show what this new role can see. Over time, not only does this generate more and more roles, but administrators struggle to keep on top of organisational changes such as projects ending or people moving roles. You’ll also find that your security policy administrators have to understand what each role means to the business and how then to update the policies affecting that role so that staff can do their jobs. The more dynamic your organisation is in terms of shifting projects and roles, the more time you spend maintaining your security model. It’s an approach that is both inflexible, and hard to scale as your organisation grows.
Understanding Attribute-Based Access Control
In Attribute Based Access Control (ABAC), you can create fine-grained permissions based on user attributes such as department, job role, team name or project. Rather than grouping people into job functions, you therefore describe each person in terms of a combination of characteristics. We similarly tag resources (and services) and then security policies enforce the value of those tags against the user’s attributes. Whilst you still have many attributes and tags, the latter will often be set only once (e.g. a project folder), but, far more importantly, it makes the security policies much easier to manage. Administrators can talk directly to the teams about which projects, groups of resources, or services they need without having to model the entire organisation as a whole. The reduction in complexity represents a significant saving in time and cost. This saving increases for larger organisations or those that experience lots of change.
The following diagrams illustrate the difference between the two approaches. In RBAC, users are grouped into roles. These roles have permissions – i.e. which resources they can see and which services they can use. An employee is usually (and for AWS always) assigned to a single role; however, the administrator must not only manage who is in which role, but also the resources and services assigned to each role. In ABAC, the users and resources have tags attached to them. For the user, this could be their role, project, security clearance: whatever usefully describes their relationship with the organisation. The resources (and services) are similarly tagged: perhaps considering the sensitivity of the information. We can also use environmental factors, such as the current threat level or geographical location of the resource. The security policy then decides whether or not the user can see it based on these tags. Changing the threat level or upgrading the security clearance of a particular user does not affect the policy, only the individual tags. This makes the system more flexible – as tagging is specific and local – but also easier to manage with respect to the security policy. It’s no longer necessary to update existing policies to allow new users to access resources.
Role-based access control
Attribute-Based Access Control
Which benefits you can expect from ABAC
Better Control
Whether or not you are in a regulated industry, ABAC should give you better control over security: it’s finer grained (ensuring people see only what they need to), user-centric (as we tie permission to specific user attributes, such as roles, responsibilities, department affiliations, or geographical location), and, because it’s easier to administer, it’s less likely to go wrong.
Flexibility and contextual decision-making
ABAC is particularly adaptable because it is able to integrate and use diverse attributes reflecting not only the user, but the resource and the context. For example, you might wish to restrict access to sensitive data based on the time of day, geographical location, or specific involvement in a project. Remember that your organisation not only changes as people shift roles, but also in response to environmental conditions. Having a security model that allows you to adapt to these conditions means you don’t have to anticipate every possible scenario when designing your security policies.
Compliance and privacy protection
In addition to being flexible – which helps you keep in step with changes to the compliance rules – it also helps you to be transparent about how this is achieved. This might include demonstrating how you enforce access restrictions based on data classification, user clearance levels, or specific compliance regulations. The approach minimises the likelihood of data breaches or privacy infringements by strictly regulating data exposure, aligning with regulatory mandates, and safeguarding sensitive information from unauthorised access.
Reduced Administrative Overhead
Managing access rights in traditional models like RBAC can become cumbersome, especially in large organisations with complex structures. ABAC simplifies this by automating access decisions based on attributes, reducing the need for manual intervention and extensive role management. This leads to lower administrative costs and more efficient access management.
Implementing ABAC: Best Practices
To effectively implement ABAC, businesses should follow these best practices:
- Identify Key Attributes: Determine the critical attributes that will define access policies. These could include user roles, departments, security clearance levels, and contextual factors like time and location.
- Define Clear Policies: Develop comprehensive access control policies that specify how attributes will be evaluated to grant or deny access. Ensure these policies are aligned with business objectives and regulatory requirements.
- Leverage Technology: Utilise advanced ABAC solutions that offer robust policy management, real-time decision-making, and integration with existing IT infrastructure. These solutions should provide user-friendly interfaces for defining and managing policies.
- Continuous Monitoring and Updating: Regularly review and update access policies to reflect changes in the organisational structure, emerging threats, and evolving business needs. Continuous monitoring ensures that the ABAC system remains effective and responsive.
- Educate and Train Staff: Ensure that employees understand the importance of access control and how ABAC works. Regular training sessions can help staff comply with access policies and recognize potential security risks.
Conclusion
Adopting Attribute-Based Access Control (ABAC) offers businesses a powerful tool to enhance security, improve compliance, and streamline access management. By leveraging the flexibility and dynamic nature of ABAC, organisations can protect their assets more effectively and adapt to changing security landscapes. As businesses continue to navigate the complexities of the digital world, ABAC provides a robust framework to safeguard sensitive information and maintain operational integrity.
By Alistair Park, CCO at Estafet
Want to learn more about how to move to ABAC?
Check out our guide: Implementing Attribute Based Access Control (ABAC) with AWS Transfer Family SFTP Servers and don’t miss the episode “I Can’t Unsee That: When Role-Based Access Exposes Too Much“
Ready to discuss your move? Let’s talk about how ABAC can enhance your security. Contact us today!
