Way back when I was working at Turner and deploying security audit roles, there were concerns over the level of access the ReadOnlyAccess policy would provide. We would have access to data that we were legally obligated to protect, but due to licensing and competition reasons, we could not be allowed to access. At the time, the specific division I was working with only stored this data in S3 and DynamoDB, so crafting a workaround that met everyone’s needs was reasonably straightforward.
Fast forward five years. AWS has gotten more complex, there are more services, and there still is no clear delineation between the access needed to audit an environment vs the access to the data in the environment.
[ tl;dr - here is a link to the repo ]
Mike Julian (the socially well adjusted half of the Duckbill Group) recently reached out to understand how they could improve the roles the ask of their clients. The need to do a security audit and the work they do around cost optimization & architecture are generally similar. Both need to know how the account is configured, but not necessarily the data that is in the account.
The common wisdom is to avoid the use of the clearly over permissive ReadOnlyAccess managed policy. But the alternatives, ViewOnlyAccess or SecurityAudit, aren’t adequate. There are 110 services in ReadOnlyAccess that are not in the ViewOnly/SecurityAudit managed policy.
The above-linked report from Rodrigo Montoro summarized the problem:
We reiterate that the problem does not lie in the ReadOnlyAccess policy but in the lack of comprehension of access and authorization levels, as well as the consequent threats it provides, especially when we are talking about access to third parties, a situation in which the policy in question is commonly used.
The cloud security community has been discussing this since (at least) 2018:
Scott Piper: Yikes, so I just looked at their privileges, and they request ReadOnlyAccess as the easiest way, which is way more data than they need, as that let’s them read all of the files out of your S3 buckets and some other resources, as opposed to just the metadata.
Andrey Devyatkin: A request that we get from almost every one of our customers is a read-only IAM policy so developers and operators can browse production safely.
Caleb Tennis: I’m looking for a list of AWS IAM api actions that are data specific vs management actions. The context is to have policy that limits infrastructure tools from being able to access data directly (think “allow s3 bucket actions, but deny s3:GetObject”). Is there a curated list already floating around out there?
heath: Howdy team - At a new org, we’re looking at rescoping our Security IAM roles across our AWS Org. Trying to avoid the ReadOnlyAccess trap that is currently in use. Does anyone have any good links for leading practices on setting that up fresh or reference policies around a Security Read-only role?
Phil Sweeney: ViewOnly and SecurityAudit policies are not a bad start.. tends to be missing a few things so you’ll need your own custom additions too
Jason Kao: The few approaches I’ve seen: like what Phil said, ViewOnly and SecurityAudit with a custom additional managed policy. ReadOnlyAccess with an explicit deny policy as a custom supplement. I found this to be easier to manage as we saw issues with ViewOnly and SecurityAudit being updated with new services. Trade-off is making sure the explicit deny denies the proper permissions (or an applicable SCP or Permission Boundary).
The problem is more than just what is metadata vs data. Other actions have significant implications. CloudSplaining went on to define actions that can lead to Privilege Escalation, Credential Exposure, and Resource Exposure. Ian Mckay (a true hero) took that list and added them to his iam-dataset project (here).
None of that solved my immediate problem of “How do I create a policy that allows me to audit the environment fully but not have access to customer data?"
What is the Sensitive Actions Repo
The sensitive_iam_actions repo is a machine-readable (YAML) file that enumerates the actions that can lead to:
- CredentialExposure
- DataAccess
- PrivEsc
- ResourceExposure
Explicit Opt-in vs. explicit Opt-Out
So our options are to explicitly define all the services and their Get* List* Describe* actions, or leverage the AWS managed policy (which only in the case of ReadOnlyAccess seems to get updated).
I’ve decided the most straightforward approach was to be over-permissive on my allow statements and then pair back access via explicit deny statements. The yaml file can be processed to create deny statements for use in policies.
There are a few problematic actions that can lead to data access but also contain critical configuration information. lambda:GetFunction is an example of an action that gives you details about runtimes and environment data but also allows the auditor to download the codebase via the pre-signed URL returned.
What does this mean for you?
If you’re still reading this, you’re probably disappointed at lack of Snark ‘n Memes. Really this post is to raise awareness. I don’t know enough about every service to know what’s considered data vs metadata. Hell, AWS can’t even answer that, so it falls on us in the cloud sec community to figure it out.
Please, if you know of or learn about new data access, privilege escalation, resource or credential exposure possibilities using these AWS actions, please send me a pull request. If you want to start leveraging these files for your own projects, feel free to do so. And by all means drop me a line - chris at primeharbor dot com - if you do use it and I’ll let you know about any major updates.
Service Analysis of ReadOnlyAccess, ViewOnlyAccess, and SecurityAudit
We pull the JSON down for three policies and run them through little shell magic:
cat ReadOnlyAccess.json | jq .Statement[0].Action[] -r | awk -F: '{print $1}' | sort | uniq
- ReadOnlyAccess.json: 261
- SecurityAudit.json: 160
- ViewOnlyAccess.json: 160
The services in SecurityAudit & ViewOnlyAccess are the same.
In the ViewOnlyAccess not in ReadOnlyAccess:
- comprehendmedical
- deepracer
- docdb-elastic
- finspace
- geo
- honeycode
- kafka-cluster
- quicksight
- s3-outposts
110 services in ReadOnlyAccess but not in ViewOnlyAccess. You’re blind to all of these services if you rely solely on ViewOnlyAccess:
- amplify
- apigateway
- appconfig
- applicationinsights
- appstream
- aps
- arc-zonal-shift
- artifact
- aws-portal
- backup-gateway
- billing
- billingconductor
- budgets
- cassandra
- ce
- chatbot
- cleanrooms
- cloudhsm
- codeguru-profiler
- codeguru-reviewer
- codestar-connections
- codestar-notifications
- compute-optimizer
- consoleapp
- consolidatedbilling
- customer-verification
- databrew
- deepcomposer
- devops-guru
- discovery
- dlm
- drs
- ec2messages
- elemental-appliances-software
- emr-containers
- emr-serverless
- evidently
- fis
- freertos
- freetier
- gamesparks
- groundstation
- healthlake
- identity-sync
- identitystore
- identitystore-auth
- imagebuilder
- importexport
- internetmonitor
- invoicing
- iot1click
- iotfleethub
- iotfleetwise
- iotroborunner
- iotwireless
- ivs
- ivschat
- launchwizard
- lookoutvision
- m2
- macie2
- mediaconvert
- mgh
- mgn
- mobileanalytics
- mobiletargeting
- monitron
- networkmanager
- nimble
- notifications
- notifications-contacts
- oam
- omics
- osis
- outposts
- payment-cryptography
- payments
- pi
- pipes
- polly
- proton
- purchase-orders
- rbin
- refactor-spaces
- resiliencehub
- resource-explorer-2
- route53-recovery-cluster
- route53-recovery-control-config
- route53-recovery-readiness
- rum
- s3-object-lambda
- sagemaker-groundtruth-synthetic
- savingsplans
- scheduler
- servicecatalog
- servicediscovery
- signer
- sms-voice
- ssm-contacts
- ssm-incidents
- sso-directory
- supportplans
- sustainability
- swf
- tax
- timestream
- tnb
- vpc-lattice
- workmail
- workspaces-web