Security Architecture

Assuming basic network vocabulary, you will learn to locate the boundary any 3.x scenario turns on. The unifying question across this domain is not which appliance or cipher to buy but where the workload runs, where data lives, and where a control sits, because those placement choices fix who is responsible for each protection. A deployment model sets the shared-responsibility boundary (on-premises means you own the whole stack; IaaS leaves you the OS upward; SaaS leaves you mostly data, identity, and configuration), and that boundary is never a transfer of accountability. The data owner remains legally responsible even when the provider runs the host. The same logic recurs at the network: a security control only acts on the traffic that reaches it, so device placement at a trust boundary, not the vendor box, is the first design decision. Reading any 3.x scenario starts by locating the boundary the question is really asking about.

Every subtopic rewards removing exposure over layering appliances. At the infrastructure layer the cheapest hardening is closing what is not needed (disable unused ports, terminate admin on a hardened jump server instead of exposing RDP/SSH, and segment zones so a compromised host cannot pivot) because a next-generation firewall in front of twenty open services has merely moved the problem. The same instinct governs data (segmentation isolates the breach blast radius, and keeping regulated data in-jurisdiction via geographic restrictions honors data sovereignty) and constrained estates (unpatchable ICS/SCADA, IoT, and embedded devices are protected by network segmentation or air-gapping rather than by an endpoint agent they cannot run). Structural reduction of connectivity is a control no single product replaces.

Security architecture is a set of state-dependent decisions rather than a single best answer. Data takes a different control in each of its three states: encryption (full-disk, file, or column) for data at rest, transport encryption such as TLS or IPsec for data in transit, and access controls, masking, or confidential-computing for data in use. Because the CPU must operate on plaintext, ordinary disk encryption never covers data in use. Methods sit on a reversible-vs-irreversible spectrum, so hashing is wrong wherever the value must be read back and tokenization is right when the goal is to remove sensitive data from PCI/audit scope. The same state-matching governs traffic protection: swap each plaintext protocol for its encrypted equivalent (SSH for Telnet, HTTPS for HTTP, SFTP/FTPS for FTP, SNMPv3 for SNMPv1/v2c, LDAPS for LDAP) and assume any network you do not control is observable.

Architecting for availability is a series of explicit cost-versus-tolerance choices, not a single robust design. RTO (downtime tolerance) and RPO (data-loss tolerance) are the two numbers that drive every recovery decision: near-zero values demand a hot site with synchronous replication at the highest cost, while a multi-day tolerance permits a cold site at the lowest. High availability (load balancing, clustering) keeps a service running through component failure but is not a backup, because a replicated cluster faithfully propagates corrupted or ransomware-encrypted data to every node. Only an independent, offsite, immutable copy gives a clean recovery point. The same deliberate-choice principle governs inline controls: fail-closed (block on device failure) protects confidentiality and integrity, fail-open (pass on failure) protects availability (the trade-off detailed in infrastructure-security) and proving the design works: a recovery plan, a backup, or a failover path is an assumption until exercised by a tabletop, parallel-processing, or full failover test and at least one real restore.