This chapter covers Microsoft Sentinel Customer-Managed Keys (CMK), a critical security feature that allows you to bring your own encryption key to protect Sentinel workspace data at rest. Understanding CMK is essential for the SC-200 exam, as it tests your ability to configure and manage data encryption compliance requirements. Approximately 10-15% of exam questions on Sentinel configuration and management touch on encryption, data retention, and key management, with CMK being a key differentiator between standard and high-security deployments.
Jump to a section
Customer-Managed Keys (CMK) for Microsoft Sentinel is like owning a high-security safety deposit box inside a bank's massive vault. The bank (Azure) provides the vault and all the infrastructure, but you bring your own lock (your key stored in Azure Key Vault) and install it on your box. When you want to deposit or retrieve data, the bank's staff (Sentinel) must use your lock to access your box. You control who has copies of your key and can revoke access at any time by disabling the key in Key Vault. The bank cannot open your box without your key, even if they wanted to. In Sentinel, CMK means you provide an encryption key that Azure uses to encrypt all data at rest in your workspace. The key is stored in your own Azure Key Vault, and Sentinel's data encryption uses envelope encryption: a Data Encryption Key (DEK) is encrypted by your Key Encryption Key (KEK) stored in Key Vault. If you revoke access to the KEK, Sentinel cannot decrypt the DEK, and the workspace effectively becomes inaccessible—data cannot be queried or ingested until you restore access. This mirrors exactly how you would lock your box with your own padlock: the bank can't open it, and if you lose your key, the contents are sealed forever.
What is Customer-Managed Key (CMK) for Sentinel?
Customer-Managed Key (CMK) is a feature that lets you control the encryption key used to protect all data stored in your Microsoft Sentinel workspace. By default, Sentinel uses Microsoft-managed keys (MMK) for encryption at rest. With CMK, you provide your own encryption key stored in Azure Key Vault, giving you full control over access and the ability to revoke access on demand. This is critical for organizations with regulatory compliance requirements (e.g., GDPR, HIPAA, FedRAMP) that mandate customer control over encryption keys.
How CMK Works Internally
CMK uses envelope encryption. When data is written to Sentinel (logs, alerts, bookmarks, etc.), Azure generates a unique Data Encryption Key (DEK) for that data. The DEK is a symmetric key that encrypts the actual data. The DEK itself is then encrypted using your Key Encryption Key (KEK) stored in Azure Key Vault. This encrypted DEK (wrapped DEK) is stored alongside the data. To decrypt data, Sentinel sends a request to Key Vault to unwrap the DEK using your KEK. Only after successful unwrapping can the DEK be used to decrypt the data. This process ensures that Sentinel never has direct access to your KEK; it only holds the wrapped DEK.
The KEK never leaves Azure Key Vault. All cryptographic operations (wrap/unwrap) are performed inside Key Vault's hardware security modules (HSMs). Sentinel's service identity (a system-assigned managed identity or user-assigned managed identity) must be granted 'Get', 'Wrap Key', and 'Unwrap Key' permissions on the key in Key Vault. The key must be an RSA key of size 2048, 3072, or 4096, and Key Vault must be in the same Azure region as the Sentinel workspace. Soft-delete and purge protection must be enabled on Key Vault.
Key Components and Defaults
Azure Key Vault: Must be in the same region as Sentinel. Requires soft-delete (enabled by default, retention period 7-90 days) and purge protection (must be enabled).
Key Vault Access Policy or RBAC: The Sentinel workspace's managed identity needs 'Get', 'Wrap Key', 'Unwrap Key' permissions. If using access policies, assign these permissions to the Sentinel service principal (Azure Sentinel principal ID: 1950a258-227b-4e31-a9cf-717495945fc2). If using RBAC, assign 'Key Vault Crypto Service Encryption User' role.
Key Type: RSA-HSM or RSA with key sizes 2048, 3072, or 4096. HSM-backed keys are recommended for production.
Key Rotation: You can rotate the KEK manually by creating a new version in Key Vault. Sentinel automatically uses the latest key version for wrapping new DEKs. Existing DEKs remain wrapped with the old key version unless you explicitly rewrap them (using a PowerShell script).
Default Encryption: Without CMK, Sentinel uses Microsoft-managed keys (MMK). Enabling CMK is irreversible for a workspace; you cannot revert to MMK.
Configuration Steps
1. Create or use an existing Azure Key Vault with soft-delete and purge protection enabled. 2. Generate or import an RSA key (size 2048 or higher) in Key Vault. 3. Assign permissions to Sentinel's managed identity. If Sentinel workspace already exists, you must enable system-assigned managed identity via Azure Portal or PowerShell:
Set-AzOperationalInsightsWorkspace -ResourceGroupName "<RG>" -Name "<WorkspaceName>" -AssignManagedIdentityGrant the managed identity access to the key using either access policy or RBAC.
Configure CMK on the Sentinel workspace using Azure Portal (Sentinel -> Settings -> Workspace settings -> Encryption) or REST API. You'll specify the Key Vault URI and key name.
Verification Commands
After configuration, verify that CMK is enabled:
Get-AzOperationalInsightsWorkspace -ResourceGroupName "<RG>" -Name "<WorkspaceName>" | Select-Object Sku, FeaturesCheck the Features property for encryption details.
Or via REST API:
GET https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}?api-version=2020-08-01Look for properties.features.encryption.
Interaction with Related Technologies
Azure Monitor Logs: Sentinel uses the same Log Analytics workspace. CMK for Sentinel also encrypts the underlying Log Analytics workspace data. However, note that Log Analytics clusters can also use CMK independently, but for Sentinel, you must configure CMK at the workspace level.
Azure Data Explorer (ADX): If you use ADX for long-term retention, CMK does not automatically encrypt ADX data. You must configure CMK separately on the ADX cluster.
Key Vault Firewall: If Key Vault has a firewall enabled, you must allow trusted Microsoft services to bypass it, or configure private endpoint. Sentinel's managed identity must be able to access Key Vault.
Azure Policy: You can enforce CMK using Azure Policy by auditing workspaces without CMK.
Performance and Cost Considerations
CMK introduces additional latency for each encryption/decryption operation because each operation requires a call to Key Vault. However, this is minimal (milliseconds) and typically not noticeable. The main cost is the Key Vault transaction cost (each wrap/unwrap operation counts towards Key Vault's transaction limits). For high-ingestion workspaces, ensure your Key Vault is in the standard tier (Premium tier is not required but offers HSM-backed keys). Monitor Key Vault throttling; if you exceed limits, operations may fail. You can request higher limits from Azure support.
Create Key Vault with Protection
Create an Azure Key Vault in the same region as your Sentinel workspace. Enable soft-delete (default retention 90 days) and purge protection. This ensures that if the key is deleted, it can be recovered within the retention period, preventing permanent data loss. Use the Azure Portal, PowerShell, or CLI. Example CLI: `az keyvault create --name myKV --resource-group myRG --location eastus --enable-soft-delete true --enable-purge-protection true`.
Generate or Import RSA Key
Create a new RSA key in Key Vault with size 2048, 3072, or 4096. For production, use HSM-backed key (Premium tier). You can also import your own key from an on-premises HSM. The key must support wrap and unwrap operations. Example CLI: `az keyvault key create --vault-name myKV --name myCMKKey --kty RSA --size 4096 --protection hsm`.
Enable Managed Identity on Sentinel
If your Sentinel workspace (Log Analytics workspace) does not have a system-assigned managed identity, enable it. This identity will be used to authenticate to Key Vault. Use PowerShell: `Set-AzOperationalInsightsWorkspace -ResourceGroupName "<RG>" -Name "<WorkspaceName>" -AssignManagedIdentity`. The managed identity object ID is displayed after assignment.
Grant Key Permissions to Managed Identity
Assign the managed identity the necessary Key Vault permissions: 'Get', 'Wrap Key', 'Unwrap Key'. Using RBAC, assign the 'Key Vault Crypto Service Encryption User' role. Using access policies, add the managed identity with those key permissions. Ensure the identity has access; otherwise, CMK configuration will fail. Example RBAC: `az role assignment create --assignee <managed-identity-object-id> --role "Key Vault Crypto Service Encryption User" --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/myKV`.
Configure CMK on Sentinel Workspace
In Azure Portal, navigate to Sentinel -> Settings -> Workspace settings -> Encryption. Select 'Customer-managed key' and provide the Key Vault URI and key name. Alternatively, use REST API or PowerShell. This operation enables CMK and cannot be reversed. The workspace will start using your key for all new data. Existing data remains encrypted with the previous key (MMK or old CMK) until it is rewritten (e.g., during log rotation).
Verify CMK Is Active
Use Azure Portal or PowerShell to confirm that CMK is enabled. Check the workspace properties for encryption settings. Also, test by temporarily disabling the key in Key Vault (via access policy or key disable). After a few minutes, queries should fail because Sentinel cannot decrypt data. Re-enable the key to restore access. This verifies that CMK is working and that without the key, data is inaccessible.
Enterprise Scenario 1: Financial Institution Compliance
A global bank must comply with PCI DSS and local banking regulations that require encryption keys to be stored in a hardware security module (HSM) under the bank's control. They deploy Sentinel CMK using Azure Key Vault Premium with an HSM-backed RSA 4096 key. The Key Vault is placed in a separate management subscription with restricted network access via private endpoints. The Sentinel workspace ingests 5 TB of logs daily. To avoid Key Vault throttling (10,000 operations per second for standard tier), they upgrade to Premium tier (unlimited operations). They also set up key rotation every 90 days using Azure Automation runbooks. A critical issue occurs when a key version expires before the new version is activated; Sentinel continues to use the old version for unwrapping existing DEKs but uses the new version for new data. They must ensure both versions are available during rotation. Misconfiguration: they initially forgot to enable purge protection, leading to risk of permanent data loss if key is deleted. They corrected by recreating the vault with purge protection.
Enterprise Scenario 2: Healthcare Provider with BYOK
A hospital system uses Bring Your Own Key (BYOK) to import an on-premises HSM key into Azure Key Vault. They use Sentinel for HIPAA compliance. The key is imported as an RSA 3072 key with no HSM backing (software key) due to cost constraints. They configure CMK on their Sentinel workspace. A problem arises when the Key Vault firewall is enabled but they forget to add the 'Allow trusted Microsoft services' exception. Sentinel's managed identity cannot access the key, causing all data ingestion to fail silently. They discover this when queries return no data. After adding the exception, ingestion resumes. They also learn that if they revoke the managed identity's access to the key, the workspace becomes unusable; they must ensure that only authorized personnel can modify Key Vault permissions.
Enterprise Scenario 3: Multi-Region Deployment with CMK
A multinational corporation deploys Sentinel in three regions. Each region has its own Key Vault with a unique key. They must ensure that each Sentinel workspace uses the key from its regional Key Vault. A common mistake is using the same key across regions, which violates compliance if a key compromise in one region affects all data. They configure Azure Policy to enforce that each workspace's CMK key vault is in the same region. They also implement key backup using Azure Key Vault backup feature to recover keys in case of regional failure. Performance: with 10 TB/day ingestion, they see no noticeable latency from CMK, but Key Vault transaction costs are significant (~$0.03 per 10,000 operations). They optimize by batching operations and using key caching where possible.
SC-200 Objective 2.1: Configure Microsoft Sentinel Settings
The exam tests CMK under objective 2.1, specifically 'Configure workspace settings, including encryption'. Candidates must know how to enable CMK, prerequisites, and the impact of key revocation. The exam focuses on:
- Prerequisites: Key Vault with soft-delete and purge protection enabled. Sentinel workspace must have a managed identity. Key Vault must be in the same region. - Permissions: The managed identity needs 'Get', 'Wrap Key', 'Unwrap Key' permissions. The exam may ask which role to assign (Key Vault Crypto Service Encryption User) or which permissions are required. - Key Types: Only RSA keys of size 2048, 3072, or 4096 are supported. HSM-backed keys are recommended but not required. - Irreversibility: Once CMK is enabled, you cannot revert to Microsoft-managed keys. This is a common trap: candidates think they can switch back. - Key Revocation Effect: If the key is disabled or permissions are removed, the workspace becomes inaccessible. Data is still encrypted but cannot be decrypted. This is a key exam scenario: 'What happens if the key is deleted?' Answer: Data becomes permanently inaccessible unless the key is recovered within the soft-delete retention period. - Common Wrong Answers: 1. 'CMK can be enabled on any Log Analytics workspace without prerequisites.' Wrong: Requires Key Vault with soft-delete and purge protection, and managed identity. 2. 'You can use any key type (e.g., EC key).' Wrong: Only RSA keys are supported. 3. 'CMK encrypts data in transit as well.' Wrong: CMK only encrypts data at rest. TLS encrypts data in transit. 4. 'You can disable CMK and revert to MMK.' Wrong: Irreversible. - Edge Cases:
If Key Vault is in a different region, configuration fails.
If Key Vault firewall blocks Sentinel's managed identity, ingestion and queries fail.
Key rotation: New data uses new key version; old data remains encrypted with old version. The exam may ask whether old data is re-encrypted automatically (no, unless you run a rewrapping script).
Exam Terms: 'Envelope encryption', 'Key Encryption Key (KEK)', 'Data Encryption Key (DEK)', 'Wrap/Unwrap', 'Soft-delete', 'Purge protection', 'Managed identity'.
To eliminate wrong answers, focus on the mechanism: CMK uses envelope encryption where the KEK never leaves Key Vault. If a question mentions 'key stored in Sentinel' or 'key used for decryption by Sentinel directly', it's wrong. Sentinel only holds wrapped DEKs.
CMK uses envelope encryption: a Data Encryption Key (DEK) is encrypted by your Key Encryption Key (KEK) stored in Azure Key Vault.
Prerequisites: Key Vault with soft-delete and purge protection, managed identity on Sentinel workspace, RSA key (2048/3072/4096).
Key Vault must be in the same region as the Sentinel workspace.
The managed identity needs 'Get', 'Wrap Key', 'Unwrap Key' permissions on the key (or 'Key Vault Crypto Service Encryption User' role).
Enabling CMK is irreversible; you cannot revert to Microsoft-managed keys.
If the key is disabled or access is revoked, the workspace becomes inaccessible until access is restored.
CMK only encrypts data at rest; data in transit is encrypted via TLS.
Key rotation creates new key versions; old data remains encrypted with old version unless you run a rewrapping script.
Common exam trap: 'CMK can be enabled on any workspace' — false, prerequisites must be met.
Soft-delete retention period is 7-90 days (default 90); purge protection must be enabled permanently.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft-Managed Keys (MMK)
Keys are generated and managed by Microsoft.
No additional cost or configuration required.
Key rotation is automatic by Microsoft.
No compliance control over key access.
Data is encrypted at rest by default.
Customer-Managed Keys (CMK)
You provide and control your own key in Azure Key Vault.
Requires Key Vault with soft-delete and purge protection.
Key rotation is your responsibility (manual or automated).
Full control over key access; can revoke access at any time.
Data becomes inaccessible if key is revoked or deleted.
Mistake
CMK encrypts data both at rest and in transit.
Correct
CMK only encrypts data at rest. Data in transit is encrypted using TLS 1.2+ between services. The key is never used for network encryption.
Mistake
You can use any type of key, including symmetric keys.
Correct
Only RSA keys of size 2048, 3072, or 4096 are supported. Symmetric keys or EC keys are not allowed for CMK.
Mistake
Once CMK is enabled, you can switch back to Microsoft-managed keys anytime.
Correct
Enabling CMK is irreversible. You cannot revert to Microsoft-managed keys for that workspace. The only way to change encryption is to create a new workspace.
Mistake
If you delete the key from Key Vault, Sentinel will fall back to Microsoft-managed keys.
Correct
If the key is deleted (and not recovered within soft-delete period), the data becomes permanently inaccessible. Sentinel cannot decrypt the DEKs, and the workspace becomes unusable. There is no fallback.
Mistake
CMK requires Azure Key Vault Premium tier.
Correct
Standard tier is sufficient. Premium tier is only needed if you require HSM-backed keys. Both tiers support CMK.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
If you disable the key, Sentinel cannot unwrap the DEKs, so it cannot encrypt new data or decrypt existing data. New data ingestion will fail, and queries will return errors. The workspace becomes effectively unusable. To restore functionality, re-enable the key in Key Vault. If the key is deleted, you have the soft-delete retention period (default 90 days) to recover it. After that, data is permanently lost.
Yes, you can use the same key for multiple workspaces, but this is not recommended for security isolation. Each workspace would have access to the same key, meaning a compromise of one workspace could affect others. Best practice is to use a separate key per workspace or per region.
No, automatic rotation is not built-in for CMK. You must manually create new key versions in Key Vault. Sentinel will automatically use the latest key version for new data. To re-encrypt existing data with the new key, you need to run a PowerShell script (e.g., using the Invoke-AzOperationalInsightsWorkspaceMigrate cmdlet) to rewrap the DEKs.
There is no additional cost for CMK itself beyond the standard Sentinel and Log Analytics pricing. However, you incur costs for Azure Key Vault (standard tier ~$0.03 per 10,000 transactions) and any key operations (wrap/unwrap). For high-ingestion workspaces, these transaction costs can add up. Premium tier costs more but offers HSM-backed keys and higher throughput.
Yes, you can enable CMK on an existing workspace. After enabling, new data is encrypted with your key. Existing data remains encrypted with the previous key (Microsoft-managed or old CMK). Over time, as data is rewritten (e.g., during log retention or index rotation), it will be re-encrypted with the new key. You can force re-encryption using the workspace migration feature.
CMK is supported in most Azure regions, but not all. You should check the Azure documentation for the latest list. Key Vault must be in the same region as the workspace. Some sovereign clouds (e.g., US Gov) may have limitations.
CMK (Customer-Managed Key) means you create or import a key into Azure Key Vault and use it to encrypt your data. BYOK (Bring Your Own Key) is a method of importing a key from your on-premises HSM into Azure Key Vault. BYOK is a subset of CMK; all BYOK keys are customer-managed, but not all CMK keys are BYOK (you can generate keys natively in Key Vault).
You've just covered Sentinel Customer-Managed Keys (CMK) — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?