Lock down S3 bucket policies that hand sensitive actions to other AWS accounts

Amazon S3 is the storage service where most of an organization's cloud data lives — backups, exports, logs, customer files. A bucket can be configured to let a different AWS account, often a partner, vendor, or another part of the business, reach into it. That sharing is normal and useful. The problem this finding catches is when the sharing goes further than it should: the outside account is allowed not just to read or write files, but to change the bucket's own security settings.

Security Hub control S3.6 flags buckets whose sharing rules let an external account perform a short list of sensitive administrative actions — things like rewriting the access rules, changing how the data is encrypted, or making individual files publicly readable. In plain terms, it's the difference between giving a contractor a key to one room and giving them the ability to re-cut every key in the building. The cost exposure here isn't a monthly line item; it's the tail risk of a breach, a regulatory penalty, or an incident-response bill that dwarfs any storage saving.

From a financial-governance standpoint, this is a control that protects against low-probability, high-impact loss. The number to care about isn't dollars per month — it's how many buckets are in this state, whether any of them hold regulated or customer data, and how quickly the count is trending toward zero. A single flagged bucket holding sensitive data is a board-level risk; ten flagged buckets holding only public marketing assets is a cleanup task. The job of governance is to tell those two cases apart and make sure the first one never lingers.

Maya owns cloud risk reporting and chairs the monthly security review. Security Hub has flagged a cluster of S3.6 findings, and rather than treat them as a uniform list, she asks the one question that sorts them: "Which of these buckets hold regulated or customer data, and which are sharing the dangerous actions versus just read access?" The security engineer maps it out — of eleven flagged buckets, two hold customer exports and grant an external account the ability to rewrite access rules; the other nine are internal log-shipping buckets sharing only read access in an unusual but low-risk way.

The conversation is about prioritization, not policy syntax. Maya doesn't ask which IAM actions are involved or how the conditions are written. She asks who owns each of the two serious buckets, who the external account belongs to, and whether the sharing was ever formally approved. It turns out one is a sanctioned partner integration that simply over-granted, and the other is a forgotten vendor proof-of-concept from a project that ended last year. The first gets a same-week fix; the second gets the external grant removed entirely, since nobody can justify it.

Maya records both in the risk register, sets a five-business-day remediation SLA for any future High-severity S3.6 finding on a data-bearing bucket, and stands up a lightweight exception process for the deliberate low-risk cases so they stop generating review noise. Two reviews later the count is stable and every remaining finding has a documented owner and reason. The dollar figure was never the point — the point was that no external account can reconfigure customer data without someone having signed off on exactly why.

Unlike most cloud findings, this one has essentially no recurring dollar cost — tightening a bucket policy doesn't change the storage bill at all. Its entire financial significance is on the risk side of the ledger: it's a low-probability, high-severity exposure. The expected monetary impact is the probability of a data breach multiplied by the cost of one, and for a bucket holding customer or regulated data, the cost of one is large enough that even a small probability dominates any other number on the page.

That changes how it should be tracked. There's no "acceptable steady-state spend" to manage down here; the right metric is the count of flagged buckets weighted by data sensitivity, and the speed at which serious ones are remediated. A flagged bucket of public marketing images is a housekeeping item. A flagged bucket of customer PII that lets an external account rewrite its access rules is a material risk that belongs in the risk register and possibly in the next board risk update. Governance's job is to make sure those two never get treated the same way.

The third impact is contractual and regulatory. Many customer contracts and frameworks — SOC 2, ISO 27001, PCI DSS, and the NIST families this control maps to — require demonstrable least-privilege access to data. A standing population of S3.6 failures is evidence that the control isn't operating, which can surface in audits, delay deals that hinge on a security questionnaire, or trigger penalties if it's tied to data that's actually exposed. The cost of remediation is trivial; the cost of being unable to show the control works is not.

Finally, treat it as a leading indicator of sharing discipline. A rising count of cross-account findings usually means data-sharing is being set up ad hoc, without an approval step or a review cadence — the same gap that produces the next exposure. Watching the trend, and insisting that every external grant has a named owner and a documented reason, costs almost nothing and prevents the expensive version of this problem.

Cloud storage buckets can be shared with other AWS accounts on purpose — that's how partners, vendors, and internal teams exchange data. This control catches the cases where that sharing accidentally goes too far: an outside account isn't just allowed to use the data, it's allowed to change the security rules around it. That's the configuration behind a meaningful share of real-world cloud data breaches.

This is a security-posture and accountability issue, not a cost line. Each flagged bucket is a question: do we actually mean for this external party to be able to reconfigure access to our data? The right outcome isn't "never share" — it's that every cross-account grant is deliberate, scoped to the minimum needed, and owned by someone who can explain why it exists.

At one company, the security review used to surface a recurring slide: "11 S3 buckets share access with external accounts, 2 of them with administrative permissions." Every quarter the number drifted, and the discussion devolved into engineers explaining IAM syntax to a room that didn't need it. The exec sponsor changed the question. Instead of "how many findings," she asked "which of these touch customer data, who approved the sharing, and how fast do the serious ones get fixed?"

Within two quarters the slide changed shape. It no longer listed raw finding counts; it showed that every cross-account grant on a data-bearing bucket was deliberate, owned, and documented, and that any new High-severity finding was resolved within a week. The forgotten vendor integrations were gone, the legitimate partner shares were scoped down to read-only, and the noise findings had an exception process so they stopped consuming review time.

That's the right outcome state. The goal was never "zero cross-account sharing" — sharing is how the business runs. The goal was that every external grant is intentional and accountable, and that the dangerous ones can't sit unattended. The finding list stopped being an argument and became a confidence signal.

The reason this finding is tracked isn't its cost — it's near zero — but its potential consequence. It represents the specific configuration that lets an outside party gain control over how your data is accessed, which is the mechanism behind a meaningful share of public cloud data breaches. A single such finding on a bucket holding sensitive data is the kind of thing that turns into a disclosure, a regulatory penalty, and a headline; the cost of that event dwarfs anything in the cloud bill.

There's a second-order signal too. A growing or stale population of these findings means data is being shared across organizational boundaries without a deliberate approval and review step. That same absence of discipline tends to produce the next exposure, whether or not it shows up as this exact finding. So the category sits at the intersection of data protection, regulatory compliance, and operational governance — which is why it belongs on the risk report even though it never appears on the cost report.