ARTICLE

Logical Access Protection: securing the use of your AWS account with IAM

From AWS Security by Dylan Shields

The Wall between Accounts

Suppose you have two unrelated applications that run in the same AWS account. The first is a WordPress site, and the second is a Jenkins server. Both applications run on EC2. If Alice is a user who works on the WordPress site, and has full access to EC2, then an attacker with Alice’s credentials could attack both applications. In this scenario we say that both the WordPress site and the Jenkins server are in the blast radius of the Alice user. Figure 1 depicts this scenario. Ideally compromising a user which is meant for one application shouldn’t have any impact on the other. What can we do to reduce Alice’s blast radius?

Figure 1. When user accounts are compromised, all applications in the same account are potentially vulnerable, not only the ones involving the user.
Figure 2. Separate AWS accounts provide logical separation of resources. The compromise of a user in one account is unlikely to have an impact on resources in a different account.

Attribute-Based Access Control with Tags

Attribute-Based Access Control (ABAC) is a model that allows for dynamic permissions which depend on attributes of the caller and the resource. This is in contrast to Role-Based Access Control (RBAC) where all the resources a user can access are defined explicitly in the Identity Policies. In the Tagged Resources section, we’ll see how to use ABAC to grant a user permission to terminate only non-production EC2 instances. In the Tagged Principals section, we’ll investigate using ABAC to grant users permission to terminate EC2 instances only in the projects they work on.

Tagged Resources

Suppose we’ve production and non-production EC2 instances running in one account. We want to give a user permission to terminate any non-production EC2 instances. With the tools we have, this is tricky. We could add the ARNs of all the non-production resources to the Resource Block of the user’s Identity Policy, but then every time we create a new instance, we must update that policy.

$ aws ec2 create-tags \ #A
--resources i-123abc \ #B
--tags Key=Environment,Value=Prod #C
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:TerminateInstances",
"Resource": "*",
"Condition": { #A
"StringEquals": { #B
"ec2:ResourceTag/Environment": "NonProd" #C
}
}
}
]
}
Table 1. Services that support Tag-based Authorization

Tagged Principals

We’ve seen how we can apply controls based on attributes of the resource being accessed. Now we’ll see how we can do the same thing using attributes of the caller. Consider a scenario where multiple teams are working on separate projects within the same account. Can we set up the permissions in a way that a user who works on one project can’t terminate EC2 instances from another project?

$ aws iam tag-user \ #A
--user-name Alice \
--tags Key=Project,Value=ABC
$ aws ec2 create-tags \ #B
--resources i-123abc \
--tags Key=Project,Value=ABC
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:TerminateInstances",
"Resource": "*",
"Condition": { #A
"StringEquals": { #A
"ec2:ResourceTag/Project": "${aws:PrincipalTag/Project}" #A
} #A
} #A
}
]
}

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Manning Publications

Follow Manning Publications on Medium for free content and exclusive discounts.