Palvelun pääprofiilien korvaaminen palvelun päänimillä

Jos ratkaisusi käyttää palvelun pääprofiilia (SPP) ja niiden käyttäjätietoja, hallintoa, ohjelmointirajapintaa tai vaatimuksiasi rajoittavia toiminnallisia rajoituksia, tämän oppaan avulla voit arvioida ja ottaa käyttöön korvaamisen erillisillä Microsoft Entra palvelun päänimillä. Jos aiemmin luotu profiilipohjainen ratkaisusi täyttää vaatimuksesi, voit jatkaa sen käyttöä.

Jos asiakas valitsee siirtämisen, tässä oppaassa suositellaan hallittuja käyttäjätietoja ja yhdistettyjä tunnistetietoja, joissa isännöinti- ja luottamusvaatimukset täyttyvät. Suoran palvelun päänimen todentaminen on edelleen vaihtoehtona. Molemmat polut tarjoavat erilliset asiakasidentiteetit hakemistojen hallinnointiin, riippumattoman kirjautumisen valvontaan ja pääsyn tuettuihin palveluihin profiilia huomioon perustuvien liittymien lisäksi.

Miksi profiilista siirtyminen

Harkitse profiilien korvaamista, kun seuraavat rajoitukset rajoittavat ratkaisuasi:

• Profiilit eivät ole Microsoft Entra ID parhaiden käytäntöjen mukaisia hallituille kuormituksen käyttäjätiteeteille. Profiililla ei ole edustusta Microsoft Entra ID. Se ei tuota riippumattomia kirjautumislokeja, sillä ei voi käyttää omaa ehdollista käyttöoikeuskäytäntöään eikä sitä voi hallita työkaluilla, joita käytetään muualla käyttäjätietotilassa.

Et voi esimerkiksi määrittää profiilia Direct Lake -yhteyden käyttäjätietona semanttisesta mallista Lakehouseen tai varastoon. Et voi myöskään myöntää sille pääsyä riippumattomana Microsoft Entra käyttäjätietoina muihin jatkopalveluihin, joihin sovelluksen tai sen kuormitusten on päästävä. Erillinen palvelun päänimi voi saada nämä käyttöoikeudet, jos palvelu tukee sitä.

Et voi käyttää profiileja Fabric REST-ohjelmointirajapintojen kanssa. Profiileja tukevat vain profiilin huomioon ottavat REST-ohjelmointirajapinta, sen .NET SDK ja tuetut XMLA/TOM-käyttöliittymät. Fabric REST-ohjelmointirajapinnat eivät tue profiileja, eikä tukea ole suunniteltu. Käytä tuettuja käyttäjätietoja näille ohjelmointirajapintakutsuille profiilin sijaan. Erityisen palvelun päänimen luominen vastaa käyttäjätietojen vaatimukseen, mutta jokaisen ohjelmointirajapinnan ja toiminnon on silti tuettava näitä käyttäjätietoja ja myönnettävä sille tarvittavat käyttöoikeudet.

• Todentaminen pysyy sidottuna pääidentiteetin käyttäjätietoihin. Kun pääkohde käyttää salaista koodia tai varmennetta, suojaa ja kierrä kyseinen tunnistetieto. Suositellussa korvaamismallissa vältetään tallennetut asiakassovelluksen tunnistetiedot. Profiilit voivat myös käyttää hallittua käyttäjätietojen pääkohdetta, joten pelkkä salaamaton todentaminen ei edellytä profiilien korvaamista. Hallittujen käyttäjätietojen pääkohde ei anna profiileille itsenäisiä hakemiston käyttäjätietoja tai laajempaa ohjelmointirajapinnan tukea.

Profiilit ratkaisevat skaalautuvan ongelman, eivät itsenäisen identiteetin ongelmaa. Yksi pääpalvelun päänimi voi luoda enintään 100 000 profiilia, ja kukin profiili voi käyttää tai luoda jopa 1 000 työtilaa. Palvelun päänimi voi kuulua enintään 1 000 työtilaan tässä mallissa. Erilliset asiakasidentiteetit kuluttavat sen sijaan Microsoft Entra hakemistoobjekteja. Vahvista käytettävissä olevat rajoitukset asiakasmäärääsi vasten ennen siirtoon vahvistamista.

Muut huomioon otettavat profiilirajoitukset

Hallittujen käyttäjätietojen ja yhdistettyjen tunnistetietojen malli

Käytä tätä mallia uudessa, erillisen päänimen ratkaisussa tai kun päätät korvata profiilit, jos suorituspalvelusi täyttää hallitut käyttäjätietojen isännöintivaatimukset.

Malli

Anna jokaiselle asiakkaalle todellinen Microsoft Entra palvelun päänimi ja käytä sovelluksen hallittuja käyttäjätietoja vahvistuslähteenä. Tämä lähestymistapa korvaa sekä jaetun sovelluksen tunnistetiedot että profiilin abstraktion. Voit kirjata ja hallita kuormituksen käyttäjätietojen jokaista asiakastunnusta sekä määrittää ehdollisen käyttöoikeuden. Se voi kutsua tuettuja Fabric REST-ohjelmointirajapintoja.

Tämä on suositeltu siirtopolku, jossa sen Azure isännöinti- ja luottamusvaatimukset sopivat ratkaisuun. Se poistaa tallennetun asiakassovelluksen tunnistetiedot ja niiden kiertoprosessit muuttamatta työtilan ja resurssin valtuutuksen pakotusta.

Arkkitehtuuri näyttää sovelluksen suorituksenaikaiset toiminnot, kolme asiakassovelluksen käyttäjätiedot ja luottamukset sekä yksi yhteen -asiakastyötilasuhteet. Se edustaa oletusarvoista jaetun suorituksenaikaista järjestelyä, ei uutta eristysrajaa.

Kuva 1. Yhden sovelluksen hallitsemat käyttäjätiedot todennetaan erillisiksi asiakaspalvelun päänimiksi.

Toiminta

1. Sovelluksen hallitsemat käyttäjätiedot. Määritä käyttäjän määrittämät hallitut käyttäjätiedot ISV-sovellukselle, joka suoritetaan tuetussa Azure tietojenkäsittelyssä, kuten sovelluspalvelussa, säilösovelluksissa, asianmukaisesti määritetyssä AKS-kuormituksessa tai näennäiskoneessa. Käytä sovellukselle yhtä hallittua käyttäjätietoa, ei yhtä asiakasta kohti. Sillä ei ole omia asiakastyötilan tai kohdepalvelun käyttöoikeuksia; sen rooli tässä on vain vahvistuksen esittäminen.

2. Asiakas-, käyttäjä- tai ryhmäpalvelun päänimet. Luo kullekin olemassa olevalle asiakkaalle tai valtuutusrajalle Microsoft Entra sovelluksen rekisteröinti ja palvelun päänimi ISV:n hakemistovuokraajaan. Looginen asiakas ei välttämättä tarkoita erillistä Microsoft Entra vuokraajaa eikä käyttäjäkohtaista käyttäjätietoa tarvita, ellei olemassa oleva käyttöoikeusrakenne sitä vaadi.

3. Liitettyjen käyttäjätietojen tunnistetiedot. Määritä yhdistettyjen käyttäjätietojen tunnistetiedot kullekin asiakassovelluksen rekisteröinnille, jotta voit luottaa sovelluksen hallittuihin käyttäjätietoihin. Suorituspalvelu voi sitten käyttää sen hallittua käyttäjätietotunnusta vahvistuksena, jolla se saa käyttöoikeustietueen kyseiselle asiakassovellukselle ilman asiakassalaisuutta tai varmennetta.

4. Suorituksenaikaisen tunnuksen vaihto. Kun käyttäjä A tai asiakaskohtainen työ kutsuu sovelluksen, ratkaise asiakkaan A luotetun palvelinpuolen yhdistämismäärityksen avulla. Hanki hallittu käyttäjätietotunnus yleisön api://AzureADTokenExchangekanssa, vaihda se käyttöoikeustietueeksi SP-A:na ja kutsu sitten kohde-ohjelmointirajapintoja palvelun päänimen tunnuksen avulla työtilojen hallintaan, resurssitoimintojen suorittamiseen tai sovelluskohtaisten tunnusten pyytämiseen tarvittaessa.

   Edellisessä vaiheessa vaihdossa .NET Azure Identity ClientAssertionCredential hyväksyy hallitun käyttäjätietotunnuksen asiakasvahvistukseksi. Tämä on Azure käyttäjätietojen tunnistetietotyyppi, ei MSAL-luokka. Käyttöoikeustietueen on suunnattava resurssin ohjelmointirajapinnan kohderyhmälle, ei tunnuksen vaihtajaryhmälle.

5. Työtilan käyttöoikeus. Myönnä jokaiselle palvelun päänimelle jäsenelle tai järjestelmänvalvojalle käyttöoikeus sen määritettyihin työtiloihin vain, kun näitä rooleja tarvitaan, tai vähiten etuoikeutettua tuettua roolia vaadituille toiminnoille. Tämä myöntää vaikutusalueille resurssin käyttöoikeuden. Koska sovelluksen hallitut käyttäjätiedot voidaan todentaa jokaisen siihen luottavan asiakassovelluksen tavoin, kohdellaan sitä ja sen käsittelyisäntiä arvokkaina käyttäjätietoina ja infrastruktuurina.

Miksi tätä polkua suositellaan

• Vähemmän pitkäikäisiä tunnistetietoja. Suorituspalveluun ei tarvitse tallentaa, hakea tai jakaa asiakassovelluksen salaista koodia tai varmenteen yksityistä avainta.

• Vähemmän kiertoa. Azure hallitsee hallittuja käyttäjätietojen tunnistetietoja ja lyhytikäisiä tunnuksia. Et tarvitse erillistä salaisen koodin tai varmenteen uusimisprosessia jokaiselle asiakassovellukselle tämän luottamuksen avulla.

• Johdonmukainen perehdytys. Asiakkaan sovelluksen ja palvelun päänimen valmisteleminen, eksplisiittisen luottamuksen määrittäminen ja asiakasresurssien käyttöoikeuksien myöntäminen. Uudet asiakkaat eivät vaadi uusia pitkäikäisiä tunnistetietoja.

Nämä edut eivät poista luottamuksen hallinnan, asiakkaan valtuutuksen, valvonnan tai hakemiston kapasiteetin suunnittelun tarvetta.

Vaihtoehto: Suora palvelun päänimen todentaminen

Jos et halua käyttää hallittuja käyttäjätietoja ja yhdistettyjä tunnistetietoja, luo samat erilliset asiakassovellusten rekisteröinnit ja palvelun päänimet, mutta todenna ne suoraan varmenteiden tai muiden tuettujen sovelluksen tunnistetietojen avulla. Suosi varmenteita asiakassalaisuuksien sijaan, jos tuettuja. Suojaa yksityiset avaimet ja salaisuudet, rajoita niiden käyttöä ja automatisoi kierto.

Suora todennus säilyttää hakemiston näkyvyyden, pääkirjautumislokit ja tuettujen ohjelmointirajapintojen käytön. Se ei edellytä hallittua käyttäjätietojen isännöintiä tai luottamusjärjestelyä, mutta se ei poista tallennettuja asiakkaan tunnistetietoja.

Avainkäsitteet

Erottele tunnistetiedot, jotka määrittävät luottamuksen suorituksen aikana käytetyistä tunnuksista.

Yhdistettyjen käyttäjätietojen tunnistetiedot

Määritä yhdistetty käyttäjätietojen (FIC) Microsoft Entra sovelluksen rekisteröinti, joka tukee asiakaspalvelun päänimeä. Se määrittää luottamussuhteen tunnuksen myöntäjän kanssa ja määrittää, minkä vahvistuksen sovellus hyväksyy asiakassalaisuuden tai varmenteen sijaan.

Tässä arkkitehtuurissa kohdekäyttäjätiedot ovat asiakassovellus ja palvelun päänimi; sovelluksen hallittu käyttäjätieto on vahvistuksen lähde. Siksi määrität asiakkaan tunnistetiedot sovelluksen rekisteröinnissä palvelun pääobjektin tai lähteen hallitun käyttäjätiedon sijaan.

Kun sovellus esittää hallitun käyttäjätietotunnuksen ja pyytää asiakassovellukselle käyttöoikeustietuetta, Microsoft Entra ID vahvistaa vahvistuksen suhteessa yhdistettyyn tunnistetietoon. Liikkeeseenlaskijan, aiheen ja yleisön on vastattava toisiaan. Jos vahvistus onnistuu, se myöntää käyttöoikeustietueen, joka edustaa pyydetyn resurssin asiakaspalvelun kohdeobjektia.

Hallittujen käyttäjätietojen ja sovellukseen rekisteröintiin luotavien käyttäjätietojen on oltava samassa Microsoft Entra vuokraajaa. Resurssiyleisö on eri valinta kuin vahvistusyleisö. Azure käyttäjätietojen yleisen pilvipalvelun tunnuksen exchange-vaikutusalue on api://AzureADTokenExchange/.default; ohjelmointirajapinnan kohdealue on yleensä resurssitunnus, jota /.defaultseuraa .

Tunnuksen vaihtotyönkulku: asiakkaan tunnistetiedot ja yhdistetty vahvistus

Tähän työnkulkuun osallistuu kolme osallistujaa ja kuusi vaihetta. SP-A on asiakkaan A:n sovellus ja palvelun päänimi. Hallitun käyttäjätiedon vahvistustunnus ja palautettu SP-A resurssin käyttöoikeustietue palvelevat eri tarkoituksia.

Kuva 2. Asiakkaan tunnistetietojen tunnuksen vaihtoa, jota tukee hallittu käyttäjätietojen vahvistus.

1. Pyydä hallitun käyttäjätiedon tunnusta. Azure sovellus pyytää hallittua käyttäjätietotunnusta yleisön api://AzureADTokenExchangekanssa.

2. Palauta vahvistustunnus. Microsoft Entra ID myöntää hallitun käyttäjätietotunnuksen, jonka sovellus vastaanottaa isännöintiympäristönsä hallitun käyttäjätietomekanismin Azure kautta.

3. Lähetä asiakastunnuspyyntö. Lähetä pyyntö hakemistovuokraajan /oauth2/v2.0/token päätepisteeseen parametrilla grant_type=client_credentials, client_id=<SP-A-client-id>, client_assertion=<MI-token>ja scope=<target-resource>/.default. Koko OAuth-pyyntö sisältää myös tiedot client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer. Käyttäjätietokirjasto käsittelee tämän parametrin.

4. Vahvista vahvistus. Microsoft Entra ID vahvistaa hallitun käyttäjätietotunnuksen käyttämällä yhdistettyä tunnistetietoa SP-A:n sovelluksen rekisteröinnissä.

5. Palauta asiakkaan käyttöoikeustietue. Microsoft Entra ID palauttaa SP-A käyttöoikeustietueen, jonka kohderesurssi on sen yleisö.

6. Kutsu kohde-REST-ohjelmointirajapintoja. Sovellus lähettää SP-A:n käyttöoikeustietueen kohde-ohjelmointirajapintaan. Se ei käytä vahvistustunnusta resurssin haltijatunnuksena eikä valitse profiilia.

Arkkitehtuurin vertailu

Korvaava sarake kattaa yleensä varatut palvelun päänimet. Hallittu käyttäjätieto ja liittoutuminen ovat suositeltu todentamismenetelmä, mutta myös suora varmenne tai muu tuettu tunnistetietojen todennus on mahdollista.

Tämän taulukon lukeminen: kumpikaan järjestely ei tarjoa asiakkaiden salausta. Resurssin avustukset valvovat käyttöoikeutta, ja suorituspalvelulla voi olla epäsuora tavoittavuus eri asiakkaiden välillä. Profiilit tarjoavat kevyen käyttäjätietojen asteikon. Erilliset päänimet parantavat hakemistojen hallintaa, kirjautumisen näkyvyyttä ja ohjelmointirajapinnan yhteensopivuutta. Suositeltu hallittu käyttäjätieto ja liittoutumispolku poistaa myös tallennetun asiakassovelluksen tunnistetiedot.

Siirtopolku

Seuraava polku korvaa profiilit erillisillä asiakaspalvelun päänimillä. Pidä siirto- ja palautuspäätökset erillisinä kullekin asiakkaalle.

Profiileista hallittuihin käyttäjätietoihin ja yhdistettyihin tunnistetietoihin

Käytä seuraavia siirtymisvaiheita pienen pilottikohortin ja asiakaskohtaisen käyttöönottokytkimen kanssa. Pidä profiilireitti käytettävissä, kunnes vahvistus ja sovittu palautusaika on valmis.

Vaihe 0: Luo sovelluksen hallitut käyttäjätiedot

• Luo käyttäjän määrittämät hallitut käyttäjätiedot sovellukselle ja määritä se käsittelyresurssille. Toteutusopas näyttää luonti- ja määrityskomennot.

• Tallenna sen päätunnuksen (objektin) tunnus. Jokaisen asiakassovelluksen yhdistetty tunnistetieto käyttää tätä arvoa aiheenaan. Tallenna myös asiakastunnus, hakemiston vuokraajatunnus ja Azure resurssitunnus.

Käytä sovellukselle yhtä hallittua käyttäjätietoa, ei yhtä asiakasta kohti. Tässä mallissa tarpeetonta on erillisten käyttäjätietojen käyttäminen jokaista asiakasta varten: asiakkaan käyttäjätiedot ovat palvelun päänimi ja käyttäjätieto toimittaa vahvistuksen. Jos käytössä on suurempi käyttöönotto tai pienempi kompromissi, jaa asiakkaat pienessä määrässä suorituksenaikaisia käyttäjätietoja, joihin kaikkiin luotetaan vain sen asiakassovellusten määritetyn alijoukon mukaan.

Vaihe 1: Varasto

Luettele kaikki olemassa olevat profiilit profiilinhallinnan ohjelmointirajapinnan kautta:

GET {profile-api-base}/v1.0/myorg/profiles

Tallenna kullekin profiilille tietue:

• Profiilitunnus ja näyttönimi, pääpalvelun päänimi ja asiakkaan yhdistämismääritys.

• liittyvät työtilat ja roolimääritykset.

• liittyvät semanttiset mallit tai tietojoukot, raportit ja muut resurssit.

• Yhteydet, tietolähteen tunnistetiedot, omistajuuden riippuvuudet, taustatyöt ja profiilista riippuvaiset ohjelmointirajapintatoiminnot.

Tallenna ennen asiakkaan määrityksen muuttamista aiemmin luodut työtilaroolit, semanttisen mallin omistajuus, yhteyden käyttäjätiedot, tunnistetietojen määritys ja asiakkaan profiiliin -yhdistäminen, joita tarvitaan palauttamisessa. Tallenna suojatut viittaukset tunnistetietoihin, älä salaisiin arvoihin.

Tallenna asiakkaiden kokonaismäärä ja vertaa vaadittuja sovelluksen ja palvelun päänimen objekteja Microsoft Entra hakemisto-objektikiintiöön ennen jatkamista. Vahvista 1 000 työtilan jäsenyyden rajoitus ja myös resurssikohtaiset rajoitukset. Jos asukasmäärä ylittää yhden hakemiston kiintiön, suunnittele tuettu kiintiön lisäys tai tarkoituksellisesti hallittu usean hakemiston rakenne. Tämä malli ei ratkaise sitä automaattisesti.

Vaihe 2: Uusien käyttäjätietojen valmisteleminen

Kullekin profiilille tai profiiliryhmälle, joka kuuluu samaan asiakkaan valtuutusrajaan:

1. Luo sovelluksen rekisteröinti ja palvelun päänimi. Tallenna sovelluksen asiakastunnus, sovelluksen objektitunnus ja palvelun päänimen objektitunnus erikseen.

2. Määritä yhdistettyjen käyttäjätietojen tunnistetiedot asiakkaan sovelluksen rekisteröinnille, joka luottaa vaiheessa 0 luotuun sovelluksen mittavaan käyttäjätietoon.

3. Anna uudelle palvelun päänimelle käyttöoikeus samoihin asiakastyötiloihin ja resursseihin. Käytä Member-funktiota, jos keksityt toiminnot edellyttävät sitä tai vähiten etuoikeutettua tuettua roolia. Myönnä järjestelmänvalvojalle oikeudet vain tarvittaessa.

Säilytä olemassa olevat työtila- ja resurssitunnukset aina, kun sitä tuetaan. Työtilan myöntäminen ei automaattisesti siirrä resurssien omistajuutta, yhteyden käyttäjätietoja tai tietolähteen tunnistetietoja. Tee nämä palvelukohtaiset päivitykset ennen katkaisua.

Vaihe 3: Sovelluskoodin päivittäminen

• Korvaa profiilinvalinnan otsikko- ja SDK-profiilin määritykset hallitulla käyttäjätietojen tukemalla tunnuksen vaihdolla valitulle asiakassovellukselle.

• Päivitä asiakaskohtaisten käyttäjätietojen yhdistäminen sovellustietokannassa.

Asiakastunnukset ovat ISV Microsoft Entra asiakkaiden loogisia tunnisteita. Vahvista todennetun käyttäjän asiakkaan jäsenyys ennen käyttäjätietojen valitsemista. Avaintunnus tallentaa välimuistiin hakemiston vuokraajan, asiakastunnuksen sekä resurssin tai laajuuden mukaan.

• Sovelluskohtaisen tunnuksen luonnin päivittäminen käyttämään asiakaspalvelun päänimen käyttöoikeustietuetta. Jos ratkaisusi upottaa raportteja tai muuta sisältöä, päivitä myös kyseisen tunnuksen luominen. upottaminen on siirrettävä olemassa oleva kuormitus, joka ei ole tämän oppaan edellytys.

• Päivitä työtilan hallinta, loppuvaiheen yhteydet, valmistelu, ajoitetut työt ja kaikki muut aloituspisteet käyttämällä vanhaa profiilimääritystä.

Vaihe 4: Vahvista

Vahvista kullekin asiakkaalle:

• Työtilan ja resurssien käyttö onnistuu uuden palvelun päänimen avulla.

• Hallitun käyttäjätietotunnuksen hankinta ja yhdistetty tunnuksen vaihto onnistuivat aiotulle asiakassovellukselle.

• Sovelluskohtaiset tunnukset luodaan onnistuneesti, jos niitä käytetään, ja olemassa olevat raportit tai muu upotettu sisältö hahmonnetaan tarvittaessa oikein.

• Uudet palvelun päänimen kirjautumiset näkyvät Microsoft Entra ID, ja ne voidaan korreloida sovelluksen ja resurssien valvontalokien kanssa.

• Asiakkaiden välinen käyttö on estetty: soittaja ei voi valita toisen asiakkaan sovelluksen käyttäjätietoja tai resurssitunnuksia.

Ennen tuotannon katkaisua dokumentoi ja testaa pilottiasiakkaan palautusmenettelyä. Sisällytä semanttisen mallin omistajuuden palauttaminen, yhteyden käyttäjätiedot, tietolähteen tunnistetiedot ja siirron aikana muutetut käyttöoikeudet. Varmista, että aiempi profiili voi suorittaa tarvittavat toimintonsa palauttamisen jälkeen, mukaan lukien päivitysmääritykset ja parametripäivitykset.

Vaihda asiakkaan sovellusreittiä vasta, kun hyväksyntäehdot on hyväksytty. Valvo virheitä, suorituskykyä ja käyttöoikeuksia ennen käyttöönoton laajentamista.

Jos vahvistus epäonnistuu, keskeytä taustatyöt ja palauta edellinen määritys käyttämällä kunkin palvelun tuettuja toimintoseditmiä. Sovellusreitin vaihtaminen takaisin profiiliin ei välttämättä palauta toimintoja, jotka riippuvat omistajuudesta tai tunnistetiedoista. Kun olet palauttanut vaaditut määritykset, siirry takaisin profiilipohjaiseen reititykseen ja tarkista resurssien käyttö ja riippuvaiset toiminnot ennen töiden jatkamista. Säilytä alkuperäiset profiilit ja vaaditut käyttöoikeudet koko palautusjakson ajan.

Vaihe 5: Käytöstäpoistoprofiilit

• Poista palautusjakson jälkeen vanhentuneet alkuperäisen ylätason työtilan ja profiilin työtilat vahvistettuaan, että varatuilla asiakaspalvelun päänimillä on tarvittavat käyttöoikeudet.

Poista jokainen siirretty profiili profiilinhallinnan ohjelmointirajapinnan kautta:

DELETE {profile-api-base}/v1.0/myorg/profiles/{profileId}

• Voit halutessasi poistaa alkuperäisen jaetun sovelluksen rekisteröinnin ja palvelun päänimen, jos mikään asiakas, työ tai asiaan liittymätön kuormitus ei vieläkään käytä niitä. Poista vanhentuneet tunnistetiedot käytöstä, säilytä siirron yhdistämismääritykset ja valvo tietueita säilytysvaatimustesi mukaan.

Käyttöönotto-ohje

Tässä oppaassa toteutetaan suositeltu hallittujen käyttäjätietojen ja yhdistettyjen tunnistetietojen polku. Suoratodennusvaihtoehto noudattaa samoja käyttäjätietojen ja käyttöoikeuksien määrityksiä, ja se kuvataan päävaiheiden jälkeen. Azure CLI esimerkeissä käytetään Bash-syntaksia; korvaa paikkamerkit ja kirjaudu sisään aiottuun hakemistoon ja tilaukseen ennen niiden suorittamista.

Vaatimukset

• Azure-tilaus ja oikeudet luoda ja määrittää hallittuja käyttäjätietoja suositellulle polulle.

• Microsoft Entra ID käyttöoikeudet sovellusten rekisteröintien ja palvelujen päänimien luomiseen ja sovelluksen tunnistetietojen päivittämiseen. Azure resurssin käyttöoikeudet ja hakemiston käyttöoikeudet ovat erilliset.

• Sovellus, jota isännöidään tuetuissa Azure tietojenkäsittelyssä, kuten sovelluspalvelu, säilösovellukset, asianmukaisesti määritetty AKS-kuormitus tai näennäiskone. Mi-tuettu vahvistuslähde tässä mallissa määräytyy tämän Azure isännöinnin määrityksen mukaan.

• Järjestelmänvalvojan oikeudet myöntää asiakkaan työtilalle ja resurssille käyttöoikeus, määrittää tarvittavat palveluasetukset ja myöntää ohjelmointirajapinnan käyttöoikeudet tai suostumuksen, jos kohdepalvelu niitä edellyttää.

• Azure CLI asentanut ja kirjautunut sisään oikean hakemiston vuokraajaan. Vahvista tilauskonteksti ennen Azure resurssien luomista.

Kehittäjän vuokraaja-asetukset

Tarkista tarvittavat asetukset palvelun hallintaliittymässä vuokraaja-asetuksista ja kehittäjäasetuksista. Alueen palvelun päänimen käyttöoikeus sallittuun käyttöoikeusryhmään, joka sisältää asiakaspalvelun päänimet. Katso tarkat tunnisteet ja nykyinen toiminta kohdasta Kehittäjien vuokraaja-asetukset.

Lisää jokaiselle ratkaisusi edellyttämälle ryhmälaajennetulle asetukselle jokainen korvaava asiakaspalvelun päänimi sallittuun käyttöoikeusryhmään ennen testaamista tai leikkaamista. Alkuperäiselle pääpalvelun päänimelle myönnetty käyttöoikeus ei automaattisesti valtuuta korvaavia päänimiä. Julkisen ohjelmointirajapinnan käyttöoikeusasetus koskee sekä olemassa olevia profiilia huomioon ottavia REST-ohjelmointirajapintoja että Fabric REST-ohjelmointirajapintoja. Vain käyttäjätietojen siirtäminen ei poista tätä edellytystä.

Seuraava julkinen ohjelmointirajapinta -asetus käyttää tuoteneutraalia tunnistetta; hallintaliittymä voi sisältää palvelun nimen.

Tarkista todelliset arvot oletusasetusten sijasta. Uudet ja olemassa olevat vuokraajat voivat olla erilaisia ja järjestelmänvalvojat voivat muuttaa asetuksia. Säilytä profiiliasetus, kunnes kaikki riippuvaiset asiakkaat ja työt siirretään. Älä ota upotusasetuksia käyttöön kuormitukselle, jota ei upota.

Vaihe 1: Luo ja määritä käyttäjän määrittämät hallitut käyttäjätiedot

Nämä hallitut käyttäjätiedot edustavat ISV-sovellusta, eivät yksittäistä asiakasta. Käytä aiemmin luotua resurssiryhmää:

az identity create \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --location "<azure-region>"

Tallenna sen asiakastunnus, pääkohteen (objektin) tunnus, hakemiston vuokraajatunnus ja Azure resurssitunnus. Määritä se käsittelyresurssiin. Aiemmin luodulle sovelluspalvelusovellukselle:

az webapp identity assign \
  --resource-group "<resource-group>" \
  --name "<web-app-name>" \
  --identities "<managed-identity-resource-id>"

Käytä vastaavaa käyttäjätietojen määrittämisen toimintosarjaa muissa laskentapalveluissa. Valitse eksplisiittisesti nämä käyttäjän määrittämät käyttäjätiedot suorituspalvelussa. Koska käyttäjätiedot ovat riippumattomia isäntäresurssista, isännän uudelleenjärjestelyn ei tarvitse korvata kaikkia asiakkaiden luottamussuhteita.

Vaihe 2: Luo palvelun päänimi kullekin asiakkaalle

Luo jokaiselle olemassa olevien profiilien edustamalle asiakkaalle, käyttäjälle tai ryhmälle sovelluksen rekisteröinti ja sen palvelun päänimi. Tämä esimerkki luo yhden vuokraajan sovelluksen ISV:n hakemistoon:

APP_CLIENT_ID=$(az ad app create \
  --display-name "customer-a-application" \
  --sign-in-audience AzureADMyOrg \
  --query appId --output tsv)

az ad sp create --id "$APP_CLIENT_ID"

APP_OBJECT_ID=$(az ad app show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

SP_OBJECT_ID=$(az ad sp show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

Vaihe 3: Yhdistettyjen käyttäjätietojen tunnistetietojen määrittäminen

Nouda hallitun käyttäjätiedon päänimi ja sen hakemiston vuokraajatunnus. Käytä käyttäjätietojen vuokraajaa sen sijaan, että olettaen, että toisella nykyisellä tilauksella on sama vuokraaja:

MI_PRINCIPAL_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query principalId --output tsv)

DIRECTORY_TENANT_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query tenantId --output tsv)

Lisää yhdistettyjen käyttäjätietojen tunnistetiedot kuhunkin asiakassovelluksen rekisteröintiin. Seuraava yleisen pilvipalvelun komento käyttää vaiheen 2 sovellusobjektitunnusta ja juuri noudettuja MI-arvoja:

az ad app federated-credential create \
  --id "$APP_OBJECT_ID" \
  --parameters "{
    \"name\": \"trust-application-mi\",
    \"issuer\": \"https://login.microsoftonline.com/$DIRECTORY_TENANT_ID/v2.0\",
    \"subject\": \"$MI_PRINCIPAL_ID\",
    \"audiences\": [\"api://AzureADTokenExchange\"],
    \"description\": \"Trust the ISV application managed identity\"
  }"

Vaihtoehtoisesti voit tallentaa saman JSON-tiedoston, jossa on korvatut arvot paikallisessa credential.json tiedostossa, ja välittää kohteen --parameters credential.json. Toista luottamus jokaiselle asiakassovellukselle. Salli määrityksen levitys ennen tunnuksen vaihtamisen vahvistamista.

Vaihe 4: myönnä kullekin palvelun päänimelle työtilan käyttöoikeus

Lisää asiakaspalvelun päänimi jäseneksi tai järjestelmänvalvojaksi vain määritettyihin työtiloihin, joissa tämä rooli vaaditaan. Suosi matalampaa tuettua roolia, jos se täyttää toiminnon vaatimukset. Tämä myöntäminen määrittää asiakkaan resurssien käytön laajuuden.

Käytä työtilan hallintaliittymää tai työtilan roolimääritystä REST-toimintoa. Seuraavassa esimerkissä käytetään määritettävissä olevaa ohjelmointirajapintaa ja resurssitunnisteita. Se edellyttää valtuutettua käyttäjätietoa; suorituksenaikaiselle mi:lle ei sinänsä myönnetä asiakasresurssien käyttöoikeuksia tunnusten vaihtoon.

PROFILE_API_BASE="<existing-profile-aware-api-base-url>"
PROFILE_RESOURCE="<existing-api-resource-identifier>"
WORKSPACE_ID="<customer-workspace-id>"

TOKEN=$(az account get-access-token \
  --resource "$PROFILE_RESOURCE" \
  --query accessToken --output tsv)

curl --fail-with-body --request POST \
  "$PROFILE_API_BASE/v1.0/myorg/groups/$WORKSPACE_ID/users" \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/json" \
  --data "{
    \"identifier\": \"$SP_OBJECT_ID\",
    \"groupUserAccessRight\": \"Member\",
    \"principalType\": \"App\"
  }"

Käytä päätepistettä ja pyydä muotoa, joka on dokumentoitu palvelulle, joka omistaa olemassa olevan työtilan. Näytetty toiminto koskee profiilin huomioon ottavaa työtilan ohjelmointirajapintaa; muut ohjelmointirajapinnat saattavat käyttää erilaisia roolimääritysten rakenteet. Älä korvaa asiakastunnusta, jos toiminto odottaa palvelun päänimen objektitunnusta. Vältä haltijatunnusten kirjaamista ja salli käyttöoikeuksien levitys.

Vaihe 5: Todenna ja kutsu ohjelmointirajapintoja suorituksen aikana

1. Ratkaise todennetun asiakkaan sovelluksen asiakastunnus ja sallitut resurssit luotetun palvelinpuolen määrityksestä.

2. Hanki vahvistustunnus käyttämällä valittua käyttäjän määrittämää hallittua käyttäjätietoa ja api://AzureADTokenExchange/.default vaikutusaluetta yleisessä pilvipalvelussa.

3. Käytä MI-tunnusta asiakassovelluksen asiakasvahvisuutena. Pyydä käyttöoikeustietuetta, jolla on resurssin ohjelmointirajapinnan sovellusalue, ei vahvistusyleisöä.

4. Kutsu kohde-ohjelmointirajapintaa kyseisen asiakassovelluksen käyttöoikeustietueen avulla ja ilman profiilinvalinnan määritystä. Hallitse työtiloja, pyydä pakollisia sovelluskohtaisia tunnuksia ja suorita muita keksittyjä toimintoja asiakastietojen kautta.

Käytä .NET Azure Identity ClientAssertionCredential-kohdetta ja hallittua käyttäjätietotunnusta vahvistuskutsuna. Kuusivaiheinen työnkulku ja viralliset määritysesimerkit näyttävät exchangen ilman upotuskohtaista sovelluskoodimallia.

Perehdytys ja käyttöönotto automaattisesti

Rivitä neljä perehdytystoimintoa valmisteluputkeen: luo sovelluksen rekisteröinti, luo sen palvelun päänimi, määritä sen yhdistetty luottamus ja myönnä työtilan rooli. Luo vastaava pois käytöstäpoistopolku samalla kertaa: poista resurssien avustukset, kumoa vanhentunut luottamus tai tunnistetiedot ja poista sovelluksen käyttäjätiedot vasta riippuvuuksien tarkistuksen jälkeen.

Vaihtoehtoinen toteutus: palvelun päänimien todentaminen suoraan

Jos et halua käyttää mi-ja liittoutumista, ohita vaiheet 1 ja 3. Suorita vaihe 2 kullekin asiakkaalle ja määritä tuettu sovelluksen tunnistetieto liitettyjen luottamusten sijaan.

Käytä varmennetta, jota tuetaan, ja noudata sovelluksen tunnistetietojen määritysohjeita. Lataa julkinen varmenne, suojaa yksityinen avain sopivassa tunnistetietosäilössä ja automatisoi uusiminen. Jos asiakassalaisuus on tarpeellinen, suojaa se ja uusi se ennen sen vanhentumista.

Suorita vaihe 4 samoilla vähäosaisimmillä asiakasavustuksilla. Vaiheessa 5 käytä asiakkaan asiakastunnusta ja sen tunnistetietoja asiakkaan tunnistetietojen pyytämiseen suoraan. Pidä samat asiakkaan reitityksen, tunnusvälimuistin erottelun, vahvistuksen ja siirron puhdistustoiminnot.

Suojaus, rajoitukset ja huomioitavat seikat

Käytä seuraavia ohjausobjekteja valitsemaasi todennuspolkuun ja suunnittele sen käyttörajoitukset.

Suojaussuositukset

• Käytä vakaata käyttäjän määrittämää hallittua käyttäjätietoa. Näin vältetään asiakkaiden luottamussuhteiden menettäminen vain siksi, että korvataan käsittelyresurssi. Älä käytä järjestelmän määrittämää käyttäjätietoa tämän sovellusluottamusmallin vahvistuslähteenä.

• Käsittele sovelluksen ohjelmointirajapintaa hyvin etuoikeutettuina käyttäjätietoina. Se voi todentaa käyttäjän jokaisen asiakassovelluksen, joka luottaa siihen. Rajoita käsittelyn käyttöönotto-oikeuksia, hallittuja käyttäjätietojen määrityksiä, sovellusten omistajia ja tunnistetietojen hallintaa. Osion suorituksenaikaiset käyttäjätiedot tarvittaessa kompromissialueen pienentämiseksi.

• Älä anna mi:lle omia asiakaspalvelun käyttöoikeuksia. Se on vahvistuksen lähde. asiakaspalvelun päänimet saavat työtilan ja tuotantoketjun loppuvaiheen palvelun avustukset.

• Vuokraajan asetukset, joissa on käyttöoikeusryhmä. Sisällytä jokainen asianmukainen asiakaspalvelun päänimi sallittuun ryhmään sen sijaan, että otat käyttöön palvelun päänimen käyttöoikeuden koko organisaatiolle.

• Valvo palvelun päänimen kirjautumisia ja ilmoita niistä. Korreloi sovellus- ja resurssilokien kanssa. Lokien kerääminen ilman asiakaskohtaista tutkintaa ja hälytyksiä ei tuota toiminnallista etua.

• Automatisoi perehdytys ja käyttöönotto yhdessä. Työtilaroolien poistamisen, tunnistetietojen tai trustien poistamisen ja vanhentuneiden palvelun päänimien poistamisen on oltava yhtä hallittuja ja toistettavissa kuin niiden valmistelu.

Säilytä asiakkaiden yhdistämismääritykset palvelinpuolella, vahvista jäsenyys ennen käyttäjätietojen valitsemista ja hylkää mielivaltaiset asiakkaan antamat käyttäjätiedot tai resurssitunnukset. Tunnuksen uudelleenkäyttö tarkoittaa, että yksi sisäänkirjautumistietue ei ole jokaisen ohjelmointirajapintakutsun tietue. Älä kirjaa salaisia tunnuksia, vahvistuksia, käyttöoikeustietueita tai varmenteen yksityisiä avaimia.

Rajoitukset ja toiminnalliset vaatimukset

Tutustu Microsoft Entra palvelun rajoituksiin ja kohdepalvelun ohjelmointirajapinnan käyttäjätietojen tukeen ennen kapasiteetin ja käyttöoikeuksien viimeistelyä.

Katso nykyiset luottamusrajoitukset ja levitystiedot artikkelista Yhdistettyjen käyttäjätietojen tunnistetietojen huomioon otettavat seikat.

Lisätietoja nykyisen käytännön kelpoisuudesta ja käyttöoikeuksista on kohdassa Kuormituksen käyttäjätietojen ehdollinen käyttö.

Käytä soveltuvin tavoin maailmanlaajuista pilvipalvelutunnuksen vaihtoyleisöä api://AzureADTokenExchange, Yhdysvaltain valtionhallinnon yleisöä api://AzureADTokenExchangeUSGovtai Kiina-yleisöä api://AzureADTokenExchangeChina. Vastaa valtuutusta pilvipalveluun. Tämän artikkelin esimerkeissä käytetään yleistä pilvipalvelua.

Käytä tuettuja käyttäjätietokirjastoja tunnuksen tallentamiseen välimuistiin ja päivitykseen. Salli luottamuksen ja käyttöoikeuksien levitys, yritä uudelleen tilapäisiä virheitä, joihin liittyy rajattu takaisku, ja tutki pysyviä liikkeeseenlaskijoita, aihe- tai yleisöristiriitoja. Jos kyseessä on suora todentaminen, kierrä varmenteita ja salaisuuksia päällekkäisen ajanjakson kanssa ja valvo vanhentumista.

Älä oleta, että profiilin poistaminen, tunnistetietojen poistaminen tai luottamuksen muuttaminen välittömästi mitätöi aiemmin annetut tunnukset. Tili tunnuksen elinkaaresta sekä kunkin resurssipalvelun valtuutus- ja kumoamiskäyttäytymisestä, kun suunnittelet katkaisua ja käytöstä poistamista.

Liittyvä sisältö

Käytä näitä viittauksia ohjelmointirajapintakohtaisiin käyttöoikeuksiin, nykyisiin käyttäjätietorajoituksiin ja olemassa olevaan kuormituksen määrittämiseen.

Profiilit, palvelun päänimet ja olemassa olevat kuormitukset

• Monivuokraaminen ja erilliset palvelun päänimet
• Palvelun pääprofiilit: valinnainen monivuokraajaratkaisu
• Palvelun pääprofiilit usean kohteen sovelluksille
• Määritä olemassa oleva sisältösovellus käyttämään palvelun päänimeä
• Kehittäjän vuokraaja-asetukset
• Aiemmin luotujen analyysien upottamisen yleiskatsaus
• Delegoitujen käyttäjien Real-Time koontinäytön upottamisen esikatselu

Kuormituksen käyttäjätietojen liittoutumista ja hallittuja käyttäjätietoja

• Kuormituksen käyttäjätietojen liittoutumisen yleiskatsaus
• Tärkeitä huomioitavia seikkoja ja rajoituksia liitettyjen käyttäjätietojen tunnistetiedoilla
• Määritä sovellus luottamaan hallittuihin käyttäjätietoihin
• Hallitut identiteetit Azure resursseille
• Liittoutumisen määritysesimerkkejä

SDK:t, ohjelmointirajapinnat ja palvelurajoitukset

• Azure Käyttäjätietojen asiakasassertionLuonti .NET:lle
• Sovelluskohtainen tunnuksen luontiviittaus olemassa olevia upotuskuormituksia varten
• Microsoft Entra palvelun rajat ja rajoitukset
• Fabric REST-ohjelmointirajapintojen tuetut sovelluksen käyttäjätiedot
• Yhteyksien käyttäjätiedot ja Direct Lake Security
• Ehdollinen pääsy työkuorman identiteetteille
• Työtilan roolimääritystoiminto
• Profiilinhallinnan ohjelmointirajapinta