3 Security Architecture and Network Design
Learn how trust boundaries, segmentation, cloud and virtual controls, and recovery measures work together to limit compromise and maintain essential services.
Trust boundaries and network layers
A marks a transition between areas with different trust levels. Examples include an internet-facing firewall, a VPN gateway, a cloud account boundary, and the boundary between business IT and operational technology (OT). Identify the traffic, identities, or data crossing each boundary, then apply controls appropriate to the risk.
A layered network commonly separates external networks, the perimeter or edge, a demilitarized zone (DMZ), and internal networks. External networks include the public internet and untrusted partner networks. Routers, firewalls, VPN gateways, and intrusion-prevention controls can occupy the edge. The DMZ contains public-facing services, such as web servers or reverse proxies, isolated from internal systems. Internal networks contain user devices, application servers, databases, and management systems, which can be separated according to purpose and sensitivity.
For example, internet users may connect to a web server in a DMZ. The server may be allowed to reach a specific internal application service, while direct internet access to the database is denied. If the web server is compromised, this arrangement limits the paths an attacker can use.
Segmentation and traffic control
divides a network into zones and controls communication between them. It can use physical separation, VLANs and subnets, firewalls, access-control lists (ACLs), virtual network controls, or host-based policies. Segmentation can restrict unauthorized access and lateral movement, but it does not replace securing the systems within each segment.
Design zones around business function, sensitivity, and required communication rather than convenience. Common zones include user workstations; public-facing services in a DMZ; application and database tiers; administrative or management interfaces; guest and bring-your-own-device (BYOD) access; backup and recovery systems; and OT or industrial-control systems.
Apply to network traffic: allow only the source, destination, protocol, and port required for a documented purpose, and deny other traffic by default where feasible. For instance, an application server might be allowed to connect to a database on its required service port, while user workstations and internet hosts are blocked from connecting directly to that database. Review rules regularly and remove obsolete exceptions.
A separates Layer 2 broadcast domains, but VLANs alone do not guarantee security. Routing or other controls may still allow traffic between VLANs, so use a firewall, ACL, or equivalent policy-enforcement point to control inter-zone traffic. applies finer-grained controls, often between individual workloads or services, to reduce unnecessary east-west communication within a network.
Verify access to each resource
rejects implicit trust based solely on network location or ownership. Access decisions should verify the user and device, consider relevant context, and authorize access to the particular resource. remains useful, while identity- and resource-based controls complement it.
For example, a remote employee may authenticate with multifactor authentication (MFA), and the organization may check whether the managed device meets security requirements. A policy can then grant access to a specific application rather than unrestricted access to the entire internal network. A VPN connection or internal IP address alone is not proof of trust.
Cloud and virtual environments
Cloud security depends on the service model and the division of responsibilities between provider and customer. The three models are infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). In general, IaaS gives the customer more control over operating systems and network configuration; in PaaS, the provider manages more of the platform; and in SaaS, the provider operates the application. The customer still manages areas such as identities, access, and data settings. Determine the actual division of responsibility rather than assuming the provider handles every security task.
Apply familiar security principles to virtual resources. Separate production, development, and test environments, and isolate workloads with different risks or sensitivity. Use identity and access management (IAM), , MFA for privileged access, and separate administrative accounts where appropriate. Restrict inbound and outbound traffic with cloud firewalls, security groups, network ACLs, and routing policies; avoid broad rules, such as allowing all sources to reach an administrative port. Protect management interfaces and administrative APIs, log their use, and monitor configuration changes. Protect data with appropriate encryption and access controls, and plan for key management and backups.
runs guest systems on shared host hardware through a hypervisor. It enables efficient resource use, but a compromised hypervisor or management plane can affect multiple virtual machines (VMs). Harden and patch hypervisors, restrict and monitor management access, separate management traffic from ordinary workload traffic, and configure virtual switches and virtual firewalls to enforce intended segmentation.
Cloud networks may also use overlays and software-defined controls to enable flexible segmentation. Policy errors or overly permissive configurations can expose resources. Treat network policies, identity permissions, and infrastructure-as-code changes as security-sensitive configurations: review, test, and monitor them.
and recovery
is the ability to continue essential operations, withstand disruption, and recover. It addresses equipment failures, misconfiguration, natural disasters, and cyberattacks. Cyber-resilient systems are designed to anticipate, withstand, recover from, and adapt to adverse conditions or compromises.
Architectural measures should fit the system’s recovery needs:
Redundancy: Provide alternate network paths, power, hardware, or service instances. Redundancy helps only if the components do not share a failure point that could disable them all.
High availability and failover: Detect a component failure and shift service to a standby system. Test failover rather than assuming it works.
Backups and recovery: Keep protected backups, including copies isolated from ordinary production access where appropriate. Test restoration, not just backup completion.
Geographic or site diversity: Use an alternate location or region when justified by the threat model and recovery needs; account for shared dependencies and provider outages.
Monitoring and response: Collect logs, detect abnormal activity, and maintain procedures for isolating affected systems while restoring trusted services.
Diverse controls: Avoid relying on a single protective measure or a shared component whose failure would defeat multiple layers.
Business-impact analysis helps identify the most important services and prioritize recovery requirements. is the target time to restore a service, while is the maximum acceptable amount of data loss measured in time. A shorter or generally requires more capable and potentially more costly recovery arrangements.
For example, an online ordering system with a short may operate redundant application instances and maintain tested recovery procedures. Its backup environment may be access-controlled separately from production. If ransomware compromises production credentials, separation helps reduce the chance that the attacker can also destroy the recovery copies.
Evaluate an architecture
When evaluating an architecture, work through these questions:
What is the asset and threat? Identify sensitive data, a critical service, a likely attack path, or a failure condition.
Where are the trust boundaries? Look for paths between the internet, DMZ, internal systems, cloud, users, and administrative planes.
What communication is actually required? Select the narrowest effective rule and block unnecessary paths.
Where could an attacker move next? Use segmentation, identity controls, and monitoring to constrain lateral movement.
What happens if a component or site fails or is compromised? Consider dependencies, failover, backups, and tested recovery.
Common design pitfalls include treating a VPN connection or internal IP address as proof of trust; assuming a alone blocks all traffic; placing public-facing servers on the same unrestricted network as sensitive databases; allowing broad administrative access; and mistaking successful backup jobs for tested recoverability.