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 since the NIST framework was initially released in 2014 — and so have cyber security threats . For example, consider the updates to the Identity & 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 increasingly 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 for the NIST update is that 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 questions, for example: what should this user or system be granted access to? 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 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 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 getting 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 and machines to authorize and authenticate. It is no longer only a question of “who is this person and what does 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 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 cyber security guide. However, compliance frameworks are a lagging indicator of the cyber security threat landscape because they only 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 cyber security late adopter and at great risk of a breach.
Is your organization moving fast, embracing DevOps, digital transformation, and/or shifting infrastructure to the public cloud? Conjur open source and Conjur Enterprise have helped a number of organizations implement authorization-as-a-service as part of these initiatives and can help you too.
Editor’s Note: This article originally appeared July, 2014. It has been updated to reflect recent information.
