Trust Boundaries

A trust boundary separates components that operate under different security assumptions, administrative control, or exposure to threats. Crossing that boundary requires explicit checks appropriate to the interaction. Boundaries can exist between the internet and an application, between application tiers, between cloud accounts, between tenants, or between a workload and a managed service. They are logical security distinctions, not necessarily physical network edges.

Start by drawing the application's data flows and identifying entry points, sensitive assets, identities, and administrative owners. Mark each place where input or authority moves into a different trust context. For each crossing, ask what an attacker could impersonate, modify, disclose, replay, or disrupt. Then select controls that address those threats: authentication, authorization, input validation, encryption, traffic filtering, rate limiting, and audit logging. A boundary is meaningful only when the required checks are actually enforced.

In a three-tier web application, the public load balancer accepts untrusted client traffic, application servers process requests, and the database holds sensitive records. Restrict application ingress to the intended load-balancer path and database ingress to the required application sources and ports. Database credentials and permissions must still constrain what the application can do. If an attacker compromises an application server, network reachability alone must not provide unrestricted access to every database or administrative interface.

Different application architectures produce different threat models. A monolith often has fewer network crossings, but a process compromise can expose many functions and secrets. Microservices introduce more service-to-service boundaries, requiring workload authentication and authorization rather than reliance on internal IP addresses. Serverless and event-driven systems add boundaries at API handlers, queues, event publishers, and execution roles; events still need schema validation and tenant-aware authorization. In multitenant applications, shared infrastructure makes application-level tenant isolation essential because network segmentation may not distinguish individual tenants.

Cloud network constructs help enforce boundaries but do not establish trust automatically. Separate subnets without restrictive traffic controls do not provide effective isolation, and a private subnet is not proof that its workloads are trustworthy. Peering or transit connectivity can expand reachable attack surfaces unless routes and filtering preserve intended separation. Security groups provide stateful traffic filtering, while network ACLs provide stateless subnet-level filtering that requires explicit consideration of return traffic. Neither substitutes for application authorization.

Hybrid and cross-account architectures require particular care because connectivity crosses administrative domains. Limit partner access to specific services rather than entire networks where possible. Private connectivity reduces public exposure but does not prove caller identity or authorize a request. Dedicated connectivity also does not inherently provide encryption; for example, AWS Direct Connect does not encrypt traffic by default. When TLS terminates at a proxy, assess whether the next connection needs encryption and ensure the application accepts identity headers only from trusted intermediaries.

More boundaries can reduce lateral movement and contain failures, but they also increase policy complexity, latency, certificate-management work, and troubleshooting effort. Centralized inspection can simplify policy enforcement but creates routing and availability dependencies, including symmetric-routing requirements for stateful inspection. For compliance, document allowed flows, administrative ownership, and required evidence. Test both permitted and denied paths, inspect flow and authorization logs, and revisit the model when architecture changes. The goal is not to label everything inside a perimeter trusted; it is to make each crossing explicit, constrained, and observable.