Chapter 6
Network, Infrastructure, and Platform Security
Bachelors Program in IT
Cloud Security
•
Bachelor
Network, Infrastructure, and Platform Security
Introduction
Cloud security depends on more than protecting application code and user identities. Applications operate through virtual networks, routing systems, gateways, storage services, databases, load balancers, and operating platforms. A weakness in any of these layers can expose data, enable unauthorized access, interrupt availability, or permit an attacker to move laterally through an environment.
Cloud infrastructure security is therefore concerned with the design and operation of technical boundaries. These boundaries include network segmentation, firewall rules, security groups, private connectivity, encrypted communication, protected management interfaces, resilient infrastructure, and continuously monitored services. Unlike a traditional data centre, cloud infrastructure is software-defined and rapidly changeable. This creates flexibility, but it also makes configuration errors, excessive permissions, and undocumented dependencies significant risks.
This chapter examines the major controls used to secure cloud networks and infrastructure. It emphasizes design reasoning rather than vendor-specific commands. Although individual cloud providers use different names, the underlying concepts—routing, filtering, isolation, encryption, resilience, and observability—are broadly transferable.
Learning Objectives
By the end of this chapter, students should be able to:
Explain the security role of virtual networks, subnets, routes, gateways, and network address translation.
Distinguish network security groups, stateful firewalls, stateless access-control lists, and web application firewalls.
Design segmented architectures for public, private, application, and data workloads.
Apply security principles to cloud storage, databases, operating systems, and infrastructure services.
Analyse a cloud infrastructure design and identify weaknesses, trade-offs, and improvements.
Evaluate operational, governance, privacy, and availability implications of infrastructure controls.
1. The Cloud Infrastructure Security Model
A useful model divides cloud infrastructure into four interacting planes:
Data plane: Processes application traffic and data, such as packets, database queries, and object requests.
Control plane: Creates and changes resources, routes, policies, identities, and configurations.
Management plane: Provides administrative access through consoles, APIs, command-line tools, and automation systems.
Monitoring plane: Collects logs, metrics, traces, alerts, and configuration evidence.
A secure design protects all four planes. Filtering application traffic while leaving an unrestricted administrative API exposed is not a secure architecture. Similarly, encryption protects data in transit but does not compensate for an overly permissive identity policy.
The principle of defence in depth requires multiple independent or partially independent controls. For example, a database may be protected by private routing, a security group, database authentication, encryption, backup controls, and monitoring. The failure of one control should not immediately expose the asset.
The shared responsibility model also applies. The provider normally protects physical facilities, underlying hardware, and foundational services. The customer remains responsible for choices such as network configuration, identity permissions, operating-system hardening, data classification, firewall rules, and application security. The exact division varies by service model: customers generally manage more in infrastructure as a service than in a fully managed software service.
2. Virtual Networks and Addressing
A virtual private cloud or equivalent virtual network is an isolated logical network within a provider environment. It normally contains subnets, route tables, gateways, firewall policies, and private service endpoints.
2.1 Address spaces and subnets
An IPv4 subnet is commonly represented in CIDR notation, such as 10.20.0.0/16. The suffix indicates the number of network-prefix bits. The remaining bits represent addresses within the block. The total number of IPv4 addresses in a block is:
N = 2^(32 − p)
where N is the total address count and p is the prefix length. This formula assumes IPv4 addressing and a conventional binary CIDR block. In some cloud platforms, a few addresses are reserved for network, gateway, DNS, or platform functions, so usable addresses may be fewer than N.
For example, a /24 contains 2^(32−24) = 256 total IPv4 addresses. If a platform reserves five addresses, the customer can assign 251 addresses. The reservation rule is provider-specific and must be verified before capacity planning.
Subnet design should reflect trust boundaries and operational needs. A common arrangement is:
Public edge subnet: load balancers, controlled ingress gateways, and occasionally bastion services.
Private application subnet: application servers and internal APIs without direct public addresses.
Private data subnet: databases, caches, and storage interfaces.
Management subnet: administrative tooling, scanners, and controlled maintenance systems.
Subnets are not automatically security boundaries merely because they have different address ranges. Effective isolation requires routes, firewall policies, security groups, identity controls, and appropriate administrative discipline.
2.2 Routing
A route table determines where traffic goes based on destination address. A route may direct traffic to a local network, internet gateway, NAT gateway, VPN, transit gateway, peering connection, or private service endpoint. A default route, commonly written as 0.0.0.0/0 for IPv4, matches destinations not covered by a more specific route.
Routing and filtering perform different functions. Routing answers “where should the packet be sent?” Filtering answers “should this traffic be permitted?” A route to a database subnet does not by itself authorize a connection. Conversely, a permissive firewall rule is ineffective if no route exists.
The principle of least reachability recommends that a workload should have routes only to services it must use. For example, an application server may need a route to a database and an update repository, but not to every internal subnet. Reduced reachability limits lateral movement after compromise.
2.3 Internet access and NAT
An internet gateway provides a path between a virtual network and the public internet, subject to routing and filtering. A public IP address does not automatically mean that an application is secure; it increases exposure and requires careful ingress, egress, patching, and monitoring.
Network address translation (NAT) allows private addresses to communicate externally through a shared public address. A NAT gateway can permit outbound updates from private workloads without accepting unsolicited inbound connections. NAT is not a substitute for a firewall: it primarily translates addresses and tracks connections, while policy enforcement determines which flows are allowed.
3. Segmentation and Traffic Filtering
Segmentation divides infrastructure into zones with distinct trust levels and communication requirements. It can be implemented through separate accounts or subscriptions, virtual networks, subnets, security groups, firewalls, service endpoints, and identity policies.
A useful segmentation question is not simply “which servers belong together?” but “which communications are necessary, from which sources, to which destinations, on which ports, and for what business purpose?” Rules should be based on explicit flows rather than broad assumptions.
3.1 Security groups
A security group is usually a stateful virtual firewall associated with an interface, virtual machine, or managed service. Stateful means that if an allowed connection is established, return traffic is automatically recognized, even when a separate reverse-direction rule is not written. Security groups commonly support allow rules and are evaluated in addition to other controls.
Good practice includes:
Allowing only required protocols and ports.
Referencing trusted security groups or service identities instead of large address ranges where possible.
Avoiding unrestricted ingress from the internet.
Restricting administrative ports to approved management paths.
Reviewing unused and overlapping rules.
Logging accepted and rejected flows when operationally justified.
3.2 Network ACLs and firewalls
A network access-control list is often applied at subnet boundaries. Depending on the platform, it may be stateless, meaning that both outbound and return traffic must be explicitly permitted. Ordered rules and default-deny behavior are important characteristics.
A stateful network firewall can provide centralized inspection, policy enforcement, intrusion detection, domain filtering, and egress control. It is useful when an organization needs consistent controls across many networks or must inspect traffic between zones. However, centralized inspection can add cost, latency, scaling requirements, and a potential failure concentration.
A web application firewall (WAF) operates at the HTTP layer. It can detect or block patterns associated with SQL injection, cross-site scripting, malicious bots, protocol abuse, and excessive requests. A WAF complements, but does not replace, network controls. It cannot correct an exposed database port or a weak database credential.
3.3 Default deny and rule evaluation
A secure baseline normally denies traffic unless a documented rule permits it. Rule evaluation differs by provider: some systems use first-match processing, while others combine rules or evaluate explicit denies differently. Engineers must understand the actual semantics rather than assume that two platforms behave alike.
Rules should have an owner, purpose, scope, review date, and change record. Temporary exceptions should have an expiration mechanism. “Any source to any destination” rules may be necessary in limited cases, but they should be treated as exceptions requiring justification.
Figure: A layered architecture using edge protection, private application and data zones, private access, and centralized monitoring.
4. DNS Security
The Domain Name System translates names into addresses and service records. In cloud environments, DNS may support public records, private zones, service discovery, health checks, and routing decisions.
Security concerns include unauthorized zone transfers, domain hijacking, cache poisoning, malicious record changes, and accidental exposure of internal names. DNS administration should use strong identity controls, multi-person approval for high-impact changes, change logging, and domain registration protection.
Private DNS zones prevent internal names from being published publicly. Split-horizon DNS can return different answers to internal and external clients, but it must be documented carefully to avoid confusion during incident response.
DNS Security Extensions (DNSSEC) provide authenticity and integrity for signed DNS responses through a chain of trust. DNSSEC does not encrypt queries and does not make a malicious application safe; it addresses a specific class of DNS authenticity problems. Encrypted DNS protocols can protect the confidentiality of queries between a client and resolver, but organizations must consider logging, policy enforcement, and resolver trust.
5. VPNs and Private Connectivity
A virtual private network creates an encrypted tunnel across an untrusted or shared network. Site-to-site VPNs connect organizational networks to cloud networks, while client VPNs connect individual users or devices. Common design issues include route propagation, overlapping address spaces, tunnel redundancy, authentication, key rotation, and bandwidth capacity.
Encryption in transit protects confidentiality and integrity between endpoints, but it does not automatically authorize every user or service inside the tunnel. Access controls must still restrict destinations and ports. Modern VPN designs should use strong cryptographic protocols, certificate- or identity-based authentication, secure key management, and monitoring of tunnel status.
Dedicated private connectivity uses a provider or carrier path rather than the public internet. It can offer predictable performance, lower exposure to internet routing, and compliance benefits. It is not inherently secure: physical or logical access, routing, encryption requirements, and provider controls must still be evaluated. Many organizations combine dedicated connectivity with application-layer encryption and restrictive firewall policies.
Private service endpoints allow workloads to reach managed cloud services through internal addressing. They reduce the need for public internet paths and can enable endpoint policies, but they must be monitored for misconfiguration and excessive service access.
6. Gateways, Load Balancers, and DDoS Defence
A gateway is a controlled entry or exit point between networks or protocol domains. Examples include internet gateways, NAT gateways, API gateways, transit gateways, and VPN gateways. Each gateway should have a defined trust boundary, routing policy, logging strategy, and availability design.
A load balancer distributes requests among healthy backend instances. It improves availability and scaling, terminates or passes through TLS, performs health checks, and may enforce connection or request policies. TLS termination at the load balancer simplifies certificate management, but traffic from the balancer to the backend should also be encrypted when confidentiality or trust requirements demand it.
Load balancer security includes:
Restricting listener protocols and ports.
Using current TLS configurations and managed certificate rotation.
Validating hostnames and application-layer headers.
Preventing direct public access to backend instances.
Protecting health-check endpoints from revealing sensitive information.
Logging client, listener, target, status, and latency information.
Distributed denial-of-service (DDoS) attacks attempt to exhaust bandwidth, connection tables, compute capacity, or application resources. Controls operate at multiple layers:
Provider-scale traffic absorption and scrubbing.
Rate limiting and connection limits.
Caching and content distribution.
WAF rules and bot management.
Autoscaling with cost safeguards.
Application-level quotas and graceful degradation.
Incident runbooks and upstream escalation arrangements.
Autoscaling alone is not a complete DDoS defence. It may increase cost while the attacker continues to consume application resources. Detection thresholds, budget alarms, reserved capacity, and tested response procedures are important parts of resilience.
7. Storage and Database Security
7.1 Object and block storage
Cloud storage should be secured through identity policies, resource policies, encryption, network restrictions, versioning, retention controls, and monitoring. Public access should be disabled by default. Access should be granted to specific roles or service identities rather than shared credentials.
Object storage often requires attention to both the storage account and individual objects. A permissive bucket policy may override an engineer’s assumption that an object is private. Public-access prevention controls and continuous policy analysis reduce this risk.
Encryption at rest protects stored data if underlying media or snapshots are accessed without authorization. Managed keys are convenient, while customer-managed keys may provide stronger separation of duties and control over rotation or revocation. Key loss can make data unrecoverable; therefore, key backups, recovery procedures, and separation of administrative roles are essential.
Backups and snapshots are security assets and targets. They should be encrypted, access-controlled, isolated from routine administrative accounts, tested for restoration, and protected against accidental or malicious deletion. Immutability and separate accounts can reduce ransomware impact.
7.2 Databases
Database security begins with network placement. A database should generally use private addressing and accept connections only from approved application identities or subnets. Network controls should be combined with database authentication, authorization, auditing, encryption, patching, and secure configuration.
Important controls include:
Separate administrative and application accounts.
Least-privilege roles and restricted schema permissions.
Strong authentication and rotation of secrets.
Encryption in transit and at rest.
Query and audit logging, subject to privacy and cost considerations.
Parameterized queries to reduce injection risk.
Backup encryption and recovery testing.
Replication and failover plans that preserve security policies.
A private database is not automatically trustworthy. A compromised application may still misuse legitimate database credentials. Application authorization, query controls, and anomaly detection remain necessary.
8. Infrastructure and Platform Security
Infrastructure security includes virtual machines, containers, orchestration platforms, images, operating systems, and management services.
Virtual machines should use hardened images, minimal packages, timely patches, host firewalls, endpoint detection, secure boot where available, restricted metadata access, and controlled administrative channels. Administrative access should use short-lived credentials, multi-factor authentication, centralized logging, and preferably a managed session service rather than exposed SSH or RDP ports.
Container security spans the image supply chain, registry, runtime, orchestration control plane, and workload. Images should be built from trusted minimal bases, scanned for vulnerabilities and secrets, signed where appropriate, and rebuilt regularly. Runtime permissions should be restricted; containers should not run as privileged users without a documented need. Orchestrator APIs and worker nodes require strong access control and network isolation.
Infrastructure as code improves repeatability and reviewability. Secure practices include version control, peer review, automated policy checks, secret separation, state-file protection, drift detection, and controlled deployment identities. Automation does not guarantee security: an incorrect template can reproduce a vulnerability consistently and at scale.
Metadata services can expose temporary credentials or instance information. Access should be limited to the intended workload, and applications should be protected from server-side request forgery that could query metadata endpoints.
9. Worked Design Example
An organization deploys an online learning platform. Students access web pages and APIs; instructors upload course materials; internal staff administer the service; transactional data is stored in a relational database.
A suitable design uses three availability zones. A public edge tier contains a DDoS-protected service, WAF, and load balancer. Application instances are placed in private subnets and accept traffic only from the load balancer security group. Database instances are placed in isolated private subnets and accept connections only from the application security group on the database port. Private endpoints provide access to object storage and monitoring services without requiring general internet routes.
Staff access occurs through identity-aware VPN or a controlled private access service with multi-factor authentication. No database or application administration port is exposed to the public internet. Outbound application traffic passes through a NAT gateway or approved egress firewall, and domain restrictions prevent connections to unapproved destinations.
The design is analysed by tracing flows:
Student browser → load balancer: HTTPS only.
Load balancer → application: authenticated or validated application traffic, encrypted where required.
Application → database: only the required database protocol and port.
Application → object storage: private endpoint and workload identity.
The design also requires operational evidence: flow logs, WAF events, load-balancer logs, database audit records, configuration history, vulnerability reports, and restoration-test results. A quarterly review verifies that rules still reflect actual business flows.
10. Illustrative Case Study: Retail Platform Exposure
Background. A fictional retailer migrates its order platform to the cloud. The initial architecture uses public IP addresses for application servers, a database reachable from the application subnet, and a storage bucket containing product images and deployment artifacts.
Problem. A security review finds that the database security group permits access from the entire virtual network. The storage bucket allows anonymous reads, and administrators use a shared SSH key. Flow logs are disabled, so the organization cannot establish whether the weaknesses have been exploited.
Analysis. The design has three major weaknesses. First, broad network reachability enables lateral movement. Second, anonymous storage access may expose deployment artifacts or sensitive metadata. Third, shared administration prevents reliable attribution and makes key revocation difficult. The absence of logs increases uncertainty and delays detection.
Approach. The retailer places the database in private subnets, permits access only from the application workload identity, and removes public routes. It replaces direct application exposure with a protected load balancer and WAF. Storage public access is disabled; object access uses workload roles and private endpoints. Administrators use individual federated identities, multi-factor authentication, and short-lived sessions. Flow, access, configuration, and database audit logs are centralized with retention appropriate to legal and operational requirements. Backups are encrypted and protected from ordinary production administrators.
Outcome. The revised design reduces the attack surface and improves accountability. Security testing confirms that the application can reach the database but unrelated workloads cannot. Restoration tests demonstrate that encrypted backups can be recovered. The organization also adds policy-as-code checks that prevent public storage and unrestricted administrative ports in future deployments.
Learning points. Secure architecture is a combination of topology, policy, identity, encryption, monitoring, and operational practice. Private placement is valuable, but it must be supported by restrictive rules. Remediation should address both the immediate exposure and the process that allowed it to recur.
11. Challenges, Trade-offs, and Governance
Security controls impose cost, latency, complexity, and operational responsibility. Central firewalls simplify policy consistency but may become bottlenecks. Extensive logging supports investigations but creates storage costs and privacy obligations. Private connectivity can improve control but may reduce flexibility and require specialized contracts. Strict egress filtering can prevent data exfiltration but may disrupt legitimate software updates.
Availability must be designed deliberately. Critical gateways, VPN tunnels, DNS resolvers, load balancers, and firewall appliances should be evaluated for redundancy, zone distribution, capacity, and failure behavior. High availability does not mean identical copies alone; dependencies such as identity, certificates, keys, DNS, and monitoring must also remain available.
Governance should define ownership, approved architectures, exception processes, configuration baselines, data classifications, retention periods, and incident responsibilities. Infrastructure changes should be traceable to an approved request or automated pipeline. Compliance requirements may mandate encryption, geographic restrictions, audit trails, breach notification, or retention controls; technical implementation must be mapped to the applicable law and contract rather than assumed from a generic checklist.
Privacy requires data minimization, access limitation, appropriate logging, and careful treatment of IP addresses, DNS queries, database records, and administrator activity. Monitoring data can itself contain personal or confidential information.
Artificial intelligence can assist with anomaly detection, policy analysis, attack-path discovery, and alert prioritization. However, AI-generated recommendations may be based on incomplete telemetry or produce false positives. Human review, explainable evidence, access controls, and testing against adversarial inputs remain necessary. AI tools should not receive secrets or sensitive configuration unless approved controls exist.
12. Best-Practice Design Principles
Start with a documented inventory of networks, services, data flows, identities, and dependencies.
Separate public edge, application, data, and management functions.
Use private addressing and default-deny policies for internal services.
Apply least privilege to network flows, identities, APIs, and database roles.
Prefer workload identities and short-lived credentials over shared secrets.
Encrypt data in transit and at rest, and manage keys with recovery and separation-of-duty controls.
Protect DNS, certificates, storage policies, backups, and metadata services.
Use layered DDoS, WAF, load-balancing, rate-limiting, and application controls.
Centralize logs and test that alerts are actionable.
Use infrastructure as code with review, policy checks, drift detection, and rollback.
Test failover, backup restoration, incident response, and rule changes.
Review architecture continuously as workloads, regulations, and threats change.
Chapter Summary
Cloud network and infrastructure security protects the paths, platforms, and services on which applications depend. Virtual networks provide logical structure, but real isolation requires appropriate routing, segmentation, firewall policies, identity controls, and monitoring. Security groups, network ACLs, stateful firewalls, and WAFs operate at different layers and should be selected according to the threats they address.
Secure designs commonly place public-facing controls at the edge, applications in private subnets, and databases and sensitive storage in restricted data zones. DNS, VPNs, private connectivity, gateways, load balancers, and DDoS controls extend this architecture beyond simple packet filtering. Storage and databases require both network protection and service-level controls such as encryption, authorization, backups, and auditing.
Infrastructure as code, hardened images, protected management paths, vulnerability management, centralized logs, and tested recovery procedures convert design intentions into operational security. Finally, effective cloud security must account for availability, privacy, governance, cost, and the shared responsibility model. Security is not a single device or rule; it is a continuously reviewed system of technical and organizational controls.
Key Terms
Virtual network: A logically isolated cloud network containing subnets, routes, and network controls.
CIDR: A notation that expresses an IP network prefix and its length.
Subnet: A subdivision of an IP address space used to organize workloads and traffic.
Route table: A collection of rules that determines the next destination for network traffic.
NAT: Network address translation, which maps private addresses to another address for communication.
Security group: A commonly stateful virtual firewall associated with a workload or interface.
Network ACL: A network access-control list applied to a subnet or network boundary.
WAF: A web application firewall that filters and inspects HTTP-layer traffic.
Segmentation: The separation of systems or traffic into controlled security zones.
Private endpoint: An internal path from a workload to a managed service.
VPN: An encrypted tunnel across a shared or untrusted network.
Load balancer: A service that distributes traffic among available backend resources.
DDoS: Distributed denial of service, an attack intended to exhaust resources through coordinated traffic.
DNSSEC: Extensions that provide authenticity and integrity for DNS responses.
Infrastructure as code: The declarative or programmatic management of infrastructure through versioned files.
Security baseline: An approved minimum configuration for a system or service.
Egress filtering: Control over outbound traffic from a network or workload.
Defence in depth: The use of multiple complementary security controls.
Shared responsibility model: The allocation of security duties between a cloud provider and its customer.
Review Questions
Short Answer Questions
What is the difference between routing and traffic filtering?
Why should databases normally be placed in private subnets?
What security problem does a WAF address?
Why is NAT not a replacement for a firewall?
What is the purpose of infrastructure as code in security operations?
Long Answer Questions
Explain how a three-tier cloud architecture can use subnets, routes, security groups, and private endpoints to reduce attack surface.
Discuss the security and operational trade-offs between VPN connectivity and dedicated private connectivity.
Explain how storage, database, backup, and key-management controls should work together.
Analyse the role of logging, monitoring, and tested recovery in cloud infrastructure security.
Analytical / Application Questions
An application server must retrieve updates from the internet but must not accept unsolicited inbound traffic. Design the required routes, gateway arrangement, and filtering controls.
A company discovers that a database is reachable from every workload in its virtual network. Identify the risks and propose a staged remediation plan.
Design a secure request flow for a public web application that uses DDoS protection, a WAF, a load balancer, private application instances, and a private database. Explain the purpose of each layer.
Multiple Choice Questions with Answers
Question 1
Which statement best describes a route table?
A. It determines where traffic should be sent based on destination
B. It encrypts all packets leaving a subnet
C. It authenticates database users
D. It scans application code for vulnerabilities
Correct Answer: A. It determines where traffic should be sent based on destination
Question 2
How many total IPv4 addresses are in a /24 CIDR block?
A. 24
B. 128
C. 256
D. 512
Correct Answer: C. 256
Question 3
What is a primary security characteristic of a stateful security group?
A. It automatically encrypts stored data
B. It recognizes return traffic for an allowed connection
C. It replaces identity authentication
D. It signs DNS records
Correct Answer: B. It recognizes return traffic for an allowed connection
Question 4
Which control operates primarily at the HTTP application layer?
A. Internet gateway
B. Network address translation
C. Web application firewall
D. Subnet route table
Correct Answer: C. Web application firewall
Question 5
Why are private service endpoints useful?
A. They eliminate the need for all authorization
B. They allow access to managed services through internal paths
C. They make every workload publicly reachable
D. They disable encryption requirements
Correct Answer: B. They allow access to managed services through internal paths
Question 6
Which practice best protects a cloud database?
A. Allowing access from every virtual-network address
B. Exposing the database directly to the internet
C. Allowing connections only from approved application identities or groups
D. Using one shared administrator account
Correct Answer: C. Allowing connections only from approved application identities or groups
Question 7
What is a limitation of autoscaling as a DDoS defence?
A. It can increase cost while the attack continues
B. It prevents all application-layer attacks
C. It disables load balancing
D. It removes the need for rate limiting
Correct Answer: A. It can increase cost while the attack continues
Question 8
What does DNSSEC primarily provide?
A. Confidentiality of all DNS queries
B. Authenticity and integrity of signed DNS responses
C. Encryption of database backups
D. Automatic firewall configuration
Correct Answer: B. Authenticity and integrity of signed DNS responses
Question 9
Which infrastructure-as-code practice improves security?
A. Storing secrets directly in source files
B. Avoiding peer review to increase deployment speed
C. Using version control and automated policy checks
D. Disabling drift detection
Correct Answer: C. Using version control and automated policy checks
Question 10
Which statement reflects the shared responsibility model?
A. The provider is always responsible for customer firewall rules
B. The customer has no responsibility when using managed services
C. Security duties are divided between provider and customer according to the service
D. Only application developers are responsible for security
Correct Answer: C. Security duties are divided between provider and customer according to the service