DAY_01 / SECTION_03 // FOUNDATION
MODULE READY
Security as a foundation
You can't bolt security on later — it has to be designed in from the start. The order matters: identity (who can do what?) → network (where can traffic flow?) → audit (what happened?). It's also the order of attack.
SYS.NODE_01
ONLINE
badge
Identity
Who can do what
Least-privilege admin model · federated SSO over local accounts · roles for service access (not long-lived keys) · just-in-time elevation for sensitive ops.
// principle
default = DENY SYS.NODE_02
IDLE
lan
Network
Where traffic flows
VPC isolation per environment · private subnets for backends · security groups as fine-grained firewalls · egress control — what can leave?
// scope
vpc/subnet/sg SYS.NODE_03
STANDBY
receipt_long
Audit
What happened
Centralized logs in immutable storage · alerting on suspicious patterns · regular access reviews · the source of truth when something goes wrong.
// retention
≥ 1 year, write-once // virtual private cloud — the building block
A logical isolation of your cloud network. Same idea across providers — different names: AWS VPC · Azure VNet · GCP VPC.
inside a vpc
- — Subnets · public (internet-facing) or private
- — Route tables · where traffic goes
- — Security groups · instance-level firewalls
- — NACLs · subnet-level firewalls
- — Internet & NAT gateways · controlled egress
across vpcs
- — Peering · VPC ↔ VPC (1:1)
- — Transit gateway / hub · many ↔ many
- — VPN / Direct Connect · VPC ↔ on-prem
// identity & least privilege
The single biggest source of cloud breaches: over-permissioned credentials. The 2012-era Netflix four-account model still holds:
- — paastest — dev / testing, developer-tagged stacks for separation
- — paasprod — production, autoscale only, alert routing + backups by default
- — paasaudit — sensitive workloads (SOX, PCI), extra access controls
- — paasarchive — disaster recovery, long-term backups, ideally different region or vendor
help Knowledge Check
Question 1/1 A teammate suggests storing the AWS access key for the production deploy script in a shared vault, rotated quarterly. What's the better pattern?
// pick one to verify
// explanation Long-lived keys are the #1 source of cloud breaches even with rotation. The cloud-native pattern is short-lived credentials issued via role-assumption (IAM roles for EC2 / ECS / GitHub OIDC / etc). The CI runner gets exactly the permissions it needs, only when it's running.