Secure Cloud Network Access Rules

Security Group Rules Expert transforms Claude into an expert in designing, implementing, and auditing security group rules for cloud infrastructure, with deep knowledge of AWS, Azure, and GCP firewall configurations, network security principles, least-privilege access, and defense-in-depth strategies. Core principles: least-privilege access, granting only the minimum required network access, using specific ports instead of ranges, preferring CIDR blocks over 0.0.0.0/0 anywhere rules, and time-based access restrictions where supported; and defense in depth, layering security groups with NACLs or subnet-level controls, using application-level groups in addition to infrastructure-level ones, filtering both ingress and egress, and separating rules by application tier (web, app, database).

Use it to design or audit security group rules on AWS, Azure, or GCP: tiered Terraform security groups (web tier allowing HTTPS/HTTP only from a load balancer with explicit egress to the app tier, and a database tier restricting inbound to the app tier plus a named admin subnet with no outbound internet access), Azure Network Security Group rule priorities including an explicit deny-all-inbound baseline rule, GCP tag-based firewall rules scoping access by source and target tags rather than IP ranges, and AWS Config rules plus a Python/boto3 audit script that flags security groups with any 0.0.0.0/0 ingress rule. It explicitly contrasts an overly permissive rule (all ports, all protocols, open to the world) against the corrected version (a single port, restricted to a specific security group), and documents dynamic security-group patterns for auto-scaling backends and multi-environment rule templates with per-environment CIDR restrictiveness. Its key recommendations, referencing a security group by ID over an IP range when connecting AWS resources, implementing egress filtering rather than relying on default allow-all, and running regular automated audits, apply across all three cloud platforms, not just AWS.

Input is a cloud network security requirement - a new application tier's ingress/egress rules, an existing environment to audit, or a compliance check to automate. Output is security-group configuration and tooling: Terraform (aws_security_group/aws_security_group_rule) resources for tiered AWS applications, Azure NSG rule JSON with explicit priorities, gcloud firewall-rule commands using source and target tags, an AWS Config rule definition for SSH-exposure compliance checking, and a Python/boto3 script that enumerates security groups and flags any rule open to 0.0.0.0/0.

resource "aws_security_group" "database" {
  name_prefix = "${var.environment}-db-"
  vpc_id      = var.vpc_id
  
  # Database access from app tier only
  ingress {
    from_port       = 5432  # PostgreSQL
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app_tier.id]
  }
  
  # Backup/maintenance access from specific subnet
  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = [var.admin_subnet_cidr]
  }
  
  # No outbound internet access
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["10.0.0.0/8"]  # Internal only
  }
}

Documented tooling spans Terraform's aws_security_group resources, Azure's NSG securityRules JSON schema, the gcloud compute firewall-rules CLI for GCP tag-based rules, AWS Config's managed INCOMING_SSH_DISABLED rule, and a boto3-based Python audit script for AWS. Key recommendations cover using security-group references over IP ranges, implementing explicit egress filtering, running regular automated audits, tracking all changes through infrastructure as code, consistent tagging for automated compliance checks, separating duties across application tiers, and documenting the business justification for every rule.

Cloud security and platform engineers designing or auditing network firewall rules on AWS, Azure, or GCP who want least-privilege, tier-separated security group patterns and automated audit tooling to catch overly permissive rules, rather than ad hoc 0.0.0.0/0 access.