Dela via

Ramverk för säker programmodell

  • Artikel

Microsoft introducerar ett säkert, skalbart ramverk för att autentisera molnlösningsleverantörspartner (CSP) och leverantörer av kontrollpaneler (CPV) via MFA-arkitekturen (Microsoft Azure Multifactor Authentication). CSP-partner och kontrollpanelsleverantörer kan förlita sig på den nya modellen för att öka säkerheten för Partner Center API-integreringsanrop. Detta hjälper alla parter, inklusive Microsoft, CSP-partner och kontrollpanelsleverantörer, att skydda sin infrastruktur och sina kunddata från säkerhetsrisker.

Viktig

Azure Active Directory (Azure AD) Graph är inaktuell från och med den 30 juni 2023. Framöver gör vi inga ytterligare investeringar i Azure AD Graph. Azure AD Graph-API:er har inget serviceavtal eller underhållsåtagande utöver säkerhetsrelaterade korrigeringar. Investeringar i nya funktioner och funktionaliteter görs endast i Microsoft Graph.

Vi drar tillbaka Azure AD Graph i stegvisa steg så att du har tillräckligt med tid för att migrera dina program till Microsoft Graph-API:er. Vid ett senare tillfälle som vi kommer att meddela kommer vi att blockera skapandet av nya program med hjälp av Azure AD Graph.

Mer information finns i Viktigt: Azure AD Graph Retirement och Powershell Module Deprecation.

Omfattning

Den här artikeln gäller för följande partner:

  • Kontrollpanelens leverantörer (CPV: er) är oberoende programvaruleverantörer som utvecklar appar för användning av CSP-partner för att integrera med PartnerCenter-API:er. En CPV är inte en CSP-partner med direkt åtkomst till partnerinstrumentpanelen eller API:erna. De är de företag som utvecklar program (vanligtvis webbappar) som gör det möjligt för molntjänstleverantörer att sälja sina produkter via en enhetlig marknadsplats.
  • CSP-indirekta leverantörer och CSP-direktpartner som använder app-ID + användarautentisering och direkt integrerar med Partnercenter-API:er.

Obs

För att kvalificera dig som en CPV måste du först ansluta dig till Partner Center som en CPV. Om du är en befintlig CSP-partner som också är en CPV gäller även den här förutsättningen för dig.

Säker programutveckling

När du gör beställningar för Microsoft-produkter på uppdrag av molntjänstleverantörer interagerar marketplace-program från CPV:er med Microsoft-API:er för att lägga beställningar och etablera resurser för kunder.

Några av dessa API:er är:

  • API:er för Partnercenter implementerar handelsåtgärder som att göra beställningar och hantera prenumerationslivscykler.
  • Microsoft Graph-API:er som implementerar identitetshantering för CSP-klienter och CSP-kundens klientorganisationer.
  • API:er för Azure Resource Manager (ARM) som implementerar Azure-distributionsfunktioner.

CSP-partner har behörighet att agera åt sina kunder när de anropar Microsoft-API:er. Med delegerade privilegier kan CSP-partner slutföra inköps-, distributions- och supportscenarier för sina kunder.

Marketplace-program är utformade för att hjälpa CSP-partner att lista sina lösningar för kunder. För att uppnå detta måste Marketplace-program personifiera CSP-partnerbehörigheter för att anropa Microsoft-API:er.

Eftersom CSP-partnerprivilegier är höga och ger åtkomst till alla partnerkunder är det viktigt att förstå hur dessa program måste utformas för att klara säkerhetsexploateringsvektorer. Säkerhetsattacker på dessa känsliga program kan leda till att kunddata komprometteras. Därför måste beviljande av behörigheter och imitation av partnerprivilegier utformas för att följa principen om lägsta behörighet. Följande principer och bästa praxis säkerställer att marketplace-program är hållbara och kan stå emot kompromisser.

Säkerhetsprinciper för efterlikning av identitetsuppgifter

  • Marketplace-program får inte lagra några autentiseringsuppgifter från CSP-partner.

  • CSP-partneranvändarlösenord ska inte delas.

  • Webbappnycklar för CSP-partnerklient får inte delas med Kontrollpanelens leverantörer.

  • En marknadsplatsapplikation måste presentera applikationens identitet tillsammans med partnerinformation i stället för att endast använda partneruppgifter när anrop görs i en CSP-partners namn.

  • Åtkomst till ett Marketplace-program måste baseras på principen om lägsta behörighet och tydligt formulerad i behörigheter.

  • Auktorisering för en marknadsplatsapplikation måste kopplas till flera autentiseringsuppgifter.

  • Programautentiseringsuppgifter och partnerautentiseringsuppgifter måste anges tillsammans för att få åtkomst.

    Viktig

    Det är viktigt att det inte finns någon enskild kompromisspunkt.

  • Åtkomsten måste begränsas till en specifik målgrupp eller ett visst API.

  • Åtkomst måste identifiera syftet med personifieringen.

  • Åtkomstbehörigheter för ett Marketplace-program måste vara tidsbundna. CSP-partner måste kunna förnya eller återkalla åtkomst till Marketplace-programmet.

  • Snabbkontroll eller reparationsprocesser måste finnas på plats för att hantera kompromisser av autentiseringsuppgifter för Marketplace-program.

  • Alla användarkonton ska använda tvåfaktorautentisering (2FA).

  • Programmodellen bör vara användarvänlig för extra säkerhetsbestämmelser, till exempel villkorlig åtkomst till en bättre säkerhetsmodell.

Notera

CSP-indirekta leverantörer och CSP-direktpartner som använder app-ID + användarautentisering och direkt integrerar med Partnercenter-API:er måste följa ovanstående principer för att skydda sina egna marketplace-program.

Programidentitet och begrepp

Program för flera klienter

Ett program med flera klientorganisationer är vanligtvis ett SaaS-program (programvara som en tjänst). Du kan konfigurera din applikation för att acceptera inloggningar från alla Microsoft Entra-klienter genom att konfigurera applikationstypen som flera klientorganisationer i Azure-instrumentpanelen. Användare i alla Microsoft Entra-klienter kommer att kunna logga in på ditt program när de har samtyckt till att använda sitt konto med ditt program.

Mer information om hur du skapar ett program med flera klientorganisationer finns i Logga in alla Microsoft Entra-användare med hjälp av multitenantprogrammönstret.

För att en användare ska kunna logga in på ett program i Microsoft Entra-ID måste programmet representeras i användarens klientorganisation, vilket gör att organisationen kan göra saker som att tillämpa unika principer när användare från deras klientorganisation loggar in på programmet. För ett enda klientprogram är den här registreringen enkel: det är den som sker när du registrerar programmet på Azure-instrumentpanelen.

För ett program med flera klienter finns den första registreringen för programmet i Microsoft Entra-klientorganisationen som används av utvecklaren. När en användare från en annan klientorganisation loggar in på programmet för första gången ber Microsoft Entra-ID dem att samtycka till de behörigheter som programmet begär. Om de ger sitt samtycke skapas en representation av applikationen, kallad en tjänsthuvudman, i användarens klientorganisation, och inloggningsprocessen kan fortsätta. En delegering skapas också i katalogen som registrerar användarens medgivande till programmet.

Anteckning

CSP-indirekta leverantörer och CSP-direktpartner som använder app-ID + användarautentisering och direkt integreras med PartnerCenter-API:er måste ge sitt godkännande till sitt Marketplace-program med samma ramverk för medgivande.

Medgivandeupplevelsen påverkas av de behörigheter som begärs av programmet. Microsoft Entra-ID har stöd för två typer av behörigheter, endast appar och delegerade.

  • App-specifik behörighet beviljas direkt till applikationens identitet. Du kan till exempel ge ett program behörighet att läsa listan över användare i en klientorganisation, oavsett vem som är inloggad i programmet.
  • Delegerad behörighet ger ett program möjlighet att fungera som en inloggad användare för en delmängd av det som användaren kan göra. Du kan till exempel ge ett program delegerad behörighet att läsa den inloggade användarens kalender.

Vissa behörigheter godkänns av en vanlig användare, medan andra kräver en klientadministratörs medgivande. Mer information om Microsoft Entra-ramverket för medgivande finns i Understanding Microsoft Entra application consent experiences.

Tokenflöde för flertenantapplikationer med öppen auktorisering (OAuth)

I ett OAuth-flöde (öppen auktorisering för flera program) representeras programmet som ett program med flera klienter i CPV- eller CSP-partnerns klientorganisation.

För att få åtkomst till Microsoft API:er (Partnercenter-API:er, Graph-API:er och så vidare) måste CSP-partner logga in på programmet och godkänna att programmet anropar API:er för deras räkning.

Notera

CSP-indirekta leverantörer och CSP-direktpartner som använder app-ID och användarautentisering och som integreras direkt med Partnercenter-API:er måste ge sitt marketplace-program samtycke till att använda samma ramverk för medgivande.

Programmet får åtkomst till partnerns resurser, till exempel Graph- och Partnercenter-API:er, genom medgivande och OAuth-bidrag.

Skapa en fleranvändarapplikation

Ett program med flera klientorganisationer måste uppfylla följande krav:

  • Det måste vara en webbapp med ett program-ID och en hemlig nyckel.
  • Implicit autentiseringsläge måste vara inaktiverat.

Dessutom rekommenderar vi att du följer dessa metodtips:

  • Använd ett certifikat för den hemliga nyckeln.
  • Aktivera villkorlig åtkomst för att tillämpa BEGRÄNSNINGAR för IP-intervall. Detta kan kräva att fler funktioner aktiveras i Microsoft Entra-klientorganisationen.
  • Tillämpa livslängdsprinciper för åtkomsttoken för programmet.

När du hämtar en token måste app-ID och hemlig nyckel visas. Den hemliga nyckeln kan vara ett certifikat.

Programmet kan konfigureras för att anropa flera API:er, inklusive Azure Resource Manager-API:er. Följande är den minsta uppsättning behörigheter som krävs för Partnercenter-API:er:

  • Delegerade behörigheter för Microsoft Entra-ID: Komma åt katalogen som inloggad användare
  • Partnercenter-API:er delegerade behörigheter: Åtkomst

Ett program med flera klientorganisationer måste inhämta medgivande från partner och använda detta medgivande och tillstånd för att göra ytterligare anrop till Partner Center API:er. Medgivande förvärvas via ett OAuth-autentiseringskodflöde.

För att få medgivande måste CPV:er eller CSP-partner skapa en onboarding-webbplats som kan godkänna ett autentiseringskodsbidrag från Microsoft Entra-ID.

Mer information finns i Microsofts identitetsplattform och OAuth 2.0-auktoriseringskodflödet.

Här följer stegen för ett program med flera klientorganisationer för att samla in CSP-partnermedgivande tillsammans med en återanvändbar token för att göra anrop till Partnercenter-API:er.

Använd följande steg för att skaffa partnermedgivande.

  1. Skapa en webbapplikation för partner-onboarding som kan tillhandahålla en länk för partnern att klicka på för att godkänna användarvillkor för applikationen med flera hyresgäster.
  2. CSP-partnern klickar på medgivandelänken. Till exempel https://login.microsoftonline.com/common/oauth2/authorize?&client_id=<marketplaceappid>&response_ty
  3. Inloggningssidan för Microsoft Entra förklarar de behörigheter som kommer att beviljas programmet för användarens räkning. CSP-partnern kan välja att använda autentiseringsuppgifterna för administratörsagenten eller försäljningsagenten för att logga in och godkänna medgivandet. Programmet får behörigheter baserat på den användarroll som används för att logga in.
  4. När medgivandet har beviljats skapar Microsoft Entra ID ett tjänstehuvudnamn för CPV:ns flerklientprogram i CSP-partnerns klientorganisation.
    • Applikationen får OAuth-rättigheter för att agera på användarens vägnar. Dessa bidrag gör det möjligt för programmet med flera klientorganisationer att anropa Partnercenter-API:er för partnerns räkning.
    • Nu omdirigeras Microsoft Entra-inloggningssidan till webbappen för partnerregistrering. Webbprogrammet tar emot en auktoriseringskod från Microsoft Entra-ID. Partner onboarding-webbprogrammet måste använda auktoriseringskoden tillsammans med applikations-ID och hemlig nyckel för att anropa Microsoft Entra ID Tokens API för att erhålla en refresh-token.
  5. Lagra uppdateringstoken på ett säkert sätt. Uppdateringstoken är en del av de partnerautentiseringsuppgifter som används för att få åtkomst till Partnercenter-API:er för partnerns räkning. När uppdateringstoken har hämtats krypterar du den och lagrar den i ett hemligt nyckelarkiv, till exempel Azure-nyckelvalvet.

Samtalsflöde för tokenbegäran

En CPV- eller CSP-partners applikation måste hämta en åtkomsttoken innan den anropar API:er för Partner Center. Dessa API:er visas på resurs-URL:en https://api.partnercenter.microsoft.com.

Ett CPV-program bör identifiera vilket partnerkonto det måste personifiera för att anropa Partnercenter-API:er baserat på antingen produkt- eller federerad inloggning. Programmet hämtar den krypterade uppdaterings-token för partnerklienten från nyckellagret. Uppdateringstoken måste dekrypteras innan den används.

För CSP-partner där det bara finns en klientorganisation som ger sitt medgivande refererar partnerkontot till CSP-partnerns klientorganisation.

Uppdateringstoken är en token för flera målgrupper. Det innebär att uppdateringstoken kan användas för att hämta en token för flera målgrupper baserat på det medgivande som beviljas. Om partnermedgivande till exempel ges för Partnercenter-API:er och Microsoft Graph-API:er kan uppdateringstoken användas för att begära en åtkomsttoken för båda API:erna. Åtkomsttokenen har beviljandet "på uppdrag av" och gör att en marknadsplatsapplikation kan agera på uppdrag av den partner som samtyckt när de anropar dessa API:er.

En åtkomsttoken kan hämtas för en enskild målgrupp i taget. Om ett program behöver åtkomst till flera API:er måste det begära flera åtkomsttoken för målgruppen. För att begära en åtkomsttoken måste programmet anropa Microsoft Entra ID Tokens API. Alternativt kan den också använda Microsoft Entra SDK:s AuthenticationContext.AcquireTokenAsync och skicka följande information:

  • Resurs-URL, som är slutpunkts-URL:en för programmet som ska anropas. Resurs-URL:en för Microsoft Partner Center-API:et är till exempel https://api.partnercenter.microsoft.com.
  • Programautentiseringsuppgifter som består av webbappens program-ID och hemliga nyckel.
  • Uppfräschnings-token

Den resulterande åtkomsttoken gör att programmet kan göra anrop till API:er som nämns i resursen. Programmet kan inte begära en åtkomsttoken för API:er som inte har beviljats behörighet som en del av begäran om medgivande. Attributet UserPrincipalName (UPN) är Microsoft Entra-användarnamnet för användarkontona.

Fler överväganden

Villkorlig åtkomst

När det gäller att hantera dina molnresurser är en viktig aspekt av molnsäkerhet identitet och åtkomst. I en mobil-första, moln-första värld kan användare komma åt din organisations resurser med hjälp av olika enheter och appar var som helst. Det räcker inte längre att bara fokusera på vem som kan komma åt en resurs. För att hantera balansen mellan säkerhet och produktivitet måste du också överväga hur en resurs används. Genom att använda villkorsstyrd åtkomst i Microsoft Entra kan du uppfylla det här kravet. Med villkorlig åtkomst kan du implementera automatiserade åtkomstkontrollbeslut för åtkomst till dina molnappar som baseras på villkor.

Mer information finns i Vad är villkorlig åtkomst i Microsoft Entra-ID?

IP-intervallbaserade begränsningar

Du kan begränsa att token endast utfärdas till ett specifikt intervall med IP-adresser. Den här funktionen hjälper till att begränsa attackytan till ett specifikt nätverk.

Multifaktorautentisering

Genom att framtvinga multifaktorautentisering kan du begränsa autentiseringsuppgifternas komprometterande situationer genom att framtvinga verifiering av autentiseringsuppgifter till två eller flera formulär. Med den här funktionen kan Microsoft Entra-ID verifiera uppringarens identitet via säkra sekundära kanaler, till exempel mobil eller e-post, innan token utfärdas.

Mer information finns i Så här fungerar det: Azure Multi.

Relaterat innehåll