Delen via

Framework voor beveiligd toepassingsmodel

  • Artikel

Microsoft introduceert een veilig, schaalbaar framework voor het verifiëren van CSP-partners (Cloud Solution Provider) en CPV (Control Panel Vendor) via de MFA-architectuur (MultiFactor Authentication) van Microsoft Azure. CSP-partners en leveranciers van bedieningspanelen kunnen vertrouwen op het nieuwe model om de beveiliging te verhogen voor API-integratieoproepen van Partner Centrum. Dit helpt alle partijen, waaronder Microsoft, CSP-partners en Leveranciers van configuratiescherm, 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 voor meer informatie Belangrijk: Buitengebruikstelling van Azure AD Graph en Afschaffing van PowerShell-module.

Draagwijdte

Dit artikel is van toepassing op de volgende partners:

  • Configuratieschermleveranciers (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 zich als CPV wilt kwalificeren, moet u zich eerst als CPV aanmelden bij het 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 leveranciers van het Configuratiescherm.

  • Een marktplaatsapplicatie moet de applicatie-identiteit samen met partnerinformatie tonen 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-applicatie moet gebaseerd zijn 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 beschikbaar zijn om inbreuken op gegevens van markttoepassingen aan te pakken.

  • 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

Multitenant-toepassingen

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.

Voor meer informatie over het maken van een multitenant-toepassing, zie Aanmelden van een Microsoft Entra-gebruiker met behulp van het multitenant-toepassingspatroon.

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 een single tenant-toepassing is deze registratie eenvoudig: het is degene 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 representatie van de toepassing, genaamd een service principal, gemaakt in de tenant van de gebruiker en kan het aanmeldingsproces worden voortgezet. Er wordt ook een delegatie in de directory gemaakt 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.

  • Toestemming voor alleen-app wordt 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 machtiging verleent een toepassing de mogelijkheid om te fungeren als een aangemelde gebruiker 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 Understanding Microsoft Entra application consent experiencesvoor meer informatie over 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: de directory openen als aangemelde gebruiker
  • Gedelegeerde machtigingen voor Partnercentrum-API's: Access-

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 Microsoft Identity Platform en OAuth 2.0-autorisatiecodestroomvoor 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 onboarding-webapplicatie voor partners die een toestemmingskoppeling kan hosten, zodat de partner kan doorklikken en toestemming voor de multitenant-toepassing kan accepteren.
  2. De CSP-partner klikt op de link voor toestemming. 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 beheerdersagent- of verkoopagentreferenties te gebruiken om zich 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-applicatie 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 Microsoft Entra ID Tokens-API aan te roepen en een vernieuwings-token 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.

Oproepverloop tokenaanvraag

Een CPV- of CSP-partner toepassing moet een toegangstoken verkrijgen voordat er oproepen naar de Partner Center API's worden gedaan. 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 "machtiging namens" en stelt een marktplaatstoepassing in staat om de partner die toestemming heeft gegeven, te vertegenwoordigen bij 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 Microsoft Entra-id tokens-APIaanroepen. U kunt ook de AuthenticationContext.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 bijvoorbeeld https://api.partnercenter.microsoft.com.
  • 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 toegang tot uw cloud-apps die zijn gebaseerd op voorwaarden.

Voor meer informatie, 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 Multivoor meer informatie.

Verwante inhoud