Lesson A14.8
Data does not stay in one place. It moves between users, services, partners, storage systems, backups, and recovery environments. Strong protection follows the data and checks whether each state has the right trust, key, authorization, and lifecycle controls.
This lesson stays conceptual and defensive. It does not teach traffic interception, decryption, certificate bypass, key extraction, or access to real protected data.
Lesson Progress
High School Advanced • A14: Cryptography and Key Management Concepts • Lesson 8 of 10
Readiness Check
0/4 ready
Professional Hook
A sensitive export might travel over a protected connection and then sit for weeks in an ungoverned staging folder. A backup may be encrypted in storage but copied across an unprotected path. A database may use strong at-rest encryption while logical access is far too broad. End-to-end design looks at the entire lifecycle of the data.
Data protection is strongest when transit, storage, identity, authorization, key lifecycle, and recovery are reviewed together.
Learning Objectives
Explain the difference between encryption in transit and encryption at rest using data state, trust boundary, key ownership, and architecture purpose.
Evaluate fictional transport and storage protections across browsers, APIs, service-to-service traffic, databases, object storage, local disks, backups, exports, and recovery environments.
Identify gaps where one data state is protected but another is not, or where encryption exists without appropriate identity, authorization, lifecycle, or recovery design.
Analyze protection coverage using data classification, endpoint trust, storage location, key ownership, certificate lifecycle, recovery evidence, and monitoring.
Build a Data Protection Coverage Matrix that becomes the eighth artifact in the A14 Key-Management Design Recommendation.
Data States
Data moving between users, applications, services, networks, storage endpoints, or external partners.
Examples
Browser sessions, API calls, service-to-service messages, partner transfers, backup replication, administrative connections.
Primary goal
Protect confidentiality and endpoint/service trust while data crosses a communication boundary.
Review question
Which endpoints communicate, which identity relationship is trusted, and who owns the certificate or transport policy?
Data stored on disks, databases, object stores, archives, file systems, devices, snapshots, or backups.
Examples
Databases, file shares, object storage, server disks, local caches, backup repositories, archived exports.
Primary goal
Reduce unauthorized disclosure from storage media or storage-layer access while supporting governed recovery.
Review question
Which storage location contains the data, what key protects it, who owns that key, and how is restoration handled?
Data actively processed by an authorized application, service, or user.
Examples
Application memory, analytics processing, report generation, business logic, document editing.
Primary goal
Apply identity, authorization, minimization, workload trust, and process controls once data is legitimately available for use.
Review question
What does encryption no longer protect once an authorized process has access to the data?
Data stored for restoration, continuity, archive, or disaster-recovery purposes.
Examples
Database backups, snapshots, archive copies, recovery replicas.
Primary goal
Maintain confidentiality without making legitimate recovery impossible.
Review question
Can current backup data still be decrypted and restored with the present key lifecycle?
Data packaged or moved outside its normal application boundary.
Examples
Reports, CSV exports, document bundles, partner files, analytics packages.
Primary goal
Preserve confidentiality and integrity while keeping export authorization and recipient scope separate.
Review question
Who approved the export, how is it protected during storage and transfer, and what happens after delivery?
Data copied between systems, regions, environments, or providers for resilience or scale.
Examples
Database replicas, backup replication, storage synchronization, regional copies.
Primary goal
Maintain equivalent protection across the replication path and destination storage boundary.
Review question
Are both the transfer path and destination copy protected under the expected trust and key model?
Transit Protection
Boundary: User device ↔ public application endpoint
Trust: Service certificate and client-side validation of the expected endpoint
Protection: Protected transport with a managed certificate relationship
Evidence: Current certificate inventory, endpoint policy, trust monitoring, renewal status
Caution: Protected transport does not prove the user is authorized to access every application function.
Boundary: Application workload ↔ internal API or service
Trust: Workload identity and approved service trust
Protection: Protected service communication under internal certificate or platform trust
Evidence: Service identity, certificate/trust state, environment scope, connection policy
Caution: Internal location should not automatically mean trusted or unencrypted.
Boundary: Internal integration service ↔ external partner service
Trust: Bounded partner certificate or service-identity relationship
Protection: Protected transport with explicit partner trust
Evidence: Partner sponsor, certificate validity, renewal state, relying-system policy
Caution: Partner transport trust should be limited to the intended integration.
Boundary: Administrator device ↔ management endpoint
Trust: Approved admin identity, device/context policy, protected management channel
Protection: Encrypted administrative transport
Evidence: Admin identity, endpoint policy, management certificate/trust, monitoring
Caution: Strong transport does not justify broad administrative privilege.
Boundary: Production backup platform ↔ recovery or secondary repository
Trust: Approved backup service identity and destination trust
Protection: Protected replication channel plus protected destination storage
Evidence: Replication policy, destination identity, storage-key inventory, recovery test
Caution: Transit protection alone does not protect the replicated copy after arrival.
Boundary: Approved export service ↔ approved receiving service
Trust: Recipient identity + export authorization + protected transfer
Protection: Protected transport, optionally combined with package-level protection where required
Evidence: Export approval, recipient trust, transfer status, integrity evidence
Caution: Recipient possession of a trusted key or certificate does not replace export authorization.
At-Rest Protection
Protection: Managed storage encryption under a governed data-encryption key
Owner: Data Platform / Application Owner
Evidence: Database encryption state, key owner, key version, access policy, restore evidence
Caution: Storage encryption does not reduce excessive logical database permissions.
Protection: Managed encryption for stored objects with policy-aligned key scope
Owner: Storage Platform / Data Owner
Evidence: Bucket/container policy, encryption state, key metadata, data classification
Caution: Public or overly broad access remains a problem even when objects are encrypted at rest.
Protection: Platform or device encryption protecting local storage media
Owner: Endpoint / Infrastructure Team
Evidence: Device compliance, encryption state, ownership, recovery policy
Caution: Disk encryption does not replace user-level authorization once the device is unlocked and operating.
Protection: Backup encryption with documented key lifecycle and tested restore access
Owner: Resilience Team
Evidence: Backup key inventory, retention mapping, restore test, recovery-role evidence
Caution: Encrypted backups can become unrecoverable if required key versions are retired too early.
Protection: Encrypted temporary storage with short retention and narrow export-service access
Owner: Analytics / Export Service Owner
Evidence: Storage policy, key scope, retention, export authorization, cleanup evidence
Caution: Temporary export copies should not become long-lived shadow data stores.
Protection: Encryption aligned with long-term retention and future key availability
Owner: Records / Data Governance Owner
Evidence: Retention policy, archive key lifecycle, recovery plan, historical-data mapping
Caution: Long retention can outlive current key owners, providers, or algorithms.
Coverage Dimensions
Transit
Does sensitivity require protected communication for every path?
At rest
Does sensitivity require storage encryption, restricted access, and retention controls?
Gap signal
Sensitive data receives weaker protection in one state than another without justification.
Transit
Where does data cross between users, services, environments, or organizations?
At rest
Which storage system or account owns the stored copy?
Gap signal
A path or storage location is missing from architecture diagrams or inventories.
Transit
Which endpoint or workload identity is trusted?
At rest
Which identities or workloads may access stored data or the storage key?
Gap signal
Encryption exists but identity scope is overly broad or Unknown.
Transit
Who owns the certificate or transport trust relationship?
At rest
Who owns the storage or data-encryption key?
Gap signal
Protection is enabled but no one owns lifecycle and recovery.
Transit
How are certificates renewed, revoked, or replaced?
At rest
How are storage keys rotated and old data/key versions managed?
Gap signal
Current protection depends on a key or certificate with no transition plan.
Transit
Can service trust be restored after certificate or platform failure?
At rest
Can encrypted data be restored with current and retained key versions?
Gap signal
Recovery assumptions are undocumented or stale.
Transit
Is endpoint trust, certificate state, and connection policy current?
At rest
Is encryption state, key inventory, and restore evidence current?
Gap signal
One side of the protection claim relies on stale or missing evidence.
Transit
Is the communicating identity allowed to perform the requested action?
At rest
Is the identity allowed to read or modify the stored data?
Gap signal
Encryption is mistakenly treated as permission.
End-to-End Examples
Transit
Browser ↔ Student Services Portal and portal ↔ database gateway use protected transport.
At rest
Database records are encrypted under a managed storage key.
In use
Application authorization limits which support staff may view the record.
Recovery
Backup restore is tested with current and retained key versions.
Coverage observation
No major gap when transport, storage, authorization, and recovery evidence are all current.
Transit
Export package is transferred through an approved protected channel to the authorized recipient.
At rest
Temporary export staging uses encrypted storage with short retention.
In use
Export service creates the package only after policy approval.
Recovery
Failed delivery is regenerated rather than leaving permanent recovery copies.
Coverage observation
A gap exists if recipient authorization is assumed from transport trust alone.
Transit
Internal integration service communicates with partner over a certificate-backed protected channel.
At rest
Inbound data is stored only in approved application storage with encryption.
In use
Integration workload has narrow access to the scheduling workflow.
Recovery
Partner certificate renewal and replacement are planned.
Coverage observation
A gap exists if partner certificate expires or if inbound data lands in unprotected staging storage.
Transit
Artifact moves between repository and deployment workflow through protected service communication.
At rest
Repository storage is encrypted.
In use
Deployment system verifies signature and release authorization before use.
Recovery
Repository recovery retains artifact integrity and required signing verification context.
Coverage observation
Encryption alone would not prove software publisher authenticity.
Transit
Backup copies move to secondary repository through protected replication.
At rest
Destination backup sets are encrypted under governed recovery keys.
In use
Only backup and recovery workflows may access the repository.
Recovery
Full restore tests confirm data, keys, and trust dependencies.
Coverage observation
Transit-only encryption is insufficient if the destination copy is unprotected.
Transit
Legacy report transfers use inconsistent transport protection.
At rest
Archive is encrypted under a key with Unknown owner.
In use
Manual reporting jobs have broad access.
Recovery
Recovery dependency is unclear.
Coverage observation
Multiple high-impact gaps make the design Blocked despite some at-rest encryption.
Design Principles
A system can protect one state well while leaving another weak.
Review: Can the architecture prove both the communication path and the stored copy are protected where required?
Protected communication still depends on the identity of endpoints and the authorization of the action.
Review: Who is on each end of the protected channel, and are they allowed to exchange the data?
Authorized applications can still read encrypted-at-rest data through normal service access.
Review: Are logical database, object, and application permissions appropriately narrow?
Data protected during transfer can become exposed after it lands in a weak storage location.
Review: What protection applies after arrival?
Backups inherit confidentiality, retention, and key-lifecycle requirements.
Review: Do backups receive protection equivalent to their source data classification?
Exported data may leave the application, storage, and policy controls that originally protected it.
Review: Is the export authorized, encrypted while stored and sent, and removed when no longer needed?
A storage-encryption design is incomplete if legitimate recovery cannot access required key versions.
Review: Has restore been tested under the current key lifecycle?
A claim of 'encrypted' should be supported by current transport, storage, key, certificate, authorization, and recovery evidence.
Review: Which data state has the weakest evidence?
Vocabulary
Cryptographic protection applied while data moves between communicating endpoints.
Cryptographic protection applied to data stored on persistent media or storage services.
Confidence that the communicating service or system is the expected identity.
The platform, service, account, device, or repository where data is stored.
The sequence of systems and boundaries through which data moves.
A data state or trust boundary that lacks the required protection or current evidence.
A communication path that uses cryptographic mechanisms to protect data and establish endpoint trust.
A cryptographic key used to protect stored data under a defined storage or data scope.
Copying data between storage systems, regions, environments, or recovery locations.
A temporary storage location used while preparing or delivering exported data.
A design view that follows data through transit, storage, use, export, replication, and recovery states.
A structured review showing where data is protected, by what relationship, under which owner, and with what evidence.
Fictional Coverage Register
Data
Student support session + support records
Classification
Sensitive
Transit path
Browser ↔ Portal ↔ Database Gateway
Transit protection
Protected browser and service transport
Transit owner
Application + Platform Security
Rest locations
Student Support Database + backup repository
Rest protection
Managed database and backup encryption
Key owner
Data Platform / Resilience Team
Authorization
Support-role policy + workload identity
Recovery
Current restore test
Evidence
Certificate inventory + key inventory + access review + restore test
Coverage gap / condition
No current major gap; continued certificate and key lifecycle monitoring required.
Data
Approved sensitive report package
Classification
Sensitive
Transit path
Export Service ↔ Approved Recipient
Transit protection
Protected recipient transfer
Transit owner
Analytics Product Owner
Rest locations
Temporary export staging
Rest protection
Encrypted short-lived storage
Key owner
Analytics Platform
Authorization
Export approval + recipient policy
Recovery
Regenerate failed export through approved workflow
Evidence
Export policy + recipient trust + storage key metadata
Coverage gap / condition
No major gap if temporary staging cleanup remains current.
Data
Scheduling messages
Classification
Internal / partner-shared
Transit path
Northbridge Integration ↔ Partner Service
Transit protection
Certificate-backed protected transport
Transit owner
Integration Owner
Rest locations
Integration queue + application database
Rest protection
Managed storage encryption
Key owner
Integration Platform
Authorization
Partner-specific integration policy
Recovery
Certificate replacement window documented
Evidence
Partner certificate + sponsor + queue/storage policy
Coverage gap / condition
Partner certificate renewal is due in 45 days.
Data
Encrypted production backup sets
Classification
Sensitive
Transit path
Primary Backup Platform ↔ Recovery Repository
Transit protection
Protected replication channel
Transit owner
Resilience Team
Rest locations
Primary + recovery backup repositories
Rest protection
Encrypted backup storage
Key owner
Resilience Team
Authorization
Backup/recovery workloads only
Recovery
Last full restore test current
Evidence
Replication policy + key inventory + restore test
Coverage gap / condition
Retained key versions must remain mapped to retained backup sets.
Data
Historical reports
Classification
Internal sensitive
Transit path
Legacy Report Server ↔ Archive Host
Transit protection
Inconsistent; some transfers use old unverified path
Transit owner
Unknown
Rest locations
Legacy archive hosts
Rest protection
Encrypted under legacy shared key
Key owner
Unknown
Authorization
Broad legacy job access
Recovery
Unclear
Evidence
Partial network notes + stale key inventory
Coverage gap / condition
Transit protection, key ownership, authorization, and recovery are all insufficiently governed.
Data
Release artifacts
Classification
Integrity-critical
Transit path
Repository ↔ Deployment Pipeline
Transit protection
Protected service communication
Transit owner
Release Engineering
Rest locations
Artifact repository
Rest protection
Managed repository encryption
Key owner
Platform Security
Authorization
Release approval + signed-artifact verification
Recovery
Repository recovery includes integrity metadata
Evidence
Repository policy + signer trust + deployment verification
Coverage gap / condition
Confidentiality is not the only goal; artifact integrity and publisher authenticity remain essential.
Data
Derived analytics dataset
Classification
Sensitive
Transit path
Approved Data Store ↔ Temporary Workspace
Transit protection
Protected service transport
Transit owner
Data Science Platform
Rest locations
Temporary workspace volume
Rest protection
Encryption enabled, but retention and key scope under review
Key owner
Data Science Platform
Authorization
Project-scoped workload/user access
Recovery
No long-term recovery required; workspace designed to expire
Evidence
Workspace policy + project owner + storage encryption status
Coverage gap / condition
Retention and automatic destruction evidence must confirm that temporary copies do not persist beyond project need.
Fake Dashboard
Fictional transit, at-rest, authorization, recovery, and lifecycle summary
Data flows reviewed
7
Portal, export, partner, backup, legacy archive, release, and temporary analytics workflows
Confirmed
4
Portal, export, backup, and release flows have current transit/rest coverage
Conditional
2
Partner renewal and temporary workspace retention need follow-up
Blocked
1
Legacy reporting has transit, ownership, authorization, and recovery gaps
Fake SOC Alert
Source: Fictional Data Protection Coverage Review • Time: 09:45
Encryption vs. Authorization
Encryption changes who can access data through a cryptographic boundary, but application and storage permissions still decide which authenticated identities may legitimately read or modify the data.
Protects the communication path or stored representation using keys, certificates, and trust relationships.
Decides which user, service, or workload is permitted to access the data after identity and trust have been established.
Fake Log Panel
[08:09] DPC-01 portal transit=PROTECTED rest=PROTECTED recovery=CURRENT state=CONFIRMED [08:33] DPC-02 export transit=PROTECTED staging=ENCRYPTED retention=SHORT state=CONFIRMED [08:57] DPC-03 partner transit=PROTECTED cert_renewal=45d rest=PROTECTED state=CONDITIONAL [09:21] DPC-04 backups replication=PROTECTED rest=ENCRYPTED restore=PASS state=CONFIRMED [09:45] DPC-05 legacy transit=INCONSISTENT key_owner=UNKNOWN recovery=UNKNOWN state=BLOCKED [10:09] DPC-06 release transit=PROTECTED repo=ENCRYPTED signature=VERIFIED state=CONFIRMED [10:33] DPC-07 workspace transit=PROTECTED rest=ENCRYPTED retention=REVIEW state=CONDITIONAL
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Common Coverage Mistakes
Why it fails: Data moves through an encrypted channel but lands in storage with weak protection or broad access.
Better approach: Review transport and destination storage as separate control points.
Why it fails: Teams assume encrypted databases are safe even with overly broad logical access.
Better approach: Keep authorization and encryption as separate architecture controls.
Why it fails: Service-to-service paths are trusted merely because they are inside the organization.
Better approach: Use workload identity and protected transport where sensitivity and trust boundaries require it.
Why it fails: Temporary report staging grows into an unmanaged shadow repository.
Better approach: Use short retention, encrypted staging, cleanup evidence, and data-owner policy.
Why it fails: The copy arrives securely but is stored unencrypted at the recovery location.
Better approach: Protect both replication and destination storage.
Why it fails: A trusted endpoint is allowed to receive any data simply because its certificate is valid.
Better approach: Require separate business authorization for the requested data transfer.
Why it fails: At-rest protection exists, but nobody can explain key ownership, rotation, or recovery.
Better approach: Treat key lifecycle as part of the storage design.
Why it fails: Backups, exports, replicas, archives, and temporary workspaces are omitted.
Better approach: Follow the data through every meaningful copy and state.
Scenario Decision Lab
A legacy reporting archive uses at-rest encryption, but internal transfer protection is inconsistent, key ownership is Unknown, access is broad, and recovery has not been validated.
Scenario Decision Lab
A temporary analytics workspace uses protected transport and encrypted storage, but the team has not yet proven that temporary copies are automatically destroyed at the end of the project.
Safe Fictional Lab
Use fictional data flows, endpoints, storage systems, certificates, key IDs, owners, classifications, and synthetic evidence only. Do not inspect or interact with real protected traffic or storage.
Create at least twenty fictional data-protection records.
Give every record a stable DPC ID.
Record the workflow or data flow.
Record the data classification.
Record all transit paths.
Record transit protection.
Assign transit trust/certificate owner.
Record all storage locations.
Record at-rest protection.
Assign storage/key owner.
Record authorization dependency.
Record backup or replication copies.
Record export or temporary copies.
Record recovery dependency.
Record certificate/key lifecycle state.
Record evidence source and freshness.
Classify status as Confirmed, Conditional, Unknown, Blocked, Accepted Risk, or Not Applicable.
Record the weakest coverage point.
Record the next remediation step.
Include at least four browser/API transit examples.
Include at least four service-to-service examples.
Include at least four database/object-storage examples.
Include at least three backup/replication examples.
Include at least three export/temporary-workspace examples.
Include at least two partner/integration examples.
Include at least one legacy workflow with both transit and rest gaps.
Add change triggers for data classification, endpoint, service identity, certificate, key version, storage location, retention, recovery, and provider changes.
Lab boundary
Do not capture traffic, inspect real encrypted data, bypass certificate validation, access protected storage, recover real keys, or test live endpoints. This is a defensive architecture mapping exercise only.
Analyze the Evidence
Advanced Challenge
A fictional organization has strong database encryption and public web transport, but internal APIs, temporary workspaces, backup replication, export staging, and old archives follow inconsistent rules. Redesign the protection model conceptually.
Data classification
Transit inventory
Storage inventory
Endpoint identity
Certificate ownership
Storage-key ownership
Service-to-service trust
Partner trust
Authorization separation
Backup replication
Recovery testing
Export staging
Temporary data retention
Legacy archive handling
Evidence freshness
Coverage-gap states
Change triggers
Residual risk
A mature data-protection design should make it easy to trace a sensitive record from creation through communication, storage, processing, export, backup, replication, recovery, retention, and eventual deletion.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the eighth artifact for your A14 Key-Management Design Recommendation: a fictional Data Protection Coverage Matrix with at least twenty records. Include DPC ID, workflow, data classification, transit path, transit protection, transit owner, storage locations, at-rest protection, key owner, authorization dependency, backup/replication copies, export/temporary copies, recovery, certificate/key lifecycle, evidence, freshness, status, weakest coverage point, remediation, residual risk, and change trigger.
Confidence / Readiness Reflection
A14.9 moves into Crypto Policy and Compliance Concepts. Before continuing, make sure you can turn technical protection coverage into a governance statement: what policy requires, who owns it, what evidence proves it, and how exceptions are handled.
I can distinguish data in transit and data at rest.
I can identify endpoint trust and storage-key ownership.
I can explain why encryption and authorization remain separate.
I can follow data through backups, exports, replicas, and temporary storage.
I can identify the weakest point in an end-to-end data-protection design.
Portfolio Build Guide
Show where it moves, where it lands, where it is copied, and how it is recovered.
Do not summarize both with one field called 'encrypted.'
Certificates, service identities, storage keys, and recovery keys may have different owners.
Record who may legitimately access the data after cryptographic trust is established.
Backups, replicas, exports, archives, and temporary workspaces often create the biggest coverage gaps.
Certificate renewal, key rotation, retention, recovery, and deletion should all appear.
A coverage matrix is most useful when it reveals the least-governed data state.
A14.9 will turn these technical coverage decisions into policy, standards, exceptions, evidence, and compliance governance.
Key Takeaways
Lesson Safety Boundary
Do not capture real traffic, inspect protected data, bypass certificate validation, extract keys, access encrypted storage, or test real endpoints without authorization. All data flows, storage systems, certificates, key IDs, and evidence in this lesson are fictional.
Lesson Complete
You now have an end-to-end model for protecting data in transit, at rest, in backup, in export, in replication, and in temporary storage, while keeping identity, authorization, key lifecycle, and recovery visible. Next, A14.9 focuses on Crypto Policy and Compliance Concepts.