Customer Managed Keys not configured

[TonyWildish-BH]

The penetration testing report showed that (page 42):

By default, all resources within Azure are encrypted with Microsoft Managed keys at rest. These keys are fully managed by Microsoft and will be automatically rotated and re-generated, as per their own compliance requirements.

With Customer-managed keys (CMK), Azure customers have control over the key and therefore more control over the data it protects, providing greater flexibility and allowing them to enforce their own key rotation policies. In the event of a security incident, the affected key can simply be revoked to prevent further compromise. CMKs also allow for tracking and monitoring of when the key is used, helping detect unauthorised attempts to access data.

Additionally, Microsoft can be compelled by legal request to hand over all encryption keys, which can happen without the customer being notified.

Microsoft-managed encryption keys were found to be in use on the following resources:

• Storage Accounts
• Key Vaults
• SQL Servers

This is a medium level risk, but is something we must fix before the next pen-test.

[TonyWildish-BH]

• Check UK GOV or NHS blueprints to see if we need to do anything at all.
• Can MS be compelled to hand over CMKs, and under what circumstances?

What real benefit do we get from CMKs?

[TonyWildish-BH]

From Steven:

This was the best reference on the blueprint I found - https://learn.microsoft.com/en-us/azure/governance/policy/samples/ukofficial-uknhs - which does not really cover CMKs.

Looking at some of the links from https://learn.microsoft.com/en-us/industry/sovereignty/customer-managed-keys I feel they are all for very specific regulatory use cases. Until we find out the NHS mandates, or a much clearer use case, I cant see any real need for this.

There was one note about tenancy level CMKs or service specific. Could/should we do this for the long-term storage of data for the SDE (if we do this) or for the shared storage in a workspace? But again there seems to be no compelling reason for doing this.

I would say we have investigated, it does not seem easy and it does not seem needed, to we did not do it!

So, we can close this ticket.