Public-facing web servers sit in a perimeter network (screened subnet) and must query the company's customer database. A network engineer asks where the database should live and what traffic should be permitted. Which design is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
The perimeter network is the lobby: visitors can get in there, but not into the vault. You keep the database in the back and open exactly one door, its listening port, and only for the web servers. Anything wider gives an attacker who compromises a web server a highway inward.
Full Explanation
A perimeter network, also called a screened subnet or DMZ, hosts systems that must accept connections from the internet, such as web servers, and is separated from internal networks by firewalls. Sensitive systems like a customer database belong on an internal segment. A firewall rule then permits only the required flow: from the web or application servers' specific addresses to the database's listener port, for example a default port such as 1433 for SQL Server or 5432 for PostgreSQL, with everything else denied. If a web server is compromised, the attacker reaches only that single port on the database rather than the whole internal network. Placing the database in the perimeter network exposes it on the same less-trusted segment as internet-facing servers, removing a layer of protection. Permitting all ports between perimeter and internal networks defeats segmentation and makes lateral movement trivial after a compromise. Assigning a public IP address and routing traffic over the internet exposes the database to scanning and attack and adds needless latency. Exam caveat: default ports can be changed, so rules should use the port actually configured on the listener. Operational check: from a web server, confirm the database port is reachable and that other ports on the database host are blocked.