ACM.154 Taking a look at the roles created by Amazon in a new AWS account
Part of my series on Automating Cybersecurity Metrics. The Code.
I previously showed you how to set up AWS Organizations, create a new Organizational Unit, and a new AWS account. In the last post, we took at look at the root user in that new account and how to lock it down with MFA.
Risk Associated with the Root User for a New AWS Organizations Account
In this post, we’ll take a look at the service-linked roles created by AWS in a new account. We’ll consider the risk of these and other service-linked roles you can create for your Organization.
View the roles in the new account created by AWS Organizations
Log into the new Governance account we created in the last post that is in the Governance OU we created for our AWS Organization in the above post. Remember we haven’t done anything in this account yet except to add MFA to the root user.
On the same screen in the above post where you altered MFA (the IAM dashboard) you can see that there are four roles in our new AWS account via the AWS IAM dashboard.
You can view the roles by clicking on the number above or by clicking “Roles” in the left menu.
You can see in the Trusted entities column that four of the roles are Service-Linked Roles. That means that those roles associated with an AWS service. An AWS service needs that role to perform actions on your behalf in your AWS account.
Evaluating the risk associated with the role: AWSServiceRoleForOrganizations
Click on AWSServiceRoleForOrganizations. Click on Trust relationships.
Here you can see the trust policy that allows the aws Service identified as organizations.amazon.com to use the permissions associated with this role in your account.
I explained what trust policies are in this post and we’ve been considering them from a lot of different angles throughout this series.
Resource, IAM, and Trust Policies on AWS
It is up to AWS to ensure that only the systems within their infrastructure that are supposed to use this role can do so in accordance with the AWS Responsibility Model which I explained here:
What are AWS’s Security Responsibilities, Anyway?
What permissions does this role have?
Click on the Permissions link. Click on the role name link.
Here you can see that the role has limited IAM Write permissions.
Click on the IAM service name link.
This role has permissions to create service-linked roles and delete roles.
Click on {} JSON.
Notice that the role is read-only. Also notice that this policy is not restricted to your account specifically which is interesting. The permissions do restrict this role from deleting any roles other than the aws organizations role. However, the CreateServiceLinkedRole is unrestricted. I wonder why this is not a more restrictive white list of roles that the AWS Organizations service is allowed to create like the delete permission.
We can’t edit this policy but can we delete the role? When I click on it the Delete button becomes active. However, I am not going to delete this role right now. Read on…
Can I edit the role? Looks like only the description:
Has this role been used? Click on Access Advisor. Note the limitation I mentioned with Access Advisor previously. It does not show you all actions taken in the account, only those associated with IAM, EC2, Lambda, and S3. Since this role has IAM permissions, you might expect them to show up here. This screen says the role has not been accessed in the tracking period. I’ll leave it as an exercise for the reader to determine if Access Advisor correctly logs activity for this role.
What does this role do anyway? Let’s consult the documentation:
Using AWS Organizations with other AWS services
When you configure a trusted service and authorize it to integrate with your organization, that service can request that AWS Organizations create a service-linked role in its member account.
…
AWS Organizations provisions the member account with a service-linked role named AWSServiceRoleForOrganizations. Only the AWS Organizations service itself can assume this role. The role has permissions that allow AWS Organizations to create service-linked roles for other AWS services.
In other words, when you want to enable certain features of AWS Organizations to manage all your accounts, AWS Organizations will use this role to create other service-linked roles to allow those services to work.
What is the risk associated with this role? Well, that depends what roles can be added and what their permissions are in your account via the service-linked roles that this role can create.
Perhaps you are thinking that you can add a Service Control Policy to limit the actions this role can take. Perhaps you could disable it and then re-enable it if needed via a policy at the organizational level. Recall what I pointed out earlier — Service Control Policies do not affect service-linked roles.
What’s the risk associated with this role? Could someone who has access to turn on service linked roles and then use that service to harm your organization? Well, let’s take a look at what services can work across your organization.
AWS services that you can use with AWS Organizations
How about AWS Backup?
Could someone turn on the organizational backup capability and back up all your data using the backup capabilities and exfiltrate it to another AWS account? I haven’t tried that yet and not going to at the moment. Instead, I’m going to only explicitly grant principals in my account the permissions they require.
As you recall when I created my delegated administrator policy, I only granted access to manage service control policies. I did not grant the user permission to all AWS organizations capabilities.
Delegated Administrator for AWS OrganizationsDelegating SCP Management to Governance Team via AWS Organizations
It appears that the only user that can enable additional service-linked roles for the organization should be the root user even after I create the AWS governance user with the above policies in this new AWS account. If AWS is securing things on their side, then the risk should be limited to the risk of someone gaining the root user credentials at this point. We will need to keep the risks associated with this role in mind as we add other principals and permissions in our AWS account.
Evaluating the risk associated with the role: AWSServiceRoleForSupport
Next we can take a look at the service support role created by AWS Organizations in our new account.
Using service-linked roles for AWS Support
The documentation states:
This service-linked role is predefined, and it includes the permissions that AWS Support requires to call other AWS services on your behalf.
Amazon describes some of the actions support staff might take on your behalf in the above documentation. We can also take a look at the permissions associated with the policy the same way we did above.
You will see that the list is quite long, but mostly consists of read-only actions:
Take a look at the IAM permissions in this role:
I can glean a lot of helpful information on an assessment or penetration test with information like the above. Consider the Capital One breach and the actions taken by the attacker, a former AWS support person.
That support person, if given access to run the support-accessible IAM and EC2 commands in the Capital One account, could query the following:
Which AWS EC2 instances are available from the Internet?Which AWS EC2 instances are associated with which instance profiles?What permissions those profiles and thereby those EC2 instances have?
With that information, the attacker would know what AWS Instances to target and what actions to try to take on those instances upon gaining access. I take a similar approach on AWS penetration tests.
Note also that AWS updates this role once per month to add permissions for new AWS functionality:
Maintaining this role securely is part of AWS’s responsibility along with all the other features and technology they create to allow you to do the things you do on AWS.
Questions on when and how AWS support professionals can use these permissions should be directed to AWS. Additionally, organizations should consider if they really want anyone in their organization interacting with AWS support (as some I know do) or if that access should be more restricted and monitored.
I imagine that AWS support professionals cannot randomly login and scan your account. I presume an associated support request must exist which grants them access to look at your account and the resources in it (I hope!) I also hope and presume that AWS is monitoring actions taken by support professionals in customer accounts for excessive and abnormal activity.
I also presume and hope that if a customer has not enabled support via a support plan that the support role is more limited because without that support plan there is no reason that I can see for a lot of the functionality in this role.
What would be interesting and perhaps preferable would be to give customers the ability to enable or disable a role without deleting it. That way a customer could disable a role until it is required without having to delete and redeploy it. #awswishlist
Considering the risk associated with the role: AWSTrustedAdvisorServiceRolePolicy
Once again, take a look at the JSON for the IAM policy associated with AWS Trusted Advisor. This is a service that can send you alerts and track risks in your AWS account. This is one of the earlier services created to help identify problems in AWS accounts and has somewhat limited capabilities but is useful. The policy is a limited subset of read-only permissions compared to the AWS support role.
This particular service should be fully automated, so hopefully the risk associated with this service is low. If someone could access the service and leverage the role in some way they might be able to glean some useful information about your account, but AWS claims to automate everything and separate people from data so the risk in this case should be minimal.
Using service-linked roles for Trusted Advisor
Should you delete service-linked roles?
Let’s log back in and take a look at the AWS Organizations management account again and take a look at a few things that exist there.
I explained what the AWS Organizations Management Account is in this post:
Automated AWS Organization Creation
On the AWS Organizations dashboard click Services in the left menu. These are the services you can enable to help manage your organization.
The first role we looked at is used by the AWS Organizations service to add new service-linked roles for each of the above services when you enable them in your AWS account. AWS recommends that you do not add or delete roles for the above services in some other manner besides using this dashboard because you may get unexpected results.
If you do not plan to use any of the above services and only use AWS consolidated billing (add all your accounts to an organization to manage the bills for all of them in one place) then you can delete the role: AWSServiceRoleForOrganizations.
Although we don’t recommend it, if your organization has only consolidated billing features enabled, the service-linked role named AWSServiceRoleForOrganizations is never used, and you can delete it. If you later want to enable all features in your organization, the role is required, and you must restore it.
Scroll down and search for Trusted Advisor. You can see here that access for AWS Access advisor is disabled for the organization.
There is also no option to turn on or off the AWS Support service-linked role here.
Those two roles exist whether you use AWS Organizations or not and they are not controlled by AWS Organizations.
Head over to the IAM dashboard. These three roles also exist in the management account.
Should you delete these roles if you are not using those services? If you do you’ll want to test it out and make sure nothing breaks. I find AWS Trusted Advisor to be somewhat useful. It’s not very in-depth but it can provide alerts to basic problems. Why not use it?
As for the support role, if you do delete it you’ll need to be very sure you test that out and that you don’t need AWS support ever if you try to do that. If you create a copy of that role it will be different in a month. AWS maintains a whole lot of functionality for the platform as a whole so if you’re going to trust them with all of that you might decide to trust them to manage access to use the support role appropriately.
That said, it doesn’t hurt to ask more questions about how that role is used in detail if you have a large organization with sensitive data. If someone uses that role, will every single action be logged in your account so you can see what they did? What triggers someone’s ability to use that role? How are their actions monitored by AWS to determine if those actions were excessive, perhaps in an attempt to enumerate resources in your account?
Evaluating the risk of other AWS Services in use in your AWS Account
Sometimes people want a “Reference Architecture” and I always tell them that is not really possible. Yes, some reference architectures exist. But the services you enable and disable in your account are going to be specific to the needs of your organization. Each service may come with service roles such as those I describe in this post. Each time you enable a service you need to assess how that affects your existing security controls.
You should be analyzing the risk associated with any service you enable and the permissions you give it in your account as I have done here. Not only do you need to evaluate the risks given to the cloud platform itself in your account, you need to evaluate how enabling that service affects the permissions of existing principals and policies in your account. Will enabling a service allow credentials in your account to do something unwanted by the virtue of service linked roles, policy changes, and new functionality?
This is why I say security architecture is not a check list. I don’t want to just teach you cybersecurity terms. I want to teach you how to think about security.
Security Architecture is Not A Checklist
If you want to discuss your cloud security architecture I can do so at a very high level on an IAN Research call. Arrange with your IANS representative to send me any encrypted documents in advance of the call as I do not click on links during a call. I can perform a more in-depth assessment or penetration test through my company, 2nd Sight Lab. Reach out in either case using the links at the bottom of this post.
OrganizationsAccountAccessRole
There was one additional role in our account created by AWS Organizations — the OrganizationsAccountAccessRole. What is that? I’ll cover it in the next post.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
If you liked this story ~ use the links below to show your support. Thanks!
Support:
Clap for this story or refer others to follow me.
Follow on Medium: Teri Radichel
Sign up for Email List: Teri Radichel
Follow on Twitter: @teriradichel
Follow on Mastodon: @[email protected]
Follow on Post: @teriradichel
Like on Facebook: 2nd Sight Lab
Buy a Book: Teri Radichel on Amazon
Buy me a coffee: Teri Radichel
Request services via LinkedIn: Teri Radichel or through IANS ResearchAbout:
Slideshare: Presentations by Teri Radichel
Speakerdeck: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Company (Penetration Tests, Assessments, Training): 2nd Sight Lab
Cybersecurity for Executives in the Age of Cloud on Amazon
Cloud Security Training (virtual now available):
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.
More by Teri Radichel:
Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
Risk Associated With Default AWS Service-Linked Roles was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
