Designing Access Control That Reduces Blast Radius

Module 2 – Security Groups & IAM Strategy

Security Is Layered, Not Singular

Cloud security is not one control.

It is multiple overlapping layers:

Network segmentation (Module 1)
Security Groups (instance-level firewall)
IAM policies (identity permissions)
Role separation
Least privilege enforcement

If one layer fails, another must contain the damage.

Security design determines blast radius.

1. Security Groups

The Instance-Level Firewall

Security Groups act as virtual firewalls.

They control:

Inbound traffic
Outbound traffic

They are stateful.

If inbound traffic is allowed, return traffic is automatically allowed.

Inbound Rules

Example:

Allow HTTP:

Port 80
Source: 0.0.0.0/0

Allow SSH (restricted):

Port 22
Source: Your Public IP Only

Never allow:

Port 22
Source: 0.0.0.0/0

Unless you understand the exposure risk.

Outbound Rules

By default, outbound is often open.

This means:

Instances can call any external service.
Data exfiltration risk increases.

In production, outbound rules should be restricted intentionally.

2. Security Group Design Strategy

Design security groups by role, not by instance.

Example:

sg-loadbalancer
sg-app
sg-database

Then define rules:

Load Balancer:

Inbound: HTTP/HTTPS from internet
Outbound: App security group only

App Tier:

Inbound: From load balancer SG only
Outbound: Database SG only

Database Tier:

Inbound: From app SG only
No internet exposure

This reduces lateral movement.

3. IAM – Identity & Access Management

Controlling Who Can Do What

IAM defines:

User permissions
Service permissions
API-level actions

Network controls traffic.

IAM controls authority.

4. IAM Policies vs Roles

Policy

A document that defines permissions.

Example permissions:

Read-only access to S3
Describe EC2 instances
Modify auto-scaling groups

Policies define what is allowed.

Role

An identity that assumes policies.

Roles are assigned to:

Applications
Instances
Services
CI/CD pipelines

Applications must use roles.

Never embed static access keys in code.

Hardcoded credentials are architectural failure.

5. Least Privilege Principle

Grant only what is necessary.

Not:

Full administrative rights
Wildcard permissions (*)

Instead:

Specific service actions
Scoped resource access
Time-bound credentials

Example of bad design:

"Action": "*",
"Resource": "*"

This maximizes blast radius.

6. Role Separation Strategy

Separate identities by function:

Human admin role
CI/CD deployment role
Application runtime role
Monitoring role

If monitoring tool is compromised, it should not have admin privileges.

Blast radius must be limited.

7. Defense in Depth

Security groups protect traffic.

IAM protects authority.

Example scenario:

If attacker gains shell access to instance:

Security group prevents external lateral movement.
IAM role limits what API calls attacker can make.

Security layers must overlap.

8. Common Misconfigurations

Allowing SSH from anywhere
Assigning AdministratorAccess to applications
Sharing IAM users across teams
Using static credentials instead of roles
Leaving default outbound open unnecessarily

Security debt accumulates silently.

9. Security Testing Exercise

Test your design:

Remove load balancer security rule temporarily.
Restrict database inbound rule incorrectly.
Attempt unauthorized API call using instance role.

Observe:

What fails?
What is denied?
What error messages appear?

Understanding denial is as important as allowing traffic.

10. Lab Assignment

Design:

Load balancer security group
App tier security group
Database security group

Create:

Application IAM role
Deployment IAM role
Monitoring IAM role

Document:

Which permissions each role has
Why each security rule exists
What would happen if rule was removed

Deliverable:

Written explanation of blast radius for each tier.

If application role is compromised, what can attacker access?

11. Production Reflection

Consider:

How would you detect excessive IAM permissions?
How would you audit unused policies?
How would you rotate credentials safely?
What happens if one IAM role is overprivileged?

Security is continuous governance.

Not one-time configuration.

Module Completion Criteria

You are ready for Module 3 when:

Security groups enforce segmentation.
IAM roles follow least privilege.
No static credentials are used.
Blast radius is minimized intentionally.
You can explain layered defense.

→ Module 3 – Load Balancing & Scaling