Cloud Data Concepts and Storage Architectures

What it is

Cloud data concepts describe how data lives in the cloud: the lifecycle it passes through, how the provider disperses it across hardware and locations, and the flows that carry it between systems and parties.

Storage architecture is where that data rests. Each storage type has its own use, its own threats and its own controls, and the exam expects you to match them.

How it works

Lifecycle phases in the cloud

The six CSA phases are Create, Store, Use, Share, Archive and Destroy. In the cloud, Create includes data generated by the provider's services, such as logs and metadata. Store usually happens immediately after creation, so protection at rest must be in place from the first write.

Data may skip phases or exist in several at once. One copy may be in use while a replica is archived and a cached copy sits at the edge.

Data dispersion

Providers spread data across many disks, nodes and often facilities for durability. Techniques include replication and erasure coding (also called bit splitting), where data is cut into fragments with parity so it can be rebuilt even if some fragments are lost.

Choose regions explicitly and confirm in the contract where replicas and backups may be stored.

Data flows

A data flow diagram maps where data enters, which components process it, where it is stored and where it leaves, including third parties. Flows show trust boundary crossings, which is where encryption in transit, authentication and DLP checks belong. They are also the evidence regulators ask for when personal data crosses borders.

Storage types

PaaS adds structured storage (databases) and unstructured storage (blobs, files). SaaS uses information storage and management, where data lives in the application, and content and file storage.

Threats to storage types

Across all types the common threats are unauthorized access, misconfiguration, data leakage between tenants, loss of keys, ransomware, and denial of service against the storage service.

Example: a deny public access policy idea

A storage policy can deny any request that does not arrive over TLS. In a JSON style policy it reads like this:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "storage:*",
  "Resource": "bucket/records/*",
  "Condition": { "Bool": { "SecureTransport": "false" } }
}

The names are generic; each provider has its own syntax, but the intent of deny by default is the same.

A worked example

A media company stores customer video uploads in object storage and user account data in a database on a volume. A security review finds snapshots of the database volume shared with an external analytics account, and one bucket readable by anyone.

The architect enables account wide blocking of public access, removes the snapshot share and replaces it with a sanitized extract sent through a documented data flow. Volumes and snapshots are encrypted with a customer managed key, so any future accidental share is unreadable without key access.

How the exam asks about this

• "Which storage type is attached to an instance like a hard drive and typically holds the operating system?" Volume storage.
• "Data is split into fragments with parity across several locations. What is this?" Data dispersion, using erasure coding or bit splitting.
• "What is the MOST common cause of data exposure in object storage?" Misconfigured access permissions, such as public buckets.