Architecture Models and Trust Boundaries
Key Takeaways
- A secure architecture model describes where assets live, how data moves, and which controls protect each trust boundary.
- Trust boundaries mark places where identity, ownership, sensitivity, or administrative control changes.
- Secure design uses defense in depth, least privilege, secure defaults, fail-safe behavior, and separation of duties.
- Exam scenarios often ask you to place a control at the boundary where risk is introduced, not just anywhere in the diagram.
- Good diagrams show users, systems, data flows, authentication points, management paths, logging paths, and third-party connections.
Architecture Models and Trust Boundaries
Security+ architecture questions test whether you can reason from a diagram. The goal is not to memorize one perfect network. The goal is to identify assets, data flows, control ownership, and the points where trust changes.
Architecture Concepts
| Concept | Exam meaning | Design example |
|---|---|---|
| Defense in depth | Multiple layers reduce reliance on one control | MFA, WAF, segmentation, EDR, logging |
| Least privilege | Access is limited to the minimum needed | App server can query only its own database schema |
| Secure defaults | The initial state is restrictive | New storage bucket is private and encrypted |
| Fail secure | Failure does not create open access | Door lock remains locked during controller failure |
| Separation of duties | Sensitive actions require distinct roles | Developer cannot approve and deploy own production change |
| Resilience | Service continues or recovers during disruption | Redundant zones, backups, tested restore process |
Trust Boundary Clues
A trust boundary exists when traffic or data crosses from one security context to another. Common clues include:
- Internet to public service.
- User workstation to privileged admin plane.
- Web tier to database tier.
- Corporate network to vendor network.
- Cloud tenant to cloud provider-managed service.
- Production to development environment.
- Low-sensitivity data store to regulated data store.
- Human user to automated service account.
At each boundary, ask which control proves identity, restricts authorization, protects data, records activity, and limits blast radius.
Boundary Control Table
| Boundary | Main risk | Better controls |
|---|---|---|
| Internet to web app | Exploit, scanning, DDoS, credential attack | CDN/DDoS protection, WAF, TLS, rate limiting, secure headers |
| Web app to API | Broken authorization, token abuse | OAuth scopes, mTLS where appropriate, input validation, API gateway |
| App to database | Data theft, injection, excessive privilege | Parameterized queries, least-privilege DB account, encryption, monitoring |
| User to admin console | Account takeover, privilege misuse | MFA, PAM, conditional access, jump host, session logging |
| On-prem to cloud | Misrouting, exposed services, weak identity | VPN or private connectivity, IAM federation, routing controls, logging |
Mini Design Example
Scenario: A company hosts a customer portal. Users browse from the internet. The portal uses an API tier and a database containing customer records. Administrators manage servers from a separate corporate subnet.
Reasonable design:
| Flow | Allow? | Control |
|---|---|---|
| Internet -> HTTPS load balancer | Yes | TLS, WAF, DDoS protection, logging |
| Internet -> database | No | Database is private, no public route |
| Web tier -> API tier | Yes | Service identity, API gateway policy |
| API tier -> database TCP 5432 | Yes | Specific source security group only |
| Admin subnet -> jump host SSH/RDP | Yes | MFA, PAM approval, session logging |
| User subnet -> database admin port | No | Admin access only through controlled path |
This design is stronger because the database is not just "behind a firewall"; it is reachable only by a specific application identity and network path.
PBQ-Style Walkthrough
You are given a diagram with these zones:
- Public subnet: reverse proxy and web server.
- Private subnet: application server.
- Data subnet: database.
- Corporate subnet: user workstations.
- Management subnet: admin jump host.
Task: Place controls to protect regulated customer data.
- Put the database in the data subnet with no public IP.
- Permit only the application server to connect to the database on the required database port.
- Require the web server to reach only the application server, not the database directly.
- Require administrators to use the jump host with MFA and session logging.
- Send security logs from web, app, database, and identity systems to centralized logging.
- Encrypt data in transit and at rest.
Common trap: choosing only a WAF. A WAF helps at the internet edge, but it does not replace least-privilege database access, segmentation, privileged access controls, or logging.
Exam Decision Pattern
When a question asks for the "best architecture control," locate the boundary first. Then choose the control that directly reduces the risk at that boundary. For example, if the issue is internet users reaching a database, the best answer is usually private placement, deny-by-default rules, and limited application access, not user awareness training.
A diagram shows an internet-facing web server connecting directly to a database that stores customer records. Which change best reduces the trust-boundary risk?
Which items most clearly indicate a trust boundary? Choose two.
Select all that apply
Order the steps for reviewing a secure architecture diagram.
Arrange the items in the correct order