Aujourd’hui, je souhaitais partager une considération lors de l’implémentation d’Azure Information Protection dans votre entreprise. Pour rappel, Azure Information Protection permet de classifier et labéliser la donnée au moment de la création en fonction de différentes étiquettes et catégories. L’administrateur peut ensuite appliquer des stratégies de protection embarquée dans la donnée en fonction de la classification appliquée. Ce service est issu du rachat de Secure Islands et du retravaille d’Azure Rights Management (RMS).
Parmi les questions que l’on a lors des phases d’Avant-Vente sur ce genre de solutions ainsi que pour le Cloud, c’est : Est-ce que l’on peut faire un retour arrière ?
La réponse est oui puisque les super utilisateurs (super user) peuvent déchiffrer tous les fichiers de l’entreprise. Vous pouvez aussi utiliser les cmdlets PowerShell via Unprotect-RMSFile
Plus globalement, je pense que le point d’attention n’est pas nécessairement sur la sortie de la solution mais sur les éventuels scénarios qui pourraient survenir lors de la vie de l’entreprise. On peut par exemple penser aux rachats, fusions, etc. Ou tout simplement à un changement de tenant Azure Active Directory.
Il est possible d’exporter la clé de chiffrement d’un tenant et l’importer sur un nouveau tenant mais ceci ne peut pas être réalisé avec la clé par défaut.
Dans ce cas de figure, il faut peut-être penser à ces aspects en avance de phase lors de l’implémentation pour éviter à devoir déchiffrer entièrement le contenu pour le rechiffrer. On retrouve plusieurs capacités :
- Se donner la possibilité d’exporter une clé de chiffrement afin de la déplacer entre tenants. Pour cela vous pouvez :
- Utiliser votre propre clé via le principe de Bring Your Own Key (BYOK).
- Créer une clé dans l’Azure Key Vault (sans BYOK) et suivre la procédure BYOK avec cette clé.
Lors de la migration, vous devez exporter la clé puis supprimer la clé du tenant original et enfin importer la clé sur le nouveau tenant. Vous devez aussi recréer les modèles, les utilisateurs, etc. Bien entendu, je ne peux que conseiller de valider la procédure sur un tenant de tests pour s’assurer qu’il n’y a pas d’effets de bord.
- Utiliser Active Directory Rights Management Services (AD RMS) comme source de clés.
- Déployer AD RMS avec le type de clé voulu
- Exporter la clé et les modèles vers Azure RMS en utilisant le guide Azure RMS Migration
- Répéter l’opération sur l’éventuel nouveau tenant.
Personnellement, je préfèrerais le scénario 1.
Bien entendu, il existe d’autres considérations sur les étiquettes/labels, etc.
