Network segmentation divides a network into isolated subnets so components with different risk profiles cannot communicate freely. Each subnet can receive security rules suited to the APIs and resources it contains. section 1.1 section 9.5
Segmentation limits the damage from a compromised service, but it does not replace authentication, authorization, input validation, or continuous monitoring. A private network is not proof that an API is safe. section 1.8 section 3.4
Blocking an SSRF path to an admin service
A user service accepts a URL at POST /user/avatar and downloads the referenced avatar. If the user service can reach an admin service, an attacker can exploit SSRF to send an internal request and access sensitive data. Separating the services into restricted subnets removes that communication path, while input sanitization and access controls address the remaining weaknesses. section 1.1 section 3.4
Apply segmentation through a small set of architectural and operational choices:
- Route internet traffic through a hardened DMZ containing components such as an API gateway, reverse proxy, load balancer, or WAF. section 9.2
- Keep services in private subnets without internet access, and expose only documented, tested, secure endpoints through the API gateway. section 9.5
- In AWS, separate resource groups with VPCs or public and private subnets, then restrict traffic with ACLs and security groups. section 9.2
- Use bastion servers for controlled access to internal APIs and databases, allowing traffic only from approved origins. section 9.2
Figure 9.10 The DMZ is a region of our network that is exposed to the internet. It’s good practice to channel inbound traffic through the DMZ and keep all our services in private subnets. The DMZ can include elements such as an API gateway and bastion server.
Use the topology figure to see how a DMZ channels inbound traffic while services remain in private subnets. section 9.2
Check every service-to-service path, especially paths from user-facing APIs to administrative or sensitive systems. Confirm that unnecessary ports and inbound routes are closed, and test that accidental deployment to an internet-accessible network cannot expose an unprotected internal API. section 9.5 section 3.4
