Secure compute, storage, and databases

When rotating customer-managed keys in Azure Storage accounts, the key rotation only affects NEW data operations, not existing data.

Here's what actually happens during CMK rotation:

Azure Storage uses envelope encryption, where actual data is encrypted with Data Encryption Keys (DEKs), and these DEKs are wrapped (encrypted) with the Customer-Managed Key (CMK) from Key Vault. When you update the storage account to reference a new key:

1. The storage account metadata is updated to reference the new key URI (MediaArchive2024 with RSA-4096)
2. All FUTURE write operations will use DEKs that are wrapped with the new RSA-4096 key
3. Existing data blobs remain encrypted with DEKs that were wrapped using the original RSA-2048 key
4. Azure Storage maintains the ability to unwrap old DEKs using the previous key version (MediaArchive2023) while simultaneously using the new key for new operations

This creates a mixed cryptographic state where the 280 TB of pre-existing data continues to use RSA-2048 wrapped DEKs, while new data uses RSA-4096 wrapped DEKs. The existing data will only transition to the new key protection when:
- Applications naturally rewrite the data
- Lifecycle management policies trigger data operations that rewrite blobs
- Manual re-encryption procedures are executed (like copying data to new locations)

Therefore, to fully benefit from RSA-4096 protection on the existing 280 TB, the organization would need to implement a strategy to rewrite the data, though this is not automatically performed by Azure.

The second answer is incorrect because Azure Storage does NOT perform automatic background re-encryption of existing data during key rotation. There is no 48-72 hour cryptographic transformation process.

The third answer is partially correct about existing data remaining with the old key, but incorrectly states it remains 'indefinitely' and that Azure maintains a rigid version mapping requiring explicit operations. In reality, the data transitions to new key protection whenever it's naturally rewritten.

The fourth answer is incorrect because Azure Storage does not perform selective re-encryption of metadata while leaving content unchanged, nor does it re-encrypt blobs during read operations. Reads simply decrypt using the appropriate key version; re-encryption only occurs during write operations.

When infrastructure encryption is enabled on an Azure Storage account, it provides double encryption at rest through two distinct and independent encryption layers:

The Correct Approach:
Each encryption layer operates with completely independent key sets that are managed separately by the Azure platform. The service-level encryption (which is always enabled by default) encrypts data at the storage service layer using 256-bit AES encryption. When infrastructure encryption is enabled, a second layer of encryption is applied at the physical infrastructure layer using a different algorithm (also 256-bit AES) with completely separate keys. These keys are managed at different architectural boundaries within Azure's infrastructure, ensuring true defense-in-depth security. This independence means that even if one encryption layer were compromised, the data would still be protected by the other layer.

Why Other Approaches Are Incorrect:

The concept of sharing a common master key hierarchy with derived subkeys would create a single point of failure. If the master key were compromised, both encryption layers could potentially be defeated, negating the security benefit of double encryption.

The idea of using a subordinate key cryptographically derived from the service-layer key creates a hierarchical dependency that undermines the defense-in-depth principle. True double encryption requires cryptographic independence between layers.

The notion of rotating between shared key material pools synchronized across tiers contradicts the fundamental security architecture of Azure's infrastructure encryption. Sharing key material between layers would reduce the security posture rather than enhance it, as it creates potential attack vectors and correlation points.

The independence of encryption keys across layers is a critical security feature that ensures maximum protection for data at rest in Azure Storage accounts.

The correct approach is to generate repository-scoped tokens with scope maps limiting access to the two designated repositories with pull-only actions, create individual tokens for each Swarm node with 90-day expiration, distribute token credentials through secure configuration management, and implement quarterly rotation procedures with audit log monitoring.

This solution is optimal because:

1. Repository-Scoped Tokens Address the Air-Gapped Constraint: The scenario explicitly states that Azure AD integration and managed identity assignment are architecturally infeasible due to regulatory restrictions on external authentication dependencies. Repository-scoped tokens work independently of Azure AD and don't require external authentication dependencies, making them ideal for air-gapped environments.

2. Granular Access Control: Scope maps allow precise control by limiting access to only 'maintenance-schedulers' and 'fuel-optimizers' repositories with pull-only actions, meeting the security requirement exactly.

3. Individual Node Authentication: Creating separate tokens for each of the 20 Swarm nodes enables individual credential management and selective revocation if any node is compromised, without affecting others.

4. Standard Docker Compatibility: Repository-scoped tokens work with standard Docker login commands across all nodes, fulfilling the operational requirement.

5. Programmatic Credential Management: Tokens can be easily retrieved and injected into Docker Swarm service definitions through configuration management tools.

6. Audit Trail Capability: Azure Container Registry provides audit logs that track which credentials were used for image pulls, enabling the security team to determine which Swarm node pulled which image version.

7. Quarterly Rotation: The 90-day expiration aligns with the quarterly rotation mandate.

Why the other answers are incorrect:

The second answer proposes service principals with federated identity credentials and Azure AD token endpoint integration. This approach fails because it requires Azure AD integration, which the scenario explicitly states is architecturally infeasible due to regulatory restrictions on external authentication dependencies in the air-gapped network segment.

The third answer suggests managed identities through Azure Arc-enabled servers and Azure Instance Metadata Service integration. This solution is incompatible with the air-gapped environment as it requires Azure Arc connectivity and managed identity assignment, both of which the scenario states are architecturally infeasible due to external authentication dependency restrictions.

The fourth answer recommends Azure AD B2B guest accounts with conditional access policies and long-lived refresh tokens. This approach is fundamentally unsuitable because it relies entirely on Azure AD authentication infrastructure, which contradicts the scenario's explicit constraint that Azure AD integration is not possible in the air-gapped network segment with regulatory restrictions on external authentication dependencies.