Glossary

Cloud security

Cloud security is the protection of data, applications and infrastructure that run in cloud environments. It combines controls the cloud provider operates with controls the customer configures, chiefly identity and access, encryption, network isolation, configuration and monitoring.

Why cloud security matters for infrastructure teams

In a data centre, the network perimeter did much of the protective work: storage sat behind firewalls, and reaching it meant first getting inside. Cloud services are reached through public APIs, and every action, from reading an object to deleting a bucket, is an authenticated API call. Identity and configuration replace the perimeter as the main line of defence. Organizations that spread workloads across public clouds, private clouds and owned sites end up with several security models running side by side, each with its own controls, logs and gaps.

The shared responsibility model

Security duties in a public cloud are split between provider and customer. The provider protects the facilities, hardware, hypervisors and service software. The customer protects what it puts on top. Where the line falls depends on the service.

The bottom row never moves. In every model the customer decides who can reach the data and under what conditions. A managed object storage service secures its servers and disks, and leaves bucket policies, keys and encryption choices to the customer.

Main control areas

Identity and access. Users, service accounts and roles receive permissions, ideally limited to what each function needs. Long-lived access keys stay valid until revoked; short-lived credentials expire after minutes or hours. Stolen long-lived keys are a common route into cloud accounts, the pattern described under credential theft.

Data protection. TLS protects data in transit. Encryption at rest is applied with provider-managed keys, with customer-managed keys held in a key service, or by the client before upload. Whoever controls the keys controls whether the data can be read. Versioning, replication and retention locks address deletion and overwriting, which encryption does nothing to prevent.

Network isolation. Virtual networks, subnets, security groups and private endpoints limit which systems can talk to which services, and how far an intruder can move after compromising one workload.

Configuration and monitoring. Misconfiguration, such as storage left publicly readable or logging switched off, sits entirely on the customer side. Posture management tools scan for it continuously, and audit logs of API activity feed detection and investigation.

The same control areas apply to private clouds and on-premises object storage, with one difference: the organization running the platform holds both sides of the responsibility line. Hardware, patching, network segmentation and physical access then sit with the same team that manages identities and data, which removes the ambiguity of a split and adds the operational work.

What cloud security means for hybrid and multi-cloud estates

Each environment brings its own identity system. An organization running two public clouds and an on-premises object store has at least three permission models, three sets of keys and three audit trails. Attackers look for the weakest of them, and a broad key in any one environment can be enough to reach data replicated from the others.

Stored data is the target, so storage is where the last line of defence sits. Ransomware operators who gain administrative access go after stored data and its backups, deleting or encrypting them through ordinary API calls that look like routine administration. Controls that depend only on access rights fail as soon as those rights are stolen. Retention enforced by the storage itself, which no account can shorten, keeps working after credentials are lost. That is why immutability sits alongside identity in cloud security designs for data at scale.

Logs have to outlive the incident. An intruder with administrative rights in a storage account can also delete that account's logs. Shipping audit records to a separate system, under different credentials, keeps the evidence intact for breach containment and later investigation.

Sovereignty adds a further dimension. For regulated or public-sector data, the question extends beyond who can log in to which jurisdiction can compel the operator to hand data over, which shapes whether data sits in a hyperscale region, a sovereign cloud or owned infrastructure.

Security architecture in Scality RING

Scality describes RING's CORE5 architecture on the RING product page as "five layers of protection against ransomware, exfiltration, and credential compromise". RING supports S3 Object Lock in governance and compliance modes, with retention periods and legal holds, on versioned buckets. A governance-mode lock gives way to any identity holding s3:BypassGovernanceRetention that sends x-amz-bypass-governance-retention:true. Under compliance mode, nobody, the account root included, can remove a locked version or shorten its retention before the retain-until date passes.