Glossary
Cloud storage security
Cloud storage security covers the controls that protect data held in cloud or object storage from unauthorized reading, alteration and deletion. For S3-style object storage it rests on four mechanisms: access policy, encryption, versioning with retention locks, and activity logging.
Shared responsibility stops at the bucket policy
Cloud security divides duties between provider and customer, and storage shows exactly where the line falls. The provider protects facilities, hardware, hypervisors and service software. Operating system patching shifts to the provider in platform and software services, yet one layer never moves in any model: identities, permissions and data stay with the customer. A managed object storage service secures its servers and disks and leaves bucket policies, keys and encryption choices to whoever owns the account.
On a private cloud or an owned object store, one organization holds both sides of that line. Hardware, patching, network segmentation and physical access sit with the same team that manages identities and data, which removes the ambiguity of a split and adds the operational load. A hybrid estate with two public clouds and an on-premises object store runs at least three permission models, three sets of keys and three audit trails, and an intruder only needs the weakest of them.
Exposure, theft and destruction mapped to controls
A large namespace concentrates risk: years of customer records, research data, media and backups for hundreds of applications behind one API. One public bucket exposes all of it at once, and one stolen administrative key can delete or encrypt it at machine speed. A store serving billions of requests a day also hides a few thousand malicious calls inside ordinary traffic, so controls have to act on each request without human review.
| Threat | How it happens | Primary controls |
|---|---|---|
| Public exposure | A bucket or object readable without authentication | Access policy, public-access blocks, configuration scanning |
| Credential misuse | Valid keys used by someone other than their owner | Short-lived credentials, least privilege, network conditions |
| Destruction | Objects deleted or overwritten with encrypted versions | Versioning, retention locks, separate copies |
| Exfiltration | Bulk reads copied to an outside location | Scoped read rights, endpoint policies, transfer monitoring |
| Media compromise | Physical access to drives or retired hardware | Encryption at rest |
Extortion campaigns frequently pair destruction with data exfiltration: data is copied out first, then what remains is deleted or encrypted. Long-lived access keys stolen from scripts, laptops or code repositories are a common way in, the pattern described under credential theft.
Policy evaluation and key custody
An S3-compatible store evaluates several policy types on every request: identity policies on users and roles, bucket policies, older per-object access control lists and time-limited presigned URLs. Access exists only where a policy explicitly allows it, an explicit deny anywhere overrides every allow, and public-access blocks sit above all of them to override anything that would make data public.
Encryption at rest comes in four arrangements, told apart by who holds the key: the storage service with its own keys, the service with keys in a separate key management system, the service with a key the client supplies per request, or the client before upload. Server-side schemes usually wrap a per-object data key with a master key, so reaching the master key becomes a second check, and customer-managed keys move that check under the data owner's control. Encryption protects confidentiality and nothing else. An identity with delete rights removes encrypted objects as easily as plain ones.
Governance mode, compliance mode and legal hold
Versioning keeps earlier versions when an object is overwritten, and a plain delete only adds a delete marker, but an identity allowed to delete specific versions can still remove them. S3 Object Lock, which requires versioning, adds write-once-read-many retention to each version.
- Governance mode can be bypassed by any identity holding
s3:BypassGovernanceRetentionthat sendsx-amz-bypass-governance-retention:true. - Compliance mode resists all users, including the account root, until the retain-until date.
- Legal hold blocks deletion with no end date until the hold is lifted.
Retention expires: locked data is protected for a defined window, after which normal permissions apply again.
Designing for the credential that leaks
The design question moves from who can get in to what survives once someone has. Policy and encryption protect data only while credentials stay in the right hands, and with hundreds of applications and service accounts holding keys to a petabyte namespace, one of them will leak sooner or later. The versions held under compliance-mode retention are the ones still recoverable whichever key was taken.
Lock windows carry a capacity cost. Every locked version occupies space until its retain-until date, including versions an attacker overwrote. A 30-day compliance window on a store that rewrites 2 percent of its data daily holds roughly 60 percent of the store's size in extra versions at steady state (30 × 2 percent), which makes lock periods a capacity planning input as much as a security setting.
Scope turns a leak into a contained incident. A key limited to one bucket and a few actions exposes one dataset; a single key with full rights across a multi-tenant namespace turns the same leak into an outage for every tenant. Logs complete the picture only if they outlive the intruder. Management events record policy and retention changes, data events record individual reads and deletes, and an attacker with administrative rights on the storage account can erase both unless they land in a separate system under different credentials, where breach containment and later investigation can use them.
Jurisdiction is the last layer. For regulated and public-sector data, the question extends from who can log in to which government can compel the operator to hand data over, and that decides whether a dataset sits in a hyperscale region, a sovereign cloud or owned infrastructure.
Scality RING and cloud storage security
RING supports S3 Object Lock in governance and compliance modes, with retention periods and legal holds, on versioned buckets. A stolen key that holds s3:BypassGovernanceRetention and sends x-amz-bypass-governance-retention:true can lift governance retention on RING as anywhere else, while compliance retention resists every user, the account root included, up to the retain-until date. RING does not stop a valid key from reading data, so exfiltration stays a question of policy scope and monitoring. On ARTESCA, audit logs can be forwarded to Splunk, Graylog, Elasticsearch or syslog, outside the storage system. Scality's ADI page describes its CORE5 design as "immutability, durability, metadata protection, multi-site replication, and policy enforcement built across five architectural layers".