Cloud security is mostly configuration security. The large providers operate infrastructure to a standard few organizations could match, and the incidents that occur are overwhelmingly caused by how customers configured what they rented rather than by failures of the platform.
That is good news, because configuration is within your control. It is also uncomfortable, because it means the responsibility cannot be transferred with the workload.
Definitions worth keeping straight
The word cloud is used loosely enough to obscure real differences. NIST's definition remains the useful reference, describing a model composed of five essential characteristics, three service models, and four deployment models.
The distinction that matters most for security is the service model, because it determines where your responsibility begins. Infrastructure leaves you the operating system, the patching and the network configuration. Platform services remove much of that and leave you identity, data and application configuration. Software as a service leaves you identity, data classification and whatever the vendor exposes as configuration, which is frequently less than you would like.
Deployment model matters too. Private cloud dedicated to one organization has a different exposure profile from a multi tenant public service, and hybrid environments carry both plus the connection between them.
Shared responsibility, and the part nobody reads
Every provider publishes a shared responsibility model, and every provider's model says the same thing in different words: they secure the infrastructure, you secure what you put on it and how you configure access to it.
The clause that surprises people is that responsibility for data is never transferred. Not for its classification, not for who may reach it, and not for whether it should have been placed there at all. A provider will encrypt storage, and the decision about who holds the keys and who can read the contents remains yours.
The practical exercise worth doing once, per platform, is to write down which controls the provider operates, which you operate, and which are shared. The shared row is where incidents live, because both parties assume the other has it.
Identity is the new perimeter, and it is not a slogan here
In a cloud environment there is no network edge to defend. Access is mediated by identity, and a credential with broad permissions is equivalent to physical access to a data center.
This makes the practices in identity and access management more consequential rather than less, with three cloud specific emphases. The control plane, where resources are created and permissions granted, is more valuable than any single workload and should be protected accordingly. Permissions granted to services rather than to people are the larger population and the less reviewed one. And the root or global administrator identity for each tenancy should be protected out of proportion to how rarely it is used.
Platform managed identities are the meaningful improvement cloud environments offer, because they remove the stored credential entirely. Where they are available and not used, that is a finding worth raising.
The configuration mistakes that actually occur
A small set of misconfigurations accounts for a large share of cloud incidents, and they recur across organizations.
- Storage exposed more broadly than intended, usually by a permission granted for a legitimate integration and never narrowed.
- Over privileged roles, assigned during development when the correct permission set was unknown and never reduced afterwards.
- Management interfaces reachable from anywhere, because restricting them was inconvenient during setup.
- Control plane logging disabled or not retained, which is discovered during an investigation.
- Resources created outside the governed process, in a subscription the central team does not know exists.
- Secrets in code or configuration rather than in a managed secret store.
None requires sophistication to exploit and all are detectable by inspection, which is why continuous configuration assessment is the highest value cloud control an organization can operate.
Network controls still exist
Cloud network controls are software defined and are frequently treated as less real than physical ones, which is a mistake. Virtual network boundaries, security groups and private connectivity to platform services do the same job as their physical equivalents and are easier to change, which is both the advantage and the risk.
The default posture in most environments is more permissive than an equivalent on premises design would be, usually because permissive settings are what made the deployment work. The correction is the same rule review discipline described in network security, applied to definitions rather than to appliances.
Encryption, and the key question
Encryption at rest is close to universal and close to free, and it defends against a narrow threat: physical access to the storage medium. It does nothing about a credential that is authorized to read the data.
The question worth asking is who holds the keys. Provider managed keys are operationally simple and mean the provider can technically access the data. Customer managed keys move that control to you along with the responsibility for not losing them. Neither is correct in general; the choice follows the data classification and any contractual obligation.
Encryption in transit is less negotiable and worth verifying rather than assuming, particularly for traffic between services inside a tenancy, which is occasionally left unencrypted on the reasoning that it is internal.
Logging in the cloud
Cloud platforms produce an audit trail of administrative actions that has no on premises equivalent: a record of who created, changed or deleted what, through the control plane.
It is also commonly left at defaults, which means short retention and incomplete coverage. Enabling it fully, exporting it somewhere the tenancy's own administrators cannot alter, and retaining it beyond the default window are three cheap decisions that determine whether a future investigation is possible. The collection and detection practice is covered in security monitoring and incident detection.
Workload security
Whatever runs on the infrastructure carries its own requirements. Virtual machines need the same treatment as any server, covered in endpoint and server security. Containers add image provenance, base image currency and registry control. Serverless functions shift attention to permissions and dependencies, since there is no host to harden.
Across all three, the recurring weakness is the supply chain of the image or package rather than the runtime configuration, and the recurring remedy is knowing what is inside what you deployed.
Software as a service, the estate nobody inventoried
Most organizations hold more data in software as a service applications than in infrastructure they operate, and those applications are usually governed least.
They are bought by departments rather than by technology functions, so they do not appear in an infrastructure inventory. Their security configuration is exposed through a vendor console that nobody reviews after onboarding. Their audit logging is frequently available only on a higher licence tier. And their access is granted directly rather than through the organization's identity system, which means a departure does not remove it.
Three practical steps address most of the exposure. Discover what is actually in use, which usually surprises people and can be derived from expenditure records and network resolution data. Connect what matters to the central identity system so that joining and leaving work. And review each application's own security settings once, deliberately, because defaults are chosen for ease of adoption rather than for your risk appetite.
Exit, and the question asked too late
Security reviews of cloud services concentrate on entry and rarely consider departure, which becomes a problem when a contract ends, a vendor is acquired, or a service is retired.
The questions worth answering before signing are how data is returned and in what format, how long the provider retains it after termination, whether backups are included in that deletion, and what evidence of destruction is available. A service holding regulated data with no documented deletion process is a liability that outlives the relationship.
Hybrid environments
Most organizations run hybrid rather than purely cloud, and the interesting risk sits at the join: the connectivity between environments, the directory synchronization that lets one identity work in both, and the trust relationships that make the arrangement convenient.
A compromise of the on premises directory in a synchronized environment is frequently a compromise of the cloud tenancy, and that dependency is worth drawing explicitly rather than discovering during an incident. The configuration discipline that keeps both ends honest is covered in security hardening and configuration management.
Running it as a service
Cloud environments change faster than on premises ones, which means configuration drifts faster and the assessment has to be continuous rather than annual. That is the argument made throughout the managed cybersecurity lifecycle, compressed into a shorter cycle.
LABUSA operates cloud configuration assessment, identity review, logging and workload protection within LABUSA's managed cloud and cybersecurity service, across public cloud and privately hosted infrastructure.
Sources
- NIST, The NIST Definition of Cloud Computing, SP 800-145, September 2011.
- NIST, Zero Trust Architecture, SP 800-207, August 2020.
- NIST, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5.