Snapshot Management Across Cloud Security Boundaries
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud providers face challenges in managing snapshots for remote extensions of their network substrate, particularly in terms of storage capacity and security, as these extensions often have limited resources and require secure key management to prevent data breaches.
Innovation Solution
The solution involves maintaining snapshots at the cloud provider network substrate, allowing the remote extension to access and update them without storing the entire volume, and ensuring secure key management by decrypting and re-encrypting snapshots to prevent key sharing outside the cloud provider network.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If snapshots are stored at the remote extension, then access speed is improved, but storage capacity is exceeded
Solution Approach 1:
The patent extracts the snapshot storage function from the remote extension and relocates it to the cloud provider network substrate. The remote extension maintains only the metadata and access pointers, while the actual snapshot data is stored externally in the cloud substrate, which has abundant storage capacity. This resolves the contradiction by removing the storage burden from the resource-constrained remote extension while preserving fast access through local metadata caching.
Solution Approach 2:
The patent introduces a new spatial dimension for snapshot storage by creating a hierarchical architecture: local metadata layer at the remote extension and remote data layer in the cloud substrate. This dimensional separation allows the system to achieve both fast local access (through metadata) and abundant storage capacity (in the cloud), resolving the contradiction between access speed and storage capacity.
2Ease of operation
If encryption keys are shared with remote extension, then snapshot accessibility is improved, but security is compromised
Solution Approach 1:
The patent introduces an intermediary encryption layer managed by the cloud provider. Snapshots are encrypted with cloud-managed keys before being stored in the substrate, and the remote extension accesses them through controlled decryption operations. This intermediary key management system enables snapshot accessibility for authorized remote extensions while preventing direct key exposure and maintaining security boundaries.
Solution Approach 2:
The patent segments the encryption key management into distinct layers: cloud-managed master keys for snapshot encryption and extension-specific access credentials. This segmentation allows the remote extension to access snapshots without obtaining the actual encryption keys, thereby maintaining security while enabling operational accessibility.
3Loss of energy
If incremental snapshots are generated at remote extension, then bandwidth usage is reduced, but storage management complexity increases
Solution Approach 1:
The patent enables the remote extension to autonomously generate incremental snapshots locally and upload only the changed blocks to the cloud substrate. The extension's snapshot manager independently identifies modifications, creates incremental snapshots, and manages the upload process without requiring complex centralized coordination. This self-service approach reduces bandwidth usage while keeping management complexity localized at the extension level.
Data Source
AI summary
Systems and methods for efficient and secure management of encrypted “snapshots” for a remote provider substrate extension (“PSE”) of a cloud provider network substrate are provided. The PSE may request and obtain a snapshot from the cloud provider network substrate, restore a volume from the snapshot, make changes to data in the restored volume, and/or initiate the creation and storage of a new snapshot that includes incremental updates to the original snapshot to reflect the changes made to data in the volume. An encrypted snapshot stored within the cloud provider network substrate may be decrypted using a cloud provider key designed for internal use only, and then re-encrypted using a PSE-specific key before providing the snapshot to the PSE, thereby avoiding the sharing of the cloud provider internal use only key outside the cloud provider network substrate.