🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🔐 धडा 14 — Design मधूनच security: प्रत्येक box साठी सहा प्रश्न

📍 तुम्ही इथे आहात: 18 पैकी धडा 14 · पुढील: lesson-15-observability

📦 या ब्रँचमध्ये काय आहे

धडे 01–13, आणि प्रत्येक box साठी दुसरा प्रश्न: कोणी त्याचा गैरवापर कसा करू शकेल? तुम्ही शिकता प्रत्येक box ला विचारलेला STRIDE, authentication vs authorization, प्रत्येक object साठी authorization, transit आणि at rest मधील encryption, secrets, least privilege, आणि abuse cases. Identity आणि permission च्या तपशिलांसाठी IAM शाळा पाहा.

design/designs.py — STRIDE आणि stride(component)
design/demo.py — python3 design/demo.py security
design/test_design.py — check L14

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

दीपिका पुन्हा आकृती घेते. या वेळी ती ऐश्वर्याला सहा प्रश्नांचे एक कार्ड देते. ऐश्वर्याने भिंतीवरील प्रत्येक box ला सहाही प्रश्न विचारायचे आहेत.

🎭 खरोखर कोण विचारत आहे? कोणी शिक्षिका असल्याचे सोंग घेऊ शकेल का?
✏️ कोणी ते बदलू शकेल का? वाटेत, किंवा नोंदवहीत?
🙈 कोणी "मी ते केलेच नाही" असे म्हणू शकेल का? त्यांना पुसता न येणारी नोंद आहे का?
👀 ते कोण वाचू शकते? एखादा पालक दुसऱ्या वर्गाच्या सूचना वाचू शकेल का?
🌊 कोणी त्यावर लोंढा आणू शकेल का? (धडा 12 मधील token ची बरणी.)
👑 कोणी मुख्याध्यापिका बनू शकेल का? एखाद्या पालकाला शिक्षिकेचे अधिकार मिळू शकतील का?

मग कतरिना खलनायिकेची भूमिका करते. "मी एका शिक्षिकेचा password चोरते. मी प्रत्येक शाळेला एक तातडीची सूचना post करते: उद्या शाळा बंद. पन्नास लाख SMS जातात." खोली शांत होते. म्हणून योजनेत नव्या ओळी येतात: शिक्षिका दुसऱ्या factor सह login करतात; एकापेक्षा जास्त शाळांना जाणाऱ्या तातडीच्या सूचनेला मंजुरीसाठी दुसरी व्यक्ती लागते; तातडीच्या सूचनांना दिवसाची मर्यादा असते; प्रत्येक post कोणालाच edit करता न येणाऱ्या log मध्ये लिहिली जाते.

🗺️ आकृती

flowchart LR
    p["📱 parent app"] -->|"TLS"| gw["🚪 API gateway<br/>authn: who are you?"]
    gw --> api["🧩 notice API<br/>authz per object:<br/>is 3A your class?"]
    api -->|"TLS"| db[("🗄️ notices DB<br/>encrypted at rest")]
    api --> sec["🔒 secrets vault"]
    api --> q["📬 SMS queue"] --> w["📤 SMS worker<br/>least privilege"]
    api --> log["📜 audit log<br/>append-only"]
    st["🃏 STRIDE per box:<br/>Spoofing · Tampering · Repudiation<br/>Info disclosure · DoS · Elevation"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l14

❓ काय

STRIDE — धोक्यांचे सहा प्रकार, प्रत्येकी एक प्रश्न: Spoofing (identity), Tampering (integrity), Repudiation (पुरावा), Information disclosure (गोपनीयता), Denial of service (availability), Elevation of privilege (authorization). प्रत्येक box आणि प्रत्येक बाणाला सहाही प्रश्न विचारा. उत्तरे requirements बनतात.
Authentication (authn) — तुम्ही कोण आहात? Login, token (OIDC / JWT), service-to-service calls साठी client certificate (mTLS). अपयशी झाल्यास 401 उत्तर द्या.
Authorization (authz) — तुम्ही काय करू शकता? शिक्षिका की पालक, कोणते वर्ग. अपयशी झाल्यास 403 उत्तर द्या.
प्रत्येक object साठी authorization — प्रत्येक request वर नेमका object तपासा: "वर्ग 3A हा या पालकाच्या वर्गांपैकी एक आहे का?" फक्त "हा login केलेला पालक आहे का?" एवढेच तपासले तर कोणताही पालक URL मधील id बदलून कोणताही वर्ग वाचू शकतो. ही सर्वात सामान्य API कमजोरी आहे (OWASP API1: Broken Object Level Authorization).
Transit मधील encryption — प्रत्येक बाणावर TLS, network च्या आतही.
At rest encryption — disks, backups, snapshots आणि object storage, key service (KMS) मधील keys ने encrypt केलेले. फोन नंबर आणि मुलांची नावे वैयक्तिक data (PII) आहे.
Secrets — database passwords आणि API keys vault मध्ये राहतात (Secrets Manager, Vault), rotate केल्या जातात, आणि code, images किंवा logs मध्ये कधीच दिसत नाहीत.
Least privilege — प्रत्येक box ला फक्त त्याला लागणाऱ्या permissions मिळतात. SMS worker एकच queue वाचू शकतो; तो notices database वाचू शकत नाही.
Abuse cases — user stories शेजारी "गैरवापराच्या कथा": चोरलेले शिक्षिका-account, फोन नंबर गोळा करणारा scraper, class ids चा अंदाज लावणारा पालक, accounts तयार करणारा bot, paid numbers ना messages पाठवणारी SMS फसवणूक. प्रत्येक abuse case ला एक control मिळतो.

🤔 का

कारण design नंतर जोडलेली security म्हणजे ठिगळांचा संच, आणि design मध्येच असलेली security म्हणजे boxes आणि नियमांचा संच ज्यानुसार सगळे बांधतात. सूचना फलकात मुलांची नावे आणि पालकांचे फोन नंबर असतात, आणि तो लाखो SMS पाठवू शकतो. या दोन गोष्टींमुळे त्यावर हल्ला करणे फायद्याचे ठरते. योजनेवर प्रत्येक box ला सहा प्रश्न विचारायला एक तास लागतो; leak नंतर उत्तर शोधायला महिने लागतात.

🔧 कसे (या repo मध्ये)

design/designs.py मधील STRIDE प्रत्येक धोक्याला त्याचा प्रश्न आणि नेहमीचे controls जोडतो. stride(component) एका box साठी सहा (threat, question) rows परत करतो. design/demo.py मधील security() ते notice API ला विचारतो. Snippet सहा boxes साठी पूर्ण कागद तयार करतो आणि inline लिहिलेली एक छोटी प्रति-object authorization तपासणी जोडतो.

🧪 करून पाहा

python3 design/demo.py security
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from designs import stride
boxes = ["mobile app", "API gateway", "notice API", "notices DB", "SMS queue", "SMS worker"]
sheet = [row for b in boxes for row in stride(b)]
print(len(boxes), "boxes ×", len(stride("x")), "threats →", len(sheet), "questions on the sheet")
for threat, q in stride("SMS worker")[3:5]: print(f"{threat:<24} {q}")
parent_classes = {"aishwarya": {"3A"}, "katrina": {"5B"}}
def can_read(user, class_id): return class_id in parent_classes.get(user, set())
for user, cls in (("aishwarya", "3A"), ("aishwarya", "5B"), ("stranger", "3A")):
    print(f"GET /classes/{cls}/notices as {user:<9} → {'200' if can_read(user, cls) else '403' if user in parent_classes else '401'}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

security हे छापतो:

── STRIDE, asked of every box on the diagram (here: the notice API)
   Spoofing                 notice API: who is really calling? → authentication (OIDC, mTLS, signed requests)
   Tampering                notice API: was it changed on the way or at rest? → TLS, signatures, checksums, least-privilege writes
   Repudiation              notice API: can someone deny doing it? → audit logs they cannot edit (CloudTrail, append-only)
   Information disclosure   notice API: who can read it? → encryption, authorization per object, no secrets in logs
   Denial of service        notice API: can it be flooded? → rate limits, WAF, quotas, autoscaling with a ceiling
   Elevation of privilege   notice API: can a user become an admin? → least privilege, input validation, isolation
   plus: parents see only their children's classes (authorization per object), PII encrypted, secrets in a vault

तुमचा snippet हे छापतो:

6 boxes × 6 threats → 36 questions on the sheet
Information disclosure   SMS worker: who can read it? → encryption, authorization per object, no secrets in logs
Denial of service        SMS worker: can it be flooded? → rate limits, WAF, quotas, autoscaling with a ceiling
GET /classes/3A/notices as aishwarya → 200
GET /classes/5B/notices as aishwarya → 403
GET /classes/3A/notices as stranger  → 401

Tests मध्ये ✅ L14 STRIDE covers six threats असते.

🏁 तुम्ही आत्ताच काय सिद्ध केले

सहा boxes च्या छोट्या design मध्येच security चे 36 प्रश्न आहेत — म्हणूनच कार्यालय आठवणीवर नाही तर checklist वर अवलंबून राहते. तेच सहा प्रश्न प्रत्येक box साठी वेगवेगळी उत्तरे देतात: SMS worker साठी "information disclosure" म्हणजे त्याच्या logs मधील फोन नंबर, आणि "denial of service" म्हणजे कोणीतरी त्याची queue भरून टाकणे. आणि प्रत्येक object साठी authorization एकाच URL ला तीन वेगवेगळी उत्तरे देते: ऐश्वर्याच्या स्वतःच्या वर्गासाठी 200, तिचा नसलेल्या वर्गासाठी 403, login न केलेल्या व्यक्तीसाठी 401.

⚠️ नेहमीच्या चुका

"login केले आहे का" तपासणे पण "हा object तुमचा आहे का" न तपासणे — कोणताही पालक कोणताही वर्ग वाचतो
client ने पाठवलेल्या ids, roles किंवा किमतींवर विश्वास ठेवणे
git मध्ये commit केलेल्या environment files मध्ये, container images मध्ये, किंवा logs मध्ये छापलेले secrets
"चालावे म्हणून" प्रत्येक service साठी "*" असलेला एकच IAM role
फक्त edge वर TLS, network च्या आत साधे HTTP
admin कृतींसाठी audit log नाही — incident नंतर कोणी काय केले हे कोणीच सांगू शकत नाही
फक्त "happy path" user stories — abuse cases नाहीत, म्हणून खर्चिक कृतींवर कोणत्याही मर्यादा नाहीत

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — PostgreSQL row-level security वापरून database मध्येच प्रत्येक object साठी authorization. WHERE विसरलेली query सुद्धा फक्त त्या पालकाचेच वर्ग परत करते:

ALTER TABLE notices ENABLE ROW LEVEL SECURITY;
CREATE POLICY parent_reads_own_classes ON notices FOR SELECT
  USING (class_id IN (SELECT class_id FROM parent_classes
                      WHERE parent_id = current_setting('app.parent_id')::bigint));
-- the API sets the caller for each transaction:
SET LOCAL app.parent_id = '42';

SMS worker साठी least privilege — तो एकाच queue मधून messages घेऊ शकतो, बाकी काहीच नाही:

{ "Version": "2012-10-17",
  "Statement": [{ "Effect": "Allow",
    "Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"],
    "Resource": "arn:aws:sqs:ap-south-1:111122223333:urgent-sms" }] }

Secrets start-up वेळी vault मधून, code मधून कधीच नाही:

aws secretsmanager get-secret-value --secret-id notice-board/db --query SecretString --output text
aws secretsmanager rotate-secret --secret-id notice-board/db --rotation-rules AutomaticallyAfterDays=30

Database आणि files bucket साठी at rest encryption:

aws rds create-db-instance --db-instance-identifier notices-db --engine postgres \
    --db-instance-class db.m7g.large --allocated-storage 100 \
    --master-username app --manage-master-user-password \
    --storage-encrypted --kms-key-id alias/notice-board
aws s3api put-bucket-encryption --bucket notice-board-files \
    --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/notice-board"}}]}'

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: STRIDE कागद repo मध्ये design शेजारी ठेवा, प्रत्येक box साठी एक row, आणि नवा box जोडला की त्याचा आढावा घ्या. Roles, policies, federation आणि permission boundaries साठी पुढे IAM शाळा मध्ये चला.

⏭️ पुढे

काय अपयशी होते आणि कशावर हल्ला होतो हे आता योजना सांगते. पण launch नंतर app निरोगी आहे हे कार्यालयाला कसे कळेल? Design मधूनच observability.

git checkout lesson-15-observability

🔐 Lesson 14 — Security by design: six questions for every box

📍 You are here: Lesson 14 of 18 · Next: lesson-15-observability

📦 What's in this branch

Lessons 01–13, plus the second question for every box: how could someone misuse it? You learn STRIDE asked per box, authentication vs authorization, authorization per object, encryption in transit and at rest, secrets, least privilege, and abuse cases. For the identity and permission details, go to the IAM school.

design/designs.py — STRIDE and stride(component)
design/demo.py — python3 design/demo.py security
design/test_design.py — check L14

🧒 Explain like I'm 5

Dipika takes the drawing again. This time she gives Aishwarya a card with six questions. Aishwarya must ask all six of every box on the wall.

🎭 Who is really asking? Could someone pretend to be a teacher?
✏️ Could someone change it? On the way, or in the book?
🙈 Could someone say "I never did that"? Is there a record they cannot erase?
👀 Who can read it? Could a parent read another class's notices?
🌊 Could someone flood it? (Lesson 12's token jar.)
👑 Could someone become the head teacher? Could a parent get teacher powers?

Then Katrina plays the bad actor. "I steal a teacher's password. I post an urgent notice to every school: school closed tomorrow. Five million SMS go out." The room is quiet. So the plan gets new lines: teachers log in with a second factor; an urgent notice to more than one school needs a second person to approve it; urgent notices have a limit per day; every post is written in a log nobody can edit.

🗺️ Diagram

flowchart LR
    p["📱 parent app"] -->|"TLS"| gw["🚪 API gateway<br/>authn: who are you?"]
    gw --> api["🧩 notice API<br/>authz per object:<br/>is 3A your class?"]
    api -->|"TLS"| db[("🗄️ notices DB<br/>encrypted at rest")]
    api --> sec["🔒 secrets vault"]
    api --> q["📬 SMS queue"] --> w["📤 SMS worker<br/>least privilege"]
    api --> log["📜 audit log<br/>append-only"]
    st["🃏 STRIDE per box:<br/>Spoofing · Tampering · Repudiation<br/>Info disclosure · DoS · Elevation"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l14

❓ What

STRIDE — six kinds of threat, one question each: Spoofing (identity), Tampering (integrity), Repudiation (proof), Information disclosure (confidentiality), Denial of service (availability), Elevation of privilege (authorization). Ask all six of each box and each arrow. The answers become requirements.
Authentication (authn) — who are you? A login, a token (OIDC / JWT), a client certificate (mTLS) for service-to-service calls. Answer with 401 when it fails.
Authorization (authz) — what may you do? Teacher or parent, which classes. Answer with 403 when it fails.
Authorization per object — check the specific object on every request: "is class 3A one of this parent's classes?" Checking only "is this a logged-in parent?" lets any parent read any class by changing the id in the URL. This is the most common API weakness (OWASP API1: Broken Object Level Authorization).
Encryption in transit — TLS on every arrow, inside the network too.
Encryption at rest — disks, backups, snapshots and object storage encrypted with keys in a key service (KMS). Phone numbers and children's names are personal data (PII).
Secrets — database passwords and API keys live in a vault (Secrets Manager, Vault), are rotated, and never appear in code, images or logs.
Least privilege — each box gets only the permissions it needs. The SMS worker may read one queue; it may not read the notices database.
Abuse cases — "misuse stories" next to user stories: a stolen teacher account, a scraper collecting phone numbers, a parent guessing class ids, a bot creating accounts, SMS fraud that sends messages to paid numbers. Each abuse case gets a control.

🤔 Why

Because security added after the design is a set of patches, and security in the design is a set of boxes and rules everybody builds to. The notice board holds children's names and parents' phone numbers, and it can send millions of SMS. Those two facts make it worth attacking. Asking six questions per box takes an hour on the plan; finding the answer after a leak takes months.

🔧 How (in this repo)

STRIDE in design/designs.py maps each threat to its question and typical controls. stride(component) returns six (threat, question) rows for one box. security() in design/demo.py asks them of the notice API. The snippet builds the whole sheet for six boxes and adds a tiny per-object authorization check, written inline.

🧪 Try it

python3 design/demo.py security
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from designs import stride
boxes = ["mobile app", "API gateway", "notice API", "notices DB", "SMS queue", "SMS worker"]
sheet = [row for b in boxes for row in stride(b)]
print(len(boxes), "boxes ×", len(stride("x")), "threats →", len(sheet), "questions on the sheet")
for threat, q in stride("SMS worker")[3:5]: print(f"{threat:<24} {q}")
parent_classes = {"aishwarya": {"3A"}, "katrina": {"5B"}}
def can_read(user, class_id): return class_id in parent_classes.get(user, set())
for user, cls in (("aishwarya", "3A"), ("aishwarya", "5B"), ("stranger", "3A")):
    print(f"GET /classes/{cls}/notices as {user:<9} → {'200' if can_read(user, cls) else '403' if user in parent_classes else '401'}")
EOF

✅ Verify — what you should see

security prints:

── STRIDE, asked of every box on the diagram (here: the notice API)
   Spoofing                 notice API: who is really calling? → authentication (OIDC, mTLS, signed requests)
   Tampering                notice API: was it changed on the way or at rest? → TLS, signatures, checksums, least-privilege writes
   Repudiation              notice API: can someone deny doing it? → audit logs they cannot edit (CloudTrail, append-only)
   Information disclosure   notice API: who can read it? → encryption, authorization per object, no secrets in logs
   Denial of service        notice API: can it be flooded? → rate limits, WAF, quotas, autoscaling with a ceiling
   Elevation of privilege   notice API: can a user become an admin? → least privilege, input validation, isolation
   plus: parents see only their children's classes (authorization per object), PII encrypted, secrets in a vault

Your snippet prints:

6 boxes × 6 threats → 36 questions on the sheet
Information disclosure   SMS worker: who can read it? → encryption, authorization per object, no secrets in logs
Denial of service        SMS worker: can it be flooded? → rate limits, WAF, quotas, autoscaling with a ceiling
GET /classes/3A/notices as aishwarya → 200
GET /classes/5B/notices as aishwarya → 403
GET /classes/3A/notices as stranger  → 401

The tests include ✅ L14 STRIDE covers six threats.

🏁 What you just proved

A small design with six boxes already has 36 security questions — that is why the office uses a checklist and not memory. The same six questions give different answers per box: for the SMS worker, "information disclosure" means phone numbers in its logs, and "denial of service" means someone filling its queue. And authorization per object gives three different answers for one URL: 200 for Aishwarya's own class, 403 for a class that is not hers, 401 for someone who has not logged in.

⚠️ Common mistakes

checking "is logged in" but not "is this object yours" — any parent reads any class
trusting ids, roles or prices sent by the client
secrets in environment files committed to git, in container images, or printed in logs
one IAM role with "*" for every service "to make it work"
TLS at the edge only, plain HTTP inside the network
no audit log for admin actions — after an incident, nobody can say who did what
only "happy path" user stories — no abuse cases, so no limits on the costly actions

🏭 In production

On a real account — authorization per object in the database with PostgreSQL row-level security. Even a query with a forgotten WHERE returns only the parent's classes:

ALTER TABLE notices ENABLE ROW LEVEL SECURITY;
CREATE POLICY parent_reads_own_classes ON notices FOR SELECT
  USING (class_id IN (SELECT class_id FROM parent_classes
                      WHERE parent_id = current_setting('app.parent_id')::bigint));
-- the API sets the caller for each transaction:
SET LOCAL app.parent_id = '42';

Least privilege for the SMS worker — it may take messages from one queue, nothing else:

{ "Version": "2012-10-17",
  "Statement": [{ "Effect": "Allow",
    "Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"],
    "Resource": "arn:aws:sqs:ap-south-1:111122223333:urgent-sms" }] }

Secrets from a vault at start-up, never from code:

aws secretsmanager get-secret-value --secret-id notice-board/db --query SecretString --output text
aws secretsmanager rotate-secret --secret-id notice-board/db --rotation-rules AutomaticallyAfterDays=30

Encryption at rest for the database and the files bucket:

aws rds create-db-instance --db-instance-identifier notices-db --engine postgres \
    --db-instance-class db.m7g.large --allocated-storage 100 \
    --master-username app --manage-master-user-password \
    --storage-encrypted --kms-key-id alias/notice-board
aws s3api put-bucket-encryption --bucket notice-board-files \
    --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/notice-board"}}]}'

🏭 Why this matters in production: keep the STRIDE sheet in the repo next to the design, one row per box, and review it when a box is added. For roles, policies, federation and permission boundaries, continue in the IAM school.

⏭️ Next

The plan now says what fails and what is attacked. But how will the office know that the app is healthy after launch? Observability by design.

git checkout lesson-15-observability

← Previousresilience Next →observability

This page is the lesson's README from the lesson-14-security branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.