Catégorie : Sécurité

Azure Lighthouse prend le contrôle

Azure Lighthouse existe déjà depuis longtemps. Mais je souhaitais malgré tout en faire un article car il est très utile dans bien des cas car il facilite grandement la gestion de ressources réparties sur plusieurs tenants Microsoft. Cela s’adapte donc parfaitement aux prestataires ou fournisseurs de services Cloud.

Qu’est-ce qu’Azure Lighthouse ?

Azure Lighthouse permet une gestion multi-locataire avec de la scalabilité, une automatisation plus poussée et une gouvernance renforcée des ressources.

Microsoft Learn

En d’autres termes, Azure Lighthouse vous permet d’accéder à plusieurs tenants en simultané. Cela permet de visualiser un ensemble de ressources Azure réparties sur plusieurs tenants dans une seule et unique vue.

Grâce à Azure Lighthouse, vous allez pouvoir :

  • Créer une relation sécurisée entre vous et vos clients gérés.
  • Fournir une transparence et à la demande sur l’accès et les actions.
  • Permettre une gestion granulaire de l’accès à l’ensemble du parc Azure.

Vous pouvez gérer plusieurs clients dans un seul Azure Lighthouse. Vous devez simplement définir comment vos équipes accéderont aux ressources des clients :

Pourquoi utiliser Azure Lighthouse pour un client ?

  • Gardez le contrôle : Ajoutez, modifiez ou retirez les droits des intervenants externes à tout moment grâce à la relation fournisseur de services / client établie via Azure Lighthouse.
  • Conservez la sécurité : Fournissez un accès granulaires aux fournisseurs de services, à des niveaux spécifiques (souscription ou groupe de ressources), et à des groupes d’utilisateurs définis, pour un accès permanent ou temporaire.
  • Restez informé : Veillez à ce que vos données soient toujours sécurisées et ne quittent pas votre environnement, tout en ayant une visibilité sur les actions et les changements effectués par vos fournisseurs de services.

Comment Azure Lighthouse fonctionne ?

Pour qu’Azure Lighthouse puisse fonctionner, il est nécessaire de disposer de :

  • Utilisateurs, groupes ou principaux de service provenant du tenant du fournisseur.
  • Rôles RBAC à appliquer sur les ressources du client.

Ces 2 éléments (Rôles + identités) sont alors combinés dans un template généré au format JSON depuis le tenant du fournisseur, puis exécuté sur le tenant du client.

C’est aussi simple que cela !

Note : A la place de la génération d’un template JSON, il est aussi possible de passer par la publication d’une offre fournisseur sur la Marketplace Azure.

Combien cela coûte ?

L’utilisation d’Azure Lighthouse est gratuite pour les clients et pour les fournisseurs.

Azure Lighthouse, qui s’appuie sur la technologie de gestion des ressources déléguées d’Azure, est donc disponible sans frais supplémentaires :

Quelles sont les étapes pour mettre en place Azure Lighthouse ?

Azure Lighthouse est donc configurable de plusieurs manières :

Afin de faire au plus simple dans cet article, je vous propose, au travers d’un petit exercice, de tester la seconde méthode :

Etape 0 – Rappel des prérequis :

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

  • Deux tenants Microsoft (fournisseur / client)
  • Tenant fournisseur :
    • Un utilisateur avec des droits d’administrateur
  • Tenant client :
    • Une souscription Azure valide
    • Un utilisateur avec rôle de Propriétaire sur la souscription Azure

Afin d’identifier plus facilement les deux tenants Azure, je vous propose de configurer les couleurs du portail Azure comme ceci :

  • Portail Azure clair : tenant fournisseur
  • Portail Azure sombre : tenant client

Commençons par la configuration du tenant du fournisseur.

Etape I – Configuration du tenant fournisseur :

Connectez-vous au tenant du fournisseur afin de créer un nouveau groupe Entra ID dédié à Azure Lighthouse :

Ajoutez dans ce nouveau groupe les membres nécessaires pour tester par la suite le bon fonctionnement de l’accès aux ressources Azure situées sur le tenant du client :

Toujours sur le tenant du fournisseur, utilisez la barre de recherche comme ceci :

Cliquez sur Créer un modèle ARM (Azure Resource Manager) :

Nommez le nom de votre template ARM, puis cliquez-ici pour ajouter des autorisations RBAC :

Recherchez le groupe créé précédemment , ajoutez une autorisation que vous accorderez à vos utilisateurs d’Azure Lighthouse, puis définissez si les droits sont permanents ou éligibles :

Pour les droits éligibles, vous devrez configurer Lighthouse avec Azure AD PIM, qui est disponible dans la licence Entra ID Premium P2.

Cliquez sur le bouton Voir le modèle :

Cliquez sur le bouton Télécharger :

La configuration du tenant fournisseur est maintenant terminée

Ce template au format JSON est utilisable autant de fois que nécessaire, tant que les accès aux ressources Azure des clients sont identiques.

La suite se passe maintenant sur le tenant du client.

Etape II – Configuration du tenant client :

Connectez-vous au tenant du client où se trouve la souscription ou le groupe de ressources que vous souhaitez gérer.

Avant de mettre en place Azure Lighthouse, prenez le temps de vérifier sur la souscription Azure le bon enregistrement du fournisseur de ressources suivant :

Utilisez la barre de recherche comme ceci :

Cliquez ici pour voir les offres des prestataires de services :

Dans le menu Offres des prestataires de services, cliquez sur Ajouter une offre, puis sélectionnez Ajouter par le biais d’un modèle :

Téléchargez le modèle que vous avez créé précédemment :

Sélectionnez la souscription Azure, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du lien Azure Lighthouse :

Attendez environ deux minutes :

La configuration est maintenant en place. Avant de créer une nouvelle ressource Azure, nous allons contrôler le lien établi.

Etape III – Contrôle de la configuration :

Toujours sur le tenant du client, rendez-vous dans le menu suivant afin de constater l’apparition de la délégation créée précédemment :

Retournez sur le tenant du fournisseur afin de constater l’apparition du client dans le menu suivant :

Cliquez sur le bouton de paramétrage du portail Azure afin de voir dans la liste des tenants et des souscriptions provenant du tenant du client :

Toujours sur le tenant fournisseur, vérifiez la présence de la souscription client dans la liste des souscriptions Azure, puis cliquez dessus :

Contrôlez la désactivation des fonctions d’assignation car le rôle de propriétaire n’est pas disponible via Azure Lighthouse :

L’environnement client est maintenant correctement configuré.

Afin de vérifier le bon fonctionnement, je vous propose créer une nouvelle machine virtuelle sur la souscription Azure du client, depuis le tenant du fournisseur.

Etape IV – Création d’une machine virtuelle Azure :

Encore sur le tenant fournisseur, cliquez-ici pour créer une machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM en choisissant bien la souscription Azure du tenant du client, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 2 minutes que le déploiement se termine :

Retournez sur le portail Azure du tenant du client afin de vérifier la bonne apparition de la machine virtuelle créée depuis le tenant du fournisseur :

Contrôlez les droits RBAC présents sur cette machine virtuelle :

Notez l’absence de droits RBAC, directs ou hérités, des utilisateurs d’Azure Lighthouse.

La création des ressources est bien possible grâce à la mise en place d’un rôle RBAC de contributeur au travers d’Azure Lighthouse.

La suppression des ressources Azure depuis le tenant du fournisseur fonctionne elle aussi sans souci :

Etape V – Modification des ressources gérées par Azure Lighthouse :

La modification ou l’ajout des ressources gérées par Azure Lighthouse est possible depuis le tenant client, sans besoin de réutiliser le template JSON du fournisseur :

Là encore, la suppression de droits sur une souscription Azure est possible à tout moment depuis le tenant du client :

Conclusion :

En quelques clics, nous avons mis en place une délégation de ressources Azure en place. Bravo ! Bien évidemment, cette liaison d’Azure Lighthouse est aussi compatible avec Microsoft Entra Privileged Identity Management.

Enfin, voici comme toujours une vidéo de John Savill qui en parle très bien :

Organisez-vous grâce au multi-tenants

Microsoft propose depuis quelques temps déjà plusieurs options pour gérer les organisations réparties sur plusieurs tenants Cloud. Par exemple, la synchronisation entre tenants a été introduite en janvier de cette année. Depuis, les choses continuent de progresser grâce à l’arrivée d’un nouveau niveau : l’organisation multi-tenants = regroupement de plusieurs tenants B2B dans un seul ensemble ayant des facultés de synchronisation.

Avant de tester la création d’une organisation multi-tenants sur mon environnement de démonstration, faisons d’abord un bref rappel de quelques notions importantes sur les tenants Microsoft.

Qu’est-ce qu’un tenant Microsoft ?

Nous pourrions traduire le mot anglais Tenant par locataire. Dans l’univers du Cloud Microsoft, le terme Tenant désigne le périmètre (le Cloud) dans laquelle vos données sont stockées. Ainsi chaque client possède sa propre sphère, son propre Tenant.

Voici d’ailleurs la définition selon Microsoft :

Un locataire est une instance d’Azure AD dans laquelle résident des informations sur une seule organisation, y compris des objets organisationnels tels que des utilisateurs, des groupes et des appareils, ainsi que des inscriptions d’applications, telles que Microsoft 365 et des applications tierces.

Microsoft Learn

Qu’est-ce que la synchronisation multi-tenants ?

La synchronisation multi-tenants d’Entra ID est un mécanisme qui facilite la création, la modification et la suppression des utilisateurs à travers plusieurs tenants via un système automatisé et géré par Microsoft :

Son objectif principal est d’assurer une collaboration transparente entre les tenants d’une même organisation, tout en rationalisant la gestion des comptes utilisateurs B2B dans un environnement multi-tenants.

Une vidéo de John en parle d’ailleurs très bien :

Concernant la gestion d’identités externes au tenant, Microsoft propose également d’autres fonctionnalités comme par exemple :

Qu’est-ce qu’une organisation multi-tenants ?

Nous sommes ici à un niveau plus élevé que le tenant unique, nous parlons ici de fédérer plusieurs tenants Microsoft.

L’image ci-dessous montre 2 tenants Microsoft distincts, contenant chacun des utilisateurs présents dans chacun d’eux (Entra ID) :

Microsoft a développé ce niveau pour répondre à plusieurs demandes :

Une organisation multilocataire est une organisation qui a plusieurs instances d’Azure AD. Voici les principales raisons pour lesquelles une organisation peut avoir plusieurs locataires :

  • Conglomérats : les organisations avec plusieurs filiales ou unités commerciales qui fonctionnent indépendamment.
  • Fusions et acquisitions : organisations qui fusionnent ou acquièrent des sociétés.
  • Activité de cession : dans le cadre d’une cession, une organisation fractionne une partie de ses activités pour former une nouvelle organisation ou la vendre à une organisation existante.
  • Plusieurs clouds : les organisations dont la conformité ou la réglementation doivent exister dans plusieurs environnements cloud.
  • Plusieurs limites géographiques : organisations qui opèrent dans plusieurs emplacements géographiques avec différentes réglementations de résidence.
  • Locataires de test ou intermédiaires : organisations qui ont besoin de plusieurs locataires à des fins de test ou de préproduction avant de procéder à un déploiement plus large sur des locataires principaux.
  • Locataires créés par un service ou un employé : organisations où des services ou des employés ont créé des locataires pour le développement, le test ou le contrôle distinct.
Microsoft Learn

Pour vous donner un exemple concret, ce scénario peut se présenter quand une entreprise en rachète d’autres. Bien souvent, celles-ci ont chacune un environnement 365 déjà en place, et l’idée d’une migration de tenant à tenant est considérée comme trop lourde.

Pour faire simple, l’organisation à multi-tenants continue elle aussi de s’appuyer sur la synchronisation entre tenants d’Entra ID : Les utilisateurs de votre tenant sont alors provisionnés dans les autres tenants de l’organisation en tant qu’utilisateurs de collaboration B2B.

Peut-on gérer une organisation multi-tenants dans Microsoft 365 ?

Au-delà les différents mécanismes possibles de collaboration sur Entra ID, Microsoft a rajouté ce niveau d’organisation multi-tenants dans la console d’administration de Microsoft 365 :

Note : L’activation antérieure de la synchronisation entre tenants d’Entra ID ne gêne en rien la mise en place d’une organisation multi-tenants. Celles-ci continueront toujours de fonctionner :

Afin de se faire une meilleure idée de l’ensemble de tenants, je vous propose de mettre en place une organisation multi-tenants à partir de 2 tenants B2B non connectés.

Voici les différentes étapes de l’exercice que je vous propose :

Commençons d’abord par détailler les prérequis et l’environnement de départ pour nos tests.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la migration Active Directory vers Azure, il vous faudra disposer de :

  • 2 tenants Microsoft avec des licences 365
  • Une souscription Azure valide pour la création des machines virtuelles de test

Dans mon exemple, mes deux tenants de test sont issus du Microsoft 365 Developer Program. Voici la vue de mes deux tenants de test :

  • JLO Tenant A // jean0loup.onmicrosoft.com
  • JLO Tenant B // tdsynnexchlab.onmicrosoft.com

Chacun de mes 2 tenants dispose d’utilisateurs avec des licences Microsoft 365 E5 Dev :

Dans chacun des tenants de test, j’ai créé également 2 groupes de 3 d’utilisateurs chacun :

Enfin pour les tests, j’ai également créé 2 machines virtuelles de test pour la démonstration côté utilisateur :

Sur ces 2 machines virtuelles hébergées sur Azure, j’y ai installé la suite office 365 + Teams :

J’ai installé Microsoft Teams par ce lien :

Avant la moindre configuration, j’ai testé le bon fonctionnement du chat EXTERNE de Teams entre 2 utilisateurs des 2 tenants :

Microsoft nous le rappelle bien : tenanta user1 fait partie d’une organisation. Il est possible qu’ils aient des politiques liées aux messages qui s’appliquent au chat.

Nous allons donc maintenant déployer une organisation multi-tenants depuis la console d’administration de Microsoft 365.

Etape I – Configuration de l’organisation multi-tenants :

La fonction d’organisation multi-tenants est encore en préversion à l’heure où ces lignes sont écrites. Il est donc nécessaire d’activer l’option de livraison ciblée sur les 2 tenants de test.

Pour cela, rendez-vous sur la page d’administration de Microsoft 365, puis dans le menu ci-dessous afin d’activer l’option suivante :

Attendez quelques minutes, puis rafraîchissez cette même page afin de voir apparaître le menu suivant :

Effectuez cette opération sur les 2 tenants.

Dans ce menu, commencez par démarrer le processus de mise en place de l’organisation multi-tenants en cliquant ici :

Sélectionnez le premier choix afin de créer l’organisation multi-tenants :

Avant d’aller plus loin, ouvrez un second navigateur internet afin de copier sur cette page l’identifiant tenant ID du second environnement :

Renseignez les champs et collez le tenant ID récupéré précédemment :

Cliquez sur Suivant :

Cochez les deux cases suivantes pour valider la synchronisation entrante, puis cliquez sur Suivant :

Cliquez sur le bouton ci-dessous pour valider et démarrer le processus de création de l’organisation multi-tenants :

Copiez le lien ci-dessous afin de terminer le processus de création dans le second tenant de test :

Dans votre second navigateur, rendez-vous sur le lien copié précédemment, puis cliquez-ici pour valider la synchronisation entrante :

Cliquez sur Terminer :

Le message suivant apparaît pour vous indiquer que le processus d’intégration du second tenant est en cours. Cliquez-ici plusieurs fois pour rafraichir le processus :

Quelques minutes plus tard, le lien de synchronisation est bien confirmé dans sur les deux tenants de notre organisation multi-tenants :

Sur les 2 tenants, cliquez ici pour partager un groupe d’utilisateurs vers l’autre tenant :

Après cela, cliquez sur les deux tenants de destinations afin de vérifier la bonne prise en compte des utilisateurs présentes dans vos 2 groupes Entra ID à synchroniser :

La configuration de l’organisation multi-tenants depuis le portail d’administration de Microsoft 365 est maintenant terminée. La synchronisation multi-tenants devrait se lancer sous peu.

Afin d’en savoir un peu plus, rendez-vous sur le portail d’Entra ID juste ici.

Etape II – Configuration de la synchronisation multi-tenants :

Grâce à la configuration de l’organisation multi-tenants, Entra ID a automatiquement préconfiguré la synchronisation multi-tenants.

Cliquez sur le menu suivant d’Entra ID pour découvrir les paramétrages effectués sur vos 2 tenants :

Cliquez sur les 2 configurations créées :

Visualisez les différentes informations disponibles, dont l’intervalle d’approvisionnement fixe :

Configurez-ici si besoin les notifications par email, puis sauvegardez :

Analysez les personnalisations possibles concernant les attributs d’Entra ID :

Quelques minutes plus tard, retournez sur les listes d’utilisateurs respectives de vos 2 tenants afin de constater l’apparition d’utilisateurs synchronisés :

Notez l’absence de synchronisation des groupes Entra ID, seuls des utilisateurs des groupes sélectionnés sont synchronisés :

Consultez et comparez sur les 2 tenants les propriétés synchronisées (ou non) d’un utilisateur concerné :

Il est également possible de lancer, sans attendre, une synchronisation manuelle.

Afin de tester cela, renseignez un titre de poste sur un autre utilisateur synchronisé :

Rendez-vous dans le menu suivant pour lancez la synchronisation à la demande :

Recherchez l’utilisateur à synchroniser, puis démarrez le traitement :

Attendez quelques secondes, puis constatez le changement de titre de poste sur le second tenant :

A noter qu’il n’est pas possible d’effectuer la synchronisation inverse depuis le tenant de destination :

Notre configuration est maintenant en place. Nous allons pouvoir effectuer différents tests entre nos deux utilisateurs de test :

  • tenanta-user1@jean0loup.onmicrosoft.com
  • tenantb-user1@tdsynnexchlab.onmicrosoft.com

Pour rappel, ces utilisateurs sont représentés de la façon suivante dans les 2 tenants de destination :

  • tenantb-user1_tdsynnexchlab.onmicrosoft.com#EXT#@jean0loup.onmicrosoft.com
  • tenanta-user1_jean0loup.onmicrosoft.com#EXT#@tdsynnexchlab.onmicrosoft.com

Etape III – Test de Microsoft Teams :

Depuis les 2 machines virtuelles, ouvrez le client Microsoft Teams. Pour une meilleure expérience utilisateur, activez le nouveau Teams :

Depuis l’écran des paramétrages de Teams, activez la prise en charge des 2 tenants :

Sur le 2 sessions Teams, recherchez les utilisateurs invités respectifs. Notez la présence d’utilisateurs externes précédemment utilisés pour communiquer :

Commencez la communication sur les utilisateurs NON EXTERNE :

Notez les points suivants :

  • La présence de 2 notifications Windows respectives
  • La présence de 2 notifications Teams respectives
  • L’incohérence dans le fil de discussion dans l’écran en tâche de fond

Un clic sur les 2 notifications Teams respectives permet de permuter sur le second tenant :

De retour sur les tenants de départ, commencez la création d’une équipe Teams :

Ajoutez dans celle-ci l’utilisateur invité du second tenant, puis cliquez sur Ajoutez :

Postez un nouveau message d’équipe en citant le second utilisateur comme ceci, afin de constater l’absence de notifications Teams :

Enfin, testez la fonctionnalité d’appel de Teams afin de constater la présence de notifications sur le second utilisateur :

Les quelques tests sur Microsoft Teams ont pu démontrer une bonne intégration des environnements multi-tenants, mais des efforts sur les notifications sont encore à faire.

Pour l’instant, je trouve que la communication via des comptes utilisateurs EXTERNES est encore plus simple.

Continuons les tests avec SharePoint Online.

Etape IV – Test de SharePoint Online :

Créez un nouveau site SharePoint online avec des droits au second utilisateur de test, puis ajoutez-y des fichiers.

Copiez / collez l’URL du site SharePoint Online dans la navigateur de la second VM, puis authentifiez-vous :

Vérifiez la bonne ouverture d’un des fichiers présents :

SharePoint Online fonctionne donc sans souci avec les utilisateurs synchronisés, continuons avec Exchange Online.

Etape V – Test d’Exchange Online :

Configurez une boite mail partagée sur un des 2 tenants, puis ajoutez-y des droits au second utilisateur de test :

Depuis Exchange Online, ouvrez sur les 2 sessions la boite mail partagée créée précédemment via la fonction Ouvrir une autre boîte aux lettres :

Saisissez le nom de la boite mail partagée, puis cliquez sur Ouvrir :

Constatez la présence d’un message d’erreur sur la seconde session :

Essayez si besoin avec le client Outlook local :

Là encore, l’expérience utilisateur ne sera pas encore fonctionnelle :

Je suppose que le point concernant Outlook repose encore sur le fait que les boîtes mails partagées n’acceptent toujours pas de comptes invités.

Conclusion :

Microsoft continue d’avancer avec sa solution d’organisation multi-tenants et cela facilite grandement la création d’utilisateurs ayant des droits SharePoint / OneDrive sur plusieurs entreprises. Mais il y a encore des difficultés dans la partie Teams, au niveau des notifications, et dans la partie Outlook dans la partie authentification.

Nul doute que d’autres améliorations encore à venir afin que les utilisateurs de tenants différents puissent encore accroitre leurs synergies.

Maîtrisez vos accès conditionnels

Cette semaine, Microsoft vient juste d’annoncer la disponibilité générale (GA) de fonctionnalités récentes liées à l’Accès Conditionnel, et très présent au cœur d’Entra ID. L’ajout de tableaux de bord sur plusieurs ressources (utilisateurs, périphériques et applications) faciliteront grandement le contrôle de la bonne couverture des polices d’accès conditionnels sur les besoins.

Voici un lien vers un article pour un bref rappel de l’accès conditionnel, déjà expliqué dans un autre article dédié à Azure Virtual Desktop.

Qu’est-ce que l’Accès Conditionnel ?

Tous les environnements informatiques sont en quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers du 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 sécuritaires à gérer.

Le périmètre de sécurité moderne s’étend au-delà du périmètre réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations utilisent désormais des signaux basés sur l’identité dans le cadre de leurs décisions de contrôle d’accès.

Microsoft Learn

Qu’est-ce qu’un Signal pour Entra ID ?

L’accès conditionnel repose sur un certain nombre de signaux ou paramètres d’entrée. 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 Entra ID
  • Application interrogée
  • IA (Détection des risques en temps réel géré par Entra ID Identity Protection)

Qu’est-ce qu’une Décision pour Entra ID ?

La décision est le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est possiblement question de bloquer l’accès à l’utilisateur, ou de l’autoriser selon des 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 à Entra ID
  • Exiger une stratégie de protection des applications

Qu’est-ce qu’une Option d’application pour Entra ID ?

Ces options apportent une supervision de session et des accès de l’utilisateur 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

Doit-on disposer de licence pour utiliser l’accès conditionnel ?

Rappel important : Mi-juillet 2023, Microsoft a annoncé renommer son service Azure AD (Azure Active Directory). Ce changement est encore en cours et devrait être finalisé pour la fin de cette année. Cette simplification de dénomination est en cohérence avec le périmètre de la gestion identitaire élargie et gérée par le Cloud de Microsoft.

Cela a aussi pour conséquence un léger changement de nom de certaines licences :

Microsoft a mis une FAQ à disposition juste ici.

L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Microsoft Entra ID Premium P1/P2. Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :

  • Microsoft Entra ID Premium P1
  • Microsoft Entra ID 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

Je vous remets également le lien vers le site très utile créé par Aaron Dinnage :

Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?

Cette question me revient très souvent 😉. Il faut savoir que 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 en mesure de limiter les avantages à des utilisateurs spécifiques. Nous vous recommandons d’acquérir des licences pour tout utilisateur dont vous avez l’intention de bénéficier et/ou d’accéder au service.

Microsoft Learn

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

Maintenant que la partie licence est clarifiée, nous allons pouvoir nous intéresser aux principales fonctionnalités de l’accès conditionnel.

Pour vous rendre sur les règles d’accès conditionnel, allez sur la page suivante d’Entra ID dédiée :

Voici quelques fonctionnalités de l’accès conditionnel d’Entra ID que je vous propose d’étudier :

Fonctionnalité I – Le nouveau tableau de bord :

La page d’accueil de l’accès conditionnelle a été revue pour afficher plusieurs informations essentielles aux équipes IT :

C’est vraiment ce qui manquait à ce service : la visibilité. Il est maintenant beaucoup plus simple de comprendre d’un rapide coup d’œil les éléments suivants :

  • Polices actives ou non : les polices d’accès conditionnel ont 3 statuts possibles. Le mode « Rapport seulement » est utile pour contrôler l’impact durant une phase de test sans perturber les utilisateurs.
  • Utilisateurs : Affiche le nombre d’utilisateurs ayant pu s’authentifier sans passer par aucune police d’accès conditionnel.
  • Périphériques : Affiche le nombre de poste étant non managés ou non conformes.
  • Applications : lien vers une liste des applications couvertes et non couvertes par une police d’accès conditionnel

Par exemple, un clic sur la première rubrique affiche le journal d’événements d’ouverture de session avec les filtres adéquats :

Un clic sur les applications ou sur l’onglet Couverture montre 2 différents tops applications :

  • Top des applications non couvertes par un accès conditionnel
  • Top des applications couvertes par un accès conditionnel

Là encore, un clic est possible pour basculer à nouveau sur le journal des événements d’ouverture de sessions afin d’identifier plus facilement les utilisateurs concernés par l’application ciblée :

Microsoft a même pensé au graphique afin d’améliorer la prise de vue dans son ensemble de ce que représente les accès conditionnés à ceux en étant dépourvues :

Voici une nouvelle vidéo qui résume bien ce nouvel écran :

Fonctionnalité II – Création d’une police :

Le véritable moteur de l’accès conditionnel d’Entra ID est : la police.

Depuis longtemps, il est possible de créer une police d’accès conditionnel depuis une feuille blanche. Vous devrez alors choisir parmi toutes les options disponibles dans les sections suivantes :

  • Utilisateur(s) : cible la police sur un utilisateur, un groupe d’utilisateurs ou même des utilisateurs selon leurs rôles. Il est même possible d’exclure des utilisateurs selon ces mêmes règles.
  • Destination(s) cible(s) : cible une ou plusieurs applications Cloud créées sur votre tenant. Là encore, Il est même possible d’exclure des applications si nécessaire.
  • Condition(s) : ajoute des conditions (ou signaux) présents au moment de l’authentification. Comme le risque calculé par Entra ID Identity Protection ou encore la localisation du poste.
  • Condition(s) d’accès : détermine si l’accès est bloqué et cela même si le processus d’authentification est réussi, ou conditionne l’accès selon des critères supplémentaires : MFA, poste conforme…
  • Contrôle(s) de session : renforce si besoin les conditions de persistance de la session au sein de l’application.

Fonctionnalité III – Création d’une police à partir d’un modèle :

Microsoft a proposé il y a plusieurs mois déjà de simplifier la création de police d’accès conditionnel en proposant des modèles de départ :

Ces modèles de base sont classifiées dans les 5 sections suivantes :

  • Sécurisation de base
  • Zero Trust
  • Travail à distance
  • Protection des administrateurs
  • Menaces émergentes

Par exemple, le blocage de l’authentification traditionnelle peut se faire en seulement quelques clics :

Vous pouvez à tout moment changer le statut de votre police. Cela permet de désactiver celle-ci si les résultats sécuritaires obtenus ne sont pas ceux attendus :

Fonctionnalité IV – Test d’une police avec la fonction « Et si » :

Tester une police d’accès conditionnel est possible avec un utilisateur de test ou via la fonction Et si. Cette second option est très utile si l’utilisateur n’est pas disponible ou si le scénario de test demande des conditions très particulières.

Un grand nombre de paramètres (signaux) sont disponibles pour réaliser des tests dans tous les sens :

Et le résultat ne se fait pas attendre, notre nouvelle police d’accès conditionnel créée à partir d’un modèle joue bien son rôle :

Fonctionnalité V – Déclaration de lieux nommés :

Par exemple, quand des lieux sont considérés comme des sites de l’entreprise et que la sécurité réseau est géré par le service IT, il devient utile de les renseigner ici :

Cela permet alors de créer des règles d’accès conditionnel plus précises en incluant ou excluant ces lieux :

Fonctionnalité VI – Configuration d’une MFA renforcée :

L’authentification multi-facteurs est devenue la norme pour s’authentifier sur Internet. Mais toutes les méthodes multi-facteurs ne se valent pas. Microsoft propose de laisser le choix des méthodes MFA aux administrateurs :

Par exemple, ils peuvent faire en sorte que seules les méthodes d’authentification résistantes au hameçonnage soient disponibles pour accéder à une ressource sensible. Toutefois, pour accéder à une ressource non sensible, ils peuvent autoriser des combinaisons d’authentification multifacteur (MFA) moins sécurisées, telles que mot de passe + SMS.

Microsoft Learn

Plusieurs méthodes de MFA renforcées sont déjà disponibles et il est aussi possible de créer les siennes :

Il suffit après d’appeler ces méthodes de MFA renforcées dans la configuration de la police d’accès conditionnel :

Conclusion :

L’accès conditionnel sous Entra ID a réussi s’imposer comme la référence de base dans l’autorisation d’accès aux ressources de l’entreprise. Les personnalisations possibles et la prise en compte d’exclusions apporte beaucoup de souplesse et évite la fatigue sécuritaire chez les utilisateurs. Nul doute que d’autres fonctionnalités sont encore à venir 😎.

LAPS : Laissez Azure en Prendre Soin

La gestion des mots de passe est une tâche critique, mais ô combien barbante, que cela concerne les comptes personnels ou professionnels. L’apparition des gestionnaires de mots de passes et des méthodes d’authentifications renforcées (2FA / MFA) ont permis d’accroîte la sécurité sur les identités.

Windows fonctionne de la même manière et dispose-lui aussi de comptes aux droits variés. Microsoft propose justement d’en gérer une partie pour vous via Entra ID (Azure AD).

Microsoft a annoncé en mai 2023, la prise en charge des mots de passe Windows LAPS (Windows Local Administrator Password Solution) par Entra ID (Azure AD).

En quelques mots, Entra ID est capable de stocker de façon sécurisé le mot de passe de l’administrateur local de chacun des postes Windows. Mais il y a mieux, Entra ID se chargera aussi de la rotation de ces derniers selon vos propres règles !

Qu’est-ce Windows LAPS ?

Chaque machine Windows dispose d’un compte d’administrateur local intégré qui ne peut pas être supprimé et qui dispose d’autorisations complètes sur l’appareil. La sécurisation de ce compte est une étape importante dans la sécurisation de votre organization. Les appareils Windows incluent la solution de mot de passe de l’administrateur local Windows (LAPS), une solution intégrée permettant de gérer les comptes d’administrateur local.

Microsoft Learn

Quels sont les OS compatibles avec Windows LAPS ?

Comme le rappelle Microsoft, Windows LAPS fonctionne sur les versions OS suivantes ou ultérieures :

Où allons-nous configurer Windows LAPS ?

La configuration de Windows LAPS via Azure AD se fait via Microsoft Intune. Il faudra donc joindre en MDM les machines à ce dernier de afin de pouvoir leur appliquer la police de configuration.

Pour cela les jointures suivantes sont possibles :

  • Jointure à Azure AD
  • Jointure Hybride (Azure AD + Active Directory)

Intune prend en charge les fonctionnalités suivantes de Windows LAPS :

  • Définition des exigences de mot de passe
  • Rotation automatique et périodique du mot de passe
  • Choix du lieu de sauvegarde du mot de passe
  • Actions après utilisation du mot de passe

Avons-nous besoin de licence particulière ?

Pour profiter de la fonctionnalité Windows LAPS au travers d’Entra ID / Intune, il est nécessaire de disposer ces licences suivantes :

  • Microsoft Intune Plan 1
  • Microsoft Entra ID Free, anciennement Azure Active Directory Free

Existe-t-il des rôles RBAC dédiés à Windows LAPS ?

Windows LAPS est encore en préversion à l’heure où ces lignes sont écrites. Les rôles et permissions dédiés seront introduit par la suite. Pour l’instant, il est nécessaire d’utiliser l’un des deux rôles Azure AD suivants :

  • Global Administrator
  • Cloud Device Administrator

Enfin, Microsoft a commencé à mettre une FAQ sur Windows LAPS juste ici.

Afin de bien comprendre Windows LAPS, nous nous allons prendre de tester cette nouvelle fonctionnalité dans cet article :

Quels sont les prérequis pour Windows LAPS ?

Pour réaliser cet exercice sur Windows LAPS, il vous faudra disposer des ressources suivantes :

  • Une souscription Azure valide
  • Une Licence Intune Plan 1

Dans notre exercice, nous allons créer plusieurs machines virtuelles via Azure Virtual Desktop afin de servir de machines utilisateurs de test. Ces machines seront automatiquement jointes à Entra ID et Intune pour la suite de notre configuration.

Etape I – Préparation d’Azure Virtual Desktop :

Commençons par créer nos machines virtuelles AVD de test.

Pour cela, rendez-vous dans le portail d’Azure afin créer un réseau virtuel en utilisant la barre de recherche en haut de l’écran :

Cliquez ici pour créer votre réseau virtuel pour les VMs d’AVD :

Renseignez les différents champs, puis lancez validation du template par Azure :

Une fois la validation réussie, lancez la création de la ressource :

Attendez environ une minute que le réseau virtuel Azure soit créé, puis cliquez-ici :

Rendez-vous dans la section suivante afin de créer un futur accès aux VMs via le service Azure Bastion :

Le service Azure Bastion se créé en tâche de fond comme le montre les deux notifications suivantes :

N’attendez par la fin d’Azure Bastion et continuez la création des ressources AVD en utilisant la barre de recherche Azure :

Cliquez-ici pour créer un nouvel environnement Azure Virtual Desktop :

Renseignez les champs du premier onglet, puis cliquez sur Suivant :

Inutile de modifier l’accès réseau AVD sur le second onglet, cliquez sur Suivant :

Renseignez les informations liées aux machines virtuelles AVD en prenant soin de choisir une image présente dans la liste de celles compatibles avec Windows LAPS :

Définissez le nombre de VMs voulues, puis renseignez le réseau virtuel créé précédemment :

Joignez vos VMs AVD à Azure AD et en gestion MDM avec Intune, puis renseignez un mot de passe administrateur local qui sera géré par Windows LAPS par la suite :

Créez un espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure passée, lancez la création des ressource AVD :

Le traitement Azure devrait durer une dizaine de minutes environ :

Pendant ce temps, recherchez Azure AD afin de créer les groupes et utilisateurs :

Créez si besoin les utilisateurs nécessaires à AVD :

Créez si besoin le groupe d’utilisateurs nécessaire à AVD :

Retournez sur le portail Azure afin d’ajouter des rôles RBAC Azure sur le groupe de ressources AVD :

Ajoutez les rôles suivants sur le groupe d’utilisateurs AVD :

Quelques minutes plus tard, les ressources Azure créées pour AVD sont bien disponibles, cliquez-ici pour consulter le pool d’hôtes :

Rafraichissez plusieurs fois afin que toutes les machines AVD soient prêtent et disponibles :

Quelques rafraichissements plus tard, toutes les machines virtuelles sont bien disponibles :

Activez la fonction suivante pour profiter du SSO dans les propriétés RDP, puis sauvegardez :

Votre environnement Azure Virtual Desktop est maintenant prêt. Nous allons pouvoir maintenant configurer Windows LAPS.

Etape II – Préparation de Windows LAPS sur Entra ID :

Afin de pouvoir utiliser Windows LAPS sur nos machines virtuelles d’Azure Virtual Desktop, il est nécessaire de l’activer sur notre tenant.

Pour cela, rendez-vous sur le portail Entra afin d’activer l’option suivante, puis sauvegardez :

Profitez-en pour vérifier les présences des VMs AVD et la bonne gestion MDM par Intune :

Créez un nouveau groupe Azure AD dédié aux machines virtuelles AVD :

Ajoutez les VMs AVD à ce groupe, puis lancez la création :

Le travail sur Entra ID est maintenant terminé, il ne nous reste qu’à créer notre police de configuration dédiée à Windows LAPS sur Intune.

Etape III – Configuration de Windows LAPS sur Intune :

Pour cela, rendez vous sur le portail Intune sur l’adresse suivante.

Créer une nouvelle police de configuration comme ceci :

Choisissez le type de profile ci-dessous, puis cliquez sur Créer :

Nommez votre nouvelle police de profil, puis cliquez sur Suivant :

Définissez les règles de configuration, puis cliquez sur Suivant :

Dans mon exemple, après chaque authentification réussie de mon administrateur local JLO, un nouveau mot de passe sera redéfini 1 heure après.

Sinon, ce dernier est systématiquement changé tous les 7 jours.

Cliquez sur Suivant :

Ajoutez le groupe de VMs créé précédemment, puis cliquez sur Suivant :

Lancez la création de votre police Windows LAPS :

Toujours sur Intune, allez voir sur une des VMs AVD afin de voir la liste des configurations appliquées :

Attendez quelques minutes puis rafraichissez afin de constater la présence de votre nouvelle police Windows LAPS :

Notre configuration est enfin terminée, nous allons pouvoir tester Windows LAPS et son impact en nous connectant sur une des machines virtuelles AVD de test.

Etape IV – Test de Windows LAPS

Avant de vous connecter, retournez sur la liste des VMs AVD depuis le portail Azure AD :

Sur une des machines AVD, cliquez sur le menu suivant pour constater l’absence de mot de passe de l’administrateur local :

Sur le portail Azure, retournez sur la liste des machines virtuelles afin de vous y connecter à l’une d’entre-elles via Azure Bastion en utilisant le compte administrateur AVD renseigné :

Vérifiez la présence des droits administrateurs sur votre session :

Déconnectez-vous de la session Azure Bastion :

Attendez un peu, puis recommencez une connexion Azure Bastion avec les mêmes identifiants :

Constatez l’apparition du message d’erreur suivant :

Retournez sur la VM AVD utilisée depuis le portail d’Azure AD :

Retentez une nouvelle connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :

Déconnectez-vous encore une fois de la session Azure Bastion :

Attendez environ une heure, puis recommencez une connexion Azure Bastion avec les mêmes nouveaux identifiants :

Constatez encore une fois l’apparition du message d’erreur suivant :

Retournez encore une fois sur la VM AVD utilisée depuis le portail d’Azure AD :

Retentez une 3ème connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :

Déconnectez-vous une fois 3ème de la session Azure Bastion :

Une heure plus tard, le mot de passe aura encore tourné ✌️:

Petite anecdote :

Sur mon portail Intune, je ne vois pas le menu Local admin password 🥲🥲

Cela ne m’a pas empêché de retrouver l’info sur le portail d’Azure AD.

Conclusion

Très facile à mettre en oeuvre et fonctionnant aussi bien dans une architecture 100% Cloud ou Hybride, cette solution apporte une sécurité supplémentaire sur les postes physiques ou virtuels. Nul doute que la gestion de mots de passe administrateur Windows dans Azure va également faciliter le travail de fournis de certains administrateurs IT 😎

Défendez votre Business

A l’ère des environnements Cloud ou hybride, la façon dont on consomme la donnée a complètement changé. Maintenant, tout est question de mobilité, d’accessibilité et de collaboration. Mais cette ouverture s’accompagne aussi de risques dont les origines, humaines ou logicielles, sont intrinsèques.

Microsoft, et comme d’autres acteurs du marché, s’efforce depuis plusieurs années d’y remédier via sa suite Microsoft 365 Defender. Dans cet article, nous allons nous intéresser à une licence apparue fin 2021 : Microsoft Defender for Business.

Avant de rentrer dans le vif du sujet, je vous propose de revenir sur plusieurs grands aspects relatifs à la sécurité, dont certains font déjà l’objet d’articles sur ce blog :

A quoi servent les couches de sécurité ?

Quel que soit l’environnement IT, le principe des couches sécurité s’applique.

Comme un oignon, chaque couche de sécurité apporte des mesures, passives ou actives, empêchant ou retardant l’accès à la donnée, élément critique de l’entreprise :

Une architecture Cloud n’échappe pas non plus à cette règle, il est naif de penser que les solutions d’hébergement publics sont toutes à 100% protégées par le fournisseur. Les mesures et l’intelligence dédiée à la sécurité y sont certes plus avancées, mais plusieurs couches nécessiteront obligatoirement votre contribution.

Qu’est-ce que Microsoft 365 Defender ?

Voici comment Microsoft le définit :

Microsoft 365 Defender est une suite de défense d’entreprise pré-et post-violation unifiée qui coordonne en natif la détection, la prévention, les examens et la réponse sur les points de terminaison, les identités, les messages électroniques et les applications pour fournir une protection intégrée contre les attaques sophistiquées.

Microsoft Learn

Pour simplifier au maximum, Microsoft Defender vous propose des services de sécurité dans 4 grands domaines :

Sécurité I – Identités avec Defender for Identity :

Solution de sécurité basée sur le cloud qui tire parti de votre AD local signaux pour identifier, détecter et examiner les menaces avancées, les identités compromises et les actions internes malveillantes dirigées contre votre organisation.

Sécurité II – Périphériques grâce Defender for Endpoint :

Plateforme unifiée pour la protection préventive, curative, ainsi pour que des méthodes d’investigation et de réponse automatisées sur les postes et les serveurs.

Sécurité III – Applications avec Defender for Cloud Apps et Defender for Office 365 :

Defender pour Office 365 protège votre organisation contre les menaces malveillantes posées par les messages électroniques, les liens (URL) et via les outils de collaboration.

Microsoft Defender for Cloud Apps est une solution multi-SaaS complète qui offre une visibilité approfondie, des contrôles de données forts et une protection renforcée contre les menaces à vos applications cloud.

Sécurité IV – Données avec Microsoft Purview :

Famille de solutions en matière de gouvernance, de risques et de conformité des données qui peuvent aider votre organisation à régir, protéger et gérer l’ensemble de votre patrimoine de données.

Microsoft Azure

La donnée est la valeur la plus importante pour une entreprise. Que celle-ci porte sur des secrets industriels, des informations clients ou des mesures financières, il est toujours nécessaire de l’appréhender selon ces 3 grands principes :

Les données ne sont pas créées de manière égale. Certaines données sont plus sensibles et nécessitent un niveau de protection et de contrôle plus fort que d’autres types.

Quand est-ce que Microsoft 365 Defender for Business rentre en scène ?

Les petites et moyennes entreprises sont-elles-aussi soumises aux mêmes risques que certaines multinationales. La solution gérant la sécurité des postes ne doit surtout pas être dégradée :

Au-delà de toutes les fonctionnalités proposées par cette licence, voici pourquoi je la trouve intéressante pour les SMB dans la gestion de la sécurité des postes et des serveurs :

  • Simplification dans la gestion et dans le processus l’onboarding
  • Intégration avec Microsoft Intune
  • Recommandations de sécurité activées dès le départ
  • Tableau de bord orienté vers l’action aidant à hiérarchiser les tâches
  • Centralisation des environnements avec Microsoft 365 Lighthouse
  • Découverte continue en mode temps réel
  • Intégration dans la licence Microsoft 365 Business Premium
  • Defender for Business servers en add-on

Afin de tester la protection des périphériques grâce à cette licence, je vous propose de créer un environnement de démonstration sur Azure.

Pour cela, nous utiliserons des machines virtuelles en Windows 11 issues d’Azure Virtual Desktop. Ces machines seront alors jointes à Azure AD, Intune, puis Microsoft 365 Defender.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur Microsoft Defender for Business, il vous faudra disposer de :

  • Un tenant Microsoft
  • Un ou plusieurs licences Microsoft 365 Business Premium
  • Une souscription Azure valide

Etape I – Vérification de l’environnement de départ :

Avant de commencer le déploiement de ressources Azure, consultez les licences présentes sur votre tenant par ce lien :

Consultez également les périphériques déjà chargés dans votre Azure AD par ce lien :

Faites-en également de même avec votre souscription Azure :

Vérifiez la présence des licences dans le portail de Microsoft 365 Defender :

Une fois l’environnement prêt à l’emploi, rendez-vous sur la page du portail Azure pour créer vos ressources de test :

Etape II – Création de l’environnement Azure Virtual Desktop

Commencez par créer un réseau virtuel Azure :

Choisissez un nom et une région Azure à votre environnement :

Une fois la validation passée, lancez la création de votre réseau virtuel :

Quelques secondes plus tard, recherchez le composant Azure Virtual Desktop, puis lancez la création d’un pool d’hôtes :

Renseignez les informations nécessaires, reprenez la même région Azure, puis cliquez sur Suivant :

Ajoutez ou plusieurs machines virtuelles à votre environnement AVD :

Renseignez les informations réseaux :

Choisissez une jointure à Azure Active Directory et activez l’enrôlement à Intune, puis cliquez sur Suivant :

Ajoutez un espace de travail AVD, puis lancez la validation :

Une fois la validation terminée, lancez la création des ressources Azure, puis attendez :

Environ 15 minutes plus tard, constater la bonne création des ressources, puis cliquez-ici :

Modifiez l’option suivante dans les propriétés RDP de votre pool d’hôtes, puis sauvegardez :

Cliquez ensuite sur le groupe d’applications créé par défaut :

Ajoutez ici vos utilisateurs de test présents dans votre Azure AD :

Sélectionnez un ou plusieurs utilisateurs, puis cliquez sur Sélectionner :

Recherchez le groupe de ressources Azure, puis cliquez-ici pour ajouter un rôle RBAC :

Choisissez le rôle suivant, puis passez au second onglet :

Sélectionnez à nouveau les utilisateurs de test AVD :

Retournez sur le portail Azure AD pour constater la bonne apparition des VMs AVD :

Faites la même vérification sur le portail Intune :

Votre environnement IT est enfin prêt. Nous allons maintenant utiliser le portail Defender.

Afin de mettre en route Microsoft Defender for Business, il est nécessaire de commencer par une étape de configuration, côté Intune et côté Defender .

Etape III – Configuration de Microsoft 365 Defender for Business :

Pour cela cliquez-ici pour vous rendre sur le portail Defender, puis lancez le démarrage de la configuration :

Quelques minutes plus tard, cliquez-ici pour démarrer la configuration :

Assignez des utilisateurs de votre tenant aux deux rôles suivants :

  • Administrateur de sécurité : autorisés à gérer les fonctionnalités liées à la sécurité dans les portails Microsoft 365 Defender, Azure Active Directory Identity Protection, Azure Active Directory Authentication, Azure Information Protection et Microsoft Purview
  • Lecteur Sécurité : accès en lecture seule au niveau global à la fonctionnalité liée à la sécurité, notamment à toutes les informations dans le portail Microsoft 365 Defender, Azure Active Directory, Identity Protection, Privileged Identity Management, mais également les rapports sur les connexions Azure Active Directory et les journaux d’audit, ainsi que dans le portail de conformité Microsoft Purview.

Cliquez ensuite sur Continuer :

Définissez une ou plusieurs adresses emails afin de recevoir des notifications concernant les incidents et les vulnérabilités :

Choisissiez la méthode d’enrôlement des périphériques à Defender. Dans mon cas, je choisi l’intégration automatique via Intune :

Validez votre configuration si tout est OK pour vous :

Attendez environ 5 minutes pour que Microsoft finalise la configuration :

Le message suivant doit alors apparaître :

Le processus de mise en oeuvre est terminé ! Plutôt rapide non ?

Avant de voir les périphériques apparaitre, profitons-en pour faire le tour de certains paramétrages.

Etape IV – Paramétrages disponibles :

Cliquez-ici pour ouvrir activer la fonctionnalité de Live Response de Defender :

Activez si vous le souhaitez les fonctionnalités encore en préversion, puis cliquer sur Sauvegarder.

Profitez-en pour élargir le périmètre de Defender en permettant aux paramètres de sécurité d’Intune d’être appliqués par Microsoft Defender for Endpoint (MDE) aux appareils qui ne sont pas encore inscrits à Intune :

Configurez également et facilement un filtrage web grâce à un blocage de catégories :

Nommez votre police de filtrage web :

Ajoutez une ou plusieurs catégories à bloquer :

Validez la création en sauvegardant votre police :

Retournez sur le portail pour vérifier la bonne connection entre Intune et Microsoft Defender for Endpoint, validez l’option suivante, puis cliquer sur Sauvegarder :

Retournez sur votre portail Defender pour constater la présence de vos machines AVD.

Note : Il est possible que cela prenne environ 30 minutes pour voir les VMs AVD apparaître.

Comme la configuration de base est terminée et que les VMs sont remontées, nous allons pouvoir tester la bonne remontée des alertes et incidents dans Microsoft 365 Defender.

Etape V – Alerte / incident de test :

Récupérez le script PowerShell disponible sur le portail Defender :

Téléchargez le client Azure Virtual Desktop via cette page Microsoft, installez-le, lancez-le, puis cliquez-ici pour ajouter vos accès AVD de test :

Ajoutez vos 4 utilisateurs de test paramétré pour utiliser AVD :

Renseignez les mots de passe pour chacun d’eux :

Cliquez sur une session AVD et renseignez à nouveau le mot de passe utilisateur :

Acceptez la configuration SSO entre votre Azure AD et votre VM AVD :

Ouvrez le programme de ligne de commande Windows en mode Administrateur :

Renseignez le compte de l’administrateur local saisi dans Azure :

Collez le script récupéré précédemment, puis lancez-le :

powershell.exe -NoExit -ExecutionPolicy Bypass -WindowStyle Hidden $ErrorActionPreference= 'silentlycontinue';(New-Object System.Net.WebClient).DownloadFile('http://127.0.0.1/1.exe', 'C:\\test-WDATP-test\\invoice.exe');Start-Process 'C:\\test-WDATP-test\\invoice.exe'

Quelques minutes plus tard, toujours dans la page de configuration, constatez la validation du test de détection :

Vérifiez la boite de messagerie renseignée lors de la configuration de Microsoft 365 Defender for Business :

Dans la page d’incident, vous devriez voir votre premier cas, issu de votre script de test :

Cliquez dessus, parcourez les différents onglets, puis cliquez ici :

Une fois analysé, changez le statut de votre incident pour le clôturer :

Jusqu’à présent, nous n’avons pas modifié la politique de configuration concernant la sécurité des postes. Comme nos machines virtuelles AVD de test sont présentes dans Intune et dans Microsoft 365 Defender, nous devons choisir le lieu de configuration.

Etape VI – Configuration de polices de sécurité via Defender :

Rappelez-vous dans mon exemple que mon environnement ne contenait aucun poste dans ma console Intune. Je n’avais donc encore rien configuré. Cela ne sera pas forcément le cas dans un environnement déjà en place.

Microsoft recommande la mise en place de la gestion des polices de sécurité via Microsoft Defender 365. Cela rendra l’outil plus performant et facilitera la tâche des personnes spécifiquement dédiées à la sécurité des postes.

Dans le menu suivant, cliquez comme ceci :

Prenez le temps de bien lire l’avertissement de Microsoft :

Validez si vous êtes toujours d’accord avec cette gestion :

Environ une minute plus tard, la configuration des périphériques est disponible sur deux points :

  • Protection Next-Gen
  • Firewall

Celles-ci sont déjà sont déjà configurés et installés sur tous les périphériques. Cliquez sur l’une d’entre-elles pour comprendre sa configuration :

Faites-en de même avec la seconde :

Retournez sur le portail Intune pour constater d’éventuels changements.

Section Antivirus :

Section Firewall :

Section EDR :

Section des profils de configuration :

De retour sur le portail Defender, constatez la bonne application des 2 configurations à vos machines virtuelles Azure Virtual Desktop :

Etape VI – Tests de fonctionnalités de Defender :

Afin de voir comment se comporte Defender for business, je vous conseille d’attendre quelques heures, le temps que toutes les configurations soient bien appliquées aux VMs AVD.

Commencez par le filtrage web en recherchant un jeu sur votre moteur de recherche favori :

Cliquez sur un résultat de la liste :

Environ une seconde plus tard, constatez le blocage par la fenêtre suivante :

Il ne vous reste rien qu’à tester d’autres fonctionnalités depuis le portail Defender !

Etape VII – Quelques fonctions Defender

Comme les fonctionnalités sont nombreuses sur Defender, je trouve intéressant de vous en sélectionner quelques-unes liées aux périphériques et accompagnées de copies d’écran.

  • Incidents & Alertes
  • Tableaux de bord & Analyses
  • Actions sur le périphérique

Incidents & Alertes :

Tableaux de bord & Analyses :

Actions sur le périphérique :

Bloquer un processus considéré comme suspicieux :

Restreindre le lancement d’application non signée :

Lancer un scan antivirus sur le périphérique :

Démarrer une session de Live Response :

Isoler un périphérique du réseau :

Conclusion :

Après seulement quelques temps passé sur le portail de Microsoft 365 Defender, on ne peut que constater la facilité de mise en oeuvre de la solution sur des périphériques. L’intégration avec Intune, Azure AD et les autres mesures de sécurité créé un ensemble cohérent.

On comprend aisément le bénéfice à passer à Microsoft 365 Business Premium.

Cette imbrication permet sans aucun doute une prise en main facile et rapide au sein de nombreuses entreprises SMB.

Voici enfin quelques liens pour vous aider :

Déployez des bases de sécurité Azure en 10 min

Configurer la sécurité sur Azure en seulement 10 minutes ? Et pourquoi pas en 9 minutes ? Cette course au temps ne veut rien dire ! La sécurité est une tâche constante, et passe presque toujours par différentes phases, comme la découverte, l’analyse et la configuration. Néanmoins, une approche directe est malgré tout possible sur certains éléments élémentaires de sécurité.

Microsoft le rappelle très régulièrement, le premier risque identifié provient d’identités mal sécurisées :

Chaque jour, plus de 300 millions de tentatives de connexion frauduleuses à nos services Cloud sont enregistrées. Les cyberattaques ne ralentissent pas, et il convient de noter que de nombreuses attaques ont réussi sans l’utilisation de technologies avancées. Il suffit d’une seule d’identité compromise … pour provoquer une violation de données. Cela montre à quel point il est essentiel de garantir la sécurité des mots de passe et une authentification forte.

Microsoft Blog

Par où commençons-nous ?

Déjà par lire mon article sur la sécurité, accessible juste ici ????. Plus sérieusement, commencer par assimiler quelques notions, comme la défense en profondeur ou le Zéro Trust.

Principe de sécurité en couche

Comme un oignon, chaque couche de sécurité apporte des mesures, passives ou actives, empêchant ou retardant l’accès à la donnée, élément critique de toute entreprise :

Qu’est-ce que TD SYNNEX peut faire pour ma sécurité ?

Travaillant chez TD SYNNEX depuis plusieurs années, j’accompagne des partenaires IT dans la conception d’architecture sur Azure. La collaboration entre Microsoft et TD SYNNEX est très forte, nous distribuons tous les produits Cloud de Microsoft via une marketplace.

Disposant de compétences techniques en interne, nous développons aussi nos propres solutions pour faciliter et automatiser toujours plus la mise en place de solutions innovantes sur Azure.

Concernant la sécurité, TD SYNNEX n’est pas en reste et propose une nouvelle solution appelée SMB Fraud Défense. Il s’agit d’une solution, dite Click-to-Run, donc prête à l’emploi : quelques clics suffisent pour mettre en place la solution sur un tenant Azure.

Que fait exactement la solution SMB Fraud Defense ?

Voyez un tenant Microsoft comme une maison : les identités et les périphériques sont les portes et les fenêtres. Il est donc évident que ces points des entrées à la donnée :

Des mesures de sécurité sont nécessaires protéger la donnée. Voici une liste non exhaustive des fonctionnalités facilement activables depuis SMB Fraud Defense :

  • Protection des identités Azure AD :
    • Création de scénarios d’accès conditionnel avec MFA
    • Restriction géographique par pays
    • Blocage d’anciens protocoles d’authentification
    • Gestion de l’expiration des mots de passe
    • Verrouillage des identités intelligent
  • Protection des ressources Azure :
    • Mise en place de budgets et notifications
    • Restrictions géographiques
    • Restrictions de familles de machines virtuelles

Combien coûte SMB Fraud Defense ?

Rien du tout ????, aucun frais à prévoir du côté de TD SYNNEX ou de Microsoft.

Comment procède-t-on pour déployer SMB Fraud Defense ?

Quelques étapes sont nécessaires et sont décrites dans les lignes de cet article, rien de plus.

Etape 0 – Rappel des prérequis :

Avant tout, le déploiement d’une solution Click-to-Run nécessite la mise en place d’un partenariat entre un vous et TD SYNNEX. En effet, ces solutions ne sont disponibles à l’achat qu’uniquement depuis notre Marketplace. Pour cela, cliquez ici.

Le second prérequis est de disposer d’un tenant Azure et d’une souscription Azure Plan acheté via la Marketplace de TD SYNNEX.

Etape I – Achat de la solution Click-to-Run SMB Fraud Defense :

Comme indiqué plus haut, SMB Fraud Defense est gratuit mais demande malgré tout par un provisionnement par depuis la Marketplace de TD SYNNEX.

Une fois votre Azure Plan en place, cliquez sur Modifier :

Parcourez la liste des solutions Click-to-Run disponibles à l’installation, et cliquez sur Acheter SMB Fraud Defense :

Note : La mise en place de la solution vous alerte sur l’incompatibilité avec des solutions MFA externe à Azure

Une fois que vous avez accepté ce message, la plate-forme vérifie la bonne configuration initiale du tenant :

Etape II – Déploiement de la solution Click-to-Run SMB Fraud Defense :

Juste avant de déployer SMB Fraud Defense, il est nécessaire de préparer 3 conditions sur le tenant cible, car la solution analyse les 3 points suivants :

  • Paramètre de sécurité par défaut d’Azure
  • Gestionnaire de coûts Azure
  • Souscription d’une licence Azure AD Premium (Plan 1 ou Plan 2)

Voici un détail point par point pour réussir la préparation et leur statut attendu :

Paramètre de sécurité par défaut d’Azure – désactivé :

La mise en place d’une sécurité personnalisée nécessite la désactivation de la sécurité par défaut d’Azure. Voici ce que cette dernière contient.

Sa désactivation est donc possible via ce menu :

Mais elle est aussi désactivable via le portail d’Azure AD :

Désactivez alors celle-ci en spécifiant un motif justifiant l’opération :

Gestionnaire de coûts Azure – Activé :

La mise en place de budget et d’alerte sur la consommation Azure nécessite l’activation du gestionnaire de coûts Azure.

En effet, la mise en place d’une souscription Azure Plan via un partenaire CSP ne l’active pas par défaut. Il est donc nécessaire de vous rapprocher de votre fournisseur CSP pour l’activation du Gestionnaire de coûts.

Souscription d’une licence Azure AD Premium Plan 1 ou Plan 2 – Souscrite :

La mise en place de l’accès conditionnel sur Azure AD nécessite de disposer d’une licence Azure AD Premium Plan 1 ou Plan 2 :

Pour un déploiement optimal, il est conseillé d’en disposer pour profiter de l’ensemble des avancées de SMB Fraud Defense, comme l’accès conditionnel avec prise en compte de l’évaluation du risque à la connexion.

Vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :

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

Une fois ces 3 points corrects sur votre environnement, vous pouvez commencer la configuration sur chacun des onglets :

Etape III – Configuration de la solution Click-to-Run SMB Fraud Defense :

Cette configuration est divisée en 5 onglets :

  • Localisation
  • Budget
  • Accès conditionnel
  • Méthodes d’authentification
  • Polices

Note : cliquez sur Déployer à la fin, une fois seulement tous les onglets configurés.

A / Localisation

Des informations sont nécessaires pour le bon déploiement des polices Azure. Pour cela, choisissez une région Azure dans le menu déroulant et spécifiez le nom d’un groupe de ressources :

B/ Budget

La mise en place d’un budget est une bonne approche pour suivre la consommation Azure en fonction de l’estimation faite au début du projet :

La mise en place d’alertes l’est tout autant pour éviter les dépassements et donc les factures salées :

Vous pouvez indiquer plusieurs adresses emails pour les notifications.

C/ Accès conditionnel

La gestion identitaire d’Azure passe par Azure Active Directory (Azure AD). La sécurisation d’environnement Azure passe donc avant tout par celui-ci.

Vous pouvez contrôler l’accès à vos applications cloud basées sur l’emplacement réseau d’un utilisateur. La condition d’emplacement est couramment utilisée pour bloquer l’accès à partir des pays/régions d’où votre organisation sait que le trafic ne doit pas provenir :

La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Azure AD impose de mettre en place les 3 méthodes d’authentification suivantes :

  • Un élément que vous connaissez (ex. mot de passe)
  • Un élément que vous possédez (ex. un appareil de confiance, comme un smartphone)
  • Un élément qui vous définit : (ex. identifiant biométrique, tel qu’une empreinte digitale)

Les périphériques et les applications accédant à vos données se doivent d’être protégés.

Il est toujours utile de joindre les périphériques à Azure AD. Comme pour un Active Directory, la connaissance de ces derniers apporte une meilleure maitrise de la sécurité lors de la création de règles de sécurité :

N’ayant pas de poste joint à Azure AD sur cet environnement de démo, je n’active donc pas ces 2 options dans la configuration.

D/ Méthodes d’authentification

Toujours sur la protection des identités, certaines options supplémentaires sont encore configurables :

Le verrouillage intelligent empêche les attaquants de pénétrer dans le système, tout en permettant à vos utilisateurs d’accéder à leur compte et de travailler :

Le déploiement local de Protection de mots de passe d’Azure AD utilise les mêmes listes globales et personnalisées de mots de passe interdits qui sont stockées dans Azure AD, et effectue les mêmes vérifications des modifications de mot de passe localement :

Comme annoncé avant, la validation en deux étapes permet de renforcer la sécurité de votre compte Microsoft en exigeant une deuxième étape de validation lorsque vous vous connectez.

En plus de votre mot de passe, vous pouvez générer un code par l’application Microsoft Authenticator sur votre téléphone :

Autrement, le standard de sécurité FIDO2 répond à ce problème en s’appuyant là aussi sur une authentification à deux facteurs basés sur l’utilisation de clés de sécurité (clés FIDO2) et de tokens (jetons d’authentification) :

E/ Polices

Les polices d’Azure sont un moyen de contrôler les déploiements des ressources. La solution SMB Fraud Defense vous propose de restreindre les SKUs de familles de machines virtuelles. Cela bloque alors les SKUs les plus coûteux :

Azure offre à ses clients la flexibilité de déployer des applications là où ils en ont besoin. Une région Azure a une tarification et une disponibilité de service distinctes.

Ici, Il est vous possible de restreindre le déploiement sur certaines régions Azure, mais aussi d’activer d’autres fonctionnalités de sécurité :

Tous les onglets ont maintenant été passés en revue, il ne vous reste qu’à déployer la configuration.

Etape IV – Déploiement de la solution Click-to-Run SMB Fraud Defense :

Pour cela, cliquez ici pour lancer le déploiement et attendez quelques minutes :

Une fois le déploiement terminé, un email de notification est également envoyé, et le status de la solution C2R change :

Etape V – Contrôle du déploiement sur le tenant :

Le déploiement est maintenant terminé, une vérification sur le tenant permet de s’assurer la présence de toutes les options choisies durant la phase de la configuration.

A / Localisation

Consultez votre portail Azure et vérifiez la présence du groupe de ressources sur votre souscription Azure Plan :

B/ Budget

Toujours sur la souscription Azure, contrôler l’ajout du budget reprenant le montant configuré :

Cliquez dessus et éditez le pour vérifier la présence des 2 alertes :

C/ Accès conditionnel

La configuration de la restriction géographique s’effectue depuis le portail Azure AD. Consultez la sécurité pour voir l’apparition du pays sélectionné dans les zones de confiance :

Toujours dans Azure AD, chaque option activée a généré la création d’une ou plusieurs polices d’accès conditionnel, toujours en mode audit au moment du déploiement :

D/ Méthodes d’authentification

Le contrôle de la désactivation de l’expiration du mot de passe se fait via le portail Microsoft 365 :

Quant à lui, le contrôle du seuil de verrouillage du compte se fait via le portail Azure AD :

La configuration des deux méthodes MFA d’authentification se retrouve juste ici :

E/ Polices

Du côté d’Azure, contrôlez les polices déployées :

Un clic sur une police affiche le détail de la configuration, comme la région autorisée ou les SKUs interdits :

Conclusion

Alors, finalement nous ne sommes pas si loin des 10 minutes ???? ?

Plus sérieusement, je trouve que ce type de solution est une bonne approche quand on voit l’éparpillement des principales mesures de sécurité, qui sont maintenant indispensables pour sécuriser au minimum un tenant Microsoft.

SMB Fraud Defense de TD SYNNEX doit être perçue comme un point de départ à une configuration sécuritaire, et facile son automatisation lors de la création de tenants.

Enfin, il faut garder en tête que ce type de solution Click-to-Run évolue sans cesse chez TD SYNNEX, grâce aux feedbacks et aux évolutions du Cloud Microsoft ????

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

Re-joignez la force d’Azure AD

La jointure d’appareil à Azure AD est un sujet à lui tout seul. Celle-ci apporte pourtant un grand nombre de bénéfices pour la sécurité de son environnement 365 grâce à aux polices de compliance ou d’accès conditionnels. Très régulièrement, une confusion émane en provenance des messages parlant de jointure à Azure AD. Souvent ambigus, ils sont provoqués par l’authentification d’un utilisateur à un service 365 du Cloud Microsoft.

Dans cet article, nous allons apprendre les différents types de jointures possible à Azure AD notions et effectuer plusieurs tests sur un environnement de démo.

Qu’est-ce qu’Azure AD ?

Le tout en moins d’une minute ????.

Pourquoi joindre un appareil à Azure AD ?

Les appareils joints Azure AD ont pour objectif de simplifier :

  • Les déploiements Windows sur des appareils professionnels
  • L’accès aux applications .365 et aux ressources de l’organisation à partir de n’importe quel appareil Windows
  • Gestion cloud des appareils professionnels
  • Aux utilisateurs de se connecter à leurs appareils à partir de leurs comptes Azure AD ou Active Directory synchronisés professionnels ou scolaires.

Existe-t-il plusieurs types de jointure à Azure AD ?

Cette question a plusieurs réponses possibles et le choix va dépendre de l’identité du propriétaire des données, de la personne qui gère l’appareil et du type d’identification de l’utilisateur utilisé pour l’authentification :

Inscrire un appareil sur Azure :

L’objectif des appareils inscrits sur Azure AD (également appelés appareils joints à l’espace de travail) est de fournir à vos utilisateurs la prise en charge des scénarios d’appareil mobile et Bring Your Own Device (BYOD). Dans ces scénarios, un utilisateur peut accéder aux ressources de votre organisation à l’aide d’un appareil personnel.

Microsoft Doc
  • Appareil appartenant à une entreprise et géré par elle
  • L’authentification au dispositif se fait à l’aide d’un identifiant local ou d’un identifiant personnel dans le Cloud.
  • Authentification aux ressources de l’entreprise à l’aide d’un identifiant d’utilisateur sur AAD.

Joindre un appareil sur Azure :

Les appareils joints Azure AD sont connectés au moyen d’un compte professionnel Azure AD. L’accès aux ressources peut être contrôlé en fonction du compte Azure AD et des stratégies d’accès conditionnel appliquées à l’appareil. Les administrateurs peuvent sécuriser et mieux contrôler les appareils joints Azure AD à l’aide d’outils de gestion des périphériques mobiles (GPM), tels que Microsoft Intune ou dans des scénarios de cogestion à l’aide de Microsoft Endpoint Configuration Manager. 

Doc Microsoft
  • Dispositifs appartenant à l’entreprise et gérés par elle
  • Authentification à l’aide d’un identifiant d’entreprise existant dans Azure AD.
  • L’authentification se fait uniquement par AAD.

Jointure hybride d’un appareil sur Azure :

Le meilleur des deux mondes !

  • Appareils appartenant à l’entreprise et géré par elle
  • Authentifié à l’aide d’un identifiant d’utilisateur d’entreprise qui existe dans l’AD local et dans Azure AD.
  • L’authentification peut être faite en utilisant les deux moyens : On-Prem AD et Azure AD.

Le tableau ci-dessous explique bien les 3 scénarios en détail :

Voici donc plusieurs des tests pour comprendre un peu mieux comment on génère ces méthodes de jointure :

  • Test I : Jointure Azure AD : Inscription + MDM Intune
  • Test II : Jointure Azure AD : Inscription
  • Test III : Absence de jointure Azure AD
  • Test IV : Jointure Azure AD : Join + MDM Intune
  • Test V : Jointure Azure AD : Hybride AD / Azure AD

Etape 0 : Rappel des prérequis

Pour effectuer ces tests, nous allons partir d’un environnement Azure et y déployer plusieurs machines virtuelles Azure. Avant cela, voici la courte liste des composants déjà présents sur mon environnement :

  • Tenant Azure
  • Souscription Azure valide
  • Un compte Azure AD avec une licence Office365

Test I : Jointure Azure AD : Inscription + MDM Intune

Déployez une première machine virtuelle avec Windows 10 dans votre souscription Azure comme ceci :

Connectez-vous en bureau à distance à cette dernière avec le compte administrateur local :

Exécutez la commande ci-dessous et constatez l’absence d’informations relatives à Azure AD :

dsregcmd /status

Exécutez l’application Office directement disponible via le menu Démarrer :

Cliquez comme ceci pour lancer le processus d’authentification 365 :

Choisissez l’option suivante et saisissez les identifiants de votre compte 365 :

Laissez cochée la case suivante et cliquez sur OK :

Un message de traitement apparaît alors et vous invite à attendre :

Fermez la fenêtre une fois le traitement réussi :

Relancez la commande précédente pour constater les changements relatifs à Azure AD :

dsregcmd /status

Retournez sur la page listant vos appareils dans le portail Azure AD :

Consultez également sur la page de vos appareils Windows dans le portail Intune :

Ce test nous apprend que la jointure à Azure AD n’est faite que sous forme d’inscription, mais que l’appareil est malgré tout gérable dans Intune. Ce scénario pourrait correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test II : Jointure Azure AD : Inscription

Déployez une seconde machine virtuelle depuis votre Azure, identique à la première :

Ouvrez là encore une session de bureau à distance avec un utilisateur local.

Effectuez les mêmes opérations pour arriver jusqu’à l’écran ci-dessous. Mais décochez cette fois la case et cliquez sur OK :

Le message de traitement vous invitant à patienter est toujours présent :

Attendez la fin du traitement et fermez la fenêtre :

Lancez la commande suivante pour constater d’éventuels changements par rapport au précédent test de jointure :

dsregcmd /status

Retournez sur la page de vos appareils dans votre portail Azure AD et constatez l’apparition de cette seconde machine virtuelle :

La colonne MDM n’est pas remplie, cela s’explique par la case décochée précédemment.

Retournez sur la page de vos appareils Windows dans le portail Intune :

Comme attendu, la seconde machine virtuelle n’apparaît pas.

Ce second test nous apprend que la jointure à Azure AD n’est faite que sous forme d’inscription, et que l’appareil n’est pas gérable dans Intune. Ce scénario pourrait lui aussi correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test III : Absence de jointure Azure AD

Déployez une troisième machine virtuelle Azure pour continuer à tester une autre possibilité de jointure.

Effectuez les mêmes opérations pour arriver jusqu’à cet écran. Cliquez sur Non, authentifiez-vous uniquement sur l’application :

Pas de traitement ou de message de fin.

Relancez la commande suivante pour voir d’éventuels changements avec les précédents tests :

dsregcmd /status

Un tour dans la liste des devices d’Azure AD pour constater une éventuelle apparition :

Aucune nouvelle machine virtuelle.

Il en est de même dans le portail Intune : 0 changement.

Ce troisième test nous apprend qu’aucune jointure à Azure AD, et que l’appareil n’est pas non plus gérable dans Intune. Ce scénario pourrait lui aussi encore correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test IV : Jointure Azure AD : Join + MDM Intune

A l’inverse des tests précédents, la jointure de ce test va s’effectuer dans la configuration Windows.

Déployez une quatrième machine virtuelle Azure, toujours identique aux précédentes :

Connectez-vous sur votre machine virtuelle avec l’utilisateur local et allez dans les Comptes de vos Paramètres Windows :

Connecter votre compte Azure AD comme ceci :

Cliquez sur l’option ci-dessous pour joindre la machine virtuelle à un tenant Azure AD :

Renseignez le compte 365 de votre utilisateur :

Approuvez la jointure en cliquant sur Joindre :

Attendez que la jointure s’applique :

Le message de succès vous indique que vous pouvez maintenant utiliser votre compte Azure AD pour ouvrir la session Windows :

La jointure est bien confirmée grâce à l’indication suivante :

Pour vous connecter sur la machine virtuelle avec votre compte Azure AD, décochez la case suivante dans les propriétés système de celle-ci :

Fermez la session RDP ouverte précédemment.

Sur votre poste, modifiez le fichier RDP avec un éditeur de texte pour y ajouter les paramètres suivants :

enablecredsspsupport:i:0
authentication level:i:2

Cela donne un fichier contenant les lignes suivantes :

Ouvrez ce programme RDP et renseignez comme ceci votre compte 365 :

Sur cette nouvelle session RDP ouverte, exécutez la commande ci-dessous :

dsregcmd /status

Retournez et constatez la présence de cette nouvelle machine virtuelle dans la liste des appareils d’Azure AD, avec un nouveau type de jointure :

Il en est de même dans le portail Intune :

La quatrième machine virtuelle apparaît bien comme appartenant à l’entreprise.

A l’inverse des tests précédents, celui-ci nous apprend que la jointure à Azure AD complète, et que l’appareil est aussi gérable dans Intune. Ce scénario pourrait correspondre à un appareil professionnel utilisé dans le cadre professionnel.

Test V : Jointure Azure AD : Hybride AD / Azure AD

Ce nouveau test demandera un peu plus d’efforts. Pour y arriver, il va nous falloir disposer d’un domaine Active Directory. Commencez donc par créer une première machine virtuelle basée sur une image Windows Server :

Une fois déployée, connectez-vous en RDP sur cette machine virtuelle Windows Server :

Ajoutez à votre serveur les rôles de Contrôleur de domaine et de Serveur DNS et laissez-vous guider jusqu’au lancement de l’installation :

Terminez la configuration de l’Active Directory en créer une nouvelle forêt de domaine :

Lancez la finalisation de l’installation avec des options de base et malgré l’affichage d’alertes non bloquantes :

Attendez que la session RDP se ferme automatiquement :

Retournez sur le portail Azure pour ajouter dans la résolution DNS du réseau virtuel par l’adresse IP de votre nouveau serveur DC / DNS :

Réouvrez une session RDP avec le nouveau compte administrateur de domaine :

N’attendez pas la fin du chargement de session et retournez sur votre portail Azure :

Créez une autre machine virtuelle sous Windows 10 sur le même réseau virtuel que la machine de domaine :

Ouvrez une session RDP avec un compte utilisateur local et joignez cette machine au domaine Active Directory :

Redémarrez cette machine virtuelle :

Retournez sur la session RDP ouverte sur le serveur Active Directory et utilisez le lien suivant pour y installer Azure AD Connect :

Lancez l’exécutable MSI téléchargé et choisissez l’option ci-dessous :

Cochez la case SSO dans la configuration de votre Azure AD Connect :

Renseignez le compte Administrateur Global de votre tenant 365 :

Renseignez le compte Administrateur d’entreprise de votre domaine Active Directory :

Cliquez sur Suivant :

Cochez la case et cliquez sur Suivant :

Synchronisez l’ensemble du domaine Active Directory :

Cliquez sur Suivant :

Cliquez encore sur Suivant :

Cliquez toujours sur Suivant :

Renseignez les identifiants d’Administrateur d’entreprise et cliquez sur Suivant :

Lancez l’installation de la configuration :

Une fois la configuration terminée, quittez le configurateur :

L’affichage des appareils d’Azure AD ne montre pour l’instant aucune nouvelle machine provenant de ce test :

Quelques minutes plus tard, relancez la configuration d’Azure AD Connect :

Cliquez comme ceci pour activer la jointure hybride AD / Azure AD :

Après avoir renseigné les identifiants d’Administrateur global du tenant 365, activez la fonctionnalité de jointure hybride :

Cochez la case pour les prendre en compte machines en Windows 10 ou ultérieures :

Renseignez les identifiants d’Administrateur d’entreprise du domaine Active Directory :

Démarrez la mise à jour de la nouvelle configuration :

Une fois la reconfiguration terminée, fermez la fenêtre d’installation d’Azure AD Connect :

Lancez en PowerShell la commande suivante pour forcer une nouvelle synchronisation entre l’AD et Azure AD :

Start-ADSyncSyncCycle -PolicyType Delta

Rafraîchissez la page des appareils d’Azure AD pour constater une nouvelle apparition :

Ouvrez une session RDP avec un compte de domaine sur la machine Windows 10 et retournez quelques minutes plus tard sur la page des appareils d’Azure AD pour constater le changement :

Conclusion

Les tests sur Azure AD sont toujours une précieuse méthode pour comprendre tous les mécanismes d’Azure. Enfin voici une vidéo explicative reprenant différentes étapes de nos tests ????????

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.