L’implémentation du chiffrement BYOK sous Microsoft 365 depuis un HSM client propriétaire
- Othmane El Hanchi
- 5 janv.
- 3 min de lecture
Dans cet article, nous partageons un retour d’expérience concernant l’implémentation du chiffrement BYOK sous Microsoft 365 depuis un HSM client propriétaire.
Le BYOK (Bring Your Own Key) est un modèle de chiffrement permettant aux entreprises de contrôler les clés utilisées pour le chiffrement de leurs données métiers. (Messagerie Asynchrone/Instantanée, Espaces disques, Outils de collaboration …)
En pratique, la gouvernance des clés est assurée au travers d’un HSM (Hardware Security Module) une technologie permettant l’externalisation de la gestion des clés cryptographiques pour assurer un niveau de sécurité plus élevé (protection de l’intégrité des données chiffrées, contrôle d’accès physique / logique granulaire et surveillé , enforcement d’audits réguliers, résilience aux conditions environnementales …)
Il convient toutefois d’écarter une confusion importante qui peut survenir à ce propos :
Le BYOK sous M365, contrairement au HYOK (Host You Own Key) ne permet pas de garantir la souveraineté sur les données stockées dans le Cloud MS
Microsoft possèdera toujours un accès aux données chiffrées en BYOK
En effet lorsque vous importez vos clés asymétriques depuis un HSM privé vers Azure, vous concédez l’exclusivité sur vos clés privées et entrez alors dans un modèle de co-propriété où vous n’êtes plus l’unique détenteur de vos propres clés.
Les modes de chiffrements CMK (Customer Managed Keys) classiques supportés par Azure, présupposent l’importation des clés privées qui ne sont plus alors stockées seulement sur le HSM propriétaire mais aussi sur le HSM Azure. (eg Azure Key Vault)
Le schéma ci-dessous illustre le lien entre KEK (Key Encryption Key) aussi appelées clés racines (Root Keys) et DEK (Data Encryption Key).
Comme on peut le constater il existe 3 copies chiffrées distinctes de la DEK, chacune permettant d’accéder à la donnée sous-jacente.
Dans la pratique les services Microsoft utilisent vos clés privées qui ont été importées dans Azure Key Vault depuis le HSM, afin de déchiffrer la DEK via API protégée et soumise aux réglementations FIPS 140-2,3.
Concernant le chiffrement des données de services M365 (Exchange / Sharepoint / Teams etc.) Microsoft crée en parallèle une troisième copie de la DEK chiffrée par une clé dite de haute-disponibilité (Availability Key) appartenant à Microsoft.
En cas de panne ou d’urgence critique (eg suppression, corruption ou perte des clés racines), le client peut alors contacter Microsoft afin d’enclencher une procédure spéciale afin de mettre en service cette clé de haute disponibilité et remettre en route les services M365.
Malgré les limitations évoquées précédemment, le BYOK vous permet tout de même de garder un certain contrôle sur vos clés de chiffrement à travers les points suivants :
Maitrise de la fréquence de rotation des clés racines (KEK)
Enforcement de la rotation de la clé de haute disponibilité Microsoft
Enforcement de la rotation de la clé de données symétrique (DEK)
Failover en cas de compromission totale ou partielle des Key Vault Azure ou de déni de service
Le processus de rotation des clés est en soit assez simple et peut être lancé en quelque minutes en suivant la documentation suivante :
Nous avons noté cependant la nécessité d’appartenir à minima au rôle Exchange Compliance Manager afin de pouvoir lancer les commandes de gestion DEP permettant d’exécuter la rotation des clés racines.
Après avoir importé les nouvelles clés privées dans les Key Vault Azure, il faut initialiser la demande d’enregistrement de ces nouvelles clés customer en mode validation puis activation respectivement.
Les valeurs SubscriptionID1 et SubscriptionID2 peuvent être égales dans le cas où les Key Vault seraient stockés sur la même souscription Azure.
La commande suivante permet de créer une nouvelle DEP (Data Encryption Policy) basée sur ces clés de chiffrement asymétrique.
Ensuite il faut affecter cette DEP à l’ensemble des services M365 (multiworkload) à travers la commande suivante :
L’execution de cette commande va enclencher le re-chiffrement des données utilisateurs avec une nouvelle clé de chiffrement symétrique elle même protégée par vos nouvelles clés privées.
Elle permet également en arrière plan de forcer la rotation de la clé de haute disponibilité Microsoft.
Il existe également des commandes équivalentes permettant de cibler un service en particulier (Exchange/Sharepoint/Onedrive) plutôt que l’intégralité des services M365.
Il faut enfin compter le temps de chiffrement des espaces M365 pour chaque utilisateur, le processus n’étant pas instantané, ce qui dans notre cas et sur une base < 1.000 utilisateurs a duré un peu moins de 24 heures.
Commentaires