CASE 96 · TALISMAN · 2025
S3 endpoints scoped to the buckets they’re allowed to talk to.
A B2B SaaS company’s S3 Gateway Endpoints were configured with the default open policy — any S3 bucket, any operation. A compromised IAM principal would have had a clean exfiltration path. We tightened the endpoint policies to a per-environment allowlist of buckets and operations.
B2B SaaS
SECURITY
2025
RESULTS
What changed, by the numbers.
EXFIL ATTACK SURFACE
−98%
BUCKETS REACHABLE
14
OPERATIONS PERMITTED
6
BREAKAGE FROM TIGHTENING
0 CRITICAL
HOW IT WENT
The default Gateway Endpoint policy is `Action: *, Resource: *` because that’s the easiest thing to ship. Most teams never revisit it. We did the math: a compromised production IAM role could `s3:GetObject` against any public-API-reachable S3 bucket in the world (including any other AWS customer’s public bucket). That’s a clean exfil path nobody had been thinking about.
We tightened the policies per environment: production endpoints could only reach the 14 named production buckets, with a six-operation allowlist (GetObject, PutObject, etc.). We ran the new policies in shadow first via VPC Flow Logs, catching the few legitimate cross-account S3 calls we hadn’t known about and explicitly allowing them.
Exfil surface dropped 98% against the default-allow baseline. Zero critical breakages — three minor ones (background scripts hitting public AWS data buckets) got the explicit allow they needed. The policy template now ships with every new VPC.
RELATED · SAME DOMAIN
Other engagements in this space.
READY WHEN YOU ARE
Let's get your AWS bill (and architecture) in order.
The discovery call is free. You walk away with at least one concrete idea — even if we never work together.