Security+ Security Architecture: Cloud, OT, and Secure Communications

Introduction

This lesson opens Domain 3, Security Architecture (18% of SY0-701). It covers objective 3.1, the effect of architecture models on security, and objective 3.2, how to apply security principles to secure enterprise infrastructure. The exam asks you to look at a design, such as a hybrid cloud, a factory floor, or a branch office, and pick the control that fits it. To do that you must know who is responsible for what in each model, what makes specialized devices hard to protect, and where each security device belongs on the network.

For Security+ architecture scenarios, place each control where the traffic or risk actually is. A web application firewall protects web traffic; a jump server protects administrative access; an air gap protects an isolated system. This lesson gives you the vocabulary and the placement logic.

Learning objectives

After this lesson you will be able to:

• Compare on-premises, cloud, hybrid, and third-party-hosted models and apply the shared responsibility model.
• Explain virtualization, containers, serverless, and microservices and their security implications.
• Describe infrastructure as code (IaC), software-defined networking (SDN), and their risks and benefits.
• Explain why IoT, ICS/SCADA, RTOS, and embedded systems need special treatment.
• Place security devices (firewalls, proxies, IPS/IDS, load balancers, jump servers) and decide between fail-open and fail-closed.
• Choose secure communication technologies: VPN, IPsec, TLS, SD-WAN, SASE, and 802.1X.

1. Architecture models

On-premises

The organization operates systems at its own site, using owned or leased assets and internal or contracted staff. It retains responsibility for physical security, patching, power, cooling, and capacity. Cost is mostly up-front (capital expenditure), and scaling means buying and racking equipment.

Cloud

Cloud computing rents resources over the network. The three service models are:

Deployment models include public (shared provider infrastructure), private (dedicated to one organization), community (shared by organizations with common requirements), and hybrid (a mix, typically on-premises plus public cloud). A multi-cloud strategy uses several providers, which reduces lock-in but multiplies skills and tooling.

The shared responsibility model

The provider secures the cloud; the customer secures what they put in the cloud. The more managed the service, the more the provider handles, but the customer always keeps responsibility for their data, identities, and access configuration. Customer misconfiguration, such as public storage or an overly permissive role, creates exposure even when provider infrastructure is secure. Provider vulnerabilities also exist; use the service-specific responsibility matrix rather than assuming one universal boundary.

A responsibility matrix is a document that lists each security task and who owns it: provider, customer, or shared. Agreements with third-party vendors should always include one.

Third-party vendors and managed services

Outsourcing to a managed service provider (MSP) or managed security service provider (MSSP) transfers operations but not accountability. You remain accountable to regulators and customers, so you need contractual security requirements, audit rights, and vendor risk reviews and security assessments.

Centralized versus decentralized

A centralized design (one data center, one identity provider) is easier to govern but is a bigger single point of failure and target. A decentralized design spreads systems across sites or regions, improving resilience but complicating consistent policy.

Example 1: choosing a model

Scenario. A hospital group has an approved requirement to keep patient imaging on systems under its direct operational control, but wants elastic capacity for a seasonal patient portal.

Reasoning. Keep imaging storage on-premises or in a private cloud, and host the portal in a public cloud. This is a hybrid design. The group must secure the connection between them (for example, an authenticated encrypted VPN; a dedicated link alone does not guarantee encryption), keep identity consistent, and document the responsibility matrix for the portal.

2. Virtualization, containers, serverless, and microservices

Virtualization runs several virtual machines (VMs) on one physical host using a hypervisor. Risks are VM escape (a guest breaking out to the host), VM sprawl (forgotten, unpatched VMs), and a compromised hypervisor affecting every guest. Mitigations: patch the hypervisor, isolate management networks, inventory VMs, and limit snapshots.

Containers package an application and its dependencies and share the host kernel. They start fast and are consistent across environments, but a host-kernel compromise can cross container boundaries. Sandboxed or VM-backed container designs can change this boundary. Controls include scanning images for vulnerabilities, using trusted registries, running as non-root, limiting capabilities, and keeping secrets out of images.

Serverless (function-as-a-service) removes server management from the customer. Security focuses on function permissions (least privilege), input validation, and dependency management, along with configuration, secrets, event sources, and logging. Runtime and base-image updates remain a shared responsibility: for example, AWS Lambda update modes differ, and customer-built container images must be rebuilt and redeployed.

Microservices split an application into small services that communicate through APIs. This improves scalability and isolation but expands the number of network paths and APIs to secure. Authentication between services, API gateways, and monitoring of east-west traffic become important.

3. Infrastructure as code and software-defined networking

Infrastructure as code (IaC) defines servers, networks, and permissions in version-controlled files, which tools then apply automatically. Benefits are consistency, repeatability, peer review, and fast rebuilds after incidents. Risks are that one flawed template is deployed everywhere, and that secrets embedded in code leak through the repository.

A provider-neutral pseudocode example illustrates the risk; it is not a deployable Terraform resource:

bucket: finance-reports
public_read: true  # unintended exposure copied to every environment

If this template is reused, every environment gets a public bucket. Controls: code review, automated policy checks and static analysis of templates before deployment, secrets managers instead of hard-coded credentials, and drift detection. Protect state and plan files too: Terraform’s sensitive marking redacts output but does not itself remove values from state.

Software-defined networking (SDN) separates the control plane (decisions) from the data plane (forwarding). Central controllers apply policy across the network, enabling microsegmentation and rapid changes. The controller becomes a high-value target and must be protected and made redundant.

4. Network infrastructure concepts

• Physical isolation / air gap: no connection to other networks. Strongest separation, but data still moves by removable media, so media handling must be controlled.
• Logical segmentation: VLANs, subnets, and firewall zones separate traffic without separate hardware.
• On-premises versus cloud networking: cloud exposes virtual networks, security groups, and network ACLs to customers, while providers still operate physical networks underneath.

For enforcement details, see network segmentation and system hardening.

5. IoT, ICS/SCADA, RTOS, and embedded systems

Specialized devices share traits that make security hard:

Industrial control systems (ICS) run physical processes; SCADA supervises them over a wide area. OT security must preserve safety, reliability, and required availability while protecting integrity and confidentiality. The correct priority depends on the process hazard assessment; aggressive scanning or unplanned reboots can cause physical harm.

Typical controls:

1. Isolate the devices in dedicated segments, often behind a firewall that allows only specific industrial protocols.
2. Use a jump host with multi-factor authentication for administration.
3. Change default credentials and disable unused services.
4. Monitor passively, since active scanning may disrupt them.
5. Plan lifecycle replacement, because vendor support may end while the device lives on.

Example 2: an unpatchable controller

Scenario. A packaging plant has controllers that cannot be patched and communicate in clear text.

Reasoning. Put them in an OT segment, allow only approved process and monitoring flows, add passive monitoring, and route administrative access through an MFA-protected jump server. Validate changes with operations and the vendor before applying them. These are compensating controls for a device that cannot be fixed directly.

6. Device placement and security zones

A security zone groups assets with similar trust and requirements: internet, DMZ (screened subnet), internal user network, server network, management network, and OT. Traffic crossing zones passes through enforcement points.

Key concepts:

• Attack surface: reduce the number of exposed services and entry points.
• Connectivity: every connection is a potential path; justify and filter each one.
• Failure modes: fail-open keeps traffic flowing when a device fails (favors availability); fail-closed blocks traffic (favors security). Distinguish a network control’s failure behavior from a physical lock’s powered state and emergency egress. Select physical access behavior with life-safety specialists and applicable building rules; an exit can permit egress while preventing entry. A sensitive-data firewall commonly fails closed, with tested redundancy to support availability.
• Active versus passive: an inline (active) device sits in the traffic path and can block it, such as an IPS; a passive device receives a copy through a tap or SPAN port and can only observe, such as an IDS. Inline devices add latency and a possible point of failure; a passive sensor does not directly block packets in the monitored path, though it may trigger a separate response control.

7. Network appliances

Layer 4 firewalls filter by address and port; Layer 7 firewalls inspect application content. WAF functionality is a Layer 7 control; product boundaries vary, so compare capabilities rather than labels. HTTPS inspection requires access to decrypted traffic, such as at TLS termination. A WAF does not repair injection flaws.

8. Secure communications

• Virtual private network (VPN): encrypted tunnel across an untrusted network. Remote access VPNs connect individual users; site-to-site VPNs connect networks.
• IPsec secures traffic at the network layer. AH provides integrity and authentication; ESP can provide confidentiality, integrity, authentication, and anti-replay protection according to the negotiated configuration. Encryption must actually be enabled; ESP’s name alone is not a guarantee. Tunnel mode protects whole packets between gateways; transport mode protects the payload between hosts.
• TLS secures application sessions (HTTPS, secure email, VPN based on TLS). Prefer current versions and strong cipher suites, and disable old protocols.
• Split tunneling sends only corporate traffic through the VPN, saving bandwidth but bypassing corporate inspection for the rest. Full tunneling sends everything through the VPN.
• SD-WAN manages multiple WAN links by policy with centralized control. Verify encryption and security features in the chosen design; traffic steering alone is not a security guarantee.
• SASE (secure access service edge) delivers networking and security functions (secure web gateway, cloud access security broker, zero trust network access, firewall as a service) from the cloud, so remote users get consistent policy without hair-pinning traffic to headquarters.
• Port security and 802.1X: separate mechanisms to control attachment. MAC-based port security limits learned addresses and is spoofable; 802.1X authenticates a user or device. 802.1X uses an authenticator (switch or access point), a supplicant (device), and an authentication server (such as RADIUS) with an EAP method for authentication before network access.
• Secure protocols: SSH instead of Telnet, SFTP or FTPS instead of FTP, HTTPS instead of HTTP, LDAPS instead of LDAP, and DNSSEC to protect DNS integrity.

Review encryption, PKI, and certificate validation before selecting trust and transport controls.

9. Worked example: designing a secure branch office

Problem. A retailer opens 30 small stores. Each has point-of-sale terminals, guest Wi-Fi, a cloud-managed camera system, and a back-office PC. Management wants low cost, central control, and PCI DSS scope kept small.

Step 1: identify zones. Payment terminals, back office, cameras (IoT), and guest Wi-Fi each have different trust levels.

Step 2: segment. Place each in its own VLAN. Block guest to anything internal. Allow payment terminals to reach only the payment processor.

Step 3: select devices. A UTM or NGFW at each store provides stateful filtering, URL filtering, and VPN. Use SD-WAN for two ISP links and central policy.

Step 4: secure communications. Use site-to-site IPsec for encrypted network connectivity, or a SASE design providing the required application/network access controls; TLS for cloud camera management; 802.1X on wired ports in the back office.

Step 5: handle IoT. Change camera defaults, restrict outbound to the vendor's cloud, and monitor for unexpected destinations.

Step 6: failure mode. The firewall fails closed for payment traffic. Because stores must keep selling, a second link plus redundant enforcement devices support availability. Any offline payment fallback must be specifically approved and tested with the payment service; a second ISP alone does not survive firewall failure.

Why other designs are worse. A flat store network puts cameras and guests next to payment terminals, expanding PCI scope and enabling lateral movement. A single link with fail-open firewall favors availability at the cost of exposing payment data.

10. Comparison: choosing the right control

11. Common pitfalls

• Assuming the cloud provider secures your data and configuration. Data, identities, and access are always the customer's responsibility.
• Choosing an IPS where the scenario forbids any risk of blocking legitimate traffic, or an IDS where blocking is required.
• Ignoring OT safety and availability requirements: use passive discovery where practical and perform active testing only with explicit operational approval, compatibility checks, and controlled conditions.
• Treating VPN as a replacement for endpoint security: a VPN encrypts the path but does not clean an infected device.
• Putting a jump server on the same unrestricted network as its targets.
• Hard-coding secrets in IaC templates or container images.

12. Exam tips

• "Who is responsible?" in IaaS, PaaS, or SaaS: the customer always owns data and access.
• "Cannot be patched": isolate, restrict, monitor, and document the exception.
• "Copy of traffic" or "no impact on traffic" signals a passive, tap-based IDS; "block" signals an inline IPS.
• "Fail-closed" favors security; "fail-open" favors availability or safety.
• "Web attack at the application layer" signals WAF.
• "Authenticate before network access" signals 802.1X.
• "Consistent configuration at scale" signals IaC; "centralized policy for software-driven networks" signals SDN.

13. Mini case study

Case. Fabrikam Energy runs a regional water utility. SCADA controllers sit on the same network as office PCs. Engineers access them by RDP from their laptops. The utility is moving its billing portal to a public cloud and uses Terraform to build the environment. An audit finds a storage bucket with customer invoices readable by anyone with the link.

Tasks. Recommend changes.

Solution.

1. Separate OT from IT. Create an OT segment behind a firewall that permits only required industrial protocols from the engineering workstation and monitoring server. This is segmentation and isolation.
2. Introduce a jump server with MFA for engineer access to the SCADA zone, with session logging, replacing direct RDP.
3. Use passive monitoring in the OT segment to reduce direct interaction with controllers; plan and test tap/SPAN installation so monitoring changes do not disrupt operations.
4. Fix the bucket by removing public access, applying least-privilege policies, and enabling logging. This is the customer's responsibility under shared responsibility.
5. Harden the IaC pipeline with code review, automated policy scanning for public storage, and a secrets manager. Add drift detection so manual console changes are caught.
6. Protect the portal with a WAF and TLS, and connect to on-premises billing through a site-to-site VPN.
7. Document the responsibility matrix with the cloud provider and review lifecycle for unsupported controllers.

Key terms

• Shared responsibility model: provider secures the cloud; customer secures their data, identities, and configuration.
• Hybrid cloud: combination of on-premises or private and public cloud.
• Hypervisor / VM escape: software running VMs; escape is a guest breaking out.
• IaC: infrastructure defined and deployed from version-controlled code.
• SDN: separation of control and data planes with central policy.
• ICS / SCADA / RTOS: industrial control, supervisory control, and real-time operating systems.
• Fail-open / fail-closed: behavior of a control on failure.
• Inline / passive (tap, SPAN): in the traffic path versus a monitoring copy.
• WAF, NGFW, UTM: application, next-generation, and unified security appliances.
• SASE: cloud-delivered networking and security services.
• 802.1X: port-based network access control with EAP.

Summary checklist

• I can explain IaaS, PaaS, and SaaS responsibilities and the shared responsibility model.
• I can describe risks of virtualization, containers, serverless, and microservices.
• I can explain IaC and SDN benefits and risks.
• I can list controls for IoT, ICS/SCADA, RTOS, and embedded devices.
• I can decide between inline and passive devices and between fail-open and fail-closed.
• I can choose between WAF, NGFW, IDS, IPS, proxy, and jump server for a given scenario.
• I can distinguish IPsec, TLS, SD-WAN, SASE, and 802.1X.

Sources

• CompTIA Security+ V7 objectives summary (opens in a new tab) — objectives 3.1–3.2.

• NIST SP 800-145, The NIST Definition of Cloud Computing: https://csrc.nist.gov/pubs/sp/800/145/final (opens in a new tab)

• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security: https://csrc.nist.gov/pubs/sp/800/82/r3/final (opens in a new tab)

• NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final (opens in a new tab)

• AWS Lambda: runtime management responsibilities (opens in a new tab)

• HashiCorp: managing sensitive configuration, state, and plan data (opens in a new tab)

• RFC 4303: IPsec ESP (opens in a new tab)