Hi Alex. I designed the feature and wrote a threat analysis for it. I'm not at home now with access to the file. Want to connect me with the person looking for this info?
Hello again Alex,
I read the core of the inquiry as this statement "If MS has a compromise in the infrastructure that exposes Availability Keys, it does not matter that I have paid for a separate Customer Key" with an implied question of "Is this a fair assertion?"
Assuming that I have correctly inferred the question, the answer is "No, it is not a fair [correct] assertion." The reason, however, is likely unintuitive. It is simply this: Customer Key is not a "security" or "privacy" measure, and an attacker that can "break in" and obtain a tenant's Availability Key has already gained complete access to the files/data stored by that tenant. It would, in fact, be rather pointless to "steal" or copy the Availability Key because there is no direct way to use it to unencrypt the customer data. Simply put, a customer uses the Customer Key feature because of a compliance obligation to "bring your own key" and/or to have the option to shrink the period between quitting the Microsoft service and the point at which data recovery/access is no longer possible by Microsoft.
Hope that helps,Paul
Hi - I don't keep up with the Microsoft documentation any longer but the link that Alex originally posted should provide enough information to make informed decisions. I'd strongly advise that the primary focus should be on what you are trying to accomplish - the end goal. If the end goal is to somehow change the privacy dynamics relative to the cloud security provider, you are barking up the wrong tree.
Hi All - long time lurker, but first time posting. Hope to be more active group member going forward.
I think this can be answered on a more generic level than just about O365/Exchange. To Paul's point: answer to questions like this should almost always be "CMK in a way it is offered by major cloud providers for at-rest encryption is not a security control hence has no bearing on overall threat profile of the service. In particular, it does not affect materially either legitimate or compromised access by CSP". It depends a bit on a specific implementation (e.g. additional layer of encryption vs simply access to the key management interface, although efficacy of layers upon layers can be easily challenged as well), but this is a reasonable rule of thumb. I have wrote a piece earlier this year where I try to explain this in simple terms: https://medium.com/@marcinjkot/customer-mis-managed-key-or-why-you-dont-need-cmk-79954930462
Secondly, I don't think a single article of MS practices and architecture of key management exists; Azure is really a collection of products, managed by separate product groups which operate more or less like small companies under a common umbrella. If we want to deep dive specific architecture, we need to do this in the context of a particular service.
Thank you for all of the responses. The replies are being shared with the requesting CISO and will let everyone know of any follow ups.Thanks again.