Security architecture
Most security work happens in code reviews, patches and configuration. But some of it can only be decided at the architecture level: where the trust boundaries are, how services prove who they are, what a compromised component can reach, and how you know the software you run is the software you built. Get those wrong and no amount of careful code saves you; get them right and a breach of one part stays a breach of one part.
1. The idea
| Principle | What it means for the architecture |
|---|---|
| Assume breach | Design as if one component is already compromised; limit what it can reach (blast radius). |
| Zero trust | No implicit trust from network location: every request is authenticated and authorised, service to service included (NIST SP 800-207; Google's BeyondCorp). |
| Least privilege | Each service, person and pipeline gets only the permissions its job needs, ideally short-lived. |
| Defence in depth | Several independent controls, so one failure isn't a breach. |
| Secure by default | The easy path (templates, platform defaults) is the secure one. |
Identity is the new perimeter
People authenticate through a central identity provider (OpenID Connect, single sign-on, multi-factor). Services need identities too: each workload gets a cryptographic identity (for example SPIFFE IDs issued as short-lived certificates), proves it with mutual TLS, and the receiving service checks a policy saying which callers may do what. Network location stops being evidence of anything.
The software supply chain
Most of the code you run, you didn't write. Architecture-level controls: build in a trusted pipeline, sign artifacts and verify signatures before deployment, keep a software bill of materials (SBOM), pin and scan dependencies. SLSA describes levels of assurance for how an artifact was built.
Protecting data
Classify data (public, internal, confidential, regulated) and let the class drive the controls: encryption in transit everywhere and at rest; keys in a key management service, rotated; tokenisation so most services handle a token, not a card number; and the fewest copies possible, because every copy is another place to secure and delete from.
Threat modelling (STRIDE, data-flow diagrams and trust boundaries) is covered in Module 26; this module is about the structures that make the threats you find hard to exploit.
2. How it works
Perimeter trust vs zero trust, after a breach
An attacker gets code running in the image-upload service through a vulnerable library. Watch what they can do in each architecture.
3. Try it yourself
Shrink the blast radius
The same breach: the attacker controls the upload service. Switch on controls and see which assets they can still reach.
A simplified model: each asset needs both a network path and a valid permission. Real systems have more paths (bugs in the other services, people, backups).
4. Trade-offs
Security vs developer speed
Every check adds friction. Make secure paths the paved road (templates, platform-issued identities, a secrets service) so teams get security by default rather than by effort.
Fine-grained vs manageable
Per-service identities and policies give tight control and thousands of rules to maintain. Express policy as code, review it like code, and test it with fitness functions.
Central vs distributed control
A central identity provider and policy engine give consistency; they're also critical dependencies. Cache decisions and design for their failure.
Logging vs privacy
Security investigations need detailed logs; logs full of personal data become a breach of their own. Log identities and actions, not payloads.
5. In real projects
Draw the trust boundaries on the architecture diagram: where untrusted input enters, where privilege changes, where data leaves. Every arrow crossing one needs authentication, authorisation and validation.
Make security a characteristic with fitness functions: dependency scans that block builds with known critical vulnerabilities, checks that every service has a policy, that no secret appears in code, that buckets aren't public (Module 26).
Short-lived credentials beat rotation schedules. A database password in an environment variable lives for years; a credential issued for an hour by a secrets service expires before it's worth stealing.
Plan the bad day: who is told, how keys are revoked, how a compromised service is isolated, and how you'll know what was accessed (audit logs that the attacker can't edit).
Regulations shape the architecture: where personal data may be stored, how long it's kept, and the right to deletion often decide data placement and the number of copies (see case study C12).
Say it in the interview
- "How do you secure service-to-service calls?" Each workload has its own short-lived identity, calls use mutual TLS, and the receiving service checks a policy of which callers may do what; the network isn't trusted.
- "One service is compromised. What then?" The design assumed it: segmentation, least-privilege identities and short-lived secrets limit what it can reach, egress controls limit what it can send out, and audit logs show what it touched.
- "How do you trust your dependencies?" Build in a trusted pipeline, sign and verify artifacts, keep an SBOM and scan it continuously, and pin versions.
- "It's on the internal network, so it doesn't need authentication."
- One shared database user or cloud role for every service.
- Long-lived secrets in environment variables or code.
6. Remember it
How this hook works: what "badge at every door" means
What the slogan means, phrase by phrase
- "Badge"
- A verifiable identity for every person and every workload, short-lived and hard to forge.
- "at every door"
- Authorisation at each service and resource, not once at the edge; each door opens only for the jobs that need it.
Why this picture fits: a stolen badge in an office building opens a few doors and leaves a trail; a breached castle gate opens everything.
The story → the concept
| The office building | Security architecture |
|---|---|
| Badges that expire | Short-lived workload identities and credentials |
| Doors that check the badge | mTLS plus per-service authorisation policy |
| Floors you can't enter | Network segmentation and least privilege |
| The entry log | Tamper-resistant audit logs |
| Checked deliveries | Signed, verified build artifacts |
The trap it saves you from
A strong perimeter and a soft interior, where one breached service reads every database.
7. Common mistakes
8. Design exercise (30 minutes)
- Trust boundaries (10 min). Draw a system you know and mark every place untrusted input enters or privilege changes.
- Blast radius (10 min). Pick one service and list everything it could reach if compromised today. Which control would cut the list most?
- Fitness functions (10 min). Write three automated checks that would catch the drift you fear most (public buckets, missing policies, secrets in code).
9. Self-check quiz
What is the core idea of zero trust?
What most limits the damage when one service is compromised?
What does mutual TLS add between services?
How do you know production runs the code you built?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| NIST SP 800-207: Zero Trust Architecture | 2 h | The reference definition of zero trust and its components. |
| BeyondCorp (Google) | 30 min | How one company removed the trusted network. |
| Threat Modeling Manifesto and OWASP threat modelling | 30 min | How and when to threat-model. |
| SPIFFE | reference | A standard for workload identities. |
| SLSA | 45 min | Levels of supply-chain assurance for build artifacts. |
| OWASP Top 10 | 30 min | The most common web application risks. |