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 hospital's electronic health records system needed this rule: "Doctors can view patient records, but only for patients currently assigned to them, and only during their shift hours, and only from hospital network IP ranges."
RBAC could handle the first part. Assign a "Doctor" role with "patient-records:read" permission. Done. But RBAC cannot restrict by assignment (which specific patients), time (shift hours), or location (hospital network). Those are attributes that change dynamically, not static role memberships.
The hospital tried to solve it with more roles: "ER-Doctor-DayShift", "ER-Doctor-NightShift", "Cardio-Doctor-DayShift". Role explosion hit fast. With 15 departments, 3 shifts, and 5 seniority levels, they needed 225 roles just for doctors. Each time the schedule changed, role assignments had to be updated.
ABAC evaluates all relevant attributes at the moment the request happens. One policy replaces 225 roles: "allow read on patient-records where subject.role = doctor AND resource.assigned_doctor = subject.id AND environment.time is within subject.shift_hours AND environment.ip is in hospital_network_range."
ABAC evaluates four categories of attributes:
| Category | Examples | Source |
|---|---|---|
| Subject (who) | Department, clearance level, job title, team, employment status | Identity provider, HR system |
| Resource (what) | Data classification, owner, creation date, sensitivity label | Resource metadata store |
| Action (how) | Read, write, delete, approve, export | The request itself |
| Environment (context) | Current time, IP address, device type, geographic location | Request headers, network context |
An ABAC policy reads like a sentence:
"Allow read on patient-records where subject.role = doctor AND resource.assigned_doctor = subject.id AND environment.time is within subject.shift_hours AND environment.ip is in hospital_network_range."
AWS IAM conditions are ABAC. When you write "Condition": {"IpAddress": {"aws:SourceIp": "10.0.0.0/8"}}, you are evaluating an environment attribute. When you write "Condition": {"StringEquals": {"aws:PrincipalTag/department": "${aws:ResourceTag/department}"}}, you are comparing subject and resource attributes. Every AWS IAM policy with a Condition block is ABAC.
NIST SP 800-162 defines ABAC formally and is the reference standard for government and regulated industries.