Part of an ongoing series walking domain by domain through the Cybersecurity Architect's Handbook, Second Edition — and the companion labs that ship with it.
If you've been following along, you know the rhythm by now. I've been working through the second edition of the Cybersecurity Architect's Handbook's "secret menu" one domain at a time — taking each of the book's concepts and pairing it with the hands-on labs that live alongside the book, then writing up what that domain is really trying to teach once you stop reading and start typing commands. We've spent time in the upper rings of the architecture: detection, prevention, monitoring, response, and the automation that ties a SOC together.
This installment moves inward. All the way inward.
There's a line I keep coming back to when I teach this material: an organization that has invested heavily in monitoring but neglected identity and encryption has built a house with excellent alarms and no locks.
Every control we design as architects ultimately serves one of two questions. Who is allowed to do what — and is the data still protected if everything else fails. Access control answers the first. Data protection answers the second. Together they form the innermost ring of a defense-in-depth architecture: the controls that still mean something after the network has been breached, the endpoint compromised, and the attacker is already inside. The outer rings buy you time and warning. This ring is what's left standing when those rings don't hold.
That's the domain at the heart of the Access Control and Data Protection — and it's also where the companion labs do some of their best work.
Two Books, One Cover Price
For anyone joining the series here, the same thing is true of this domain as every other one I've covered: the book is only half of what you get.
The printed second edition runs to nearly 700 pages. That's the framework: how to think like an architect, how identity became the new perimeter, why encryption is the control of last resort, and how to weave both into a coherent whole rather than a pile of point products.
But the companion GitHub repository carries another 700-plus pages of step-by-step, build-it-yourself lab content — material that never had to fit inside a print binding and so could go as deep as the hands-on work demanded. For this domain alone, that means standing up a working identity provider, building encrypted volumes by hand, and running a real secrets-management server through its full lifecycle.
Concepts you can read about in an afternoon. Muscle memory you can only build by typing the commands and watching the system push back.
What the Labs Actually Build
The labs in this domain are deliberately sequenced so that each one makes the next one land harder.
Keycloak — identity, end to end. The first lab stands up Keycloak 26 on Debian 13, backed by PostgreSQL rather than its throwaway embedded database, because that's how it's actually deployed. You create a realm, register an OpenID Connect client, define a role, provision a user, and then walk the full authentication flow until a token is issued — and then you crack that token open to read the claims inside. Here's the point I want every reader to internalize: a realm is a tenant, a client is an app registration, and the OIDC flows you just exercised are identical in Microsoft Entra ID, Okta, and Ping. The console changes. The protocol does not. Learn it on open source at home; apply it to whatever commercial stack your employer chose.
VeraCrypt — making encryption concrete. The second lab does something BitLocker and LUKS deliberately hide from you. Enterprise full-disk encryption tools bury their cryptographic choices behind sensible defaults — exactly right for fleet management, and exactly wrong for learning. VeraCrypt exposes the moving parts: which cipher, which hash, which key-derivation function. You build an encrypted container, mount it, write to it, dismount it, and watch plaintext become opaque ciphertext on disk. Then you build a hidden volume and discover plausible deniability — and the operational discipline it demands — in a way no amount of reading conveys. The primitives you're handling here (AES in XTS mode, a password-stretched key unwrapping a randomly generated master key) are the same primitives every enterprise encryption product manages for you behind the curtain.
HashiCorp Vault — and the idea that ties the room together. The final pair of labs installs Vault Community Edition on Debian 13 and then walks its core workflow: enable a KV v2 secrets engine, write and version a secret, author a least-privilege policy, stand up a userpass auth method, and then prove least privilege by logging in as a scoped user and watching Vault deny everything that user's policy doesn't explicitly allow — every attempt landing in a tamper-evident audit log. You'll initialize Vault, receive its Shamir unseal key shares, and unseal it by hand, which teaches the seal/unseal model better than any diagram.
And Vault is where the two halves of this domain quietly become one. Because Vault is identity-based, every request for a secret is itself an access-control decision. Encryption and access control aren't two adjacent topics here. They're the same decision, made about data instead of doors.
The Architect's-Eye Throughline
What I wanted these labs to teach isn't "how to run Keycloak" or "how to use VeraCrypt." Tools change. The patterns underneath them don't — and if you've read the earlier posts in this series, you'll recognize the move, because it's the same one every domain rewards:
- Identity is the new perimeter. When the network boundary dissolves into cloud and mobile, the access decision is the boundary. The Keycloak lab is OAuth 2.0, OIDC, and SAML 2.0 made tangible — the exact standards every commercial IAM platform is built on.
- Encryption is the control of last resort. If every other defense fails and someone walks off with the disk, the database export, or the backup tape, properly encrypted data is just noise. VeraCrypt lets you see why that's true.
- Secrets sprawl is a design failure, and least privilege is the fix. Vault replaces credentials hard-coded in source, pasted into chat, and duplicated across servers with one audited authority that issues, leases, rotates, and revokes under fine-grained policy. Dynamic, short-lived credentials shrink the window in which a leak is useful — often a stronger control than guarding the secret itself.
Every one of these maps directly onto the enterprise. Keycloak's vocabulary transfers to Entra ID and Okta. VeraCrypt's primitives underpin BitLocker and LUKS. Vault's model is the same one behind AWS Secrets Manager, Azure Key Vault, CyberArk Conjur, and the open-source OpenBao fork. You learn the protocol on tooling you can run for free, and you carry that fluency into whatever your organization standardized on.
Tested on Real Infrastructure
These aren't aspirational walkthroughs — and that, too, has been the through-line of this whole series. Every step was executed on actual Debian 13 hosts: the dependency quirks, the version notes (VeraCrypt's move to Argon2id, Vault's jump from the 1.21 line to 2.0, the occasional HashiCorp repo lag behind a fresh Debian release), the validation checklists at the end of each lab. When something breaks in the real environment, the lab tells you so and tells you why. That's the difference between reading about a control and being able to defend it in a design review.
Put Your Hands On It
If you want to actually build the innermost ring — to stand up an identity provider, watch plaintext turn to ciphertext and back, and enforce least privilege with a full audit trail — that's all waiting in the lab repository, the 700-plus pages that ship alongside the book.
Grab the Cybersecurity Architect's Handbook, Second Edition here: Amazon
And if you build something with these labs — or break it in an interesting way — I'd genuinely like to hear about it. You can find me at secdoc.tech. The series continues with the next domain soon.
