Auditing & Accountability for AWS S3 Read-Only Roles

AWS S3 is one of the most widely used storage solutions in the cloud, handling everything from backups to high-throughput data lakes. However, with its pervasive use comes a critical need for strong security practices. Ensuring proper auditing and accountability for S3 access, particularly for read-only roles, is essential.

Mismanagement of S3 permissions is a common entry point for unauthorized access, and even read-only access can expose sensitive information. This post explains key steps to audit and enforce accountability for S3 read-only roles, helping you improve your cloud infrastructure’s security posture.

Why Auditing AWS S3 Read-Only Roles is Non-Negotiable

AWS Identity and Access Management (IAM) allows for granular control over users, groups, and roles. Read-only roles might seem harmless due to their lack of write permissions, but they still allow users to see your data, metadata, and access patterns.

Here's why auditing read-only roles matters:

• Data Exposure: Exfiltrating sensitive data is still possible with read-only access.
• Untracked Usage: The "assume role"feature can make it unclear who accessed what, when.
• Compliance Standards: GDPR, SOC 2, and other regulations often require complete auditing trails.
• Preventive Diagnostics: Pinpoint unusual activity patterns and fine-tune role configurations before a breach occurs.

Step-by-Step Guide to Audit AWS S3 Read-Only Roles

To ensure your S3 read-only roles are secure and traceable, follow this structured audit process:

1. Identify All Read-Only Roles

• Use AWS CLI to fetch roles with s3:List* or s3:Get* permissions:

aws iam list-policies
aws iam list-roles

• Narrow your focus by specifically checking policies attached to roles:

aws iam list-attached-role-policies --role-name <role-name>

• Identify resource scoping. Unrestricted permissions like "Resource": "*" require especially close scrutiny.

2. Log and Monitor Access Requests

Every S3 request leaves a trail in AWS CloudTrail. This service records who made the request, the source location, and the request's outcome. To track read access:

• Enable CloudTrail logging for S3:

aws cloudtrail create-trail --name S3AuditTrail --s3-bucket-name <your-bucket>
aws cloudtrail start-logging --name S3AuditTrail

• Use AWS Athena to query logs for actions like GetObject or ListBucket.

Example Athena query:

SELECT eventTime, userIdentity.userName, eventSource, eventName
FROM cloudtrail_logs
WHERE eventName IN ('GetObject', 'ListBucket')

3. Assess Accountable Use

Users often share read-only roles across tasks, making precise attribution more difficult. Address this by:

• Tagging S3 bucket operations with environment-specific metadata (e.g., team names or application IDs).
• Enforcing Session Tags during “assume role” operations. Example:

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/ExampleRole --role-session-name MySession --tags Key=Project,Value=Audit

• Querying API requests with session tags using CloudTrail or AWS Config.

4. Regularly Validate Permissions

Over time, roles often collect additional permissions that weren't part of the original design. Validate that all existing read-only roles:

• Follow Least Privilege principles: allow only the minimum s3:Get* or s3:List* calls necessary.
• Avoid wildcard permissions ("Action": "s3:*" or "Resource": "*") in policy-based roles.
• Perform periodic scans with AWS's IAM Access Analyzer or the simulate-principal-policy command.

Best Practices for Enhancing Accountability

Beyond identifying and auditing read-only roles, you can improve accountability with these strategies:

Use Centralized Access Management Tools

AWS Organizations or third-party solutions can consolidate role-based access management across accounts. This reduces the risk of mismatched policies.

Automate Alerts for Policy Changes

Deploy AWS Config or EventBridge rules to automatically alert teams whenever:

• Critical S3 bucket policies are modified.
• IAM roles are edited to include read-specific actions.

Rotate Access Keys for Temporary Roles

While assumed roles don’t explicitly use keys, related sessions generate temporary credentials. Rotating roles and enforcing expiration policies adds another layer of security.

See Auditing in Action

Enabling robust auditing for S3 read-only roles doesn’t have to take months. Tools like hoop.dev simplify this process by offering in-depth tracking, automated tagging, and instant insights into role activity. With help from hoop.dev, you can implement and validate these security practices in just minutes.

Take control of every “read” operation in AWS S3—try hoop.dev and experience better auditing today.