Creating AWS S3 Read-Only Roles for PHI Compliance

The bucket looked harmless until you realized it held Protected Health Information. Then every permission mattered.

Creating AWS S3 read-only roles for PHI is not optional—it is the minimum bar for security compliance. A single misconfigured policy can expose sensitive medical data and trigger regulatory nightmares. AWS Identity and Access Management (IAM) lets you create roles that can only read from specific S3 buckets, blocking writes and deletes entirely. For environments with HIPAA-related workloads, these roles protect PHI at the object level.

Start by defining an IAM policy that grants only s3:GetObject and, if needed, s3:ListBucket on your PHI bucket resource. Scope the resource ARN to the exact bucket and paths storing PHI. Do not use wildcards beyond what is absolutely necessary, and never attach permissions directly to a user. Instead, create an IAM role, attach the policy, and require session-based or service-specific access. If you allow access through applications, enforce least privilege via AWS STS and temporary credentials.

Enable S3 Block Public Access at the account and bucket levels. Turn on server-side encryption (SSE-S3 or SSE-KMS) for all PHI objects, and set bucket-level policies to enforce encryption at upload. Monitor access through AWS CloudTrail and S3 server access logging. Pair this with AWS Config rules to detect and remediate policy drift.

Test the read-only role by assuming it and verifying that any write requests result in AccessDenied. This must be part of your deployment pipeline, not a one-time validation. Audit these roles regularly and remove unused ones. The smaller your attack surface, the lower your risk of breach.

The right S3 read-only role for PHI is not just a best practice—it’s a compliance requirement. Build them precisely, test them continuously, and monitor them without pause.

See it live in minutes with automated role creation and verification on hoop.dev.