I’ve recently started the SANS SEC488 course, which is as intensive as all SANS courses tend to be.
In the cloud a solid understanding of Identity and Access Management is crucial from the start; otherwise, there’s a high chance of making early mistakes in design and deployment that can cause significant issues later on. In the realm of AWS, policies serve as a prime example of this. If you’re looking to learn these important topics, this is the course for you.
I’ve observed many junior administrators quickly jump into a new subscription and create a new AMI user, assigning an access key right away. They often attach the AdministratorAccess policy to this user and proceed without hesitation. Granted, they avoid creating access keys for the root user, which is a positive. However, this approach is still a direct path to disaster as it bypasses the crucial principle of least privilege.
Consider a fairly simple scenario:
Two AWS S3 buckets are created; foo-us-east-1 and bar-us-east-1. Then an IAM user named foobar.buckets is created and the s3-packets-buckets-east-1 policy is attached to the user. Finally access keys are generated for the foobar.buckets user.
The s3-packets-buckets-east-1 policy attached is below for review. The end result is that the foobar.buckets user is allowed to list the contents of the foo-us-east-1 and bar-us-east-1 buckets, as well as write new files to them. That it! That’s _all_ that user is allowed to do, the bare minimum to accomplish a task.
The sooner you dive in and start working, the sooner you realize you very much needed a plan. Plan your work, and work your plan in the cloud. Determine your requirements up front and bake in what you need before you proceed.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::foo-us-east-1/*",
"arn:aws:s3:::bar-us-east-1/*"
]
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::foo-us-east-1/*",
"arn:aws:s3:::bar-us-east-1/*"
]
}
]
}