ACM.116 Other security controls and policies to consider for user-specific EC2 instances
This is a continuation of my series on Automating Cybersecurity Metrics.
Code in the last post automatically stops a VM after deploying it to help save money when resources are created before they are needed for use.
https://medium.com/@2ndsightlab/automatically-stop-vms-on-aws-792cded54578
Now that we have deployed our user-specific VM we can think about how the controls we put in place may be bypassed.
We have created a number of restrictions to try to lock down access to a VM to a single user.
As it is now:
We only have one SSH key associated with the instance for the specific user that is allowed to login to that instance.The security group only allows that specific user’s IP address to access the instance (in the scenario where you have remote users and each user has a different remote IP address.)If one user tries to log into another user’s instance, their SSH key won’t work.They won’t be able to get through the network controls.
What could a user do to get around these restrictions?
As explained in a prior post there is a way to add or change an SSH key. If the user can swap out an SSH key on an EC2 instance with their own, they could login.
Troubleshoot connecting to your instance
If a user in the developer group has backup and restore permissions they might be able to back up a volume and attach it to their own instance. Since we created a single KMS key for all members of the developer user group, they would not be restricted by encryption controls.
Restoring from an Amazon EBS snapshot or an AMI
If a developer has permission to detach a volume then they could attach it to a different host.Detach an Amazon EBS volume from a Linux instanceAttach an Amazon EBS volume to an instanceIf a user has permission to change the security groups on an instance (which is part of the ec2.* permission set) then they can add their own user-specific security group to a different ec2 instance.
No resource policies for EC2 instances or Security Groups
EC2 instances do not offer resource policies. Neither do security groups. (#awswishlist). I have wished that you could apply policies to networking since I was working on the Capital One cloud network and cloud engineering teams.
When I implemented the networking for bastion hosts and a proxy on AWS these hosts needed direct access to other networks. Anyone with permission to change the security groups and networking or deploy a new EC2 instance (VM) could deploy it in that networking with broad access.
In fact, I remember when the person who approved network security changes noticed that someone had put security groups associated with different tiers in a three tier network to their EC2 instance. He wasn’t too happy. I think our NACLs and routes would have helped somewhat but he was worried that the person had effectively created a proxy to bypass our networking standards.
User-Specific and zero-trust IAM Policies for EC2 Instance Actions
This is where your IAM policies can help you. You’d want to disallow risky actions or limit them to an VM with a name that matches the user taking the action.
Disallow users from taking EC2 actions on any instance but one that matches a particular naming convention (and make sure they cannot soehow bypass the naming convention)Disallow users from reassigning security groups to those they shouldn’t be able to use.Disallow EC2 deployments with SSH access to any IP other than their own via their own user-specific SSH security group.Disallow attaching and reattaching volumes or making snapshots unless required.Leverage an automated backup process — that is not associated with a single user’s credentials! (Yes, I’ve seen that. I won’t say where.)Be cautious in your architecture regarding who can get to or leverage the backup credentials. This also helps you protect against ransomware infecting all your backups.Make sure users cannot assign permissions greater than their own to an EC2 instance.
I’m not going to write the code to protect against all of the above right now, but something to consider when trying to protect your EC2 resources.
Follow for updates.
Teri Radichel
If you liked this story please clap and follow:
******************************************************************
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
******************************************************************
© 2nd Sight Lab 2022
All the posts in this series:
Automating Cybersecurity Metrics (ACM)GitHub – tradichel/SecurityMetricsAutomation
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
Bypassing the User-Specific Restrictions We Created for Cloud VMs was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
