Multitenancy med dedikerede tjenesteprincipaler

Til nye multitenancy-løsninger skal du bruge dedikerede Microsoft Entra tjenesteprincipaler til kundeidentiteter. Hvis kravene til hosting og tillid passer til din løsning, kan du bruge administrerede identitets- og organisationsidentitetslegitimationsoplysninger til at godkende disse kundeprogrammer uden at gemme deres klienthemmeligheder eller private nøglecertifikater.

Tjenesteprincipalprofiler forbliver en gyldig, valgfri løsning til nye og eksisterende Power BI Embedded programmer, hvis krav passer til deres fordele og begrænsninger. De udfases ikke. Hvis din eksisterende profilbaserede løsning opfylder dine krav, kan du fortsætte med at bruge den.

Denne artikel hjælper dig med at vælge en identitetsmodel og finde den relevante konfigurationsvejledning. En kunde er en logisk kunde- eller godkendelsesgrænse i dit program, ikke nødvendigvis en separat Microsoft Entra lejer.

Anbefalet model: Dedikerede kundeserviceprincipaler

Opret en programregistrerings- og tjenesteprincipal for hver kundegodkendelsesgrænse. Tildel kun denne hovedadgang til kundens tilladte arbejdsområder og ressourcer. Dedikerede hovedprincipaler leverer uafhængige Microsoft Entra logonposter, mappeadministration og adgang til tjenester, der understøtter disse identiteter.

Hvis du er berettiget og licenseret, kan du anvende arbejdsbelastningsidentitet Betinget adgang direkte på kundeserviceprincipaler. Oprettelse af en hovedkonto giver ikke automatisk adgang eller aktiverer ikke-understøttet API-handling. Kontrollér kravene til identitetssupport og -tilladelser for hver destinationstjeneste.

Vælg en autentificeringsmetode

Det anbefalede godkendelsesmønster bruger en brugertildelt administreret identitet på programmets understøttede Azure beregningsressource som en antagelseskilde. Et organisationsnetværksidentitetslegitimationsoplysninger for hver kundeprogramregistrering har tillid til den administrerede identitet. På kørselstidspunktet udveksler programmet den administrerede identitetsantagelse for et ressourceadgangstoken, der repræsenterer den valgte kundeserviceprincipal.

Dette mønster fjerner behovet for at gemme og rotere kundeprogramhemmeligheder eller -certifikater. Det udelukker ikke programregistrering, administration af tillid, ressourcetilladelser eller administration af kundeidentitetslivscyklus.

Den administrerede identitet og de programregistreringer, der har tillid til den, skal tilhøre den samme Microsoft Entra kataloglejer. Destinationsressourcer i en anden lejer har yderligere krav til programkonfiguration, samtykke og tilladelse. Udveksling af tokens på tværs af skyen understøttes ikke. Se mønsteret og kravene til tillid.

Hvis du ikke vil bruge administreret identitet og sammenslutning, skal du godkende de dedikerede kundeprogrammer direkte med certifikater eller andre understøttede programlegitimationsoplysninger. Beskyt gemte legitimationsoplysninger, og automatiser rotation. Se alternativet til direkte godkendelse.

Plangodkendelse og skalering

Hverken dedikerede principaler eller profiler opretter automatisk kryptografisk kundeisolering. En administreret identitet for delt kørsel kan godkendes som alle de kundeprogrammer, der har tillid til det. På samme måde kan en kørsel med adgang til flere gemte kundelegitimationsoplysninger bruge disse identiteter. Beskyt kørselstidspunktet, og løs kundens identitet og tilladte ressourcer via serverkonfiguration, der er tillid til.

Tilladelser til arbejdsområder og ressourcer gennemtvinger adgang. Konfigurer de påkrævede lejerindstillinger, og tildel hver kundeprincipal de mindst privilegerede understøttede ressourceroller. I forbindelse med gruppebaserede indstillinger skal du eksplicit inkludere alle relevante sikkerhedskonti i en tilladt sikkerhedsgruppe.

Dedikerede identiteter forbruger Microsoft Entra katalogobjekter. Sammenlign dit kundeantal med katalogkvoter, klargøringstilladelser og gennemløb og hver tjenestes ressourcegrænser. Automatiser onboarding, overvågning og offboarding. Vælg ikke en identitetsmodel udelukkende fra antallet af programbrugere.

Alternativ model: Tjenesteprincipalprofiler

Profiler leverer letvægtskundekontekster under en overordnet tjenesteprincipal. Du kan oprette profiler uden en separat Microsoft Entra programregistrering for hver kunde. En overordnet kan oprette op til 100.000 profiler, og hver profil kan få adgang til eller oprette op til 1.000 arbejdsområder inden for de dokumenterede grænser.

Profiler kan passe til programmer, der værdsætter denne skalerings- og administrationsmodel og ikke kræver uafhængige Entra-identiteter til deres kundekontekster. De understøtter de dokumenterede grænseflader Power BI REST API, .NET SDK og XMLA/TOM, men ikke Fabric REST API'er. Profiler mangler også uafhængige Entra-logonposter og identiteten Betinget adgang til arbejdsbelastning pr. profil og forbliver bundet til deres overordnede.

En administreret identitets overordnet kan godkende uden gemte programhemmeligheder, men gør ikke sine profiler til uafhængige Entra-identiteter eller udvide deres API-understøttelse.

Evaluer fordelene og begrænsningerne ved den valgfri profilløsning , før du vælger den. Separate kundearbejdsområder og semantiske modeller kan understøtte begge identitetsmodeller. disse datadesignfordele er ikke eksklusive profiler.

Find den relevante implementeringsvejledning

Brug den vejledning, der svarer til din valgte model og aktuelle løsning:

Relateret indhold

• Konfigurer et program til at have tillid til en administreret identitet.
• Microsoft Entra tjenestegrænser.
• Betinget adgang til arbejdsbelastningsidentiteter.
• Fabric understøttelse af REST API-identiteter.