Why use multiple roles instead of just one?
When it comes to security in the cloud, the principle of least privilege is extremely important, and it tells us that we should always only grant the bare minimum privileges needed to perform a job function.
As an example, if all I need to be able to do is read data from a single CloudTrail trail, then I should not also have access to other trails or to Amazon EC2.
Not only can this help protect us from insider threats, but it can also help protect against accidental mistakes, where you could have a role that only has permissions to read data and not write or make changes to data or services. If an employee isn’t meant to be able to make changes to configurations, then they shouldn’t have write access.
Even if that employee is meant to be able to make changes from time to time but on most days they’re only performing tasks that require reading data, there’s no need for them to use a role that has write permissions for their day-to-day activities.
How roles get used and deployed depends a lot on the organization and how they want to run things. It also depends a lot on the size of the organization.
If you’re the only employee or if you only have a handful of technical employees, it will look different than if you have hundreds or thousands of technical employees, and so segmentation of permissions varies widely depending on that.
In this course, we’ll follow AWS best practices as closely as possible so that you can take what we’re building and apply it regardless of your company size — but just keep the above in mind as you progress along.
Roles we need for this course
For this course, we’re going to create 4 roles:
SecurityAnalystSecurityDeploySecurityBreakGlassSecurityAdmin
SecurityAnalyst Role
The SecurityAnalyst role is what we’re going to assume while we’re performing analysis steps, which is when we’re primarily reading data.
You can imagine that if you’re part of a larger organization, you may have one person in charge of the analysis and they would assume this role.
Or, even if it’s a smaller organization and it’s only you, you can still make use of this role as a way of forcing you to follow your playbook, and we’ll see that in action in this course.
SecurityDeploy Role
The next role we’ll create is the SecurityDeploy role, which is the role you would use to deploy infrastructure. How you deploy infrastructure is up to you — you can use Terraform, Pulumi, CloudFormation, or the AWS CDK. Whatever you use, you need a role that can be assumed by those tools.
In this course, we’ll be using CloudFormation for the initial lab environment deployment, and we’ll also make manual changes.
SecurityAdmin Role
After that, we’ll create a SecurityAdmin role which is what we can use to perform security tooling admin tasks like to modify Athena settings, modify CloudTrail settings, etc… as needed. Think of this as the role we use to administer security tooling services in our accounts.
Keep in mind that ideally you are deploying and configuring these services by using Infrastructure as Code (IaC) and not “ClickOps” which is when you go around in the console and click around. That way, you have a repeatable set up that you can easily tear down and re-create, or easily modify without having to log into the AWS console. But sometimes, you may need to make on-the-fly changes in an emergency situation.
SecurityBreakGlass role
The last role that we’ll create in this course is called the SecurityBreakGlass — in reference to breaking glass to reach the fire alarm in an emergency.
This role is only meant to be used in emergency situations like in the case of a legitimate incident response, and that’s what we’ll use it for in this course and as per the incident response playbooks from AWS. We’ll use this role to perform:
- Containment tasks
- Eradication tasks
This role should either have full AdministratorAccess or for more mature setups, it should provide just required permissions for a particular playbook. This is quite a bit more advanced, though, and so for this course we will provide it with admin access.
Another reason the SecurityBreakGlass role gets used
Another reason that a SecurityBreakGlass role gets used by organizations is if you’re using Identity Center, then the SecurityBreakGlass role also acts as a failsafe in case there’s an Identity Center outage or compromise, or if your identity provider has an outage or compromise.
You don’t want to be stuck and locked out of your account in that situation. You could still assume this break glass role with a break glass user, which is one of the few situations where it is recommended to still have an IAM User.
Because this role should never be used unless there’s an emergency, it’s one of those roles that we can set up a lot of alerts for. Basically, you should know the moment someone uses this role for any reason, and then you should go back through and audit what was done with that role so that you know exactly who/what/where.
A great way to deploy the SecurityBreakGlass role and the alerts you need is to use this repo from AWS themselves: https://github.com/awslabs/aws-break-glass-role.
For this course and for the sake of time, we’re going to simplify it a little bit and so we won’t be using this more advanced script, but it’s definitely worth checking out.
Conclusion
Now that we know what roles we’re going to create for this course, let’s actually do that! Let’s complete this lesson and move on to the next!
Responses