Managing keys and data in the MS Cloud

At the recent Microsoft Ignite event, I attended the "Achieving compliance by protecting and controlling your data with encryption in Microsoft 365" session.

It highlighted that there are several levels of encryption available with Microsoft 365.  There is Network encryption with TLS to protect data in transit, BitLocker, and Service Encryption (both to protect data at rest).  They all require keys for encryption and decryption of the data.  Beyond that, protection of the keys and data access must be considered.
In Microsoft 365 you can manage keys in a few different ways.  The method of key management that you select is dictated by how much responsibility you want to have and what compliance requirements you must adhere to.  You can lessen the responsibilities on the customer side, but they will never be zero.  There isn't much that the customer can do about the external compliance requirements placed on the company.

The first option is to have Microsoft manage the keys.

This option is simple and lowers the administrative burden on the customer.  Microsoft manages a private key which is stored in an Azure Key Vault.  This option is readily available with an Office 365 E3 or higher subscription.
If you are subject to a compliance requirement that prevents you from making use of Microsoft management of your keys (such as "Proof of Possession" and "End to End Control"), the "Bring Your Own Key" (BYOK) option may be the best option for you.  BYOK imports all your keys into the Azure Key Vault using BYOK.  You can then prove possession and show end-to-end control of the certificates.

The last option is "Hold Your Own Key" (HYOK), which uses an on-prem Active Directory Rights Management Services (ADRMS) instance.

You only really use HYOK for secret, very sensitive data. Microsoft estimates that only 1-2% of customers will actually need this type of key management.  They are the ones who are subject to a compliance requirement which then must be able to show physical possession of their encryption keys.  This makes the data "opaque" to the cloud.  Services such as search, index, mailbox rules, and other forms of data reasoning are not available with HYOK.  External sharing of the data is extremely difficult.

The Ignite session emphasized that if you need to externally share the data, you need to reconsider why you chose HYOK in the first place.

In fact, the presenters clearly stated that before implementing HYOK to think twice, think thrice, and then think ten times more.  The good news is that HYOK is not an exclusive choice.  You can use BYOK and HYOK in conjunction with one another.
If you lose your keys, you lose access to your data.
There are ways to protect against this unpleasant possibility.  An Availability key can be configured, which allows for high-availability in cases where there are network issues, a need for emergency restore of service, or system maintenance calls.  Use of the Availability key may require a service call to Microsoft to enable it.  The key is controlled by the customer and is stored in the Office 365 back end rather than in the Azure Key Vault.  You can create a second key, as well. That key is stored in the vault and set to have a "soft delete" policy. Then it's recovered within 90 days if need be.

Something else to think about with relation to information storage is the data purge path.

How do you remove data from the system?  What is the process, and is it sufficient to prevent accidental or malicious removal of data?  When the customer makes the decision to purge their data, for example, if they decide to stop using the Microsoft cloud services, a specific procedure must be followed before the data is removed.  Different people with different roles perform tasks, preventing any one person from committing either an error or a deliberate act of sabotage.

You can remove permissions from the vaults by the Azure Key Vault Admin.

The Tenant Admin sets a permanent data purge flag and the customer is notified.  Microsoft calls to confirm the request to purge the data. Then a document signed by a C-Level exec verifies that the data is to be purged.  Once the requirements have been met, the data is removed from the Microsoft online cloud services.
So, it appears that there was an attempt to cover all the bases.  The keys used for encryption in Microsoft 365 are critically important. Each key is managed in different ways. And of course, there are different implications for each type.  The keys must be protected as well because protecting the keys is synonymous with protecting your data.  Lose your keys, lose your data.

Microsoft has also implemented a process for purging data from their cloud services. It protects against wholesale accidental or malicious data deletion.

This was just an overview, but from what I can see I think the approach was well thought out.  Technology evolves.  I have seen it all! If anything has been missed or if new needs arise, the people at Microsoft will be right there to address the challenges.