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 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 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:
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 (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:
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.
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.
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.