Cloud, Virtualized, and Hybrid Network Security

Introduction

Cloud computing has changed how organisations design, operate, and secure networks. Applications that once ran in privately owned data centres may now use public-cloud infrastructure, software-as-a-service platforms, containers, serverless services, and connections to offices or legacy systems. This flexibility creates operational benefits, but it also changes the location of security controls and the identity of the people responsible for them.

Cloud security is therefore not simply traditional network security moved to a different data centre. Cloud environments are programmable, highly distributed, elastic, and often shared among many customers. A secure design must address identity, virtual networks, workloads, data, application interfaces, management planes, third-party dependencies, and the connections between cloud and on-premises environments.

This chapter explains the shared-responsibility model, virtual networking, cloud firewalls, security groups, secure connectivity, containers, software-defined networking (SDN), secure access service edge (SASE), and practical controls for cloud and hybrid digital transformation.

Learning Objectives

By the end of this chapter, learners should be able to:

1. Explain the shared-responsibility model and distinguish provider duties from customer duties.
2. Describe the main components of a cloud virtual network.
3. Compare cloud firewalls, network security groups, host firewalls, and web application firewalls.
4. Select appropriate methods for secure cloud-to-cloud, site-to-cloud, and user-to-cloud connectivity.
5. Identify security risks associated with virtual machines and containers.
6. Explain the security value and risks of software-defined networking and SASE.
7. Apply practical controls to a hybrid-cloud adoption scenario.
8. Recognise governance, privacy, resilience, and supply-chain requirements in cloud security.

1. The Changing Security Perimeter

In a traditional network, the principal security boundary was often the organisation’s data-centre firewall. Users worked on managed internal networks, applications were hosted on known servers, and traffic flowed through a relatively small number of controlled gateways. This model was never perfect, but it provided a visible perimeter.

Cloud and hybrid environments produce several overlapping perimeters:

• Identity perimeter: access is controlled by users, service accounts, devices, and workload identities.
• Network perimeter: virtual networks, subnets, routes, gateways, and network policies determine communication paths.
• Workload perimeter: virtual machines, containers, databases, and applications enforce local controls.
• Data perimeter: classification, encryption, tokenisation, and data-loss-prevention controls protect information wherever it resides.
• Management perimeter: administrative consoles, APIs, infrastructure-as-code pipelines, and privileged credentials can change the entire environment.

The management plane is particularly important. An attacker who obtains a privileged cloud identity may not need to penetrate a server through the network. The attacker may simply modify firewall rules, create credentials, copy data, or disable logging through an authorised API call.

Cloud security consequently follows a defence-in-depth approach. No single firewall or product can compensate for weak identity management, excessive permissions, vulnerable software, poor logging, or an insecure deployment pipeline.

2. The Shared-Responsibility Model

The shared-responsibility model states that cloud security is divided between the cloud service provider (CSP) and the customer. The exact boundary depends on the service model.

The provider is normally responsible for security of the cloud, including physical facilities, underlying hardware, and foundational services. The customer is responsible for security in the cloud, including correct configuration and appropriate use of services. These phrases are useful, but they should not be treated as universal legal definitions; contracts and service documentation determine specific obligations.

Responsibility is also affected by the deployment model. In a private cloud, the organisation may manage more infrastructure. In a public cloud, it may manage less physical infrastructure but still retain extensive responsibility for identities, data, configuration, and applications. A managed service does not eliminate the customer’s duty to govern access or validate security.

Common customer failures

Typical cloud incidents arise from:

• publicly exposed storage or databases;
• excessive permissions granted to users or service accounts;
• unprotected access keys stored in source code;
• disabled or incomplete audit logging;
• insecure network routes;
• vulnerable images and dependencies;
• inadequate backup testing;
• failure to remove former employees’ access; and
• misunderstanding what the provider actually guarantees.

A useful governance practice is to create a responsibility matrix. For every important control, identify the provider, customer, shared duties, evidence required, and review frequency.

3. Virtual Networks and Segmentation

A cloud virtual network is a logically isolated network defined through software. Although it uses the provider’s physical infrastructure, the customer normally controls address ranges, subnets, routes, gateways, and traffic policies.

3.1 Addressing and subnets

The organisation selects a private address range, divides it into subnets, and assigns workloads to appropriate zones. Public-facing components should generally be separated from internal services. A common arrangement includes:

• a public or edge subnet for load balancers and controlled ingress points;
• an application subnet for application servers;
• a data subnet for databases and internal services; and
• a management subnet for administrative access and monitoring.

A subnet is not automatically a security boundary. Security depends on routing, security policies, identity controls, and the exposure of services. A database in a “private” subnet can still be exposed through a permissive route, a compromised application, or an improperly configured management interface.

3.2 Routing

Route tables determine where packets are sent. Routes may direct traffic to an internet gateway, network address translation (NAT) gateway, virtual appliance, VPN gateway, peering connection, or transit hub. Secure routing follows least privilege: only necessary paths should exist, and unexpected paths should be detected.

Particular care is needed with network peering. Peering may provide efficient private connectivity, but a large mesh of peerings can become difficult to understand and monitor. Transit architectures may simplify governance, although they introduce concentration points that require resilience and careful policy design.

3.3 Segmentation and microsegmentation

Segmentation limits the movement of an attacker after an initial compromise. Traditional segmentation uses subnets and firewalls. Microsegmentation applies policy more precisely, often based on workload identity, labels, application role, or security group membership.

Segmentation is effective only when policies reflect actual business communication. Excessive segmentation can create operational workarounds, while insufficient segmentation permits unrestricted lateral movement. The goal is not to block all communication but to permit justified communication and deny unneeded communication.

4. Cloud Firewall and Traffic-Control Mechanisms

Cloud platforms provide several overlapping controls. Their names differ between providers, but their functions can be compared conceptually.

A security group is commonly stateful: if an allowed rule permits a connection, return traffic is automatically permitted for that established flow. This behaviour is provider-specific and must be verified in documentation. A stateless network access-control list may require explicit rules in both directions.

Rules should be specific. “Allow all traffic from anywhere” is rarely appropriate for a production database. Better rules identify the source application group, destination service, protocol, and required port. Administrative access should use a controlled management path, strong authentication, and logging rather than broad exposure of remote administration ports.

A WAF is not a replacement for secure coding. It can reduce exposure to common web attacks, but it may be bypassed, incorrectly configured, or unable to understand application-specific logic. Input validation, patching, secure authentication, and application testing remain necessary.

Ingress and egress

Ingress is traffic entering a service; egress is traffic leaving it. Organisations often focus on ingress while neglecting egress. Restricting outbound access can limit command-and-control traffic, data exfiltration, and the download of unapproved software. Egress controls must account for legitimate updates, APIs, package repositories, monitoring, and failover services.

5. Secure Connectivity in Hybrid Environments

Hybrid environments connect cloud resources with offices, data centres, remote users, partners, and sometimes other cloud providers. Connectivity must provide confidentiality, integrity, availability, authentication, and operational visibility.

Site-to-site VPN

An IPsec site-to-site VPN creates an encrypted tunnel over an untrusted network. It is comparatively quick to deploy and suitable for moderate traffic volumes. However, it depends on internet connectivity, correct cryptographic configuration, tunnel monitoring, and redundant endpoints.

Dedicated private connectivity

A dedicated connection from an organisation to a cloud provider may offer more predictable performance and reduced exposure to the public internet. It does not automatically encrypt traffic or make the cloud environment secure. Private circuits require redundancy, provider diversity where appropriate, route filtering, encryption decisions, and continuous monitoring.

Zero-trust remote access

Remote users should not receive broad network access merely because they successfully connect to a VPN. Zero-trust access evaluates identity, device condition, requested application, context, and risk. Access should be granted to a specific resource for a defined purpose and duration.

DNS and certificate security

Hybrid systems depend heavily on DNS. Split-horizon DNS, private zones, resolver forwarding, and conditional rules must be documented and monitored. Incorrect DNS can expose internal services, redirect users, or interrupt authentication. TLS certificates should be managed centrally, renewed before expiry, and associated with verified service identities.

6. Virtual Machines and Hypervisor Security

Virtualisation allows several virtual machines (VMs) to share physical hardware through a hypervisor. The hypervisor isolates guest systems, but isolation is not absolute. Vulnerabilities in the hypervisor, insecure management interfaces, weak guest configurations, or excessive privileges can create serious risk.

Good VM security includes:

• hardened and supported operating-system images;
• rapid patching of operating systems and applications;
• removal of unnecessary services;
• encrypted disks and protected snapshots;
• restricted administrative interfaces;
• unique identities and strong authentication;
• vulnerability scanning;
• centralised logs; and
• tested backup and recovery procedures.

Images are a supply-chain component. A conveniently downloaded image may contain malware, outdated packages, embedded credentials, or unsafe configuration. Organisations should approve image sources, scan images, sign or attest trusted images, and rebuild rather than manually modifying long-lived servers.

7. Container and Kubernetes Security

Containers package applications and dependencies while sharing the host operating-system kernel. They are generally lighter than VMs but do not provide the same isolation model. A container escape or privileged container can expose the underlying host.

Security must cover the full container lifecycle:

1. Source: review application code and third-party dependencies.
2. Build: use trusted base images, reproducible builds, and secret-free build processes.
3. Registry: authenticate access, scan images, sign approved images, and retain provenance.
4. Deployment: enforce admission policies, least privilege, resource limits, and network policies.
5. Runtime: monitor processes, images, system calls, logs, and unusual behaviour.
6. Retirement: remove obsolete images, credentials, and workloads.

Kubernetes adds an orchestration control plane containing an API server, configuration store, scheduler, and controllers. The API server is a high-value target. Role-based access control should grant only required permissions, and administrative actions should be logged. Secrets should not be treated as ordinary configuration files; they require encryption, controlled access, rotation, and appropriate external secret management.

Containers are not automatically secure because they are short-lived. Ephemeral workloads can still process sensitive data, communicate with other systems, and create persistent risk through logs, volumes, registries, or compromised credentials.

8. Software-Defined Networking

Software-defined networking separates, conceptually, the control plane that decides network policy from the data plane that forwards traffic. Programmable controllers and APIs can create networks rapidly and apply consistent policy across large environments.

Benefits include automation, central policy management, rapid segmentation, and better integration with infrastructure-as-code. Risks include controller compromise, insecure APIs, configuration errors at scale, excessive privileges, and loss of visibility when multiple tools modify the same environment.

Secure SDN requires authenticated and authorised APIs, separation of administrative duties, protected controller communications, change approval, configuration versioning, policy testing, and rollback capability. Infrastructure-as-code should be reviewed like software: stored in version control, scanned for secrets and insecure settings, tested in non-production environments, and deployed through controlled pipelines.

Automation creates a distinctive risk: a single incorrect template can introduce the same vulnerability into hundreds of resources. Automated controls should therefore include preventive guardrails, policy-as-code, continuous compliance checks, and alerts for drift.

9. SASE and Cloud-Delivered Security

Secure access service edge (SASE) is an architectural approach that combines wide-area networking functions with cloud-delivered security services. Depending on the implementation, services may include secure web gateways, cloud access security brokers, zero-trust network access, firewall-as-a-service, and remote-browser isolation.

SASE is useful where users, applications, and devices are distributed. It can reduce dependence on backhauling traffic through a central data centre and can apply identity- and context-based policies near the user or application.

SASE is not a single product and does not remove the need for governance. Organisations must evaluate policy consistency, provider concentration risk, data-processing locations, logging, service availability, integration with identity providers, and the ability to exit or change suppliers. A SASE deployment should define which traffic is inspected, how encrypted traffic is handled, what privacy constraints apply, and how incidents are investigated.

10. Monitoring, Detection, and Response

Cloud security requires central visibility across cloud accounts, subscriptions, regions, providers, endpoints, workloads, and identity systems. Important telemetry includes:

• administrative and API activity;
• authentication success and failure;
• network-flow records;
• firewall and WAF decisions;
• DNS queries;
• workload and container events;
• configuration changes;
• data-access events; and
• endpoint security alerts.

Logs should be protected from unauthorised alteration, synchronised to a reliable time source, retained according to legal and operational requirements, and regularly tested for usefulness. Logging everything without a detection strategy can generate cost and noise. Detection rules should focus on events such as creation of privileged accounts, disabling of security services, unusual geographic access, impossible travel, unexpected data downloads, and changes to network exposure.

Incident response plans must include cloud-specific actions: preserving provider logs, suspending credentials, isolating workloads, identifying affected accounts, checking snapshots and images, and coordinating with the provider. Evidence collection may depend on provider capabilities and contractual terms.

11. Governance, Privacy, and Resilience

Cloud adoption creates governance questions beyond technical configuration.

Data location and privacy: Data may be replicated across regions or processed by subcontractors. Classification, lawful processing, retention, cross-border transfer, and deletion requirements must be understood before selecting services.

Compliance: Regulations and industry standards may require access control, audit trails, encryption, breach notification, segregation of duties, or evidence of testing. Compliance is not equivalent to security, but compliance obligations provide important control requirements.

Availability: A cloud provider can experience outages, account suspension, regional failures, or service dependency failures. Resilience may require multiple availability zones, tested backups, alternative regions, provider-independent recovery plans, and documented recovery objectives.

Third-party and supply-chain risk: Managed services, software libraries, images, integrations, and support providers extend the trust boundary. Contracts should address security duties, incident notification, audit rights, data return, deletion, and termination assistance.

Ethics: Monitoring should be proportionate and transparent. Security teams should avoid unnecessary collection of employee data, protect confidential logs, and use automated risk scoring with human oversight where decisions affect individuals.

12. Illustrative Case: Hybrid Migration of a Healthcare Provider

Background

A regional healthcare provider operates an electronic appointment system in a public cloud while maintaining clinical databases in a private data centre. Staff work from clinics, hospitals, and home offices. The organisation plans to move its appointment application and analytics platform to the cloud.

Problem

An initial assessment finds broad VPN access, shared administrator accounts, a flat cloud network, unencrypted backups, and incomplete logging. The organisation also lacks a clear responsibility matrix with its cloud provider.

Analysis

The main risks are credential compromise, lateral movement from the appointment system to clinical data, accidental public exposure, unauthorised analytics access, and inability to investigate incidents. The VPN provides connectivity but does not enforce least-privilege application access. The flat network increases the impact of a compromised workload.

Approach

The provider adopts the following design:

• central identity management with phishing-resistant multifactor authentication for administrators;
• separate cloud accounts or projects for production, development, security, and logging;
• private application and database subnets;
• security groups allowing only documented application-to-database flows;
• a WAF and load balancer at the public edge;
• site-to-site VPN with redundant tunnels while evaluating dedicated connectivity;
• zero-trust access for staff rather than unrestricted network access;
• encryption for databases, backups, and data in transit;
• central, tamper-resistant logging;
• approved VM and container images scanned before deployment;
• policy-as-code checks preventing public storage and unrestricted administrative ports; and
• tested recovery procedures with defined recovery time and recovery point objectives.

Outcome

The organisation reduces the reachable attack surface and gains evidence of administrative activity. Staff can access required applications without receiving general access to clinical networks. The security team can identify configuration drift and investigate suspicious data access more effectively.

Learning points

The case illustrates that hybrid security is an architectural and governance problem, not merely a connectivity problem. Strong encryption cannot compensate for excessive privileges, and a private connection does not remove the need for identity, segmentation, monitoring, and resilient operations.

13. Best-Practice Implementation Sequence

A certificate-level practitioner can contribute effectively by following a structured sequence:

1. Inventory cloud accounts, providers, applications, data, identities, and connections.
2. Classify data and identify legal, contractual, and availability requirements.
3. Document the shared-responsibility boundary.
4. Establish central identity, multifactor authentication, privileged-access management, and account separation.
5. Design networks with minimal exposure, explicit routes, segmentation, and controlled egress.
6. Standardise secure images and container build processes.
7. Enable logging, monitoring, alerting, and protected log retention before production launch.
8. Automate configuration checks and detect drift.
9. Test backups, incident response, failover, and account-recovery procedures.
10. Review the design continuously as services, threats, regulations, and business requirements change.

Security should be integrated into procurement, architecture, development, operations, and retirement. It is considerably more effective to prevent an insecure resource from being deployed than to discover it months later through an external scan.

Contemporary Developments

Current cloud-security practice is increasingly influenced by identity-centric zero trust, confidential computing, cloud-native application protection platforms, software supply-chain attestations, workload identity, automated remediation, and artificial-intelligence-assisted detection. These technologies can improve scale and visibility, but they introduce their own risks. AI-generated infrastructure code may contain insecure defaults; automated remediation may interrupt legitimate services; and machine-learning alerts can produce false positives or obscure the reasoning behind a decision.

Organisations should treat emerging technology as an additional control capability rather than a substitute for sound architecture, skilled review, and accountability. Human approval remains important for high-impact changes, sensitive data decisions, and incident containment.

Chapter Summary

Cloud, virtualised, and hybrid environments distribute security responsibilities across providers, customers, identities, networks, workloads, applications, and data. The shared-responsibility model clarifies that providers secure underlying cloud infrastructure while customers remain responsible for secure configuration and use of services. Virtual networks use subnets, routes, gateways, and security policies to control communication, but logical labels alone do not guarantee isolation.

Cloud firewalls, security groups, host firewalls, WAFs, and egress controls serve different purposes and should be layered. VPNs, dedicated connectivity, and zero-trust access provide different forms of secure connection and must be selected according to risk, performance, and governance requirements. Virtual machines and containers require secure images, least privilege, patching, runtime monitoring, and supply-chain controls. SDN and infrastructure-as-code improve consistency but can multiply errors when poorly governed. SASE combines networking and cloud-delivered security for distributed users and applications, while introducing provider, privacy, and availability considerations.

Effective cloud security is continuous. It combines architecture, identity, segmentation, encryption, monitoring, resilience, governance, privacy protection, incident response, and regular testing.

Key Terms

Shared responsibility model: Division of security duties between a cloud provider and its customer.

Cloud service provider (CSP): Organisation that delivers cloud infrastructure, platforms, or applications.

IaaS: Cloud service model providing virtualised infrastructure such as compute, storage, and networking.

PaaS: Cloud service model providing a managed application platform and runtime.

SaaS: Cloud-delivered application managed largely by the provider.

Virtual network: Software-defined logical network isolated within cloud infrastructure.

Security group: Policy controlling network flows to or from a workload, interface, or subnet.

Network virtual appliance: Software-based network device providing functions such as firewalling or inspection.

WAF: Web application firewall that filters HTTP and HTTPS traffic.

Segmentation: Division of a network or workload environment to limit unnecessary communication.

Microsegmentation: Fine-grained segmentation based on workload, identity, role, or labels.

VPN: Encrypted logical connection across an untrusted network.

Zero trust: Security approach that does not grant implicit trust based solely on network location.

Virtual machine: Software-defined computer operating on a hypervisor.

Container: Isolated application process sharing the host operating-system kernel.

Kubernetes: Platform for orchestrating containerised workloads.

Software-defined networking: Programmable networking in which policy and forwarding functions are managed through software.

SASE: Architecture combining cloud-delivered networking and security services.

Egress: Traffic leaving a network, service, or workload.

Infrastructure as code: Machine-readable definition and management of infrastructure configuration.

Review Questions

Short Answer Questions

1. What does the shared-responsibility model mean in cloud security?
2. Why is a cloud subnet not automatically a complete security boundary?
3. What is the principal purpose of a security group?
4. State two security differences between a virtual machine and a container.
5. Why should cloud environments restrict and monitor egress traffic?

Long Answer Questions

1. Explain how security responsibilities differ among IaaS, PaaS, and SaaS.
2. Compare security groups, network firewalls, host firewalls, and WAFs.
3. Describe a secure design for connecting an on-premises data centre to a public cloud.
4. Explain the main security controls required throughout a container lifecycle.
5. Discuss the benefits and risks of SASE in a distributed organisation.

Analytical / Application Questions

1. An organisation has a public web application, an internal application server, and a database. Propose subnets, routes, security rules, and monitoring controls that would limit lateral movement.
2. A cloud administrator discovers that a storage service is publicly accessible and that an access key is present in source code. Analyse the likely risks and define an incident-response sequence.
3. A company wants to replace its broad employee VPN with zero-trust access. Identify the identity, device, application, logging, and governance requirements that should be addressed before migration.

Multiple Choice Questions with Answers

Question 1

Which responsibility normally remains with the customer in an Infrastructure as a Service environment?

A. Physical security of the provider’s data centre

B. Maintenance of the cloud provider’s hypervisor

C. Configuration of operating systems and customer applications

D. Replacement of failed provider-owned disks

Correct Answer: C. Configuration of operating systems and customer applications

Question 2

What is the primary security purpose of network segmentation?

A. To eliminate the need for authentication

B. To limit unnecessary communication and lateral movement

C. To guarantee that all traffic is encrypted

D. To increase the public exposure of services

Correct Answer: B. To limit unnecessary communication and lateral movement

Question 3

Which control is specifically designed to inspect HTTP and HTTPS requests for web attacks?

A. Web application firewall

B. Disk encryption

C. Hypervisor

D. NAT gateway

Correct Answer: A. Web application firewall

Question 4

Why is unrestricted outbound traffic risky in a cloud environment?

A. It prevents all software updates

B. It can facilitate command-and-control communication or data exfiltration

C. It automatically disables multifactor authentication

D. It makes private subnets publicly addressable

Correct Answer: B. It can facilitate command-and-control communication or data exfiltration

Question 5

Which statement best describes zero-trust access?

A. Every user inside the corporate network is trusted automatically

B. Access is granted based only on the user’s IP address

C. Access is evaluated using identity, context, device, and requested resource

D. Users must be denied access to all cloud applications

Correct Answer: C. Access is evaluated using identity, context, device, and requested resource

Question 6

What is a major security concern specific to container images?

A. They cannot contain software dependencies

B. They may include vulnerable packages or embedded secrets

C. They always require a separate physical server

D. They cannot be scanned before deployment

Correct Answer: B. They may include vulnerable packages or embedded secrets

Question 7

What is a principal benefit of software-defined networking?

A. It removes the need for network policies

B. It enables programmable and consistently applied network controls

C. It guarantees that controllers cannot be attacked

D. It prevents all configuration errors

Correct Answer: B. It enables programmable and consistently applied network controls

Question 8

Which practice best protects privileged cloud administration?

A. Using shared administrator accounts

B. Publishing administrative ports to the internet

C. Using strong authentication, least privilege, and audit logging

D. Disabling logs to reduce operational cost

Correct Answer: C. Using strong authentication, least privilege, and audit logging

Question 9

What does SASE generally combine?

A. Physical cabling and database indexing

B. Cloud-delivered security services and wide-area networking functions

C. Only endpoint antivirus and backup software

D. Hypervisor management and printer services

Correct Answer: B. Cloud-delivered security services and wide-area networking functions

Question 10

Why should cloud logs be protected from unauthorised alteration?

A. To ensure they can support investigation and accountability

B. To make applications run without authentication

C. To increase network bandwidth

D. To prevent all service outages

Correct Answer: A. To ensure they can support investigation and accountability