Azure Virtual Desktop ❤️ FIDO2

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

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

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

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

FIDO Alliance

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

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

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

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

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

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

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

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

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

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

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

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

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

Où peut-on se procurer des clefs FIDO2 ?

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

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

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

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

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

Etape 0 – Rappel des prérequis :

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

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

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

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

Etape I – Configuration du code PIN :

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

Cliquez ici pour configurer la clef :

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

Définissez un code PIN et confirmez-le :

Etape II – Activation de FIDO2 sur Azure AD :

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

Cliquez sur Méthodes d’authentification :

Cliquez sur la ligne FIDO2 :

Activez la fonctionnalité FIDO2, puis cliquez sur Configurer :

Sauvegardez-là avec les options de base :

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

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

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

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

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

Cliquez ici pour ajouter la première clef FIDO2 :

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

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

Azure AD entame une communication avec la clef FIDO2 :

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

Renseignez le PIN de votre clef FIDO2, puis continuez :

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

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

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

Etape IV – Test de FIDO2 :

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

Cliquez-ici pour vous authentifier :

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

Renseignez le code PIN de votre clef FIDO2 :

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

Cliquez enfin sur Non :

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

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

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

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

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

Ouvrez le menu Sécurité :

Cliquez sur Méthodes d’authentification :

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

Terminez la création de celle-ci :

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

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

Créez votre nouvelle Police :

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

Ajoutez l’application Azure Virtual Desktop :

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

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

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

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

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

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

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

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

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

Attendez que le processus continue :

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

Renseignez le code PIN de votre clef FIDO2 :

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

Attendez que la session AVD s’ouvre :

Conclusion

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

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

Privatisez l’accès de votre AVD

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 :

Qu’est-ce qu’Azure Private Link ?

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 virtuel Azure

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 resourceType de sous-resourceQuantité
Microsoft.DesktopVirtualization/workspacesglobalUn pour tous les déploiements Azure Virtual Desktop
Microsoft.DesktopVirtualization/workspacesfeedUn par workspace
Microsoft.DesktopVirtualization/hostpoolsconnectionUn 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 :

aka.ms/wvdarmweb

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 ????

Architecte en cybersécurité Microsoft (SC-100)

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.

Microsoft Learn

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 !

Voici la liste des examens accessibles via ce voucher Ignite :

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

Bon examen ????

Conditionnez l’accès de votre AVD

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.

Microsoft Doc

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.

Doc Microsoft

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 votre propre 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 ????

Configurer l’autorisation multi-utilisateur pour Azure Backup

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Microsoft Doc

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

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

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

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

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

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

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

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

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

Où doit se trouver Azure Resource Guard ?

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

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

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

Etape 0 : Rappel des prérequis

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

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

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

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

Nous avons donc les deux environnements Azure suivants :

Tenant A.

Etape I : Création d’Azure Resource Guard

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

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

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

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

Cliquez alors sur celui-ci puis sur Enregistrer :

Attendez quelques minutes que le traitement se termine :

Contrôler le nouveau statut du resource provider :

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

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

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

Lancez la création de votre Azure Resource Guard :

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

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

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

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

Ajoutez votre Administrateur sauvegarde :

Cliquez pour valider :

Etape II : Création du coffre de sauvegarde

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

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

Etape III : Protégez votre coffre de sauvegarder

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

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

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

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

Sauvegardez la configuration MUA de votre coffre de sauvegarde :

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

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

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

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

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

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

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

Etape IV : Sauvegardez votre la machine virtuelle avec MUA

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

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

Continuez la configuration avec la famille de ressources Machine virtuelle :

Ajoutez votre machine virtuelle à sauvegarder :

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

Activez la mise en place de la sauvegarde :

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

Cliquez ici pour afficher les détails :

Lancez une sauvegarde immédiate :

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

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

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

Que peut-on encore mettre en place ?

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

Microsoft Doc

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

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

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

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

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

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

Sur le tenant B, recherchez le service Azure suivant :

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

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

Ajoutez un nouvel assignement :

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

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

Etape VI : Mise en place du processus de validation

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

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

Cliquez sur le rôle Contributeur :

Cliquez sur Modifier :

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

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

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

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

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

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

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

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

Cliquez sur Mes Rôles :

Cliquez sur Ressources Azure puis sur Activer :

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

La notification Azure suivante doit apparaître :

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

Cliquez sur Ressources Azure et approuvez la demande :

Confirmez la demande d’approbation :

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

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

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

Conclusion

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

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

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

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

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 :

Ne jamais faire confiance, toujours vérifier

Comment le comprendre ?

Considérez simplement chaque demande d’accès comme potentiellement suspecte. Pour cela, Microsoft met à disposition plusieurs ressources :

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 :

Etape VIII : Certifications de Sécurité Microsoft

Voici un rappel du poster des certifications Cloud proposées par Microsoft. Ce document est utile car il contient toutes les certifications disponibles dans les 4 thèmes :

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.

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

La donnée est une valeur critique pour tout entreprise. L’impact des ransomwares entraînant des blocages complets de productivité n’est plus à démontrer. Les attaques contre des hôpitaux montre l’absence de moralité et le large spectre pour les attaquants. De plus, le respect des normes (ex. respect de la vie privée) ou en regard avec le secteur concerné élève toujours plus haut le besoin de maîtriser la sécurité des données.

A la suite de renommages de produits, Microsoft Purview devient le centre névralgique pour la gouvernance, la protection et la gestion des données. Il s’agit donc d’une fusion entre Azure Purview et Microsoft 365 Compliance.

Microsoft Purview (anciennement Azure Purview)

Microsoft Purview est une solution unifiée de gouvernance des données qui vous aide à gérer et à gouverner vos données sur site, multicloud et SaaS (Software-as-a-Service). Créez facilement une carte holistique et actualisée de votre paysage de données avec la découverte automatisée de données, la classification des données sensibles et le lignage des données de bout en bout. Permettez aux consommateurs de données d’accéder à une gestion des données précieuse et fiable.

Azure Doc

La donnée est une des valeurs les plus importantes 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 actions :

  • Connaissez vos données : toutes les données n’ont pas le même impact et ne doivent donc pas être protégées de la même manière. La connaissance des données à protéger apporte une meilleure connaissance des risques possibles. Par exemple, des données personnelles peuvent être chiffrées et/ou supprimées pour le respect de certaines normes.
  • Protégez vos données : Une fois la donnée identifiée, différentes mesures de protection sont applicables à celle-ci. Un autre exemple est la restriction d’accès. Tous les salariés d’une entreprise n’ont pas besoin de voir toutes les données de celle-ci. La gestion granulaire des droits et la vérification régulière de leur utilité apporte un gage de sécurité supplémentaire.
  • Prévenez la fuite de données : La donnée doit en accès restreint. Un partage interne / externe de données sensibles doit être empêché ou alerté. L’utilisation de labels de sensibilité est une bonne méthode pour y appliquer des règles particulières selon le type de données.

Cycle de vie de la donnée

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.

Les types d’informations à protéger dépendent de vos exigences de sécurité internes et de vos obligations de conformité.

Chaque organisation peut avoir des normes de gouvernance ou de conformité différentes, il est important de permettre la personnalisation des politiques de classification.

Finalement, les fonctions de classification des données vous aident à mieux comprendre ce qui est utilisé, afin que vous puissiez mettre en place les bonnes politiques pour les protéger et les gérer.

Protection de la donnée

L’étiquetage de la donnée est indispensable pour comprendre d’où elle vient et où elle part, la protéger quel que soit l’endroit où elle se trouve durant le transit, la conserver et la supprimer selon chaque finalité. Pour cela, l’affectation d’étiquettes de sensibilité, des étiquettes de conservation et une classification par type d’information sensible.

Il existe plusieurs façons de procéder à la découverte, à l’évaluation et au marquage, mais le résultat attendu est de voir un très grand nombre de documents et de courriels marqués et classés avec des étiquettes.

Après avoir appliqué vos étiquettes de conservation et de sensibilité, il est possible de voir comment les étiquettes sont utilisées dans votre tenant et ce qui est fait avec ces éléments, comme par exemple :

  • Le nombre d’éléments qui ont été classés comme un type d’information sensible
  • Les étiquettes de sensibilité les plus appliquées
  • Les étiquettes de conservation les plus appliquées
  • Un résumé des activités que les utilisateurs effectuent sur votre contenu sensible
  • Les emplacements de vos données sensibles et conservées

Compliance Secure Score

Comme pour Defender for Cloud, Microsoft apporte un score de sécurité dédié au Compliance Manager. Ce score est le reflet des actions d’amélioration recommandées par Microsoft. Votre score peut vous aider à comprendre votre situation actuelle en matière de conformité. Il peut également vous aider à prioriser les actions en fonction de leur potentiel de réduction des risques.

Rappel des chapitres de l’article

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

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

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

Azure Advisor

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

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

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

Les premières recommandations sont pleines de bon sens :

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

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

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

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

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

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

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

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

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

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

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

Azure Defender for Server

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

Microsoft Doc

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

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

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

Particularité Azure :

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

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

Azure Backup

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

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

Azure Disaster Recovery

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

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

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

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

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

Verrous Azure

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

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

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

  • Souscription Azure
  • Groupe de ressource
  • Azure

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

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

Rappel des chapitres de l’article

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

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

Comme vous le savez déjà, 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.

Microsoft propose donc un grand nombre d’outils combinables pour renforcer la sécurité des identités d’Azure AD. Certains sont disponibles gratuitement, tandis que d’autres nécessiteront une licence par utilisateur.

J’ai en sélectionné plusieurs dans mon article. L’ordre des outils présentés n’est pas nécessairement un ordre de mise en place.

Gouvernance des identités Azure AD (Azure AD Identity Governance)

Afin de garder la main sur les identités dans la durée, la gouvernance des identités est une excellente solution pour clôturer les accès inutiles ou périmés. Microsoft nous explique comment il faut voir cela :

La gestion du cycle de vie des identités constitue le fondement d’Identity Governance. Une gouvernance efficace à grande échelle implique la modernisation de l’infrastructure de gestion du cycle de vie des identités pour les applications.

Microsoft Doc

Gestion des rôles Azure / Azure AD (Role-Based Access Control – RBAC)

L’attribution permanente de rôles Azure / Azure AD est gratuite et très pratique. Mais en tant que premier gage de sécurité pour les identités, il est primordial de ne distribuer les rôles qu’en fonction des vrais besoins, en partant toujours de l’attribution minimale des droits dans le temps.

Avec Azure RBAC, vous pouvez séparer les tâches au sein de votre équipe et accorder aux utilisateurs uniquement les accès nécessaires pour accomplir leur travail. Lorsque vous planifiez votre stratégie de contrôle d’accès, vous pouvez accorder aux utilisateurs les privilèges minimaux pour effectuer leur travail. Évitez d’attribuer des rôles plus larges à des étendues plus importantes, même s’ils semblent plus pratiques dans un premier temps.

Microsoft Doc

Authentification multifacteur (Azure AD Multi-Factor Authentication – MFA)

L’utilisation d’un mot de passe uniquement ne protège pas complètement des attaques. Si le mot de passe est faible ou s’il a été exposé ailleurs, un attaquant peut l’utiliser pour y accéder. Quand vous exigez une deuxième forme d’authentification, la sécurité est renforcée parce que ce facteur supplémentaire n’est pas un élément qu’un attaquant peut facilement obtenir ou dupliquer.

Microsoft Doc

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)
Ecran de configuration utilisateur pour configurer la sécurité MFA

La MFA est gratuite pour certains rôles administrateurs Azure AD, mais nécessitera une licence Azure AD Premium P1/P2 pour les autres.

Accès conditionnel (Azure AD Conditional Access)

L’authentification multifacteur est approche de sécurité combinable avec un accès conditionnel. La mise en place d’une stratégie d’accès conditionnel via l’exploitation de signaux renforce la sécurité :

Les stratégies d’accès conditionnel, dans leur forme la plus simple, sont des instructions Si-Alors : si un utilisateur souhaite accéder à une ressource, il doit effectuer une action. Exemple : Un responsable paie souhaite accéder à l’application de paie et il doit effectuer une authentification multifacteur pour y accéder.

Microsoft Doc
Signal conditionnel conceptuel + Décision = Application

L’accès conditionnel repose donc sur l’étude d’une liste des signaux envoyés lors de la connexion, comme par exemple :

  • Identifiant utilisateur (UPN)
  • Localisation (Adresse IP, pays, coordonnées GPS, …)
  • Appareil (Type d’appareil, état, …)
  • Application cible (Azure, Office 365, Salesforce, Azure Virtual Desktop, …)
  • Risque potentiel (Faible, Moyen ou Haut). Signal propre Azure AD Identity Protection

Une fois les signaux pris en compte, une décision en résulte :

  • Bloquer l’accès
  • Accorder l’accès avec une ou des conditions suivantes : exiger une authentification multifacteur, que l’appareil soit marqué comme conforme, que l’appareil soit joint à Azure AD en mode hybride, …

L’accès conditionnel ne finit pas systématiquement à la connexion, il peut encore continuer au sein même de l’application cible via des restrictions fonctionnelles.

Protection de l’identité (Azure AD Identity Protection)

Pour protéger vos utilisateurs, Azure AD Identity Protection s’appuie sur les connaissances acquises par Microsoft au niveau des organisations avec Azure AD, de l’espace grand public avec les comptes Microsoft et des jeux avec Xbox. Microsoft analyse 6 500 milliards de signaux par jour pour identifier les menaces et protéger les clients.

Microsoft Doc

Comme le montre le schéma ci-dessous, Azure AD Identity Protection est lui aussi un composant utilisable dans un stratégie d’accès conditionnel :

Chaque jour, nos systèmes d’apprentissage automatique et heuristiques fournissent des scores de risque pour 18 milliards de tentatives de connexion correspondant à plus de 800 millions de comptes distincts, dont 300 millions relèvent de manière perceptible d’adversaires (entités telles que des auteurs malveillants et des pirates informatiques).

Alex Weinert

Mais ce n’est pas tout, son analyse est aussi exportable et intégrable dans un outil SIEM (Security Information and Event Management) pour un examen et une exploitation plus poussés.

Attention, Azure AD Identity Protection nécessite une licence Azure AD Premium P2 par utilisateur.

Revues d’accès (Azure AD Access Reviews)

Une revue d’accès est un examen, généralement périodique, des besoins d’accès à une ressource. Ce dernier est réalisé en auto-contrôle ou par supervision.

Azure AD permet aux organisations de gérer efficacement les appartenances à des groupes, l’accès aux applications d’entreprise et l’attribution de rôles. L’accès des utilisateurs peut donc être revu régulièrement pour s’assurer que seules les bonnes personnes ont encore un accès :

Pourquoi les révisions d’accès périodiques sont-elles si importantes ?

Azure AD vous permet de collaborer avec des utilisateurs à l’intérieur de votre organisation ainsi qu’avec des utilisateurs externes. Les utilisateurs peuvent se joindre à des groupes, inviter des personnes, se connecter à des applications cloud et travailler à distance à partir de leurs appareils personnels ou professionnels. L’intérêt d’utiliser le libre-service a conduit à la nécessité d’avoir de meilleures fonctionnalités de gestion des accès.

Microsoft Doc
Attention, Azure AD Access Reviews nécessite lui aussi une licence Azure AD Premium P2 par utilisateur.

Gestion des identités privilégiées (Azure AD Privileged Identity Management – PIM)

Nous avons parlé de la gestion des rôles Azure et Azure AD via RBAC. PIM est un second outil intégré à RBAC en instaurant un processus d’attribution des rôles via le couple demande / approbation.

Cette approche facile la gestion, le contrôle et la supervision des accès de vos utilisateurs dans votre tenant et en fonction du contexte (besoin, durée, justification).

Attention, Azure AD Privileged Identity Management nécessite lui aussi une licence Azure AD Premium P2 par utilisateur.

Azure AD et la sécurité

Afin de vous faire une synthèse des différentes mesures abordés et d’autres, j’ai retrouvé cette vidéo qui devrait vous éclaircir un peu :

Rappel des chapitres de l’article

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

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

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

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

Azure VPN

Azure VPN est un service managé par Microsoft :

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

Microsoft Doc

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

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

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

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

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

Azure ExpressRoute

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

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

Les principaux avantages de la connexion ExpressRoute sont :

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

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

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

Des formules annexes d’ExpressRoute existent comme :

Azure Network Security Group (NSG)

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

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

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

Azure Application Security Group (ASG)

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

Azure Bastion

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

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

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

Azure Firewall

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

Rappel des chapitres de l’article

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