Cloud Network Security — Security Groups & NACLs Guide

In this tutorial, you'll learn about Cloud Network Security. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Cloud network security uses security groups and network ACLs to filter traffic at the instance and subnet boundaries, with AWS, Azure, and GCP each offering stateful and stateless options.

What You Will Learn

The difference between stateful security groups and stateless network ACLs, how to design a defense-in-depth network layer, and CLI commands to audit and enforce rules.

Why It Matters

Misconfigured network rules are the number one attack vector in cloud environments. An overly permissive security group can expose a database to the entire internet within minutes of deployment.

Real-World Use

A fintech startup uses AWS security groups with zero-trust rules: all inbound traffic denied by default, only specific CIDR blocks allowed, and audit logs forwarded to a SIEM platform for every rejected connection.

Stateful vs Stateless

Security groups are stateful — if you allow inbound traffic, the return traffic is automatically allowed. NACLs are stateless — you must explicitly define both inbound and outbound rules.

flowchart TD
  Client[Internet Client] -->|Inbound: Allow 443| SG[Security Group\nStateful]
  SG -->|Return traffic auto-allowed| Client
  
  Client2[Internet Client] -->|Inbound: Allow 443| NACL[Network ACL\nStateless]
  NACL -->|Return traffic\nmust be explicit| Client2
  
  style SG fill:#390,color:#fff
  style NACL fill:#f90,color:#fff

AWS Security Groups

Security groups act as virtual firewalls for EC2 instances. Each instance can have up to five security groups. Rules are always permissive — there is no deny rule.

# Create an HTTP-only security group
aws ec2 create-security-group \
  --group-name web-sg \
  --description "Allow HTTP and HTTPS from anywhere" \
  --vpc-id vpc-0a1b2c3d

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# Verify rules
aws ec2 describe-security-groups --group-ids sg-12345678
# Output:
# {
#   "SecurityGroups": [{
#     "GroupName": "web-sg", "#     "IpPermissions": [
#       {"IpProtocol": "tcp"", "FromPort": 80, "ToPort": 80, "IpRanges": [{"CidrIp": "0.0.0.0/0"}]},
#       {"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "0.0.0.0/0"}]}
#     ]
#   }]
# }

Azure Network Security Groups

Azure NSGs filter traffic at the subnet or NIC level. Rules include priority values that determine evaluation order. Lower numbers are evaluated first.

# Create an NSG with a rule to block inbound port 3389 (RDP)
az network nsg create --name prod-nsg --resource-group prod-rg

az network nsg rule create \
  --nsg-name prod-nsg \
  --resource-group prod-rg \
  --name block-rdp \
  --priority 100 \
  --direction Inbound \
  --access Deny \
  --protocol Tcp \
  --destination-port-ranges 3389 \
  --source-address-prefixes Internet

az network nsg rule list --nsg-name prod-nsg --resource-group prod-rg --output table
# Output:
# Name       Direction  Priority  Access  Protocol  DestinationPortRange
# block-rdp  Inbound    100       Deny    Tcp       3389
# default-allow-ssh  Inbound  300  Allow  Tcp  22

GCP Firewall Rules

GCP firewall rules are global and apply to VPC networks. They support both ingress and egress filtering with target tags for granularity.

# Create a firewall rule allowing SSH only from a bastion host
gcloud compute firewall-rules create allow-ssh-bastion \
  --network default \
  --allow tcp:22 \
  --source-ranges 10.0.1.0/24 \
  --target-tags ssh-bastion

gcloud compute firewall-rules list --format="table(name, network, direction, priority, allowed)"
# Output:
# NAME              NETWORK  DIRECTION  PRIORITY  ALLOWED
# allow-ssh-bastion default  INGRESS    1000      tcp:22
# default-deny-ingress  default  INGRESS  65535  deny-all

Defense in Depth Strategy

Layer your network controls: use NACLs at the subnet boundary for broad denial, security groups at the instance level for fine-grained access, and web application firewalls at the edge.

Common Mistakes

1. Using 0.0.0.0/0 for SSH or RDP: Never open SSH (port 22) or RDP (port 3389) to the entire internet. Use a bastion host or VPN with restricted source CIDR.
2. Confusing stateful vs stateless behavior: With stateless NACLs, allowing inbound HTTP means you must also allow outbound ephemeral ports (1024-65535) for return traffic.
3. Ignoring default deny rules: Azure and AWS both include default deny-all rules at the bottom of every NACL. Ensure your explicit rules cover all needed traffic so default denial doesn't break legitimate flows.
4. Applying security groups at the wrong level: Use NACLs for broad subnet-wide rules and security groups for instance-specific policies. Mixing them incorrectly creates bypass paths.
5. Not tagging firewall rules: As environments scale, untagged rules become unmanageable. Tag every rule with its purpose, owner, and expiration date.

Practice Questions

1. What is the difference between a stateful security group and a stateless NACL?
2. In Azure NSGs, how does rule priority affect traffic evaluation?
3. What GCP feature lets you apply firewall rules based on instance labels?
4. Why must stateless NACLs define both inbound and outbound rules?
5. How would you block all traffic except HTTPS to a web server across all three clouds?

Challenge

Design a network security architecture for a three-tier web application. The web tier must accept HTTPS from the internet, the app tier must accept traffic only from the web tier, and the database tier must accept traffic only from the app tier. Implement this using security groups and NACLs in any cloud, then write the equivalent rules for the other two.

FAQ