AVD + SSO + Accès conditionnel v2

Azure Virtual Desktop propose différentes options dans l’authentification Entra ID, comme le SSO, l’accès conditionnel, ou encore la combinaisons des 2 😎. Microsoft nous apporte justement une petite évolution sur ce mois de juin 2024. Annoncée via un email pour une partie d’entre-nous, je souhaitais refaire un point sur la configuration SSO et les différentes polices possibles dans l’accès conditionnel AVD.

Il y a quelques jours, certains ont peut-être reçu l’email suivant de la part de Microsoft Azure :

Upcoming change for conditional access policies that target the Microsoft Remote Desktop Entra ID cloud app for Azure Virtual Desktop single sign-on.

You’re receiving this notice because you have conditional access policies that explicitly include or exclude the Microsoft Remote Desktop Entra ID cloud app and use single sign-on.

This change timeline was initially targeted for April 2024. We’ve extended the timeline to 26 June 2024. Azure Virtual Desktop clients will transition to the Windows Cloud Login Entra ID cloud app for Windows authentication when single sign-on is enabled. Windows authentication will continue to work as expected when single sign-on isn’t enabled. Additionally, conditional access policies targeted towards the Azure Virtual Desktop Entra ID cloud applications will continue to be applied across resource retrieval, gateway authentication, and diagnostic processes.

Since you’re using single sign-on for Azure Virtual Desktop and have conditional access policies that specifically include or exclude the Microsoft Remote Desktop Entra ID cloud app you’ll need to update your policies to also include or exclude the Windows Cloud Login Entra ID cloud app.

  • Microsoft Remote Desktop Entra ID cloud app ID: a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID cloud app ID: 270efc09-cd0d-444b-a71f-39af4910ec45

If you have existing conditional access policies targeting the Microsoft Remote Desktop Entra ID cloud app, action is required to ensure policies continue to be applied as intended.

Required action

We recommend you update any conditional access policies that specifically target the Microsoft Remote Desktop Entra ID cloud app to add the Windows Cloud Login Entra ID cloud app to ensure a smooth transition by 26 June 2024.

  • Reach out to your Azure Global Administrator for Azure Virtual Desktop to develop a plan for deploying these updates to your infrastructure.
  • Update your internal documentation as needed and if you have a helpdesk, you may want to make them aware of this change.

To get started, review the documentation to secure user sign-in events with Microsoft Entra Multifactor authentication.

Help and support

If you need help developing a plan for deploying the updates, contact your Azure global administrator for Azure Virtual Desktop.

If you have general questions, ask community experts in Microsoft Q&A. If you have a support plan and you need technical help, open a support case in the Azure portal and select the question mark icon at the top of the page.

————————————————————-

Voici en quelques mots de ce que l’on peut en dire sur ce changement sur les polices d’accès conditionnel destinés à Azure Virtual Desktop :

Vous recevez cet avis parce que vous avez des politiques d’accès conditionnel qui incluent ou excluent explicitement l’application cloud Microsoft Remote Desktop Entra ID et/ou utilisent l’authentification unique.

La date limite de transition est prévue pour le 26 juin 2024 :

  • Changement : Les clients Azure Virtual Desktop utiliseront l’application Windows Cloud Login Entra ID pour l’authentification Windows avec SSO.
  • Impact : Vos politiques d’accès conditionnel actuelles doivent inclure l’application Windows Cloud Login Entra ID en plus de Microsoft Remote Desktop Entra ID.

Les actions requises :

  1. Mettre à jour vos politiques d’accès conditionnel pour inclure l’application Windows Cloud Login Entra ID.
  2. Contactez votre administrateur global Azure pour planifier ces mises à jour.
  3. Mettre à jour votre documentation interne et informer votre service d’assistance.

Le support :

En relisant en détail la documentation Microsoft relative à la configuration SSO pour AVD, j’avais jusqu’à présent configuré le SSO sur des environnements Azure Virtual Desktop de manière incomplète : à savoir uniquement au niveau du pool d’hôtes AVD :

Malgré cette configuration SSO partielle, mes utilisateurs n’avaient aucun souci pour s’y connecter, avec quelques clics supplémentaires.

Je vous propose donc au travers de cet article sur la configuration SSO et les accès conditionnel AVD possibles :

Commençons donc par un rappel de l’expérience utilisateur sans configuration SSO dans le cadre d’un environnement AVD joint directement à Microsoft Entra ID.

Tâche I – Premier test AVD sans SSO :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de l’utilisateur AVD :

Confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Renseignez à nouveau votre identifiant et mot de passe utilisateur :

Confirmez à nouveau votre choix en cliquant sur Continuer :

Autoriser la connexion à la machine virtuelle AVD en cliquant sur Oui :

Microsoft nous informe sur le pourquoi de cette boite de dialogue ci-dessus :

Après avoir activé l’authentification Microsoft Entra pour RDP, vous devez configurer les groupes d’appareils cibles. Par défaut, lors de l’activation de l’authentification unique, les utilisateurs sont invités à s’authentifier auprès de Microsoft Entra ID et à autoriser la connexion Bureau à distance lors du lancement d’une connexion à un nouvel hôte de session. Microsoft Entra mémorise jusqu’à 15 hôtes pendant 30 jours avant de vous présenter une nouvelle invite. Si une boîte de dialogue pour autoriser la connexion Bureau à distance s’affiche, sélectionnez Oui pour vous connecter.

Microsoft Learn

L’expérience réalisée nous montre que le SSO n’est pas opérationnel. Microsoft nous explique qu’il est possible de l’améliorer :

Vous pouvez masquer cette boîte de dialogue et fournir l’authentification unique pour les connexions à tous vos hôtes de session en configurant une liste d’appareils approuvés. Vous devez créer un ou plusieurs groupes dans Microsoft Entra ID qui contient vos hôtes de session, puis définir une propriété sur les principaux de service pour les mêmes applications Bureau à distance Microsoft et Connexion au cloud Windows, telles qu’elles sont utilisées dans la section précédente, pour le groupe.

Microsoft Learn

Voici un rappel des étapes de configuration du SSO pour un environnement AVD :

  1. Activation de l’authentification Microsoft Entra pour le protocole RDP
  2. Création du groupe de machines AVD
  3. Configuration AVD pour activer l’authentification unique

Commençons donc par correctement configurer le SSO au niveau de l’application Entra ID.

Tâche II – Activation de l’authentification Microsoft Entra pour le protocole RDP :

Depuis votre portail Azure, ouvrez le service Azure Cloud Shell :

Importez les 2 modules Graph suivants, puis connectez-vous à ce dernier :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Validez l’authentification de votre compte grâce à un Device Code :

Obtenez l’ID d’objet de chaque principal de service, puis stockez-les dans des variables en exécutant les commandes PowerShell suivantes :

  • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45
$MSRDspId = (Get-MgServicePrincipal -Filter "AppId eq 'a4a365df-50f1-4397-bc59-1a1564b8bb9c'").Id
$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Vérifiez la valeur actuelle de la propriété isRemoteDesktopProtocolEnabled :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Définissez la propriété isRemoteDesktopProtocolEnabled sur true en exécutant les commandes suivantes :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -IsRemoteDesktopProtocolEnabled
}

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}

Vérifiez le changement de valeur de la propriété isRemoteDesktopProtocolEnabled :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Pour information, la commande PowerShell suivante vous permet si besoin de revenir en arrière :

$params = @{
	"@odata.type" = "#microsoft.graph.remoteDesktopSecurityConfiguration"
	isRemoteDesktopProtocolEnabled = $false
}

Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -BodyParameter $params
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -BodyParameter $params

La suite de la configuration SSO se passe au niveau d’un groupe Entra ID.

Tâche III – Création d’un groupe de machines AVD :

Créez un groupe Entra ID dans lequel vous y ajoutez les différentes machines hôtes d’Azure Virtual Desktop :

Copiez les valeurs suivantes de votre groupe de machines virtuelles AVD :

  • Nom du groupe
  • Object ID

Intégrez ces 2 valeurs dans la commande PowerShell suivante :

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"

Ajoutez le groupe à l’objet targetDeviceGroup en exécutant les commandes PowerShell suivantes :

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $MSRDspId -BodyParameter $tdg
New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Pour information, la commande PowerShell suivante vous permet si besoin de revenir en arrière :

Remove-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $MSRDspId -TargetDeviceGroupId "<Group object ID>"
Remove-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -TargetDeviceGroupId "<Group object ID>"

La suite se passe au niveau du pool d’hôtes AVD.

Tâche IV – Configuration AVD pour activer l’authentification unique :

Finissons par l’activation de l’option SSO depuis les propriétés RDP de votre pool d’hôtes AVD :

Il ne reste qu’à refaire un test utilisateur depuis votre client Microsoft Remote Desktop :

Tâche V – Second test AVD avec SSO :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de cet utilisateur :

Confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Plus aucune authentification supplémentaire n’est nécessaire, la session de bureau à distance AVD s’ouvre directement :

La fonctionnalité SSO est maintenant en place sur notre environnement Azure Virtual Desktop. Continuons maintenant avec l’accès conditionnel AVD.

Tâche VI – Accès conditionnel actuel AVD (Portail) :

Pour rappel, j’utilise déjà cet accès conditionnel pour protéger l’accès à Azure Virtual Desktop. Voici ma configuration actuelle de la police d’accès conditionnel AVD :

Comme vous pouvez le voir, l’application ciblée est Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07)

Voici l’impact sur l’utilisateur AVD quand cette première police est activée :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de ce premier utilisateur AVD :

L’accès conditionnel AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

L’ouverture de la session AVD de ce premier utilisateur se fait automatiquement :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Continuons avec un second test d’accès conditionnel ciblant cette fois les 2 applications indiquées dans l’email de Microsoft :

  • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
  • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45

Tâche VII – Accès conditionnel actuel AVD (VM) :

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de ce second utilisateur AVD :

Aucune MFA renforcée n’est exigée, mais confirmez votre choix en cliquant sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

Renseignez à nouveau les identifiants Cloud de l’utilisateur AVD :

L’accès conditionnel à la VM d’AVD fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’ouverture de la session AVD de ce second utilisateur se fait dans la foulée du challenge MFA :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Terminons les tests par une combinaison de 2 polices d’accès conditionnels ciblant les 3 applications AVD.

Tâche VIII – Accès conditionnel AVD doublé (Portail + VM) :

J’ai paramétré un troisième utilisateur pour avoir une MFA renforcée sur les 3 applications AVD, via 2 polices distinctes d’accès conditionnel :

Police Portail

  • Police Portail :
    • Azure Virtual Desktop : 9cdead84-a844-4324-93f2-b2e6bb768d07
  • Police VM :
    • Microsoft Remote Desktop Entra ID : a4a365df-50f1-4397-bc59-1a1564b8bb9c
    • Windows Cloud Login Entra ID : 270efc09-cd0d-444b-a71f-39af4910ec45

Depuis l’application Microsoft Remote Desktop, ajoutez l’environnement AVD d’un utilisateur via la fonction suivante :

Renseignez les identifiants Cloud de cet utilisateur :

L’accès conditionnel Portail fonctionne bien et demande ici une méthode de MFA renforcée, comme la clef FIDO2 :

Saisissez votre code PIN :

Touchez physiquement la clef FIDO2 :

Cliquez sur Continuer :

L’icône AVD apparaît alors, cliquez sur ce dernier pour ouvrir une session de bureau à distance :

L’ouverture de la session AVD de ce troisième utilisateur se fait automatiquement sans repasser par un challenge MFA de la police VM :

Le journal de log entra ID nous permet de comprendre le déroulé et l’impact des tokens entre les 2 applications AVD :

Conclusion

Ce mail d’information Microsoft m’a donc permis de correctement configurer le SSO AVD. Il nous explique également la mise à jour nécessaires des polices d’accès conditionnel pour garantir la continuité du service et la sécurité des connexions avec Azure Virtual Desktop.

En intégrant l’application Windows Cloud Login Entra ID avant le 26 juin 2024, vous assurerez une transition fluide et éviterez toute interruption de service 🤘

Sécurisez votre AVD grâce au Watermarking

Il s’agit d’un article que je voulais sortir il y a quelques temps déjà. Fin janvier, Microsoft a rajouté une fonctionnalité de Watermarking, encore en préversion, à son service Azure Virtual Desktop. En quelques mots, le Tatouage numérique date des années 90 : il permet de tracer la source de l’information ayant fuitée.

Ce procédé a d’ailleurs beaucoup été utilisé dans le monde du cinéma pour essayer d’endiguer le phénomène du piratage, sans grand succès.

Dans le cadre d’Azure Virtual Desktop, un filigrane est apposé sur le bureau de session utilisateur AVD. Ce filigrane comporte un QR code comportant des informations utiles aux équipes IT pour retrouver la session et donc l’utilisateur à l’origine d’une fuite de données sensibles.

Avec cette fonctionnalité, quelles sont les contraintes pour les utilisateurs ?

Quand cette fonctionnalité est mise en place sur votre environnement Azure Virtual Desktop, la connexion pourra être refusée car la connexion au bureau à distance nécessite un client supportant le watermarking (supérieure à 1.2.3317).

En revanche :

  • La connexion aux applications publiées ne passera pas par le watermarking.
  • Les connections directes aux machines virtuelles via l’application MSTSC ne sont pas impactées par le watermarking.

Comment installe-t-on cette fonctionnalité ?

Il est encore nécessaire de passer par une police locale ou via une police de groupe Active Directory. Voici d’ailleurs un lien vers le fichier de modèle administratif pour Azure Virtual Desktop.

Est-il possible de le faire via Intune ?

Ayant récemment sorti un article sur les GPOs via Intune, je me suis dit qu’il serait intéressant d’en faire de même pour mettre en place le Watermarking sur un environnement AVD.

J’ai donc testé cette idée avec le fichier ADMX correspondant :

J’ai sélectionné les fichiers ADMX et ADML de l’archive précédemment téléchargée sur mon poste :

Tout semblait bon, alors j’ai donc cliqué sur Créer :

Impossible de charger le fichier : une erreur de liée à une dépendance est apparue 🤷‍♂️

J’ai donc fait de même avec TerminalServer.admx, mais une autre dépendance est venue gâcher la fête :

La dépendance Windows.admx est bien passée sur Intune, mais la réinstallation de TerminalServer.admx bloqua toujours :

The given key was not present in the dictionary

A ce jour, je n’ai pas encore trouvé de méthode pour contourner cette erreur. Donc non, ce n’est pas encore possible de passer par Intune pour les GPOs AVD.

Afin d’en savoir un peu plus sur la mise en place du Watermarking, je vous propose une autre manière de tester cette nouvelle fonctionnalité d’AVD.

Mon environnement de test est donc basé sur un domaine managé (Azure Active Directory Domain Services).

Rappel des prérequis :

Pour réaliser cet exercice sur Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure active

Afin de tester la fonctionnalité voulue, j’ai déjà déployé un certain nombre de ressources dans mon environnement Azure.

Voici d’abord les ressources liées au service Azure Active Directory Domain Services :

J’ai également créé une machine virtuelle de jump, pour créer et configurer mes GPOs dans mon Azure AD DS :

J’ai ensuite créé un service Azure Virtual Desktop, composé de 3 machines virtuelles individuelles. Ces 3 VMs sont liées à mon domaine Active Directory managé :

J’ai aussi créé le service Azure Bastion afin de me connecter plus facilement aux machines virtuelles sans passer par une IP publique :

Etape I – Mise en place d’un Log Analytics workspace :

La configuration du QR code sur les sessions utilisateurs d’AVD ne nécessite pas directement de Log Analytics workspace. Seulement, la conversion de celui-ci en UPN utilisateur nécessite justement de stocker cette information quelque part.

Pour cela, recherchez dans votre portail le service Log Analytics workspace :

Créez votre Log Analytics workspace dédié à votre environnement AVD :

Remplissez les champs pour sa création, puis lancez sa validation :

Attendez quelques minutes que la ressource se créée :

Retournez sur votre environnement Azure Virtual Desktop pour commencer la configuration vers le Log Analytics workspace, La configuration doit bien se faire sur les 3 éléments que compose tout environnement AVD :

  • Pool d’hôtes
  • Espace de travail
  • Machines virtuelles

Cliquez comme-ceci pour configurer les 3 éléments à la suite :

En commençant par le Pool d’hôtes, choisissez le Log Analytics workspace créé précédemment, puis cliquez sur Configurer :

Cliquez sur Déployer pour installer la configuration du LAW au Pool d’hôtes :

Continuez la configuration du LAW avec l’Espace de travail :

Cliquez sur Déployer pour installer la configuration du LAW à l’Espace de travail :

Continuez la configuration du LAW avec les machines virtuelles AVD en les ajoutant :

Cliquez sur Déployer pour installer la configuration du LAW des machines virtuelles :

Ajoutez les métriques de Performances Windows :

Cliquez sur Déployer pour installer la configuration du LAW des métriques de Performances Windows :

Ajoutez les Evènements journalisés de Windows :

Cliquez sur Déployer pour installer la configuration du LAW des Evènements journalisés de Windows :

Quelques minutes plus tard, l’onglet Insights commence à s’alimenter en données de votre environnement AVD :

Etape II – Configuration de la Jump VM :

Afin de mettre en place une GPO pour notre environnement AVD, il est nécessaire de passer par l’Éditeur de stratégie de groupe dans notre domaine.

Pour cela, ajoutez les fonctionnalités liées aux GPOs, mais aussi les outils RSAT pour l’Active Directory :

Une fois l’installation des fonctionnalités terminée, lancez le gestionnaire AD de vos utilisateurs et machines :

Créez si besoin une OU contenant vos machines virtuelles AVD :

Toujours sur la même machine de Jump, pensez à désactiver le contrôle renforcé d’internet :

Rendez-vous ensuite sur le lien suivant, puis téléchargez le dernier fichier de modèles administratifs Azure Virtual Desktop :

Extrayez le contenu du fichier .cab et de l’archive .zip selon votre cas :

  • Si vous utilisez le magasin central pour la stratégie de groupe :
    • Copiez terminalserver-avd.admx dans le magasin central de stratégies de groupe de votre domaine, par exemple \contoso.com\SYSVOL\contoso.com\Policies\PolicyDefinitions,
    • Copiez ensuite le fichier terminalserver-avd.adml dans le sous-dossier en-us.
  • Si non :
    • Copiez et collez le fichier terminalserver-avd.admx dans le dossier PolicyDefinitions à %windir%\PolicyDefinitions.
    • Copiez ensuite le fichier terminalserver-avd.adml dans le sous-dossier en-us.

Dans mon cas, voici ce que cela donne :

Ouvrez le Gestionnaire de la stratégie de groupe :

Sur votre OU contenant vos machines virtuelles AVD, créez une nouvelle GPO :

Nommez votre GPO, puis cliquez sur OK :

Editez votre GPO pour configurer le Watermarking AVD :

Rendez-vous dans le menu suivant :

  • Computer Configuration
    • Administrative Templates
      • Windows Components
        • Remote Desktop Services
          • Remote Desktop Session Host
            • Azure Virtual Desktop

Cliquez sur la configuration de Watermarking :

Activez-là :

D’autres options sont également configurables si besoin :

Etape III – Testez la solution de Watermarking :

De retour sur votre portail Azure, redémarrer les machines virtuelles AVD pour prendre en compte la nouvelle GPO qui leur a été attribuée :

Suivez le redémarrage de celles-ci depuis la console AVD :

Un nouveau statut Eteint a d’ailleurs fait son apparition.

Quelques minutes plus tard, vérifiez que toutes vos machines AVD sont bien redémarrées et accessibles :

Ouvrez le client Windows Remote Desktop, dont la version est en 1.2.3317 ou ultérieure :

Entrez les identifiants d’un utilisateur AVD de test :

Constatez la présence immédiate du QR code au chargement du bureau à distance AVD :

La présence des QR codes continue également durant toute la durée de vie de la session AVD :

Etape IV – Identifiez la session AVD :

Une fois l’image contenant un QR Code en votre possession, il ne vous reste qu’à la scanner pour en obtenir l’identifiant de connexion AVD :

Pour votre test, utilisez votre smartphone ou un site gratuit comme celui-ci :

Copiez la valeur obtenue dans votre presse-papier :

Sur votre portail Azure, recherchez le service Azure Monitor :

Allez dans le menu Logs, puis lancez la requête suivante :

WVDConnections
| where CorrelationId contains "<connection ID>"

Constatez le résultat par vous-même :

Conclusion :

Cette fonctionnalité de Watermarking pourra prévenir la capture d’informations sensibles sur les sessions AVD. Sa mise en place facile et rapide permet de récupérer l’ID de connexion d’une session à distance, utile pour les administrateurs afin de tracer la session.

Azure Virtual Desktop ❤️ FIDO2

Rassurez-vous, Azure Virtual Desktop propose depuis longtemps une intégration avec l’accès conditionnel disponible sur Azure AD. Ce billet, datant déjà de 2019, écrit par Freek Berson, nous montre bien l’intégration entre AVD et FIDO2.

Je souhaitais malgré tout vous écrire un article en français pour détailler le processus de mise en place FIDO2 et les possibilités intéressantes avec AVD.

Qu’est-ce que FIDO2 (Fast IDentity Online 2) ?

La réponse de l’industrie au problème des mots de passe.

FIDO Alliance

Exit donc l’utilisation d’un simple du mot de passe pour valider un processus d’authentification. FIDO2 a été développé par la FIDO Alliance et est à ce jour leur dernière norme.

FIDO2 est bâti sur des spécifications Web Authentication, ou WebAuthn, du World Wide Web Consortium (W3C), donc universel mais disposant de capacités supplémentaires.

Cette vidéo en français explique plusieurs de ces avantages :

  • USB-A ou C ou encore NFC
  • Absence de donnée personnelle sur la clef
  • Code PIN de protection
  • Zone de contact pour valider une présence physique
  • Utilisation pour plusieurs comptes
Bon conseil : toujours avoir deux clefs ????.

Puis-je utiliser une clef FIDO2 pour m’authentifier sur Azure AD ?

Oui, Azure AD supporte un grand nombre de méthodes renforcées pour sécuriser l’authentification des utilisateurs. Vous pouvez retrouver cette liste ici, ou dans le portail Azure, via la page des Méthodes d’authentification :

D’une manière générale, Microsoft déconseille l’utilisation unique de mot de passe pour authentifier un compte (Voir tableau ci-dessous). Azure AD propose à ce jour différentes méthodes dans le cadre d’un processus d’authentification multifacteur :

  • Windows Hello Entreprise
  • Microsoft Authenticator
  • Clés de sécurité FIDO2

Ai-je besoin d’une licence particulière pour utiliser FIDO2 ?

FIDO2 n’exige pas de licence particulière, mais l’accès conditionnel en demandera une. En effet, pour intégrer FIDO2 dans une ou plusieurs polices d’accès conditionnel, il vous faudra une licence Azure Premium P1 ou P2 pour tous les utilisateurs concernés.

FonctionnalitéAzure AD Free – Paramètres de sécurité par défaut Azure AD Free – Administrateurs généraux uniquementOffice 
365
Azure AD Premium P1Azure AD Premium P2
Accès conditionnel
Accès conditionnel basé sur les risques

Il ne faut pas confondre l’accès conditionnel qui vient en remplacement, car plus abouti et personnalisable que la MFA de base ou les paramètres de sécurité par défaut :

StratégieParamètres de sécurité par défautAccès conditionnelAuthentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise
Activé/désactivé en un clic
Inclus dans la gestion des licences Office 365
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365
Flexibilité de la configuration
Fonctionnalité
Exempter les utilisateurs de la stratégie
Authentification par appel téléphonique ou SMS
S’authentifier par Microsoft Authenticator et jetons logiciels
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels
Bloque les protocoles d’authentification hérités
Les nouveaux employés sont automatiquement protégés
Déclencheurs MFA dynamiques en fonction des événements à risque
Stratégies d’authentification et d’autorisation
Configurable en fonction de l’emplacement et de l’état de l’appareil
Prise en charge du mode « Rapport seul »

Où peut-on se procurer des clefs FIDO2 ?

Microsoft met à disposition cette liste de fournisseur proposant justement des clefs FIDO2 :

FournisseurBiométrieUSBNFCBLECertifié FIPSContact
AuthenTrendyyyynhttps://authentrend.com/about-us/#pg-35-3
Cirightnnynnhttps://www.cyberonecard.com/
Ensurityyynnnhttps://www.ensurity.com/contact
Excelsecuyyyynhttps://www.excelsecu.com/productdetail/esecufido2secu.html
Feitianyyyyyhttps://shop.ftsafe.us/pages/microsoft
Fortinetnynnnhttps://www.fortinet.com/
Giesecke + Devrient (G+D)yyyynhttps://www.gi-de.com/en/identities/enterprise-security/hardware-based-authentication
GoTrustID Inc.nyyynhttps://www.gotrustid.com/idem-key
HIDnyynnhttps://www.hidglobal.com/contact-us
Hypersecunynnnhttps://www.hypersecu.com/hyperfido
IDmelon Technologies Inc.yyyynhttps://www.idmelon.com/#idmelon
Kensingtonyynnnhttps://www.kensington.com/solutions/product-category/why-biometrics/
KONA Iynyynhttps://konai.com/business/security/fido
NeoWavenyynnhttps://neowave.fr/en/products/fido-range/
Nymiynynnhttps://www.nymi.com/nymi-band
Octatcoyynnnhttps://octatco.com/
OneSpan Inc.nynynhttps://www.onespan.com/products/fido
Swissbitnyynnhttps://www.swissbit.com/en/products/ishield-fido2/
Thales Groupnyynyhttps://cpl.thalesgroup.com/access-management/authenticators/fido-devices
Thetisyyyynhttps://thetis.io/collections/fido2
Token2 Switzerlandyyynnhttps://www.token2.swiss/shop/product/token2-t2f2-alu-fido2-u2f-and-totp-security-key
Solutions TrustKeyyynnnhttps://www.trustkeysolutions.com/security-keys/
VinCSSnynnnhttps://passwordless.vincss.net
Yubicoyyynyhttps://www.yubico.com/solutions/passwordless/

Pour effectuer mes tests sur mon environnement Azure, j’ai décidé d’acheter deux clefs USB-A sous forme de pack auprès de Token2 Switzerland, au prix de 23€, frais de port compris :

Comment procède-t-on pour intégrer FIDO2 à Azure Virtual Desktop ?

Le processus d’installation est très simple, il vous faudra néanmoins quelques prérequis pour arriver à une intégration complète. Dans ce tutoriel, nous allons mettre en place une clef FIDO2 pour un utilisateur et créer deux polices d’accès conditionnel dédiées à AVD :

Etape 0 – Rappel des prérequis :

Les prérequis suivants sont nécessaires pour réaliser cette démonstration avec AVD :

  • Un poste sous Windows 10 (1903) ou supérieur
  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un environnement AVD déployé (je vous conseille de suivre ce tutoriel)
  • Une licence Azure AD Premium Plan 1 ou Plan 2

Si votre tenant ne dispose d’aucune licence Azure AD Premium, vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :

Une fois la version d’essai activée, pensez à affecter une licence Azure AD Premium Plan 2 à un utilisateur votre tenant.

Etape I – Configuration du code PIN :

Azure AD exige que les clés de sécurité soient protégées par un code PIN. Insérer votre clef FIDO2 dans un port USB et allez dans les paramètres de votre poste pour le définir :

Cliquez ici pour configurer la clef :

Touchez la zone prévue à cet effet pour continuer :

Définissez un code PIN et confirmez-le :

Etape II – Activation de FIDO2 sur Azure AD :

Sur le portail d’Azure AD, consulter les paramètres de Sécurité via le menu suivant :

Cliquez sur Méthodes d’authentification :

Cliquez sur la ligne FIDO2 :

Activez la fonctionnalité FIDO2, puis cliquez sur Configurer :

Sauvegardez-là avec les options de base :

Quelques minutes sont parfois nécessaire pour continuer sur la configuration FIDO2 au niveau de l’utilisateur. Ne vous inquiétez pas si les écrans suivants ne sont pas encore identiques au tutoriel.

Etape III – Enrôlement d’une clef FIDO2 sur un compte Azure AD :

Comme dit précédemment, la clef FIDO2 n’embarque aucune information personnelle sur les comptes associés à celle-ci. Vous pouvez donc sans souci utiliser la même clef pour plusieurs comptes Azure AD.

Dans mon cas, j’ai créé un nouvel utilisateur pour retester un enrôlement complet.

Rendez-vous sur la page myaccount de Microsoft avec votre utilisateur de test, puis cliquez les Informations de sécurité :

Cliquez ici pour ajouter la première clef FIDO2 :

Dans mon cas, Azure m’avertit que mon utilisateur de test ne dispose d’aucune autre méthode MFA, j’en profite donc pour mettre en place le SMS comme seconde méthode :

Une fois terminé, recommencez le processus pour arriver sur cet écran :

Azure AD entame une communication avec la clef FIDO2 :

Plusieurs messages d’information de Windows 10 vont se succéder :

Renseignez le PIN de votre clef FIDO2, puis continuez :

Touchez la zone prévue à cet effet pour terminer :

Il ne vous reste plus qu’à donner un nom à cette première clef FIDO2 :

Comme il est fortement conseillé, recommencer la même opération avec une seconde clef FIDO2, utilisable en cas de secours :

Etape IV – Test de FIDO2 :

Avant d’aller plus loin dans l’intégration avec Azure Virtual Desktop, je vous conseille de tester l’authentification utilisateur avec sa clef FIDO2. Pour cela ouvrez le navigateur de votre choix en mode privé et allez sur la page web office.com.

Cliquez-ici pour vous authentifier :

Au lieu de saisir le mot de passe du compte de test, cliquez comme ceci :

Renseignez le code PIN de votre clef FIDO2 :

Touchez la zone prévue à cet effet pour confirmer l’authentification :

Cliquez enfin sur Non :

Et vous voilà correctement authentifié sur le portail Office365 ????

Etape V – Création d’une méthode d’authentification renforcée :

En faisant différents tests, je me suis rendu compte que l’on pouvait intégrer le mécanisme FIDO2 à plusieurs niveaux d’AVD.

Pour rappel, je suis partie d’un environnement Azure Virtual Desktop existant et équivalent à ce qui est détaillé dans cet article : Simplifiez l’authentification des utilisateurs d’AVD joint Azure AD avec Single Sign-on – Jean-Loup & Azure (jlou.eu).

Encore en préversion à ce jour, connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :

Ouvrez le menu Sécurité :

Cliquez sur Méthodes d’authentification :

Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle :

Terminez la création de celle-ci :

Etape VI – Test de l’accès conditionnel au premier niveau :

Toujours dans votre portail Azure AD, retournez dans la section Sécurité puis cliquez sur Accès conditionnel :

Créez votre nouvelle Police :

Saisissez un nom à votre police et sélectionnez votre utilisateur de test :

Ajoutez l’application Azure Virtual Desktop :

Terminez la configuration en autorisant l’accès sous réserve de satisfaire votre nouvelle méthode d’authentification renforcée :

Attendez quelques minutes et ouvrez votre client Windows d’Azure Virtual Desktop pour tester votre première police d’accès conditionnel :

Renseignez le compte Azure de votre utilisateur de test et constatez la présence de ce message :

Touchez la zone prévue à cet effet pour terminer l’authentification :

Félicitations ! Votre accès AVD est bien protégé par la clef FIDO2 ????.

Etape VII – Test de l’accès conditionnel au second niveau :

En parcourant les fonctionnalités de l’accès conditionnel d’Azure AD, j’ai remarqué une seconde application du Cloud Azure très intéressante :

J’ai donc créé une seconde règle d’accès conditionnel, avec les mêmes autres paramètres pour intégrer un mécanisme FIDO2 au moment de l’ouverture de session Windows d’AVD :

Sur votre application Azure Virtual Desktop, cliquez sur l’icône pour ouvrir une session AVD :

Attendez que le processus continue :

Choisissez le compte autorisé à AVD et disposant d’une clef FIDO2 :

Renseignez le code PIN de votre clef FIDO2 :

Touchez la zone prévue à cet effet pour confirmer l’authentification :

Attendez que la session AVD s’ouvre :

Conclusion

Cette combinaison AVD + AD + FIDO2 fut très intéressante à tester, et assez simple à mettre en place. Cette flexibilité nous montre aussi l’infinité de scénarios possibles pour augmenter la sécurité des utilisateurs sans pour autant rendre le quotidien lourd ou invivable.

Enfin, profitez-en pour sécuriser un peu plus vos comptes à vous ????

Configurer l’autorisation multi-utilisateur pour Azure Backup

J’avais déjà écrit un article sur comment sauvegarder de machine virtuelle via Runbook/Snapshot. Cette option est intéressante dans le cas où la sauvegarde native d’Azure ne supporte pas l’OS de la machine virtuelle. Microsoft continue d’apporter des mesures de sécurité sur son service sauvegarde Azure Backup.

Dans cet article, nous allons parler et tester l’autorisation multi-utilisateur (MUA), annoncée il y a seulement quelques jours en disponibilité générale. Dans quel but ? Accroître la protection des sauvegardes de vos ressources Azure.

Mais avant cela, nous allons faire un rappel de quelques mesures de protection de sauvegardes de machines virtuelles disponibles sur Azure.

Par défaut, quelles mesures de protection existent sur mes sauvegardes de VMs ?

Quand vous sauvegardez des machines virtuelles au travers de la sauvegarde native d’Azure, vous utilisez et déployez un coffre de sauvegarde. Ce dernier est directement géré par le service Azure Backup :

Ce schéma nous montre la création de snapshots et le transfert différé vers le coffre de sauvegarde.

La création de snapshots et la rétention de vos sauvegardes sont alors configurées selon une police de sauvegarde, créée dans ce coffre de sauvegarde :

Il est possible de créer plusieurs polices de sauvegardes.
Azure propose maintenant plusieurs sauvegardes par jour.

D’autre part, le nombre et la répartition des copies de vos sauvegardes vont dépendre des propriétés de ce coffre :

La création d’un Recovery Service Vault est paramétré en Geo-redondant par défaut.
Cette option reste modifiable tant qu’aucune sauvegarde n’est paramétrée.

Pour rappel, voici quelques notions de réplication à connaitre, tant elles sont très utilisées sur un grand nombre de ressources Azure :

  • Redondance locale (LRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure.
  • Redondance zonale (ZRS) : La donnée est présente en triple exemplaires, chacun réparti dans les 3 datacenters (Zones) de la même région Azure, si celle-ci le propose.
  • Géo-redondance (GRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure, et 3 autres exemplaires dans la région paire Azure de la première.

Note : il existe également d’autres scénarios de réplication Azure : RA-GRS, GZRS, … ????

Enfin, la suppression d’une sauvegarde stockée dans un coffre conserve encore celle-ci pendant 14 jours. Cette fonctionnalité est activée par défaut et est appelée Soft-delete :

Pour information, la donnée maintenue dans cet état de soft-delete ne coûte rien.

Un coffre de sauvegarde contenant encore des sauvegardes en état de soft-delete ne peut être supprimé.

Envi d’en savoir plus sur la sauvegarde de machine virtuelle ?

Voici l’excellente vidéo de Travis Roberts expliquant le service Azure Backup et les étapes de sa mise en place sur différentes ressources Azure :

Pourquoi mettre en place l’autorisation multi-utilisateur sur les sauvegardes Azure ?

L’autorisation multi-utilisateur (MUA) pour la sauvegarde Azure vous permet d’ajouter une couche supplémentaire de protection aux opérations critiques sur vos coffres Recovery Services. Pour MUA, Sauvegarde Azure utilise une autre ressource Azure appelée protection des ressources pour garantir que les opérations critiques sont effectuées uniquement avec l’autorisation applicable.

Microsoft Doc

En y réfléchissant, un scénario apparait effectivement comme non protégé : comment sécuriser les sauvegardes contre un compte administrateur compromis ou contre une suppression accidentelle ?

En effet, un compte utilisateur Azure AD, configuré comme propriétaire ou contributeur de ressources Azure, dispose des droits pour la mise en en place de sauvegardes, mais également de ceux pour les démettre ! Les mesures listées précédemment renforcent la sécurité mais sont toutes réversibles par cet utilisateur.

Est-ce ici qu’entre en scène Azure Resource Guard ?

L’idée générale d’Azure Resource Guard est de faire reposer la répartition des tâches (donc des droits Azure) sur différents utilisateurs. Il s’agit d’un dispositif (SOD) mis en place dans tout processus de contrôle interne : acteur et contrôleur.

Comme le montre le schéma ci-dessous, deux roles sont alors nécessaires pour sécuriser les actions liées aux sauvegardes avec MUA :

  • Administrateur sauvegarde : Propriétaire ou contributeur du coffre de sauvegarde. Ce dernier met en place et gère les sauvegardes de ressources Azure. L’administrateur sauvegarde ne doit pas avoir de droits élevés et permanent sur l’Azure Resource Guard.
  • Administrateur sécurité : Propriétaire du Azure Resource Guard et gardien des opérations critiques sur le coffre de sauvegarde. Par conséquent, l’administrateur sécurité contrôle les permissions dont l’Administrateur sauvegarde a besoin pour effectuer les opérations critiques.

Quelles sont les actions restreintes grâce à Azure Resource Guard ?

L’installation du contrôle d’Azure Resource Guard sur un coffre de sauvegarde bloquera certaines actions si les droits de l’Administrateur sauvegarde sont insuffisants :

Les opérations marquées comme obligatoires ne peuvent pas être exclues de la protection par Azure Resource Guard. Enfin, cette configuration s’appliquera à tous les coffres de sauvegarde associés à celui-ci.

Où doit se trouver Azure Resource Guard ?

Le service Azure Resource Guard doit obligatoirement être sur la même région Azure que le coffre de sauvegarde qu’il protège. De plus, l’Administrateur sauvegarde ne doit pas avoir de droits de contributeur permanent sur Azure Resource Guard. Dans le cas contraire, il n’est jamais bloqué pour aucune action critique sur le coffre de sauvegarde.

Il est alors possible d’envisager différents scénarios :

  • Le coffre de sauvegarde et Azure Resource Guard sont dans la même souscription. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard.
  • Le coffre de sauvegarde et Azure Resource Guard sont dans des souscriptions différentes du même tenant. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard ou à sa souscription.
  • Le coffre de sauvegarde et Azure Resource Guard sont dans des tenants différents. Mais l’Administrateur de sauvegarde n’a pas accès à Azure Resource Guard, à la souscription ou tenant correspondant.

Etape 0 : Rappel des prérequis

Comme pour beaucoup d’articles sur ce blog, nous allons créer différentes ressources sur Azure pour y parvenir. Comme à chaque fois, des prérequis sont nécessaires pour réaliser cette démonstration :

  • Un tenant Microsoft. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde hébergés sur différents tenants.
  • Une ou plusieurs souscriptions Azure. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde sur différentes souscriptions Azure.
  • Une machine virtuelle déjà déployée sur un tenant accessible à l’Administrateur de sauvegarde .

Dans mon cas, j’ai utilisé deux tenants différents, différenciés dans cet article par la couleur du portail Azure pour plus de simplicité :

  • Le tenant A, noir pour l’Administrateur de sauvegarde, contient la machine virtuelle à sauvegarder et le coffre de sauvegarde.
  • Le tenant B, blanc pour l’Administrateur sécurité, contient Azure Ressource Guard.

Nous avons donc les deux environnements Azure suivants :

Tenant A.

Etape I : Création d’Azure Resource Guard

Sur le tenant B, commencez la création du service Azure Resource Guard :

Renseignez les différents champs, puis cliquez sur Suivant :

Si l’erreur suivante apparaît, retournez sur la page de la souscription Azure concernée :

Cliquez comme ceci pour constater le statut du resource provider Microsoft.DataProtection :

Cliquez alors sur celui-ci puis sur Enregistrer :

Attendez quelques minutes que le traitement se termine :

Contrôler le nouveau statut du resource provider :

Retournez dans la création de votre Azure Resource Guard pour constater la disparition du message d’erreur sur le second onglet.

Sélectionnez les opérations dont vous avez besoin de protéger et cliquez comme ceci pour les valider :

Vous pourrez toujours modifier cette liste après la création dans les propriétés d’Azure Resource Guard.

Lancez la création de votre Azure Resource Guard :

Etape I : Assignation du rôle de lecteur pour l’administrateur de sauvegarde

Afin de pouvoir interroger le service Azure Resource Guard, l’Administrateur sauvegarde doit disposer d’un rôle de lecteur sur ce dernier.

Sur le tenant B, retournez sur l’Azure Resource Guard et cliquez comme-ci pour rajouter le rôle de lecteur à l’administrateur sauvegarde :

Choisissez le rôle de lecteur puis cliquez sur Suivant :

Ajoutez votre Administrateur sauvegarde :

Cliquez pour valider :

Etape II : Création du coffre de sauvegarde

De retour sur le tenant A, recherchez le service Recovery Service Vault pour le créer :

Renseignez les champs et lancez la création du coffre de sauvegarde :

Etape III : Protégez votre coffre de sauvegarder

Retournez sur le tenant B, puis copiez la valeur suivante de votre Azure Resource Guard :

Sur le tenant A, retournez sur votre coffre de sauvegarde et cliquez ici pour mettre en place la MUA :

Effectuez les opérations suivantes et collez votre Resource Guard ID dans le champ suivant :

Contrôlez la cohérence des informations de votre Azure Resource Guard :

Sauvegardez la configuration MUA de votre coffre de sauvegarde :

Votre coffre de sauvegarde est maintenant protégé, continuez sur l’étape suivante pour vérifier le blocage des opérations pour l’Administrateur sauvegarde.

Etape IV : Contrôlez le blocage pour l’administrateur sauvegarde

Restez dans les propriétés de votre coffre de sauvegarde et cliquez sur les options de sécurité :

Vous êtes immédiatement averti de la couche de protection supplémentaire grâce au service Azure Resource Guard :

Essayez de désactiver la fonctionnalité Soft Delete et sauvegardez la nouvelle configuration :

L’action de sauvegarde échoue bien et affiche la notification d’erreur suivante :

La même opération, avec un autre compte, disposant lui de droits de contributeur sur Azure Resource Guard, dans mon exemple grâce à Azure Lighthouse, ne pose aucun souci :

Etape IV : Sauvegardez votre la machine virtuelle avec MUA

La mise en place de MUA ne bloque pas l’Administrateur sauvegarde de mettre en place de nouvelles protections pour des ressources Azure.

Pour cela, retournez sur la page principale de votre coffre de sauvegarde et cliquez comme-ceci :

Continuez la configuration avec la famille de ressources Machine virtuelle :

Ajoutez votre machine virtuelle à sauvegarder :

Cochez la case correspondante pour prendre la machine virtuelle désirée et cliquez sur OK

Activez la mise en place de la sauvegarde :

Une fois le traitement terminé, retournez sur le coffre de sauvegarde comme-ci :

Cliquez ici pour afficher les détails :

Lancez une sauvegarde immédiate :

La mise en place de la sauvegarde et la première sauvegarde n’ont pas provoqué d’erreur MUA pour l’Administrateur sauvegarde.

Contrôler l’avancement des travaux de la première sauvegarde et affichez les détails pour vérifier quand celui-ci est entièrement terminé :

Après quelques minutes et plusieurs rafraichissements, la sauvegarde est complète et correctement envoyée dans le coffre de sauvegarde.

Que peut-on encore mettre en place ?

Dans certains cas, vous devrez peut-être effectuer des opérations critiques sur vos sauvegardes et MUA peut vous aider à vous assurer qu’elles sont exécutées uniquement lorsque les approbations ou les autorisations appropriées existent. Comme nous l’avons vu précédemment, l’administrateur de sauvegarde doit avoir un rôle Collaborateur sur le service de protection des ressources pour effectuer des opérations critiques qui se trouvent dans l’étendue de la protection des ressources. L’une des façons d’autoriser l’exécution juste-à-temps pour ces opérations consiste à utiliser Azure Active Directory (Azure AD) Privileged Identity Management.

Microsoft Doc

Les étapes suivantes de cet article sont facultatives, mais peuvent simplifier le processus d’élévations des droits grâce à la combinaison de plusieurs services Azure :

  • Azure Gestion des identités privilégiées (PIM)
  • Azure Resource Guard

La Gestion des identités privilégiées Azure AD, présente dans la licence Azure AD Premium P2, apporte de la souplesse dans les autorisations de droits temporaires sur des ressources Azure.

Dans le cadre de PIM et d’Azure Resource Guard, nous aurions la cinématique suivante :

  • Etape 0 : Demande d’élévation des droits par l’Administrateur sauvegarde
  • Etape I : Validation de la demande par Administrateur sécurité pour une durée donnée
  • Etape 2 : Intervention sur les sauvegardes par l’Administrateur sauvegarde
  • Etape 3 : Fin de l’élévation des privilèges d‘Administrateur sauvegarde
Le schéma ci-dessus est un exemple de scénario possible grâce à PIM.

Etape V : Intégration de PIM sur Azure Resource Guard

Sur le tenant B, recherchez le service Azure suivant :

Cliquez sur Ressources Azure puis sur la souscription ou le groupe de ressources contenant Azure Resource Guard :

Si aucune souscription n’apparait, cliquer « Découvrir les ressources » et laissez-vous guider.

Ajoutez un nouvel assignement :

Choisissez le rôle Contributeur et reprenez l’utilisateur Administrateur sauvegarde et cliquez sur Suivant :

Conservez bien la notion d’éligibilité et cliquez sur Assigner :

Etape VI : Mise en place du processus de validation

Notre utilisateur Administrateur sauvegarde est maintenant éligible pour devenir Contributeur sur Azure Resource Guard. Seulement, il est nécessaire de mettre en place un processus de validation pour l’élévation de ses droits. Sans cela et par défaut, toutes ses demandes seront automatiquement approuvées.

Sur le tenant B et au même niveau que précédemment, cliquez comme ceci dans Azure AD PIM pour modifier les paramétrages de validation :

Cliquez sur le rôle Contributeur :

Cliquez sur Modifier :

Modifiez vos paramétrages pour intégrer l’Administrateur sécurité dans l’activation et cliquez sur Mettre à jour :

Etape VII : Test de la fonctionnalité PIM sur Azure Resource Guard

Avant d’activer le rôle Contributeur sur Azure Resource Guard via Azure AD PIM, nous allons vérifier que l’action sur la sauvegarde de la machine virtuelle n’est pas autorisée dans les conditions de base.

Sur le tenant A, retourner sur le coffre de sauvegarde et cliquez comme ceci :

Cliquez ici pour arrêter le mécanisme de sauvegarde :

Arrêtez complètement le backup et supprimer les données :

Le message d’erreur suivant devrait alors apparaître :

Il est donc bien nécessaire de faire une élévation temporaire des droits sur Azure Resource Guard. Positionnez-vous sur le tenant contenant Azure Resource Guard et lancez Azure AD PIM :

Cliquez sur Mes Rôles :

Cliquez sur Ressources Azure puis sur Activer :

Entrez une justification et une période puis cliquez sur Activer :

La notification Azure suivante doit apparaître :

Sur le tenant B, cliquez sur Approuver les demandes dans Azure AD PIM :

Cliquez sur Ressources Azure et approuvez la demande :

Confirmez la demande d’approbation :

Sur le tenant A, un contrôle sur Azure AD PIM nous montre que le rôle de Contributeur est bien actif :

Retentez alors l’opération de suppression de la sauvegarde de la machine virtuelle :

Si l’erreur suivante arrive en notification, refaite un test dans quelques minutes :

Conclusion

L’ajout de cette fonctionnalité sur un coffre de sauvegarde est un vrai plus en termes de protection des ressources Azure. Il est vrai que la situation antérieure, avec des propriétaires et des contributeurs au plein pouvoirs pouvaient inquiéter en cas de scénarios d’attaque.

Il parait indispensable de sécuriser les opérations critiques liées aux sauvegardes, bien prises en compte avec Azure Resource Guard :

MUA apporte une vraie réponse pour protéger encore plus les sauvegardes et sans surcoût, sauf si Azure AD PIM est présent dans votre architecture. Nul doute qu’Azure Resource Guard va apporter encore plus de protection sur d’autres services au fil de ses évolutions.

Optimisez votre Azure : 2/4 – La sécurité de votre Azure

Comme pour les autres sections, voici une liste non exhaustive de différents outils de protection des ressources créées sur Azure.

Azure Advisor

Je vous avais déjà signalé que cet outil prodiguait gratuitement quelques conseils pour réaliser des économies sur votre architecture Cloud. Azure Advisor va plus loin en proposant également des conseils de sécurité.

Comme les autres recommandations, celles de sécurité sont classifiées selon l’impact et le risque sécuritaire.

Un clic sur les 21 recommandations listées dans mon tenant nous en affiche le détail :

Les premières recommandations sont pleines de bon sens :

  • Trop de propriétaires pour le(s) souscription(s) Azure
  • Activation si besoin de Microsoft Defender
  • Activation de la MFA pour les comptes propriétaires ????

Certaines sont à prendre avec plus de recul, comme par exemple celle-ci :

Azure Advisor autorise les exceptions après analyse du conseil.

Comme beaucoup de services sous Azure, le coût peut être un frein selon l’usage :

Dans certains cas, Azure Advisor proposera même de « corriger » à votre place la recommandation de sécurité :

Defender for Cloud (Anciennement Azure Security Center + Azure Defender)

Microsoft a renommé ce service lors du dernier Ignite en 2021. Microsoft Defender for Cloud est une solution comportant deux aspects majeurs :

  • Gestion de la posture de sécurité cloud (CSPM) : identifie les faiblesses dans votre architecture cloud, aide à renforcer la posture de sécurité globale de votre environnement (IaaS, PaaS, SaaS).
  • Protection de la charge de travail cloud (CWP). Créer une protection des charges de travail (machine virtuelle, stockage, Kubernetes, SQL, …) dans des environnements multiclouds ou hybrides contre les menaces.

Historiquement, il existait déjà ces deux services, l’un gratuit (Azure Security Center) et l’autre payant (Azure Defender), couvrant approximativement le même périmètre. Voici un schéma pour comprendre cette évolution :

Posture de sécurité pour Microsoft Defender pour le cloud

Déjà disponible sous un ancien nom Azure Secure Score, Defender for Cloud reprend le même principe grâce l’évolution permanente des caractéristiques de sécurité des ressources Azure. Chaque point de faiblesse et alors valorisé pour établir le score de sécurité de l’architecture : plus le score est élevé, plus le niveau de risque identifié par Microsoft est faible.

Azure Defender for Server

Microsoft Defender pour les serveurs fournit la détection des menaces ainsi que des défenses avancées à vos machines Windows et Linux, qu’elles s’exécutent dans Azure, AWS, GCP ou localement. Microsoft Defender pour les serveurs est disponible dans deux plans :

Microsoft Doc

Autrement dit, l’intégration d’une ressource dans Microsoft Defender active un grand nombre de mesures de sécurité (capteurs de faille, évaluation des vulnérabilités, threat intelligence, …), mais apporte également la possibilité de piloter ses alertes et ses incidents depuis le centre de sécurité Microsoft.

Deux plans sont maintenant disponibles selon le serveur concerné et les fonctionnalités recherchées. Le plan 2 correspond à l’ancien plan appelé Defender for Server :

La liste des avantages de Defender for Server se trouve ici.

Particularité Azure :

Il est aussi possible d’intégrer un serveur protégé par Defender for Cloud dans Microsoft Defender sans aucun surcoût ! Prenez le temps de lire attentivement l’article suivant, mettant en lumière les différences entre Defender for Cloud et Defender for server, mais aussi leurs possibilités d’intégration commune.

Et enfin un autre article pour la mise en place juste ici.

Azure Backup

Azure Backup est un service de sauvegarde apportant une couche de sécurité supplémentaire en cas de perte ou de corruption de donnée. Ce service est payant et est en supplément dans la plupart des cas, mais peut être déjà intégré dans le cout de certains services PaaS (App service, MySQL, …). Comme le montre le schéma ci-dessous :

  • Azure Backup Center pilote les sauvegardes effectuées dans les différents coffres de sauvegarde ou coffres de restauration.
  • Le choix du nombre de sauvegardes est accessible lors de la mise en place de cette dernière
  • Il est même possible de sauvegarder des ressources en dehors Azure afin de garantir une copie complète de toutes les données d’entreprise.

Azure Disaster Recovery

La sauvegarde de données n’est pas un gage systématique de reprise d’activité après sinistre. Pour cela, des solutions dédiées sont mises en place et interviennent en parallèle du cycle de sauvegarde.

Le schéma d’architecture ci-dessous montre la réplication des services entre deux régions Azure :

Les machines virtuelles présentes dans la seconde région Azure ne seront allumées que lors que failover est déclenché.

La synchronisation des données est pilotée par le service Azure Site Recovery. Des disques réplicas sont créés et facturés dans la seconde région. Il en est de même pour les bases de données répliquées. A l’inverse, les machines virtuelles ne sont pas démarrées, ce qui en réduit le coût opérationnel de la seconde région.

Retrouvez mon article sur la mise en place de ce service sur une architecture Azure Virtual Desktop.

Verrous Azure

Comment protéger les ressources Azure d’une simple suppression accidentelle ?

Il arrive que les droits utilisateurs soient justifiés, mais qu’une simple erreur d’inattention provoque de gros dégâts dans l’architecture Azure. Les verrous d’Azure sont là pour ça !

Les verrous Azure sont des composants gratuits et paramétrables sur différents niveaux :

  • Souscription Azure
  • Groupe de ressource
  • Azure

Les verrous Azure fonctionnent aussi par héritage et provoque deux types de blocage :

  • CanNotDelete signifie que les utilisateurs autorisés peuvent lire et modifier une ressource, mais qu’ils ne peuvent pas la supprimer.
  • ReadOnly signifie que les utilisateurs autorisés peuvent lire une ressource, mais ne pas la supprimer ni la mettre à jour. Appliquer ce verrou revient à limiter à tous les utilisateurs autorisés les autorisations fournies par le rôle Lecteur.

Rappel des chapitres de l’article

Etape II : La sécurité de vos identités
Etape III : La sécurité de vos périphériques
Etape IV : La sécurité de votre Azure
Etape V : La sécurité de vos réseaux
Etape VI : La sécurité de vos applications
Etape VII : La sécurité de vos données
Etape VIII : Certifications de Sécurité Microsoft

Optimisez votre Azure : 2/4 – La sécurité de vos réseaux

Dans un environnement Cloud, la connectivité réseau est un point primordial de la sécurité. Que les services hébergés dans le cloud doivent être accessibles depuis une architecture on-premise ou pour des utilisateurs internet, il est nécessaire de mettre en place des mesures de sécurité pour protéger le traffic réseau mais aussi les périphériques.

Pour cela, voici quelques services disponibles nativement sous Azure pour y parvenir :

Azure VPN

Azure VPN est un service managé par Microsoft :

Une passerelle de réseau virtuel est composée de deux machines virtuelles ou plus qui sont automatiquement configurées et déployées sur un sous-réseau spécifique que vous créez, appelé sous-réseau de la passerelle… Vous ne pouvez pas configurer directement les machines virtuelles qui font partie de la passerelle de réseau virtuel, même si les paramètres que vous sélectionnez lors de la configuration de votre passerelle ont un impact sur les machines virtuelles de passerelle créées.

Microsoft Doc

La passerelle de réseau virtuel envoie du trafic crypté entre un réseau virtuel Azure et un site via Internet. Cette connexion est disponible pour deux besoins :

  • Connexion Site à Site (S2S) : utilisée pour établir une ou des connexions permanentes vers des locaux afin de prolonger les réseaux locaux dans Azure.
  • Connexion Point à Site (P2S) : utilisée pour établir des connexions temporaires en situation de mobilité. Ideal pour des périphériques portables.

Dans le cadre d’une connexion P2S, les méthodes d’authentification à Azure VPN sont à considérer selon le type de périphériques utilisé :

Azure propose plusieurs SKUs de VPN avec différents débits :

A cela, il faut aussi ajouter les coûts de bande passantes puisque le traffic sortant d’Azure est facturé par Microsoft :

Azure ExpressRoute

A l’inverse d’Azure VPN, les connexions ExpressRoute n’acheminent pas le traffic via Internet. Elles offrent plus de fiabilité, une vitesse plus rapide et une latence inférieure que les connexions Internet classiques.

Un circuit ExpressRoute comporte toujours deux connexions à deux routeurs périphériques Microsoft Enterprise (MSEE). Les fournisseurs de connectivité utilisent eux aussi des dispositifs redondants pour assurer la redondance de vos connexions à Microsoft.

Les principaux avantages de la connexion ExpressRoute sont :

  • Connectivité de couche 3 entre votre réseau local et le cloud de Microsoft via un fournisseur de connectivité.
  • Connectivité aux services de cloud de Microsoft dans toutes les régions de la zone géopolitique.
  • Routage dynamique entre votre réseau et Microsoft via le protocole de routage dynamique standard (BGP).
  • Redondance intégrée dans chaque emplacement de peering pour une plus grande fiabilité.
  • SLA de disponibilité de la connexion.
  • Support de la qualité de service pour Skype Entreprise.

La tarification d’une liaison ExpressRoute est plus chère qu’une liaison Azure VPN et se décompose de la façon suivante :

  • Passerelle de réseau virtuelle ExpressRoute (Microsoft)
  • Circuit ExpressRoute (Microsoft)
  • Traffic sortant si formule non illimité (Microsoft)
  • Partenaire de connectivité ExpressRoute (Fournisseur d’accès)

Des formules annexes d’ExpressRoute existent comme :

Azure Network Security Group (NSG)

Un groupe de sécurité réseau (NSG) filtre le trafic réseau entrant et sortant et contient des règles qui sont utilisées pour autoriser ou refuser le trafic de sécurité réseau filtré. La configuration de ces règles de sécurité NSG vous permet de contrôler le trafic réseau en autorisant ou en refusant des types de trafic spécifiques. Vous pouvez affecter un NSG à :

  • Une interface réseau pour filtrer le trafic réseau sur cette interface uniquement.
  • Un sous-réseau pour filtrer le trafic sur toutes les interfaces réseau connectées dans le sous-réseau.

Vous pouvez également affecter des NSG à la fois à des interfaces réseau et à des sous-réseaux. Dans ce cas, chaque NSG est évalué indépendamment.

Azure Application Security Group (ASG)

Il est possible de combiner l’efficacité du NSG en associant les ressources de même nature à un ASG. Le groupe de sécurité des applications vous permet de configurer la sécurité du réseau comme une extension naturelle de la structure d’une application, en vous permettant de regrouper des machines virtuelles et de définir des politiques de sécurité du réseau en fonction de ces groupes.

Azure Bastion

Les machines virtuelles Windows et Linux nécessitent un accès pour leur administration. L’ajout d’une IP publique sur la machine virtuelle résout le souci d’accès externe mais créer un précédent de sécurité. C’est là qu’Azure Bastion rentre en scène :

Azure Bastion est un service PaaS proposé par Azure pour apporter une couche de sécurité supplémentaire dans le cadre de connexion RDP/SSH. Ce composant permet alors de se connecter sur des machines virtuelles sans les exposer à internet.

Azure Bastion doit être associé à un réseau virtuel même s’il est compatible avec les réseaux virtuels associés à ce dernier.

Azure Firewall

Azure Firewall est un service de sécurité réseau basé sur le cloud qui permet de protéger vos ressources VNet. En utilisant Azure Firewall, vous pouvez créer et gérer de manière centralisée des profils de connectivité réseau dans toute votre organisation.

Rappel des chapitres de l’article

Etape II : La sécurité de vos identités
Etape III : La sécurité de vos périphériques
Etape IV : La sécurité de votre Azure
Etape V : La sécurité de vos réseaux
Etape VI : La sécurité de vos applications
Etape VII : La sécurité de vos données
Etape VIII : Certifications de Sécurité Microsoft