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 cloud platform organized resources in a hierarchy: Organization > Department > Project > Resources. An admin granted broad permissions at the Organization level, intending them only for the top-level dashboard. Permissions inherited downward. Every project, every database, every storage bucket under that organization inherited the admin grant. An intern in the marketing department could delete production databases in the engineering department because the permission cascaded through the entire tree.
The team discovered the problem during a compliance audit. Fixing it required reviewing every resource in the hierarchy, adding explicit deny rules at sensitive levels, and retraining every admin on the principle of narrowest scope. The whole exercise took two weeks of engineering time.
Permission inheritance is powerful because it eliminates repetition. Set a permission once at a high level and it applies to everything underneath. But that same power makes it dangerous. A single overly broad grant at the wrong level propagates to every child resource below it.
| Model | Behavior | Example |
|---|---|---|
| Additive | Child inherits all parent permissions, can only add more | Google Cloud IAM |
| Override | Child can override parent permissions with explicit deny rules | AWS IAM |
| Blocking | Child can block inheritance entirely, starting from a clean slate | Windows NTFS |
Google Cloud IAM hierarchy in practice:
Organization (billing-admin granted here)
Folder: Engineering
Project: payment-service (inherits billing-admin)
Cloud SQL instance (inherits billing-admin)
The billing-admin role was intended for organizational-level billing reports. It inherited all the way down to a production database. In GCP's additive model, you cannot remove that permission at a lower level. You must restructure: move the grant to a narrower scope or restructure the folder hierarchy.
AWS IAM uses override logic. An explicit deny at any level beats an allow at any level. This is your safety valve. You can grant broad read access at the organizational level and deny access to sensitive resources at the resource level. The deny always wins.
The principle: Grant permissions at the narrowest scope possible. If a developer needs access to one project, grant it at the project level. Not the folder. Not the organization.