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 developer got temporary production database access to debug an urgent incident at 2 AM. The on-call manager granted it manually through the admin panel. It was supposed to last one hour. The manager fell asleep after the incident was resolved and forgot to revoke it.
Three months later, that developer, now on a completely different team, still had direct production database access. Nobody noticed until a routine SOC 2 audit flagged it. The auditor found 47 other "temporary" access grants that had never been revoked, some dating back over a year.
Time-based access control makes permissions inherently temporary. Every grant has a start time, an end time, and automatic expiration. When the window closes, access is revoked without any human remembering to do it. The grant simply stops existing.
| Pattern | How It Works | Use Case |
|---|---|---|
| Business hours only | Access restricted to 9 AM - 6 PM in the user's local time zone | Customer data access by support staff |
| Maintenance windows | Access granted only during scheduled change windows | Database migration permissions |
| Just-in-time (JIT) | Access granted on request, auto-expires after N hours | Emergency production access |
| Temporary elevation | Higher privileges for a fixed duration, then reverted | Deployer access for a single release |
| Recurring schedules | Access active on specific days/times on a weekly cycle | Weekend on-call rotation permissions |
JIT access is the gold standard for sensitive systems. Instead of permanent production access for 50 engineers (most of whom rarely need it), nobody has standing access. When an incident occurs, the engineer requests access through a workflow. Access is granted for 2 hours. When the timer expires, credentials are rotated and access disappears.
Google's internal BeyondProd system works this way. No standing privileges to production. Every access request is logged with a justification, approved by a peer or manager, time-bounded, and automatically revoked. The audit trail is complete by design.
HashiCorp Vault implements this pattern for secrets: vault write aws/creds/my-role ttl=1h generates temporary AWS credentials that self-destruct after one hour.