Why granular, scalable control is a must for every CTO

Whilst it is never at the top of the list of areas to tackle, an inevitable topic that creeps up is how to handle user permissions and authorization across applications or services being developed and maintained. This is the core security logic for your application which typically starts off as a simple check of whether a user has a particular role - role-based access control (RBAC) - but can quickly turn into spaghetti code as requirements land from customers, regulators, and internal teams needing more fine-grained access.

How quickly you may tackle this will vary by architecture, target industry and types of users served, so it is worth having an idea of an ideal end state even if it is not going to be tackled now.

Architectural drivers

With microservices architecture dominating application design - though modular monoliths are coming up fast - having authorization logic embedded in the application code is an issue as every time the requirements change, the implementation needs updating across every service. This is a technical debt that needs to be paid off at some point in the lifespan of the application.

Regulatory drivers

Banking, healthcare, and public sector systems are rightfully the most regulated industries and have strict requirements around access controls - both defining the policies and recording the audit trail of activities - which must be met to operate in the market. Applications in these sectors will need to have demonstrable implementations of the access controls and will likely be audited on the topic.

"For the business owner, they now can control the amount of responsibility they want to give to external accountants, which is incredibly powerful for us and incredibly powerful for the accountants. We have a payroll product, we obviously don't want everyone in the business to see what their payroll is, so we restrict access to that. Including, we have a bank transaction feed, so we limit it. While some people can see the bank transaction feed, they can't necessarily see the payroll numbers." - Henry Arnold, CTO & Co-Founder @ Nook. Cerbos user.

Outside of these verticals, gaining a compliance certification such as ISO27001 and SOC2 is beneficial from a customer trust and winning enterprise deals perspective. These come with similar requirements for access controls so designing for this ahead of time is a worthwhile exercise.

Internal drivers

As a business grows there are key inflection points when access controls need to have some thought put into them. In the early days when the user base and company size are small, having users and admins as your two groups is a simple starting point, but as the company grows or the size of the companies using your application grows, this is far too coarse and additional roles and fine-grained permissions checks need to be implemented. This could be due to having disparate teams in different locations who need a locked-down view across an app, or the product packaging has evolved and access needs to be granted based on what the end customer has bought. Having a flexible access control model is going to save time in the long term.

The transition to fine-grained authorization

The tipping point will eventually arrive when the access control model of the application needs a rethink. The journey from a basic role-based access control (RBAC) or rudimentary access models to a more nuanced fine-grained approach is often perceived as a never-ending project, due to its foundational nature. However, it's a transition that holds the promise of not only enhancing security postures but also being an enabler of the business and meeting compliance mandates such as SOC2, ISO27001, GDPR and CCPA.

The initial place to begin is to augment the simple role checks with additional conditions where the context of the user, the resource, and the action they are trying to do upon it, are taken into account in the permissions check. For example, implementing a control that says only the owner of the purchase order can update it, is an example of an attribute-based access control (ABAC). ABAC applies conditions beyond whether someone has a role or not to include logic against individual attributes of the user and the resource - for the owner, the ownerId attribute of the resource being accessed must be equal to the ID of the user making the request, thereby introducing a logical, contextual element to access control.

The journey from a no access or RBAC model to ABAC isn't about replacing one model with another; it's about evolving to a model that can integrate a myriad of attributes and scenarios, making authorization decisions more intelligent and context-aware.

Embracing externalized authorization

When designing a new access control model, leverage these fine-grained ABAC checks. The key consideration is how to ensure you don’t end up making the spaghetti code problem even worse - especially in large heterogeneous codebases.

Pulling from the best practices of distributed architecture design, externalized authorization is emerging as the go-to approach for future-proofing an application’s security model, where a centralized, yet distributed mechanism, for managing access control is stood up.

Unlike the traditional embedded authorization logic within each service, a centralized system, such as Cerbos, enables authorization logic to be defined as policy and then distributed to local authorization services, which are called from by the application to check access. This decentralized approach aligns well with the essence of microservices architecture where each service operates independently, and performs one specific task.

Centralizing authorization policy leads to consistency in access control logic, significantly reducing the complexity associated with managing disparate authorization logic across various services.

A pragmatic approach to implementation

Embarking on this journey doesn’t necessitate a wholesale change overnight. A pragmatic, phased approach can mitigate risks and ensure smoother transition. At Cerbos, we recommend beginning by isolating specific domain areas, transitioning one component at a time, learning from each phase, and progressively tackling more complex domains.

For instance, in a large financial system, one can initially focus on refining permissions for the reporting module, before venturing into invoice creation and customer account maintenance. Such an approach not only provides a controlled environment for transition but also fosters an organizational learning culture, gradually acquainting teams with the new access control model.

Conclusion

The strategic importance of adopting a flexible, granular, and compliant access control model cannot be overstated. Taking a finer-grained approach with ABAC policy-driven authorization can not only meet the current requirements, but also sets up a workflow and process to support future access control needs.