How can one centrally manage / audit AWS resource-based policies

Question

An administrator of an AWS account wants their users to be able to create their own S3 buckets, SQS queues, and KMS keys and attach resource-based IAM policies to their resources. How can said administrator find resources that have resource-based IAM policies in bulk and review these to ensure they are in compliance with a set of standards?

Given that these policies are in line, the only thing I can think of is to use Amazon's list of aws services that support resource based policies, find all resources of each of these services, and then get the policy associated with each of the resources.

This approach does not allow effective planning for the potential of AWS enabling users to attach resource-based policies to future Amazon services.

Is there a best practice or a smarter approach here?

Answer 1

You should be able to use AWS Config for this to ensure that only certain policies are allowed. Within Storage, you have the following options:

ebs-snapshot-public-restorable-check
efs-encrypted-check
elb-deletion-protection-enabled
s3-bucket-blacklisted-actions-prohibited
s3-bucket-logging-enabled
s3-bucket-policy-grantee-check
s3-bucket-policy-not-more-permissive
s3-bucket-public-read-prohibited
s3-bucket-public-write-prohibited
s3-bucket-replication-enabled
s3-bucket-server-side-encryption-enabled
s3-bucket-ssl-requests-only
s3-bucket-versioning-enabled

For your usage case, I think you can use s3-bucket-blacklisted-actions-prohibited and block for example all s3:GetBucket* policies.

You can also use these rules in CloudFormation templates.

Answer 2

I would suggest disallowing the putPolicy* API call for each of the service supporting resource policies for all of the non-admins. Then providing a structured interface to make changes to these policies. I'm fairly certain users can still create S3 Buckets and SQS queues without having the putPolicy permission. I do think you need to have the putPolicy permission to create a new CMK.

Cloudformation

If you had all of the resources in question controlled in CF, and your users could submit pull requests to the CF Template. Then you could have your reviewers review the changes before running the stack and implementing the changes.

Simple Workflow Service

Though I don't have personal experience with this service, this might be a good use-case. You could have users submit a proposed policy, have it sent to an approver and have it automatically implemented upon approval by Lambda. This seems like the lowest friction solution to me.

Service Catalog

Again, I don't have personal experience operating this service, but (I believe) you can set up a catalog item to make any change that can be represented by Cloudformation and provide cookie-cutter templates that users are allowed to use. It might be possible to list serveral types of policies with variables the users can control that would allow them flexibility without creating a policy that locks everyone out or otherwise doesn't meet your business standards. Also, this wouldn't require manual approval.

Roll your own

This isn't so hard of a problem that you couldn't write a Lambda or Fargate or other type of service that checks with your businesses ticketing system and implements policies that have been approved. And you might be able to provide an interface that automatically approves certain policies (no allow all, admins have allow all, no deny that apply to admins, etc.), but that depends on how confident you are in your validation logic and what your business needs are.

Answer 3

Adding to the other answers, IAM access analyzer is an interesting service that might be some help to you. It is quick and free way to audit cross account access given to AWS resources. It covers S3 buckets, KMS keys, Lambda functions and SQS queues. It also covers IAM roles that allow cross account access (using trust policy). Here is a screenshot of how a finding looks like in Access Analyzer:

Here the "crossAccountS3" role allows another account to assume itself and gain access to the resources allowed by the policies attached to the role.

This solution only covers one of the possible abuse cases with resource policies but is definitely useful.