CCSP Cloud Security Concepts: Key Management, Access Control, Sanitization, Network and Virtualization Security

Cryptography protects data in three states: at rest (storage encryption of volumes, objects and databases), in transit (TLS between clients and services and between services) and in use (confidential computing, where data stays encrypted in memory inside a hardware-protected enclave while it is processed). Symmetric algorithms such as AES use one shared key and are fast, so they encrypt the data itself; asymmetric algorithms such as RSA and elliptic-curve cryptography use a public/private key pair and are used to exchange or wrap keys and to sign. A hash (for example SHA-256) is a one-way fingerprint that proves integrity but cannot be reversed, and a digital signature is a hash signed with a private key, proving both integrity and origin. Keys live either in a hardware security module (HSM), a tamper-resistant device that never releases key material in plaintext, or in a software key management service, which is cheaper and usually backed by provider HSMs; the choice is driven by risk and by compliance requirements such as FIPS 140-3 validation.

In the cloud, encryption is only as strong as the custody of its keys: the decisive question is not which algorithm protects the data but who can use the keys and therefore who can decrypt. Every key management option is a point on a line that trades control against operational burden. The further the keys move away from the provider, the less the provider can read your data, and the more you become responsible for keeping those keys available.

The models differ on two separate questions, and requirements usually turn on one of them. Who creates and can withdraw the key material? With BYOK the customer generates the key and can delete it from the provider, yet no customer system takes part in day-to-day decryption. Can the provider read the data at all? Any model in which the provider's service performs the decryption, including BYOK, a provider-operated single-tenant HSM and an external key manager, leaves the provider technically able to decrypt while access is granted; an external key manager gives the customer a veto and the power to revoke, not technical inability. Only client-side encryption, where data is encrypted before it reaches the provider and the keys never enter it, makes the provider technically unable to decrypt, which also means its services cannot index, search or process the plaintext. A FIPS 140-3 validation says the cryptographic module is sound; it says nothing about who controls the keys inside it. Note that vendors use "hold your own key" differently: some mean an external key manager the provider calls, while Microsoft's HYOK for its information-protection service means content protected with an on-premises key the cloud service never uses.

Holding your own keys moves an availability risk onto you. If the provider must call your external key manager for every decryption, an outage of that key manager is an outage of the cloud service, and a lost key means lost data. The right design response is to treat the key manager as critical infrastructure: a high-availability cluster across sites, tested key backups and recovery procedures. Any arrangement that also leaves a usable copy of the key with the provider removes the very separation that holding it yourself was meant to create.

Envelope encryption is a key hierarchy in which data encryption keys (DEKs) encrypt the data and a key-encryption key (KEK), also called a wrapping or master key, encrypts the DEKs. The KEK never touches the data directly; it protects keys. The wrapped DEK is stored alongside the ciphertext, while the KEK stays in a key management service or HSM, so the keys that can unlock the data are kept apart from the data they protect.

The hierarchy is what makes rotation practical at cloud scale. Rotating the KEK touches only keys, never the bulk data: either the service unwraps each DEK with the old KEK and re-wraps it with the new one (a few hundred bytes per object instead of re-encrypting terabytes), or, as many provider key services do, it keeps the old KEK version available to unwrap existing DEKs and uses the new version for all new wraps. Either way, a periodic rotation requirement for the key protecting stored data is met at the KEK level with the least effort. Re-encrypting the data itself is the heavy alternative, reserved for when a DEK is suspected of compromise. Compliance with a rotation policy means meeting it as written, across all the data in scope; changing the policy's terms to fit what is convenient is a policy decision for the risk owner, not a way of complying.

Key management also covers the full key lifecycle: generation with a good random source, distribution, storage in tamper-resistant hardware where risk warrants it, use under least privilege, rotation on a defined cryptoperiod, backup or escrow where recovery is needed, revocation, and destruction. Separation of duties applies: the people who administer the key service should not be the same people who can read the data it protects.

Cloud identity and access control means proving who or what is calling (authentication) and limiting what each identity may do (authorization) for three different populations: people using services, administrators and workloads calling other workloads. Each has its own typical failure and its own fix.

User access: federation and lifecycle

Federation lets a cloud service trust assertions from the organization's identity provider (IdP) instead of keeping its own passwords. SAML 2.0 and OpenID Connect sign users in; OAuth 2.0 delegates authorization to applications; SCIM (System for Cross-domain Identity Management) is the standard that creates, updates and removes accounts in cloud applications from a central directory. Federation alone stops a disabled user from signing in through the IdP, but only provisioning closes the account itself and its local credentials or tokens. Tying both to the joiner-mover-leaver process means a leaver loses access everywhere at once. Movers are the subtle case: if roles are only ever added, people keep their old job's permissions (privilege creep). Deriving application roles from HR job attributes makes a transfer remove the old roles as well as add the new ones, without depending on periodic manual reviews.

Privileged access: just-in-time elevation

Privileged access management in the cloud means that no one holds administrator rights permanently: rights are granted just in time, for the duration of a task, approved by someone other than the requester, and fully logged. Rights that are held permanently but used rarely are standing privilege an attacker can steal at any time. Controls that harden standing privilege (stronger authentication, periodic reviews, network restrictions) reduce the risk but still leave the privilege standing; just-in-time elevation removes it between tasks.

The control loses its value when it is implemented loosely. Self-approval and grants far longer than the work turn just-in-time access back into standing access with extra steps. The intent depends on independent approval and a grant length that matches the task; controls added around an over-long, self-approved grant, or reviews after the fact, do not restore it.

Privileged identities should also be separate from everyday ones. An administrator who reads email and browses with the account that holds tenant admin rights lets one malicious link become a tenant compromise. The fix is a dedicated privileged account used only from a dedicated administrative workstation. Protections layered onto a combined account make compromise less likely but leave everyday activity and admin rights in the same identity.

Break-glass accounts

Break-glass (emergency) accounts keep administrators in control when federation fails. They should be cloud-native accounts that do not depend on the corporate IdP, few in number (commonly two), protected by strong hardware MFA, with credentials vaulted under dual control, and alerted on every use. An emergency account that can be used without security noticing is a backdoor, so alerting on use is the control that matters most; credential hygiene and periodic testing build on it. The design principle is independence without standing privilege: anything that still relies on the corporate identity system fails with it, and anything that gives individuals permanent or long-lived admin access recreates the risk break-glass is meant to contain.

Service access is how workloads authenticate to cloud APIs and to each other, and the secure pattern is no stored secret at all: the platform issues the workload an identity and short-lived credentials that it rotates automatically. Any long-lived secret can leak, through code repositories, logs or backups. Measures that protect the secret better reduce the exposure but leave the root cause in place, which is that a static secret exists at all; giving the virtual machine, container or function a platform identity removes it.

Between services, authenticate the workload, not its address. In container clusters, pods are rescheduled and IP addresses reused, so IP-based trust lets a compromised pod impersonate other services. Any identifier the workload can assert about itself, or any credential shared across many workloads, has the same weakness: one compromised workload can claim to be another. Issuing each workload its own short-lived certificate and requiring mutual TLS gives cryptographic, per-workload identity on both ends of every call; authorization policies can then be written against those identities.

Media sanitization makes data on storage unrecoverable, and in a multi-tenant cloud the practical method for customers is cryptographic erase (crypto-shredding): destroy every copy of the keys that encrypted the data, and the remaining ciphertext is unreadable. NIST SP 800-88, the media sanitization guideline, groups methods into clear, purge and destroy; overwriting, degaussing and physical destruction all require access to the physical media, which cloud customers do not have.

Overwriting fails in the cloud for an architectural reason rather than a technical weakness of the overwrite itself. A virtual volume is an abstraction over storage the provider controls: blocks are replicated, snapshotted, cached and remapped, so the customer can neither reach every copy nor prove it was overwritten. Logs of multi-pass overwrites are therefore weak audit evidence.

Crypto-shredding has two preconditions. First, the keys must be tenant-specific: if a SaaS provider encrypts all customers' data under its own platform keys, it cannot destroy one customer's key without destroying everyone's, so cryptographic erase at exit has to be secured in the contract up front (dedicated keys, destroyed with written attestation). Second, every copy of the key must be destroyed, including keys replicated to other regions, backups and escrowed copies held by third parties; until the last copy is gone, the data remains recoverable. The best evidence for auditors combines the customer's own key-destruction records with the provider's independent audit report (for example a SOC 2 Type II report, or an ISO/IEC 27001 certification whose scope covers media handling, which is less specific about sanitization) showing how it sanitizes and destroys its physical media.

A network security group is a virtual firewall attached to instances or network interfaces that allows traffic by source, destination, port and protocol, and it is the main software-defined network control in the cloud alongside traffic inspection and geofencing. They are usually stateful (return traffic for an allowed connection is permitted automatically), unlike the stateless subnet-level access lists many platforms also offer, and they do not look at request content. That is why tightening a security group cannot stop SQL injection: the attack arrives on the allowed web port, and blocking it needs application-layer inspection such as a web application firewall.

Security groups also enable microsegmentation. Rules that reference another group ("allow the database port from members of the application tier group") follow workloads as they autoscale, whereas rules based on subnet ranges or individual addresses are either too broad or need constant maintenance. Segmenting by group membership limits lateral movement, such as a compromised web server reaching the database directly.

Traffic inspection

Customers cannot place hardware taps or span ports in a provider's network, so payload inspection uses the provider's traffic mirroring feature to copy virtual machine traffic to a virtual IDS or sensor. Flow logs record metadata (who talked to whom, on which port, how many bytes) but not payloads; they show that a conversation happened, not what was said. Encrypted traffic must be decrypted (for example at a TLS-inspecting proxy) before its content can be examined. Applications that use certificate pinning accept only their expected certificate and break under interception, even if the proxy's root certificate is installed. The balanced response is to exempt those destinations from decryption, keep monitoring them by connection metadata, and keep inspecting everything else.

Geofencing

Geofencing restricts activity by location, and it has two different meanings that must not be confused. Access geofencing blocks sign-ins or API calls from certain countries, using IP geolocation; a VPN or proxy in an allowed country defeats it, so it is a supplementary layer, not a strong control. Resource geofencing restricts where resources, data and backups may be created, through tenant-wide policies that deny regions outside the approved boundary. Data residency requirements (keep personal data in the EU) concern where data is stored and processed, so only the second kind meets them. Residency is a property of storage location, so it is enforced by controls on where resources are placed, not by controls on identity, connectivity or encryption.

Virtualization security protects the isolation between workloads that share physical hardware, which is the foundation of multi-tenancy. The hypervisor is the boundary. A Type 1 (bare-metal) hypervisor runs directly on the host hardware, while a Type 2 hypervisor runs as an application on a host operating system and inherits that operating system's attack surface; providers use Type 1 for multi-tenant infrastructure because fewer layers mean a smaller attack surface. The most direct threat to tenant confidentiality is VM escape: an attacker in one guest exploits a hypervisor flaw to reach the host or other tenants' memory. Side-channel attacks against shared CPUs and caches are a related co-residency risk.

Customers cannot patch the provider's hypervisor, so a customer worried about neighbours on the same host removes the neighbours: dedicated hosts (single-tenant hardware within the public cloud) address co-residency directly. Controls on data, networks or the provider's processes are useful but do not stop an attack that runs on the same physical processor; only removing co-residency does.

Containers share the host kernel, so a kernel exploit in one container can affect every container on the host. Namespaces, cgroups, read-only root filesystems, non-root users, dropped capabilities and network policies harden containers but do not give each one its own kernel. When customers' untrusted code must run on shared hosts, the strongest isolation that keeps container tooling is a sandboxed runtime or lightweight virtual machine per tenant, which puts a kernel boundary back between them.

Container security also lives in the supply chain. Vulnerable packages in production containers are prevented, not just detected, by scanning images in the build pipeline, signing approved images and deploying only signed images from a private registry. Containers are meant to be immutable: you fix the image and redeploy. Changes made inside running containers are lost on the next deployment, and detection in production finds problems only after they have shipped.

Ephemeral computing means instances and execution environments that exist only briefly and are created and destroyed automatically, as in autoscaling groups and serverless functions. Their security consequence is that evidence disappears with them: there is often no disk to image after the fact. Investigations must be prepared in advance by shipping logs, traces and audit records to a separate, durable log store as they are produced. Forensic techniques that assume a long-lived host the customer controls do not apply to environments the customer does not run.

When detection flags a suspicious instance in an autoscaling group, the first move is to keep it from vanishing while taking it out of service: detach it from the scaling group (so automation will not terminate or replace it) and move it to an isolating security group, then capture memory and disk. The order matters: containment must not destroy volatile evidence, and preserving evidence must not leave a compromised instance serving traffic.

Serverless shifts the runtime, operating system and scaling to the provider, but the customer still owns the function code, its dependencies, its configuration and its permissions. A vulnerable open-source library is the customer's problem, and the damage of exploiting it is set by the function's identity. If every function shares one broad role, one compromise reads every bucket; a narrowly scoped identity per function limits the blast radius. Dependency scanning reduces the chance of compromise, while least privilege limits what a compromise can reach.

The common cloud threats are the ones that exploit how cloud is consumed: self-service configuration, internet-reachable management interfaces, shared infrastructure and pay-per-use elasticity. Industry lists such as the Cloud Security Alliance's top threats research consistently put customer-side failures ahead of exotic attacks on the provider; the CSA's current list is led by misconfiguration and inadequate change control, identity and access management, and insecure interfaces and APIs, while several rows below (insiders, data loss, shared technology) come from its earlier editions.

Two distinctions are worth holding on to. Against adversary-in-the-middle phishing, passwords, SMS codes, authenticator-app codes and push approvals can all be relayed or approved by a deceived user; only authenticators that check the origin of the sign-in page, such as FIDO2 security keys, refuse to respond to a fake site. And against denial of wallet, the requests usually look valid and the service stays up, so protections that look for floods of malformed traffic may not engage, and cost monitoring only reports the damage: the control has to cap consumption itself.

Security hygiene is the routine discipline of keeping systems in a known secure state, and it starts with a documented secure baseline: the approved configuration, usually derived from a published hardening benchmark (such as the CIS Benchmarks), that says which services are disabled, which settings are required and which patch level is acceptable. Hardening applies the baseline (removing unneeded services, accounts and ports, setting secure defaults); baselining makes it measurable. Only when every system is continuously checked against the baseline can drift be detected, whether it is an extra running service or a missing patch. Tools that check only one dimension (patch level, say) miss the rest of the baseline, and hardening applied once without ongoing checks cannot reveal later change.

Patching follows the shared-responsibility line. In IaaS the provider patches the physical hosts and hypervisor, and the customer patches the guest operating system and everything installed on it, using its own process and prioritizing exposed systems. A provider statement that its hypervisor is unaffected says nothing about the customer's guests. In PaaS and SaaS the provider takes on progressively more of the stack.

Baselines need a governed way to handle legitimate exceptions. When a required setting breaks a business-critical legacy application, the answer is an approved, time-bound exception for the affected systems, with compensating controls, recorded so it is reviewed and expires. The principle is that exceptions are managed risk: scoped to the affected systems, owned, compensated and expiring, rather than changes that alter the standard itself or make the deviation invisible.

Immutable architecture

Immutable architecture means servers are never changed after deployment: to patch or reconfigure, you update the versioned image (or the infrastructure-as-code definition), build new instances from it and replace the old ones. Because nobody logs in to modify running systems, there is no configuration drift, every running server matches a known image, and every change is auditable through the image history and the pipeline that built it.

Any approach that changes long-lived servers in place, however well automated or audited, lets individual servers diverge; accountability for those changes is useful but is not consistency. Immutability also simplifies rollback: when a new image misbehaves, the fastest route to a known-good, consistent fleet is to redeploy from the previous known-good image version and retire the faulty instances; the image history already holds a tested state to return to.

Immutable infrastructure works together with the other hygiene practices: the baseline is built into the image, the image is scanned and signed in the pipeline, and drift detection becomes simpler because any difference from the image is by definition unauthorized. It also suits ephemeral computing, where instances are disposable by design.