You’re on a three-day holiday when your boss rings you up, saying a few GuardDuty alerts are firing up. Luckily, you have your laptop with you. You open it up, log in to the console, quickly investigate the situation, and find a contextual false positive (someone was migrating data from one S3 to another).
Have you ever been in such a situation?
It's an advantage to have access from anywhere. You were able to log in quickly and investigate.
Now, think from the other angle.
One of your applications has a debug endpoint that leaks environment variables (including AWS credentials). An attacker discovered this.
The attacker uses the leaked credentials with their automation tools and explores the account to achieve their objectives (crypto mining).
For the attacker as well, it's an advantage to have access from anywhere.
The fundamental fact of the cloud is the control plane is accessible from anywhere in the world.
It’s entirely different in the world of on-prem servers. Let’s say you manage on-prem servers and have an admin console to manage and monitor your servers. A standard security approach to secure the admin console includes cutting down internet access so the console is accessible only from the local network.
If your network admin leaks their credentials on the internet, it might not a huge problem. The attackers must be on the network (whether through physical access or VPN) to authenticate to the admin console using the leaked credentials.
But in the cloud, since it's accessible from anywhere, the consequences of a credential leak are high.
Leaked credentials = Can be exploited from anywhere.
Is a high-permission user compromised? An attacker could:
Spin up EC2 instances
Read sensitive storage content
And much, much more
Some possible solutions
Restrict all access to AWS to a specific IP using SCP
You can add a Service Control Policy (SCP) to restrict access to specific IP ranges that your company owns. The policy does not deny requests made by AWS services.
If your company doesn’t own an IP range but has a VPN, you can route all traffic to AWS through the VPN and allow the VPN’s IP address.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"1.2.3.4/16"
]
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
}
}Pros:
Easiest to implement.
Completely removes the attack surface for leaked credentials.
SCPs apply to all IAM entities, groups, and roles
Cons:
SCPs don’t apply to AWS Org master accounts. Any IAM users on that account (it's a bad practice) can still leak their AWS access keys.
You need an internet gateway for all your VPCs and whitelist their IPs on the SCPs. If not, AWS will deny access to your temporary IAM keys from your EC2s.
Add permissions boundary or deny-based IAM policy to IAM entities
You can add IAM permissions boundaries to IAM users and roles. The following permission boundary policy explicitly allows access only from a specific range of IPs.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"1.2.3.4/16"
]
}
}
}
]
}If you use IAM groups, you can’t add the permissions boundary. Instead, you can add a deny-based policy to restrict access based on source IP.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"1.2.3.4/16"
]
}
}
}
}Pros:
Flexible as permission boundaries or deny-based IAM policies can be tweaked as per requirement
You can implement permission boundaries to IAM entities even in the AWS Org root account.
Cons:
Operationally, it takes a lot of work to implement and maintain them. If you miss adding permission boundary or deny-based access policy to few IAM entities, they still post some risk.
Permissions boundary is an advanced concept. Sometimes, debugging IAM deny errors can be a bit harder.
Using either of the above approaches, you can remove the risks associated with leaked credentials altogether. The bigger question is how hard it is to roll out this strategy in your company.
My course “Securing AWS: Strategies for Lean Teams” is live now!
Unlock AWS security mastery at 40% OFF – your ticket to securing AWS like a pro awaits! (Oh, did I forget to mention about free preview videos in the course)
