4.3 Infrastructure and cloud security¶

Overview and motivation¶

Applications run on infrastructure, and these days that infrastructure is largely cloud-based, software-defined, and always changing. A single engineer can now provision a database, open a network path, or grant a permission with one command, at a scale and speed traditional change control never anticipated. That power is exactly why misconfiguration, not exotic exploits, is the leading cause of cloud breaches. An accidentally public storage bucket or an over-broad access role can expose an entire organization's data in seconds.

For large enterprises, cloud infrastructure spans multiple providers, thousands of accounts, and a mix of managed services, containers, and serverless functions. The attack surface is not a static perimeter. It is a living, sprawling collection of resources and identities. For government, the same complexity meets strict authorization regimes, data residency mandates, and classification boundaries that shape every architectural choice. In both, the identity layer has become the new perimeter: who can do what, to which resource, under what conditions.

This chapter covers how to secure that foundation: identity and access management (IAM), network segmentation, encryption and key management, the security of containers and serverless workloads, and the continuous posture management that keeps a fast-moving cloud estate from drifting into danger.

Key principles¶

• Identity is the perimeter. Access decisions hinge on strong identity and fine-grained authorization, not network location.
• Least privilege, always. Every identity, human or machine, gets the minimum permissions needed, and no more.
• Segment to contain. Divide networks and workloads so a compromise in one area cannot spread freely.
• Encrypt everywhere. Protect data in transit and at rest by default, with well-managed keys.
• Immutable and declarative. Define infrastructure as code (IaC), deploy immutably, and treat drift as a defect.
• Continuous verification. Posture is not a one-time audit; scan and enforce continuously.
• Secure by default configuration. The default state of any resource should be locked down, not open.

Recommendations¶

Design identity and access management deliberately¶

IAM is the most important part of cloud security, and the most frequently mismanaged.

• Use role-based access control (RBAC) to grant permissions by job function, and attribute-based access control (ABAC) where finer, context-aware decisions are needed (based on tags, environment, data classification, or time).
• Eliminate long-lived static credentials in favor of short-lived, automatically issued tokens and workload identity federation.
• Enforce MFA (multi-factor authentication) for all human access and require strong authentication for privileged actions.
• Apply least privilege rigorously: start from zero and add permissions deliberately. Regularly review and prune unused permissions; access tends to accumulate.
• Separate duties so that no single identity can both make and approve sensitive changes.
• Use dedicated accounts or projects to create hard boundaries between environments (production, staging, development) and between business units.

Segment networks and micro-segment workloads¶

Flat networks let attackers roam sideways once they are in. Divide and contain.

• Segment at the network level into tiers and zones, allowing only the traffic each tier legitimately needs.
• Apply micro-segmentation so that individual workloads communicate only with the specific peers they require, enforced by identity-aware policy rather than broad subnet rules.
• Default-deny east-west traffic; require explicit allow rules.
• Place sensitive data stores in private subnets with no direct internet exposure, reached only through controlled paths.
• Use private connectivity to managed services instead of routing over the public internet where possible.

Encrypt data and manage keys properly¶

Encryption is only ever as strong as the key management behind it.

• Encrypt in transit with current TLS (Transport Layer Security) everywhere, including internal service-to-service traffic.
• Encrypt at rest by default for all storage, databases, and backups.
• Manage keys with a Key Management Service (KMS), and use a Hardware Security Module (HSM) for the highest-assurance keys and for regulatory requirements.
• Rotate keys on a schedule and support rapid rotation on suspected compromise.
• Control and audit who can use and manage keys separately from who can access the data, so key custody enforces separation of duties.
• Consider customer-managed keys where regulation or contractual trust requires the organization to hold the keys rather than the provider.

Secure containers, Kubernetes, and serverless¶

Each compute model brings its own risks.

• Containers: build from minimal, trusted base images; scan images for vulnerabilities before deployment; run as non-root; make filesystems read-only where possible; and never bake secrets into images.
• Kubernetes: enable RBAC and scope service accounts tightly; apply network policies for micro-segmentation; use admission controllers and policy engines to enforce standards; restrict privileged containers; isolate sensitive workloads; and keep the control plane and nodes patched.
• Serverless: apply least privilege to each function's execution role (a common source of over-permissioning); validate all event inputs; manage secrets through the platform's secret store; and monitor for anomalous invocation patterns.

Whatever the model, keep the runtime patched and the images fresh. A container is only as secure as the software inside it.

Manage cloud security posture continuously¶

The cloud changes far too fast for periodic manual audits to keep up.

• Adopt Cloud Security Posture Management (CSPM) tooling to continuously detect misconfigurations, public exposure, and policy violations across accounts.
• Define security policy as code and enforce it at deployment time so bad configurations are blocked before they land.
• Prefer prevention (guardrails that stop misconfiguration) over detection (alerts after the fact), and combine both.
• Maintain an accurate inventory of resources and identities; you cannot secure what you cannot see.
• Track and remediate drift between declared infrastructure-as-code and the actual running state.

Trade-offs: pros and cons¶

The dominant trade-off is control versus operational burden. Tighter controls (customer-managed keys, strict micro-segmentation, ABAC) reduce risk, but they demand expertise and maintenance that small teams struggle to sustain. The right level depends on how sensitive the data is and what regulations apply. A pragmatic approach layers strong secure defaults for everyone, then reserves extra rigor for the highest-risk systems, and it favors automated guardrails that make the secure choice the default rather than a manual discipline.

Examples¶

Startup. A small startup runs everything in one cloud account and cannot staff a platform team, so it leans on defaults that ship secure: encryption at rest on by default, storage buckets private unless a human explicitly opens them, and MFA required on the root account. Instead of long-lived access keys pasted into CI, it uses the provider's built-in workload identity so the pipeline gets short-lived credentials automatically. A single free guardrail that flags any database opened to the internet saves them from the most common and most costly cloud mistake, at a cost of one afternoon to set up.

Enterprise. A media company running thousands of accounts across two cloud providers enforces a landing-zone pattern: every account is provisioned from a template with encryption-at-rest on by default, no public access on storage, mandatory tags, and a baseline of guardrail policies. CSPM continuously scans for drift, and workload identity federation has eliminated long-lived keys for CI systems. When a developer accidentally attempts to open a database to the internet, a preventive policy blocks the change and files a ticket automatically.

Government. A defense-adjacent agency operates in an isolated cloud region with data residency enforced by policy so no data leaves national boundaries. The most sensitive keys live in FIPS-validated (Federal Information Processing Standards) HSMs, with key custody separated from data access to enforce separation of duties. Kubernetes clusters use strict network policies and admission controls; every container image is scanned and signed before it may run. Continuous posture management feeds directly into the agency's ongoing authorization evidence.

Business case: motivations, ROI, and TCO¶

Cloud infrastructure security is where a small investment heads off catastrophic, headline-grade losses. The total cost of ownership includes CSPM tooling, key management services, the engineering time to design least-privilege IAM and segmentation, and the ongoing effort to keep policies current. These costs are real but modest. The cost of skipping them is a single misconfigured resource exposing an entire customer database, along with the regulatory fines, notification costs, and lasting brand damage that follow. Cloud misconfiguration breaches are among the most common and most preventable incidents in the industry.

Automation and reuse amplify the ROI. Encode secure defaults into landing zones and infrastructure-as-code templates, and every new account and workload inherits protection with no per-team effort, turning security from a recurring manual tax into a one-time platform investment. For government and regulated enterprises, strong posture management also lowers the cost of audits and continuous authorization by producing evidence automatically. When you make the case to leadership, stress that the identity and configuration layer is now the primary breach vector, that misconfiguration is preventable, and that guardrails cut both the risk and the friction of manual review.

Anti-patterns and pitfalls¶

• Wildcard permissions. Granting broad * access "to get things working" and never tightening it.
• Long-lived static keys. Access keys embedded in scripts and CI that never expire and eventually leak.
• Flat networks. No segmentation, so one compromised host reaches everything.
• Public by accident. Storage and databases exposed to the internet through default or careless settings.
• Encryption without key discipline. Enabling encryption but leaving key access wide open or never rotating.
• Secrets baked into images. Credentials embedded in container images that spread everywhere the image runs.
• Over-permissioned serverless roles. Functions granted far more than they need because scoping was skipped.
• Audit-only posture. Detecting misconfigurations after the fact instead of preventing them at deploy time.
• Ignoring drift. Letting the running environment diverge from infrastructure-as-code until no one knows the real state.

Maturity model¶

Level 1: Initial. Manual provisioning. Broad permissions and static keys. Flat networks. Encryption inconsistent. No posture management; misconfigurations found only after incidents.

Level 2: Repeatable. Some IAM roles and MFA. Basic network tiers. Encryption at rest enabled for major stores. Periodic manual configuration reviews. Infrastructure partly defined as code.

Level 3: Defined. Least-privilege RBAC/ABAC with short-lived credentials. Segmentation with default-deny east-west. Encryption in transit and at rest by default, keys in KMS with rotation. Container and Kubernetes hardening standard. CSPM in place with defined policies.

Level 4: Optimizing. Secure defaults baked into landing zones and IaC so every resource is born hardened. Micro-segmentation with identity-aware policy. Customer-managed keys and HSMs where required, with custody separation. Preventive guardrails block misconfiguration; drift is auto-detected and remediated; posture evidence feeds compliance continuously.

Ideas for discussion¶

1. Where is ABAC worth its complexity versus sticking with RBAC in your environment?
2. How do you eliminate long-lived credentials without breaking legacy automation?
3. What is the right split between preventive guardrails and detective posture management?
4. Which systems justify customer-managed keys or HSMs given their operational cost?
5. How do you keep least-privilege permissions from silently accumulating back to over-privilege?
6. How should multi-cloud complexity change your approach to consistent posture and policy?

Key takeaways¶

• Identity is the new perimeter; invest in least-privilege IAM with short-lived credentials.
• Segment networks and micro-segment workloads to contain compromise.
• Encrypt in transit and at rest by default, and manage keys with KMS/HSM and separation of custody.
• Harden containers, Kubernetes, and serverless; keep runtimes and images patched.
• Prefer preventive guardrails over after-the-fact detection, and manage posture continuously.
• Bake secure defaults into landing zones and infrastructure-as-code so protection scales automatically.
• Misconfiguration, not exotic exploits, is the leading cause of cloud breaches, and it is preventable.

References and further reading¶

• National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
• Center for Internet Security, CIS Benchmarks (cloud providers, Kubernetes, Docker)
• Cloud Security Alliance, Cloud Controls Matrix and Security Guidance for Cloud Computing
• NIST, SP 800-190: Application Container Security Guide
• Liz Rice, Container Security
• Marco Lancini and others, Cloud security posture and detection engineering literature
• Provider Well-Architected security pillars (as vendor-neutral architectural guidance)