Detect and Remediate Publicly Exposed Storage (Azure Blob / S3)

Publicly exposed storage is the most common — and most embarrassing — cloud data breach pattern of the last decade. No exploit, no malware, no stolen credentials: just a bucket or container configured for anonymous access, discovered by automated scanners that continuously enumerate cloud storage namespaces. Customer databases, backups, source code, and credential files have all leaked this way. The fix costs nothing and takes hours; the exposure can cost a regulatory investigation and years of reputation repair.

How exposure happens

• A developer enables public access to make a demo, integration, or static website work, and never reverts it.
• Infrastructure-as-code templates copied from tutorials ship with permissive defaults and get reused across projects.
• Access is granted at the container/bucket level for one file, unintentionally exposing everything else in it.
• Nobody owns the review: storage accumulates over years, and the exposed resource is often one nobody remembers creating.

Detection — find what is already exposed

• Azure: list storage accounts where public access is permitted with Get-AzStorageAccount and check the AllowBlobPublicAccess property, or use Azure Resource Graph to query the whole tenant at once. Microsoft Defender for Cloud raises recommendations for storage accounts allowing anonymous access and for containers actually set to public.
• AWS: the S3 console's Access analyzer and the "Public" indicator flag exposed buckets; AWS Config rules (s3-bucket-public-read-prohibited, s3-bucket-public-write-prohibited) provide continuous evaluation across accounts.
• Distinguish configured-public from actually-accessed: enable and review access logs (Azure Storage diagnostics, S3 server access logging / CloudTrail data events) to determine whether anonymous requests already occurred — this changes the incident response answer.
• Do not forget secondary exposure paths: overly broad SAS tokens in Azure and pre-signed URLs in AWS can grant public-equivalent access without the resource ever being flagged "public."

Remediation — deny by default, at the highest level

• Azure: set AllowBlobPublicAccess to false on every storage account that does not have a documented public use case, and enforce it tenant-wide with Azure Policy (deny effect) so new accounts cannot be created public. Recent API versions default to disallowing public access — but only for newly created accounts; existing ones keep their old setting.
• AWS: enable Block Public Access at the account level, which overrides bucket-level settings, and enforce it organization-wide with Service Control Policies. New buckets have it on by default since 2023; legacy buckets need the explicit setting.
• For content that must be public — static websites, downloadable assets — serve it through a CDN (Azure Front Door, CloudFront) with origin access restrictions, keeping the storage itself private. This gives you logging, WAF, and revocation ability that raw public storage lacks.
• Replace anonymous integration patterns with scoped, time-limited access: SAS tokens with stored access policies in Azure, pre-signed URLs or IAM roles in AWS — and rotate or shorten anything long-lived found during the audit.

If you find exposed sensitive data

• Treat it as an incident, not a configuration fix: preserve access logs, determine what was reachable and for how long, and whether anonymous access actually occurred.
• Assume enumeration: exposed buckets are typically discovered by scanners within days. Absence of logging is not evidence of absence of access.
• Assess notification obligations under KVKK/GDPR or your applicable regime based on the data classes involved.

Finish by making the control permanent: a preventive policy (Azure Policy deny / AWS SCP), a detective control (Defender for Cloud / AWS Config) feeding your monitoring, and a documented exception process for the rare legitimate public use case. Exposure should require deliberate, reviewed effort — never a default.