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 6-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 team of 40 used a shared file server. Each file and folder had its own list of who could read, write, or execute it. The marketing folder was readable by marketing, the engineering folder by engineering. Simple enough.
Then cross-functional projects started. A product launch required marketing, engineering, and sales to share a folder. Someone added 30 individual users to the folder's ACL. Interns rotated off the project but nobody removed them. A contractor who left six months ago still had write access.
After two years, some folders had ACLs with 80+ entries, half for people who had left the company. An auditor asked "who has access to the Q4 financial projections?" and nobody could answer without manually reading every nested ACL. The file server was technically working perfectly. The permissions were the disaster.
ACLs give you per-resource control, which is exactly what you need for shared documents, S3 buckets, and file systems. But that granularity comes at a cost: without automation and regular pruning, ACLs grow stale and become a security liability.
An ACL is a list attached to a resource that specifies which principals (users or groups) have which permissions on that specific resource.
| Resource | Principal | Permission |
|---|---|---|
| /docs/roadmap.pdf | alice@co.com | read, write |
| /docs/roadmap.pdf | bob@co.com | read |
| /docs/roadmap.pdf | engineering-group | read, write |
| /api/users | admin-role | create, read, update, delete |
| /api/users | viewer-role | read |
Linux file permissions are the simplest ACL: rwxr-xr-- means the owner can read/write/execute, the group can read and execute, everyone else can only read. POSIX ACLs extend this to arbitrary users and groups beyond the owner/group/other triple.
RBAC vs ACL, the mental model:
| Aspect | RBAC | ACL |
|---|---|---|
| Permissions live on | Users (via roles) | Resources |
| Question it answers | "What can this user do?" | "Who can access this resource?" |
| Granularity | Role-level (same access across resources) | Per-resource, per-user |
| Scale | Thousands of users, dozens of roles | Hundreds of resources with distinct sharing |
| Best for | Organizational-wide permissions | Fine-grained resource-level sharing |
In practice, most systems combine both. Google Drive is the canonical example: your organizational role (from RBAC via Google Workspace) determines default access. Each document has its own sharing list (ACL) for fine-grained exceptions. RBAC handles the 90% case. ACLs handle the edge cases.
When NOT to use ACLs: when uniform access patterns apply. If every engineer should have identical access to every repository, maintaining per-repo ACLs adds overhead with zero benefit. Use RBAC and apply it uniformly.