Share via

Framework voor beveiligd toepassingsmodel

  • Artikel

Microsoft introduceert een veilig, schaalbaar framework voor het verifiëren van CSP-partners (Cloud Solution Provider) en Configuratiescherm Leveranciers (CPV) via de MFA-architectuur (MultiFactor Authentication) van Microsoft Azure. CSP-partners en Configuratiescherm Leveranciers kunnen vertrouwen op het nieuwe model om de beveiliging voor API-aanroepen van partnercentrum te verhogen. Dit helpt alle partijen, waaronder Microsoft, CSP-partners en Configuratiescherm Leveranciers, om hun infrastructuur en klantgegevens te beschermen tegen beveiligingsrisico's.

Belangrijk

Azure Active Directory (Azure AD) Graph is vanaf 30 juni 2023 afgeschaft. In de toekomst doen we geen verdere investeringen in Azure AD Graph. Azure AD Graph-API's hebben geen SLA of onderhoudsverplichting buiten beveiligingsgerelateerde oplossingen. Investeringen in nieuwe functies en functionaliteiten worden alleen gedaan in Microsoft Graph.

Azure AD Graph wordt in incrementele stappen buiten gebruik gesteld, zodat u voldoende tijd hebt om uw toepassingen te migreren naar Microsoft Graph-API's. Op een later tijdstip dat we zullen aankondigen, blokkeren we het maken van nieuwe toepassingen met behulp van Azure AD Graph.

Zie Belangrijk: Buitengebruikstelling van Azure AD Graph en Afschaffing van Powershell-module voor meer informatie.

Bereik

Dit artikel is van toepassing op de volgende partners:

  • Configuratiescherm Leveranciers (CPV's) zijn onafhankelijke softwareleveranciers die apps ontwikkelen voor gebruik door CSP-partners om te integreren met Partner Center-API's. Een CPV is geen CSP-partner met directe toegang tot het partnerdashboard of API's. Dit zijn de bedrijven die toepassingen (meestal web-apps) ontwikkelen waarmee CSP's hun producten kunnen verkopen via een geïntegreerde marketplace.
  • Indirecte CSP-providers en CSP-directe partners die app-id en gebruikersverificatie gebruiken en rechtstreeks integreren met Partner Center-API's.

Notitie

Als u als CPV wilt kwalificeren, moet u eerst als CPV onboarden naar partnercentrum. Als u een bestaande CSP-partner bent die ook een CPV is, is deze vereiste ook van toepassing op u.

Ontwikkeling van beveiligde toepassingen

Bij het plaatsen van orders voor Microsoft-producten namens CSP's communiceren Marketplace-toepassingen van CPV's met Microsoft-API's om orders te plaatsen en resources in te richten voor klanten.

Enkele van deze API's zijn:

  • Partner center-API's die commercebewerkingen implementeren, zoals het plaatsen van orders en het beheren van de levenscyclus van abonnementen.
  • Microsoft Graph-API's die identiteitsbeheer implementeren voor CSP-tenants en tenants van CSP-klanten.
  • ARM-API's (Azure Resource Manager) implementeren functionaliteit voor Azure-implementatie.

CSP-partners zijn gemachtigd met gedelegeerde bevoegdheden om namens hun klanten te handelen bij het aanroepen van Microsoft-API's. Met gedelegeerde bevoegdheden kunnen CSP-partners aankoop-, implementatie- en ondersteuningsscenario's voor hun klanten voltooien.

Marketplace-toepassingen zijn ontworpen om CSP-partners te helpen hun oplossingen voor klanten weer te geven. Om dit te bereiken, moeten Marketplace-toepassingen CSP-partnerbevoegdheden imiteren om Microsoft-API's aan te roepen.

Omdat CSP-partnerbevoegdheden hoog zijn en toegang bieden tot alle klanten van de partner, is het belangrijk om te begrijpen hoe deze toepassingen moeten worden ontworpen om beveiligingsuitbuitingsvectoren te weerstaan. Beveiligingsaanvallen op deze gevoelige toepassingen kunnen leiden tot inbreuk op klantgegevens. Daarom moeten machtigingen en imitatie van partnerbevoegdheden worden ontworpen om het principe van minimale bevoegdheden te volgen. De volgende principes en best practices zorgen ervoor dat marketplace-toepassingen duurzaam zijn en bestand zijn tegen compromissen.

Beveiligingsprincipes voor imitatie van referenties

  • Marketplace-toepassingen mogen geen referenties van CSP-partners opslaan.

  • Gebruikerswachtwoorden van CSP-partners mogen niet worden gedeeld.

  • Web-app-sleutels van de CSP-partnertenant mogen niet worden gedeeld met Configuratiescherm Leveranciers.

  • Een Marketplace-toepassing moet de toepassingsidentiteit samen met partnergegevens presenteren in plaats van alleen partnerreferenties te gebruiken bij het aanroepen van een CSP-partneridentiteit.

  • Toegang tot een Marketplace-toepassing moet zijn gebaseerd op het principe van minimale bevoegdheden en duidelijk geformuleerd in machtigingen.

  • Autorisatie voor een Marketplace-toepassing moet worden gedraaid op meerdere referenties.

  • Toepassingsreferenties en partnerreferenties moeten samen worden opgegeven om toegang te krijgen.

    Belangrijk

    Het is belangrijk dat er geen enkel compromispunt bestaat.

  • Toegang moet worden beperkt tot een specifieke doelgroep of API.

  • Access moet het doel van de imitatie identificeren.

  • Toegangsmachtigingen voor een Marketplace-toepassing moeten tijdsgebonden zijn. CSP-partners moeten de toegang tot de Marketplace-toepassing kunnen vernieuwen of intrekken.

  • Snelle controle- of herstelprocessen moeten aanwezig zijn om inbreuk te kunnen maken op marketplace-toepassingsreferenties.

  • Alle gebruikersaccounts moeten gebruikmaken van tweeledige verificatie (2FA).

  • Het toepassingsmodel moet vriendelijk zijn voor extra beveiligingsvoorzieningen, zoals voorwaardelijke toegang tot een beter beveiligingsmodel.

Notitie

Indirecte CSP-providers en CSP-directe partners die app-id en gebruikersverificatie gebruiken en rechtstreeks integreren met Partner Center-API's, moeten voldoen aan de bovenstaande principes om hun eigen Marketplace-toepassingen te beveiligen.

Toepassingsidentiteit en -concepten

Toepassingen met meerdere tenants

Een multitenant-toepassing is over het algemeen een SaaS-toepassing (Software as a Service). U kunt uw toepassing zo configureren dat aanmeldingen van microsoft Entra-tenants worden geaccepteerd door het toepassingstype te configureren als multitenant op het Azure-dashboard. Gebruikers in elke Microsoft Entra-tenant kunnen zich aanmelden bij uw toepassing nadat ze toestemming hebben gegeven om hun account met uw toepassing te gebruiken.

Zie Sign in any Microsoft Entra user using the multitenant application pattern voor meer informatie over het maken van een multitenant-toepassing.

Als een gebruiker zich kan aanmelden bij een toepassing in Microsoft Entra ID, moet de toepassing worden weergegeven in de tenant van de gebruiker, zodat de organisatie bijvoorbeeld uniek beleid kan toepassen wanneer gebruikers van hun tenant zich aanmelden bij de toepassing. Voor één tenanttoepassing is deze registratie eenvoudig: dit is de toepassing die plaatsvindt wanneer u de toepassing registreert in het Azure-dashboard.

Voor een multitenant-toepassing bevindt de eerste registratie voor de toepassing zich in de Microsoft Entra-tenant die door de ontwikkelaar wordt gebruikt. Wanneer een gebruiker van een andere tenant zich voor het eerst aanmeldt bij de toepassing, vraagt Microsoft Entra-id hen om toestemming te geven voor de machtigingen die door de toepassing zijn aangevraagd. Als ze toestemming geven, wordt een weergave van de toepassing met de naam een service-principal gemaakt in de tenant van de gebruiker en kan het aanmeldingsproces worden voortgezet. Er wordt ook een delegatie gemaakt in de map waarin de toestemming van de gebruiker voor de toepassing wordt vastgelegd.

Notitie

Indirecte CSP-providers en CSP-directe partners die gebruikmaken van app-id en gebruikersverificatie en rechtstreeks integreren met Partner Center-API's, moeten toestemming geven voor hun Marketplace-toepassing met hetzelfde toestemmingsframework.

De toestemmingservaring wordt beïnvloed door de machtigingen die door de toepassing zijn aangevraagd. Microsoft Entra ID ondersteunt twee soorten machtigingen, alleen voor apps en gedelegeerden.

  • Alleen-app-machtigingen worden rechtstreeks verleend aan de identiteit van de toepassing. U kunt bijvoorbeeld een toepassing machtigen om de lijst met gebruikers in een tenant te lezen, ongeacht wie is aangemeld bij de toepassing.
  • Gedelegeerde machtigingen verlenen een toepassing de mogelijkheid om als aangemelde gebruiker te fungeren voor een subset van de dingen die de gebruiker kan doen. U kunt bijvoorbeeld een toepassing de gedelegeerde machtiging verlenen om de agenda van de aangemelde gebruiker te lezen.

Sommige machtigingen worden door een gewone gebruiker toegestaan, terwijl anderen toestemming van een tenantbeheerder vereisen. Zie Microsoft Entra-toestemmingservaringen voor microsoft Entra-toepassingen voor meer informatie over het Microsoft Entra-toestemmingsframework.

OAuth-tokenstroom (Open Authorization) voor multitenant-toepassingen

In een OAuth-stroom (Open Authorization) voor meerdere tenants wordt de toepassing weergegeven als een multitenant-toepassing in de tenant van de CPV- of CSP-partner.

Om toegang te krijgen tot Microsoft-API's (Partnercentrum-API's, Graph-API's, enzovoort), moeten CSP-partners zich aanmelden bij de toepassing en toestemming geven dat de toepassing NAMENS hen API's kan aanroepen.

Notitie

Indirecte CSP-providers en directe CSP-partners die gebruikmaken van app-id en gebruikersverificatie en rechtstreeks integreren met Partner Center-API's, moeten toestemming geven voor hun Marketplace-toepassing om hetzelfde toestemmingsframework te gebruiken.

De toepassing krijgt toegang tot de resources van de partner, zoals Graph- en Partner Center-API's, via toestemming en OAuth-subsidies.

Een multitenant-toepassing maken

Een toepassing met meerdere tenants moet voldoen aan de volgende vereisten:

  • Het moet een web-app zijn met een toepassings-id en geheime sleutel.
  • De modus voor impliciete verificatie moet zijn uitgeschakeld.

Daarnaast raden we u aan deze aanbevolen procedures te volgen:

  • Gebruik een certificaat voor de geheime sleutel.
  • Voorwaardelijke toegang inschakelen om beperkingen voor IP-bereiken toe te passen. Hiervoor is mogelijk meer functionaliteit vereist voor de Microsoft Entra-tenant.
  • Beleid voor levensduur van toegangstokens toepassen voor de toepassing.

Bij het verkrijgen van een token moet de app-id en geheime sleutel worden weergegeven. De geheime sleutel kan een certificaat zijn.

De toepassing kan worden geconfigureerd om meerdere API's aan te roepen, waaronder Azure Resource Manager-API's. Hieronder ziet u de minimale set machtigingen die zijn vereist voor Partnercentrum-API's:

  • Gedelegeerde machtigingen voor Microsoft Entra-id: Toegang tot de map als aangemelde gebruiker
  • Gedelegeerde machtigingen voor Partnercentrum-API's: Toegang

Een multitenant-toepassing moet toestemming verkrijgen van partners en de toestemming gebruiken en verlenen om verdere aanroepen naar Partnercentrum-API's uit te voeren. Toestemming wordt verkregen via een OAuth-verificatiecodestroom.

Als u toestemming wilt verkrijgen, moeten CPV's of CSP-partners een onboardingwebsite bouwen die een verificatiecodetoekenning van Microsoft Entra-id kan accepteren.

Zie Toegang verlenen tot Azure Active - en Directory-webtoepassingen met behulp van de OAuth 2.0-stroom voor het verlenen van code voor meer informatie.

Hier volgen de stappen voor een multitenant-toepassing voor het vastleggen van CSP-partnertoestemming, samen met een herbruikbaar token voor het maken van aanroepen naar Partnercentrum-API's.

Gebruik de volgende stappen om toestemming van de partner te verkrijgen.

  1. Bouw een webtoepassing voor onboarding van partners die een toestemmingskoppeling voor de partner kan hosten om door te klikken om toestemming voor de multitenant-toepassing te accepteren.
  2. De CSP-partner klikt op de toestemmingskoppeling. Bijvoorbeeld https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_ty
  3. Op de aanmeldingspagina van Microsoft Entra worden de machtigingen uitgelegd die namens de gebruiker aan de toepassing worden verleend. De CSP-partner kan besluiten om Beheer agent- of verkoopagentreferenties te gebruiken om u aan te melden en de toestemming goed te keuren. De toepassing krijgt machtigingen op basis van de gebruikersrol die wordt gebruikt om u aan te melden.
  4. Zodra toestemming is verleend, maakt Microsoft Entra ID een service-principal van de multitenant-toepassing van de CPV in de tenant van de CSP-partner. De toepassing verleent OAuth toestemming om namens de gebruiker actie te ondernemen. Met deze subsidies kan de multitenant-toepassing partnercentrum-API's aanroepen namens de partner. Op dit moment wordt de aanmeldingspagina van Microsoft Entra omgeleid naar de onboarding-webtoepassing van de partner. De webtoepassing ontvangt een autorisatiecode van Microsoft Entra ID. De onboarding-webtoepassing van de partner moet de autorisatiecode gebruiken, samen met de toepassings-id en de geheime sleutel om de Api voor Microsoft Entra ID Tokens aan te roepen om een vernieuwingstoken te verkrijgen.
  5. Sla het vernieuwingstoken veilig op. Het vernieuwingstoken maakt deel uit van de partnerreferenties die worden gebruikt voor het verkrijgen van toegang tot partnercentrum-API's namens de partner. Zodra het vernieuwingstoken is verkregen, versleutelt u het en slaat u het op in een geheim sleutelarchief, zoals de Azure-sleutelkluis.

Oproepstroom tokenaanvraag

Een CPV's of de toepassing van een CSP-partner moet een toegangstoken verkrijgen voordat u aanroept naar Partnercentrum-API's. Deze API's worden weergegeven op de resource-URL https://api.partnercenter.microsoft.com.

Een CPV-toepassing moet identificeren welk partneraccount het moet imiteren om Partnercentrum-API's aan te roepen op basis van product- of federatieve aanmelding. De toepassing haalt het versleutelde vernieuwingstoken voor die partnertenant op uit het geheime sleutelarchief. Het vernieuwingstoken moet worden ontsleuteld voordat u het gebruikt.

Voor CSP-partners met slechts één tenant die toestemming geeft, verwijst het partneraccount naar de tenant van de CSP-partner.

Het vernieuwingstoken is een token voor meerdere doelgroepen. Dit betekent dat het vernieuwingstoken kan worden gebruikt om een token te verkrijgen voor meerdere doelgroepen op basis van de toestemming die wordt verleend. Als er bijvoorbeeld partnertoestemming wordt gegeven voor Partnercentrum-API's en Microsoft Graph-API's, kan het vernieuwingstoken worden gebruikt om een toegangstoken aan te vragen voor beide API's. Het toegangstoken heeft de toekenning 'namens' en stelt een Marketplace-toepassing in staat om de partner te imiteren die toestemming heeft gegeven tijdens het aanroepen van deze API's.

Een toegangstoken kan worden verkregen voor één doelgroep tegelijk. Als een toepassing toegang moet hebben tot meerdere API's, moet deze meerdere toegangstokens aanvragen voor de doelgroep. Als u een toegangstoken wilt aanvragen, moet de toepassing de API voor Microsoft Entra-id-tokens aanroepen. U kunt ook de VerificatieContext.AcquireTokenAsync van de Microsoft Entra SDK gebruiken en de volgende informatie doorgeven:

  • Resource-URL, de eindpunt-URL voor de toepassing die moet worden aangeroepen. De resource-URL voor de Microsoft Partner Center-API is https://api.partnercenter.microsoft.combijvoorbeeld .
  • Toepassingsreferenties die bestaan uit de toepassings-id en geheime sleutel van de web-app.
  • Het vernieuwingstoken

Met het resulterende toegangstoken kan de toepassing api's aanroepen die in de resource worden vermeld. De toepassing kan geen toegangstoken aanvragen voor API's die niet zijn verleend als onderdeel van de toestemmingsaanvraag. De kenmerkwaarde UserPrincipalName (UPN) is de Gebruikersnaam van Microsoft Entra voor de gebruikersaccounts.

Meer overwegingen

Voorwaardelijke toegang

Als het gaat om het beheren van uw cloudresources, is identiteit en toegang een belangrijk aspect van cloudbeveiliging. In een wereld van mobiel en cloud-first hebben gebruikers overal toegang tot de resources van uw organisatie met behulp van verschillende apparaten en apps. Het is niet meer voldoende om te focussen op wie toegang heeft tot een resource. Als u de balans tussen beveiliging en productiviteit wilt beheersen, moet u ook overwegen hoe een resource wordt geopend. Met behulp van voorwaardelijke toegang van Microsoft Entra kunt u aan deze vereiste voldoen. Met voorwaardelijke toegang kunt u geautomatiseerde beslissingen voor toegangsbeheer implementeren voor het openen van uw cloud-apps op basis van voorwaarden.

Zie Wat is voorwaardelijke toegang in Microsoft Entra ID?

Beperkingen op basis van IP-bereik

U kunt tokens beperken tot alleen een specifiek bereik van IP-adressen. Deze functie helpt het oppervlak van aanvallen alleen te beperken tot een specifiek netwerk.

Meervoudige verificatie

Als u meervoudige verificatie afdwingt, kunt u situaties met betrekking tot inbreuk op referenties beperken door verificatie van referenties af te dwingen op twee of meer formulieren. Met deze functie kan Microsoft Entra ID de identiteit van de beller valideren via beveiligde secundaire kanalen, zoals mobiel of e-mail, voordat tokens worden uitgegeven.

Zie Hoe het werkt: Azure Multi voor meer informatie.

Volgende stappen