Lucent Owl logo Lucent Owl

Security Diagrams

Last updated:

4 related guides
diagrams envelope-encryption architecture-diagrams

Envelope Encryption

Flow

A data key wrapped by a KMS key, stored with the ciphertext.

Envelope encryption with a key management service An application asks the key management service for a new data encryption key and receives it twice: in plaintext and wrapped under a key encryption key that never leaves the service. The application encrypts the data locally with the plaintext data key, discards it, and stores the ciphertext together with the wrapped data key. To decrypt, the application sends only the small wrapped key to the service, which unwraps it if the caller is authorized. A stolen database therefore holds only ciphertext and wrapped keys, and revoking the application's permission on the key encryption key makes every data key unusable. Application encrypts data locally with the plaintext DEK (AES-GCM) discards the plaintext DEK once the data is encrypted holds no long-lived key KEY MANAGEMENT SERVICE Key encryption key (KEK) HSM-backed, never leaves the service wraps and unwraps DEKs every use authorized by identity and logged 1 request a new DEK 2 plaintext + wrapped DEK decrypt: send wrapped DEK plaintext DEK back STORAGE Stored record ciphertext, nonce, and tag wrapped DEK and KEK identifier unreadable without a call to the KMS 3 store ciphertext + wrapped DEK What each theft yields database backup: ciphertext and wrapped DEKs only application config: no key to steal KMS permission revoked: every DEK it protects is unusable encrypt path decrypt path

OIDC Authorization Code Flow with PKCE

C4 · Dynamic

Seven steps from redirect to API call, front channel and back.

OpenID Connect authorization code flow with PKCE Four participants: the user's browser, the client application, the identity provider, and an API. The client generates a random code verifier and redirects the browser to the identity provider with a hash of it, the code challenge. The user authenticates at the identity provider, which redirects the browser back to the client with a short-lived one-time authorization code. The client then calls the identity provider's token endpoint directly, sending the code and the original code verifier. The identity provider checks that the verifier hashes to the challenge before returning an ID token, an access token, and a refresh token. The client calls the API with the access token, and the API validates its signature, issuer, audience, and expiry. Tokens are issued only on the direct back channel, never through the browser, and a stolen code cannot be redeemed without the verifier. Browser Client application Identity provider API create random code_verifier, code_challenge = SHA-256 of it 1 redirect to IdP with code_challenge 2 user signs in at the IdP (password, passkey, MFA) 3 redirect back with a one-time authorization code 4 code delivered to client 5 code + code_verifier does the verifier hash to the challenge from step 1? 6 ID token, access + refresh tokens 7 call API with access token validate signature, issuer, audience, expiry, scopes front channel, through the browser back channel, direct to the IdP: tokens issued here API call

Threats at Trust Boundaries

Trust boundary

An order API's trust boundaries, with a threat on each crossing.

Data flow diagram of an order API with threats at trust boundaries A customer's browser on the internet calls an order API in the application zone. The API writes to an orders database and an audit log in the data zone, sends payment requests to a third-party payment provider, and receives a payment webhook back from it. Each flow crosses a trust boundary, and each crossing carries a numbered threat: spoofed sessions and tampered prices from the browser, an over-privileged database account and missing tenant filters toward the database, card data leaking toward the payment provider, a forged payment webhook coming back, and an API that can edit its own audit trail. No threat sits inside a zone; every one sits on a crossing. INTERNET Customer browser [External entity] APPLICATION ZONE Order API [Process] validates, prices, and records orders DATA ZONE Orders database [Data store] Audit log [Data store] THIRD PARTY Payment provider [External entity] 1 2 3 4 5 1 Spoofing, tampering stolen session, edited price: authenticate every request, recompute totals 2 Elevation, disclosure API connects as database owner, skips tenant filter: least-privilege account 3 Information disclosure card data passes through and is logged: provider-hosted form, tokens only 4 Spoofing forged "payment succeeded" webhook: verify the provider's signature 5 Repudiation, tampering API can rewrite its own audit trail: append-only log store trust boundary threat at a boundary crossing

Zero Trust Policy Decision and Enforcement

Flow

One request decided in the control plane, enforced in the data plane.

Zero trust policy decision and enforcement points A user and device make a request that reaches a policy enforcement point in the data plane. The enforcement point asks the control plane, where a policy engine evaluates identity, device posture, resource sensitivity, and risk signals, and a policy administrator turns that verdict into a session instruction sent back to the enforcement point. Only then does traffic reach the one resource that was requested. The session grants no path to any other resource, and the next request is evaluated again from scratch. SIGNALS identity and authentication device posture and compliance resource sensitivity behavior and threat intelligence time, location, and network CONTROL PLANE Policy engine evaluates policy against the signals and returns grant, deny, or revoke Policy administrator turns the verdict into a session instruction, and can end the session User and device untrusted wherever they connect from DATA PLANE Enforcement point in the path of every single request Resource one application, API, or dataset 1 request 2 evaluate this request 3 allow this one session 4 The session reaches this resource only. Anything else the user asks for goes back through step 2, and a change in posture or risk lets the policy administrator end a session that is already running. traffic policy decision

Found this useful? Share it:

Share on LinkedIn