Block, Object, Ephemeral, Archive: Cloud Storage Architectures and the Threat Each One Invites

The threat each architecture invites

Objective 2.2 pairs the architectures with threats to storage types, and the useful way to learn them is that each architecture's strength is also its weakness.

The object storage row is the one the exam returns to most, because public bucket exposures are the cloud's signature breach. The control is not a better password. It is a default-deny posture enforced at the account level, so an individual bucket cannot be made public by a single mistaken setting, plus scanning that notices when one is.

Two more threats apply across every architecture. Unauthorized access through the management plane: whoever holds the cloud account's credentials can reach every volume, bucket and snapshot regardless of what is encrypted, so the storage controls are only as strong as the identity controls in front of them. And data remanence: when your volume is released, the physical media goes back to the provider's pool. The provider sanitizes it between tenants; your control is encryption with keys you control, so that whatever remains is ciphertext, which is why crypto-shredding is the only destruction a tenant can perform.

Archive tiers and the retrieval nobody budgeted

Archival storage is where the exam hides an availability question inside a cost question. Cold tiers are priced for data you will almost never read, and their retrieval takes hours and carries a per-request cost that can exceed a year of storage fees if you restore everything at once. A recovery plan that assumes backups in a cold tier can be restored inside a four-hour objective has an unexamined dependency, and a scenario where a recovery ran a day late because "the data was still being retrieved" is that dependency surfacing.

The second archival question is readability. Retention periods run to years. The application that wrote the data, the format it used and the keys that encrypted it all have to survive as long as the data does, or the archive is a compliance liability that cannot be opened. Restore tests on a schedule, not just backup jobs, are the control, and the exam treats a backup that has never been restored as untested.

Encryption by architecture

Every architecture supports encryption at rest, but who holds the key and where the encryption happens differs, and the exam tests the difference. Block volumes are typically encrypted by the platform with a key you can choose to manage, so the provider cannot read the disk but can still snapshot the ciphertext. Object storage offers server-side encryption with provider keys, with keys you manage in the provider's key service, or with keys you supply per request, and the last of those is the only option in which the provider never holds the key. Ephemeral disks are often encrypted by default with keys that die with the instance, which is the right property for scratch data. Archive tiers inherit whatever the object layer used, which means the key that encrypted a seven-year-old archive has to be available in seven years. Client-side encryption, performed before the data reaches any storage, is the architecture-independent answer for data the provider must never see, at the cost of losing every server-side feature that needs to read it.

Data dispersion and the storage question underneath it

Cloud providers do not store your object in one place. Data dispersion breaks it into fragments, often with erasure coding so that any subset can rebuild the whole, and spreads them across disks, racks and sometimes facilities. That gives durability far beyond a single disk, and it changes what "where is my data" means: the answer is a region and a durability figure, not a shelf. The lifecycle consequences, including what dispersion does to deletion, are covered in the cloud data lifecycle; the storage point is that dispersion is a property of object and archive storage, and a customer choosing a region is choosing the boundary within which the fragments stay.

Four stems, decoded

1. A start-up's application stores user session data and uploaded files on the instance's local disk; after an automated instance replacement, both are gone. Ephemeral storage used for persistent data. Sessions go to a cache service or database, files to object storage.
2. A security scan finds a storage container of customer invoices readable by anyone with the URL. Object storage exposed by a permissive policy. Block public access at the account level, deny by default, and scan continuously.
3. A team shares a snapshot of a production database volume with a partner's cloud account for testing. An unencrypted, or encrypted with a shareable key, block snapshot leaving the boundary. Mask the data, encrypt with customer-managed keys that are not shared, and restrict snapshot sharing.
4. A recovery test of a seven-year archive fails because the files are in a format the current application cannot open. Retention outlived readability. Plan formats and keys as part of retention, and test restores on a schedule.

Cloud data storage architectures are objective 2.2 of CCSP Domain 2, Cloud Data Security, 20% of the exam and its heaviest domain. They sit beneath the cloud data lifecycle and use the encryption, tokenization and masking methods the domain tests alongside them. Work all 29 topics with our CCSP Domain 2 study guide.

#CCSP #ISC2 #CloudSecurity #ObjectStorage #BlockStorage #CloudDataSecurity #DataProtection #StorageSecurity #InfoSec #CyberSecurity