What Do Authentication and Authorization Mean in Zero Trust?

The foundation of putting zero trust security principles into practice is authentication and authorization. What they mean is actually quite simple, but the specifics of how authentication and authorization work in zero trust versus other systems are different.

Authentication simply means proving that the user, whether a human or computer user, is in fact who they claim to be.

Authorization means establishing, once we are certain of the user’s identity, that this person or service is permitted to access the resource that it is requesting access to.

“Authentication and authorization don’t necessarily change their meaning in a zero trust context,” said Leonid Belkind, chief technology officer and co-founder of Torq, a security automation company.

“If at all, authentication becomes much stricter, if you’re granting it properly, and authorization becomes much more granular,” he said. “Instead of asking, ‘Could I access my corporate data center and do whatever I like with it?’ you would ask to access this particular document inside this particular application, inside this particular section of my data center, from this particular location, using this particular device at this particular point in time.”

Authorization depends on authentication. It makes no sense to authorize a user if you do not have any mechanism in place to make sure the person or service is exactly what, or who, they say they are.

Most organizations have some mechanism in place to handle authentication, and many have role-based access controls (RBAC) that group users by role, and grant or deny access based on those roles. In a zero trust system, however, both authentication and authorization are much more granular.

To return to the castle analogy we explored previously, before zero trust the network would be considered a castle, and inside the castle there would be many different types of assets. In most organizations, human users would be authenticated individually — have to prove not only that they belong to a particular role, but that they are exactly the person they say they are.

Service users can often also be granularly authenticated. In a RBAC system, however, each user is granted or denied access on a group basis — all the human users in the “admin” category would get blanket access, for example.

It was also not possible to give a user access to only a portion of the resources inside the castle: The knight standing at the drawbridge could either come in and get full access, or be turned away.

In other words, one could not grant granular access. In practice, this generally means both human and computer users are granted excessive permissions.

According to the most recent Cloud Threat Report by Prisma Cloud of Palo Alto Networks, 99% of cloud users, roles, services and resources are granted permissions that they don’t use — in other words, permissions that they do not need.

Getting Granular

One of the most important aspects of zero trust is granularity. In a zero trust system, granting access based on roles is not security enough. Access requests have to be granular, and access is granted to only that single resource, for only a set amount of time.

This requires organizations to break up their castles into single-resource fortresses. This particular analogy does a good job at illustrating the architectural shift that has to happen to move to zero trust: Granting granular access is only possible once you have created the proper structure around it.

A zero trust strategy helps cut down on granting too many unnecessary permissions, which can easily be used to gain illicit access to a network.

The idea of breaking resources into more granular components is the same as the principle behind microservices in general. As services are broken into smaller pieces and data is broken up into smaller pieces, it becomes more possible to grant access granularly.

When all of your resources are clustered together in a “castle,” with no mechanism for sending people away from a particular room once they are inside, it isn’t possible to implement zero trust.

The Role of Automation

In talking about authentication and authorization in a zero trust environment, there is sometimes an assumption that the process must always be 100% automated. That’s not true.

Clearly, without some automation tools it would be impossible to get anything done in a zero trust system. But some types of requests can, and should, be reviewed manually by a human.

“In fact, for zero trust network access of users, the system could be semi-automated, it could involve people in the loop,” Belkind said. “I don’t necessarily assume that we are talking about machine-to-machine communications.”

Time-Limited Authorization

One of the most common misconceptions about zero trust systems is that once a user is authenticated and authorized, that user becomes a “trusted” user. The user is able to come and go from the fortress at any time.

However, there are no trusted users or trusted devices in a true zero trust implementation. Users have to be authenticated and authorized each time they attempt to access a resource.

And in a true zero trust architecture, there will be a time window on the authorization: this user is allowed to do this particular action in this time window. Neither the user nor the associated device becomes trusted.

Out in the real world, the vast majority of security leaders acknowledge the importance of zero trust. “You need to first take the step of authentication of users and systems, and not everybody even has that basic step implemented,” said Jonas Iggbom, director of sales engineering at Curity, an IAM and API security technology provider.

“But then you need to encore the fact that, yes, you’re Jonas, but are you allowed to access this information? That enforcement is even less implemented in organizations. At this point, there’s still a reasonably heavy lift for organizations to actually implement that.”