L’œil de l’actu

Restez au contact de l’actualité transformation et cloud

Voir tous les articles

Découverte Azure Disk Encryption

article-1

Le billet « Cacher les mots de passe en Powershell » ayant eu beaucoup de succès, j’ai décidé de passer un peu plus de temps sur Azure Key Vault. En creusant un peu, on comprend qu’elle permet de stocker un grand nombre de secrets, y compris les clés de chiffrement de Bitlocker, ce qui nous amène au service Azure Disk Encryption, encore en Preview au moment où je rédige cet article. Linux n’étant pas encore ma tasse de thé, ce sera donc à Windows que je vais consacrer mon billet.

 

Le couplage d’Azure Disk Encryption avec Azure Key Vault est une évidence : Remplacer le TPM que nous avions On- Premises pour y stocker notre secret. Azure Key Vault étant un service Cloud, il est capable de stocker bien plus qu’un secret avec un niveau de sécurité bien plus élevé. Pour information, les instances « Premium » du service Azure Key Vault sont hébergées sur des boitiers HSM Thales certifiés FIPS 140-2 Level 2. Pourquoi s’en priver ?  La mise en place s’effectuera selon les étapes suivantes :

  • Mise en place des prérequis
  • Activation pour le disque OS de notre VM IaaS
  • Constats dans la machine virtuelle

 

Mise en place des prérequis

Azure Disk Enryption nécessite la version 1.1.0 du module Powershell Azure Active Directory. Une rapide commande « Get-Module Azure -ListAvailable » nous inique que j’ai bien la version minimale.

Azure_Disk_Encryption_1

Ceci vérifié, on peut s’attaquer au grand classique de l’authentification avec Login-AzureRmAccount.

Azure_Disk_Encryption_2

Et sélectionner la souscription que nous allons utiliser avec les commandes Get-AzureRMSubscription et Select-AzureRMSubscription.

Azure_Disk_Encryption_3

Pour travailler, nous allons avoir besoin d’une machine virtuelle qui a été provisionnée dans le groupe de ressources AzureDiskEncrypt, ce que j’ai bien avec les commandes suivantes :

Get-AzureRMresourceGroup -Name AzureDiskEncrypt

Get-AzureRMVM -Resourcegroupname ‘AzureDiskEncrypt’ | Select ResourcegroupName, Name, Location, ProvisioningState

Azure_Disk_Encryption_4

, j’avais mis en œuvre un Key Vault dans son édition standard. Cette fois, j’utilise l’édition Premium, juste pour bénéficier du stockage sur un HSM certifié FIPS 140-2 Level 2. Comme indiqué plus tôt, à ce tarif, ce serait criminel de ne pas l’utiliser. La commande suivante va nous permettre de créer mon coffre-fort numérique dans le même groupe de ressources pour raisons de simplicité. Donc allons y :

New-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEnrypt’ -Location ‘North Europe’ -SKU ‘Premium’.

Azure_Disk_Encryption_5

Remarque : Une limite à connaitre, le Key vault que nous allons utiliser pour la fonctionnalité Azure Disk Encryption doit nécessairement dépendre de la même région Azure que les machines virtuelles sur lesquelles nous allons activer la prise en charge. Dans un sens c’est logique, ou alors on devrait accepter que les secrets sortent d’une région et donc d’un Datacenter.

 

Notre coffre à secrets est en place et accessible via une URL. Pour l’instant, je suis le seul à avoir tous les privilèges, ce qui est normal en tant que créateur. A ce stade, on peut constater que notre coffre-fort numérique n’est pas éligible aux fonctionnalités qui nous intéresse. Nous allons y remédier avec les commandes Powershell suivantes :

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEncrypt’ -EnabledForDiskEncryption -EnabledForDeployment

Get-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’ -ResourceGroupName ‘AzureDiskEncrypt’

Azure_Disk_Encryption_6

Je vois tout de suite qu’il y en a qui se demandent pourquoi l’option ‘-EnabledForTemplateDeployment’ n’a pas été utilisée. La réponse est venue de la documentation de la commande New-AzureRmKeyVault : « Note: This parameter is not currently implemented. ». On est bien en Preview.

 

On arrive bientôt à la fin des prérequis, plus que deux. Pour que nos machines virtuelles puissent utiliser notre coffre-fort numérique, il nous faut deux choses :

  • Une identité que nos machines virtuelles pourront utiliser pour accéder à notre coffre-fort numérique (plus précisément l’extension de machine virtuelle)
  • Une ressource à laquelle nous allons accorder des accès.

 

Il m’a fallu un peu de temps pour comprendre le modèle mais c’est logique. Pour piloter la mise en place de la fonctionnalité Azure Disk Encryption, nous allons injecter un agent dans la machine virtuelle. Du point de vue de Windows Azure Active Directory, notre machine virtuelle n’a pas d’identité, il faut donc l’aider en lui fournissant une identité, laquelle sera utilisée pour accéder au coffre-fort numérique.

 

Au moment où je rédige ce billet, Windows Azure Active Directory est encore disponible uniquement depuis l’ancien portail. C’est donc depuis celui-ci que nous allons déclarer une nouvelle application dans notre tenant Windows Azure Active Directory.

Azure_Disk_Encryption_7

 

L’application référencée pointera directement sur l’URL de la ressource de notre coffre-fort numérique.

Azure_Disk_Encryption_8

C’est là qu’intervient une subtilité. Pour configurer notre agent, il va avoir besoin de deux informations :

  • Un Client ID
  • Une clé.

Azure_Disk_Encryption_9

C’est un peu comme un login & Mot de passe. Nous allons garder ces informations dans un coin. On va commencer par autoriser l’accès au coffre-fort numérique pour cette identité avec la commande Powershell suivante : Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MyKeyVaultHSM’ -ServicePrincipalName ‘<ClientID>’ -PermissionsToKeys All -PermissionsToSecrets All

Azure_Disk_Encryption_10

Pour vérifier que cela fonctionne, il suffit s’afficher les caractéristiques de notre coffre-fort numérique avec la commande Get-AzureRMKeyVault -VaultName ‘MyKeyVaultHSM’. On constate que le ClientID que nous avons fourni a été reconnu. Pour simplifier, j’ai volontairement simplifié la mise en œuvre. Dans un véritable déploiement, on limiterait l’accès à certains types de secrets, voire jusqu’à segmenter en plusieurs coffre-fort numériques en fonction des usages. Si ça vous intéresse, l’aide en ligne de la commande PowerShell Set-AzureRmKeyVaultAccessPolicy est un bon point de départ.

 

Activation pour le disque OS de notre VM IaaS

C’est maintenant que cela commence à devenir intéressant. Pour commencer on va personnaliser le portail pour faire apparaitre une nouvelle colonne. Pour l’instant, le service Azure Disk Encryption est bien désactivé.

Azure_Disk_Encryption_11

On peut avoir le même résultat avec la commande Powershell suivante : Get-AzureRMVMDiskEncryptionStatus -ResourceGroupName ‘AzureDiskEncrypt’ -VMName AzureVM01

Azure_Disk_Encryption_12

L’information est ici plus précise puisqu’on sépare le statut du disque OS des éventuels disques de données. Dernière étape, l’activation de l’agent de chiffrement dans notre machine virtuelle. Pour commencer, on va mettre de côté quelques informations sur notre coffre-fort numérique avec la commande Powershell suivante : $Vault = Get-AzureRMKeyVault -Resourcegroupname ‘AzureDiskEncrypt’ -VaultName ‘MyKeyVaultHSM’

Azure_Disk_Encryption_13

On a tout ce qu’il nous faut, on passe au tour de magie. L’installation de l’agent va nécessiter le redémarrage de notre machine virtuelle ainsi qu’un peu de temps pour activer Bitlocker. Voilà la formule magique :

Set-AzureRMVMDiskEncryptionExtension -ResourceGroupName ‘AzureDiskEncrypt’ -VMName ‘AZUREVM01’ -AadClientID ‘<Identifiant Client ID de l’application dans le portail>’ -AadClientencryptionKeyVaultURL $vault.VaultUri -DiskEncryptionKeyVaultID $Vault.ResourceId

Azure_Disk_Encryption_14

 

Après quelques minutes et un redémarrage de la machine virtuelle, la commande Powershell rend la main en nous indiquant un succès. Un rapide Get-AzureRMVMDiskEncryptionStatus -ResourceGroupName ‘AzureDiskEncrypt’ -VMName AzureVM0’1 nous confirme que le chiffrement est bien activé, au moins pour le disque OS pour lequel on a maintenant un secret dans le coffre-fort numérique.

Logiquement, si on a activé la fonctionnalité Bitlocker, on devrait avoir des secrets dans notre coffre-fort numérique. Je dis bien des secrets car au minimum, une machine virtuelle est composée de deux disques dur :

  • Le disque OS
  • Le disque temporaire

C’est pour cela que la commande Get-AzureKeyvaultSecret -VaultName ‘MyKeyVaultHSM’ nous indique deux secrets.

Azure_Disk_Encryption_15

Constats dans la machine virtuelle

On a passé assez de temps dans les nuages, allons constater que notre système d’exploitation a bien activé Bitlocker. Juste après l’authentification, un joli message nous indique que cela se présente bien :

Dans le détail, effectivement, ça se présente même très bien dans le panneau de configuration.

Azure_Disk_Encryption_17

Pour finir, comme j’aime de moins en moins les interfaces graphiques, je repasse en Powershell avec la commande Get-BitlockerVolume :

Azure_Disk_Encryption_18

Là, les résultats sont sans appel. On a bien deux volumes pour lesquels Bitlocker est activé (dont un en cours d’activation). Y a juste une subtilité qui m’échappe. Le KeyProtector indique ‘ExternalKey’. Elle est ou cette clé. Pour rappel, n’a pas de TPM. La réponse m’est apparue quelques minutes plus tard en regardant l’explorateur Windows.

Ce nom ne m’est pas inconnu, allons revoir les secrets dans notre coffre-fort numérique

Get-AzureKeyVaultSecret -Vaultname ‘MyKeyvaultHSM’ | Select Name

Get-AzureKeyVaultSecret -Vaultname ‘MyKeyvaultHSM’ -name ‘EBCAF0E6-3AAB-4234-9B64-AB84DCC1A0DA’

Azure_Disk_Encryption_20

C’est la clé Bitlocker. La VM Extension utilise donc un disque additionnel pour y placer le secret qu’elle a extrait de mon coffre-fort numérique.

 

Conclusion

La fonctionnalité est encore en Preview mais vu que seul l’accès aux secrets est facturé 0,8433€ par secret par mois, ce sera une fonctionnalité obligatoire lorsqu’elle passera en General Availability. 1€ pour stocker des clés de chiffrement dans des boitiers HSM Thales certifiés FIPS 140-2 Level 2, ce serait criminel de s’en passer. Pour rappel dans le Cloud, la responsabilité de vos ressources et contenu de votre tenant est sous votre responsabilité. Microsoft fournit les moyens de sécuriser nos ressources, nous seuls sommes responsables en cas d’incident de sécurité.