We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A data pipeline needed to read from one S3 bucket. The developer, under deadline pressure, attached the AdministratorAccess policy to the service account. Full access to every AWS service, every resource, in every region. The pipeline worked. Ship it.
Six months later, the access key leaked in a misconfigured log. The attacker used it to spin up cryptocurrency miners across three regions, create new IAM users with their own admin access, and exfiltrate data from unrelated S3 buckets. The damage: $47,000 in compute charges and a data breach affecting 200,000 customer records. The incident response took three weeks.
If the service account had only s3:GetObject on that one bucket, the leaked key would have been nearly useless. The attacker could read files from one bucket. Bad, but containable. Instead, they had the keys to every resource in the account.
Least privilege means every user, service, and process gets exactly the permissions it needs and nothing more. It is the single most effective way to limit what an attacker can do after they get in, because they will get in eventually.
| Layer | Overly Permissive | Least Privilege |
|---|---|---|
| IAM users | Standing admin access for "convenience" | No standing admin. Request elevation via JIT when needed. |
| Service accounts | s3:* on * | s3:GetObject on arn:aws:s3:::data-pipeline-bucket/* |
| Database | App connects as postgres superuser | App connects as app_reader with SELECT on 3 tables |
| API keys | Full API access key shared across services | Per-service keys scoped to specific endpoints |
| Network | Default security group: allow all inbound | Allow only port 443 from the CIDR |
| Containers | Run as root, all Linux capabilities | USER nonroot, drop: [ALL], add only needed caps |
cluster-admin ClusterRoleBinding for the app pod | Namespace-scoped Role with specific verbs on specific resources |
AWS IAM Access Analyzer can scan your existing policies and flag permissions that are granted but never used. It identified unused permissions in 95% of accounts scanned, according to AWS re:Invent 2023 data. Google Cloud has a similar Recommender that suggests removing unused IAM bindings.