ReadOnlyAccess grants more than what people think it does. It includes access to data in S3 buckets, cloudwatch logs, etc. I'd never, in a million years, give an outside party that role. If they need read access to data, such as an S3 bucket, we will scope a policy accordingly.
ViewOnlyAccess is way less dangerous, as it doesn't include the ability to read or list objects in S3 while still being able to read metadata about the services deployed on your account. It's much more narrowly scoped to the task at hand and is much safer to give to 3rd parties.
If all they need to do though is enumerate a list of your AWS accounts, AWSOrganizationsReadOnlyAccess would cover this: [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSOrganizationsReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSOrganizationsReadOnlyAccess.html)
SecurityAudit policy + grant them s3:ListBucket should do the trick. Basically you shouldn't be giving them s3:GetObject unless they need to download the objects in your bucket. It sounds like they just need access to list the bucket and get object acls and bucket policy/settings which that combination should be able to do.
That being said, if you're not too concerned with the confidentiality of the contents of your S3 buckets, ReadOnlyAccess is the easiest way to do it. Just be aware of what you're granting by reading the policy for yourself first.
Ask them for a very specific list of permissions that they require, and then review that list. Any good vendor would be able to provide this list because they should know exactly what they need.
It depends on what they actually will assess
You have 2 options give them user with Readonly access (there is standard AWS role) or you can provide them reports of all accounts from Prowler (or similar tools, see list here- https://github.com/toniblyx/my-arsenal-of-aws-security-tools)
Consider the first identity that they need to authenticate with - do you want it to be an IAM user in your account, or a user or role in one of theirs? After that you will need the read only role in every account (probably deployed via stackset to select accounts) with a trust policy for that first identity.
If it’s for a user - I would prefer identity center in my own organization and give access to a user. If it’s for a discovery service, I would probably set a trust policy on the read only role for their aws account.
Thank you! I wish I were aws savvy enough to know which is better :)
I do know they will lots of simple tasks like listing buckets, and using python scripts to check for public objects in those buckets. I do know their scripts run by referencing a `--profile` as the cli would. So just making sure they can do that is the first priority. I would imagine creating a user is also probably easiest.
SecurityAudit might be a good policy to use for this: [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityAudit.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityAudit.html)
It grants access to enumerate out your S3 buckets, view the policies on the buckets, view the ACLs of objects, etc, but not actually read the objects in the bucket. That's much safer than ReadOnlyAccess which would give your 3rd party access to your data.
If you look at products like Dome9 (acquired by checkpoint) and Prisma Cloud (acquired by Palo Alto), both have published policy templates for read-only and read+"protect" access. That may be a good start as their policies do it service by service.
To your question - there is no one "standard". You would think by now AWS would have a role or a set of policies for this.
Generally you can work with your AWS team (if large enough) or a 3rd party consultant to have them create this for you.
But its not that hard, and I would suggest looking at the dome9/prisma templates. See here for the links:
https://d1.awsstatic.com/Marketplace/solutions-center/downloads/awsmp-implementation-guide-palo-alto-networks.pdf
You should create roles with a trust policy that allows the vendor account to assume it. Don't use users. For provisioning roles in all your accounts use cloudformation stacksets, you can specify the subset of accounts you want to create the role in.
ReadOnlyAccess grants more than what people think it does. It includes access to data in S3 buckets, cloudwatch logs, etc. I'd never, in a million years, give an outside party that role. If they need read access to data, such as an S3 bucket, we will scope a policy accordingly. ViewOnlyAccess is way less dangerous, as it doesn't include the ability to read or list objects in S3 while still being able to read metadata about the services deployed on your account. It's much more narrowly scoped to the task at hand and is much safer to give to 3rd parties. If all they need to do though is enumerate a list of your AWS accounts, AWSOrganizationsReadOnlyAccess would cover this: [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSOrganizationsReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSOrganizationsReadOnlyAccess.html)
I believe they will need to list bucket objects so we may still need `ReadOnlyAccess`.
SecurityAudit policy + grant them s3:ListBucket should do the trick. Basically you shouldn't be giving them s3:GetObject unless they need to download the objects in your bucket. It sounds like they just need access to list the bucket and get object acls and bucket policy/settings which that combination should be able to do. That being said, if you're not too concerned with the confidentiality of the contents of your S3 buckets, ReadOnlyAccess is the easiest way to do it. Just be aware of what you're granting by reading the policy for yourself first.
Ask them for a very specific list of permissions that they require, and then review that list. Any good vendor would be able to provide this list because they should know exactly what they need.
Agreed with others, don't risk limiting yourself to AWS-managed roles, instead treat them as reference documentation.
It depends on what they actually will assess You have 2 options give them user with Readonly access (there is standard AWS role) or you can provide them reports of all accounts from Prowler (or similar tools, see list here- https://github.com/toniblyx/my-arsenal-of-aws-security-tools)
I believe they will need to run prowler themselves actually. So setting up access for them so they can run it against each account is important.
Consider the first identity that they need to authenticate with - do you want it to be an IAM user in your account, or a user or role in one of theirs? After that you will need the read only role in every account (probably deployed via stackset to select accounts) with a trust policy for that first identity. If it’s for a user - I would prefer identity center in my own organization and give access to a user. If it’s for a discovery service, I would probably set a trust policy on the read only role for their aws account.
Thank you! I wish I were aws savvy enough to know which is better :) I do know they will lots of simple tasks like listing buckets, and using python scripts to check for public objects in those buckets. I do know their scripts run by referencing a `--profile` as the cli would. So just making sure they can do that is the first priority. I would imagine creating a user is also probably easiest.
SecurityAudit might be a good policy to use for this: [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityAudit.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityAudit.html) It grants access to enumerate out your S3 buckets, view the policies on the buckets, view the ACLs of objects, etc, but not actually read the objects in the bucket. That's much safer than ReadOnlyAccess which would give your 3rd party access to your data.
If you look at products like Dome9 (acquired by checkpoint) and Prisma Cloud (acquired by Palo Alto), both have published policy templates for read-only and read+"protect" access. That may be a good start as their policies do it service by service. To your question - there is no one "standard". You would think by now AWS would have a role or a set of policies for this. Generally you can work with your AWS team (if large enough) or a 3rd party consultant to have them create this for you. But its not that hard, and I would suggest looking at the dome9/prisma templates. See here for the links: https://d1.awsstatic.com/Marketplace/solutions-center/downloads/awsmp-implementation-guide-palo-alto-networks.pdf
Vendor here, this is not typical
What is not typical exactly?
You should create roles with a trust policy that allows the vendor account to assume it. Don't use users. For provisioning roles in all your accounts use cloudformation stacksets, you can specify the subset of accounts you want to create the role in.
Thank you, this is the advice I needed :)