Il est possible depuis longtemps de se connecter à une session Windows via un compte Azure AD, que cela concerne Windows 10/11 ou Windows Server. Pour cela, une jointure à Azure AD est nécessaire et l’article l’expliquant est disponible juste ici. Seulement sur Azure, les choses sont légèrement différentes. Je trouvais donc intéressant de vous en écrire un article dessus.
En effet, lors de la création d’une machine virtuelle Azure, il est possible de la joindre directement à Azure AD au travers d’une extension. Cette jointure va vous permettre de vous y connecter en bureau à distance via votre compte Azure AD.
Mais certaines choses sont à respecter pour que cela fonctionne, et c’est pour cela que j’ai écrit cet article, car bien souvent on bloque et on tourne en rond.
Dans celui-ci, vous trouverez toutes les étapes nécessaires, de la création à la connexion à la machine virtuelle, en passant par une règle d’accès conditionnel d’Azure AD :
Modifiez les deux clefs suivantes en changeant leur valeur par zéro :
SecurityLayer
UserAuthentication
Il est possible de faire via un script PowerShell, exécutable depuis le portail Azure :
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '0' # was before 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '0' # was before 1
Retentez une connexion à distance depuis Azure Bastion avec votre utilisateur de test, toujours précédé de la mention AzureAD\ :
Constatez cette fois-ci la bonne ouverture de votre session Windows :
Afin de renforcer la sécurité de vos utilisateurs, la mise en place d’une connexion renforcée via MFA est indispensable. Voici d’ailleurs plus articles intéressants à ce sujet :
Bien souvent, la question se pose sur l’ouverture de session Windows avec un compte Azure AD protégé par une MFA. Pour cela, nous allons tester l’impact de l’accès conditionnel sur notre utilisateur
Etape III – Test avec accès conditionnel MFA :
Pour cela, rendez-vous à la page d’Azure AD suivante afin d’y créer une règle d’accès conditionnel pour notre utilisateur de test :
Ajoutez votre utilisateur de test dans le public cible :
Dans un premier temps, intégrez l’ensemble des applications cloud dans cette police d’accès conditionnel :
Autorisez l’accès sous la condition de réussir le challenge MFA, activez la police puis sauvegardez la :
Avant de tester la solution sur l’ouverture de session Windows, il est nécessaire de configurer la MFA pour notre utilisateur de test.
Comme la police d’accès conditionnel est très récente, il est préférable d’attendre environ 5 minutes que celle-ci soit correctement appliquée pour notre utilisateur.
Rendez-vous en navigation privée sur la page office.com, puis authentifiez-vous :
Comme on pouvait s’y attendre, il est nécessaire de remplir les informations MFA dès à présent.
Choisissez la méthode MFA qui vous arrange, puis configurez-là :
Fermez le navigateur privé, puis réouvrez-en un afin de vérifier que le challenge MFA est bien présent et correctement configuré :
Retournez sur le portail Azure, rouvrez une session Windows avec les mêmes identifiants que lors du test précédent :
Constatez la présence de ce message bloquant provenant du challenge MFA :
Et cela malgré l’indication des succès dans le log des authentifications d’Azure AD de notre utilisateur de test :
Afin de contourner le problème lié à la MFA sur le compte Azure AD, retournez dans la police d’accès conditionnel créée précédemment afin de lui y ajouter l’exclusion suivante, puis sauvegardez :
Retendez encore une fois d’ouvrir une session Windows avec les mêmes identifiants que lors du test précédent :
Constatez cette fois-ci le succès et l’absence de blocage au moment de l’ouverture de session.
Un rapide whoami en ligne de commande nous confirme bien la connexion au compte Azure AD :
Conclusion
Finalement, les opérations nécessaires à la connexion à la VM via Azure AD ne sont pas très compliquées. Notez ici qu’il s’agit d’un simple test et que la grande majorité d’environnement de production nécessiteront des mesures de sécurité supplémentaires.
La gestion des mots de passe est une tâche critique, mais ô combien barbante, que cela concerne les comptes personnels ou professionnels. L’apparition des gestionnaires de mots de passes et des méthodes d’authentifications renforcées (2FA / MFA) ont permis d’accroîte la sécurité sur les identités.
Windows fonctionne de la même manière et dispose-lui aussi de comptes aux droits variés. Microsoft propose justement d’en gérer une partie pour vous via Entra ID (Azure AD).
Microsoft a annoncé en mai 2023, la prise en charge des mots de passe Windows LAPS (Windows Local Administrator Password Solution) par Entra ID (Azure AD).
En quelques mots, Entra ID est capable de stocker de façon sécurisé le mot de passe de l’administrateur local de chacun des postes Windows. Mais il y a mieux, Entra ID se chargera aussi de la rotation de ces derniers selon vos propres règles !
Qu’est-ce Windows LAPS ?
Chaque machine Windows dispose d’un compte d’administrateur local intégré qui ne peut pas être supprimé et qui dispose d’autorisations complètes sur l’appareil. La sécurisation de ce compte est une étape importante dans la sécurisation de votre organization. Les appareils Windows incluent la solution de mot de passe de l’administrateur local Windows (LAPS), une solution intégrée permettant de gérer les comptes d’administrateur local.
La configuration de Windows LAPS via Azure AD se fait via Microsoft Intune. Il faudra donc joindre en MDM les machines à ce dernier de afin de pouvoir leur appliquer la police de configuration.
Pour cela les jointures suivantes sont possibles :
Jointure à Azure AD
Jointure Hybride (Azure AD + Active Directory)
Intune prend en charge les fonctionnalités suivantes de Windows LAPS :
Définition des exigences de mot de passe
Rotation automatique et périodique du mot de passe
Choix du lieu de sauvegarde du mot de passe
Actions après utilisation du mot de passe
Avons-nous besoin de licence particulière ?
Pour profiter de la fonctionnalité Windows LAPS au travers d’Entra ID / Intune, il est nécessaire de disposer ces licences suivantes :
Microsoft Intune Plan 1
Microsoft Entra ID Free, anciennement Azure Active Directory Free
Existe-t-il des rôles RBAC dédiés à Windows LAPS ?
Windows LAPS est encore en préversion à l’heure où ces lignes sont écrites. Les rôles et permissions dédiés seront introduit par la suite. Pour l’instant, il est nécessaire d’utiliser l’un des deux rôles Azure AD suivants :
Global Administrator
Cloud Device Administrator
Enfin, Microsoft a commencé à mettre une FAQ sur Windows LAPS juste ici.
Afin de bien comprendre Windows LAPS, nous nous allons prendre de tester cette nouvelle fonctionnalité dans cet article :
Pour réaliser cet exercice sur Windows LAPS, il vous faudra disposer des ressources suivantes :
Une souscription Azure valide
Une Licence Intune Plan 1
Dans notre exercice, nous allons créer plusieurs machines virtuelles via Azure Virtual Desktop afin de servir de machines utilisateurs de test. Ces machines seront automatiquement jointes à Entra ID et Intune pour la suite de notre configuration.
Etape I – Préparation d’Azure Virtual Desktop :
Commençons par créer nos machines virtuelles AVD de test.
Pour cela, rendez-vous dans le portail d’Azure afin créer un réseau virtuel en utilisant la barre de recherche en haut de l’écran :
Cliquez ici pour créer votre réseau virtuel pour les VMs d’AVD :
Renseignez les différents champs, puis lancez validation du template par Azure :
Une fois la validation réussie, lancez la création de la ressource :
Attendez environ une minute que le réseau virtuel Azure soit créé, puis cliquez-ici :
Rendez-vous dans la section suivante afin de créer un futur accès aux VMs via le service Azure Bastion :
Le service Azure Bastion se créé en tâche de fond comme le montre les deux notifications suivantes :
N’attendez par la fin d’Azure Bastion et continuez la création des ressources AVD en utilisant la barre de recherche Azure :
Cliquez-ici pour créer un nouvel environnement Azure Virtual Desktop :
Renseignez les champs du premier onglet, puis cliquez sur Suivant :
Inutile de modifier l’accès réseau AVD sur le second onglet, cliquez sur Suivant :
Renseignez les informations liées aux machines virtuelles AVD en prenant soin de choisir une image présente dans la liste de celles compatibles avec Windows LAPS :
Définissez le nombre de VMs voulues, puis renseignez le réseau virtuel créé précédemment :
Joignez vos VMs AVD à Azure AD et en gestion MDM avec Intune, puis renseignez un mot de passe administrateur local qui sera géré par Windows LAPS par la suite :
Créez un espace de travail AVD, puis lancez la validation Azure :
Une fois la validation Azure passée, lancez la création des ressource AVD :
Le traitement Azure devrait durer une dizaine de minutes environ :
Pendant ce temps, recherchez Azure AD afin de créer les groupes et utilisateurs :
Créez si besoin les utilisateurs nécessaires à AVD :
Créez si besoin le groupe d’utilisateurs nécessaire à AVD :
Retournez sur le portail Azure afin d’ajouter des rôles RBAC Azure sur le groupe de ressources AVD :
Ajoutez les rôles suivants sur le groupe d’utilisateurs AVD :
Quelques minutes plus tard, les ressources Azure créées pour AVD sont bien disponibles, cliquez-ici pour consulter le pool d’hôtes :
Rafraichissez plusieurs fois afin que toutes les machines AVD soient prêtent et disponibles :
Quelques rafraichissements plus tard, toutes les machines virtuelles sont bien disponibles :
Activez la fonction suivante pour profiter du SSO dans les propriétés RDP, puis sauvegardez :
Votre environnement Azure Virtual Desktop est maintenant prêt. Nous allons pouvoir maintenant configurer Windows LAPS.
Etape II – Préparation de Windows LAPS sur Entra ID :
Afin de pouvoir utiliser Windows LAPS sur nos machines virtuelles d’Azure Virtual Desktop, il est nécessaire de l’activer sur notre tenant.
Pour cela, rendez-vous sur le portail Entra afin d’activer l’option suivante, puis sauvegardez :
Profitez-en pour vérifier les présences des VMs AVD et la bonne gestion MDM par Intune :
Créez un nouveau groupe Azure AD dédié aux machines virtuelles AVD :
Ajoutez les VMs AVD à ce groupe, puis lancez la création :
Le travail sur Entra ID est maintenant terminé, il ne nous reste qu’à créer notre police de configuration dédiée à Windows LAPS sur Intune.
Etape III – Configuration de Windows LAPS sur Intune :
Pour cela, rendez vous sur le portail Intune sur l’adresse suivante.
Créer une nouvelle police de configuration comme ceci :
Choisissez le type de profile ci-dessous, puis cliquez sur Créer :
Nommez votre nouvelle police de profil, puis cliquez sur Suivant :
Définissez les règles de configuration, puis cliquez sur Suivant :
Dans mon exemple, après chaque authentification réussie de mon administrateur local JLO, un nouveau mot de passe sera redéfini 1 heure après.
Sinon, ce dernier est systématiquement changé tous les 7 jours.
Cliquez sur Suivant :
Ajoutez le groupe de VMs créé précédemment, puis cliquez sur Suivant :
Lancez la création de votre police Windows LAPS :
Toujours sur Intune, allez voir sur une des VMs AVD afin de voir la liste des configurations appliquées :
Attendez quelques minutes puis rafraichissez afin de constater la présence de votre nouvelle police Windows LAPS :
Notre configuration est enfin terminée, nous allons pouvoir tester Windows LAPS et son impact en nous connectant sur une des machines virtuelles AVD de test.
Etape IV – Test de Windows LAPS
Avant de vous connecter, retournez sur la liste des VMs AVD depuis le portail Azure AD :
Sur une des machines AVD, cliquez sur le menu suivant pour constater l’absence de mot de passe de l’administrateur local :
Sur le portail Azure, retournez sur la liste des machines virtuelles afin de vous y connecter à l’une d’entre-elles via Azure Bastion en utilisant le compte administrateur AVD renseigné :
Vérifiez la présence des droits administrateurs sur votre session :
Déconnectez-vous de la session Azure Bastion :
Attendez un peu, puis recommencez une connexion Azure Bastion avec les mêmes identifiants :
Constatez l’apparition du message d’erreur suivant :
Retournez sur la VM AVD utilisée depuis le portail d’Azure AD :
Retentez une nouvelle connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :
Déconnectez-vous encore une fois de la session Azure Bastion :
Attendez environ une heure, puis recommencez une connexion Azure Bastion avec les mêmes nouveaux identifiants :
Constatez encore une fois l’apparition du message d’erreur suivant :
Retournez encore une fois sur la VM AVD utilisée depuis le portail d’Azure AD :
Retentez une 3ème connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :
Déconnectez-vous une fois 3ème de la session Azure Bastion :
Une heure plus tard, le mot de passe aura encore tourné ✌️:
Petite anecdote :
Sur mon portail Intune, je ne vois pas le menu Local admin password 🥲🥲
Cela ne m’a pas empêché de retrouver l’info sur le portail d’Azure AD.
Conclusion
Très facile à mettre en oeuvre et fonctionnant aussi bien dans une architecture 100% Cloud ou Hybride, cette solution apporte une sécurité supplémentaire sur les postes physiques ou virtuels. Nul doute que la gestion de mots de passe administrateur Windows dans Azure va également faciliter le travail de fournis de certains administrateurs IT 😎
A l’ère des environnements Cloud ou hybride, la façon dont on consomme la donnée a complètement changé. Maintenant, tout est question de mobilité, d’accessibilité et de collaboration. Mais cette ouverture s’accompagne aussi de risques dont les origines, humaines ou logicielles, sont intrinsèques.
Microsoft, et comme d’autres acteurs du marché, s’efforce depuis plusieurs années d’y remédier via sa suite Microsoft 365 Defender. Dans cet article, nous allons nous intéresser à une licence apparue fin 2021 : Microsoft Defender for Business.
Avant de rentrer dans le vif du sujet, je vous propose de revenir sur plusieurs grands aspects relatifs à la sécurité, dont certains font déjà l’objet d’articles sur ce blog :
Quel que soit l’environnement IT, le principe des couches sécurité s’applique.
Comme un oignon, chaque couche de sécurité apporte des mesures, passives ou actives, empêchant ou retardant l’accès à la donnée, élément critique de l’entreprise :
Une architecture Cloud n’échappe pas non plus à cette règle, il est naif de penser que les solutions d’hébergement publics sont toutes à 100% protégées par le fournisseur. Les mesures et l’intelligence dédiée à la sécurité y sont certes plus avancées, mais plusieurs couches nécessiteront obligatoirement votre contribution.
Qu’est-ce que Microsoft 365 Defender ?
Voici comment Microsoft le définit :
Microsoft 365 Defender est une suite de défense d’entreprise pré-et post-violation unifiée qui coordonne en natif la détection, la prévention, les examens et la réponse sur les points de terminaison, les identités, les messages électroniques et les applications pour fournir une protection intégrée contre les attaques sophistiquées.
Pour simplifier au maximum, Microsoft Defender vous propose des services de sécurité dans 4 grands domaines :
Sécurité I – Identités avec Defender for Identity :
Solution de sécurité basée sur le cloud qui tire parti de votre AD local signaux pour identifier, détecter et examiner les menaces avancées, les identités compromises et les actions internes malveillantes dirigées contre votre organisation.
Sécurité II – Périphériques grâce Defender for Endpoint :
Plateforme unifiée pour la protection préventive, curative, ainsi pour que des méthodes d’investigation et de réponse automatisées sur les postes et les serveurs.
Sécurité III – Applications avec Defender for Cloud Apps et Defender for Office 365 :
Defender pour Office 365 protège votre organisation contre les menaces malveillantes posées par les messages électroniques, les liens (URL) et via les outils de collaboration.
Microsoft Defender for Cloud Apps est une solution multi-SaaS complète qui offre une visibilité approfondie, des contrôles de données forts et une protection renforcée contre les menaces à vos applications cloud.
Sécurité IV – Données avec Microsoft Purview :
Famille de solutions en matière de gouvernance, de risques et de conformité des données qui peuvent aider votre organisation à régir, protéger et gérer l’ensemble de votre patrimoine de données.
La donnée est la valeur la plus importante pour une entreprise. Que celle-ci porte sur des secrets industriels, des informations clients ou des mesures financières, il est toujours nécessaire de l’appréhender selon ces 3 grands principes :
Les données ne sont pas créées de manière égale. Certaines données sont plus sensibles et nécessitent un niveau de protection et de contrôle plus fort que d’autres types.
Quand est-ce que Microsoft 365 Defender for Business rentre en scène ?
Les petites et moyennes entreprises sont-elles-aussi soumises aux mêmes risques que certaines multinationales. La solution gérant la sécurité des postes ne doit surtout pas être dégradée :
Au-delà de toutes les fonctionnalités proposées par cette licence, voici pourquoi je la trouve intéressante pour les SMB dans la gestion de la sécurité des postes et des serveurs :
Simplification dans la gestion et dans le processus l’onboarding
Intégration avec Microsoft Intune
Recommandations de sécurité activées dès le départ
Tableau de bord orienté vers l’action aidant à hiérarchiser les tâches
Centralisation des environnements avec Microsoft 365 Lighthouse
Afin de tester la protection des périphériques grâce à cette licence, je vous propose de créer un environnement de démonstration sur Azure.
Pour cela, nous utiliserons des machines virtuelles en Windows 11 issues d’Azure Virtual Desktop. Ces machines seront alors jointes à Azure AD, Intune, puis Microsoft 365 Defender.
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice sur Microsoft Defender for Business, il vous faudra disposer de :
Un tenant Microsoft
Un ou plusieurs licences Microsoft 365 Business Premium
Une souscription Azure valide
Etape I – Vérification de l’environnement de départ :
Avant de commencer le déploiement de ressources Azure, consultez les licences présentes sur votre tenant par ce lien :
Consultez également les périphériques déjà chargés dans votre Azure AD par ce lien :
Votre environnement IT est enfin prêt. Nous allons maintenant utiliser le portail Defender.
Afin de mettre en route Microsoft Defender for Business, il est nécessaire de commencer par une étape de configuration, côté Intune et côté Defender .
Etape III – Configuration de Microsoft 365 Defender for Business :
Pour cela cliquez-ici pour vous rendre sur le portail Defender, puis lancez le démarrage de la configuration :
Quelques minutes plus tard, cliquez-ici pour démarrer la configuration :
Assignez des utilisateurs de votre tenant aux deux rôles suivants :
Administrateur de sécurité : autorisés à gérer les fonctionnalités liées à la sécurité dans les portails Microsoft 365 Defender, Azure Active Directory Identity Protection, Azure Active Directory Authentication, Azure Information Protection et Microsoft Purview
Lecteur Sécurité : accès en lecture seule au niveau global à la fonctionnalité liée à la sécurité, notamment à toutes les informations dans le portail Microsoft 365 Defender, Azure Active Directory, Identity Protection, Privileged Identity Management, mais également les rapports sur les connexions Azure Active Directory et les journaux d’audit, ainsi que dans le portail de conformité Microsoft Purview.
Cliquez ensuite sur Continuer :
Définissez une ou plusieurs adresses emails afin de recevoir des notifications concernant les incidents et les vulnérabilités :
Choisissiez la méthode d’enrôlement des périphériques à Defender. Dans mon cas, je choisi l’intégration automatique via Intune :
Validez votre configuration si tout est OK pour vous :
Attendez environ 5 minutes pour que Microsoft finalise la configuration :
Le message suivant doit alors apparaître :
Le processus de mise en oeuvre est terminé ! Plutôt rapide non ?
Avant de voir les périphériques apparaitre, profitons-en pour faire le tour de certains paramétrages.
Etape IV – Paramétrages disponibles :
Cliquez-ici pour ouvrir activer la fonctionnalité de Live Response de Defender :
Activez si vous le souhaitez les fonctionnalités encore en préversion, puis cliquer sur Sauvegarder.
Profitez-en pour élargir le périmètre de Defender en permettant aux paramètres de sécurité d’Intune d’être appliqués par Microsoft Defender for Endpoint (MDE) aux appareils qui ne sont pas encore inscrits à Intune :
Configurez également et facilement un filtrage web grâce à un blocage de catégories :
Nommez votre police de filtrage web :
Ajoutez une ou plusieurs catégories à bloquer :
Validez la création en sauvegardant votre police :
Retournez sur le portail pour vérifier la bonne connection entre Intune et Microsoft Defender for Endpoint, validez l’option suivante, puis cliquer sur Sauvegarder :
Retournez sur votre portail Defender pour constater la présence de vos machines AVD.
Note : Il est possible que cela prenne environ 30 minutes pour voir les VMs AVD apparaître.
Comme la configuration de base est terminée et que les VMs sont remontées, nous allons pouvoir tester la bonne remontée des alertes et incidents dans Microsoft 365 Defender.
Etape V – Alerte / incident de test :
Récupérez le script PowerShell disponible sur le portail Defender :
Téléchargez le client Azure Virtual Desktop via cette page Microsoft, installez-le, lancez-le, puis cliquez-ici pour ajouter vos accès AVD de test :
Ajoutez vos 4 utilisateurs de test paramétré pour utiliser AVD :
Renseignez les mots de passe pour chacun d’eux :
Cliquez sur une session AVD et renseignez à nouveau le mot de passe utilisateur :
Acceptez la configuration SSO entre votre Azure AD et votre VM AVD :
Ouvrez le programme de ligne de commande Windows en mode Administrateur :
Renseignez le compte de l’administrateur local saisi dans Azure :
Collez le script récupéré précédemment, puis lancez-le :
Quelques minutes plus tard, toujours dans la page de configuration, constatez la validation du test de détection :
Vérifiez la boite de messagerie renseignée lors de la configuration de Microsoft 365 Defender for Business :
Dans la page d’incident, vous devriez voir votre premier cas, issu de votre script de test :
Cliquez dessus, parcourez les différents onglets, puis cliquez ici :
Une fois analysé, changez le statut de votre incident pour le clôturer :
Jusqu’à présent, nous n’avons pas modifié la politique de configuration concernant la sécurité des postes. Comme nos machines virtuelles AVD de test sont présentes dans Intune et dans Microsoft 365 Defender, nous devons choisir le lieu de configuration.
Etape VI – Configuration de polices de sécurité via Defender :
Rappelez-vous dans mon exemple que mon environnement ne contenait aucun poste dans ma console Intune. Je n’avais donc encore rien configuré. Cela ne sera pas forcément le cas dans un environnement déjà en place.
Microsoft recommande la mise en place de la gestion des polices de sécurité via Microsoft Defender 365. Cela rendra l’outil plus performant et facilitera la tâche des personnes spécifiquement dédiées à la sécurité des postes.
Dans le menu suivant, cliquez comme ceci :
Prenez le temps de bien lire l’avertissement de Microsoft :
Validez si vous êtes toujours d’accord avec cette gestion :
Environ une minute plus tard, la configuration des périphériques est disponible sur deux points :
Protection Next-Gen
Firewall
Celles-ci sont déjà sont déjà configurés et installés sur tous les périphériques. Cliquez sur l’une d’entre-elles pour comprendre sa configuration :
Faites-en de même avec la seconde :
Retournez sur le portail Intune pour constater d’éventuels changements.
Section Antivirus :
Section Firewall :
Section EDR :
Section des profils de configuration :
De retour sur le portail Defender, constatez la bonne application des 2 configurations à vos machines virtuelles Azure Virtual Desktop :
Etape VI – Tests de fonctionnalités de Defender :
Afin de voir comment se comporte Defender for business, je vous conseille d’attendre quelques heures, le temps que toutes les configurations soient bien appliquées aux VMs AVD.
Commencez par le filtrage web en recherchant un jeu sur votre moteur de recherche favori :
Cliquez sur un résultat de la liste :
Environ une seconde plus tard, constatez le blocage par la fenêtre suivante :
Il ne vous reste rien qu’à tester d’autres fonctionnalités depuis le portail Defender !
Etape VII – Quelques fonctions Defender
Comme les fonctionnalités sont nombreuses sur Defender, je trouve intéressant de vous en sélectionner quelques-unes liées aux périphériques et accompagnées de copies d’écran.
Incidents & Alertes
Tableaux de bord & Analyses
Actions sur le périphérique
Incidents & Alertes :
Tableaux de bord & Analyses :
Actions sur le périphérique :
Bloquer un processus considéré comme suspicieux :
Restreindre le lancement d’application non signée :
Lancer un scan antivirus sur le périphérique :
Démarrer une session de Live Response :
Isoler un périphérique du réseau :
Conclusion :
Après seulement quelques temps passé sur le portail de Microsoft 365 Defender, on ne peut que constater la facilité de mise en oeuvre de la solution sur des périphériques. L’intégration avec Intune, Azure AD et les autres mesures de sécurité créé un ensemble cohérent.
On comprend aisément le bénéfice à passer à Microsoft 365 Business Premium.
Cette imbrication permet sans aucun doute une prise en main facile et rapide au sein de nombreuses entreprises SMB.
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 :
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.
Ayant eu l’occasion de participer à un évènement conjoint entre TD SYNNEX, Microsoft et DELL et dédié à Azure Stack HCI, j’ai pu m’intéresser au service qui oeuvre dans l’ombre : Azure Arc. L’ouverture d’Azure sur d’autres sites IT que leurs propres datacenters est indispensable, beaucoup d’architectures IT reposent en effet sur des serveurs locaux, ou sont déjà hébergées auprès d’autres fournisseurs Cloud.
Dans cet article, nous allons effectuer ensemble plusieurs méthodes d’intégration très facile de serveurs au service Azure Arc. Nous en profiterons pour faire tour dans les fonctionnalités disponibles gratuitement ou payantes sur les ressources Arc déployées.
Qu’est-ce qu’Azure Arc ?
Azure Arc est une passerelle qui étend la plateforme Azure pour vous aider à créer des applications et des services ayant la souplesse nécessaire pour fonctionner dans des centres de données, à la périphérie et dans des environnements multiclouds.
A la base, Azure Arc ne coûte rien. Il vous permet d’effectuer les actions suivantes sans débourser un seul centime :
Inventaires des ressources Azure Arc
Accès et sécurisation via l’attribution de droits RBAC
Gestion via l’outil Windows Admin Center
Mais certains services annexes sont payants :
Serveur SQL avec Azure Arc
Defender for Cloud
Azure Policy Guest Configuration
Azure Insights
Logs
…
Puis-je tester moi-même Azure Arc avec une VM Azure ?
Non cela n’est pas possible aussi facilement : Azure n’autorise pas d’intégrer directement une machine virtuelle provenant dans la Marketplace Microsoft dans Azure Arc :
Seulement tout le monde ne dispose pas d’une infrastructure IT prête à servir de cobaye pour tester Azure Arc. C’est pourquoi Microsoft propose Azure Arc Jumpstart.
Le Jumpstart fournit des guides étape par étape pour des scénarios Azure Arc indépendants qui intègrent autant d’automatisation que possible, des captures d’écran et des échantillons de code détaillés, ainsi qu’une expérience riche et complète lors de la prise en main de la plateforme Azure Arc.
Pour en avoir testé quelques-uns, c’est très facile et très bien expliqué.
De mon côté, je vous propose une alternative via un exercice facile pour intégrer des serveurs sur Azure Arc via l’utilisation de ressources uniquement hébergées sur Azure.
Etape 0 – Rappel des prérequis :
Les prérequis suivants sont nécessaires pour réaliser cette démonstration d’Azure Arc :
Un tenant Microsoft
Une souscription Azure valide
Etape I – Déploiement d’un template ressources :
Pour créer des ressources intégrables dans Azure Arc, j’utilise un template développé par Microsoft et disponible depuis GitHub : Line-of-business application migration : à la base, ce template est destiné à tester le service Azure Migrate.
Ce dernier vous propose de déployer un serveur Hyper-V, dans lequel se trouve un applicatif web réparti sur plusieurs machines virtuelles et une base de données SQL.
Seule la partie initiale, encadrée en rouge, nous intéresse pour Azure Arc :
Par ce template, nous allons donc déployer une machine virtuelle Standard D8s v3 (8 vCPU, 32 GB memory) avec un rôle Hyper-V. Cette dernière hébergera 4 machines virtuelles :
Pour cela, cliquez ici pour charger la configuration du template directement dans votre tenant :
Renseignez les champs suivants et continuez :
Par défaut : Le nom d’utilisateur demouser Le mot de passe demo!pass123
Lancez la création et attendez une heure environ :
Prévoyez au moins une heure à partir du début du déploiement du template pour couvrir l’exécution des scripts.
Remarque : le déploiement du template prend environ 6 à 7 minutes. Une fois le déploiement du modèle terminé, plusieurs scripts supplémentaires sont exécutés pour amorcer l’environnement de laboratoire.
Récupérez l’adresse IP publique suivante :
Ouvrez un nouvel onglet depuis votre navigateur internet avec celle-ci. Vous devriez voir un site web affichant des réservations fictives d’hôtels :
Un déploiement correctement terminé devrait vous afficher cette page.
Supprimez le second groupe de ressources destiné aux tests d’Azure Migrate. Nous ne l’utiliserons pas dans le cadre de nos tests sur Azure Arc :
Ouvrez la machine virtuelle SmartHotelHost et cliquez sur Bastion :
Le service Bastion n’est pas créé, lancez son déploiement avec la configuration par défaut :
N’attendez pas la fin du déploiement de Bastion pour continuer.
Etape II – Configuration d’Azure Arc
La configuration d’Azure Arc est très rapide, utilisez la barre de recherche d’Azure pour retrouver le service Azure Arc :
Avant de commencer l’intégration de machines virtuelles à Azure Arc, nous allons créer un principal de service dédié à cette tâche. Ce principal de service va être utilisé pour l’authentification automatique pendant le processus d’intégration des ressources dans Azure Arc.
Cliquez dans le menu suivant :
Cliquez sur Créer :
Renseignez les champs, puis cliquez sur Créer :
Prenez soin de copier l’ID et le secret de principal de service dans un bloc-notes :
Revenez sur la page d’Azure Arc et constatez son apparition :
Une fois Azure Bastion entièrement déployé, retournez sur votre machine virtuelle SmartHotelHost, puis lancez une connexion RDP via Azure Bastion :
Renseignez les identifiants utilisés dans le template, puis cliquez sur Connecter :
La session RDP d’Azure Bastion s’ouvre alors dans un nouvel onglet de votre navigateur web :
Retournez sur le service Azure Arc depuis votre portail Azure, puis cliquez sur Ajouter dans la section Serveurs :
Plusieurs méthodes d’intégration à Azure Arc sont possibles. Le choix de la méthode va surtout dépendre du volume d’intégration à réaliser. Nous allons en tester plusieurs pour vous faire une meilleure idée.
Etape III – Test d’un ajout simple de serveur :
Cette méthode correspond à l’ajout d’un serveur unique sur Azure Arc. Ce premier script effectue les opérations suivantes :
Récupération de l’agent depuis le Centre de téléchargement Microsoft
Installation de l’agent sur le serveur
Création de la ressource serveur compatible avec Azure Arc
Pour utiliser ce script, cliquez comme ceci :
Azure commence par vous présenter les prérequis nécessaires pour assurer la communication entre le serveur et Azure Arc.
La communication repose sur le port 443 (HTTPS), cela nécessite une ouverture de pare-feu pour les flux sortant, et éventuellement la prise en charge d’un service proxy si besoin :
Aucun blocage réseau n’est présent dans notre environnement de test.
Cliquez sur Suivant et renseignez les champs :
Renseignez si besoin les étiquettes appropriées, puis cliquez sur Suivant :
Copiez le script suivant dans votre presse-papier :
Retournez sur la session RDP ouverte grâce à Azure Bastion, puis ouvrez la console Hyper-V :
Connectez-vous à la machine Windows smarthotelweb1 :
Renseignez le mot de passe de session Windows : demo!pass123
Dans cette nouvelle session, ouvrez la console PowerShell :
Collez le script donné par Azure Arc et appuyez sur Entrée pour lancer son exécution :
Comme attendu, le script procède au téléchargement et à l’installation de l’agent :
Identifiez-vous avec le compte Azure AD adéquat pour continuer le processus d’intégration :
Validez le processus d’authentification par un challenge MFA si besoin :
Fermez la fenêtre d’Internet Explorer :
Le script vous confirme la bonne création de l’objet serveur dans Azure Arc :
Retournez sur la page des serveurs Azure Arc, rafraîchissez la page si besoin :
Etape IV – Test d’un ajout de plusieurs serveurs :
Pour ajouter plusieurs serveurs à la fois sur Azure Arc, nous pouvons utiliser la seconde option.
Celle-ci génère un facilement script transportable puisqu’il gère l’authentification Azure via l’exploitation du principal de service créé précédemment. Ce script effectue les opérations suivantes :
Récupération de l’agent depuis le Centre de téléchargement Microsoft
Installation de l’agent sur le serveur
Création de la ressource serveur sur Azure Arc
Pour continuer, cliquez comme ceci :
Renseignez les champs et le principal de service, puis cliquez sur Suivant :
Renseignez si nécessaire les étiquettes appropriées, puis cliquez sur Suivant :
Copiez le script dans le presse-papier :
Retournez sur la session d’Azure Bastion. Sur la console Hyper-V, connectez-vous à la machine smarthotelweb2 :
Renseignez le même mot de passe : demo!pass123
Ouvrez la console PowerShell :
Collez votre script en prenant bien soin de remplacer le secret du principal de service par celui donné lors de sa création :
Attendez que le traitement d’intégration se termine :
Retournez sur la page des serveurs d’Azure Arc, rafraîchissez la page si besoin :
Nul besoin de fournir une authentification manuelle d’Azure, ce script est donc destiné à être utilisé pour importer massivement des serveurs sur Azure Arc.
Etape V – Test d’un ajout d’un serveur Linux
Azure Arc supporte également les serveurs fonctionnant sous distribution Linux ,via l’utilisation d’un autre script spécifique. Celui effectue les actions suivantes :
Récupération du script d’installation à partir du Centre de téléchargement Microsoft
Configuration du gestionnaire de packages pour approuver le référentiel
Téléchargement de l’agent à partir du référentiel de logiciels Linux de Microsoft
Installation l’agent sur le serveur
Création de la ressource de serveur sur Azure Arc
Pour continuer, cliquez encore une fois sur la seconde option :
Renseignez à nouveau les champs et le principal de service, puis cliquez sur Suivant :
Renseignez si besoin les étiquettes appropriées, puis cliquez sur Suivant :
Copiez le script dans le presse-papier :
Retournez sur la session d’Azure Bastion. Depuis le serveur Hyper-V, ouvrez directement une console PowerShell et connectez-vous à la machine UbuntuWAF via SSH:
Renseignez le mot de passe : demo!pass123
Collez le script donné par Azure Arc en prenant soin de modifier le secret, puis appuyez sur Entrée pour lancer son exécution :
Laissez la machine redémarrer au besoin :
Une fois le script correctement terminé, vérifiez sur le service Azure Arc l’apparition du serveur Linux :
Etape VI – Test d’un ajout d’un serveur SQL
Une machine virtuelle hébergeant un serveur SQL est également compatible avec Azure Arc et vous permet de le gérer dans votre inventaire. Le processus repose toujours sur le lancement d’un script. Ce dernier effectue les actions suivantes :
Vérification de la connectivité de votre environnement à Azure et à la machine spécifiée
Intégration de la machine hôte via l’agent Azure Connected Machine si absent
Initiation de la découverte d’instances SQL Server
Ajout des instances SQL Server de votre machine cible à Azure Arc
Cliquez comme ceci :
Renseignez les champs, puis cliquez sur Suivant :
Copiez le script dans le presse-papier :
Retournez sur la session d’Azure Bastion, sur la console Hyper-V, ouvrez une connexion vers le serveur smarthotelSQL1 :
Collez le script précédemment donné par Azure Arc et validez avec la touche Entrée :
Authentifiez-vous avec votre compte Azure. Si aucune fenêtre ne s’ouvre, saisissez l’URL dans votre navigateur web et authentifiez-vous avec votre compte Azure:
Cliquez sur Continuez :
Attendez que le script termine l’intégration du serveur SQL sur Azure Arc :
Une fois terminé, retrouvez le serveur SQL dans la liste des serveurs d’Azure Arc :
L’agent WindowsAgent.SqlServer est bien présent dans les extensions du serveur :
Retrouvez aussi le serveur SQL dans la liste ci-dessous d’Azure Arc :
Comme un serveur SQL Azure, cette intégration sur Azure Arc apporte une visibilité des bases de données ou apporte une intégration avec Microsoft Defender for SQL :
Etape VII – Test de fonctionnalités d’Azure Arc
Un grand nombre de fonctionnalités sont disponibles pour faciliter la gestion des serveurs intégrés sur Azure Arc. J’en ai sélectionné quelques-unes pour vous :
Windows Admin Center
Inauguré en 2018, Windows Admin Center est une interface web destinée à la configuration de serveurs, comme le ferait déjà Server Manager, mais à distance.
Voici un poster Microsoft récapitulant les fonctionnalités de Windows Admin Center :
Il est également possible de télécharger Windows Admin Center sur n’importe quelle machine Windows 10 (version 1709 ou ultérieure), ou Windows Server (version 2016 ou ultérieure) :
Dans notre exemple, l’installation de Windows Admin Center est nécessaire avant de pouvoir l’utiliser :
Lancez l’installation de Windows Admin Center :
Attendez plusieurs minutes :
Une fois terminée, la notification suivante apparaît alors :
Retournez sur le groupe des ressources Azure Arc pour y ajouter un rôle RBAC supplémentaire à votre identité Azure AD :
Ajoutez le rôle comme ceci :
Retournez sur Windows Admin Center et constatez la disparition de la notification, puis connectez-vous :
Patientez si besoin plusieurs minutes.
Retrouvez la console Windows Admin Center et toutes ses fonctionnalités, comme :
Accès au registre Windows
Configuration réseau et pare-feu
Accès aux journaux d’évènements Windows
Explorateur de fichiers
Il est même possible d’ouvrir une session RDP depuis Windows Admin Center ????
Renseignez le mot de passe de session : demo!pass123
Defender for Cloud
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 sontdisponibles 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.
L’activation de Defender for Server est facile, cliquez sur un des serveurs Azure Arc, puis rendez-vous dans la section Sécurité et enfin cliquez comme ceci :
Cliquez sur la souscription hébergeant vos ressources Azure Arc :
Activez le plan destiné à Defender for Servers :
Que le serveur soit sous Linux ou Windows, l’installation d’agent est réalisé de la même manière que pour des ressources Azure :
Azure Policy Guest configuration
Comme pour des ressources Azure, Azure Policy prend en charge l’audit de l’état de votre serveur compatible avec Azure Arc grâce aux politiques de configuration des invités. Les définitions de configuration d’invité d’Azure Policy peuvent auditer ou appliquer des paramètres à l’intérieur de la machine.
Il est à noter que ce service est payant pour des ressources non-Azure :
Contrairement à Defender for Cloud où l’activation est possible depuis une souscription Azure pour l’ensemble des ressources de même type, l’activation de cette fonctionnalité doit s’effectuer sur chacun des serveurs Azure Arc :
Cochez les cases voulues :
Les nouvelles polices sont bien visibles, mais en attente de lancement :
Retournez sur l’Hyper-V pour arrêter la machine virtuelle :
Une fois arrêté, redémarrer là :
Attendez un bon quart d’heure pour espérer voir des résultats sur les polices :
Surveillance
Comme pour les ressources Azure, la sauvegarde des logs est aussi disponible. L’activation de Defender for Server Plan 2 automatise sa mise en place et intègre dans le coût 500 Mo journalier pour les logs :
Insights
L’activation de capacités de surveillance supplémentaires permet d’obtenir des informations sur les performances et les dépendances de vos ressources de l’Arc.
Cliquez-ici pour configurer les paramétrages :
Activez le service :
Un Log Analytics Workspace est nécessaire. Choisissez-en un existant ou créez-en un nouveau :
En entendant le déploiement complet, consultez la liste des extensions pour voir apparaître AMA :
AzureMonitorWindowsAgent pour Windows AzureMonitorLinuxAgent pour Linux
Il faut bien attendre un peu pour avoir de la donnée et en tirer des analyses intéressantes.
Microsoft démontre sous ouverture à d’autres environnements via Azure Arc. La centralisation des opérations sur le portail Azure sans tenir compte de la provenance de la ressource IT est une belle avancée car elle facilite la gestion d’infrastructure. Cela permet en plus de pouvoir toujours profiter des derniers services ajoutés par Microsoft.
Configurer la sécurité sur Azure en seulement 10 minutes ? Et pourquoi pas en 9 minutes ? Cette course au temps ne veut rien dire ! La sécurité est une tâche constante, et passe presque toujours par différentes phases, comme la découverte, l’analyse et la configuration. Néanmoins, une approche directe est malgré tout possible sur certains éléments élémentaires de sécurité.
Microsoft le rappelle très régulièrement, le premier risque identifié provient d’identités mal sécurisées :
Chaque jour, plus de 300 millions de tentatives de connexion frauduleuses à nos services Cloud sont enregistrées. Les cyberattaques ne ralentissent pas, et il convient de noter que de nombreuses attaques ont réussi sans l’utilisation de technologies avancées. Il suffit d’une seule d’identité compromise… pour provoquer une violation de données. Cela montre à quel point il est essentiel de garantir la sécurité des mots de passe et une authentification forte.
Déjà par lire mon article sur la sécurité, accessible juste ici ????. Plus sérieusement, commencer par assimiler quelques notions, comme la défense en profondeur ou le Zéro Trust.
Principe de sécurité en couche
Comme un oignon, chaque couche de sécurité apporte des mesures, passives ou actives, empêchant ou retardant l’accès à la donnée, élément critique de toute entreprise :
Qu’est-ce que TD SYNNEX peut faire pour ma sécurité ?
Travaillant chez TD SYNNEX depuis plusieurs années, j’accompagne des partenaires IT dans la conception d’architecture sur Azure. La collaboration entre Microsoft et TD SYNNEX est très forte, nous distribuons tous les produits Cloud de Microsoft via une marketplace.
Disposant de compétences techniques en interne, nous développons aussi nos propres solutions pour faciliter et automatiser toujours plus la mise en place de solutions innovantes sur Azure.
Concernant la sécurité, TD SYNNEX n’est pas en reste et propose une nouvelle solution appelée SMB Fraud Défense. Il s’agit d’une solution, dite Click-to-Run, donc prête à l’emploi : quelques clics suffisent pour mettre en place la solution sur un tenant Azure.
Que fait exactement la solution SMB Fraud Defense ?
Voyez un tenant Microsoft comme une maison : les identités et les périphériques sont les portes et les fenêtres. Il est donc évident que ces points des entrées à la donnée :
Des mesures de sécurité sont nécessaires protéger la donnée. Voici une liste non exhaustive des fonctionnalités facilement activables depuis SMB Fraud Defense :
Protection des identités Azure AD :
Création de scénarios d’accès conditionnel avec MFA
Restriction géographique par pays
Blocage d’anciens protocoles d’authentification
Gestion de l’expiration des mots de passe
Verrouillage des identités intelligent
Protection des ressources Azure :
Mise en place de budgets et notifications
Restrictions géographiques
Restrictions de familles de machines virtuelles
Combien coûte SMB Fraud Defense ?
Rien du tout ????, aucun frais à prévoir du côté de TD SYNNEX ou de Microsoft.
Comment procède-t-on pour déployer SMB Fraud Defense ?
Quelques étapes sont nécessaires et sont décrites dans les lignes de cet article, rien de plus.
Etape 0 – Rappel des prérequis :
Avant tout, le déploiement d’une solution Click-to-Run nécessite la mise en place d’un partenariat entre un vous et TD SYNNEX. En effet, ces solutions ne sont disponibles à l’achat qu’uniquement depuis notre Marketplace. Pour cela, cliquez ici.
Le second prérequis est de disposer d’un tenant Azure et d’une souscription Azure Plan acheté via la Marketplace de TD SYNNEX.
Etape I – Achat de la solution Click-to-Run SMB Fraud Defense :
Comme indiqué plus haut, SMB Fraud Defense est gratuit mais demande malgré tout par un provisionnement par depuis la Marketplace de TD SYNNEX.
Une fois votre Azure Plan en place, cliquez sur Modifier :
Parcourez la liste des solutions Click-to-Run disponibles à l’installation, et cliquez sur Acheter SMB Fraud Defense :
Note : La mise en place de la solution vous alerte sur l’incompatibilité avec des solutions MFA externe à Azure
Une fois que vous avez accepté ce message, la plate-forme vérifie la bonne configuration initiale du tenant :
Etape II – Déploiement de la solution Click-to-Run SMB Fraud Defense :
Juste avant de déployer SMB Fraud Defense, il est nécessaire de préparer 3 conditions sur le tenant cible, car la solution analyse les 3 points suivants :
Paramètre de sécurité par défaut d’Azure
Gestionnaire de coûts Azure
Souscription d’une licence Azure AD Premium (Plan 1 ou Plan 2)
Voici un détail point par point pour réussir la préparation et leur statut attendu :
Paramètre de sécurité par défaut d’Azure – désactivé :
La mise en place d’une sécurité personnalisée nécessite la désactivation de la sécurité par défaut d’Azure. Voici ce que cette dernière contient.
Sa désactivation est donc possible via ce menu :
Mais elle est aussi désactivable via le portail d’Azure AD :
Désactivez alors celle-ci en spécifiant un motif justifiant l’opération :
Gestionnaire de coûts Azure – Activé :
La mise en place de budget et d’alerte sur la consommation Azure nécessite l’activation du gestionnaire de coûts Azure.
En effet, la mise en place d’une souscription Azure Plan via un partenaire CSP ne l’active pas par défaut. Il est donc nécessaire de vous rapprocher de votre fournisseur CSP pour l’activation du Gestionnaire de coûts.
Souscription d’une licence Azure AD Premium Plan 1 ou Plan 2 – Souscrite :
La mise en place de l’accès conditionnel sur Azure AD nécessite de disposer d’une licence Azure AD Premium Plan 1 ou Plan 2 :
Pour un déploiement optimal, il est conseillé d’en disposer pour profiter de l’ensemble des avancées de SMB Fraud Defense, comme l’accès conditionnel avec prise en compte de l’évaluation du risque à la connexion.
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.
Une fois ces 3 points corrects sur votre environnement, vous pouvez commencer la configuration sur chacun des onglets :
Etape III – Configuration de la solution Click-to-Run SMB Fraud Defense :
Cette configuration est divisée en 5 onglets :
Localisation
Budget
Accès conditionnel
Méthodes d’authentification
Polices
Note : cliquez sur Déployer à la fin, une fois seulement tous les onglets configurés.
A / Localisation
Des informations sont nécessaires pour le bon déploiement des polices Azure. Pour cela, choisissez une région Azure dans le menu déroulant et spécifiez le nom d’un groupe de ressources :
B/ Budget
La mise en place d’un budget est une bonne approche pour suivre la consommation Azure en fonction de l’estimation faite au début du projet :
La mise en place d’alertes l’est tout autant pour éviter les dépassements et donc les factures salées :
Vous pouvez indiquer plusieurs adresses emails pour les notifications.
C/ Accès conditionnel
La gestion identitaire d’Azure passe par Azure Active Directory (Azure AD). La sécurisation d’environnement Azure passe donc avant tout par celui-ci.
Vous pouvez contrôler l’accès à vos applications cloud basées sur l’emplacement réseau d’un utilisateur. La condition d’emplacement est couramment utilisée pour bloquer l’accès à partir des pays/régions d’où votre organisation sait que le trafic ne doit pas provenir :
La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Azure AD impose de mettre en place les 3 méthodes d’authentification suivantes :
Un élément que vous connaissez (ex. mot de passe)
Un élément que vous possédez (ex. un appareil de confiance, comme un smartphone)
Un élément qui vous définit : (ex. identifiant biométrique, tel qu’une empreinte digitale)
Les périphériques et les applications accédant à vos données se doivent d’être protégés.
Il est toujours utile de joindre les périphériques à Azure AD. Comme pour un Active Directory, la connaissance de ces derniers apporte une meilleure maitrise de la sécurité lors de la création de règles de sécurité :
N’ayant pas de poste joint à Azure AD sur cet environnement de démo, je n’active donc pas ces 2 options dans la configuration.
D/ Méthodes d’authentification
Toujours sur la protection des identités, certaines options supplémentaires sont encore configurables :
Le verrouillage intelligent empêche les attaquants de pénétrer dans le système, tout en permettant à vos utilisateurs d’accéder à leur compte et de travailler :
Le déploiement local de Protection de mots de passe d’Azure AD utilise les mêmes listes globales et personnalisées de mots de passe interdits qui sont stockées dans Azure AD, et effectue les mêmes vérifications des modifications de mot de passe localement :
Comme annoncé avant, la validation en deux étapes permet de renforcer la sécurité de votre compte Microsoft en exigeant une deuxième étape de validation lorsque vous vous connectez.
En plus de votre mot de passe, vous pouvez générer un code par l’application Microsoft Authenticator sur votre téléphone :
Autrement, le standard de sécurité FIDO2 répond à ce problème en s’appuyant là aussi sur une authentification à deux facteurs basés sur l’utilisation de clés de sécurité (clés FIDO2) et de tokens (jetons d’authentification) :
E/ Polices
Les polices d’Azure sont un moyen de contrôler les déploiements des ressources. La solution SMB Fraud Defense vous propose de restreindre les SKUs de familles de machines virtuelles. Cela bloque alors les SKUs les plus coûteux :
Azure offre à ses clients la flexibilité de déployer des applications là où ils en ont besoin. Une région Azure a une tarification et une disponibilité de service distinctes.
Ici, Il est vous possible de restreindre le déploiement sur certaines régions Azure, mais aussi d’activer d’autres fonctionnalités de sécurité :
Tous les onglets ont maintenant été passés en revue, il ne vous reste qu’à déployer la configuration.
Etape IV – Déploiement de la solution Click-to-Run SMB Fraud Defense :
Pour cela, cliquez ici pour lancer le déploiement et attendez quelques minutes :
Une fois le déploiement terminé, un email de notification est également envoyé, et le status de la solution C2R change :
Etape V – Contrôle du déploiement sur le tenant :
Le déploiement est maintenant terminé, une vérification sur le tenant permet de s’assurer la présence de toutes les options choisies durant la phase de la configuration.
A / Localisation
Consultez votre portail Azure et vérifiez la présence du groupe de ressources sur votre souscription Azure Plan :
B/ Budget
Toujours sur la souscription Azure, contrôler l’ajout du budget reprenant le montant configuré :
Cliquez dessus et éditez le pour vérifier la présence des 2 alertes :
C/ Accès conditionnel
La configuration de la restriction géographique s’effectue depuis le portail Azure AD. Consultez la sécurité pour voir l’apparition du pays sélectionné dans les zones de confiance :
Toujours dans Azure AD, chaque option activée a généré la création d’une ou plusieurs polices d’accès conditionnel, toujours en mode audit au moment du déploiement :
D/ Méthodes d’authentification
Le contrôle de la désactivation de l’expiration du mot de passe se fait via le portail Microsoft 365 :
Quant à lui, le contrôle du seuil de verrouillage du compte se fait via le portail Azure AD :
La configuration des deux méthodes MFA d’authentification se retrouve juste ici :
E/ Polices
Du côté d’Azure, contrôlez les polices déployées :
Un clic sur une police affiche le détail de la configuration, comme la région autorisée ou les SKUs interdits :
Conclusion
Alors, finalement nous ne sommes pas si loin des 10 minutes ???? ?
Plus sérieusement, je trouve que ce type de solution est une bonne approche quand on voit l’éparpillement des principales mesures de sécurité, qui sont maintenant indispensables pour sécuriser au minimum un tenant Microsoft.
SMB Fraud Defense de TD SYNNEX doit être perçue comme un point de départ à une configuration sécuritaire, et facile son automatisation lors de la création de tenants.
Enfin, il faut garder en tête que ce type de solution Click-to-Run évolue sans cesse chez TD SYNNEX, grâce aux feedbacks et aux évolutions du Cloud Microsoft ????
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.
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 uniquement
Office 365
Azure AD Premium P1
Azure 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égie
Paramètres de sécurité par défaut
Accès conditionnel
Authentification 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 :
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.
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 ????
Azure Virtual Desktop continue encore d’évoluer et s’associe maintenant avec un autre service réseau du cloud Microsoft : Azure Private Link. En ce début du mois de novembre, Microsoft vient de l’ouvrir en préversion publique pour tester cette fonctionnalité. L’idée est donc de sécuriser d’avantage, par une restriction encore plus poussée, l’accès au service Azure Virtual Desktop.
Pourquoi restreindre un service Cloud ?
Pour répondre à une demande provenant de certaines entreprises. Beaucoup d’entre-elles ont même des exigences légales et ne souhaitent donc pas faire passer un flux réseau à travers internet, quand bien même il s’agirait de communications en HTTPS.
Il paraissait donc important que Microsoft propose ce type de fonctionnalité pour permettre à au service à Azure Virtual Desktop d’être 100% en dehors du web.
Pour parvenir à la mise en place de cette fonctionnalité, Microsoft met déjà à disposition plusieurs documentations, disponibles uniquement en anglais pour l’instant :
En deux mot, Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple du stockage Azure, compte le compte de stockage ou encore une base de données SQL) depuis votre réseau virtuel :
Voici une vidéo qui aborde le sujet dans son entièreté :
Comment va fonctionner Azure Virtual Desktop avec Private Link ?
Comme pour les autres services proposant cette association, le trafic entre le réseau virtuel et Azure Virtual Desktop transitera par le réseau « dorsal » de Microsoft, ce qui signifie que vous n’aurez plus besoin d’exposer votre AVD à l’Internet.
En termes de sécurité, transiter son trafic dans le réseau « connu » et sécurisé de Microsoft renforcera toujours un peu plus la protection de vos données.
A quel moment intervient le Private Link dans le chemin de connexion entre l’utilisateur et AVD ?
Il peut intervenir à plusieurs niveaux. En effet, la connexion est décomposée en différentes étapes et avec plusieurs composants. Il est alors possible de choisir quelles connexions ont le droit ou non de transiter par internet.
C’est d’ailleurs pour cela que plusieurs options sont présentes dans la configuration réseau d’AVD :
La première option se charge d’autoriser ou non l’accès au service AVD des utilisateurs depuis internet. Autrement la partie frontale de la connexion AVD.
La seconde option se charge d’autoriser ou non l’accès au service AVD des machines virtuelles AVD depuis internet. Autrement la partie arrière-plan de la connexion AVD.
Peut-on utiliser à la fois les fonctionnalités Private Link et RDP Shortpath ?
Durant cette phase de préversion, cela n’est pas possible. Pour rappel RDP Shortpath est une méthode habile d’Azure Virtual Desktop qui établit un transport direct basé sur le protocole UDP entre le client Remote Desktop et l’hôte de session. Tout y est expliqué ici.
Etape 0 – Rappel des prérequis
Pour arriver à la démonstration de l’association entre Azure Virtual Desktop et Private Link, je dispose d’un environnement comprenant des composants déjà en place :
Poste Windows 10 avec Azure VPN
Environnement AVD avec jointure Azure AD
On retrouve ainsi mon premier réseau virtuel comprenant :
La machine virtuelle faisant office de poste utilisateur distant sous Windows 10
Le service Azure Bastion pour m’y connecter plus facilement
J’ai également déployé un second réseau virtuel. Celui-ci comprend
Mon environnement Azure Virtual Desktop
Une passerelle VPN pour assurer la connection entre le poste Windows 10 et AVD
La connexion VPN Point à Site est bien fonctionnelle :
L’accès direct à une des machines virtuelles AVD répond bien.
Comme vous pouvez le voir sur la configuration d’Azure Virtual Desktop, une nouvelle section dédiée au réseau a fait son apparition :
Avant d’aller plus loin, il est donc nécessaire d’activer la fonctionnalité, encore en préversion à l’heure où ces lignes sont écrites.
Etape I – Activation de la fonction de préversion d’Azure Private Link
Comme beaucoup de fonctionnalités encore en préversion, il est nécessaire de l’activer depuis le portail Azure. Pour cela, effectuer l’opération suivante via ce lien :
N’oubliez pas de sélectionner la bonne souscription Azure.
Une fois enregistrée, attendez environ 15 minutes.
Retournez sur la section réseau de votre Azure Virtual Desktop pour constater le déblocage des fonctionnalités réseaux :
Dans cette configuration par défaut, avec les 2 cases de cochées, la connexion réseau transite via internet dans sa totalité :
Entre le client et le service Azure Virtual Desktop
Entre le service Azure Virtual Desktop et les machines virtuelles AVD
Un test, avec le VPN désactivé, montre que la connexion se fait toujours via internet :
Etape II – Restreindre la communication entre le service AVD et le pool d’hôtes au réseau virtuelAzure
La première étape consiste donc à restreindre la communication entre le service Azure Virtual Desktop et les machines virtuelles AVD au réseau virtuel. Pour cela décochez la case suivante et sauvegardez :
Un nouvel essai de connexion utilisateur vous montre le blocage immédiat de cette méthode en passant par internet :
Comme dit plus haut, l’utilisateur n’en est pas responsable : Le service Azure Virtual Desktop est incapable de communique avec la machine virtuelle AVD.
Pour arriver rétablir l’accès au service AVD, nous avons besoin de créer un premier private endpoint en cliquant sur le second onglet de la section réseau :
Pour réactiver les connexions, vous devrez créer un private endpoint pour chaque pool d’hôtes AVD que vous souhaitez autoriser.
Donnez-lui un nom, puis passez à l’onglet suivant :
Laissez cet onglet comme ceci avec le type connexion et passez sur le suivant.
Pour information, il existe différents types de sous-resource cible, ils auront une importance et seront utilisés par la suite :
Type de resource
Type de sous-resource
Quantité
Microsoft.DesktopVirtualization/workspaces
global
Un pour tous les déploiements Azure Virtual Desktop
Microsoft.DesktopVirtualization/workspaces
feed
Un par workspace
Microsoft.DesktopVirtualization/hostpools
connection
Un par pool d’hôtes
Renseignez le réseau / sous réseau de votre environnement Azure Virtual Desktop :
Pour votre information, plusieurs adresses IP privées seront alors allouées pour les services suivants :
Sur l’onglet suivant, une zone DNS privée va être créé pour le private endpoint :
Lancez la création puis attendez :
Une fois créé, la carte réseau du private endpoint nouvellement créé vous montre que chaque service dispose bien d’une adresse IP dédiée :
Important : Pour les gros environnement AVD, prévoir un second sous-réseau pour éviter un souci d’adressage.
Un redémarrage de machines virtuelles AVD plus tard : la connexion AVD depuis le poste client refonctionne sans souci :
Veuillez noter que la copie d’écran ci-dessus montre bien que le VPN d’Azure est toujours déconnecté. Cela montre bien que nous n’avons pas encore influencé la partie frontale du service AVD.
Pour bien comprendre ce qui s’est passé, un test intéressant est de
Créer un groupe de sécurité réseau (NSG)
Y ajouter une restriction d’accès au service publique d’Azure Virtual Desktop
L’associer au sous-réseau contenant les machines virtuelles AVD
Ce test créé une contrainte qui n’empêche pas notre test de fonctionner, car la connexion entre le service Azure Virtual Desktop et les machines AVD transite par le private endpoint nouvellement créé.
J’ai également fait un autre test de retirer le private endpoint. Les machines virtuelles AVD apparaissent alors bien comme étant injoignables pour le service Azure Virtual Desktop :
Maintenant, la seconde étape est de restreindre également l’accès au service Azure Virtual pour les postes connectés uniquement à internet.
Etape IIIa – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel
La première étape consiste donc à restreindre la communication entre le service AVD et les utilisateurs via internet. Pour cela, décochez la case suivante et sauvegardez :
Un nouvel essai de connexion à AVD nous montre le blocage immédiat de cette méthode en passant par internet :
Un rafraichissement de l’espace de travail AVD montre maintenant un refus d’affichage de celui-ci :
Pour terminer la configuration, nous avons besoin de créer deux autres private endpoints.
Pour cela, allez sur l’espace de travail AVD, allez dans la section réseau, décochez la case et sauvegardez :
Comme précédemment, commencez par créer un private endpoint comme ceci :
Nommez-le différemment du premier private endpoint créé durant l’étape précédente :
Choisissez cette fois-ci la sous-resource cible de type Feed :
Renseignez le réseau / sous réseau où votre environnement Azure Virtual Desktop :
Là encore, des adresses IP privées seront allouées pour les services suivants :
Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le second private endpoint, rattaché à votre espace de travail :
Lancez la création puis attendez :
Une fois créé, retournez sur la page d’Azure Virtual Desktop pour créer le troisième private endpoint de type Global.
Etape IIIb – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel
Microsoft conseille d’isoler ce private endpoint sur un espace de travail dédié au réseau. En effet, ce private endpoint unique de type Global pourrait service servir à tous les réseaux virtuels appairés.
Pour cela, créez un nouvel espace de travail AVD :
Nommez-le et lancez sa création :
Une fois créé, retournez-y, décochez là encore l’option réseau, puis sauvegardez.
Créez ici le troisième private endpoint et remplissez le premier onglet comme les 2 précédentes fois :
Choisissez le type de sous-resource cible Global :
Choisissez un réseau en relation directe avec votre environnement AVD :
Pour information, une adresse IP privée sera là-encore allouée pour le service suivant :
Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le troisième private endpoint, rattaché à ce nouvel espace de travail :
Lancez la création puis attendez :
Etape IV : Configuration du réseau on-premise
Pour que la connexion restreinte à Azure Virtual Desktop fonctionne bien, il est nécessaire d’apporter les enregistrements DNS créés précédemment sur le réseau on-premise.
Comme mon réseau on-premise est virtuellement créé sur Azure, j’ai choisi de créer une seconde zone DNS privée avec le même nom et de la rattacher à mon réseau on-premise :
Reprenez tous les enregistrements présents dans la zone DNS créée par les private endpoints.
Si comme moi votre réseau on-premise est dans Azure, associez cette zone DNS privée à celui-ci.
Etape V : Test de la connexion via Azure VPN Point à Site
Sur le poste on-premise de test, effectuez un premier test de connexion à l’URL d’Azure Virtual Desktop tout en ayant la connexion VPN de stoppée :
Constatez avant tout que la page n’est dorénavant plus joignable :
Démarrez votre connexion VPN grâce au client Azure VPN :
Recharger la page web du service Azure Virtual Desktop et renseignez vos identifiants de l’utilisateur de test :
Cliquez sur l’icône de bureau à distance :
Renseignez une seconde fois son mot de passe :
Et vus voilà dans votre session AVD !
Un test de déconnexion de la connexion VPN affectera immédiatement la session utilisateur d’AVD :
Réactiver la connexion VPN pour retrouver la session AVD.
Etape VI : Résumé des ressources Azure créées
Afin d’apporter plus de clarté à toutes ces opérations de déploiement, voici un récapitulatif du travail effectué dans cet article sur mon environnement Azure :
3 private endpoints :
3 cartes réseaux :
2 zones DNS privées :
1 second espace de travail AVD :
Etape VI : Aide à la résolution
Si l’installation s’est déroulée sans accro, mais que vous n’arrivez toujours pas à vous reconnecter à votre environnement Azure Virtual Desktop, voici quelques pistes qui peuvent vous aider :
Absence du premier private endpoint sur le pool d’hôtes AVD.
Connexion VPN non démarrée.
Authentification correcte, mais absence d’enregistrements DNS www, rdweb et client sur le réseau on-premise.
Authentification correcte, mais absence d’enregistrements DNS .rdweb sur le réseau on-premise.
Authentification correcte, mais absence d’enregistrements DNS gateway sur le réseau on-premise.
Conclusion
Par cette nouvelle fonctionnalité, Microsoft apporte encore plus de liberté dans la manière d’utiliser son environnement AVD, avec toujours plus d’exigences de sécurité. La possibilité de restreindre le service AVD à différents types de connexions sécurisées, comme les VPNs ou encore Azure ExpressRoute était attendue depuis longtemps.
Comme toujours, Dean de l’Azure Academy a préparé une vidéo très explicative de la mise en route ????
Une nouvelle certification dédiée à la sécurité du Cloud Microsoft a fait son apparition il y a déjà quelques mois. Contrairement aux autres certifications dédiées au même sujet de niveau intermédiaire, celle-ci est de niveau expert. Elle ne se focalise par uniquement sur un pan sécuritaire spécifique du Cloud Microsoft, que ce soit Azure, Azure AD ou Microsoft 365.
Microsoft est d’ailleurs assez clair dans la description de ce que l’on peut attendre d’un Architecte en cybersécurité :
L’architecte de cybersécurité collabore continuellement avec les dirigeants et les professionnels en matière de sécurité informatique et de confidentialité, ainsi que d’autres rôles organisationnels, afin de planifier et d’implémenter une stratégie de cybersécurité répondant aux besoins d’une organisation.
Comment comprendre le niveau Expert chez Microsoft ?
Je persiste à dire que les certifications de niveau Expert ont une utilité dans la connaissance macro du cloud Microsoft. Aucune volonté de réapprendre les fondamentaux de tel ou te service de sécurité, de leur fonctionnement précis, mais bien de comment les intégrer dans une stratégie sécuritaire globale de l’entreprise.
Il vous faut donc percevoir cette certification de la même manière que celles dédiées aux Architectes Azure ou aux Administrateurs Expert 365. N’en doutez-pas, les gammes de produits disponibles chez les acteurs majeurs du cloud publics sont tellement gigantesques que des rôles se sont nécessaire pour maîtriser cette vue d’ensemble et coordonner le tout.
Comment obtenir cette certification ?
Comme toutes les autres certifications de niveau expert, la certification ne s’obtient pas qu’avec un seul examen. Un examen de niveau associé est nécessaire pour obtenir le précieux badge.
En plus de l’examen SC-100, il vous faudra obtenir un des examens suivants :
Aucune nécessité de programmer le passage d’examen dans un ordre précis.
Quels sont les sujets abordés dans cette certification ?
Microsoft continue toujours de lister les compétences mesurées depuis la page d’examen :
Concevoir une stratégie et une architecture zéro confiance (30-35 %)
Évaluer les stratégies techniques et les stratégies d’opérations de sécurité de gouvernance des risques (20-25 %)
Concevoir la sécurité pour l’infrastructure (20-25%)
Concevoir une stratégie de données et d’applications (20-25 %)
Le fichier PDF lui aussi disponible sur cette même page reprend toujours en détail ces pourcentages de chaque module.
Il a changé depuis peu et intègre maintenant tous les liens utiles à la préparation de l’examen. De plus il vous détaille aussi les prochains changements opérés par Microsoft sur cet examen, pour vous permettre d’appréhender au mieux sa future mise à jour.
Comment préparer cette certification ?
Depuis peu, Learn est maintenant au centre de l’offre d’apprentissage proposé par Microsoft, que ce soit pour la documentation en libre accès ou pour les cours officiels dispensés par un MCT (Microsoft Certified Trainer) :
Cette mise à disposition complète et gratuite de contenus d’apprentissage est donc aussi valable pour la préparation de certifications Microsoft, via la mise en place de collections accessibles à tous :
L’authentification sur Learn est conseillé car elle vous permet alors de suivre votre progression d’apprentissage, et même d’accumuler des badges de succès obtenus après la lecture complète de modules :
Des contrôles de connaissances sont régulièrement intégrés en fin de module pour vous aider à valider votre compréhension :
Quoi d’autres ?
Des contenus adaptés à cet examen sont aussi disponibles sur des sources externes, comme sur ce blog ???? :
Comme toujours, une autre source me sert et m’informe sur Azure toutes les semaines : YouTube. John Savill reste pour moi une valeur sûre sur le fond et sur la forme. Il suffit de voir le temps passé sur cet examen sur cette vidéo :
John en a même fait une playlist YouTube pour rentrer en détail dans chacun des sujets ????.
Microsoft Learn Cloud Skills Challenge3
Petit rappel : comme à chaque Ignite, Microsoft vous propose de passer de petits challenges techniques. Ces challenges sont un moyen facile d’obtenir des connaissances techniques mais également des vouchers pour des certifications Microsoft. Tout cela gratuitement !
Ne tardez pas pour vous en occuper avant le 09 novembre !
0
Years
:
0
Months
:
0
J
:
0
H
:
0
M
:
0
S
Conclusion
Au final, et comme dit précédemment, le passage de cet examen m’a fait penser aux autres certifications de niveau expert. La majorité des questions ont concerné des connaissances précises sur la sécurité, sans en attendre un côté incollable. L’important est d’en avoir une vue d’ensemble sur les capacités générales pour faire face à différentes exigences de sécurité.
Comme vous le savez déjà, ce type de certification Microsoft doit être renouvelée tous les ans pour conserver sa validité. Ce cycle de re certification est pour moi une excellente approche pour se tenir informé des nouvelles menaces et mesures de sécurité disponibles sur le marché.
Je souhaitais faire cet article depuis quelques temps déjà. Comme pour les autres services disponibles sur le Cloud Microsoft, Azure Virtual Desktop nécessite une sécurité renforcée. Hors de question de laisser un accès ouvert aux applications de l’entreprise avec un simple identifiant / mot de passe.
Dans cet article, nous allons commencer par reprendre quelques bases sur l’accès conditionnel disponible sur Azure AD. Puis nous allons le mettre en oeuvre dans un environnement Azure Virtual Desktop.
Qu’est-ce que l’Accès Conditionnel proposé par Azure AD ?
Tous les environnements informatiques sont quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers d’un hébergeur Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations à gérer pour la sécurité IT.
Le périmètre de sécurité moderne s’étend désormais au-delà du réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations peuvent utiliser des signaux d’identité dans le cadre de leurs décisions de contrôle d’accès.
Pour cela, Microsoft propose d’intégrer dans le processus d’authentification à Azure AD de nouvelles étapes, sous forme de police :
Le schéma ci-dessus est une vue simplifiée des 3 étapes du processus d’accès conditionnel.
Signal : pour Azure AD, l’accès conditionnel repose sur un certain nombre de signaux ou paramètres. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :
Emplacement (adresse IP)
Appareil (OS, version, conformité, …)
Utilisateur Azure AD
Application interrogée
IA (Détection des risques en temps réel par Azure AD Identity Protection)
Décision : la décision sera alors le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est question ici de bloquer l’accès à l’utilisateur, ou de l’autoriser selon les conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :
Exiger une authentification multifacteur (cas plus utilisé)
Exiger que l’appareil soit marqué comme conforme
Exiger un appareil joint en hybride à Azure AD
Exiger une stratégie de protection des applications
Application : apporte une supervision des sessions et des accès utilisateur aux applications en fonction des stratégies d’accès et de session, telles que :
Empêcher l’exfiltration des données
Protéger lors du téléchargement
Empêcher le chargement de fichiers sans label
Bloquer les programmes malveillants potentiels
Surveiller les sessions utilisateur pour la conformité
Bloquer l’accès
Quelles sont les licences nécessaires pour l’accès conditionnel d’Azure AD ?
L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Azure AD Premium P1. Cela est donc bien différent des offres disponibles pour disposer de l’authentification multifacteur (Challenge MFA).
Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :
Azure AD Premium P1
Azure AD Premium P2
Enterprise Mobility + Security E3
Enterprise Mobility + Security E5
Microsoft 365 Business Premium
Microsoft 365 A3
Microsoft 365 A5
Microsoft 365 F1
Microsoft 365 F3
Microsoft 365 F5 Security
Microsoft 365 F5 Security + Compliance
Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?
Cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :
Certains services clients ne sont actuellement pas capables de limiter les avantages à des utilisateurs spécifiques. Des efforts doivent être déployés pour limiter les avantages du service aux utilisateurs sous licence.
Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.
Voici un autre tenant Azure ne disposant d’aucune licence.
Comment l’accès conditionnel est vécu par un utilisateur ?
Une fois l’accès conditionnel mis en place via une police, la sécurité est immédiatement renforcée par l’application de celle-ci. L’image ci-dessous montre en exemple une authentification multifacteur déployée par ce mécanisme pour protéger le portail Azure :
L’accès au portail Azure est conditionné à une authentification multifacteur pour cet utilisateur : challenge MFA.
L’absence de réponse entraîne alors un blocage dans le processus d’authentification et donc de l’accès au portail Azure pour l’utilisateur :
En alternative, si l’utilisateur ne peut pas utiliser cette méthode, Il lui est malgré tout possible de continuer le processus d’authentification par une autre mesure disponible dans la double authentification :
Les réussites ou les échecs des connexions d’utilisateurs sont directement visibles dans le journal des connexions de l’utilisateur sur Azure AD :
Un clic sur une authentification affiche alors les détails et l’application de la police utilisée :
Essai I : Absence de règle d’accès conditionnel
Le premier essai que nous allons faire repose sur aucune configuration particulière.
L’accès au service Azure Virtual Desktop se fait en HTML 5 via l’URL officielle. L’accès conditionnel marcherait également avec les applications installées sur le poste en local, comme le client Remote Desktop, disponible ici au téléchargement.
Aucun blocage ni contrainte pour l’utilisateur n’est constaté :
La sécurité y est donc minimale et l’obtention du login et du mot de passe par un tier permet de se connecter à son environnement et d’accéder aux données.
Essai II : Mise en place d’une règle de blocage total
Le second essai nécessite la création d’une police d’accès conditionnel. Connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :
Ouvrez le menu de la Sécurité :
Rentrez dans la section d’Accès conditionnel :
Créez votre nouvelle Police :
Saisissez un nom à votre police et sélectionnez votre utilisateur de test :
Cherchez l’application Azure Virtual Desktop dans la section suivante :
Définissez la décision sur Bloquer l’accès :
Activez votre police et validez sa création :
Attendez quelques minutes et retester l’accès à Azure Virtual Desktop sur votre utilisateur. Pour information, l’accès conditionnel d’Azure AD dispose d’une fonction Et Si pour tester vos règles avant de les appliquer :
Quelques minutes plus tard, le test de connexion nous montre que blocage est bien effectif pour cet utilisateur :
Les conditions d’authentification sont bien réunies, mais ici l’utilisateur n’a tout simplement par le droit de se connecter à AVD.
Essai III : Mise en place d’une règle pour exiger la MFA
Retournez sur votre accès conditionnel et cliquez sur votre police pour la modifier :
Modifiez la décision pour autoriser l’accès à Azure Virtual Desktop, sous réserve d’un succès au challenge MFA par votre utilisateur de test :
Retentez la connexion à Azure Virtual Desktop avec votre utilisateur de test. La modification MFA de la police est bien prise en compte ici :
Dans mon cas, l’utilisateur est alors invité à enregistrer une ou des méthodes pour le challenge MFA pour poursuivre cette nouvelle opération d’authentification. L’application Microsoft Authenticator est proposée en tant que première méthode du challenge à configurer :
Il est possible de choisir une autre méthode.
La méthode MFA choisie est immédiatement vérifiée pour éviter un blocage ultérieur :
Essai IV : Mise en place d’une règle pour bloquer la connexion autre qu’au bureau
La restriction ou le blocage d’un service comme Azure Virtual Desktop est possible selon la localisation de l’utilisateur par son adresse IP. Retournez sur votre police pour la modifier comme ceci :
Pensez à créer votre location de confiance, en reprenant votrepropre IP publique :
Retentez la connexion de votre utilisateur à AVD et constatez l’absence de blocage ou de challenge MFA :
Un contrôle dans le journal des connexions nous montre bien le processus d’exclusion de la police d’accès conditionnel grâce à mon adresse IP publique, exclue :
Essai V : Mise en place d’une règle pour exiger le challenge MFA toutes les heures
La mémorisation constante du challenge MFA sur une poste peut être considérée comme un risque sécuritaire, spécialement si le poste est en accès libre pour différents utilisateurs.
Retournez sur votre police pour la modifier comme ceci :
Effectuez l’authentification de votre utilisateur et réussissez le challenge MFA :
Validez la présence des icônes et attendez une heure. Une heure plus tard, rafraîchissez votre AVD :
Une MFA est bien redemandée après le délai défini dans la police d’accès conditionnel.
Conclusion :
Grâce à l’accès conditionnel d’Azure AD, il est assez facile de renforcer la sécurité d’Azure Virtual Desktop. Comme toujours, Microsoft rappelle les risques encourus à seulement utiliser un login et mot de passe pour seule sécurité. L’excellente vidéo de Dean nous montre cela en détail :
En espérant que cela a pu vous aider à mieux sécuriser votre environnement Cloud ????
