Lesson A12.3
Cloud storage is secure only when the organization understands what data is stored, why it exists, who and what can reach it, where copies move, how long they remain, and which evidence proves the intended exposure.
This lesson uses fictional storage records, synthetic identifiers, and safe evidence. It does not involve real cloud storage consoles, accounts, credentials, databases, buckets, shares, or production data.
Lesson Progress
High School Advanced • A12: Cloud Security Architecture • Lesson 3 of 10
Readiness Check
0/4 ready
Professional Hook
A fictional student-support application may store its main records in a managed database. But the same information can also appear in backups, generated reports, analytics datasets, temporary exports, caches, file shares, or vendor integrations.
A storage review that examines only the primary database can miss the places where exposure actually grows.
Data security follows the data — including every approved copy.
Learning Objectives
Explain cloud storage security as a combination of data purpose, classification, access, exposure, lifecycle, encryption responsibilities, logging, and evidence rather than simply choosing a storage service.
Compare object storage, managed databases, file storage, backup repositories, analytics stores, and temporary export locations by security purpose and exposure risk.
Evaluate storage access paths, public/private state, identity scope, retention, encryption configuration, logging coverage, replication, and backup relationships using fictional cloud evidence.
Identify architecture risks such as overbroad access, unnecessary public exposure, stale exports, weak ownership, retention drift, unmonitored copies, and unclear data lifecycle.
Build a Cloud Storage Exposure Review that becomes the third artifact in the A12 Cloud Security Architecture Assessment.
Storage Types
Stores files, generated reports, media, archives, application objects, or export packages.
Architecture questions
Who can read or write objects? Is the location public or private? How are sharing, lifecycle, retention, and logging controlled?
Common risk
Broad access, accidental public exposure, old exports, weak ownership, or missing data lifecycle.
Stores structured application records with schemas, transactions, and application queries.
Architecture questions
Which workloads and administrators can connect? How are identities scoped? What backup, audit, retention, and recovery controls apply?
Common risk
Overprivileged identities, broad network exposure, weak audit evidence, or unclear backup ownership.
Stores structured or semi-structured application data at flexible scale.
Architecture questions
Which services can access collections or records? How are indexes, backups, replication, retention, and audit handled?
Common risk
Broad service permissions, unexpected copies, weak data classification, or stale development replicas.
Provides shared file-style access for approved workloads or business processes.
Architecture questions
Which identities and workloads can mount or access the share? Is access environment-specific? What audit and lifecycle evidence exists?
Common risk
Shared write access, inherited permissions, cross-environment reuse, or unclear owner.
Stores protected copies intended to support recovery.
Architecture questions
Who can create, read, restore, modify, or delete backups? Are retention and restoration evidence current?
Common risk
Backup data treated as less sensitive than production, weak restore controls, or retention that does not match business needs.
Holds approved datasets for analysis, dashboards, reporting, or aggregate insight.
Architecture questions
Is raw sensitive data necessary? Are fields minimized? Who can query it? How are exports and derived datasets governed?
Common risk
Secondary copies expand exposure, data minimization weakens, and old datasets remain after purpose ends.
Holds short-lived generated files for approved transfer, processing, or user download.
Architecture questions
How long do exports remain? Who can access them? Are they automatically removed? Is access logged?
Common risk
Temporary data becomes permanent because expiration, cleanup, or ownership is missing.
Exposure States
The storage location is not intended for general public access and is reachable only by approved identities or workloads.
Evidence that should support the state
Access policy, identity scope, network architecture, storage configuration, and audit evidence support the claim.
The storage content is intentionally public because the business purpose requires it.
Evidence that should support the state
Data classification, public-content approval, owner, exposure review, logging, and change trigger support the decision.
Specific external users or systems may access selected data without making the storage location generally public.
Evidence that should support the state
Guest or partner identity, narrow resource scope, expiration, sponsor, sharing policy, and audit record.
Only named workloads or managed services should access the storage location.
Evidence that should support the state
Workload identity, resource scope, service policy, environment boundary, and application architecture.
Privileged personnel can administer storage configuration or perform approved support actions.
Evidence that should support the state
Privileged role, JIT activation where appropriate, approval, audit, and access review.
Available evidence does not clearly establish whether the storage is exposed, who can reach it, or whether the current configuration matches design intent.
Evidence that should support the state
The uncertainty itself should be recorded and resolved rather than converted into an assumed safe state.
Storage Architecture Principles
Start with why the data exists and what business function needs it before choosing storage controls.
Review: Can every storage location explain its business purpose and data type?
Store only the fields and copies required for the approved purpose.
Review: Do reporting, analytics, export, and backup copies contain more data than necessary?
Limit who and what can read, write, administer, restore, delete, or share data.
Review: Do permissions match identity and workload purpose?
Sensitive or internal data should not become publicly reachable unless an explicit approved requirement exists.
Review: Is any public state documented, justified, and reviewed?
Production data should not casually flow into development, test, or personal storage locations.
Review: Are lower environments using synthetic or appropriately minimized data?
Data should have creation, active-use, retention, archive, export, backup, and deletion expectations.
Review: Can the owner explain when the data should no longer exist?
Important access and configuration claims need current evidence.
Review: Are access, sharing, configuration, and administrative events observable enough to support architecture claims?
Backups, replicas, exports, caches, and analytics copies extend the data boundary.
Review: Has every secondary copy been included in classification, access, retention, and recovery decisions?
Vocabulary
A method for grouping data by sensitivity, business importance, regulatory or contractual needs, and expected handling.
The set of identities, workloads, networks, external parties, or public users able to reach stored data.
The configuration or authorization rules that determine who can access a storage service and under what conditions.
A state where data can be reached without belonging to a narrowly approved internal or partner identity boundary.
A state where data access is limited to approved identities, workloads, networks, or service paths.
Protection applied to stored data while it resides on storage media or in a managed storage service.
The ownership, access, rotation, separation, evidence, and lifecycle decisions associated with cryptographic keys.
The period data should remain available before archive, deletion, or another lifecycle action.
Maintaining additional copies of data to support availability, locality, performance, or resilience.
A protected copy intended to support recovery after data loss, corruption, or another failure.
A record of where data came from, where it moved, what transformations occurred, and which derived copies were created.
A new dataset produced from another source through filtering, aggregation, transformation, reporting, or analytics.
Fictional Storage Register
Purpose
Primary student-support application records
Classification
Restricted
Access
Portal workload + approved data administrators
Exposure
Service-to-service + privileged administration
Retention
Per approved student-record schedule
Encryption
Provider-managed storage encryption enabled
Logging
Database audit + access telemetry
Owner
Data Platform Owner
Architecture concern
One legacy read-only reporting role is scheduled for review next month.
Purpose
Stores approved generated reports for short-term retrieval
Classification
Sensitive
Access
Reporting workload + authorized application users
Exposure
Private
Retention
Automatic removal after 14 days
Encryption
Storage encryption enabled
Logging
Read/write/admin events enabled
Owner
Reporting Team
Architecture concern
No public access is required for the business purpose.
Purpose
Aggregate service-quality analysis
Classification
Internal / minimized
Access
Analytics workload + approved analysts
Exposure
Private
Retention
90-day rolling analysis window
Encryption
Managed encryption enabled
Logging
Query and administration logs enabled
Owner
Analytics Owner
Architecture concern
A new derived dataset has not yet completed minimization review.
Purpose
Recovery copies for critical application data
Classification
Restricted
Access
Backup service + recovery operators
Exposure
Private / recovery-only
Retention
Policy-defined recovery schedule
Encryption
Managed encryption enabled
Logging
Backup and restore events enabled
Owner
Recovery Owner
Architecture concern
Backup configuration is current, but one restoration test is stale.
Purpose
Short-lived approved export packages
Classification
Sensitive
Access
Export workload + requesting user
Exposure
Private, time-bounded
Retention
24-hour automatic expiration
Encryption
Storage encryption enabled
Logging
Object access and deletion logs
Owner
Application Team
Architecture concern
A failed cleanup event last month was resolved and monitoring was added.
Purpose
Historical internal document workflow
Classification
Mixed / unclear
Access
Large inherited group
Exposure
Internal but broad
Retention
Unknown
Encryption
Managed encryption enabled
Logging
Basic access logging
Owner
Unknown
Architecture concern
Purpose, owner, classification, permission scope, and retention are not current.
Purpose
Publicly available help documents and static assets
Classification
Public
Access
Public read, controlled publishing
Exposure
Public by business requirement
Retention
Content lifecycle managed by communications owner
Encryption
Managed storage encryption
Logging
Publishing and administrative events
Owner
Communications Web Owner
Architecture concern
Publishing workflow must prevent restricted content from entering this location.
Data Copies
Copies are not automatically wrong. Backups, reports, analytics, exports, and replicas can be necessary. The architecture problem is losing track of them.
Source
STO-01 Student Support Database
Copy
STO-04 Recovery Backup Repository
Security effect: Backup contains similarly sensitive data and therefore requires strong access, retention, recovery, and deletion controls.
Source
STO-01 Student Support Database
Copy
STO-03 Analytics Workspace
Security effect: Data should be minimized before analysis so the secondary dataset exposes only fields needed for the approved purpose.
Source
STO-01 Student Support Database
Copy
STO-02 Generated Report Storage
Security effect: Reports are temporary secondary copies and should inherit sensitivity, access controls, logging, and short retention.
Source
STO-02 Generated Report Storage
Copy
STO-05 Temporary Export Area
Security effect: Export packages should remain private, time-bounded, and linked to a requesting user or workflow.
Fake Dashboard
Fictional storage exposure and lifecycle metrics
Storage locations reviewed
7
Database, object, analytics, backup, export, file, and public content storage
Private or bounded
6 / 7
One public location is intentionally public for approved help content
Current ownership
6 / 7
Legacy Team File Share has no confirmed owner
Lifecycle current
5 / 7
Legacy share retention is Unknown and one recovery test is stale
Fake SOC Alert
Source: Fictional Storage Governance Review • Time: 10:23
Fake Log Panel
[08:18] STO-01 student-db exposure=PRIVATE workload=PortalDBClient status=CONFIRMED [08:44] STO-02 report-storage public_access=NO retention=14d status=CONFIRMED [09:06] STO-03 analytics derived_dataset=minimization_review=PENDING status=CONDITIONAL [09:33] STO-04 recovery-backup configuration=CURRENT restore_test=STALE [09:57] STO-05 temp-export expiry=24h cleanup_monitor=HEALTHY [10:23] STO-06 legacy-share owner=UNKNOWN retention=UNKNOWN permissions=BROAD status=BLOCKED [10:49] STO-07 help-content classification=PUBLIC exposure=PUBLIC_APPROVED status=CONFIRMED
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Storage Anti-Patterns
Why it fails: Public exposure becomes a convenience choice rather than an explicit business requirement.
Better approach: Keep storage private unless public access is required, approved, and supported by data classification.
Why it fails: Encryption at rest does not fix overbroad identities, public exposure, poor retention, or weak logging.
Better approach: Evaluate encryption alongside access, exposure, lifecycle, ownership, and monitoring.
Why it fails: Backup copies often contain the same sensitive data as production but may receive weaker access or retention controls.
Better approach: Apply classification and access governance to backup and recovery data too.
Why it fails: A short-lived business process becomes a permanent secondary data store.
Better approach: Use explicit expiration and evidence that cleanup occurs.
Why it fails: An internal file share may still expose data to far more people than the business purpose requires.
Better approach: Review identity scope even when data is not public.
Why it fails: Analytics, reporting, backup, and export copies exist without clear links to the source data or owner.
Better approach: Record lineage, purpose, classification, retention, and responsible owner for each copy.
Why it fails: No one can approve access, retention, or retirement decisions.
Better approach: Block expansion and resolve ownership before treating the storage location as normal.
Why it fails: A previous review is treated as proof after identities, policies, network paths, or service configuration changed.
Better approach: Refresh evidence after material changes and on an appropriate review cadence.
Encryption Responsibilities
Cloud services commonly provide encryption capabilities. The provider may operate the underlying encryption service, but the organization still owns important decisions about data classification, identity access, key-governance expectations, service configuration, and evidence.
Scenario Decision Lab
A legacy file share is internal only, but a large inherited group can access it. No owner is documented, retention is Unknown, and the data classification is mixed.
Scenario Decision Lab
Northbridge stores approved public help documents and static assets in a public-read object-storage location. The content is classified Public and publishing is controlled.
Safe Fictional Lab
Use fictional storage services, datasets, identities, and evidence only. Do not sign in to or inspect any real cloud storage service.
Create at least ten fictional storage records.
Include object storage, a managed database, backup storage, analytics, temporary exports, and file-style storage.
Give each storage location a stable ID.
State the business purpose.
Classify the data.
List approved human and workload access.
Record public, private, shared, service-only, privileged, or Unknown exposure state.
Record retention and deletion expectations.
Record encryption responsibility at a conceptual level.
Record logging and evidence coverage.
Assign an accountable owner.
Link secondary copies back to their source data.
Identify at least two overexposure or lifecycle gaps.
Identify at least one unnecessary or stale copy.
Add a remediation or retirement decision.
Add change triggers for new identities, public exposure, new copies, retention changes, integrations, or service-model changes.
Lab boundary
This is an architecture and governance exercise. Use fictional storage metadata only — no real buckets, databases, shares, credentials, account IDs, or private data.
Analyze the Evidence
Advanced Challenge
Choose one fictional sensitive record from the Student Support Database and trace every approved place it may appear during its lifecycle.
Primary database
Application cache if applicable
Generated report
Temporary export
Analytics dataset
Backup repository
Recovery restoration environment
Audit or monitoring metadata
External integration field set
Retention rule for each copy
Identity boundary for each copy
Final deletion or retirement condition
The strongest answer shows that classification and ownership follow the data into every meaningful copy instead of stopping at the primary database.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the third artifact for your A12 Cloud Security Architecture Assessment: a fictional Cloud Storage Exposure Review with at least ten storage records. Include storage ID, type, business purpose, data classification, approved human/workload access, exposure state, retention, encryption responsibility, logging, owner, evidence status, secondary copies, risk concern, next action, and change trigger.
Confidence / Readiness Reflection
A12.4 moves into Cloud Network Boundaries. Before continuing, make sure you can explain how storage exposure depends not only on identity but also on which network and service paths can reach the data.
I can explain the difference between public, private, shared, service-only, privileged, and Unknown exposure.
I can evaluate storage access using identity, purpose, classification, lifecycle, and evidence.
I can explain why backups and secondary copies remain part of the protected data boundary.
I can identify why encryption alone does not prove storage safety.
I can trace data into reports, analytics, backups, and temporary exports.
Portfolio Build Guide
The reason the storage exists should be visible before the technical settings.
Separate public, private, shared, service-only, privileged, and Unknown access instead of using vague labels.
Link storage access to the human and workload identities from A12.2.
Include retention, expiration, archive, backup, deletion, and retirement expectations.
Trace backups, reports, exports, analytics, and other derived data back to their source.
Mark stale access reviews, missing retention, weak logging, and Unknown ownership clearly.
Public storage should visibly connect to Public-classified content and controlled publishing.
Make the review reusable in A12.4 network boundaries, A12.5 monitoring, A12.7 resilience, and A12.9 governance.
Key Takeaways
Lesson Safety Boundary
Do not use real cloud credentials, storage consoles, database endpoints, bucket names, account IDs, private logs, files, exports, or production data. All storage and evidence in this lesson are fictional and defensive.
Lesson Complete
You now have a storage architecture model for purpose, classification, access, exposure, encryption responsibilities, lifecycle, copies, logging, ownership, and evidence. Next, A12.4 focuses on Cloud Network Boundaries.