Après ces quelques chaudes semaines d’été, il est pour nous l’occasion de nous replonger dans Azure Virtual Desktop et ses dernières nouveautés. Comme vous le savez peut-être, AVD repose sur une authentification d’Azure AD, potentiellement combinée avec un Active Directory classique. Cette méthode apporte une couche de sécurité dans l’accès au service grâce aux mesures de protections disponibles sur Azure AD.
Dans cet article, nous allons nous intéresser au Single Sign-on, ou Authentification Unique, dans Azure Virtual Desktop à travers une première méthode de gestion des identités Cloud : Azure AD. Enfin, nous finirons ce billet par un rapide troubleshooting concernant cette évolution, encore en préversion à l’heure où les lignes de cet article sont écrites.
L’authentification unique, souvent désignée par le sigle anglais SSO est une méthode permettant à un utilisateur d’accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentification.
Afin de bien comprendre l’évolution du SSO dans Azure Virtual Desktop, l’authentification utilisateur s’effectue en deux étapes. Voici un rappel du processus depuis le client Windows Remote Desktop utilisé pour AVD, disponible ici :
Première authentification Azure AD (ou serveur AD FS si besoin) :
Seconde authentification pour l’ouverture de la session Windows :
La mémorisation du mot de passe de session Windows est bien disponible via la case à cocher ci-dessous, mais elle pose un souci de sécurité. Il ne s’agit pas ici de SSO mais d’un classique stockage de mot de passe en local. En effet, le mot de passe sera alors sauvegardé sur le Credential Manager de Windows :
Sur un ordinateur partagé, cela rendrait simplement l’accès à Azure Virtual Desktop ouvert à tous !
Microsoft travaille depuis déjà pas mal de temps sur du SSO pour Azure Virtual Desktop. L’excellente vidéo ci-dessous faite il y a quelques mois par Dean Cefola de l’Azure Academy nous montre son processus de mise en place, mais uniquement si l’infrastructure dispose d’un Active Directory avec un serveur AD FS :
Comment faire du SSO sans serveur AD FS ?
C’est dans ce cas précis que la nouveauté de Microsoft intervient ! Une nouvelle option RDP vient de se faire son apparition sur Azure Virtual Desktop. Cette option apporte le SSO de manière 100% native. Petit rappel toujours utile, voici la liste des propriétés RDP acceptées par AVD.
Comme pour presque tous les articles de ce blog, nous allons détailler le processus de mise en place de cette nouvelle fonctionnalité d’AVD :
Etape 0 : Rappel des prérequis
Cette fonctionnalité d’AVD est encore en préversion. Nous allons donc partir d’un environnement Azure vierge et y installer un environnement AVD joint à Azure AD. Voici la courte liste des composants déjà présents sur mon environnement de test :
Tenant Azure
Souscription Azure valide
Etape I : Création du réseau virtuel
Dans un environnement vide, il faut donc commencer par la création d’un réseau virtuel :
Dans mon exemple de test, je ne modifie pas l’adressage réseau :
Attendez que la création se termine pour continuer :
Etape II : Déploiement d’Azure Virtual Desktop
Comme pour un déploiement classique d’Azure Virtual Desktop, notre travail commence par déployer un pool d’hôtes. Vous trouverez ce dernier dans la barre de recherche d’Azure :
Taper « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.
La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI :
Il n’est toujours pas possible de stocker les métadatas d’AVD sur un centre de données en Suisse.
Le choix de l’image Windows utilisée pour Azure Virtual Desktop a son importance ! Actuellement, la fonctionnalité de préversion du SSO repose sur une modification de l’OS Windows, et n’est pour l’instant déployée que sur la version 22H2 de Windows 11 :
La suite des options concernant les machines virtuelles AVD ne changent pas :
Type de domaine à joindre : Choisissez Azure Active Directory
Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.
La création de l’espace de travail ne change pas :
Lancez la création et attendez plusieurs minutes :
Une fois le déploiement terminé, constatez la présence des ressources suivantes dans le groupe de ressources :
Etape III : Affectation des utilisateursAVD
Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou groupes pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par le groupe d’application AVD :
Il est aussi possible de passer par l’attribution d’un rôle RBAC pour cette même opération :
Etape IV : Ajout des rôles RBAC
Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles AVD jointes à Azure AD, l’attribution d’un rôle RBAC spécifique est nécessaire. Affectez les deux rôles RBAC suivants sur le groupe de ressources :
Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD
Etape V : Implémentation de la fonctionnalité SSO
Retournez sur votre pool d’hôtes afin de profiter très facilement de cette nouvelle fonctionnalité :
La sauvegarde de cette option impacte les arguments RDP affichés dans l’onglet Avancé :
Pensez bien à sauvegarder ????.
Un clic sur la session RDP vous affiche toujours la demande d’authentification de la session Windows :
Lancez un rafraîchissement pour mettre à jour les options RDP :
Retentez l’opération de connexion RDP pour voir cette nouvelle fenêtre apparaître :
Confirmez votre identité :
Acceptez la demande d’autorisation pour autoriser les connexion RDP :
Il semble que cette demande soit valable pour une machine du pool uniquement.
La session Windows 11 devrait alors s’ouvrir :
Retentez l’opération une seconde fois pour vérifier le bon fonctionnement du SSO ????
Conclusion
On peut dire que Microsoft a fait le maximum pour simplifier les choses concernant le déploiement de cette nouvelle fonctionnalité AVD ! D’autres articles suivront pour tester les autres cas de gestions des identités via Active Directory.
Encore merci à Dean pour cette annonce et sa vidéo sur le sujet.
Troubleshoot
Depuis l’apparition de cette nouvelle fonctionnalité, je me suis retrouvé embêté dans le déploiement d’environnements AVD joint à Azure AD et sous Windows 10/11 sans utiliser cette nouvelle option.
En effet, mes utilisateurs de test n’étaient plus en mesure de passer l’authentification de la session Windows :
La faute revient à l’impossibilité de remettre l’ancien argument RDP suivant dans ma configuration RDP, comme indiqué dans mon premier article sur le sujet.
targetisaadjoined:i:1
Voici le message d’erreur en question sur mon AVD depuis le portail Azure :
????
La solution
Pour contourner ce blocage, il est nécessaire de passer cet argument RDP targetisaadjoined:i:1 via une commande PowerShell :
J’avais déjà écrit un article sur comment sauvegarder de machine virtuelle via Runbook/Snapshot. Cette option est intéressante dans le cas où la sauvegarde native d’Azure ne supporte pas l’OS de la machine virtuelle. Microsoft continue d’apporter des mesures de sécurité sur son service sauvegarde Azure Backup.
Dans cet article, nous allons parler et tester l’autorisation multi-utilisateur (MUA), annoncée il y a seulement quelques jours en disponibilité générale. Dans quel but ? Accroître la protection des sauvegardes de vos ressources Azure.
Mais avant cela, nous allons faire un rappel de quelques mesures de protection de sauvegardes de machines virtuelles disponibles sur Azure.
Par défaut, quelles mesures de protection existent sur mes sauvegardes de VMs ?
Quand vous sauvegardez des machines virtuelles au travers de la sauvegarde native d’Azure, vous utilisez et déployez un coffre de sauvegarde. Ce dernier est directement géré par le service Azure Backup :
Ce schéma nous montre la création de snapshots et le transfert différé vers le coffre de sauvegarde.
La création de snapshots et la rétention de vos sauvegardes sont alors configurées selon une police de sauvegarde, créée dans ce coffre de sauvegarde :
D’autre part, le nombre et la répartition des copies de vos sauvegardes vont dépendre des propriétés de ce coffre :
La création d’un Recovery Service Vault est paramétré en Geo-redondant par défaut. Cette option reste modifiable tant qu’aucune sauvegarde n’est paramétrée.
Pour rappel, voici quelques notions de réplication à connaitre, tant elles sont très utilisées sur un grand nombre de ressources Azure :
Redondance locale (LRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure.
Redondance zonale (ZRS) : La donnée est présente en triple exemplaires, chacun réparti dans les 3 datacenters (Zones) de la même région Azure, si celle-ci le propose.
Géo-redondance (GRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure, et 3 autres exemplaires dans la région paire Azure de la première.
Note : il existe également d’autres scénarios de réplication Azure : RA-GRS, GZRS, … ????
Enfin, la suppression d’une sauvegarde stockée dans un coffre conserve encore celle-ci pendant 14 jours. Cette fonctionnalité est activée par défaut et est appelée Soft-delete:
Pour information, la donnée maintenue dans cet état de soft-delete ne coûte rien.
Un coffre de sauvegarde contenant encore des sauvegardes en état de soft-delete ne peut être supprimé.
Envi d’en savoir plus sur la sauvegarde de machine virtuelle ?
Voici l’excellente vidéo de Travis Roberts expliquant le service Azure Backup et les étapes de sa mise en place sur différentes ressources Azure :
Pourquoi mettre en place l’autorisation multi-utilisateur sur les sauvegardes Azure ?
L’autorisation multi-utilisateur (MUA) pour la sauvegarde Azure vous permet d’ajouter une couche supplémentaire de protection aux opérations critiques sur vos coffres Recovery Services. Pour MUA, Sauvegarde Azure utilise une autre ressource Azure appelée protection des ressources pour garantir que les opérations critiques sont effectuées uniquement avec l’autorisation applicable.
En y réfléchissant, un scénario apparait effectivement comme non protégé : comment sécuriser les sauvegardes contre un compte administrateur compromis ou contre une suppression accidentelle ?
En effet, un compte utilisateur Azure AD, configuré comme propriétaire ou contributeur de ressources Azure, dispose des droits pour la mise en en place de sauvegardes, mais également de ceux pour les démettre ! Les mesures listées précédemment renforcent la sécurité mais sont toutes réversibles par cet utilisateur.
Est-ce ici qu’entre en scène Azure Resource Guard ?
L’idée générale d’Azure Resource Guard est de faire reposer la répartition des tâches (donc des droits Azure) sur différents utilisateurs. Il s’agit d’un dispositif (SOD) mis en place dans tout processus de contrôle interne : acteur et contrôleur.
Comme le montre le schéma ci-dessous, deux roles sont alors nécessaires pour sécuriser les actions liées aux sauvegardes avec MUA :
Administrateur sauvegarde : Propriétaire ou contributeur du coffre de sauvegarde. Ce dernier met en place et gère les sauvegardes de ressources Azure. L’administrateur sauvegarde ne doit pas avoir de droits élevés et permanent sur l’Azure Resource Guard.
Administrateur sécurité : Propriétaire du Azure Resource Guard et gardien des opérations critiques sur le coffre de sauvegarde. Par conséquent, l’administrateur sécurité contrôle les permissions dont l’Administrateur sauvegarde a besoin pour effectuer les opérations critiques.
Quelles sont les actions restreintes grâce à Azure Resource Guard ?
L’installation du contrôle d’Azure Resource Guard sur un coffre de sauvegarde bloquera certaines actions si les droits de l’Administrateur sauvegarde sont insuffisants :
Les opérations marquées comme obligatoires ne peuvent pas être exclues de la protection par Azure Resource Guard. Enfin, cette configuration s’appliquera à tous les coffres de sauvegarde associés à celui-ci.
Où doit se trouver Azure Resource Guard ?
Le service Azure Resource Guard doit obligatoirement être sur la même région Azure que le coffre de sauvegarde qu’il protège. De plus, l’Administrateur sauvegarde ne doit pas avoir de droits de contributeur permanent sur Azure Resource Guard. Dans le cas contraire, il n’est jamais bloqué pour aucune action critique sur le coffre de sauvegarde.
Il est alors possible d’envisager différents scénarios :
Le coffre de sauvegarde et Azure Resource Guard sont dans la même souscription. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard.
Le coffre de sauvegarde et Azure Resource Guard sont dans des souscriptions différentes du même tenant. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard ou à sa souscription.
Le coffre de sauvegarde et Azure Resource Guard sont dans des tenants différents. Mais l’Administrateur de sauvegarde n’a pas accès à Azure Resource Guard, à la souscription ou tenant correspondant.
Etape 0 : Rappel des prérequis
Comme pour beaucoup d’articles sur ce blog, nous allons créer différentes ressources sur Azure pour y parvenir. Comme à chaque fois, des prérequis sont nécessaires pour réaliser cette démonstration :
Un tenant Microsoft. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde hébergés sur différents tenants.
Une ou plusieurs souscriptions Azure. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde sur différentes souscriptions Azure.
Une machine virtuelle déjà déployée sur un tenant accessible à l’Administrateur de sauvegarde .
Dans mon cas, j’ai utilisé deux tenants différents, différenciés dans cet article par la couleur du portail Azure pour plus de simplicité :
Le tenant A, noir pour l’Administrateur de sauvegarde, contient la machine virtuelle à sauvegarder et le coffre de sauvegarde.
Le tenant B, blanc pour l’Administrateur sécurité, contient Azure Ressource Guard.
Nous avons donc les deux environnements Azure suivants :
Tenant A.
Etape I : Création d’Azure ResourceGuard
Sur le tenant B, commencez la création du service Azure Resource Guard :
Renseignez les différents champs, puis cliquez sur Suivant :
Si l’erreur suivante apparaît, retournez sur la page de la souscription Azure concernée :
Cliquez comme ceci pour constater le statut du resource provider Microsoft.DataProtection :
Cliquez alors sur celui-ci puis sur Enregistrer :
Attendez quelques minutes que le traitement se termine :
Contrôler le nouveau statut du resource provider :
Retournez dans la création de votre Azure Resource Guard pour constater la disparition du message d’erreur sur le second onglet.
Sélectionnez les opérations dont vous avez besoin de protéger et cliquez comme ceci pour les valider :
Vous pourrez toujours modifier cette liste après la création dans les propriétés d’Azure Resource Guard.
Lancez la création de votre Azure Resource Guard :
Etape I : Assignation du rôle de lecteur pour l’administrateur de sauvegarde
Afin de pouvoir interroger le service Azure Resource Guard, l’Administrateur sauvegarde doit disposer d’un rôle de lecteur sur ce dernier.
Sur le tenant B, retournez sur l’Azure Resource Guard et cliquez comme-ci pour rajouter le rôle de lecteur à l’administrateur sauvegarde :
Choisissez le rôle de lecteur puis cliquez sur Suivant :
Ajoutez votre Administrateur sauvegarde :
Cliquez pour valider :
Etape II : Création du coffre de sauvegarde
De retour sur le tenant A, recherchez le service Recovery Service Vault pour le créer :
Renseignez les champs et lancez la création du coffre de sauvegarde :
Etape III : Protégez votre coffre de sauvegarder
Retournez sur le tenant B, puis copiez la valeur suivante de votre Azure Resource Guard :
Sur le tenant A, retournez sur votre coffre de sauvegarde et cliquez ici pour mettre en place la MUA :
Effectuez les opérations suivantes et collez votre Resource Guard ID dans le champ suivant :
Contrôlez la cohérence des informations de votre Azure Resource Guard :
Sauvegardez la configuration MUA de votre coffre de sauvegarde :
Votre coffre de sauvegarde est maintenant protégé, continuez sur l’étape suivante pour vérifier le blocage des opérations pour l’Administrateur sauvegarde.
Etape IV : Contrôlez le blocage pour l’administrateur sauvegarde
Restez dans les propriétés de votre coffre de sauvegarde et cliquez sur les options de sécurité :
Vous êtes immédiatement averti de la couche de protection supplémentaire grâce au service Azure Resource Guard :
Essayez de désactiver la fonctionnalité Soft Delete et sauvegardez la nouvelle configuration :
L’action de sauvegarde échoue bien et affiche la notification d’erreur suivante :
La même opération, avec un autre compte, disposant lui de droits de contributeur sur Azure Resource Guard, dans mon exemple grâce à Azure Lighthouse, ne pose aucun souci :
Etape IV : Sauvegardez votre la machine virtuelle avec MUA
La mise en place de MUA ne bloque pas l’Administrateur sauvegarde de mettre en place de nouvelles protections pour des ressources Azure.
Pour cela, retournez sur la page principale de votre coffre de sauvegarde et cliquez comme-ceci :
Continuez la configuration avec la famille de ressources Machine virtuelle :
Ajoutez votre machine virtuelle à sauvegarder :
Cochez la case correspondante pour prendre la machine virtuelle désirée et cliquez sur OK
Activez la mise en place de la sauvegarde :
Une fois le traitement terminé, retournez sur le coffre de sauvegarde comme-ci :
Cliquez ici pour afficher les détails :
Lancez une sauvegarde immédiate :
La mise en place de la sauvegarde et la première sauvegarde n’ont pas provoqué d’erreur MUA pour l’Administrateur sauvegarde.
Contrôler l’avancement des travaux de la première sauvegarde et affichez les détails pour vérifier quand celui-ci est entièrement terminé :
Après quelques minutes et plusieurs rafraichissements, la sauvegarde est complète et correctement envoyée dans le coffre de sauvegarde.
Que peut-on encore mettre en place ?
Dans certains cas, vous devrez peut-être effectuer des opérations critiques sur vos sauvegardes et MUA peut vous aider à vous assurer qu’elles sont exécutées uniquement lorsque les approbations ou les autorisations appropriées existent. Comme nous l’avons vu précédemment, l’administrateur de sauvegarde doit avoir un rôle Collaborateur sur le service de protection des ressources pour effectuer des opérations critiques qui se trouvent dans l’étendue de la protection des ressources. L’une des façons d’autoriser l’exécution juste-à-temps pour ces opérations consiste à utiliser Azure Active Directory (Azure AD) Privileged Identity Management.
Les étapes suivantes de cet article sont facultatives, mais peuvent simplifier le processus d’élévations des droits grâce à la combinaison de plusieurs services Azure :
Azure Gestion des identités privilégiées (PIM)
Azure Resource Guard
La Gestion des identités privilégiées Azure AD, présente dans la licence Azure AD Premium P2, apporte de la souplesse dans les autorisations de droits temporaires sur des ressources Azure.
Dans le cadre de PIM et d’Azure Resource Guard, nous aurions la cinématique suivante :
Etape 0 : Demande d’élévation des droits par l’Administrateur sauvegarde
Etape I : Validation de la demande par Administrateur sécurité pour une durée donnée
Etape 2 : Intervention sur les sauvegardes par l’Administrateur sauvegarde
Etape 3 : Fin de l’élévation des privilèges d‘Administrateur sauvegarde
Le schéma ci-dessus est un exemple de scénario possible grâce à PIM.
Etape V : Intégration de PIM sur Azure Resource Guard
Sur le tenant B, recherchez le service Azure suivant :
Cliquez sur Ressources Azure puis sur la souscription ou le groupe de ressources contenant Azure Resource Guard :
Si aucune souscription n’apparait, cliquer « Découvrir les ressources » et laissez-vous guider.
Ajoutez un nouvel assignement :
Choisissez le rôle Contributeur et reprenez l’utilisateur Administrateur sauvegarde et cliquez sur Suivant :
Conservez bien la notion d’éligibilité et cliquez sur Assigner :
Etape VI : Mise en place du processus de validation
Notre utilisateur Administrateur sauvegarde est maintenant éligible pour devenir Contributeur sur Azure Resource Guard. Seulement, il est nécessaire de mettre en place un processus de validation pour l’élévation de ses droits. Sans cela et par défaut, toutes ses demandes seront automatiquement approuvées.
Sur le tenant B et au même niveau que précédemment, cliquez comme ceci dans Azure AD PIM pour modifier les paramétrages de validation :
Cliquez sur le rôle Contributeur :
Cliquez sur Modifier :
Modifiez vos paramétrages pour intégrer l’Administrateur sécurité dans l’activation et cliquez sur Mettre à jour :
Etape VII : Test de la fonctionnalité PIM sur Azure Resource Guard
Avant d’activer le rôle Contributeur sur Azure Resource Guard via Azure AD PIM, nous allons vérifier que l’action sur la sauvegarde de la machine virtuelle n’est pas autorisée dans les conditions de base.
Sur le tenant A, retourner sur le coffre de sauvegarde et cliquez comme ceci :
Cliquez ici pour arrêter le mécanisme de sauvegarde :
Arrêtez complètement le backup et supprimer les données :
Le message d’erreur suivant devrait alors apparaître :
Il est donc bien nécessaire de faire une élévation temporaire des droits sur Azure Resource Guard. Positionnez-vous sur le tenant contenant Azure Resource Guard et lancez Azure AD PIM :
Cliquez sur Mes Rôles :
Cliquez sur Ressources Azure puis sur Activer :
Entrez une justification et une période puis cliquez sur Activer :
La notification Azure suivante doit apparaître :
Sur le tenant B, cliquez sur Approuver les demandes dans Azure AD PIM :
Cliquez sur Ressources Azure et approuvez la demande :
Confirmez la demande d’approbation :
Sur le tenant A, un contrôle sur Azure AD PIM nous montre que le rôle de Contributeur est bien actif :
Retentez alors l’opération de suppression de la sauvegarde de la machine virtuelle :
Si l’erreur suivante arrive en notification, refaite un test dans quelques minutes :
Conclusion
L’ajout de cette fonctionnalité sur un coffre de sauvegarde est un vrai plus en termes de protection des ressources Azure. Il est vrai que la situation antérieure, avec des propriétaires et des contributeurs au plein pouvoirs pouvaient inquiéter en cas de scénarios d’attaque.
Il parait indispensable de sécuriser les opérations critiques liées aux sauvegardes, bien prises en compte avec Azure Resource Guard :
MUA apporte une vraie réponse pour protéger encore plus les sauvegardes et sans surcoût, sauf si Azure AD PIM est présent dans votre architecture. Nul doute qu’Azure Resource Guard va apporter encore plus de protection sur d’autres services au fil de ses évolutions.
La maintenance informatique est une fenêtre nécessaire dans laquelle un service est volontairement indisponible et annoncé en amont. Les architectures basées sur des services Azure n’échappent pas à cette règle car il est toujours nécessaire d’effectuer des maintenances régulières pour des sauvegardes, des mises à jour, des refontes, des réplications, …
Dans cet article, nous allons nous intéresser une nouvelle fonctionnalité disponible sous Azure Virtual Desktop. Encore en préversion à l’heure où ces lignes sont écrites, elle permet de gérer les périodes de mise à jour des agents AVD sur les machines virtuelles qui composent votre pool d’hôtes.
Qu’est qu’un agent AVD ?
Un environnement Azure Virtual Desktop est composée d’une ou plusieurs machines virtuelles. Pour que la communication entre le contrôleur de structure Azure et ces dernières soit assurée, un agent est présent sur chaque machine virtuelle. Un tour dans les programmes installés nous montre tout cela :
L’installation de ces agents est entièrement transparente si la création de la machine virtuelle est réalisée depuis le portail Azure. Si vous créez la machine virtuelle via un script PowerShell, vous devrez alors télécharger et installer manuellement les fichiers MSI.
Quand est-ce que l’agent AVD est mis à jour ?
Avant l’apparition de cette nouvelle fonctionnalité, l’agent AVD se mettait à jour à son rythme sans logique particulière. A ce ceci près qu’il existait une option ayant un impact sur le rythme de mise à jour : environnement de validation.
Qu’est-ce que l’environnement de validation ?
Nous (Microsoft) vous recommandons vivement de créer un pool d’hôtes de validation dans lequel les mises à jour de service seront appliquées en premier. Les pools d’hôtes de validation vous permettent de superviser les mises à jour de service avant que celui-ci ne les applique à votre environnement standard ou de non-validation. Sans pool d’hôtes de validation, vous risquez de ne pas détecter les modifications qui génèrent des erreurs, ce qui peut entraîner des temps d’arrêt pour les utilisateurs de votre environnement standard.
Autrement dit, la mise à jour est orientée en premier lieu vers les pools d’hôtes marqués comme environnement de validation. Une fois la mise à jour déployée avec succès en grand nombre sur des environnements de validation, elle est aussi installée sur les machines virtuelles d’environnements AVD de production.
De manière générale, un environnement de validation a tout son sens dans une solution de bureau à distance car il apporte une couche supplémentaire de tests via des utilisateurs spécifiques et évite ainsi un déploiement pouvant provoquer un blocage massif.
Mises à jour planifiées de l’agent
Toujours dans la volonté d’apporter une meilleure maîtrise de l’environnement Azure Virtual Desktop, Microsoft introduit la fonctionnalité de planification. Celle-ci ne concerne que la mise à jour de l’agent AVD présent sur les machines virtuelles du pool d’hôtes.
Comme vous allez le voir dans les écrans ci-dessous, cette option se configure au niveau du pool d’hôtes et impacte alors toutes les machines virtuelles rattachées de la même manière.
Via le portail Azure, rendez-vous sur votre pool d’hôtes et cliquez sur Mises à jour programmées des agents :
Cliquez sur la case ci-dessous pour activer la gestion manuelle des mises à jour :
Il vous est alors possible de définir une ou deux fenêtres de maintenance. Comme indiqué sur la page, 4 tentatives de mise à jour seront effectuées avant que celle-ci soit reportée la prochaine fois que les hôtes de session seront allumés.
Commencez par définir le fuseau horaire. Vous avez le choix entre celui employé par la machine virtuelle ou un parmi la liste déroulante :
Définissez le jour et l’heure de la première fenêtre de mise à jour :
Ajoutez au besoin une seconde fenêtre de mise à jour :
Enfin cliquez pour appliquer la configuration :
Et c’est tout ! ????
Conclusion
Azure Virtual Desktop continue son chemin et évolue en permanence ????. Pour rester sur ce sujet, retrouvez la vidéo très bien expliquée faite par Dean de l’Azure Academy. Dean y aborde également la possibilité de consulter l’historique des mises à jour installées via l’utilisation du Log Analytics Workspace d’Azure :
Ce billet est le second d’une série dédiée à l’optimisation sur Azure. Le premier article était dédié aux coûts générés dans le Cloud Microsoft, et les astuces pour en diminuer sa facture. Comme le titre l’indique ici, celui-ci est dédié à la sécurité sur Azure.
L’objectif de cet article n’est pas vendre ou de démontrer la sécurité absolue, mais de mettre en lumière des réflexions, des postures ou encore des mesures de sécurité essentielles. Ces actions augmenteront la sécurité sur Azure et diminueront les risques.
Enfin, nous aborderons aussi les certifications Microsoft, spécifiquement dédiées à ce sujet.
Etape I – Importants concepts de sécurité
Pour bien situer notre sujet, il n’est pas inutile de rappeler deux notions importantes.
Notion A : Défense en profondeur
Retenez bien ceci : Quel que soit l’environnement informatique, le principe de sécurité en couche 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 toute entreprise :
Une architecture Cloud n’échappe pas non plus à cette règle, il est faux de penser que les solutions d’hébergement publics sont toutes à 100% protégées. Les mesures et l’intelligence dédiée à la sécurité y seront certes plus avancées, mais elles passeront par obligatoirement par votre contribution.
Dans le cadre d’Azure, Microsoft prend à sa charge la sécurité en relation avec les premières couches, votre rôle va alors dépendre du service utilisé (IaaS, PaaS, SaaS). Il est donc important d’adapter sa stratégie selon les services déployés :
Prenons l’exemple d’une machine virtuelle sur Azure (IaaS), il est de votre responsabilité de mettre en place les correctifs, de sécuriser le système d’exploitation et d’installer les mises à jour logicielles adéquates. Il en va aussi de même pour la partie réseau de cette machine virtuelle, en y apportant des mesures de sécurité adaptées (Firewall, VPN, NSG, …)
Dans le cadre de l’utilisation d’un service (PaaS), certaines mesures de sécurité sont prises en charge par Microsoft. Par exemple, Azure se charge du système d’exploitation et de certains services comme les moteurs de base de données.
Notion B : Zéro Trust
La définition de ce concept peut se résumer en quelques mots :
Voici une première vidéo pour aller plus loin sur Zéro Trust :
Comme pour la défense en profondeur, les identités, les périphériques, les applications, le réseau, l’infrastructure et les données sont tous des maillons critiques de la chaîne Zéro Trust. Le périmètre de contrôle est horizontal car il impacte tous ces domaines :
Comme le montre le schéma ci-dessous, le canal d’authentification est renforcé et appliqué en tout temps et dans toutes les circonstances.
Comment aborder la sécurité sur Azure ?
La protection de votre environnement Cloud nécessite de s’occuper des identités, des données, des applications, de l’infrastructure, …
Grâce aux outils de sécurité intégrés à Azure, mettez en œuvre une stratégie de défense en profondeur par couche, unifiez la gestion de la sécurité et générez une protection avancée contre les menaces.
Une attaque plus difficile est plus coûteuse. Le piratage reste un business : plus l’attaque nécessitera de moyens pour réussir, plus elle aura de chances d’être moins rentable et donc de ne pas aller à son terme.
Pour des questions de clarté de lecture, j’ai donc scindé les chapitres suivants dans différents articles afin de vous y retrouver plus facilement dans ce qui vous intéresse :
Historiquement, deux certifications Sécurité étaient présentes. Chacune représentait un pan du Cloud Microsoft : Modern Work Place & Azure.
MS-500 : Les Administrateurs de la sécurité Microsoft 365 sont chargés de sécuriser de manière proactive les environnements d’entreprise et hybrides Microsoft 365, de mettre en œuvre et de gérer les solutions de sécurité et de conformité, de répondre aux menaces et de faire appliquer la gouvernance des données.
Autrement dit, le but est de maîtriser la sécurité d’un environnement Microsoft 365, au travers de tous les outils de collaboration : Teams, Outlook, SharePoint, OneDrive, … Aucun mystère, beaucoup de travail et de connaissances sont à prévoir dans les différents outils 365.
AZ-500 : Les Ingénieurs Sécurité Azure sont chargés de maintenir l’état de la sécurité, d’identifier et de corriger les vulnérabilités, d’effectuer une modélisation des menaces, de mettre en œuvre une protection contre les menaces et de répondre aux escalades des incidents de sécurité.
La racine AZ dans le nom de la certification nous indique que son périmètre se porte sur Azure. Presque tous les composants disponibles sur Azure disposent de fonctionnalités natives de sécurité, activables ou non selon les besoins. Le but de cette certification est de valider les connaissances sur la maîtrise des différents outils et mesures de sécurité.
Pourquoi créer de nouvelles certifications Microsoft dédiées à la sécurité ?
Cette approche de Microsoft fut un premier pas pour couvrir l’apprentissage des grandes mesures de sécurité sur le Cloud. Depuis, la sécurité reste une préoccupation majeure pour Microsoft comme pour tous les autres acteurs du marché.
Du côté client, un besoin d’outils toujours plus performants et des formations adaptées aux équipes de sécurité sont demandés. Pour cela, Microsoft a décidé d’étoffer son apprentissage via ces nouvelles certifications dédiées à la sécurité :
SC-900 : Certification de niveau fondamental apportant les bases et les concepts de la sécurité, de la conformité et de l’identité. Elle permet de mieux comprendre les fonctionnalités des solutions Microsoft de gestion des identités et des accès. Voici mon article sur celle-ci.
SC-400 : Certification de niveau intermédiaire, la SC-400 apporte une expertise sur les moyens de protection de l’information dans un environnement Microsoft 365. Il est question de savoir mettre en œuvre des mesures de prévention contre la perte de données, de protection d’informations sensibles et de politique de conservation des données.
SC-300 : Certification de niveau intermédiaire, la SC-300 fait la part belle à la sécurité sur Azure Active Directory (Azure AD). Autant vous dire que les sujets sont vastes, en rapport avec l’importance de la gestion identité. Probablement une des certifications les plus intéressante que j’ai eu à passer. Voici là encore mon article sur celle-ci.
SC-200 : Certification de niveau intermédiaire. La gestion, le monitoring et la réponse aux menaces fait partie du quotidien des équipes de sécurité. Les principaux outils à connaitre sont Microsoft Sentinel, Microsoft Defender for Cloud, Microsoft 365 Defender. Voici également mon article sur celle-ci.
SC-100 : Certification de niveau expert, elle est encore en version beta à l’heure où ces lignes sont écrites. Le spectre de connaissances est très large : l’ingénierie de la sécurité, notamment l’identité et l’accès, la protection des plateformes, les opérations de sécurité, la sécurisation des données et la sécurisation des applications. Les personnes certifiées doivent également être familiarisées avec la sécurité dans les environnements hybrides.
Bref que du bonheur ????
Conclusion
Microsoft nous montre encore une fois l’important de la sécurité, présente partout et en tout temps. Il est donc important de mettre en oeuvre un certain nombre de mesures, mais de former régulièrement les équipes aux évolutions des attaques pour au mieux les déjouer, ou les minimiser au pire.
Comme pour les autres sections, voici une liste non exhaustive de différents outils de protection des ressources créées sur Azure.
Azure Advisor
Je vous avais déjà signalé que cet outil prodiguait gratuitement quelques conseils pour réaliser des économies sur votre architecture Cloud. Azure Advisor va plus loin en proposant également des conseils de sécurité.
Comme les autres recommandations, celles de sécurité sont classifiées selon l’impact et le risque sécuritaire.
Un clic sur les 21 recommandations listées dans mon tenant nous en affiche le détail :
Les premières recommandations sont pleines de bon sens :
Trop de propriétaires pour le(s) souscription(s) Azure
Activation si besoin de Microsoft Defender
Activation de la MFA pour les comptes propriétaires ????
Certaines sont à prendre avec plus de recul, comme par exemple celle-ci :
Azure Advisor autorise les exceptions après analyse du conseil.
Comme beaucoup de services sous Azure, le coût peut être un frein selon l’usage :
Dans certains cas, Azure Advisor proposera même de « corriger » à votre place la recommandation de sécurité :
Defender for Cloud (Anciennement Azure Security Center + Azure Defender)
Microsoft a renommé ce service lors du dernier Ignite en 2021. Microsoft Defender for Cloud est une solution comportant deux aspects majeurs :
Gestion de la posture de sécurité cloud (CSPM) : identifie les faiblesses dans votre architecture cloud, aide à renforcer la posture de sécurité globale de votre environnement (IaaS, PaaS, SaaS).
Protection de la charge de travail cloud (CWP). Créer une protection des charges de travail (machine virtuelle, stockage, Kubernetes, SQL, …) dans des environnements multiclouds ou hybrides contre les menaces.
Historiquement, il existait déjà ces deux services, l’un gratuit (Azure Security Center) et l’autre payant (Azure Defender), couvrant approximativement le même périmètre. Voici un schéma pour comprendre cette évolution :
Posture de sécurité pour Microsoft Defender pour le cloud
Déjà disponible sous un ancien nom Azure Secure Score, Defender for Cloud reprend le même principe grâce l’évolution permanente des caractéristiques de sécurité des ressources Azure. Chaque point de faiblesse et alors valorisé pour établir le score de sécurité de l’architecture : plus le score est élevé, plus le niveau de risque identifié par Microsoft est faible.
Azure Defender for Server
Microsoft Defender pour les serveurs fournit la détection des menaces ainsi que des défenses avancées à vos machines Windows et Linux, qu’elles s’exécutent dans Azure, AWS, GCP ou localement. Microsoft Defender pour les serveurs est disponible dans deux plans :
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 sontmaintenant disponibles selon le serveur concerné et les fonctionnalités recherchées. Le plan 2 correspond à l’ancien plan appelé Defender for Server :
La liste des avantages de Defender for Server se trouve ici.
Particularité Azure :
Il est aussi possible d’intégrer un serveur protégé par Defender for Cloud dans Microsoft Defender sans aucun surcoût ! Prenez le temps de lire attentivement l’article suivant, mettant en lumière les différences entre Defender for Cloud et Defender for server, mais aussi leurs possibilités d’intégration commune.
Et enfin un autre article pour la mise en place juste ici.
Azure Backup
Azure Backup est un service de sauvegarde apportant une couche de sécurité supplémentaire en cas de perte ou de corruption de donnée. Ce service est payant et est en supplément dans la plupart des cas, mais peut être déjà intégré dans le cout de certains services PaaS (App service, MySQL, …). Comme le montre le schéma ci-dessous :
Azure Backup Center pilote les sauvegardes effectuées dans les différents coffres de sauvegarde ou coffres de restauration.
Le choix du nombre de sauvegardes est accessible lors de la mise en place de cette dernière
Il est même possible de sauvegarder des ressources en dehors Azure afin de garantir une copie complète de toutes les données d’entreprise.
Azure Disaster Recovery
La sauvegarde de données n’est pas un gage systématique de reprise d’activité après sinistre. Pour cela, des solutions dédiées sont mises en place et interviennent en parallèle du cycle de sauvegarde.
Le schéma d’architecture ci-dessous montre la réplication des services entre deux régions Azure :
Les machines virtuelles présentes dans la seconde région Azure ne seront allumées que lors que failover est déclenché.
La synchronisation des données est pilotée par le service Azure Site Recovery. Des disques réplicas sont créés et facturés dans la seconde région. Il en est de même pour les bases de données répliquées. A l’inverse, les machines virtuelles ne sont pas démarrées, ce qui en réduit le coût opérationnel de la seconde région.
Retrouvez mon article sur la mise en place de ce service sur une architecture Azure Virtual Desktop.
Verrous Azure
Comment protéger les ressources Azure d’une simple suppression accidentelle ?
Il arrive que les droits utilisateurs soient justifiés, mais qu’une simple erreur d’inattention provoque de gros dégâts dans l’architecture Azure. Les verrous d’Azure sont là pour ça !
Les verrous Azure sont des composants gratuits et paramétrables sur différents niveaux :
Souscription Azure
Groupe de ressource
Azure
Les verrous Azure fonctionnent aussi par héritage et provoque deux types de blocage :
CanNotDelete signifie que les utilisateurs autorisés peuvent lire et modifier une ressource, mais qu’ils ne peuvent pas la supprimer.
ReadOnly signifie que les utilisateurs autorisés peuvent lire une ressource, mais ne pas la supprimer ni la mettre à jour. Appliquer ce verrou revient à limiter à tous les utilisateurs autorisés les autorisations fournies par le rôle Lecteur.
Dans un environnement Cloud, la connectivité réseau est un point primordial de la sécurité. Que les services hébergés dans le cloud doivent être accessibles depuis une architecture on-premise ou pour des utilisateurs internet, il est nécessaire de mettre en place des mesures de sécurité pour protéger le traffic réseau mais aussi les périphériques.
Pour cela, voici quelques services disponibles nativement sous Azure pour y parvenir :
Azure VPN
Azure VPN est un service managé par Microsoft :
Une passerelle de réseau virtuel est composée de deux machines virtuelles ou plus qui sont automatiquement configurées et déployées sur un sous-réseau spécifique que vous créez, appelé sous-réseau de la passerelle… Vous ne pouvez pas configurer directement les machines virtuelles qui font partie de la passerelle de réseau virtuel, même si les paramètres que vous sélectionnez lors de la configuration de votre passerelle ont un impact sur les machines virtuelles de passerelle créées.
La passerelle de réseau virtuel envoie du trafic crypté entre un réseau virtuel Azure et un site via Internet. Cette connexion est disponible pour deux besoins :
Connexion Site à Site (S2S) : utilisée pour établir une ou des connexions permanentes vers des locaux afin de prolonger les réseaux locaux dans Azure.
Connexion Point à Site (P2S) : utilisée pour établir des connexions temporaires en situation de mobilité. Ideal pour des périphériques portables.
Dans le cadre d’une connexion P2S, les méthodes d’authentification à Azure VPN sont à considérer selon le type de périphériques utilisé :
Azure propose plusieurs SKUs de VPN avec différents débits :
A cela, il faut aussi ajouter les coûts de bande passantes puisque le traffic sortant d’Azure est facturé par Microsoft :
Azure ExpressRoute
A l’inverse d’Azure VPN, les connexions ExpressRoute n’acheminent pas le traffic via Internet. Elles offrent plus de fiabilité, une vitesse plus rapide et une latence inférieure que les connexions Internet classiques.
Un circuit ExpressRoute comporte toujours deux connexions à deux routeurs périphériques Microsoft Enterprise (MSEE). Les fournisseurs de connectivité utilisent eux aussi des dispositifs redondants pour assurer la redondance de vos connexions à Microsoft.
Les principaux avantages de la connexion ExpressRoute sont :
Connectivité de couche 3 entre votre réseau local et le cloud de Microsoft via un fournisseur de connectivité.
Connectivité aux services de cloud de Microsoft dans toutes les régions de la zone géopolitique.
Routage dynamique entre votre réseau et Microsoft via le protocole de routage dynamique standard (BGP).
Redondance intégrée dans chaque emplacement de peering pour une plus grande fiabilité.
Un groupe de sécurité réseau (NSG) filtre le trafic réseau entrant et sortant et contient des règles qui sont utilisées pour autoriser ou refuser le trafic de sécurité réseau filtré. La configuration de ces règles de sécurité NSG vous permet de contrôler le trafic réseau en autorisant ou en refusant des types de trafic spécifiques. Vous pouvez affecter un NSG à :
Une interface réseau pour filtrer le trafic réseau sur cette interface uniquement.
Un sous-réseau pour filtrer le trafic sur toutes les interfaces réseau connectées dans le sous-réseau.
Vous pouvez également affecter des NSG à la fois à des interfaces réseau et à des sous-réseaux. Dans ce cas, chaque NSG est évalué indépendamment.
Azure Application Security Group (ASG)
Il est possible de combiner l’efficacité du NSG en associant les ressources de même nature à un ASG. Le groupe de sécurité des applications vous permet de configurer la sécurité du réseau comme une extension naturelle de la structure d’une application, en vous permettant de regrouper des machines virtuelles et de définir des politiques de sécurité du réseau en fonction de ces groupes.
Azure Bastion
Les machines virtuelles Windows et Linux nécessitent un accès pour leur administration. L’ajout d’une IP publique sur la machine virtuelle résout le souci d’accès externe mais créer un précédent de sécurité. C’est là qu’Azure Bastion rentre en scène :
Azure Bastion est un service PaaS proposé par Azure pour apporter une couche de sécurité supplémentaire dans le cadre de connexion RDP/SSH. Ce composant permet alors de se connecter sur des machines virtuelles sans les exposer à internet.
Azure Bastion doit être associé à un réseau virtuel même s’il est compatible avec les réseaux virtuels associés à ce dernier.
Azure Firewall
Azure Firewall est un service de sécurité réseau basé sur le cloud qui permet de protéger vos ressources VNet. En utilisant Azure Firewall, vous pouvez créer et gérer de manière centralisée des profils de connectivité réseau dans toute votre organisation.
Microsoft organise assez régulièrement un évènement appelé Microsoft Build. Comme l’indique sa page Wikipédia, c’est une conférence annuelle destinée aux ingénieurs logiciels et aux développeurs Web utilisant Windows, Azure et d’autres technologies Microsoft.
Sa première organisation date de 2011, en remplacement d’autres évènements eux aussi dédiés aux développeurs, comme la Conférence des développeurs professionnels et le MIX. Cette année encore, il fut organisé en virtuel.
Qu’est-ce que le Microsoft Build Cloud Skills Challenge ?
Comme pour le Microsoft Ignite, organisé pour la dernière fois en novembre dernier, Microsoft propose de rendre ses évènements plus interactifs avec la participation de l’audience.
Pour cela, Microsoft vous propose de participer à un exercice technique, appelé challenge. La réalisation d’un seul challenge vous apporte une meilleure compréhension du message de Microsoft et vous donne la possibilité de repartir avec un gain immédiat : un bon d’examen pour une certification Microsoft.
Attention :
Ce challenge est limité dans le temps, vous devez le terminer au plus tard le 21 juin prochain
La réalisation de plusieurs challenges ne vous apportera pas plusieurs bons d’examen Microsoft
Quelques informations supplémentaires sont disponibles dans la FAQ officielle
La réalisation d’un des 3 challenges techniques, vous offre un bon d’examen pour tester et valider vos connaissances Microsoft. Cette année, 3 challenges vous sont accessibles :
Pour quelles certifications pourrons-nous utiliser notre bon d’examen ?
Vous retrouvez ci-dessous les certifications Microsoft accessibles gratuitement grâce à l’utilisation de votre bon d’examen Microsoft Build :
Il arrive qu’une machine virtuelle ne corresponde plus aux besoins initialement définis avec sa taille. Pas de panique ! Un changement est toujours possible après coup. L’un des grands avantages d’Azure est la possibilité de modifier la taille des machines virtuelles, à la volée, des besoins en termes de performances du processeur, du réseau ou de disques.
Dans cet article, nous allons démontrer ensemble la simplicité de changer la taille d’une machine virtuelle, mais également les étapes additionnelles pour un changement particulier.
Dans quel cas redimensionner ?
Lorsque l’on examine le redimensionnement de machines virtuelles sous Azure, trois axes définissent ce processus de changement de taille :
Localisation : votre région Azure ne contient pas le matériel nécessaire pour prendre en charge la taille de machine virtuelle souhaitée.
Interruption : vous devrez dans certains cas désallouer la machine virtuelle. Cela peut se produire si la nouvelle taille n’est pas disponible sur le cluster matériel qui l’héberge actuellement.
Restriction : Si votre machine virtuelle utilise le stockage Premium, assurez-vous que vous choisissez une version s de la taille pour obtenir le support du stockage Premium.
Tailles des machines virtuelles dans Azure
Avant de basculer sur le portail Azure pour effectuer les étapes de modification de taille, voici un rappel de l’offre des machines virtuelles Azure. Afin d’y voir plus clair, Microsoft a segmenté son offre de machines virtuelles par famille, correspondant à des scénarios de besoin utilisateur :
En exemple, voici la définition donnée par Microsoft pour des besoins GPU :
Les tailles de machine virtuelle au GPU optimisé sont des machines virtuelles spécialisées disponibles avec des GPU uniques, multiples ou fractionnaires. Ces tailles sont conçues pour des charges de travail de visualisation, mais également de calcul et d’affichage graphique intensifs.
Les familles sont généralement couvertes par plusieurs séries. Une série est une combinaison CPU + RAM + Autre critères. Les séries sont régulièrement mis à jour par Microsoft via des versions. Voici en exemple le détail de la composition pour la série NCv3 :
Les machines virtuelles de série NCv3 sont optimisées par les GPU NVIDIA Tesla V100. Ces GPU peuvent fournir des performances de calcul une fois et demie supérieure à celles de la série NCv2… les machines virtuelles de la série NCv3 sont également pilotées par des processeurs Intel Xeon E5-2690 v4 (Broadwell).
Enfin, chaque série dispose plusieurs SKUs pour proposer différentes puissances. Toujours en exemple, la série graphique NCv3 :
La taille de la machine virtuelle influe également sur le prix de celle-ci. Toujours en exemple, la série graphique NCv3 :
Les instances réservées, d’un ou trois ans, diminuent fortement le prix des machines virtuelles.
Codification Azure
Cette large découpe propose aux utilisateurs un très grand nombre de machines virtuelles possibles. Dans cette jungle de SKUs, Microsoft a mis en place une codification précise dans la dénomination.
Une ou plusieurs lettres minuscules indiquent des fonctionnalités supplémentaires, telles que : a = processeur basé sur AMD b = bloquer les performances de stockage d = diskfull (c.-à-d., un disque temporaire local présent) ; ceci concerne les nouvelles machines virtuelles Azure, consultez Séries Ddv4 et Ddsv4 i = taille isolée l = mémoire insuffisante ; une quantité de mémoire inférieure à la taille d’utilisation intensive de la mémoire m = utilisation intensive de la mémoire ; la plus grande quantité de mémoire dans une taille particulière t = très petite mémoire ; la plus petite quantité de mémoire dans une taille particulière s = capacité de stockage Premium, y compris l’utilisation possible de SSD Ultra (Remarque : certaines tailles plus récentes sans l’attribut de s peuvent toujours prendre en charge le stockage Premium, par exemple M128, M64, etc.)
*Type d’accélérateur
Indique le type d’accélérateur matériel dans les références (SKU) spécialisées/GPU. Seules les nouvelles références (SKU) spécialisées/GPU lancées à partir du troisième trimestre 2020 auront l’accélérateur matériel dans leur nom.
Version
Indique la version de la série de machines virtuelles
Voici un exemple de dénomination pour la machine virtuelle graphique NC4as_T4_v3 :
Valeur
Explication
Famille
N
Sous-famille
C
Nombre de processeurs virtuels
4
Fonctionnalités supplémentaires
a = processeur basé sur AMD s = capacité de stockage Premium
Type d’accélérateur
T4
Version
v3
Avec toutes ces informations, nous allons pouvoir nous intéresser au changement de SKU sur une machine virtuelle existante.
Etape 0 : Rappel des prérequis
Pour cela, nous allons créer différentes ressources sur Azure pour y parvenir. Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration :
Un tenant Microsoft
Une souscription Azure valide
Une machine virtuelle déployée et démarrée
Comme le montre la copie d’écran ci-dessous, ma machine virtuelle dispose actuellement de la taille D4ds v4
Afin de mesurer les impacts d’un changement de taille sur une machine virtuelle démarrée, j’ai également ouvert une connexion RDP à celle-ci
Test I : Changement d’une taille dans la même série
Le changement de taille de la machine virtuelle s’effectue depuis le portail Azure via la section Taille.
Azure y regroupe différentes tailles, accessibles ou non :
Jouez avec les filtres suivants pour trouver la taille adaptée
Certaines tailles ne sont même pas visibles.
Sélectionnez la taille et cliquez sur redimensionner
Une fois déclenché, une notification de traitement apparait dans votre portail Azure
La session RDP est-elle aussi coupée
Après traitement (30 secondes environ), la machine virtuelle retrouve son status démarré. La nouvelle taille se retrouve alors sur la page principale de la machine virtuelle Azure
La réouverture manuelle de la session RDP montre bien la nouvelle puissance
Test II : Changement d’une taille dans une série disponible
Continuez vos tests en effectuant un changement de taille vers une autre famille de machine virtuelle
Là encore, la session RDP se ferme et la notification de changement apparaît sur le portail Azure. Moins d’une minute plus tard, la machine virtuelle repart avec sa dernière taille
Test III : Changement d’une taille dans une série disponible
Dans certains cas, il est nécessaire de partir sur une taille de machine virtuelle ayant des propriétés différentes. Ma machine virtuelle, actuellement en Standard F8s v2, dispose d’un stockage temporaire.
Le disque temporaire est très utile pour les données qui, vous l’aurez deviné, sont de nature temporaire. Un excellent exemple de ce type de données pour Windows est le pagefile. Lorsqu’une nouvelle machine virtuelle Windows est provisionnée à partir d’une image dans Azure, le pagefile est configuré si cela est possible pour qu’il soit situé sur ce disque temporaire.
Ce stockage temporaire se retrouve alors sur le disque D
Pour la plupart des machines virtuelles Windows, le volume sur le disque temporaire à la lettre de lecteur D:. Il a également l’étiquette de lecteur « Temporary Storage ».
Les clients ne doivent pas utiliser le disque temporaire pour des données qui doivent être persistantes.
Un retour dans la liste des tailles disponibles pour ma machine virtuelle vm001 ne permet pas de choisir une machine virtuelle dépourvue de disque temporaire.
Dans ce cas, pas le choix, la recréation d’une nouvelle machine virtuelle est un passage obligatoire.
Etape I : Créer une sauvegarde du ou des disques présents
Allez sur la page des disques de la machine virtuelle et cliquez sur chacun d’eux
Créez une sauvegarde de chaque disque (OS et Data)
Vérifiez les champs et lancez la création
Une fois terminé, cliquez ici pour accéder au snapshot
Etape II : Créez un ou des disques depuis la ou les sauvegardes
Lancez la création du ou des nouveaux disques depuis le ou les snapshots créés
Une fois terminé, cliquez ici pour accéder au disque créé
Etape III : Création de la nouvelle machine virtuelle
Il ne reste plus qu’à rattacher ce ou ces disques à une nouvelle machine virtuelle
Renseignez tous les champs nécessaires et la nouvelle taille de machine désirée
Lancez la création de la machine virtuelle
Cliquez ici pour retrouver les propriétés de votre nouvelle machine virtuelle
Constatez la bonne taille de votre machine virtuelle Standard D4s v4
Rouvrez une session RDP sur cette nouvelle machine virtuelle pour finaliser les réglages de pagefile. Un message d’avertissement apparaît à l’ouverture de la session
Sélectionnez les paramétrages automatiques Windows
Redémarrez la machine virtuelle pour appliquer les modifications pagefile
Et vous voilà avec la nouvelle taille ????
Conclusion
Azure apporte beaucoup de flexibilité avec le changement de taille pour les machines virtuelles. Il est même possible de scripter le changement de taille selon les besoins ou les pics de charges.
Comme toujours John nous propose une vidéo pour aller plus loin sur ce sujet ????
Sauvegarder ou ne pas sauvegarder ? Telle est la question ! Évidemment, la sauvegarde n’est pas un choix mais bien une nécessité ! Dans cet article, nous allons prendre le temps de nous intéresser aux sauvegardes de machines virtuelles dans un cas très particulier.
Cet article n’a pas pour but de vous parler de la sauvegarde native des machines virtuelles sous Azure, via le service Azure Recovery Service Vault. Cette fonctionnalité est à la portée de tous et fonctionne sans souci.
Mais il arrive dans certains cas que ce service ne fonctionne pas pour certaines machines virtuelles… Voici par exemple le déploiement d’un firewall Fortigate, disponible sur la marketplace d’Azure
Une fois cette machine virtuelle déployée, j’ai rajouté des disques de données supplémentaires à cette dernière
J’ai ensuite créé un Recovery Service Vault pour mettre en place une sauvegarde habituelle
J’ai continué avec la configuration de la police de sauvegarde avec ma machine virtuelle
Seulement l’activation de la sauvegarde Azure me pose quelques soucis
Voici le détail du message d’erreur
{
"status": "Failed",
"error": {
"code": "UserErrorUnSupportedDistribution",
"message": "Unsupported OS version for virtual machine backup."
}
}
Ce problème est visiblement connu sur la toile depuis plusieurs années, mais pour l’instant aucune alternative n’a été proposée par Microsoft. Inutile de penser aux agents MARS ou MABS…
Que faire dans ce cas ?
Il est bien possible de faire des snapshots réguliers … à la main !
En quête d’automatisation, je suis tombé sur plusieurs articles intéressants, assez proche sur la solution apportée :
Azure Automation est un service d’automatisation et de configuration basé sur le cloud qui prend en charge la gestion cohérente de vos environnements Azure et non-Azure. Il comprend l’automatisation des processus, la gestion des configurations, la gestion des mises à jour, les capacités partagées et les fonctionnalités hétérogènes. L’automatisation vous donne un contrôle total pendant le déploiement, l’exploitation et la mise hors service des charges de travail et des ressources.
Dans notre déploiement, nous allons utiliser un compte Azure Automation pour stocker et lancer notre script PowerShell. Ce script prend en compte les disques rattachés à la machine virtuelle afin d’en faire des snapshots pour chacun d’eux.
Etape 0 : Rappel des prérequis
Passé cette rapide explication, nous allons créer différentes ressources sur Azure pour y parvenir. Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration :
Un tenant Microsoft
Une souscription Azure valide
Une machine virtuelle déployée
Etape I : Affectation d’un tag sur la machine virtuelle
Le script va effectuer une recherche sur les machines virtuelles à sauvegarder. Il est nécessaire de marquer celles qui nous intéresse. Rendez-vous sur la machine virtuelle concernée et ajoutez-y le tag suivant :
Nom : Snapshot
Valeur : True
Etape II : Création du compte Azure Automation
Tout commence par la création d’un compte Azure Automation pour héberger notre script PowerShell. Utilisez la barre de recherche du portail Azure pour commencer éa création
Renseignez les éléments de base sur le premier onglet du compte puis lancez directement la création de celui-ci :
Cherchez la section Paramétrages du compte,puis cliquez sur Identité et enfin assignez les rôles Azure
Ajoutez le rôle de Contributeur sur le groupe de ressources contenant la machine virtuelle, puis sauvegardez
Quelques minutes plus tard, constatez la présence de ce dernier dans le tableau précédent
Etape III : Création du Runbook
Continuez avec la création de votre runbook
Renseignez les champs pour valider sa création
La création vous ouvre ensuite l’éditeur de code
Collez le script suivant dans l’éditeur, ou également disponible sur mon GitHub
Cliquez sur le bouton ci-dessous pour démarrer le test
Attendez un peu
Constatez le succès ou l’échec de votre runbook
Retournez sur le groupe de ressources pour y voir apparaître les snapshots des disques
Cliquez sur l’un d’eux et constatez les tags
Etape V : Mise en place de l’automatisation
Une fois constaté le succès de votre script, il ne vous reste qu’à le publier et à le programmer périodiquement. Retournez sur votre runbook et cliquez sur Publier
Ajoutez une programmation périodique sur votre runbook
Cliquez sur le premier lien
Cliquez sur ajouter une programmation
Renseignez les champs selon votre besoin
Confirmez la bonne création de votre programmation
Contrôlez au prochain lancement de la programmation dans le groupe de ressources
Contrôlez également l’historique des lancements du runbook
Conclusion
Et voilà ! Une tâche manuelle de moins… Cette petite opération nous a permis de bien comprendre l’utilité et la puissance des automatismes possibles sur Azure. Celui-ci est bien évidemment très simple, d’autres sont sans doute très intéressants à mettre en oeuvre ????.
Azure Virtual Desktop utilise le protocole RDP (Remote Desktop Protocol) pour établir la connexion avec l’utilisateur. Pour rappel, ce protocole permet de se connecter à des ordinateurs de manière distante. Dans la plupart des cas, cette connexion utilise le protocole TCP pour y parvenir. Le serveur écoute par défaut sur le port TCP 3389.
Il est néanmoins possible de varier cette approche de connexion pour des questions de perfomences et de fiabilité. Depuis déjà l’année dernière, Microsoft proposait la fonctionnalité RDP Shortpath pour améliorer cette connexion, débit et latence, entre l’utilisateur et la machine virtuelle AVD :
RDP Shortpath est une fonctionnalité d’Azure Virtual Desktop qui établit un transport direct basé sur UDP entre le client Remote Desktop et l’hôte de session. RDP utilise ce transport pour fournir le Bureau à distance et le RemoteApp tout en offrant une meilleure fiabilité et une latence constante.
Microsoft Doc
Dans cet article, nous allons regarder en détail cette évolution et effectuer un test sur un environnement AVD. Avant de commencer à manipuler Azure, cette vidéo vous explique très bien l’idée :
L’excellent billet de Denis Gundarev nous explique avec simplicité l’inadéquation entre le protocole TCP pour un besoin RDP :
TCP est un excellent protocole pour la livraison garantie de petites quantités de données. Les applications telles que les navigateurs ou les clients de messagerie se contentent d’envoyer les données et de les oublier. Le protocole assure la cohérence et l’ordre des paquets et relance la transmission si la livraison échoue. Cependant, RDP utilise des connexions de longue durée et les connexions TCP de longue durée sont problématiques.
Le protocole TCP est idéal pour les réseaux locaux, mais pas pour l’Internet. Oui, si le paquet est perdu, il sera retransmis. La disponibilité de la bande passante est un facteur essentiel. Malheureusement, les algorithmes de contrôle de congestion TCP limitent la possibilité de saturer le réseau.
RDH Shortpath s’applique donc sur les réseau publics
Comme son grand frère, cette fonctionnalité établit un flux UDP direct pour RDP. Toutefois, elle ne nécessite pas l’ouverture de ports entrants sur le pare-feu. Au lieu de cela, elle sélectionne automatiquement les conditions du réseau. Elle utilise une combinaison de protocoles de traversée NAT tels que STUN et UPnP et le processus d’établissement de la connectivité interactive (ICE). RDP établit alors le flux UDP direct dans la plupart des configurations de réseau.
Par conséquent, vos utilisateurs bénéficieront d’une latence plus faible, d’une meilleure utilisation du réseau et d’une grande tolérance à la perte de paquets ou aux changements de configuration du réseau.
Et la sécurité ?
RDP Shortpath pour les réseaux publics étend les capacités de multi-transport de RDP. Il ne remplace pas le transport de connexion inverse mais le complète. Le courtage de la session initiale est toujours géré par l’infrastructure Azure Virtual Desktop.
Comment constater le bénéfice ?
Denis nous a même préparé une vidéo pour montrer le bénéfice possible dans la gestion des paquets perdus entre les différents protocoles possibles :
La vidéo de gauche reprend une connexion avec le RDP Shortpath, tandis que celle de droite est en protocole TCP. La vidéo originale en bas de l’écran fait office de référence.
Mise en oeuvre de la solution
Dans un environnement Azure Virtual Desktop, chaque connexion RDP commence par l’établissement du transport de connexion inverse sur la passerelle Azure Virtual Desktop. Après l’authentification de l’utilisateur, le client et l’hôte de session établissent le transport RDP initial, et le client et l’hôte de session commencent à échanger leurs capacités.
Important : comme le rappel la documentation Microsoft, RDP Shortpath configurés sur des réseaux managés est actuellement incompatible avec la prévision de RDP Shortpath pour les réseaux publics.
Comme à chaque article d’Azure Virtual Desktop, vous pouvez suivre les différentes étapes pour mettre en route cette fonctionnalité, toujours en preview à l’heure où ces lignes sont écrites.
Etape 0 : Rappel des prérequis
Des prérequis sont nécessaires pour réaliser cette démonstration AVD :
Un tenant Microsoft
Une souscription Azure valide
Un réseau virtuel existant sur Azure
Un domaine Active Directory synchronisé avec Azure AD via l’agent Azure AD Connect
Une ou des machines virtuelles AVD déployées sur ce même réseau virtuel
Mon environnement Azure Virtual Desktop est donc déjà en place :
Etape I : Test avant modification du RDP Shortpath
Avant d’effectuer les modifications, connectez-vous à votre environnement AVD avec un utilisateur pour constater la connexion RDP via le protocole TCP :
Saisissez vos identifiants pour ouvrir votre session RDP :
Contrôlez la méthode de connexion TCP, mise en place par défaut :
Afin de mettre en place la configuration nécessaire sur les machines virtuelles AVD, il est possible d’y parvenir de plusieurs manières. En voici deux :
Etape IIa : Modifiez la configuration de registre d’une machine virtuelle AVDmanuellement
Fermez la session utilisateur et retournez sur une machine virtuelle via votre portail Azure. Exécutez la commande suivante comme ceci
Attendez quelques minutes et constatez le succès de celle-ci sur le portail Azure
Etape IIb : Modifiez la configuration de registre d’une machine virtuelle AVD via GPO
Au lieu de faire cette modification manuelle sur toutes vos machines virtuelles, vous pouvez également créer une GPO dans votre domaine AD et l’appliquer aux machines AVD.
Connectez à une machine de votre domaine AD pour y créer votre nouvelle GPO
Commencez la création de cette nouvelle GPO sur l’OU correspondante à vos machines AVD
Nommez votre GPO à votre convenance
Editez-là avec un clic droit
Créez y un nouvel objet de registre comme ceci
Descendez dans l’arborescence suivante et sélectionnez là :
Ajoutez-lui les propriétés suivantes et cliquez sur OK
Redémarrez les machines virtuelles AVD pour une bonne prise en compte de cette nouvelle GPO
Etape III : Test après modification du RDP Shortpath
Comme au premier essai, reconnectez-vous à votre environnement AVD avec un utilisateur de test, puis constatez le changement de protocole UDP :
Rien de bien compliqué ????.
Evidemment, Microsoft prévoit aussi des ajouts de règles firewall pour les machines virtuelles AVD et pour les machines clients. Ces opérations sont nécessaires si le protocole UDP est à l’origine bloqué.
Conclusion
Cette nouvelle fonctionnalité est donc une façon facile d’améliorer l’expérience de vos utilisateurs sans mettre en défaut la sécurité à travers des réseaux publics.
Pour finir et vous aider dans cette démarche, Dean nous a même préparé un seconde vidéo sur la chaine YouTube et dédiée à cette évolution du RDP Shortpath, encore en préversion !
