10.4 Cloud Storage Models & Object Storage Security

10.4 Cloud Storage Models & Object Storage Security

Quick Answer: Cloud storage is not one security boundary. Block storage presents volumes to compute, file storage presents shared paths, object storage presents objects and metadata through APIs, databases expose structured operations, archives trade retrieval speed for retention economics, and ephemeral storage disappears with a workload. Secure design starts with the access model and then applies identity, network, encryption, lifecycle, backup, monitoring, and deletion controls appropriate to that model.

Storage models

Block storage exposes addressable blocks or a virtual disk. A guest OS creates a filesystem or database on the volume. Security includes attachment permissions, snapshots, guest access, encryption, backup, and sanitization. A snapshot can contain the entire filesystem even when file-level permissions were restrictive.

File storage exposes a hierarchy of directories and files through protocols such as NFS or SMB. Identity mapping, share export rules, file permissions, protocol security, snapshots, and ransomware protection matter. A broad network path or anonymous export can bypass expected application controls.

Object storage stores an object payload plus metadata in a bucket or container and is accessed through provider APIs. It is highly scalable and commonly used for application assets, logs, data lakes, backups, and static sites. Authorization is policy based rather than a mounted filesystem permission model.

Managed databases expose query or record operations. The customer controls data, database identities, schemas, and many network and encryption choices, while the provider operates selected engine and infrastructure layers. Backups, replicas, exports, and analytics copies are separate data locations that require governance.

Archive storage reduces long-term storage cost with slower or staged retrieval. Security planning must include key retention, legal hold, restoration time, and proof that archived data can actually be recovered.

Ephemeral and local workload storage may exist only for the lifetime of a VM, pod, or function environment. It is useful for scratch data but unsuitable as the only copy of durable evidence or business state.

Object authorization is a combined decision

An object request may be affected by organization policy, account policy, bucket or container policy, identity permissions, object ownership settings, access-control lists, a service role, and an explicit deny. Evaluate the effective decision, not one screen in the console.

Prefer a private-by-default pattern:

• block public access at the broadest practical scope;
• grant applications a dedicated workload identity;
• restrict permissions to the needed bucket, prefix, operation, and condition;
• use private service endpoints when the workload does not need internet access;
• separate write, read, retention, and administrative roles; and
• continuously analyze policies for public, cross-account, or unused access.

Anonymous public access may be appropriate for a deliberately public static asset, but it should be isolated from sensitive data and supported by an explicit business decision. Do not mix public website content and confidential records in one security boundary.

Pre-signed URLs and delegated access

A pre-signed URL carries a time-limited authorization signature. Anyone who obtains the URL can normally use it until it expires or an underlying permission is revoked. Treat it as a bearer capability:

• generate it from a narrowly privileged identity;
• bind it to one object and required operation;
• use the shortest practical lifetime;
• deliver it only over protected channels;
• avoid placing it in analytics, referrer, or support logs;
• validate content type, size, checksum, and malware policy for uploads; and
• record generation and use where the service supports it.

A pre-signed URL is not a substitute for application authorization. The application must decide that the user may receive it before generating it.

Encryption and keys

Provider-managed encryption at rest protects physical media and is a useful baseline. Customer-managed keys can add policy, audit, separation, and revocation options. Client-side encryption can keep plaintext from the storage service but shifts key availability, search, processing, and recovery duties to the customer.

Encryption does not prevent an authorized or publicly allowed API read from returning plaintext. It must be combined with least-privilege access, data classification, sharing controls, and monitoring. Key policy should prevent a workload administrator from silently granting itself key administration or deleting the only recovery key.

Versioning, immutability, and recovery

Object versioning retains prior versions after overwrite or deletion and can aid recovery from error or ransomware. Immutable retention or object lock can prevent alteration for a defined period. Governance mode may permit specially authorized overrides; compliance-style modes may be more restrictive. The exact provider behavior, retention clock, legal hold, and deletion semantics must be understood before use.

Protect lifecycle policy because a hostile rule can expire versions or move evidence unexpectedly. Isolate backup copies from production identities and test restoration, including keys and metadata. Replication improves availability but can copy corruption or malicious deletion unless version and retention controls interrupt the path.

Monitoring and data events

Management events show bucket creation and policy changes. Object data events show reads, writes, and deletions but may need explicit enablement and can be high volume. Combine them with identity, network, DLP, and application context. Alert on new public access, broad cross-account grants, disabled logging, unusual enumeration, large downloads, retention changes, and access from unexpected identities or regions.

Inventory and classification should find abandoned buckets, sensitive unlabeled objects, old snapshots, public access, stale pre-signed sharing patterns, and replicas outside approved locations. Storage security is continuous because APIs make data easy to copy even when the original bucket is well controlled.