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 at a fintech company wrote a code change that skimmed $0.01 from every transaction into a personal account. They approved their own pull request, merged it, deployed it to production, and the change ran for three weeks before a separate auditor caught the anomaly. Total theft: $340,000.
The failure was not technical. The pipeline worked perfectly. The code was syntactically correct. The problem was organizational: one person controlled the entire pipeline from code to production. Write, approve, deploy, all the same individual.
Separation of duties prevents any single person from controlling a critical process end to end. The person who writes code cannot approve it. The person who initiates a payment cannot authorize it. The person who creates a database user cannot assign admin privileges. Fraud or catastrophic mistakes require collusion between multiple people, which is orders of magnitude harder than one bad actor or one tired engineer.
This is not about distrust. It is about designing systems where the structure itself prevents single-point failures in human judgment.
| Process | Without SoD | With SoD |
|---|---|---|
| Code deployment | Developer writes, reviews, and deploys | Developer writes. Peer reviews. Automated pipeline deploys. |
| Financial transfer | One person initiates and approves | Initiator creates. Approver authorizes. System executes. |
| User provisioning | Admin creates account and assigns permissions | HR requests. Admin creates. Security team approves permissions. |
| Database migration | Developer writes and executes DDL | Developer writes migration. DBA reviews. Automated tooling runs it. |
| Certificate management | One person generates and installs certificates | Requester generates CSR. Security team approves. Automation installs. |
| Production access | One person grants themselves access | Engineer requests via JIT workflow. Manager approves. System grants with . |
Git branch protection rules are the most common SoD implementation in software: require at least one approval from someone other than the PR author. GitHub, GitLab, and Bitbucket all enforce this at the platform level.
pipelines enforce SoD by removing the manual deploy button entirely. Code that passes review and automated tests is deployed by the pipeline, not by a human. No engineer has kubectl apply access to production. Stripe, Google, and Meta all operate this way.
Dual authorization (dual control) for sensitive operations: changing billing configuration, deleting production data, rotating root credentials. Two authorized people must approve independently before the operation executes.