AAD, Azure, Azure Active Directory, Azure AD, Azure RBAC, Azure Security, Cloud Security, Cybersecurity, Entra, Identity, Microsoft Entra, Permissions Management, Security
Permissions Management and AWS Account
Howdy folks. This is third installment in my testing of Microsoft Entra Permissions Management. The first post had initial overall impressions. The second post was about Azure subscriptions. This installment is about collecting permissions from AWS Account.
I have to say up front that I’m not an expert in securing AWS, like I’m (or pretending to be) with Azure. And here I see a potential problem with Permissions Management. If you read my second post, you will see that Permissions Management does not give a clear picture on all accounts that can control Azure subscription or subset of it. I only know it because I have pretty good experience with securing Azure and can see where Permissions Management is not telling me what I need to know.
With AWS, I have to fully depend on Permissions Management to be authoritative on what it sees and tells me as the factual information about all accounts that can control it. If I don’t know what it is potentially missing (like in Azure case) then I’m blinded with luck of such information.
I have a single AWS account that I use for some limited testing. I configured it with a few accounts, assigning them with different permissions, those that seems to me as fairly powerful. I configured all of it with the Root Account on which I have MFA enabled. Note upfront, Permissions Management does not know anything about the root account, as it only looks at the AWS IAM.
Account Name | Policy Assigned | MFA | Type |
admin | AdministratorAccess | no | user |
admin1 | AdministratorAccess | no | user |
admin2 | AmazonEC2FullAccess | no | user |
admin3 | AWSSSODirectoryAdministrator | no | user |
admin4 | IAMFullAccess | no | user |
admin5 | IAMUserChangePassword | no | user |
admin6 | SecurityAudit | no | user |
admin7 | AWSCloudShellFullAccess | no | user |
admin8 | AWSCodeDeployFullAccess | no | user |
admin9 | AWSLambdaDynamoDBExecutionRole | no | user |
admin10 | AWSMarketplaceFullAccess | no | user |
admin11 | SecretsManagerReadWrite | no | user |
testuser1 | ReadOnlyAccess | no | user |
mciem-oidc-connect-role-msft | n/a | role | |
mciem-collection-role-msft | SecurityAudit | n/a | role |
The last two roles in the table are roles configured as part of setting up Permissions Management to collect data from AWS Account.
Permissions Management interface for AWS is the same as for Azure, but it has some additional categories.
After refreshing data in the Permissions Management, I have the following observations:
- Two accounts are marked as Super Identities, accounts Admin and Admin1, both assigned the same “AdministratorAccess” policy. None of the other policies have the same designation. I have not found actual list of all AWS policies that would be considered Super Identities. If you have a list, please drop a link in the comments!
- Three accounts marked as Over-Provisioned Active – Admin account and both of the roles.
- All accounts marked as no MFA configured accounts – which was nice!
- All accounts that have not been used (most of them in my case) have been marked as inactive.
- Three accounts were marked as “Can access Secrets”, both SI accounts and Admin11 with “SecretsManagerReadWrite” policy. This is nice, as with Azure it did not report on the AKV RBAC roles.
Same, as with Azure, the primary dashboard provides very basic high level information. For specific account details you have to go into Analytics page and drill into each account individually.
So at this point I’m on the fence on the comprehensiveness of the Permissions Management reporting on all accounts that can control AWS account and its resources. I can see almost 750 different policies available to be assigned to users. I can’t test them all, but out of a few random with “FullAccess” it only flagged one policy as Super Identity. Is it missing something, like it does in Azure?
I’ll have to do a bit more research on it.