Distinguishing Authn and Authz

For many organizations, understanding how to monitor, manage, secure, and audit authorization and access is difficult because the distinction between "authorization" and "authentication" is poorly defined.

The latest updates to the NIST Cybersecurity Framework are an important reminder of how quickly the threat landscape changes. Technology has greatly advanced; so have cybersecurity threats since the NIST framework was initially released in 2014. For example, consider the updates to the Identity and Access Control section of NIST. It was updated to clarify concepts such as authn and authz and to provide guidance on best practices for controlling machine identity and access. This is important as machine access starts to exceed human user access at an exponential rate. This is a trend largely driven by mass adoption of DevOps and digital transformation (DX) practices.

One of the reasons NIST was updated is because many vendors and systems purportedly solve "authorization and access management," but, in reality, they are actually identity (authentication) management solutions. As companies ramp up digital transformation (DX) efforts and move more data into highly connected or cloud-based systems, the consequences of this misunderstanding increases. The modern organization must provide both authentication and authorization management at scale, with an architecture that is cloud native, programmable, distributed, and durable. In order to do so, however, they must first distinguish authn from authz, and then address each appropriately.

Understanding the Difference

Authn primarily deals with user identity: who is this person? Is she who she says she is? There are a large number of systems that handle this "checkpoint" level of identity and access management and help to reduce the number of credentials that a user needs to provide, often through single sign-on (or SSO).

Authz answers a different set of questions, for example: what should this user or system be allowed to access (authz can manage service-to-service as well as user-to-service permissioning)? An authz platform might determine if a user is a developer, and then grant his/her permission to push source code to a Git repository, but prohibit the user from directly changing the software deployed into the production environment.

This is a critical distinction for organizations that have a fast-moving infrastructure, such as those that are part of a DevOps initiative, or digital transformation where there is a push to move away from on-premises IT and towards a cloud-first future. The engine that drives DevOps is infrastructure-as-code. This enables operations teams to configure machines as code. These machines need access and privilege to do what they were programmed to do, but it is increasingly more difficult for security teams to keep track of who or what has access.

The move from monolithic on-premises servers to micro-services and containers complicates the authz and authn picture by introducing more privileged access, secrets and users/machines to authorize and authenticate. It is no longer only a question of "who is this person and what he/she wants to access." Now, it is also a question of "what is this machine and what does it want to access?"

In our experience, there are (at least) five use cases for authorization-as-a-service in the authz sense, none of which are handled by authn alone:

• Implementing role-based access controls (RBAC) for user-to-system and system-to-system permissions management.
• Keeping critical access keys out of code, off of hard drives, and out of code repositories such as GitHub and GitLab.
• Generating audit reports to demonstrate regulatory compliance around access and authorization.
• Managing SSH keys and/or secrets at scale across dynamic systems.
• Gaining visibility into the total set of cloud systems in use and seeing who has access to them.

Organizations Must Control Machine Access and Understand Authz and Authn

NIST is a largely voluntary compliance framework in the public sector, but it is still widely respected as a cybersecurity guide. However, compliance frameworks are a lagging indicator of the cybersecurity threat landscape because they address breaches that have occurred multiple times. This means that any organization that does not already have both authentication and authorization solutions with machine and application identity capabilities is a cybersecurity late adopter and at great risk of a breach.

Editor's Note: This article originally appeared July 2014. It has been updated to reflect recent information.