Unit 7.2 · about 4 h
284 / 324Identity, authorization, least privilege and secrets
The threat model names who may cross each boundary. This unit builds the gates: identities for every caller including services, least-privilege defaults, and secrets handling that the password-manager story warns about.
- explain
You can now
- Separate identity, authentication and authorization, and place each check in a layered service call.
- Apply least privilege with small functional APIs, scoped credentials and breakglass, and state the audit cost of each exception.
- Describe secret rotation and key-lifecycle vocabulary, and say where process or container isolation stops protecting secrets.
Covers
- Identity, authentication and authorization
- Least privilege, scoped credentials and secure defaults
- Secrets, rotation, encryption and key-lifecycle vocabulary
Study, in this order
4 steps
- Least privilege, risk-ranked access and breakglassBuilding Secure and Reliable Systems - selected design route
Chapter 5, Design for Least Privilege: Concepts and Terminology (Least Privilege, Zero Trust Networking, Zero Touch); Classifying Access Based on Risk; Best Practices (Small Functional APIs, Breakglass, Auditing); A Policy Framework for Authentication and Authorization Decisions
- Identities, authentication, access control and boundariesBuilding Secure and Reliable Systems - selected design route
Chapter 6, Design for Understandability: Understandable Identities, Authentication, and Access Control (Identities; Authentication and transport security; Access control); Security Boundaries (Small TCBs and strong security boundaries)
- Authentication, access control and cryptography vocabularyOSTEP - introductory security chapters
Chapters 53 Intro Security, 54 Authentication, 55 Access Control and 56 Cryptography (the security chapter PDFs in the book table): credential, authorization-decision and key-lifecycle vocabulary
Depth · Use for vocabulary only. Connect process and container isolation back to the threat model and state where those boundaries do not protect the system.
- Secrets handling failure storyBuilding Secure and Reliable Systems - selected design route
Chapter 1, On Passwords and Power Drills: the HSM smart-card restart failure and the safe combination stored in the offline password manager
Focus on
- Identity covers services and hardware, not only humans: the snapshot and quota call chain in Chapter 6 needs a credential at every hop.
- Small functional APIs are the auditing advantage: breakglass sessions and direct credential handouts cannot produce granular trails.
- Credentials assert identity through a protocol (password, X.509 certificate, OAuth2 token). Authorization is a separate policy decision.
- Rotation is measured work: Chapter 8 advises measuring key rotation cycles, and Chapter 9 covers rotating signing keys under rollback.
Reproduce closed-book
Traps
- Storing the recovery secret inside the system it recovers. The safe combination lived in the offline password manager.
- Treating authentication as authorization. A valid credential identifies the caller; the policy still decides the operation.
- Assuming containers add access control. Namespaces and cgroups isolate processes and resources; they do not authenticate callers or scope credentials.
Practice
The section mini-project covers this: authenticated service boundaries, scoped credentials with expiry, and audit tests that reject over-scoped and expired credentials.
Self-test
-
A service presents a valid token for a snapshot operation it was never granted. Which check failed?
Authorization. Authentication succeeded; the policy decision for that operation is a separate step. -
Why do small functional APIs improve auditing more than any log format?
Each call is one granular action with its parameters, so the log states exactly what happened. A broad interactive session log cannot. -
An on-call engineer uses breakglass during an outage. What must happen after?
The exceptional access is audited and reviewed, and the temporary grant expires or is revoked. Breakglass is exceptional by design. -
Where do container boundaries stop helping with secrets?
At identity and access: a secret mounted into the container is visible to every process that can read it. Scoping and rotation still apply inside.
Completion criterion
Stop when
You can place every identity, credential, policy check and audit point on the call chain and defend the breakglass scope from memory.
Mark passed, then open 7.3 Only mark this when you can do it without notes.Leads to
- 7.3 Tenant isolation, input validation and injection Scope the identities and credentials per tenant and test the cross-tenant paths.
- 1.9 Namespaces, cgroups and container boundaries State where container boundaries stop protecting secrets and identities.
Comes after
- 7.1 Security goals, trust boundaries and threat modelsTurn the trust boundary into identities, scoped credentials and audit points.
Resources for this unit
- Building Secure and Reliable Systems - selected design route Read Chapters 1, 2, 4-9 and 12-14: adversaries, trade-offs, least privilege, understandability, changing landscapes, resilience, recovery, code, tests and deployment. Apply the chapter questions to the same RPC, store, tenant and migration boundary.
- OSTEP - introductory security chapters Use Chapters 53-56 for introductory security, authentication, access control and cryptography vocabulary. Connect process and container isolation to the threat model and state where those boundaries do not protect the system.
Also in this section
- OpenDP theory - one bounded privacy mechanism Read A Framework to Understand DP and Differential Privacy with OpenDP (in the 0.16.0 user guide, Framework API), then Accuracy: Pitfalls and Edge Cases and the Differencing, Membership and Reconstruction attack notebooks. Define one privacy unit, clamp an aggregate, add calibrated noise, record \(\epsilon\) and \(\delta\) inputs, measure utility and list everything outside the guarantee.
- OWASP Threat Modeling Cheat Sheet Model trust boundaries, data flows, data stores, processes and external entities, and list the assets they carry. Write misuse cases for unauthorized mutation, cross-tenant reads, stale credentials, sensitive logs and restore or migration paths, then turn each into a test or explicit residual risk.
- Systems Foundations Checkpoint - security and privacy slice Use only the tenant-access, privacy aggregate, abuse, migration, backup and residual-risk requirements as the final assessment. A toy privacy mechanism is evidence for its stated aggregate, not a claim that the service or model is private.
- Data Privacy and Security (MIT Data-Centric AI) Read the threat-model examples, shadow-training and metrics-based membership attacks, extraction by sampling plus perplexity ranking, empirical-defense evaluation, and the \((\epsilon, \delta)\) definition with DP-SGD.
- A Survey of Privacy Attacks in Machine Learning Use the attack taxonomy and threat model (adversarial knowledge, assets under attack) plus the causes of leaks and the defenses overview; skip the per-paper catalog.
- Targeted Backdoor Attacks on Deep Learning Systems Using Data Poisoning Read the weak threat model (no model or training-set knowledge, about 50 poisoning samples) and the reported result of above 90 percent attack success; skip the optimization details.
- OWASP Input Validation Cheat Sheet Apply allowlist validation, parse-safely-then-validate, structured-data rules, and the common pitfalls (client-only checks, trusted internal sources, denylisting, logging rejected input).
- OWASP Deserialization Cheat Sheet Apply the Python clear-box rules (
pickle, unsafe YAML loaders,jsonpickle) and the language-agnostic methods (pure-data formats, signed data).