Planification de l’identité pour les applications Azure Government

Microsoft Azure Government fournit les mêmes moyens de créer des applications et de gérer des identités que Azure Public. Les clients Azure Government peuvent déjà avoir un locataire public Microsoft Entra ou créer un locataire dans Microsoft Entra Government. Cet article fournit des conseils sur les décisions relatives à la gestion de l’identité en fonction de l'utilisation et de l’emplacement de votre identité.

Modèles d’identité

Avant de déterminer l’approche d’identité de votre application, vous devez savoir quels types d’identité sont disponibles pour vous. Il existe trois types : identité locale, identité cloud et identité hybride.

Identité locale	Identité cloud	Identité hybride
Les identités locales appartiennent aux environnements Active Directory locaux qu'utilisent la plupart des clients aujourd'hui.	Les identités cloud proviennent, existent uniquement et sont gérées dans Microsoft Entra ID.	Les identités hybrides proviennent d’identités locales, mais deviennent hybrides par le biais de la synchronisation d’annuaires pour Microsoft Entra ID. Après la synchronisation d’annuaires, elles existent à la fois localement et dans le cloud, donc hybrides.

Note

Hybrid est fourni avec les options de déploiement (identité synchronisée, identité fédérée, et ainsi de suite) qui s’appuient sur la synchronisation d’annuaires et définissent principalement comment les identités sont authentifiées comme indiqué dans Quel est l’identité hybride avec Microsoft Entra ID ?

Sélection de l’identité pour une application Azure Government

Lors de la création d’une application Azure, vous devez d’abord décider de la technologie d’authentification :

• Applications à l’aide de l’authentification moderne : applications utilisant OAuth, OpenID Connect et/ou d’autres protocoles d’authentification modernes pris en charge par Microsoft Entra telles que les applications nouvellement développées à l’aide de technologies PaaS, par exemple, Web Apps, Azure SQL Database, etc.
• Applications utilisant des protocoles d’authentification hérités (Kerberos/NTLM) : les applications généralement migrées à partir d’applications locales, par exemple des applications lift-and-shift.

En fonction de cette décision, il existe différentes considérations lors de la création et du déploiement sur Azure Government.

Applications utilisant l’authentification moderne dans Azure Government

Enregistrer une application avec la plateforme d’identités Microsoft montre comment utiliser Microsoft Entra ID pour fournir une connexion sécurisée et une autorisation à vos applications. Ce processus est le même pour Azure public et Azure Government une fois que vous avez choisi votre autorité d’identité.

Choix de votre autorité d’identité

Azure Government applications peuvent utiliser Microsoft Entra identités gouvernementales, mais pouvez-vous utiliser Microsoft Entra identités publiques pour s’authentifier auprès d’une application hébergée dans Azure Government ? Yes! Étant donné que vous pouvez utiliser l’une ou l’autre autorité d’identité, vous devez choisir celle à utiliser :

• Microsoft Entra Public : couramment utilisé si votre organisation dispose déjà d’un locataire public Microsoft Entra pour prendre en charge Office 365 (public ou GCC) ou une autre application.
• Microsoft Entra Government : couramment utilisé si votre organisation dispose déjà d’un locataire Microsoft Entra Government pour prendre en charge Office 365 (GCC High ou DoD) ou créez un locataire dans Microsoft Entra Government.

Une fois que vous avez décidé, vous devez tenir compte de l’endroit où vous effectuez l’inscription de votre application. Si vous choisissez les identités publiques de Microsoft Entra pour votre application Azure Government, vous devez inscrire l’application dans votre client public Microsoft Entra. Sinon, si vous effectuez l'inscription de l'application dans le répertoire approuvé par l'abonnement (Azure Government), l'ensemble prévu d'utilisateurs ne pourra pas s'authentifier.

Note

Les applications inscrites auprès de Microsoft Entra-only autorisent la connexion des utilisateurs dans le locataire Microsoft Entra dans lequel l’application a été inscrite. Si vous disposez de plusieurs locataires Microsoft Entra Public, il est important d’identifier celui qui doit autoriser les connexions. Si vous envisagez d’autoriser les utilisateurs à s’authentifier auprès de l’application à partir de plusieurs locataires Microsoft Entra, l’application doit être inscrite dans chaque locataire.

L’autre considération est l’URL de l’autorité d’identité. Vous avez besoin de l’URL correcte en fonction de votre autorité choisie :

Autorité d’identité	URL
Microsoft Entra Public	login.microsoftonline.com
Microsoft Entra Government	login.microsoftonline.us

Applications utilisant des protocoles d’authentification hérités (Kerberos/NTLM)

La prise en charge des applications cloud IaaS (Infrastructure-as-a-Service) dépendantes de l’authentification NTLM/Kerberos nécessite une identité locale. L’objectif est de prendre en charge les connexions pour les applications métier et d’autres applications nécessitant une authentification intégrée Windows. L’ajout de Active Directory contrôleurs de domaine en tant que machines virtuelles dans Azure IaaS est la méthode classique pour prendre en charge ces types d’applications, comme illustré dans la figure suivante :

Note

La figure précédente est un exemple de connectivité simple, à l’aide d’un VPN de site à site. Azure ExpressRoute est une autre option de connectivité préférée.

Le type de contrôleur de domaine à placer dans Azure est également une considération basée sur les exigences d’application pour l’accès au répertoire. Si les applications nécessitent un accès en écriture de répertoire, déployez un contrôleur de domaine standard avec une copie accessible en écriture de la base de données Active Directory. Si les applications nécessitent uniquement un accès en lecture d’annuaire, nous vous recommandons de déployer un contrôleur de domaine Read-Only (RODC) pour Azure à la place. Plus précisément, pour les contrôleurs de domaine en lecture seule (RODC), nous recommandons de suivre les recommandations disponibles dans la section Planification de l’emplacement des contrôleurs de domaine.

La documentation couvrant les instructions relatives au déploiement de contrôleurs Active Directory Domain et des services ADFS (Active Director Federation Services) est disponible à partir de :

• Virtualisation sécurisée de Active Directory Domain Services répond aux questions telles que
  • Est-il sûr de virtualiser les contrôleurs de domaine Active Directory de Windows Server ?
  • Pourquoi déployer Active Directory sur Azure Virtual Machines ?
  • Pouvez-vous déployer ADFS sur Azure Virtual Machines ?
• Deploying Active Directory Federation Services dans Azure fournit des conseils sur la façon de déployer ADFS dans Azure.

Scénarios d’identité pour l’administration des abonnements dans Azure Government

Tout d’abord, consultez Connect to Azure Government using portal pour obtenir des instructions sur l’accès au portail de gestion Azure Government.

Il existe quelques points importants qui définissent la base de cette section :

• Les abonnements Azure n’approuvent qu’un seul répertoire. Par conséquent, l’administration des abonnements doit être effectuée par une identité provenant de ce répertoire.
• Les abonnements Azure Public font confiance aux répertoires de Microsoft Entra Public, tandis que les abonnements Azure Government font confiance aux répertoires de Microsoft Entra Government.
• Si vous avez à la fois Azure abonnements publics et Azure Government, des identités distinctes pour les deux sont requises.

Les scénarios d’identité actuellement pris en charge pour gérer simultanément Azure abonnements publics et Azure Government sont les suivants :

• Identités cloud : les identités cloud sont utilisées pour gérer les deux abonnements.
• Identités hybrides et cloud : identité hybride pour un abonnement, identité cloud pour l’autre.
• Identités hybrides : les identités hybrides sont utilisées pour gérer les deux abonnements.

Un scénario courant, avec des abonnements Office 365 et Azure, est transmis dans les sections suivantes.

Utilisation des identités cloud pour l’administration d’abonnements multiclouds

Le diagramme suivant est le plus simple des scénarios à implémenter.

Bien que l’utilisation d’identités cloud soit l’approche la plus simple, elle est également la moins sécurisée, car les mots de passe sont utilisés comme facteur d’authentification. Nous vous recommandons Microsoft Entra l'authentification multifacteur, solution de vérification en deux étapes de Microsoft, pour ajouter une deuxième couche critique de sécurité pour sécuriser l'accès aux abonnements Azure lors de l'utilisation d'identités cloud.

Utilisation d’identités hybrides et cloud pour l’administration d’abonnements multiclouds

Dans ce scénario, nous incluons des identités d’administrateur par le biais de la synchronisation d’annuaires avec le locataire public, tandis que les identités cloud sont toujours utilisées dans le locataire du gouvernement.

L’utilisation d’identités hybrides pour les comptes d’administration permet d’utiliser des cartes à puce (physiques ou virtuelles). Les agences gouvernementales utilisant des cartes d’accès communs (CAC) ou des cartes de vérification d’identité personnelle (PIV) bénéficient de cette approche. Dans ce scénario, ADFS sert de fournisseur d’identité et implémente la vérification en deux étapes (par exemple, carte à puce + code confidentiel).

Utilisation d’identités hybrides pour l’administration d’abonnements multiclouds

Dans ce scénario, les identités hybrides sont utilisées pour les abonnements d’administrateur dans les deux clouds.

Questions fréquemment posées

Pourquoi Office 365 GCC utilise-t-il Microsoft Entra public ?
Le premier environnement Office 365 pour le gouvernement des États-Unis, "Government Community Cloud" (GCC), a été créé lorsque Microsoft disposait d'un répertoire cloud unique. L’environnement Office 365 GCC a été conçu pour utiliser Microsoft Entra public tout en respectant toujours les contrôles et les exigences décrits dans FedRAMP Moderate, Criminal Justice Information Services (CJIS), Internal Revenue Service (IRS) 1075 et National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171. Azure Government, avec son infrastructure Microsoft Entra, a été créée ultérieurement. À ce moment-là, GCC avait déjà sécurisé les autorisations de conformité nécessaires (par exemple, FedRAMP Moderate et CJIS) pour répondre aux exigences fédérales, d’état et de gouvernement local tout en servant des centaines de milliers de clients. À présent, de nombreux clients Office 365 GCC ont deux locataires Microsoft Entra : l’un de l’abonnement Microsoft Entra qui prend en charge Office 365 GCC et l’autre de leur abonnement Azure Government, avec des identités dans les deux.

Comment identifier un locataire Azure Government ?
Voici un moyen de savoir à l’aide de votre navigateur de choix :

• Obtenez votre nom de locataire (par exemple, contoso.onmicrosoft.com) ou un nom de domaine inscrit à votre locataire Microsoft Entra (par exemple, contoso.gov).

• Accédez à https://login.microsoftonline.com/<domainname>/.well-known/openid-configuration.

  • <domainname> peut être le nom de locataire ou le nom de domaine que vous avez collecté à l’étape précédente.
  • Exemple d’URL : https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

• Le résultat est renvoyé à la page sous forme de paires attribut/valeur au format JavaScript Object Notation (JSON), semblable à ce qui suit :

  {
    "authorization_endpoint":"https://login.microsoftonline.com/b552ff1c-edad-4b6f-b301-5963a979bc4d/oauth2/authorize",
    "tenant_region_scope":"USG"
  }
  

• Si la valeur de l’attribut tenant_region_scope est USG comme indiqué ou USGov, vous disposez d’un locataire Azure Government.

  • Le résultat est un fichier JSON rendu en mode natif par des navigateurs plus modernes tels que Microsoft Edge, Mozilla Firefox et Google Chrome. Internet Explorer ne restitue pas en mode natif le format JSON. Vous invite donc à ouvrir ou enregistrer le fichier. Si vous devez utiliser Internet Explorer, choisissez l’option Enregistrer et ouvrez-la avec un autre navigateur ou lecteur de texte brut.
  • La propriété tenant_region_scope est précisément ce que son nom indique : régionale. Si vous avez un locataire dans Azure Public en Amérique du Nord, la valeur est NA.

Si je suis un client Office 365 GCC et que je souhaite créer des solutions dans Azure Government dois-je avoir deux locataires ?
Oui, le client Microsoft Entra Government est requis pour la gestion de votre abonnement Azure Government.

Si je suis un client Office 365 GCC qui a généré des charges de travail dans Azure Government, où dois-je m’authentifier à partir de : Public ou Government ?
Consultez Choisir votre autorité d’identité plus haut dans cet article.

Je suis un client Office 365 et j’ai choisi l’identité hybride comme modèle d’identité. J’ai également plusieurs abonnements Azure. Est-il possible d’utiliser le même locataire Microsoft Entra pour gérer la connexion pour Office 365, les applications intégrées à mes abonnements Azure et/ou les applications reconfigurées pour utiliser Microsoft Entra ID pour la connexion ?
Oui, consultez Associer ou ajouter un abonnement Azure à votre locataire Microsoft Entra pour en savoir plus sur la relation entre les abonnements Azure et Microsoft Entra ID. Il contient également des instructions sur l’association d’abonnements au répertoire commun de votre choix.

Un abonnement Azure Government peut-il être associé à un répertoire dans Microsoft Entra Public ?
Non, la possibilité de gérer les abonnements Azure Government nécessite des identités provenant d’un répertoire dans Microsoft Entra Government.

Prochaines étapes

• guide du développeur Azure Government
• Sécurité Azure Government
• Conformité d’Azure Government
• Comparer Azure Government et Azure mondial
• Gestion des utilisateurs mutualisée
• Documentation de base Microsoft Entra