Designing Rules for a Three-Tier App

Chain the tiers together with group references

Least privilege means each component accepts only the traffic it genuinely needs. For a web application, write the policy in plain language first: the internet may reach the load balancer on 443; only the load balancer may reach the app servers on the app port; only the app servers may reach the database on 5432; administrators reach servers through a managed session tool rather than open SSH. Then implement it with three security groups, sg-alb, sg-app and sg-db, where each inbound rule references the previous group. Nothing except the load balancer has an internet-facing rule, so even a misrouted public IP on an app server is not exploitable. Keep egress in mind too: allowing all outbound traffic is the default, but restricting the database's outbound access limits what an attacker can exfiltrate. Google Cloud achieves the same chaining with network tags or service accounts on firewall rules; Azure uses application security groups.

Chained security groups

Each tier trusts only the tier in front of it: the load balancer group, then the application group, then the database group.

The same chain as data

A JSON summary of the intended rules is easy to review in a pull request before you apply it with Terraform or the console.

{
  "sg-alb": [{ "port": 443, "from": "0.0.0.0/0" }],
  "sg-app": [{ "port": 8080, "from": "sg-alb" }],
  "sg-db":  [{ "port": 5432, "from": "sg-app" }]
}

Avoid 0.0.0.0/0 on port 22

Open SSH to the world is the classic audit finding. Prefer a session manager or a VPN; if SSH is unavoidable, restrict it to a known office range and remove it when the task is done.

त्वरित जाँच: Which rule best follows least privilege for the database tier?

• Allow 5432 from 10.0.0.0/16
• Allow all TCP from sg-app
• Allow 5432 from 0.0.0.0/0 with a strong password
• Allow 5432 from sg-app