Architecting Automated Operations That Require MFA on AWS
ACM.13 Requiring MFA to carry out sensitive operations with AssumeRole or GetSessionToken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: IAM | AWS Security | MFA | Passwords
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last few posts we considered types of MFA we can use with automation including an AWS Yubikey and an Authenticator app:
I also wrote about automating account creation in the last post, but we’ll dive into that deeper hopefully at a later time.
When I run a batch job, I want to require MFA so I’ll need an IAM user for that for reasons I already explained.
Possible solution #1:
Once the MFA token is processed, the batch job permissions such as retrieving, encrypting, and decrypting files will be assigned to an IAM role. The user that executers the batch job with MFA will assume the batch job role to allow the batch job to carry out the necessary tasks with the AssumeRole action.
Benefits:
- The user executing the job only needs STS assume role permissions.
- Each batch job can use a role that has limited permissions for the task at hand.
Downside:
We can’t write policies that enforce MFA such as requiring MFA when reading files in S3 buckets because API calls made by roles do not currently include an MFA indicator. Access will be denied.
I provided more details in this blog post:
I would like to see that fixed so that requests by assumed roles include the user or service that assumed the role and and the correct MFA indicator. #awswishlist. That would solve the problem of not being able to create policies that require MFA and it would make security incident handling much easier since you wouldn’t have to try to trace back the call made by the role to the original role assumption in the logs.
Possible solution #2:
Use GetSessionToken to carry out actions based on the permissions assigned to my user. In that scenario we can enforce MFA on every action taken because the MFA indicator is included in every request. We could create a bucket policy that requires MFA and when the batch job leveraging the user’s credentials accesses the bucket it would succeed because the MFA token is present.
If we use the GetSessionToken option we can enforce MFA on every action taken by our batch job, but we’d either have to create a separate user for every batch job to limit the permissions of each batch job to a zero-trust set of permissions, or we’d have to give our user a great deal of permissions to perform all the actions in every batch job. I explain zero trust in my book if you’re not familiar with that term.
Architecting a solution with zero-trust policies that requires MFA
We can overcome the challenges above by combining a set of controls to solve this problem. I like to avoid these types of solutions whenever possible because they are complicated, and when the next person comes along and doesn’t understand why and how the system was architected the way it is, they remove or change something that breaks everything. But in this case, because the assume role function doesn’t pass the MFA indicator through, we’ll have to think of alternatives if we don’t want give broad permissions or create new users for every batch job. That seems a little hokey.
What else could we do?
- We could ensure that the only way to access our batch job resources is with a batch job role.
- We can ensure that the only way someone can use that role is if they assume the role using MFA.
Since the batch job roles can only be assumed with MFA and those are the only things allowed to access our batch jobs resources without MFA we should be reasonably sure that MFA is required to access our batch job resources. We’ll test out that theory in the upcoming blog posts. We’ll also want to document this for whomever will be maintaining this solution in the future so they don’t remove or change something that breaks our security controls later on down the line.
Implementation of all of this is coming in future blog posts but we have many considerations to secure our deployment environment before we get to that point.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2022
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
