Access has a lifecycle, too–implementing "permissions while you need them"

Mike Neuenschwander on July 15, 2022

Mike portrait

A major barrier to implementing a least privilege program is the arduous, manual, and lengthy process of turning access back on. The fear of letting go—when it comes to cloud access—is very much warranted: you may not be able to restore your access to a service in a timely manner when you need it again. But least privilege is a core principle of Zero Trust, so what’s to be done?

The way we see it, the ON / OFF dichotomy for permissions is a digital Hobson’s choice—and one the industry must quickly outgrow. As a first step, we can at least bring user access on par with options that API access already enjoys, namely the use of “one-time” and “refresh” tokens. So, the proposal is to add two new states of access: Temporary and On-demand. Temporary access provides one-time access for a specified duration (similar to a one-time token). “On-demand” means the user can regain access anytime, but the access will need to be renewed after a set duration (similar to using a refresh token). Depending on how you use these new states, either Temporary and On-Demand access could be considered “just-in-time access.” The overall effect is to have your cloud environment offer "permisions while you need them" (to turn ZipCar's marketing phrase).

The next step is to periodically adjust access, based on a range of risk factors. For example, if I move to a different dev team, some of my access should be moved to temporary while I gain on-demand access to my new team’s resources. Access should also be tied to usage patterns and manager approvals. The dynamic nature of access is why we say access has a lifecycle, too: a person’s access can change fluidly from None to Temporary to On-demand, then back to Temporary as the need arises.

access lifecycle blog

The third step is to make the access lifecycle applicable to a broad range of resources, from coarse-grained to fine-grained. A resource could be anything from a role in AWS to a specific AD group or a system policy. A proper Zero Trust implementation also means keeping metadata on such resources to categorize their level of sensitivity–for example, whether a permission provides users with admin-level access to a database. Each of these resources can have its own lifecycle and adjust over time.

With the access lifecycle in place, an approver can simply set a renewal policy and let the system perform the necessary access changes. As a result, the number of approvals, the administrative overhead, and even the anxiety are all greatly reduced, making least privilege a reality.