net/go.book
All Parts Marketing

Cloud Networking Security

Renting an apartment in a large building means the landlord secures the front doors, the elevators, and the foundation, but you're still the one who has to lock your own apartment door and not tape the spare key under the doormat. Cloud security works the same way, and forgetting who is responsible for which lock is one of the most common causes of cloud breaches on record.

The Shared Responsibility Model

Every major cloud provider frames security as a shared responsibility: the provider secures the underlying physical infrastructure, hypervisor, and (for managed services) the platform itself, while the customer remains responsible for configuring identity, network access controls, data encryption, and the workloads they deploy correctly. The exact dividing line shifts depending on the service model - infrastructure-as-a-service pushes more responsibility onto the customer than a fully managed platform-as-a-service does - but the customer's share never reaches zero. A remarkable number of publicly reported cloud incidents trace back not to a provider failure but to a misconfiguration on the customer's side of that line.

Network Segmentation in the Cloud

Virtual Private Clouds (VPCs) give each customer an isolated virtual network within the provider's infrastructure, further divisible into subnets - typically a public subnet for internet-facing resources and private subnets for backend systems with no direct internet route, mirroring the on-premises segmentation principles from earlier in this part.

Security groups act as stateful, instance-level virtual firewalls: define which ports and source addresses are allowed inbound and outbound for a specific resource, and return traffic for an allowed connection is automatically permitted without a matching explicit rule.

Network ACLs operate at the subnet level and are stateless, meaning inbound and outbound rules must both be defined explicitly for a connection to complete in both directions. Security groups and NACLs are complementary layers, not substitutes for each other - a common real-world pattern is a broad NACL as a subnet-wide baseline with tighter, resource-specific security groups layered on top.

Identity and Access as a Network Control

In cloud environments, Identity and Access Management (IAM) is a network security control every bit as much as a firewall rule. A management API reachable from anywhere on the internet is only as secure as the credentials and permissions guarding it - a leaked access key with broad, unscoped permissions can grant an attacker the ability to open network paths, spin up resources, or read data directly through the provider's own control plane, without needing to breach a single VPC boundary. Least-privilege IAM policies, short-lived credentials, and mandatory multi-factor authentication for privileged accounts are as central to cloud network security as any security group configuration.

Cloud-Native Firewalls and Web Application Firewalls

Beyond security groups and NACLs, most providers offer managed firewall and WAF services that inspect application-layer traffic for common attack patterns - SQL injection attempts, cross-site scripting payloads, known bad request signatures - before it reaches an application. These sit conceptually alongside the IDS/IPS concepts covered earlier in this part, applied specifically to HTTP/HTTPS traffic at the edge of a cloud deployment, often integrated with a content delivery network for both performance and an additional layer of filtering.

Secrets and Logging

Hardcoded credentials in source code or container images remain a persistent source of cloud breaches; dedicated secrets management services (rotating database credentials, API keys, and certificates automatically) close much of that gap. Equally important is comprehensive audit logging of control-plane activity - every API call that creates, modifies, or deletes a resource - which feeds directly into the SIEM correlation practices from earlier in this part and is frequently the only record available after an incident of exactly what an attacker did with compromised credentials.

Zero Trust in a Cloud Context

The zero trust principles covered earlier in this book apply naturally to cloud networking: rather than trusting traffic because it originates inside a VPC, each request is authenticated and authorized on its own merits, typically through short-lived service identities and mutual TLS between internal services rather than implicit trust based on network location alone. This matters more in cloud environments than traditional data centers precisely because the traditional network perimeter is far less meaningful when workloads span multiple regions, providers, and third-party services.

Frequently Asked Questions

If our security groups are locked down tightly, do we still need Network ACLs too? Yes, because they protect against different failure modes. A security group is stateful and attached to a specific resource, so a single misconfigured or newly launched instance can silently miss the rules you intended; a subnet-level NACL acts as a blunter but subnet-wide backstop that applies regardless of how any individual resource was configured, catching mistakes that a resource-by-resource approach can miss entirely.

We haven't been breached, so does that mean our IAM permissions are scoped tightly enough? Not necessarily - overly broad IAM permissions are a latent risk, not an active alarm, and they typically only surface once a single credential is leaked or a service is compromised for some unrelated reason. The safer way to check is auditing what permissions are actually used against what's actually granted, rather than waiting for an incident to reveal the gap.

Is a publicly exposed storage bucket really more dangerous than a sophisticated zero-day exploit? In terms of how often it actually happens, yes - the pattern behind an enormous share of publicly disclosed cloud incidents is a misconfigured access policy on a bucket, database, or management interface, not an exotic exploit. It's a useful reminder that attackers overwhelmingly go after the easiest available path, and a default-private, explicit-allow posture closes off far more real-world risk than most exotic defenses would.

Does "zero trust" in the cloud mean we no longer need VPCs and security groups? No - zero trust changes what you rely on for authorization, not whether network-layer segmentation still exists. VPCs, subnets, and security groups still shape what can reach what at the network level; zero trust adds an additional layer on top, authenticating and authorizing each individual request on its own merits instead of assuming that anything already inside the VPC boundary can be implicitly trusted.

Summary

  • The shared responsibility model means the provider secures the infrastructure, but the customer is always responsible for configuring their own network, identity, and data controls correctly.
  • VPCs, subnets, security groups, and NACLs together form layered network segmentation, mirroring on-premises defense-in-depth principles.
  • Misconfigured public exposure of storage, databases, and management interfaces is the single most common root cause behind publicly disclosed cloud incidents.
  • IAM, secrets management, and control-plane audit logging are network security controls in the cloud, not separate concerns from firewalls and segmentation.