Partager via

Infrastructure de modèle d’application sécurisée

  • Article

Microsoft introduit une infrastructure sécurisée et évolutive pour l’authentification des partenaires fournisseurs de solutions cloud (CSP) et des fournisseurs de panneau de configuration (CPV) via l’architecture mFA (Multifactor Authentication) Microsoft Azure. Les partenaires CSP et les fournisseurs de panneaux de contrôle peuvent s’appuyer sur le nouveau modèle pour améliorer la sécurité des appels d’intégration d’API du Partner Center. Cela permet à toutes les parties, notamment microsoft, les partenaires CSP et les fournisseurs du Panneau de configuration de protéger leur infrastructure et les données client contre les risques de sécurité.

Important

Azure Active Directory (Azure AD) Graph est déconseillé depuis le 30 juin 2023. À l’avenir, nous n’effectuons aucun investissement supplémentaire dans Azure AD Graph. Les API Graph Azure AD n’ont pas de contrat SLA ou de maintenance au-delà des correctifs liés à la sécurité. Les investissements dans de nouvelles fonctionnalités ne seront effectués que dans Microsoft Graph.

Nous allons mettre hors service Azure AD Graph en étapes incrémentielles afin que vous ayez suffisamment de temps pour migrer vos applications vers les API Microsoft Graph. À une date ultérieure que nous annoncerons, nous bloquerons la création de toutes les nouvelles applications à l’aide d’Azure AD Graph.

Pour plus d'informations, consultez Important : Mise à la retraite d'Azure AD Graph et dépréciation du module PowerShell.

Portée

Cet article s’applique aux partenaires suivants :

  • Les fournisseurs de panneau de configuration (CPV) sont des éditeurs de logiciels indépendants qui développent des applications à utiliser par les partenaires CSP pour s’intégrer aux API de l’Espace partenaires. Un CPV n’est pas un partenaire CSP disposant d’un accès direct au tableau de bord ou aux API du partenaire. Il s’agit des entreprises qui développent des applications (généralement des applications web) qui permettent aux fournisseurs de services cloud de vendre leurs produits via une place de marché unifiée.
  • Fournisseurs indirects CSP et partenaires directs CSP qui utilisent l'ID d’application et l’authentification utilisateur et s’intègrent directement aux API de l’Espace partenaires.

Note

Pour être éligible en tant que CPV, vous devez d'abord vous inscrire à l’Espace partenaires en tant que CPV. Si vous êtes un partenaire CSP existant qui est également un CPV, cette condition préalable s’applique également à vous.

Sécuriser le développement d’applications

Au cours du processus de passage de commandes pour les produits Microsoft pour le compte des CSPs, les applications de la place de marché des VPCs interagissent avec les API Microsoft pour passer des commandes et approvisionner des ressources pour les clients.

Voici quelques-unes de ces API :

  • API de l’Espace partenaires implémentant des opérations commerciales telles que le passage de commandes et la gestion des cycles de vie des abonnements.
  • API Microsoft Graph qui implémentent la gestion des identités pour les locataires CSP et les locataires du client CSP.
  • API Azure Resource Manager (ARM) implémentant la fonctionnalité de déploiement Azure.

Les partenaires CSP sont autorisés à utiliser des privilèges délégués pour agir au nom de leurs clients lors de l’appel des API Microsoft. Les privilèges délégués permettent aux partenaires CSP d’effectuer des scénarios d’achat, de déploiement et de support pour leurs clients.

Les applications de la Place de marché sont conçues pour aider les partenaires CSP à répertorier leurs solutions pour les clients. Pour ce faire, les applications de la place de marché doivent emprunter les privilèges de partenaires CSP afin d’appeler les API Microsoft.

Étant donné que les privilèges de partenaire CSP sont élevés et fournissent un accès à tous les clients du partenaire, il est important de comprendre comment ces applications doivent être conçues pour résister aux vecteurs d’exploitation de sécurité. Les attaques de sécurité sur ces applications sensibles peuvent entraîner la compromission des données client. Par conséquent, les autorisations accordées et l’usurpation des privilèges de partenaires doivent être conçues de manière à respecter le principe du privilège minimum. Les principes et bonnes pratiques suivants garantissent que les applications de la Place de marché sont durables et peuvent résister aux compromissions.

Principes de sécurité pour l’usurpation des identifiants

  • Les applications de la Place de marché ne doivent pas stocker les informations d’identification des partenaires CSP.

  • Les mots de passe des utilisateurs partenaires CSP ne doivent pas être partagés.

  • Les clés d'application web de l'espace client partenaire CSP ne doivent pas être partagées avec les fournisseurs de panneau de configuration.

  • Une application de marketplace doit présenter l'identité de l'application, ainsi que les informations du partenaire, au lieu d'utiliser uniquement les informations d'identification du partenaire lorsqu'elle agit sous l'identité d'un partenaire CSP.

  • L’accès à une application de la Place de marché doit être basé sur le principe des privilèges minimum et clairement défini dans les autorisations.

  • L’autorisation d’une application de la Place de marché doit être pivotée vers plusieurs informations d’identification.

  • Les informations d’identification de l’application et les informations d’identification du partenaire doivent être fournies ensemble pour obtenir l’accès.

    Important

    Il est important qu’il n’y ait aucun point de compromis unique.

  • L’accès doit être limité à un public ou à une API spécifique.

  • L’accès doit identifier l’objectif de l’usurpation d’identité.

  • Les autorisations d’accès pour une application de la Place de marché doivent être limitées au temps. Les partenaires CSP doivent pouvoir renouveler ou révoquer l’accès à l’application de la Place de marché.

  • Des processus rapides de contrôle ou de remédiation doivent être mis en place pour gérer les compromissions des identifiants d'application du marché.

  • Tous les comptes d’utilisateur doivent utiliser l’authentification à deux facteurs (2FA).

  • Le modèle d’application doit être convivial pour des dispositions de sécurité supplémentaires, comme l’accès conditionnel à un meilleur modèle de sécurité.

Note

Les fournisseurs indirects CSP et les partenaires directs CSP qui utilisent l'ID d'application + l'authentification utilisateur et qui s'intègrent directement aux API de l'Espace Partenaires doivent suivre les principes ci-dessus pour sécuriser leurs propres applications de marketplace.

Identité et concepts d’application

Applications multilocataires

Une application multilocataire est généralement une application SaaS (Software as a Service). Vous pouvez configurer votre application pour accepter les connexions à partir de n’importe quel locataire Microsoft Entra en configurant le type d’application en tant que multilocataire sur le tableau de bord Azure. Les utilisateurs d’un locataire Microsoft Entra pourront se connecter à votre application après avoir accepté d’utiliser leur compte avec votre application.

Pour en savoir plus sur la création d'une application multilocataire, consultez Connectez n'importe quel utilisateur Microsoft Entra en utilisant le modèle d'application multilocataire.

Pour qu’un utilisateur se connecte à une application dans l’ID Microsoft Entra, l’application doit être représentée dans le locataire de l’utilisateur, ce qui permet à l’organisation d’appliquer des stratégies uniques lorsque les utilisateurs de leur locataire se connectent à l’application. Pour une application à locataire unique, cette inscription est simple : c’est celle qui se produit lorsque vous inscrivez l’application dans le tableau de bord Azure.

Pour une application multilocataires, l’inscription initiale de l’application se fait dans le locataire Microsoft Entra utilisé par le développeur. Lorsqu’un utilisateur d’un autre locataire se connecte à l’application pour la première fois, l’ID Microsoft Entra lui demande de donner son consentement aux autorisations demandées par l’application. S'ils consentent, une représentation de l'application appelée entité de service est créée dans l'instance de l'utilisateur, et le processus de connexion peut continuer. Une délégation est également créée dans le répertoire qui enregistre le consentement de l’utilisateur à l’application.

Note

Les fournisseurs indirects CSP et les partenaires directs CSP qui utilisent l’ID d’application + l’authentification utilisateur et qui s’intègrent directement aux API de l’Espace partenaires devront donner leur consentement à leur application sur la Place de marché via le même framework de consentement.

L’expérience de consentement est affectée par les autorisations demandées par l’application. Microsoft Entra ID prend en charge deux types d’autorisations, d’application uniquement et déléguées.

  • L’autorisation d’application uniquement est accordée directement à l’identité de l’application. Par exemple, vous pouvez accorder une autorisation d’application pour lire la liste des utilisateurs d’un locataire, quel que soit l’utilisateur connecté à l’application.
  • autorisation déléguée accorde à une application la possibilité d’agir en tant qu’utilisateur connecté pour un sous-ensemble des actions que l’utilisateur peut faire. Par exemple, vous pouvez accorder à une application l’autorisation déléguée de lire le calendrier de l’utilisateur connecté.

Certaines autorisations sont accordées par un utilisateur régulier, tandis que d’autres nécessitent le consentement d’un administrateur client. Pour plus d’informations sur l’infrastructure de consentement Microsoft Entra, consultez Présentation des expériences de consentement de l’application Microsoft Entra.

Flux de jetons OAuth pour une application multilocataire

Dans un flux d’autorisation ouverte (OAuth) d’application multilocataire, l’application est représentée en tant qu’application multilocataire dans le locataire du partenaire CPV ou CSP.

Pour accéder aux API Microsoft (API de l’Espace partenaires, API Graph, et ainsi de suite), les partenaires CSP doivent se connecter à l’application et donner leur consentement pour permettre à l’application d’appeler des API pour leur compte.

Remarque

Les fournisseurs indirects CSP et les partenaires directs CSP qui utilisent l’ID d’application et l’authentification utilisateur et qui s’intègrent directement aux API du Centre de partenaires devront donner leur autorisation à leur application de marché pour employer le même cadre d'autorisation.

L’application obtient l’accès aux ressources du partenaire, comme Graph et les API du Centre de Partenaires, via le consentement et les autorisations OAuth.

Créer une application multilocataire

Une application mutualisée doit respecter les exigences suivantes :

  • Il doit s’agir d’une application web avec un ID d’application et une clé secrète.
  • Le mode d’authentification implicite doit être désactivé.

En outre, nous vous recommandons d’adhérer à ces meilleures pratiques :

  • Utilisez un certificat pour la clé secrète.
  • Activez l’accès conditionnel pour appliquer des restrictions de plage d’adresses IP. Cela pourrait nécessiter l'activation d'autres fonctionnalités sur le client Microsoft Entra.
  • Appliquez des stratégies de durée de vie des jetons d’accès pour l’application.

Lors de l’acquisition d’un jeton, l’ID d’application et la clé secrète doivent être présentés. La clé secrète peut être un certificat.

L’application peut être configurée pour appeler plusieurs API, y compris les API Azure Resource Manager. Voici le jeu minimal d’autorisations requis pour les API de l’Espace partenaires :

  • Autorisations déléguées d’ID Microsoft Entra : Accéder au répertoire en tant qu’utilisateur connecté
  • Autorisations déléguées des API de l’Espace partenaires : Accès

Une application mutualisée doit obtenir le consentement des partenaires et utiliser ce consentement et l'autorisation pour effectuer d'autres appels aux API du Partner Center. Le consentement est acquis via un flux de code d’authentification OAuth.

Pour obtenir le consentement, les partenaires CPV ou CSP doivent créer un site web d’intégration qui peut accepter un code d’authentification octroyé à partir de Microsoft Entra ID.

Pour plus d’informations, consultez Plateforme d’identités Microsoft et flux de codes d’autorisation OAuth 2.0.

Voici les étapes d’une application mutualisée pour capturer le consentement du partenaire CSP, ainsi qu’un jeton réutilisable pour passer des appels aux API de l’Espace partenaires.

Procédez comme suit pour acquérir le consentement du partenaire.

  1. Créez une application web d’intégration de partenaire qui peut héberger un lien de consentement sur lequel le partenaire peut cliquer pour accepter le consentement de l’application multilocataire.
  2. Le partenaire CSP clique sur le lien de consentement. Par exemple, https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_ty
  3. La page de connexion Microsoft Entra explique les autorisations qui seront accordées à l’application pour le compte de l’utilisateur. Le partenaire CSP peut décider d’utiliser les informations d’identification de l’agent d’administration ou de l’agent commercial pour se connecter et approuver le consentement. L’application reçoit des autorisations en fonction du rôle d’utilisateur utilisé pour se connecter.
  4. Une fois le consentement accordé, Microsoft Entra ID crée un principal de service de l’application multilocataire du CPV dans le locataire du partenaire CSP.
    • L’application reçoit des subventions OAuth pour agir au nom de l’utilisateur. Ces subventions permettent à l’application mutualisée d’appeler les API de l’Espace partenaires pour le compte du partenaire.
    • À ce stade, la page de connexion Microsoft Entra redirige vers l’application web d’intégration partenaire. L’application web reçoit un code d’autorisation de Microsoft Entra ID. L'application web d'intégration du partenaire doit utiliser le code d'autorisation, ainsi que l'ID d'application et la clé secrète pour appeler l'API Microsoft Entra ID Tokens afin d'obtenir un jeton d'actualisation.
  5. Stockez en toute sécurité le jeton d’actualisation. Le jeton d’actualisation fait partie des informations d’identification du partenaire utilisées pour obtenir l’accès aux API de l’Espace partenaires pour le compte du partenaire. Une fois le jeton d’actualisation acquis, chiffrez-le et stockez-le dans un magasin de clés secrète, tel que le coffre de clés Azure .

Flux d’appel de la demande de jeton

L'application d'un partenaire CSP ou CPVs doit acquérir un jeton d'accès avant d'effectuer des appels aux API de Partner Center. Ces API sont représentées à l’URL de ressource https://api.partnercenter.microsoft.com.

Une application CPV doit identifier le compte partenaire qu'elle doit usurper pour appeler les API du Centre de Partenaires, en fonction du produit ou de la connexion fédérée. L’application récupère le jeton d’actualisation chiffré pour ce locataire partenaire à partir du magasin de clés secrètes. Le jeton d’actualisation doit être déchiffré avant l’utilisation.

Pour les partenaires CSP où il n’y a qu’un seul locataire qui donne son consentement, le compte partenaire fait référence au locataire du partenaire CSP.

Le jeton d’actualisation est un jeton multiaudience. Cela signifie que le jeton d’actualisation peut être utilisé pour obtenir un jeton pour plusieurs audiences en fonction du consentement accordé. Par exemple, si le consentement du partenaire est donné pour les API de l’Espace partenaires et les API Microsoft Graph, le jeton d’actualisation peut être utilisé pour demander un jeton d’accès pour les deux API. Le jeton d’accès octroie l’autorisation « au nom de » et permet à une application de place de marché d’emprunter l’identité du partenaire qui a consenti lors de l’appel de ces API.

Un jeton d’accès peut être acquis pour une audience unique à la fois. Si une application doit accéder à plusieurs API, elle doit demander plusieurs jetons d’accès pour l’audience ciblée. Pour demander un jeton d’accès, l’application doit appeler l’API de jetons de Microsoft Entra ID. Elle peut également utiliser AuthenticationContext.AcquireTokenAsync du Kit de développement logiciel (SDK) Microsoft Entra et transmettre les informations suivantes :

  • URL de ressource, qui est l’URL de point de terminaison de l’application à appeler. Par exemple, l’URL de ressource de l’API de l’Espace partenaires Microsoft est https://api.partnercenter.microsoft.com.
  • Informations d’identification de l’application composées de l’ID d’application et de la clé secrète de l’application web.
  • Jeton d’actualisation

Le jeton d’accès résultant permet à l’application d’effectuer des appels aux API mentionnées dans la ressource. L’application ne peut pas demander un jeton d’accès pour les API qui n’ont pas reçu d’autorisation dans le cadre de la demande de consentement. La valeur de l’attribut UserPrincipalName (UPN) est le nom d’utilisateur Microsoft Entra pour les comptes d’utilisateur.

Autres considérations

Accès conditionnel

Quand il s’agit de gérer vos ressources cloud, un aspect clé de la sécurité cloud est l’identité et l’accès. Dans un monde d’abord mobile et cloud, les utilisateurs peuvent accéder aux ressources de votre organisation à l’aide de différents appareils et applications depuis n’importe où. Se concentrer simplement sur qui peut accéder à une ressource n'est plus suffisant. Pour maîtriser l’équilibre entre la sécurité et la productivité, vous devez également prendre en compte la façon dont une ressource est accessible. En utilisant l’accès conditionnel Microsoft Entra, vous pouvez répondre à cette exigence. Avec l’accès conditionnel, vous pouvez implémenter des décisions de contrôle d’accès automatisées pour accéder à vos applications cloud basées sur des conditions.

Pour plus d’informations, consultez Qu’est-ce que l’accès conditionnel dans l’ID Microsoft Entra ?

Restrictions basées sur une plage d’adresses IP

Vous pouvez restreindre les jetons à émettre à une plage spécifique d’adresses IP uniquement. Cette fonctionnalité permet de limiter la surface d’attaque à un réseau spécifique uniquement.

Authentification multifacteur

L’application de l’authentification multifacteur permet de limiter les situations de compromission des informations d’identification en appliquant la vérification des informations d’identification à deux formulaires ou plus. Cette fonctionnalité permet à Microsoft Entra ID de valider l’identité de l’appelant via des canaux secondaires sécurisés, tels que des appareils mobiles ou des e-mails, avant d’émettre des jetons.

Pour plus d’informations, consultez Fonctionnement : Azure Multi.

Contenu connexe