The Cloud Misconfigurations That Quietly Expose Company Data

When a company discovers that its internal data is reachable from the Internet, the first instinct is to look for an attacker. Often there is none, at least not yet. The data has simply been public since the day it was created, because a checkbox was left at its default, a temporary firewall rule was never closed, or an access policy was copied from a quickstart written for a test environment.

This is the fundamental difference between cloud security and traditional data centre security. In the old model, getting an internal service onto the Internet required deliberate steps: a firewall change, NAT configuration, an approval. In the cloud, the distance between private and public is sometimes a single parameter in a configuration file whose author did not realise what it meant.

What follows is a walkthrough of the recurring misconfiguration classes and how to check for each inside your own environment. The focus is detection and remediation, not finding other people’s systems.

Public object storage

This is the most common class and often the most damaging, because object storage tends to hold database exports, user uploads, generated reports and application logs.

Public exposure arrives through several independent paths, and checking only one of them is not enough:

• A bucket-level policy that permits anonymous access.
• Per-object access control lists, which can be public even when the bucket is not.
• Static website hosting configuration, which turns the entire contents into web content.
• Signed sharing links with excessive or unlimited lifetimes.
• A content delivery layer in front of a private bucket that serves the whole path prefix publicly.

How to check: use the provider’s account-level public access block. It is the strongest control because it applies regardless of what individual bucket settings say. Then review each bucket that remains exempt and record why. Enable access analysis reporting if the platform offers it, since it also surfaces indirect access paths granted to external accounts. For sensitive data, encrypt with customer-managed keys so that an accidental public setting does not automatically mean readable content.

Over-broad IAM policies and wildcards

A policy allowing every action on every resource is easy to spot. The harder variants are more dangerous precisely because they look constrained:

• Actions narrowed but the resource scope left open, for example every read action across the whole account.
• Identity-management actions mixed into an application policy, letting a service modify its own permissions.
• Trust policies that allow an external account to assume a role without an additional identifying condition.
• Permission granted indirectly by allowing a role to be passed to a compute service, which routes around every constraint above it.

How to check: do not read policies, evaluate effective permissions. Every major platform provides a simulator that answers whether this identity can perform this action on this resource once all overlapping layers are combined. Pay particular attention to policies that grant access to external accounts, and always require an additional identifying condition when granting access to a third party.

Unrestricted security groups and network rules

A rule allowing the entire Internet to reach a management port is the classic case. It is almost always created with temporary intent: an engineer working from home, a broken VPN, a contractor who needed access at short notice.

Beyond management ports, the commonly missed cases are database ports opened outward so a reporting tool can connect, security groups that reference one another and chain into something broader than intended, rules that open a whole port range instead of a single port, and public IP addresses attached to resources that were only ever supposed to live on a private network.

How to check: list every rule whose source is the entire Internet, classify by destination port, and assign a remediation deadline to each. Replace direct administrative access with the provider’s managed session service or a logged bastion, so that no management port needs to face outward at all. Use network reachability analysis to confirm the real path, because a tight-looking rule can still be undone by a route table or a load balancer sitting in front of it.

Exposed management interfaces and databases

This class is not merely an open port but a service actually listening and answering from the Internet. The usual forms:

• Application admin panels, content management back ends and internal tools deployed alongside the main application.
• Databases and caches created with defaults that permit public reachability, occasionally without authentication enabled.
• Cluster management interfaces and monitoring dashboards, which typically reveal a great deal about system structure.
• Framework diagnostic endpoints left enabled in a production build.
• File servers and internal sharing protocols enabled on hosts that hold a public address.

How to check: build an inventory of every public IP address, hostname and load balancer the business owns, then compare it against the list of services that are supposed to be public. Anything not on the allow list needs a named owner and an explanation. Put management components behind a private network with centralised authentication, and separate non-production from production at the account level so a test deployment cannot be exposed together with real data.

Long-lived access keys

Static credentials do not expose data on their own, but they are what turns a small gap into durable access. Long-lived keys tend to spread beyond their intended scope: into source repositories, into CI environment variables, into configuration files on laptops, into screenshots inside internal documentation.

How to check: the platform’s credential report tells you which keys exist, when they were created and when they were last used. Delete unused keys. For keys still in use, migrate towards temporary credentials issued through roles attached to compute or through federation from the corporate identity provider. Enable secret scanning on repositories and in the build pipeline. Build and rehearse a rotation procedure, because rotating a key for the first time during an incident is the worst moment to discover that four other services quietly share it.

Disabled or incomplete logging

This class does not expose data directly, but it decides whether you can answer the most important question after an incident: was the data actually accessed, by whom, and what left the environment.

Typical gaps include activity logging enabled in only one region while resources span several, data-access logging switched off for cost reasons, retention shorter than the time an incident usually takes to surface, logs stored in the same account as the systems they describe so a compromised identity can delete the evidence, and no alert at all when logging is turned off.

How to check: enable logging at the organisation level so it applies to every account and region, including regions you do not use. Write to a dedicated logging account with append permissions but no ability to modify or delete. Set retention long enough to support an investigation. Most importantly, alert on the act of disabling logging or changing where logs are written.

Public snapshots, backups and machine images

This class gets less attention but is severe, because a volume snapshot or machine image usually contains the entire contents of a system, including configuration files holding credentials.

Cases worth checking: volume and database snapshots with public sharing attributes; custom machine images shared for a partner project and never unshared; backups copied to another region without their access policy following them; and container image registries set to public to simplify a deployment pipeline.

How to check: enumerate every snapshot and image with sharing attributes beyond your own account, across all regions. Apply an organisation-level policy that prevents public sharing outright. Where genuine sharing is required, share directly with a named account rather than publicly, and record an expiry date for the grant.

Why a one-time cleanup is not enough

A manual review stays clean for a few weeks. Then the estate keeps changing and the same gaps return along the same paths. Three measures make the clean state last:

1. Prevent above the account level. Organisation-wide policies, account-level public access blocks and region restrictions cannot be undone by a local change.
2. Check in the deployment pipeline. If infrastructure is described as code, scan the configuration before it is applied. Fixing a line in a change request costs far less than remediating a resource already serving production traffic.
3. Monitor continuously for drift. Enable the provider’s configuration assessment service, define rules for the states you never want to see, and route the alerts into the channel your operations team already watches. An alert sent to a mailbox nobody opens is the same as no alert.

Finally, keep two activities clearly separated. Reviewing configuration inside infrastructure you own is ordinary operational work and should happen on a schedule. Scanning systems you do not own, or for which you hold no written authorisation, is an entirely different matter and outside the scope of this article.

How HiTechCloud can help

HiTechCloud is an AWS partner and a Google Premier Partner, and operates in-country infrastructure. We help organisations review the current configuration state of their cloud accounts, put preventive controls in place at the organisation level, add configuration checks to deployment pipelines, and set up separated logging suitable for investigation. If you want a review with a clearly defined scope, contact us to discuss your environment.