Security, Privacy & Trust Boundaries

Security architecture begins with trust boundaries. NIST’s zero-trust guidance treats implicit network trust as unsafe and emphasizes explicit, contextual access decisions. In software architecture, a trust boundary is any place where assumptions change: public internet to edge, user device to backend, service to database, internal network to vendor, tenant A to tenant B, employee to production, or application code to secrets store.

Senior architecture does not bolt security on after the structure is chosen. It asks where identity is established, where authorization decisions are made, where data changes sensitivity, where secrets live, where audit evidence is produced, where blast radius is contained, and where privacy obligations follow data. The design should make safe behavior the default path.

left to right direction
actor "User Device\nuntrusted" as Device
rectangle "Edge\nTLS, WAF, rate limits" as Edge
rectangle "Application Zone\nleast privilege services" as App
database "Data Zone\ncontrolled access" as Data
rectangle "Vendor API\nexternal trust" as Vendor
rectangle "Security Monitoring" as Monitor

Device --> Edge : public boundary
Edge --> App : authenticated request
App --> Data : authorized query
App --> Vendor : outbound policy
Edge --> Monitor : access events
App --> Monitor : audit events
Data --> Monitor : sensitive access

Threat Modeling as Design

Threat modeling is architecture analysis under adversarial conditions. It asks what assets matter, who might attack or misuse them, which boundaries they cross, what can go wrong, and what controls reduce risk. The output should influence design decisions, not merely create a compliance artifact.

Useful threat models are concrete. “An attacker steals customer data” is too broad. “A compromised support account exports all tenant records because the admin API authorizes by role only and has no tenant scoping, export rate limit, or audit alert” is designable. It points to controls: scoped authorization, just-in-time elevation, export limits, approval workflow, anomaly detection, and audit review.

rectangle "Threat Model Loop" as Loop {
rectangle "Assets\ndata, money, availability, reputation" as Assets
rectangle "Actors\nexternal attacker, insider, compromised service" as Actors
rectangle "Entry Points\nAPIs, jobs, admin tools, vendors" as Entry
rectangle "Threats\nspoof, tamper, disclose, deny, escalate" as Threats
rectangle "Controls\nprevent, detect, respond, recover" as Controls
}
Assets --> Actors
Actors --> Entry
Entry --> Threats
Threats --> Controls
Controls --> Assets : residual risk review

Identity and Authorization

Authentication answers who the caller is. Authorization answers what the caller may do in this context. Architecture failures often come from mixing these questions. A valid token does not mean the caller may access this tenant, approve this refund, read this medical record, or call this internal endpoint. Authorization needs domain context.

Centralized identity can reduce duplication, but authorization often belongs near the domain that understands the resource. A policy engine may help if policies are complex and shared, but the system still needs clear ownership of policy meaning. The contract should define subject, action, resource, environment, and decision evidence. Audit logs should capture why sensitive access was allowed, not merely that a request succeeded.

left to right direction
actor "Caller" as Caller
rectangle "Identity Provider" as IdP
rectangle "API Gateway" as Gateway
rectangle "Domain Service" as Service
rectangle "Policy Decision Point" as PDP
database "Resource State" as Resource
database "Audit Log" as Audit

Caller --> IdP : authenticate
Caller --> Gateway : token
Gateway --> Service : verified identity
Service --> PDP : subject, action, resource
PDP --> Resource : context
PDP --> Service : allow or deny
Service --> Audit : decision evidence

Secrets and Supply Chain

Secrets architecture defines how credentials, keys, tokens, certificates, and signing material are created, stored, rotated, accessed, and revoked. Secrets in source code, logs, build artifacts, or shared configuration are architectural risks because they create large blast radius. A mature design gives workloads short-lived credentials, narrow permissions, rotation paths, and observability of secret use.

Supply-chain security belongs in architecture because modern systems are assembled from dependencies, containers, CI/CD pipelines, infrastructure modules, and third-party services. The runtime boundary begins in the build pipeline. Signing, provenance, dependency scanning, artifact promotion, and environment separation are not bureaucratic extras; they protect the integrity of what reaches production.

left to right direction
rectangle "Source" as Source
rectangle "CI Pipeline" as CI
rectangle "Dependency Scan" as Scan
rectangle "Build Artifact" as Artifact
rectangle "Signature and Provenance" as Sign
rectangle "Artifact Registry" as Registry
rectangle "Production Deploy" as Deploy
rectangle "Secrets Manager" as Secrets

Source --> CI
CI --> Scan
Scan --> Artifact
Artifact --> Sign
Sign --> Registry
Registry --> Deploy
Deploy --> Secrets : short-lived credentials

Privacy Architecture

Privacy is not only access control. It includes data minimization, purpose limitation, consent, retention, deletion, correction, encryption, masking, lineage, and cross-border movement. Architecture should know where personal data enters, where it is copied, which fields are sensitive, and how obligations are enforced across logs, caches, analytics, backups, and vendors.

One strong tactic is data classification at boundaries. Public, internal, confidential, personal, and regulated data should not flow through the system with equal treatment. Another is separation: keep personal identifiers separate from event history where possible, use tokenization or pseudonymization, and design deletion as a known workflow instead of a heroic database search.

left to right direction
rectangle "User Profile Service" as Profile
database "PII Store" as PII
queue "Domain Events\nminimal personal data" as Events
database "Analytics Store\npseudonymous ids" as Analytics
rectangle "Deletion Workflow" as Delete
rectangle "Vendor Export" as Vendor
rectangle "Privacy Controls" as Controls

Profile --> PII : owns personal data
Profile --> Events : publishes minimal facts
Events --> Analytics : pseudonymous projection
Profile --> Vendor : purpose-limited export
Controls .. PII : encryption, retention, access
Delete --> PII : erase or anonymize
Delete --> Analytics : remove linkage
Delete --> Vendor : deletion request

Blast Radius

Security design should assume some control will fail. Blast radius asks what an attacker, bug, or misconfigured service can do after one credential, service, tenant, region, or account is compromised. Narrow blast radius comes from least privilege, network segmentation, tenant isolation, scoped credentials, rate limits, approval workflows, immutable logs, and fast revocation.

The ideal is not infinite prevention. It is layered control: prevent common attacks, detect unusual behavior, contain damage, recover safely, and learn. A control that cannot be operated during an incident is incomplete. A highly secure design that no team can maintain will decay into exceptions and bypasses.

Practice

Choose one sensitive workflow such as refund approval, medical record access, payroll export, or production database query. Draw the trust boundaries, identify the assets, name three threats, and propose one preventive, one detective, and one recovery control. Then state the residual risk in business language.

References & Further Reading

• NIST SP 800-207: Zero Trust Architecture (U.S. government publication, public domain)
• NIST SP 800-218: Secure Software Development Framework (U.S. government publication, public domain)
• OWASP Application Security Verification Standard (OWASP, CC BY-SA 4.0)
• Microsoft Azure Well-Architected Framework: Security Pillar (Microsoft Learn, CC BY 4.0)