ACM.115 A dedicated and easy-to-identify virtual machine for a specific user on a zero-trust security group and personal SSH key
This is a continuation of my series on Automating Cybersecurity Metrics.
In our last post we created a user-specific security group that limits traffic to a single remote user’s IP address.
In this post we are going to use it to deploy a user-specific EC2 instance.
Creating a unique VM name per user
In order to create a user-specific VM we need to add the username to the VM. We’re already doing that because we are passing in the user name (Developer) as the NameParam.
We use that in the instance name via a tag:
We also use the username in an output.
Assigning our user-specific Security Group
If you recall we create our user VM by passing in a list of security group IDs:
We’ll need to get the security group ID for our user-specific security group. We can get that from the outputs of our security group stacks by using the stack name concatenated with the specific username.
We’ll need to get those outputs to add to our function that deploys our developer vm and add them to the list of security group IDs:
This function is currently for a Linux VM so we’re just deploying the SSH security group. Just add -$user to the end of the stack and export name
Update the deploy script to add the second developer. Notice that I moved the code to get the latest AMI up so we only retrieve it once for both developers.
We’ll also need to deploy an SSH key for the second developer:
And prior to deploying the key, a secret where our script attempts to deploy the key:
We will probably want to think through our new user creation process a bit more later but for now just added that code above, deployed the secret, then the SSH key, and then the VMs.
After that’s done you can see now we have two VMs — one for each developer — with the name of the developer in the VM name.
You may not want usernames in your VM names depending on who has access to your account. If someone has the username they could try to use the username and enumerate passwords, but if people can get the usernames out of the logs or from somewhere else it’s a bit of a moot point. Hopefully you are using MFA — correctly — so attackers require more than one factor to get access to your cloud environment.
Now you’ll notice when we start the new instances they are automatically running. We want to make sure we are only running instances when in use to save money. We’ll take a look at that in the next post.
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:
____________________________________________
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
