Modal Title
Security

Implement Fine-Grained Security, or Get Left Behind

Authorization has to happen close to the application, because it’s in the critical path of every application request. But fine-grained security requires real-time access to user attributes and resource relationships.
Sep 6th, 2022 10:00am by
Featued image for: Implement Fine-Grained Security, or Get Left Behind
Feature image via Pixabay.

The biggest shift in security over the last decade has been from perimeter-based approaches to zero trust. Multicloud and remote work have accelerated this trend. But what people don’t talk about is how zero trust requires a similar shift from coarse-grained to fine-grained security. 

Coarse-Grained Security Is Old School

Coarse-grained security deals with networks, users and applications. If you’re on a corporate network, you have network access to everything on that network. If you’re authenticated as a user, you have login access to a particular set of applications. And if you can log in to an application, you have role-based access depending on the roles or groups you’re part of. 

Security logs and observability are likewise coarse-grained. Traditional firewalls, identity providers and applications tell you who logged in and when, but often don’t capture any application-specific data beyond that.

Fine-Grained Security Is What’s Next

A zero-trust mindset requires a shift to fine-grained security. Here are a few elements of a fine-grained, zero-trust approach to application security.

Policy-Based Access That Defaults to ‘Deny’

For organizations to get a handle on access control, the authorization logic needs to be lifted out of applications and described in an authorization policy. These policies should default to denying access, and only allow access when a user, workload or device passes authorization criteria.

Decoupling the authorization policy from the application code allows security teams to own the life cycle of that policy and evolve it in a safe and predictable way. Treating policy as code and storing it in a source code repository provides a full audit trail for policy evolution. Building policy code into immutable, signed images allows security teams to deploy trusted versions and roll back to previously known good images, enabling a secure software supply chain for authorization policies.

Enforcing the Principle of Least Privilege

Omri Gazitt
Omri is the co-founder/CEO of Aserto, an authorization startup and his third entrepreneurial venture. He's spent the majority of his 30-year career working on developer and infrastructure technology, most recently as the CPO of Puppet. Previously, he was the VP and GM of HP's cloud native platform (with business, product and engineering oversight for OpenStack, Cloud Foundry, CloudSystem products and services), and a general manager at Microsoft with responsibilities for Azure, SQL Server, Application Server and the .NET Framework.

Applications that define coarse-grained roles make it really hard for application administrators to give users just enough access, but no more than is strictly necessary. Moving to a fine-grained access control model involves one or more of the following techniques: 

Defining Fine-Grained Permissions as the Basis for Access Control

Applications should have permission checks before every access to a protected resource. But instead of checking whether a user is in a role, an application should check whether the user has a discrete permission. This way, the mapping between roles and permissions can be done outside of the application. This enables easily assigning new permissions to existing roles, creating new roles based on customer requirements and even allowing customers to define custom roles that aggregate a set of application permissions.

Disentangling ‘Roles’ and ‘Groups’

A role is a collection of permissions, and a group is a set of users. Yet most applications conflate the two. Modern authorization systems enable the creation of groups which aggregate users, and then allow an administrator to assign these groups into roles. This way, an application administrator can control how they group their users and have a single place to manage the mapping of roles (and transitively permissions) to those groups of users.

Fine-Grained Access Control over Application Resources

Applications have a resource hierarchy, also known as a domain model. For multitenant SaaS applications, “tenants” are at the top of this resource hierarchy. For these applications, the simplest authorization policy ensures that users who have a relationship with a particular tenant (e.g., viewers, admins) should only have access to resources scoped within that tenant. 

Most applications further organize their tenant-scoped resources into a hierarchy: teams, projects, lists, folders and even individual items. Ultimately, customers want fine-grained access control for each layer in the hierarchy. This type of access control is increasingly known as “Relationship-based Access Control” or ReBAC. 

ReBAC adopts RBAC’s concept of roles (aka “relations”) as a mechanism to aggregate a set of permissions but provides the ability to create relations between subjects (users/groups) and objects at any level of the resource hierarchy, which results in much finer-grained access than traditional RBAC.

Utilizing Attributes in Addition to (or in Place of) Group Membership 

Modern applications often want to make access decisions based on dynamic user attributes, such as what department the user belongs to, or whether they are a manager. When the user moves to a different department, the application still evaluates permissions correctly without the admin having to manually deprovision and provision the user into a new group. This pattern is an instance of “Attribute-based Access Control” or ABAC.

Organization-Aware Access Decisions

Management relationships are inherent in every organizational structure. Many applications want to enable managers to perform actions on their reports, which requires an understanding of a very specific type of user attribute which describes management relationships. 

For example, instead of creating a group that contains all of an executive’s department and having to manage it explicitly, an access control policy can be constructed that walks the organizational graph and determines whether a user is in that executive’s organization.

Environment-Based Attributes

Some applications need to behave differently based on where a user is logged in from, what region the application is running in or the day/time an operation is invoked. This is often due to regional differences in service levels or compliance requirements (such as GDPR). Access control policies should make it possible to combine environment-based attributes with other fine-grained access control techniques.

Fine-Grained Security Logging and Events

A sizable portion of the security industry focuses on capturing and processing security events in product categories such as security information and event management (SIEM), and security orchestration, automation and response (SOAR). 

Here, too, the coarse-grained security mindset of the past is giving way to the fine-grained security approach. Rather than merely recording logins, we need decision logs for every access check that an application makes over the course of a user’s session. This helps find and fix over-provisioned or misconfigured permissions much more effectively.

Getting There

This transformation has to start with applications. Developers need an easy way to incorporate fine-grained security into their applications. This requires lifting all of the authorization logic out of the application and delegating authorization calls to a service that makes authorization decisions based on an externalized policy. 

This fine-grained security service needs to reason about user, resource and environmental attributes. It also needs to collect and forward all of the decision logs that the application generates to a central system.

Build It

For organizations that have the right levels of resources and expertise, there are some open source building blocks that can be helpful in creating a custom fine-grained security service:

  • The Open Policy Agent is a general-purpose decision engine that can be used to make ABAC-style authorization decisions based on user and resource attributes.
  • The Google Zanzibar paper has given rise to multiple open source projects for storing and evaluating user permissions over a ReBAC object graph.
  • The Beats log shippers and lumberjack protocol make it possible to ship and aggregate decision logs. 

With that said, building a solution based on these components isn’t trivial, and most of them don’t include an end-to-end solution that covers attribute-based access control (ABAC), relationship-based access control (ReBAC), org-based access control and log aggregation that provides guaranteed ordering and delivery. In other words, even with the help of open source projects, there’s still a lot to build. 

Deploy It

Authorization has to happen close to the application because it’s in the critical path of every application request. But fine-grained security requires real-time access to user attributes and resource relationships. Getting those attributes to the application without incurring a costly network call in the critical path of the application request is a distributed systems problem and is the hardest challenge to address when building a custom solution.

The same is true for authorization policy: The whole point behind extracting access control code out of an application and into an authorization policy is that you want to manage that policy centrally but have it available right next to the application. Building an automated policy-as-code workflow from source commit to policy distribution is also far from trivial.

Manage It

Authorization has to be done locally, but management has to be done centrally in order to operate successfully. All of those local authorizers need to be managed by a control plane, which is the central control point for user data, relationship/resource data, policies and decision logs. This way, security and operations teams have one place to manage all the artifacts across the set of applications and microservices that they are responsible for.

Once again, creating a control plane for fine-grained security takes considerable effort. Companies like Google, Netflix, Airbnb and Intuit have done it, but they have teams dedicated to running those services.

Fine-Grained Security Platforms

For organizations that don’t want to invest the time and effort to build it all themselves, there are alternatives. What should you look for in a fine-grained security platform?

  • OPA-based authorization for ABAC-style policies.
  • ReBAC directory for fine-grained user, group, and resource hierarchy relationships.
  • Modeling of management relationships in the directory.
  • Built-in integrations to systems of record for identity and directory data.
  • Fine-grained decision log capture and aggregation.
  • Distributed architecture for authorizing locally and managing centrally.

Aserto

Aserto is the fine-grained security platform for developers. It offers a complete end-to-end solution that makes it easy for developers to incorporate into applications, and for security and operations teams to manage at scale. Create a free account today!

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.