Vers l’identité et au-delà : le point de vue d’un architecte

  • Article

Dans cet article, Alex Shteynberg, architecte technique principal chez Microsoft, décrit les principales stratégies de conception pour les organisations d’entreprise qui adoptent Microsoft 365 et d’autres services cloud Microsoft.

À propos de l’auteur

Photo Alex Shteynberg.

Je suis architecte technique principal au New York Microsoft Technology Center. Je travaille principalement avec de grands clients et des exigences complexes. Mon point de vue et mes opinions sont basés sur ces interactions et peuvent ne pas s’appliquer à toutes les situations. Toutefois, d’après mon expérience, si nous pouvons aider les clients avec les défis les plus complexes, nous pouvons aider tous les clients.

Je travaille généralement avec plus de 100 clients chaque année. Bien que chaque organization possède des caractéristiques uniques, il est intéressant de voir les tendances et les points communs. Par exemple, une tendance est l’intérêt inter-secteurs pour de nombreux clients. Après tout, une agence bancaire peut également être un café et un centre communautaire.

Dans mon rôle, je me concentre sur l’aide que les clients arrivent à la meilleure solution technique pour répondre à leur ensemble unique d’objectifs commerciaux. Officiellement, je me concentre sur l’identité, la sécurité, la confidentialité et la conformité. J’aime le fait que ces touches tout ce que nous faisons. Cela me donne l’occasion de participer à la plupart des projets. Cette activité me tient occupé et profiter de ce rôle.

Je vis à New York (le meilleur !) et vraiment profiter de la diversité de sa culture, de la nourriture, et des gens (pas de la circulation). J’aime voyager quand je peux et j’espère voir la plupart du monde dans ma vie. Je suis actuellement à la recherche d’un voyage en Afrique pour en savoir plus sur la faune.

Principes directeurs

  • Le simple est souvent mieux : vous pouvez (presque) tout faire avec la technologie, mais cela ne signifie pas que vous devriez. En particulier dans le domaine de la sécurité, de nombreux clients sur-entent sur les solutions d’ingénierie. J’aime cette vidéo de la conférence Google Stripe pour souligner ce point.
  • Personnes, processus, technologie : conception pour que les personnes améliorent le processus, et non la technologie d’abord. Il n’y a pas de solutions « parfaites ». Nous devons équilibrer les différents facteurs de risque et les décisions qui peuvent être différentes pour chaque entreprise. Trop de clients conçoivent une approche que leurs utilisateurs évitent par la suite.
  • Concentrez-vous sur « pourquoi » d’abord et « comment » plus tard : Soyez l’enfant ennuyeux de 7 ans avec un million de questions. Nous ne pouvons pas obtenir la bonne réponse si nous ne connaissons pas les bonnes questions à poser. De nombreux clients font des hypothèses sur la façon dont les choses doivent fonctionner au lieu de définir le problème métier. Il existe toujours plusieurs chemins d’accès qui peuvent être empruntés.
  • Longue fin des meilleures pratiques passées : reconnaissez que les meilleures pratiques changent à la vitesse de la lumière. Si vous avez examiné Microsoft Entra il y a plus de trois mois, vous êtes probablement obsolète. Tout est susceptible d’être modifié après la publication. La meilleure option d’aujourd’hui pourrait ne pas être la même dans six mois.

Concepts de base

N’ignorez pas cette section. Je trouve souvent que je dois revenir à ces articles, même pour les clients qui utilisent des services cloud depuis des années. Hélas, la langue n’est pas un outil précis. Nous utilisons souvent le même mot pour désigner des concepts différents ou des mots différents pour signifier le même concept. J’utilise souvent le diagramme suivant pour établir une terminologie de base et un « modèle de hiérarchie ».

Illustration du locataire, de l’abonnement, du service et des données.

Lorsque vous apprenez à nager, il est préférable de commencer dans la piscine et non au milieu de l’océan. Je n’essaie pas d’être techniquement précis avec ce diagramme. Il s’agit d’un modèle pour discuter de certains concepts de base.

Dans le schéma :

  • Locataire = instance de Microsoft Entra ID. Il se trouve en haut d’une hiérarchie, ou niveau 1 dans le diagramme. Nous pouvons considérer ce niveau comme étant la « limite » où tout le reste se produit (Microsoft Entra B2B mis à part). Tous les services cloud d’entreprise Microsoft font partie de l’un de ces locataires. Les services aux consommateurs sont distincts. « Locataire » apparaît dans la documentation en tant que locataire Microsoft 365, locataire Azure, locataire WVD, etc. Je trouve souvent que ces variations sont source de confusion pour les clients.
  • Les services/abonnements, de niveau 2 dans le diagramme, appartiennent à un seul locataire. La plupart des services SaaS sont 1 :1 et ne peuvent pas être déplacés sans migration. Azure est différent. Vous pouvez déplacer la facturation et/ou un abonnement vers un autre locataire. De nombreux clients doivent déplacer des abonnements Azure. Ce scénario a diverses implications. Les objets qui existent en dehors de l’abonnement ne sont pas déplacés. Par exemple, le contrôle d’accès en fonction du rôle (RBAC Azure), Microsoft Entra objets (groupes, applications, stratégies, etc.) et certains services (Azure Key Vault, Data Bricks, etc.). Ne migrez pas les services sans avoir besoin d’une bonne entreprise. Certains scripts qui peuvent être utiles pour la migration sont partagés sur GitHub.
  • Un service donné a généralement une sorte de limite de « sous-niveau » ou niveau 3 (L3). Cette limite est utile pour comprendre la séparation de la sécurité, des stratégies, de la gouvernance, etc. Malheureusement, il n’y a pas de nom uniforme que je connais. Voici quelques exemples de noms pour L3 : Abonnement Azure = ressource ; Dynamics 365 CE = instance ; Power BI = espace de travail ; Power Apps = environnement ; et ainsi de suite.
  • Le niveau 4 correspond à l’emplacement où résident les données réelles. Ce « plan de données » est un article complexe. Certains services utilisent Microsoft Entra ID pour RBAC, d’autres non. J’en parlerai un peu quand nous aurons des articles de délégation.

Parmi les autres concepts que je trouve de nombreux clients (et employés De Microsoft) sont confus ou ont des questions à ce sujet, citons les problèmes suivants :

  • Tout le monde peut créer de nombreux locataires gratuitement. Vous n’avez pas besoin d’un service provisionné dans celui-ci. J’en ai des dizaines. Chaque nom de locataire est unique dans le service cloud mondial de Microsoft (en d’autres termes, aucun locataire ne peut avoir le même nom). Ils sont tous au format de TenantName.onmicrosoft.com. Il existe également des processus qui créent automatiquement des locataires (locataires non managés). Par exemple, ce résultat peut se produire lorsqu’un utilisateur s’inscrit à un service d’entreprise avec un domaine de messagerie qui n’existe dans aucun autre locataire.
  • Dans un locataire managé, de nombreux domaines DNS peuvent y être inscrits. Ce résultat ne change pas le nom du locataire d’origine. Il n’existe actuellement aucun moyen simple de renommer un locataire (autre que la migration). Bien que le nom du locataire ne soit techniquement pas critique de nos jours, certaines personnes peuvent se sentir limitées par cette réalité.
  • Vous devez réserver un nom de locataire pour votre organization même si vous n’envisagez pas encore de déployer de services. Sinon, quelqu’un peut le prendre de vous et il n’y a pas de processus simple pour le reprendre (même problème que les noms DNS). Je l’entends trop souvent de la part des clients. Le nom de votre locataire doit également être un article de débat.
  • Si vous possédez un espace de noms DNS, vous devez ajouter tous ces espaces de noms à vos locataires. Dans le cas contraire, vous pouvez créer un locataire non managé avec ce nom, ce qui entraîne une interruption pour le rendre géré.
  • Un espace de noms DNS (par exemple, contoso.com) peut appartenir à un seul locataire. Cette exigence a des implications pour différents scénarios (par exemple, le partage d’un domaine de messagerie lors d’une fusion ou d’une acquisition, etc.). Il existe un moyen d’inscrire un sous-réseau DNS (par exemple, div.contoso.com) dans un autre locataire, mais cela doit être évité. En inscrivant un nom de domaine de niveau supérieur, tous les sous-domaines sont supposés appartenir au même locataire. Dans les scénarios multilocataires (comme expliqué ci-dessous), je recommande normalement d’utiliser un autre nom de domaine de niveau supérieur (par exemple, contoso.ch ou ch-contoso.com).
  • Qui doit « posséder » un locataire ? Je vois souvent des clients qui ne savent pas qui possède actuellement leur locataire. Ce manque de connaissances est un indicateur d’alerte important. Appelez le support Microsoft dès que possible. Tout aussi problématique est lorsqu’un propriétaire de service (souvent un administrateur Exchange) est désigné pour gérer un locataire. Le locataire contient tous les services que vous souhaiterez peut-être à l’avenir. Le propriétaire du locataire doit être un groupe capable de prendre une décision pour l’activation de tous les services cloud dans un organization. Un autre problème est lié au fait qu’un groupe de propriétaires de locataires est invité à gérer tous les services. Cette méthode n’est pas mise à l’échelle pour les grandes organisations.
  • Il n’existe aucun concept de sous-locataire/super locataire. Pour une raison quelconque, ce mythe ne cesse de se répéter. Ce concept s’applique également aux locataires Azure Active Directory B2C . J’entends trop de fois : « Mon environnement B2C se trouve dans mon locataire XYZ » ou « Comment faire déplacer mon locataire Azure vers mon locataire Microsoft 365 ? »
  • Ce document se concentre principalement sur le cloud commercial mondial, car c’est ce que la plupart des clients utilisent. Il est parfois utile de connaître les clouds souverains. Les clouds souverains ont d’autres implications à discuter qui sont hors du cadre de cette discussion.

Articles sur l’identité de base de référence

Il existe de nombreuses documentations sur la plateforme d’identité de Microsoft, Microsoft Entra ID. Pour les gens qui commencent, c’est souvent écrasant. Même après avoir appris à le faire, il peut être difficile de suivre l’innovation et le changement constants. Dans mes interactions avec les clients, je me retrouve souvent en tant que « traducteur » entre les objectifs de l’entreprise et les approches « Bon, Meilleur, Meilleur » pour répondre à ces préoccupations (et les « notes de falaise » humaines pour ces articles). Il y a rarement une réponse parfaite et la « bonne » décision est un équilibre entre divers facteurs de risque. Voici quelques-unes des questions courantes et des zones de confusion que j’ai tendance à discuter avec les clients.

Approvisionnement

Microsoft Entra ID ne résout pas le manque de gouvernance dans votre monde d’identité ! La gouvernance des identités doit être un élément critique indépendant de toute décision cloud. Les exigences de gouvernance changent au fil du temps, c’est pourquoi il s’agit d’un programme et non d’un outil.

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) ou autre chose (tiers ou personnalisé) ? Enregistrez vos problèmes maintenant et à l’avenir et utilisez Microsoft Entra Connect. Cet outil comporte toutes sortes d’intelligences pour répondre à des configurations client particulières et à des innovations en cours.

Certains cas de périphérie qui peuvent conduire à une architecture plus complexe :

  • J’ai plusieurs forêts AD sans connectivité réseau entre elles. Il existe une nouvelle option appelée Provisionnement cloud.
  • Je n’ai pas Active Directory et je ne veux pas l’installer. Microsoft Entra Connect peut être configuré pour la synchronisation à partir de LDAP (le partenaire peut être requis).
  • Je dois provisionner les mêmes objets sur plusieurs locataires. Ce scénario n’est pas techniquement pris en charge, mais dépend de la définition de « same ».

Dois-je personnaliser les règles de synchronisation par défaut (filtrer les objets, modifier les attributs, id de connexion de remplacement, et ainsi de suite) ? Évitez-le ! Une plateforme d’identité n’a que la valeur des services qui l’utilisent. Bien que vous puissiez effectuer toutes sortes de configurations difficiles, pour répondre à cette question, vous devez examiner l’effet sur les applications. Si vous filtrez des objets à extension messagerie, la liste d’adresses gal pour services en ligne est incomplète ; si l’application s’appuie sur des attributs spécifiques, le filtrage sur ces attributs a des effets imprévisibles, etc. Ce n’est pas une décision d’équipe d’identité.

XYZ SaaS prend en charge l’approvisionnement juste-à-temps (JIT), pourquoi me demander de synchroniser ? Consultez le paragraphe précédent. De nombreuses applications ont besoin d’informations de « profil » pour les fonctionnalités. Vous ne pouvez pas avoir de gal si tous les objets à extension messagerie ne sont pas disponibles. Il en va de même pour l’approvisionnement d’utilisateurs dans les applications intégrées à Microsoft Entra ID.

Authentification

Synchronisation de hachage de mot de passe (PHS), authentification directe (PTA) et fédération.

Habituellement, il y a un débat passionné autour de la fédération. Plus simple est généralement préférable et donc utiliser PHS sauf si vous avez une bonne raison de ne pas. Il est également possible de configurer différentes méthodes d’authentification pour différents domaines DNS dans le même locataire.

Certains clients activent la fédération + PHS principalement pour :

Je guide souvent les clients dans le flux d’authentification client pour clarifier certaines idées fausses. Le résultat ressemble à l’image suivante, ce qui n’est pas aussi bon que le processus interactif pour y arriver.

Exemple de conversation sur un tableau blanc.

Ce type de dessin de tableau blanc montre où les stratégies de sécurité sont appliquées dans le flux d’une demande d’authentification. Dans cet exemple, les stratégies appliquées par le biais du service de fédération Active Directory (AD FS) sont appliquées à la première demande de service, mais pas aux demandes de service suivantes. Ce comportement est au moins une raison de déplacer les contrôles de sécurité vers le cloud autant que possible.

Nous avons poursuivi le rêve de l’authentification unique (SSO) depuis aussi longtemps que je me souvienne. Certains clients pensent qu’ils peuvent obtenir l’authentification unique en choisissant le fournisseur de fédération « approprié » (STS). Microsoft Entra ID peut considérablement aider à activer les fonctionnalités d’authentification unique, mais aucun STS n’est magique. Il existe trop de méthodes d’authentification « héritées » qui sont encore utilisées pour les applications critiques. L’extension Microsoft Entra ID avec des solutions partenaires peut répondre à la plupart de ces scénarios. L’authentification unique est une stratégie et un parcours. Vous ne pouvez pas y accéder sans passer à des normes pour les applications. Cet article est lié à un parcours vers l’authentification sans mot de passe , qui n’a pas non plus de réponse magique.

L’authentification multifacteur (MFA) est essentielle aujourd’hui (ici pour plus d’informations). Ajoutez-y l’analyse du comportement des utilisateurs et vous disposez d’une solution qui empêche les cyberattaques les plus courantes. Même les services grand public passent à l’authentification multifacteur. Pourtant, je rencontre encore de nombreux clients qui ne souhaitent pas passer à des approches d’authentification modernes . Le plus gros argument que j’entends est qu’il a un impact sur les utilisateurs et les applications héritées. Parfois, un bon coup de pied peut aider les clients à avancer - Exchange Online des changements annoncés. De nombreux rapports Microsoft Entra sont désormais disponibles pour aider les clients à effectuer cette transition.

Autorisation

Selon Wikipédia, « autoriser » consiste à définir une stratégie d’accès. De nombreuses personnes la souhaitent comme la possibilité de définir des contrôles d’accès à un objet (fichier, service, etc.). Dans le monde actuel des cybermenaces, ce concept évolue rapidement vers une politique dynamique capable de réagir aux différents vecteurs de menaces et d’ajuster rapidement les contrôles d’accès en réponse à ces derniers. Par exemple, si j’accède à mon compte bancaire à partir d’un emplacement inhabituel, j’obtiens des étapes de confirmation supplémentaires. Pour aborder cette réalité, nous devons prendre en compte non seulement la politique elle-même, mais aussi l’écosystème des méthodologies de détection des menaces et de corrélation des signaux.

Le moteur de stratégie de Microsoft Entra ID est implémenté à l’aide de stratégies d’accès conditionnel. Ce système dépend des informations d’autres systèmes de détection des menaces pour prendre des décisions dynamiques. Une vue simple ressemble à l’illustration suivante :

Moteur de stratégie dans Microsoft Entra ID.

La combinaison de tous ces signaux permet des stratégies dynamiques comme celles-ci :

  • Si une menace est détectée sur votre appareil, votre accès aux données est réduit au web uniquement sans possibilité de téléchargement.
  • Si vous téléchargez un volume de données inhabituellement élevé, tout ce que vous téléchargez est chiffré et restreint.
  • Si vous accédez à un service à partir d’un appareil non géré, vous êtes bloqué à partir de données hautement sensibles, mais vous êtes autorisé à accéder à des données non contraintes sans avoir la possibilité de les copier vers un autre emplacement.

Si vous êtes d’accord avec cette définition étendue de l’autorisation, vous devez implémenter des solutions supplémentaires. Les solutions que vous implémentez dépendent de la dynamique que vous souhaitez que la stratégie soit dynamique et des menaces que vous souhaitez hiérarchiser. Voici quelques exemples de ces systèmes :

En plus de Microsoft Entra ID, différents services et applications ont leurs propres modèles d’autorisation spécifiques. Certains de ces modèles sont abordés plus loin dans la section délégation.

Audit

Microsoft Entra ID dispose de fonctionnalités détaillées d’audit et de création de rapports. Toutefois, ces rapports ne sont généralement pas la seule source d’informations nécessaires pour prendre des décisions en matière de sécurité. Pour plus d’informations sur ce sujet, consultez la section délégation.

Il n’y a pas d’échange

Ne paniquez pas ! Exchange n’est pas déconseillé (ou SharePoint, etc.). Il s’agit toujours d’un service de base. Ce que je veux dire, c’est que depuis un certain temps, les fournisseurs de technologie ont fait la transition de l’expérience utilisateur (UX) pour englober les composants de plusieurs services. Dans Microsoft 365, un exemple simple est « pièces jointes modernes » où les pièces jointes aux e-mails sont stockées dans SharePoint Online ou OneDrive.

Joindre un fichier à un e-mail.

En examinant le client Outlook, vous pouvez voir de nombreux services qui sont « connectés » dans le cadre de cette expérience, pas seulement Exchange. Exemples : Microsoft Entra ID, Recherche Microsoft, Applications, Profil, conformité et groupes Microsoft 365.

Interface Outlook avec légendes.

En savoir plus sur Infrastructure Microsoft Fluid pour obtenir la préversion des fonctionnalités à venir. En préversion, je peux lire et répondre aux conversations Teams directement dans Outlook. En fait, le client Teams est l’un des exemples les plus importants de cette stratégie.

Dans l’ensemble, il devient de plus en plus difficile de tracer une ligne claire entre Microsoft 365 et d’autres services dans les clouds Microsoft. Je considère cela comme un grand avantage pour les clients, car ils peuvent bénéficier d’une innovation totale dans tout ce que nous faisons, même s’ils utilisent un seul composant. Assez cool et a des implications de grande portée pour de nombreux clients.

Aujourd’hui, je trouve que de nombreux groupes informatiques clients sont structurés autour de « produits ». C’est logique pour un monde local, car vous avez besoin d’un expert pour chaque produit spécifique. Toutefois, je suis heureux de ne plus avoir à déboguer une base de données Active Directory ou Exchange, car ces services ont été déplacés vers le cloud. L’automatisation (qui est essentiellement le cloud) supprime certains travaux manuels répétitifs (regardez ce qui est arrivé aux usines). Toutefois, ces tâches sont remplacées par des exigences plus complexes pour comprendre l’interaction interservices, l’effet, les besoins métier, etc. Si vous êtes prêt à apprendre, la transformation cloud offre d’excellentes opportunités. Avant de me lancer dans la technologie, je parle souvent aux clients de la gestion des changements dans les compétences informatiques et les structures d’équipe.

À tous les fans et développeurs SharePoint, arrêtez de demander « Comment puis-je faire XYZ dans SharePoint Online ? » Utilisez Power Automate (ou Flow) pour le flux de travail. Il s’agit d’une plateforme beaucoup plus puissante. Utilisez Azure Bot Framework pour créer une meilleure expérience utilisateur pour votre liste de 500 000 éléments. Commencez à utiliser Microsoft Graph au lieu de CSOM. Microsoft Teams inclut SharePoint, mais aussi un monde plus. Il y a beaucoup d’autres exemples que je peux lister. Il y a un univers vaste et merveilleux là-bas. Ouvrez la porte et commencez à explorer.

L’autre effet courant concerne la zone de conformité. Cette approche interservices semble complètement confondre de nombreuses stratégies de conformité. Je continue de voir les organisations qui déclarent : « Je dois journaliser toutes les communications par e-mail dans un système eDiscovery ». Qu’est-ce que cette affirmation signifie vraiment lorsque le courrier n’est plus simplement un courrier électronique, mais une fenêtre sur d’autres services ? Microsoft 365 a une approche complète de la conformité, mais la modification des personnes et des processus est souvent beaucoup plus difficile que la technologie.

Il y a beaucoup d’autres personnes et d’autres implications sur le processus. À mon avis, ce facteur est critique et sous-discuté. Peut-être plus dans un autre article.

Options de structure de locataire

Monolocataire ou multilocataire

En général, la plupart des clients ne doivent avoir qu’un seul locataire de production. Il existe de nombreuses raisons pour lesquelles plusieurs locataires sont difficiles (donnez-lui une recherche Bing) ou lisez ce livre blanc. Dans le même temps, de nombreux clients d’entreprise avec lesquels je travaille ont un autre (petit) locataire pour l’apprentissage, le test et l’expérimentation informatiques. L’accès Azure interlocataire est simplifié avec Azure Lighthouse. Microsoft 365 et de nombreux autres services SaaS ont des limites pour les scénarios inter-locataires. Il y a beaucoup à prendre en compte dans Microsoft Entra scénarios B2B.

De nombreux clients se retrouvent avec plusieurs locataires de production après une fusion-acquisition (M&A) et souhaitent consolider. Aujourd’hui, ce n’est pas simple et nécessite Microsoft Consulting Services (MCS) ou un partenaire et un logiciel tiers. Un travail d’ingénierie est en cours pour répondre à différents scénarios avec des clients multilocataires à l’avenir.

Certains clients choisissent d’utiliser plusieurs locataires. Cela devrait être une décision prudente et presque toujours une raison d’affaires pilotée ! Voici quelques exemples :

  • Structure d’entreprise de type holding où la collaboration facile entre les différentes entités n’est pas nécessaire et où il existe de forts besoins d’isolation administratifs et autres.
  • Après une acquisition, une décision commerciale est prise de garder deux entités distinctes.
  • Simulation de l’environnement d’un client qui ne change pas l’environnement de production du client.
  • Développement de logiciels pour les clients.

Dans ces scénarios multilocataires, les clients souhaitent souvent conserver une configuration identique entre les locataires, ou créer des rapports sur les modifications et les dérives de configuration. Cela signifie souvent passer des modifications manuelles à la configuration en tant que code. La prise en charge de Microsoft Premiere propose un atelier pour ces types d’exigences en fonction de cette adresse IP publique : https://Microsoft365dsc.com.

Multi-Géo

À multigéographique ou non à multigéographique. C’est la question. Avec Microsoft 365 Multi-Geo, vous pouvez provisionner et stocker des données au repos dans les emplacements géographiques que vous choisissez pour répondre aux exigences de résidence des données . Il y a beaucoup d’idées fausses sur cette fonctionnalité. Gardez à l’esprit les points suivants :

  • Il ne permet pas de bénéficier d’avantages en matière de performances. Cela peut aggraver les performances si la conception du réseau n’est pas correcte. Obtenez des appareils « proches » du réseau Microsoft, pas nécessairement de vos données.
  • Il ne s’agit pas d’une solution pour la conformité au RGPD. Le RGPD ne se concentre pas sur la souveraineté des données ou les emplacements de stockage. Il existe d’autres frameworks de conformité pour la souveraineté des données ou les emplacements de stockage.
  • Il ne résout pas la délégation d’administration (voir ci-dessous) ou les obstacles à l’information.
  • Il n’est pas identique à multilocataire et nécessite davantage de flux de travail d’approvisionnement d’utilisateurs .
  • Il ne déplace pas votre locataire (votre Microsoft Entra ID) vers une autre zone géographique.

Délégation de l’administration

Dans la plupart des grandes organisations, la séparation des tâches et le contrôle d’accès en fonction du rôle (RBAC) sont une réalité nécessaire. Je vais m’excuser à l’avance. Cette activité n’est pas aussi simple que certains clients le souhaitent. Les exigences des clients, juridiques, de conformité et d’autres exigences sont différentes et parfois contradictoires dans le monde entier. La simplicité et la flexibilité sont souvent opposées les unes des autres. Ne vous méprenez pas, nous pouvons faire un meilleur travail à cet objectif. Des améliorations significatives ont été (et seront) apportées au fil du temps. Visitez votre centre de technologie Microsoft local pour découvrir le modèle qui répond aux besoins de votre entreprise sans lire 379 230 documents ! Ici, je me concentre sur ce que vous devez penser et non pas sur la raison pour laquelle c’est ainsi. À venir, il y a cinq domaines différents à planifier et certaines des questions courantes que je rencontre.

centres d’administration Microsoft Entra ID et Microsoft 365

La liste des rôles intégrés est longue et croissante. Chaque rôle se compose d’une liste d’autorisations de rôle regroupées pour permettre l’exécution d’actions spécifiques. Vous pouvez voir ces autorisations dans l’onglet « Description » à l’intérieur de chaque rôle. Vous pouvez également voir une version plus lisible de ces autorisations dans le Centre Administration Microsoft 365. Les définitions des rôles intégrés ne peuvent pas être modifiées. En règle générale, je regroupe ces rôles en trois catégories :

  • Administrateur général : ce rôle « tout puissant » doit être hautement protégé comme vous le feriez dans d’autres systèmes. Les recommandations classiques incluent : pas d’affectation permanente et d’utilisation Microsoft Entra Privileged Identity Management (PIM), authentification forte, etc. Fait intéressant, ce rôle ne vous donne pas accès à tout par défaut. En règle générale, je vois une confusion au sujet de l’accès de conformité et de l’accès Azure, abordé plus loin. Toutefois, ce rôle peut toujours attribuer l’accès à d’autres services dans le locataire.
  • Administrateurs de service spécifiques : certains services (Exchange, SharePoint, Power BI, etc.) utilisent des rôles d’administration de haut niveau à partir de Microsoft Entra ID. Ce comportement n’est pas cohérent entre tous les services et il existe d’autres rôles spécifiques au service abordés plus loin.
  • Fonctionnel : il existe une longue liste (et de plus en plus) de rôles axés sur des opérations spécifiques (inviteur d’invités, etc.). Régulièrement, un plus grand nombre de ces rôles sont ajoutés en fonction des besoins des clients.

Il n’est pas possible de tout déléguer (bien que l’écart diminue), ce qui signifie que le rôle d’administrateur général doit parfois être utilisé. La configuration en tant que code et l’automatisation doivent être prises en compte au lieu de l’appartenance de personnes à ce rôle.

Remarque : l’Centre d'administration Microsoft 365 dispose d’une interface plus conviviale, mais possède un sous-ensemble de fonctionnalités par rapport à l’expérience d’administration Microsoft Entra. Les deux portails utilisent les mêmes rôles Microsoft Entra, de sorte que les modifications se produisent au même endroit. Conseil : si vous souhaitez une interface utilisateur d’administration axée sur la gestion des identités sans tout l’encombrement Azure, utilisez https://aad.portal.azure.com.

Quel est le nom ? Ne faites pas d’hypothèses à partir du nom du rôle. La langue n’est pas un outil précis. L’objectif doit être de définir les opérations qui doivent être déléguées avant d’examiner les rôles nécessaires. L’ajout d’une personne au rôle « Lecteur de sécurité » ne lui permet pas de voir les paramètres de sécurité sur tout.

La possibilité de créer des rôles personnalisés est une question courante. Cette fonctionnalité est limitée dans Microsoft Entra aujourd’hui (comme expliqué plus loin), mais elle augmentera au fil du temps. Je pense que ces rôles personnalisés s’appliquent aux fonctions dans Microsoft Entra ID et peuvent ne pas couvrir « en bas » le modèle de hiérarchie (comme indiqué précédemment). Chaque fois que je traite avec « personnalisé », j’ai tendance à revenir à mon principe de « simple est mieux ».

Une autre question courante est la capacité à étendre les rôles à un sous-ensemble d’un répertoire. Un exemple est quelque chose comme « Administrateur du support technique pour les utilisateurs dans l’UE uniquement ». Les unités administratives sont destinées à traiter ce scénario. Comme décrit précédemment, je pense que ces étendues s’appliquent aux fonctions dans Microsoft Entra ID et peuvent ne pas s’étendre « vers le bas ». L’étendue de certains rôles n’a pas de sens (administrateurs généraux, administrateurs de service, etc.).

Aujourd’hui, tous ces rôles nécessitent une appartenance directe (ou une attribution dynamique si vous utilisez Microsoft Entra PIM). Cela signifie que les clients doivent gérer ces rôles directement dans Microsoft Entra ID et que ces rôles ne peuvent pas être basés sur une appartenance à un groupe de sécurité. Je ne suis pas un fan de la création de scripts pour gérer ces rôles, car il devrait s’exécuter avec des droits élevés. Je recommande généralement l’intégration d’API à des systèmes de processus comme ServiceNow ou l’utilisation d’outils de gouvernance partenaires comme Saviynt. Des travaux d’ingénierie sont en cours pour résoudre ce problème au fil du temps.

J’ai mentionné Microsoft Entra PIM à plusieurs reprises. Il existe une solution de gestion des accès privilégiés (PAM) Microsoft Identity Manager (MIM) correspondante pour les contrôles locaux. Vous pouvez également examiner les stations de travail à accès privilégié (PW) et les Gouvernance Microsoft Entra ID. Il existe également différents outils tiers, qui peuvent permettre une élévation de rôle juste-à-temps, juste-assez et dynamique. Cette fonctionnalité fait généralement partie d’une discussion plus large sur la sécurisation d’un environnement.

Parfois, les scénarios appellent l’ajout d’un utilisateur externe à un rôle (voir la section multilocataire précédente). Ce résultat fonctionne correctement. Microsoft Entra B2B est un autre article volumineux et amusant pour guider les clients à travers, peut-être dans un autre article.

portails de conformité Microsoft Defender XDR et Microsoft 365 Purview

Email & rôles de collaboration dans le portail Microsoft Defender et *Groupes de rôles pour les solutions Microsoft Purview dans le portail de conformité Microsoft 365 Purview sont une collection de « groupes de rôles », qui sont distincts et distincts des rôles Microsoft Entra. Cela peut prêter à confusion, car certains de ces groupes de rôles ont le même nom que Microsoft Entra rôles (par exemple, Lecteur de sécurité), mais ils peuvent avoir une appartenance différente. Je préfère l’utilisation de rôles Microsoft Entra. Chaque groupe de rôles se compose d’un ou de plusieurs « rôles » (voir ce que je veux dire par rapport à la réutilisation du même mot ?) et a des membres de Microsoft Entra ID, qui sont des objets activés pour les e-mails. En outre, vous pouvez créer un groupe de rôles portant le même nom qu’un rôle, qui peut contenir ou non ce rôle (évitez cette confusion).

En un sens, ces autorisations sont une évolution du modèle de groupes de rôles Exchange. Toutefois, Exchange Online a sa propre interface de gestion des groupes de rôles. Certains groupes de rôles dans Exchange Online sont verrouillés et gérés à partir de Microsoft Entra ID ou des portails de conformité Microsoft Defender XDR et Microsoft 365 Purview, mais d’autres peuvent avoir le même nom ou des noms similaires et sont gérés dans Exchange Online (ce qui ajoute à la confusion). Je vous recommande d’éviter d’utiliser l’interface utilisateur Exchange Online, sauf si vous avez besoin d’étendues pour la gestion d’Exchange.

Vous ne pouvez pas créer de rôles personnalisés. Les rôles sont définis par les services créés par Microsoft et continuent de croître à mesure que de nouveaux services sont introduits. Ce comportement est similaire dans le concept aux rôles définis par les applications dans Microsoft Entra ID. Lorsque de nouveaux services sont activés, de nouveaux groupes de rôles doivent souvent être créés pour accorder ou déléguer l’accès à ces derniers (par exemple, la gestion des risques internes).

Ces groupes de rôles nécessitent également une appartenance directe et ne peuvent pas contenir Microsoft Entra groupes. Malheureusement, aujourd’hui, ces groupes de rôles ne sont pas pris en charge par Microsoft Entra PIM. Comme Microsoft Entra rôles, j’ai tendance à recommander la gestion de ces groupes de rôles par le biais d’API ou d’un produit de gouvernance partenaire comme Saviynt, ou d’autres.

Microsoft Defender portail et les rôles de portail de conformité Microsoft 365 Purview couvrent Microsoft 365 et vous ne pouvez pas étendre ces groupes de rôles à un sous-ensemble de l’environnement (comme vous le pouvez avec des unités administratives dans Microsoft Entra ID). De nombreux clients demandent comment ils peuvent subdéléguer. Par exemple, « créer une stratégie DLP uniquement pour les utilisateurs de l’UE ». Aujourd’hui, si vous disposez de droits sur une fonction spécifique dans les portails de conformité Microsoft Defender XDR et Microsoft 365 Purview, vous disposez des droits sur tout ce qui est couvert par cette fonction dans le locataire. Toutefois, de nombreuses stratégies ont des fonctionnalités permettant de cibler un sous-ensemble de l’environnement (par exemple, « rendre ces étiquettes accessibles uniquement à ces utilisateurs »). Une gouvernance et une communication appropriées sont un élément clé pour éviter les conflits. Certains clients choisissent d’implémenter une approche de « configuration en tant que code » pour résoudre les problèmes de sous-suppression dans les portails de conformité Microsoft Defender XDR et Microsoft 365 Purview. Certains services spécifiques prennent en charge la sous-suppression (voir la section suivante).

Spécifique au service

Comme indiqué précédemment, de nombreux clients cherchent à obtenir un modèle de délégation plus granulaire. Exemple courant : « Gérer le service XYZ uniquement pour les utilisateurs et les emplacements de division X » (ou une autre dimension). La possibilité d’effectuer cette opération dépend de chaque service et n’est pas cohérente entre les services et les fonctionnalités. En outre, chaque service peut avoir un modèle RBAC distinct et unique. Au lieu de discuter de tous ces modèles (ce qui prendrait une éternité), j’ajoute des liens pertinents pour chaque service. Cette liste n’est pas complète, mais elle peut vous aider à démarrer.

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • eDiscovery - (.. /compliance/index.yml)
    • Filtrage des autorisations - (.. /compliance/index.yml)
    • Limites de conformité - (.. /compliance/set-up-compliance-boundaries.md)
    • eDiscovery (Premium) - (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multigéographique - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 : (/dynamics365/)

Remarque

Ce lien est à la racine de la documentation. Il existe plusieurs types de services avec des variantes dans le modèle d’administration/délégation.

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      Remarque

      il existe plusieurs types avec des variantes dans les modèles d’administration/délégation.

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      Remarque : La sécurité et la délégation de la plateforme de données (dont Power BI est un composant) sont un domaine complexe.

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender pour point de terminaison : (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps - (/cloud-app-security/manage-admins)

  • Flux - (/stream/assign-administrator-user-role)

  • Obstacles à l’information - (.. /compliance/information-barriers.md)

Journaux d’activité

Microsoft 365 dispose d’un journal d’audit unifié. Il s’agit d’un journal très détaillé, mais ne lisez pas trop dans le nom. Il peut ne pas contenir tout ce que vous souhaitez ou avez besoin pour vos besoins en matière de sécurité et de conformité. En outre, certains clients sont très intéressés par l’audit (Premium).

Les fonctionnalités suivantes sont des exemples de journaux Microsoft 365 accessibles via d’autres API :

Il est important d’identifier d’abord toutes les sources de journaux nécessaires pour un programme de sécurité et de conformité. Notez également que les différents journaux ont des limites de rétention en ligne différentes.

Du point de vue de la délégation d’administrateur, la plupart des journaux d’activité Microsoft 365 n’ont pas de modèle RBAC intégré. Si vous avez l’autorisation d’afficher un journal, vous pouvez voir tout ce qu’il contient. Un exemple courant d’exigence du client est : « Je souhaite pouvoir interroger l’activité uniquement pour les utilisateurs de l’UE » (ou une autre dimension). Pour ce faire, nous devons transférer les journaux vers un autre service. Dans le cloud Microsoft, nous vous recommandons de le transférer vers Microsoft Sentinel ou Log Analytics.

Diagramme de haut niveau :

diagramme des sources de journaux pour un programme de sécurité et de conformité.

Le diagramme représente les fonctionnalités intégrées permettant d’envoyer des journaux à Event Hubs et/ou stockage Azure et/ou Azure Log Analytics. Tous les systèmes n’incluent pas encore ce prêt à l’emploi. Toutefois, il existe d’autres approches pour envoyer ces journaux au même dépôt. Par exemple, consultez Protection de vos équipes avec Microsoft Sentinel.

La combinaison de tous les journaux dans un seul emplacement de stockage offre un avantage supplémentaire, comme des corrélations croisées, des durées de rétention personnalisées, l’augmentation des données nécessaires à la prise en charge du modèle RBAC, etc. Une fois que les données se trouvent dans ce système de stockage, vous pouvez créer un tableau de bord Power BI (ou un autre type de visualisation) avec un modèle RBAC approprié.

Les journaux n’ont pas besoin d’être dirigés vers un seul emplacement. Il peut également être utile d’intégrer les journaux Microsoft 365 à Microsoft Defender for Cloud Apps ou à un modèle RBAC personnalisé dans Power BI. Les différents dépôts présentent des avantages et des audiences différents.

Il convient de mentionner qu’il existe un système d’analytique intégré riche pour la sécurité, les menaces, les vulnérabilités, etc. dans un service appelé Microsoft Defender XDR.

De nombreux grands clients souhaitent transférer ces données de journal vers un système tiers (par exemple, SIEM). Il existe différentes approches pour ce résultat, mais en général, Azure Event Hubs et Graph sont de bons points de départ.

Azure

On me demande souvent s’il existe un moyen de séparer les rôles à privilèges élevés entre Microsoft Entra ID, Azure et SaaS (par exemple, Administrateur général pour Microsoft 365, mais pas Azure). Pas vraiment. Une architecture multilocataire est nécessaire si une séparation administrative complète est nécessaire, mais cela ajoute une complexité importante (comme indiqué précédemment). Tous ces services font partie de la même limite de sécurité/identité (comme indiqué dans le modèle de hiérarchie).

Il est important de comprendre les relations entre les différents services dans le même locataire. Je travaille avec de nombreux clients qui créent des solutions métier qui couvrent Azure, Microsoft 365 et Power Platform (et souvent aussi des services cloud locaux et tiers). Un exemple courant :

  1. Je souhaite collaborer sur un ensemble de documents/images/etc (Microsoft 365)
  2. Envoyer chacun d’eux via un processus d’approbation (Power Platform)
  3. Une fois tous les composants approuvés, assemblez ces éléments en un ou plusieurs livrables unifiés (Azure) Microsoft API Graph est votre meilleur ami ici. Ce n’est pas impossible, mais beaucoup plus complexe pour concevoir une solution couvrant plusieurs locataires.

Azure Role-Based Access Control (RBAC) permet une gestion affinée des accès pour Azure. À l’aide de RBAC, vous pouvez gérer l’accès aux ressources en accordant aux utilisateurs le moins d’autorisations nécessaires pour effectuer leur travail. Les détails sont hors de portée pour ce document, mais pour plus d’informations sur RBAC, consultez Qu’est-ce que le contrôle d’accès en fonction du rôle (RBAC) dans Azure ? RBAC est important, mais seulement une partie des considérations de gouvernance pour Azure. Cloud Adoption Framework est un excellent point de départ pour en savoir plus. J’aime la façon dont mon ami , Andres Ravinet, guide les clients pas à pas à travers différents composants pour décider de l’approche. La vue d’ensemble de divers éléments (pas aussi bon que le processus d’obtention du modèle client réel) est semblable à ceci :

Vue d’ensemble des composants Azure pour l’administration déléguée.

Comme vous pouvez le voir dans l’image ci-dessus, de nombreux autres services doivent être pris en compte dans le cadre de la conception (par exemple, Azure Policies, Azure Blueprints, groupes d’administration, etc.).

Conclusion

Cet article a commencé comme un bref résumé, finalement plus long que prévu. J’espère que vous êtes maintenant prêt à vous aventurer dans une vue approfondie de la création d’un modèle de délégation pour votre organization. Cette conversation est très courante avec les clients. Il n’existe aucun modèle qui fonctionne pour tout le monde. En attente de quelques améliorations planifiées de l’ingénierie Microsoft avant de documenter les modèles courants que nous voyons parmi les clients. En attendant, vous pouvez collaborer avec votre équipe de compte Microsoft pour organiser une visite au Centre de technologie Microsoft le plus proche. Rendez-vous là- bas !