Share via

Framework du modèle d’application sécurisé

  • 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 solutions Cloud Panneau de configuration peuvent s’appuyer sur le nouveau modèle pour élever la sécurité des appels d’intégration d’API de l’Espace partenaires. Cela permet à toutes les parties, y compris Microsoft, les partenaires CSP et les fournisseurs de 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é. Nous limiterons les investissements dans de nouvelles fonctions et fonctionnalités à 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 : Suppression du module Azure AD Graph et Dépréciation du module PowerShell.

Étendue

Cet article s’applique aux partenaires suivants :

  • Panneau de configuration Vendors (CPVs) 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.
  • Partenaires indirects et directs du programme Fournisseur de solutions Cloud qui utilisent un ID d’application et une authentification utilisateur et s’intègrent directement aux API de l’Espace partenaires.

Remarque

Pour être éligible en tant que CPV, vous devez d’abord intégrer 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 fournisseurs de services cloud, les applications de la Place de marché des processeurs 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 l’identité des privilèges de partenaire CSP pour appeler des 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é. Des attaques de sécurité visant ces applications sensibles peuvent entraîner la compromission des données client. Par conséquent, les octrois d’autorisations et l’emprunt d’identité de privilège partenaire doivent être conçus pour suivre 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’emprunt d’identité des informations d’identification

  • 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 du locataire partenaire CSP ne doivent pas être partagées avec Panneau de configuration Fournisseurs.

  • Une application de la Place de marché doit présenter l’identité de l’application avec les informations de partenaire, par opposition à l’utilisation des informations d’identification du partenaire uniquement lors de l’emprunt d’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’emprunt 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é.

  • Les processus de contrôle rapide ou de correction doivent être en place pour gérer les compromissions des informations d’identification d’application de la Place de 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é.

Remarque

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 place de marché.

Identité et concepts d’application

Applications mutualisées

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 comme multilocataire sur le tableau de bord Azure. Les utilisateurs de n’importe quel client Microsoft Entra pourront se connecter à votre application après votre consentement afin d’utiliser leur compte avec votre application.

Pour en savoir plus sur la création d’une application mutualisée, consultez Se connecter à un utilisateur Microsoft Entra à l’aide du modèle d’application mutualisé.

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 mutualisée, l’inscription initiale de l’application réside dans le locataire Microsoft Entra utilisé par le développeur. Lorsqu’un utilisateur d’un autre client se connecte à l’application pour la première fois, Microsoft Entra ID l’invite à donner son consentement pour les autorisations demandées par l’application. S’ils consentent, une représentation de l’application appelée principal de service est créée dans le locataire 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.

Remarque

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 de la Place de marché à l’aide du 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.
  • L’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 d’autorisation ouverte d’application multilocataire (OAuth)

Dans un flux d’autorisation ouverte d’application multilocataire (OAuth), l’application est représentée en tant qu’application mutualisée 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 de l’Espace partenaires devront donner leur consentement à leur application de place de marché pour utiliser le même framework de consentement.

L’application obtient l’accès aux ressources du partenaire, telles que Graph et les API de l’Espace partenaires, via le consentement et les subventions OAuth.

Créer une application mutualisée

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 peut nécessiter d’autres fonctionnalités pour être activées sur le locataire 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 acquérir le consentement des partenaires et utiliser le consentement et accorder pour effectuer d’autres appels aux API de l’Espace partenaires. Le consentement est acquis via un flux de code d’authentification OAuth.

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

Pour plus d’informations, consultez Autoriser l’accès aux applications web Azure Active et Directory à l’aide du flux d’octroi de code 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 pour que le partenaire clique pour accepter le consentement de l’application mutualisée.
  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 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é, l’ID Microsoft Entra 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 partenaire doit utiliser le code d’autorisation, ainsi que l’ID d’application et la clé secrète pour appeler l’API Jetons d’ID Microsoft Entra pour 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 demande de jeton

L’application d’un partenaire CSP ou des PROCESSEURs doit acquérir un jeton d’accès avant d’effectuer des appels aux API de l’Espace partenaires. Ces API sont représentées à l’URL https://api.partnercenter.microsoft.comde la ressource.

Une application CPV doit identifier le compte partenaire qu’il doit emprunter pour appeler les API de l’Espace 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 multi-audience. 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 dispose de l’octroi « au nom de » et permet à une application de la 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 Jetons d’ID Microsoft Entra. Vous pouvez également utiliser AuthenticationContext.AcquireTokenAsync du Kit de développement logiciel (SDK) AuthenticationContext.AcquireTokenAsync 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ù. Il suffit de se concentrer sur les personnes qui peuvent accéder à une ressource n’est plus suffisante. 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 qui sont 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.

Étapes suivantes