Cloud Attack Surface: What You Are Missing

Misreading: The firewall is the boundary

Many teams treat the cloud like a data centre with a virtual front door. They monitor ingress traffic and block known malicious IP ranges. This approach fails because cloud services communicate via application programming interfaces rather than raw network packets.

Correct reading: The boundary is the identity provider. Access is granted through tokens and roles, not open ports. If a user has permission to read a storage bucket, they can do so from anywhere, regardless of firewall rules. You must audit who can do what, not where they are connecting from. For deeper context on managing these credentials, review the principles in our guide on cloud security architecture.

Misreading: Encryption equals security

Organisations often assume that encrypting data at rest and in transit solves the exposure problem. They enable default encryption on storage buckets and enforce HTTPS for APIs. This creates a false sense of safety.

Correct reading: Encryption protects against interception, not against authorised access. If a service account has read permissions, it can decrypt the data on the fly. The risk is not that someone steals the encrypted file, but that someone uses a legitimate key to read it. This is why leaked cloud access keys represent a critical failure point, as the key itself is the decryption mechanism.

Misreading: Public code is separate from infrastructure

Developers often push configuration files to public repositories without realising these files contain secrets. They believe that because the code is open source or public, the underlying infrastructure is safe. This separation rarely exists in practice.

Correct reading: Code repositories often contain environment variables, API tokens, or infrastructure-as-code templates that define permissions. These artifacts can be used to reconstruct your environment or gain initial access. You must treat public code as part of your attack surface. Scanning for exposed secrets is a routine part of preventing public code repository leaks.

Misreading: Human users are the primary threat

Security teams spend most of their budget on multi-factor authentication and user training. They assume that if humans are protected, the system is safe. This overlooks the volume and persistence of machine identities.

Correct reading: Service accounts, automation scripts, and third-party applications often have broader permissions than human users. These accounts rarely use multi-factor authentication and run continuously. A compromised service account can exfiltrate data silently over months. This drift in permissions is a form of identity sprawl that outpaces human oversight.

Misreading: Shadow IT is unmanaged software

Teams often define shadow IT as employees installing unauthorized applications. They focus on blocking downloads or restricting browser access. This definition misses the infrastructure layer.

Correct reading: Shadow IT includes unmanaged cloud resources created by developers or administrators without security approval. These resources often lack logging, monitoring, or patching. They connect to core systems via internal APIs, bypassing traditional controls. Identifying these hidden resources is the first step in mapping the true scope of shadow IT.

Misreading: SaaS data is out of your control

Organisations using software-as-a-service often believe the vendor handles all security responsibilities. They assume that because the vendor is reputable, their data is safe. This ignores the configuration of data sharing and retention.

Correct reading: You retain responsibility for how data is shared within SaaS applications. Misconfigured sharing settings can expose sensitive information to the entire organisation or the public internet. You must audit user permissions and data export capabilities. This risk is distinct from the vendor’s infrastructure security and is covered in our analysis of SaaS data exposure.

Misreading: Compliance equals security

Teams often rely on compliance badges from cloud providers to assert their security posture. They assume that because the provider is compliant with standards, their specific configuration is secure. This conflates platform security with tenant security.

Correct reading: Compliance frameworks cover the provider’s infrastructure, not your configuration. You are responsible for securing the resources you provision within that infrastructure. A compliant cloud can still host insecure applications. You must verify your own controls against frameworks like the Centre for Information Security Standards.

Misreading: Disaster recovery is a backup strategy

Many teams treat disaster recovery as a process for restoring data after a breach or failure. They focus on storage snapshots and replication. This misses the operational continuity aspect.

Correct reading: Disaster recovery includes restoring identity permissions and access controls. If you restore data but lose the permission structure, you may inadvertently grant access to the wrong users or lock out legitimate ones. Your recovery plan must include identity restoration. For a full view of this process, consult our guide on cloud disaster recovery.

Misreading: Information sharing is optional

Teams often keep their security incidents internal to protect their reputation. They believe that sharing details helps attackers more than defenders. This isolation reduces collective defence.

Correct reading: Sharing anonymised threat indicators helps the broader community detect and block similar attacks. Industry-specific information sharing and analysis centres provide a structured way to exchange data safely. Participating in ISACs allows you to benefit from collective intelligence without exposing sensitive details.

Key takeaways

• Identity is the new perimeter, not the network edge.
• Default cloud configurations often expose data publicly by design.
• Internal service accounts often hold more power than human users.

Frequently asked questions

How do I find misconfigured cloud storage?

Use automated scanning tools that check for public access flags and overly broad permissions on storage buckets and databases.

Are service accounts safer than human accounts?

No, they are often more dangerous because they have persistent access and rarely use multi-factor authentication.

Does encryption stop data leaks?

Encryption stops interception, but it does not stop authorised users or compromised accounts from reading the data.

How often should I review cloud permissions?

Review them quarterly or after significant project changes to ensure permissions match current business needs.

How this guide was produced: written by the Vector Bulletin editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.