Though anyone who has accidentally run a migration on a production database might disagree, the primary focus for most cloud security professionals is not what a human or a program does with an over-provisioned role by mistake. Instead, security teams focus on risks presented by external actors. Recent data breaches have been caused by attackers using social engineering, mfa attacks and other techniques to obtain access to employee accounts. Essentially, they gain the ability to authenticate as an employee and if that employee has read access to your customer database so does the successful attacker.

Authenticating as an employee is only the first step. Attackers need to figure out a way to navigate the network until they’ve found the path to their target so it’s the administrator’s job to limit the attacker’s options once they’re in. One way to do that is to apply the principle of least privilege to employee access.

The Principle of Least Privilege

The principle of least privilege states that a user or program should only have access to information and resources it needs to do its job. One of the earliest explorations of least privilege was in a 1975 paper by Saltzer and Schroeder: The Protection of Information in Computer Systems

 Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional,  unwanted, or improper uses of privilege are less likely to occur.

This paper was written as Unix was gaining popularity. As such, the focus was on users and programs interacting with operating systems. Today, the principle of least privilege is used by modern engineering teams when implementing access management strategies in the cloud. But risks faced by cloud security teams are different from those considered by operating system designers.

Least Privilege in the Cloud

Least privilege applied to cloud security mitigates the risk of data breaches by limiting the blast radius if an attacker were to successfully compromise an employee account. Removing permissions until you arrive at an acceptable least privilege posture requires a balance between risk and productivity.

It is usually easier to predict the friction caused by removing permissions than to quantify the risk associated with each permission, which is why many engineering teams default to overprovisioned access. Larger companies have entire departments dedicated to managing risk and compliance which helps offset the pressure from engineers to expand their access. For smaller companies without a security department, we recommend engineers take a risk-based approach to prioritize efforts.

Wherever you start, there are a couple ways to scope down standing access for your team:

1. Remove unneeded permissions. Removing permissions that engineers will never use can be a quick and easy way to reduce the risk of a security breach. In AWS land, that might mean migrating engineers to scoped-down managed policies  (e.g. ReadOnlyAccess) in the early days and then building out your own custom customer managed policies as you grow. Later in your maturity curve you may use AccessAnalyzer to fine tune your own policies or even Repokid to harvest unused permissions over time.
2. Remove the need for risky permissions. There is often a category of manual tasks that can be automated away thereby eliminating the need for associated permissions. Adding observability and maintenance scripts might obviate the need for SSH access. GitOps tools might make it so production access can be removed from whole teams of engineers.
3. Make risky permissions temporary. For those permissions where - they would be dangerous in an attackers hands, yet engineers require them periodically - consider making them temporary. Temporary access can be gated on an approval and can be logged for visibility and reporting. JIT access can provide lightweight guardrails that enable engineers to get their job done without leaving overprovisioned standing access.

Beyond an effective risk-management framework to help with prioritization, automation can be the biggest lever for managing risk. Not only can it help eliminate the need for broad categories of access, it can remove the friction of just-in-time access which will make it easier to remove more and more standing access.

Just-in-Time Access in AWS

Just-in-time (JIT) access is a security practice where access is granted for a predetermined time, at the time it is needed. Also known as on-demand access or temporary access, just-in-time access allows administrators to reduce standing access which is important protection against data breaches.

A simple but illustrative example of a just-in-time access implementation can be accomplished using IAM roles, users, user groups and policies. Let’s say you’re using SSM for EC2 SSH access. By making access to EC2 temporary, you can reduce the risk of standing access. A simple way to migrate those permissions to a temporary role might look something like this:

1. Create new Role: EC2SSHAccess and attach a policy with the required permissions
2. Create a Group: EC2SSHAccess and attach a policy that enables anyone in that user group to AssumeRole for the EC2SSHAccess role.

Now, when a developer requires access to an EC2 instance, their AWS user can be added to that user group so they can assume the EC2SSHAccess Role.

These days if you are setting up a new AWS Organization, you’d probably begin with IAM Identity Center and would be provisioning permission-sets vs updating user groups. But at a high level, this is the same pattern: isolate the risky permissions and make it easy to grant and revoke access to them.

Automating Just-in-Time Access

As your team grows, even a few clicks to grant access can become too much. It is also easy to forget to revoke access at the right time. As your company grows, you may need to decouple the process of getting approval for access from the process of actually granting the access. Without automation, you may find yourself seeking approvals from managers or other authorities. This creates even more toil for yourself and delays for the requestor.

Automation can help smooth out the friction of just-in-time access. It can not only take the act of granting and revoking off your hands via API calls, it can make the requests and approvals easier. Some teams decide to build their own just-in-time access systems but we (selfishly) recommend taking a buy vs build approach! Consider a proven solution like Sym.

Conclusion

Just-in-time access strikes the right balance between lowering risk and maintaining velocity. It is our view that the friction of implementing just-in-time access solutions has prevented many teams from adopting JIT access for the cloud. Recent solutions like Sym provide the automation and user experience to overcome that friction. As such, just-in-time access should be a tool considered by anyone implementing least privilege in the cloud.