Archives mensuelles : mars 2016

Découverte d’Azure Disk Encryption (Preview)

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.

clip_image001

 

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

clip_image002

 

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

clip_image003

 

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

clip_image004

 

Dans mon dernier billet, 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’.

clip_image005

 

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’

clip_image006

 

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.

clip_image007

 

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

clip_image008

 

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

  • Un Client ID
  • Une clé.

clip_image009

 

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

clip_image010

 

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é.

clip_image011

 

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

clip_image012

 

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’

clip_image013

 

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

clip_image014

 

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.

clip_image015

 

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 :

clip_image016

 

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

clip_image017

 

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

clip_image018

 

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.

clip_image019

 

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’

clip_image020

 

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é.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Gabarit de certificat pour utiliser CMSMessage de Powershell 5.0

Honte à moi. Un certificat auto-signé dans mon dernier billet. J’avoue, je l’ai écrit sur mon canapé, et uniquement survolé la page Technet avant de me rendre compte de mon impardonnable erreur. Vu que le Technet ne donne pas les spécifications du gabarit de certificat à utiliser pour ADCS, je m’y colle en pénitence.

Comme base de travail, j’ai retenu le gabarit user. Pourquoi? Car je compte limiter ce type de certificats aux seuls comptes de services membres d’un groupe spécifique. Pas besoin que tous mes systèmes disposent de ce type de certificat. En plus avec ce choix, je vais limiter l’accès à ce certificat aux seuls comptes de service et non la totalité des comptes qui peuvent accéder au magasin personnel de l’ordinateur avec des privilèges administrateur ou supérieur.

Après, vu que pour utiliser la fonctionnalité CMSMessage, il faut PowerShell 5.0, j’ai choisi de limiter les systèmes éligibles en conséquences. Pour installer de Windows Management Framework 5.0, il faut au minimum un système d’exploitation de génération Windows 7 / Windows 2008 R2.

clip_image001

Dans l’onglet général, on nomme notre nouveau gabarit de certificat « CMS Message », pas grand-chose à dire sinon que ça ne sert à rien de publier le certificat dans l’Active Directory dans notre cas.

clip_image002

Dans l’onglet « Request Handeling », une seule chose compte, la capacité à exporter la clé privée. C’est grâce à elle qu’on sera en mesure de déchiffrer notre CMSMessage.

clip_image003

Pour la construction du Subject Name, il y a eu un peu de travail. Par défaut, le gabarit de certificat était prévu pour construire l’attribut en utilisant les informations issues de l’annuaire Active Directory. Bien, mais le problème, il est rare qu’un compte de service ou même un ordinateur se voit affecté une adresse de messagerie. Pour cela, j’ai dû procéder à quelques adaptations :

  • Ne pas inclure l’adresse de messagerie dans l’attribut Alternate Subject Name
  • Ne pas inclure l’attribut E-Mail
  • Ne pas inclure le DNS Name (pas de sens pour un utilisateur)
  • Mais bien inclure un UPN

clip_image004

C’est maintenant qu’il faut introduire la subtilité. Pour que la commande Protect-CMSMessage accepte d’utiliser notre certificat, il doit avoir un rôle bien particulier. Pas de bol, il est pas dans le gabarit de certificat que nous avons utilisé comme base de travail. Qu’à cela ne tienne, on va le personnaliser.

clip_image005

Pour être sûr que notre certificat ne soit pas détourné pour un autre usage, on va faire le ménage dans les EKU et ne positionner que « Document Encryption ».

clip_image006

Maintenant, c’est mieux.

clip_image007

On approche de la fin. Ne pas limiter la capacité d’enregistrement de certificat, c’est la porte ouverte à toutes les fenêtres, des certificats délivrés à gogo sans se soucier qu’un jour il faudra les renouveler, ce qui bien sûr arrive toujours au pire moment. En limitant la capacité d’enrôlement aux seuls membres d’un groupe, on saura déjà à qui on a délivré ces certificats.

clip_image008

Y a plus qu’à publier notre gabarit de certificat et Zou, à la signature.

clip_image009

Une fois la session ouverte avec notre compte de service, on peut réaliser la demande.

clip_image010

C’est fini. Pour s’assurer que cela fonctionne, une rapide commande Powershell « Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert » nous confirme que nous avons bien un certificat prévu pour cet usage dans le magasin. Vu que c’est le cas, y a plus qu’à chiffrer notre message :

$Cert = Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert

$CMSMessage = Protect-CMSMessage -Content « Ilachangé! » -To $Cert/Thumbprint

clip_image011

 

Aller, je retourne me punir, j’ai du python sur le feu. Je ne déconne pas

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Cacher les mots de passe dans les scripts Powershell

Nous passons tous beaucoup de temps à industrialiser avec PowerShell. Il n’est pas rare que je retrouve les mots de passe codés en dur dans les scripts. Pour éviter ces dérives, j’ai compilé dans ce billet quelques méthodes pour cacher ces mots de passe, du plus simple, au plus sexy

En PowerShell, la gestion des credentials est quelque chose que nous semble très simple. On sait tous que l’on peut « sécuriser » les mots de passe avec le fameux ConvertTo-SecureString. Le problème, c’est que cette fonction est réversible avec la méthode « Get-NetworkCredential ». Pour vous donner une idée, une rapide démonstration :

clip_image002

Le problème, c’est que dans l’exemple ci-dessous, PowerShell utilise Windows Data Protection API (DAPI). Cela signifie que seul le même compte est capable de chiffrer/déchiffrer notre secret. Stocker l’information dans un fichier ou dans le registre. On va devoir ruser pour ne pas utiliser une clé de chiffrement locale au système d’exploitation. Si on creuse un peu la commande ConvertFrom-SecureString, on trouve deux paramètres intéressants :

clip_image004

Donc si on utilise une clé externe de taille assez grande, on devrait être capable de chiffrer nos données en étant indépendant du système d’exploitation. Commençons par chiffrer notre information avec notre nouvelle clé.

$ScriptPath = (Split-Path -parent $MyInvocation.MyCommand.Definition)

[Object] $Cred = $null

[Guid] $Key = « e8bdc7c5-a62c-4fa3-9228-5abe22488141 »

[String] $CredFile = « $ScriptPath\CredData.ps1xml »

if ( $Cred -isnot [System.Management.Automation.PSCredential] )

{

[Object] $Cred = (Get-Credential -Message « Service Account »)

[Object] $CredData = $Cred | Select-Object -Property UserName,@{Name= »SecurePassword »; Expression={ ConvertFrom-SecureString -SecureString $_.Password -Key $Key.ToByteArray() }}

$CredData | Export-CliXml -Path $CredFile -Encoding Unicode -Force

Remove-Variable -Name CredData -Force

}

Get-Content $CredFile

clip_image006

Logiquement, on doit pouvoir faire l’inverse facilement avec le script suivant :

$ScriptPath = (Split-Path -parent $MyInvocation.MyCommand.Definition)

[Guid] $Key = « e8bdc7c5-a62c-4fa3-9228-5abe22488141 »

$CredFile = « CredData.ps1xml »

[Object] $CredData = Import-CliXml -Path ($ScriptPath + »\ » + $CredFile)

if ( $? )

{

$SecurePassword = ConvertTo-SecureString -String $CredData.SecurePassword -Key $Key.ToByteArray()

$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList ($CredData.UserName, $SecurePassword)

$Credential.GetNetworkCredential() | Format-Table *

}

clip_image008

Note : On m’a fait remarqué cette semaine que cela aurait été encore mieux d’utiliser le paramètre « -SecureKey ». Notre clé aurait alors été encodée dans un System.Security.SecureString. Merci Sylvain.

Le problème, c’est que ma clé est lisible dans le script. Ce qu’il faudrait, c’est de pouvoir la disposer d’un mécanisme me permettant de chiffrer des données avec une clé qui soit reconnue d’autres systèmes mais qu’on ait pas besoin de la même clé. Un truc comme une clé asymétrique. Chiffrer des données avec un certificat, c’est utiliser la clé publique pour cela. Pour déchiffrer, on aura besoin de la clé privée. Nous allons avoir besoin d’un certificat qui devra être présent :

  • Sur le système qui assure le chiffrement du message (en l’occurrence un mot de passe)
  • Sur les systèmes qui devront accéder à cette information

Cela implique que le certificat que nous allons demander devra être :

  • Reconnu comme issu d’une autorité de certification reconnue de toutes les parties
  • Être exportable

Ces points techniques résolus, attaquons nous au chiffrement de notre message avec quelques lignes de PowerShell :

$cert=Get-ChildItem Cert:\LocalMachine\my | where {$_.Subject -like « CN=Powershell Authentification* »}

$Password = ‘Il a changé!’

$EncodedPassword = [System.Text.Encoding]::UTF8.GetBytes($Password)

$EncodedBytes = $Cert.PublicKey.Key.Encrypt($EncodedPassword, $True)

$EncryptedPassword = [System.Convert]::ToBase64String($EncodedBytes)

clip_image010

Quelques explications s’imposent. On commence par localiser le certificat que nous allons utiliser et encoder notre mot de passe au format UTF8. Ceci-fait, on encode notre mot de passe à l’aide de la clé publique de notre certificat et con convertit le tout en Base 64. Ca ressemble plus du tout à notre mot de passe. On peut communiquer cela tel que, aucun risque que cela puisse être décodé sans la privée. Justement, allons voir comment décoder cela sur un autre système avec un peu de PowerShell :

$cert=Get-ChildItem Cert:\LocalMachine\my | where {$_.Subject -like « CN=Powershell Authentification* »}

$Encryptedcontent = Get-Content .\secret.txt

$Encryptedcontent

$EncryptedBytes = [System.Convert]::FromBase64String($Encryptedcontent)

$DecryptedBytes = $Cert.PrivateKey.Decrypt($EncryptedBytes, $True)

$DecryptedPassword = [System.text.Encoding]::UTF8.GetString($DecryptedBytes)

clip_image012

Si on a compris la logique, on commence par reconvertir notre contenu en une chaine de caractères pour laquelle on va utiliser la clé privée de notre certificat pour déchiffrer notre message. L’avantage de cette approche est qu’elle est indépendante du système d’exploitation, même Cross-Plateforme. Autre avantage, on peut limiter l’accès à la clé privée. Il faut juste décider qui à accès à la clé privée.

clip_image014

Ça c’était bien avec les vieilles versions de PowerShell, ça fonctionne super, même avec Orchestrator, c’est pour dire, … On ne peut pas faire plus sexy avec des versions plus récentes ? Oui, car depuis la version 5.0, on dispose de la fonctionnalité CMSMessage. L’aide intégrée de PowerShell ne vas pas vous aider beaucoup.

clip_image016

Avec la version en ligne de Protect-CMSMessage, c’est déjà mieux. On utilise toujours un certificat, sauf que cette fois, notre certificat devra comprendre l’EKU « Document_Encryption » pour qu’on puisse l’utiliser avec la commande Protect-CMSMessage. J’ai donc préparé une demande de certificat en bonne et due forme ou presque. En fait, ce sera un certificat auto-signé (j’ai fait court pour la démonstration).

clip_image018

Au passage, un switch bien pratique que je ne connaissais pas pour filtrer les certificats : Get-ChildItem Cert:\CurrentUser\My -DocumentEncryptionCert

En une seule commande on va être capable de chiffrer notre message : $Message = Protect-CmsMessage -Content $Password -To « *benoit@simplebydesign.fr ». Après, y a plus qu’à empaqueter et transmettre.

clip_image020

De l’autre côté, même principe. On commence par localiser le certificat que nous allons utiliser pour déchiffrer à l’aide de la commande Get-ChildItem Cert:\CurrentUser\My DocumentEncryptionCert. Reste plus qu’à déchiffrer.

clip_image022

Jusque-là, on parlait On-Premises, Old-School IT. Et si on regardait comment faire de même dans Azure. Y a forcément un service pour cela. Oui, C’est Azure Key Vault. Avant cela, faut un peu préparer le terrain. On peut faire cela en PowerShell assez rapidement :

Install-Module AzureRM

Install-AzureRM

clip_image024

Justement, le dernier installé nous intéresse. Continuons notre mise en place, on y reviendra. Continuons avec l’installation du module PowerShell Azure, chargeons tous les modules Azure Resource Managers et celui d’Azure avec les trois commandes suivantes :

Install-Module Azure

Import-AzureRM

Import-module Azure

clip_image026

La première étape d’Azure, c’est l’authentification. Ça se règle en deux commandes PowerShell :

$Cred = get-Credential

Login-AzureRMAccount -Credential $Cred

clip_image028

La commande Get-AzureRMSubscription nous indique que j’ai accès à plusieurs souscriptions. Nous allons nous fixer sur l’une d’entre elle.

clip_image030

Les prérequis sont en place. Nous devons mettre en place notre Azure Key Vault au sein d’un groupe de ressources dédié (sécurité oblige)

New-AzureRmResourceGroup -Name ‘MyKeyVault’ -Location ‘North Europe’

New-AzureRMKeyVault -VaultName ‘MesPrecieux’ -ResourceGroupName ‘MyKeyVault’ -Location’North Europe’

clip_image032

A noter que lors de la création, il faudra prouver son identité. A ce niveau, nous sommes le seul à y avoir accès via l’URL suivante : . Stockons notre mot de passe avec les commandes PowerShell suivantes :

$Password = « Ilachangé! »

$SecretValue = ConvertTo-SecureString $Password -AsPlaintext -Force

Set-AzureRMKeyVaultSecret -VaultName ‘MesPrecieux’ -Name « Password » -SecretValue $SecretValue

clip_image034

Nous pouvons vérifier que nous avons bien un secret dans notre coffre aux précieux :

Get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’

clip_image036

Jusque-là, ça casse pas trois pattes à un canard. Montons un peu le niveau. Si on a un coffre-fort pour nos secrets, la moindre des choses, ce serait de pouvoir retrouver l’historique de notre mot de passe, voyons le résultat de la commande Get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -IncludeVersions.

clip_image038

La ça devient intéressant. Non seulement, on a l’historique des valeurs mais on peut aussi filtrer pour utiliser le dernier disponible. Voyons comment retrouver la dernière version de notre mot de passe :

$liste = get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -IncludeVersions

$Password = $liste | Sort-object -property updated -Descending | select -first 1

$secret = get-AzureKeyVaultSecret -VaultName ‘Mesprecieux’ -Name ‘Password’ -Version $password.Version

$Secret | Get-member

$Secret.SecretValue

$Secret.SecretValueText

clip_image040

Nous avons retrouvé le dernier mot de passe associé. Entre temps, il a été changé (sécurité oblige). OK, c’est pas mal. Le problème, c’est de partager nos secrets. La, Azure Key Vault fait fort car grâce à Azure Resource Manager, on peut déléguer l’accès. La commande ci-dessous délègue l’accès à un utilisateur, uniquement pour lire le contenu de mon coffre.

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘MesPrecieux’ -UserPrincipalName ‘test@XXXXXXXXXX.onMicrosoft.com’ -PermissionsToSecrets ‘Get’

Get-AzureRmKeyVault -VaultName ‘mesprecieux’

clip_image042

Après, j’aurai pu pousser le vice de déléguer uniquement l’accès à mon mot de passe. On peut même autoriser des applications à accéder aux précieux.

Pour les amateurs, quelques lectures supplémentaires :

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Windows Azure Pack connector: two clouds, one portal

Alors que Microsoft Azure Stack (MAS) pointe le bout de son nez avec la TP1 sorti en ce début d’année 2016, on pourrait penser que les développements autour de Windows Azure Pack sont limités aux Update Rollup. Et bien non. Ce n’est pas l’équipe produit mais un développement de l’IT Microsoft autour de Windows Azure Pack qui est maintenant disponible sur GITHUB.

L’idée de ce développement est de permettre à des locataires de Windows Azure Pack de consommer des souscriptions Azure pour le service des machines virtuelles IaaS. Attention, même si c’est intégré aux portails, cela n’offre pas la cohérence de service que propose Microsoft Azure Stack. De plus, c’est une première version pour laquelle il n’est pas encore possible de l’installer sur une installation distribuée de Windows Azure Pack.

Si le test vous tente, la version actuelle est disponible ici. Effectivement, ça s’interface très bien avec le portail :

clip_image001

Même si l’approche est limitée, c’est une première version. Après, le code source est disponible, très intéressant pour comprendre Windows Azure Pack.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)