Power BI:n suojauksen tekninen raportti

Yhteenveto: Power BI on Microsoftin online-ohjelmistopalvelu (SaaS eli Software as a Service), jonka avulla voit helposti ja nopeasti luoda omatoimisia liiketoimintatietojen koontinäyttöjä, raportteja, semanttisia malleja ja visualisointeja. Power BI:n avulla voit muodostaa yhteyden moniin eri tietolähteisiin, yhdistää ja muotoilla tietoja kyseisistä yhteyksistä sekä luoda sitten raportteja ja koontinäyttöjä, jotka voidaan jakaa muiden kanssa.

Kirjailijat: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Tekniset tarkistajat: Cristian Petculescu, Amir Netz, Sergei Gundorov

Koskee seuraavia: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI Mobile.

Muistiinpano

Voit tallentaa tai tulostaa tämän valkoisen raportin valitsemalla selaimessa Tulosta ja valitsemalla sitten Tallenna PDF-tiedostona.

Esittely

Power BI on Microsoftin online-ohjelmistopalvelu (SaaS eli Software as a Service), jonka avulla voit helposti ja nopeasti luoda omatoimisia liiketoimintatietojen koontinäyttöjä, raportteja, semanttisia malleja ja visualisointeja. Power BI:n avulla voit muodostaa yhteyden moniin eri tietolähteisiin, yhdistää ja muotoilla tietoja kyseisistä yhteyksistä sekä luoda sitten raportteja ja koontinäyttöjä, jotka voidaan jakaa muiden kanssa.

Maailma muuttuu nopeasti. organisaatiot käyvät läpi nopeutettua digitaalista muutosta, ja etätyö, verkkopalveluiden asiakaskysyntä kasvavat valtavasti ja kehittyneiden teknologioiden käyttö toiminnassa ja liiketoiminnan päätöksenteossa lisääntyvät. Ja kaikki tämä toimii pilvipalvelun avulla.

Kun siirtyminen pilvipalveluun on muuttunut tulvasta ja sen mukana tulevasta uudesta, alttiina olevasta pinta-alasta, yhä useammat yritykset kysyvät , kuinka suojattuja tietoni ovat pilvipalvelussa ja mikä päästä päähän -suojaus on saatavilla, jotta arkaluontoisia tietojani ei pääse vuotamaan? Niissä BI-ympäristöissä, joissa käsitellään usein yrityksen strategisimpia tietoja, nämä kysymykset ovat kaksin verroin tärkeitä.

BI-suojausmallin vuosikymmeniä vanhat perusteet – objektitason ja rivitason suojaus – vaikka ne ovatkin vielä tärkeitä, eivät selvästikään enää riitä pilvipalvelun aikakaudella tarvittavan suojauksen tarjoamiseen. Organisaatioiden on sen sijaan etsittävä liiketoimintatietojensa pilvipohjainen, monitasoinen ja perusteellinen suojausratkaisu.

Power BI on luotu tarjoamaan alan johtava kattava ja hermeyttinen suojaus tiedoille. Tuote on ansainnut alan korkeimmat saatavilla olevat turvallisuusluokitukset, ja nykyään monet kansalliset turvallisuusvirastot, rahoituslaitokset ja terveydenhuollon palveluntarjoajat antavat sille kaikkein arkaluonteisimpia tietojaan.

Kaikki alkaa perustuksista. 2000-luvun alun kovan jakson jälkeen Microsoft teki valtavia investointeja tietoturva-aukkojensa korjaamiseksi, ja seuraavina vuosikymmeninä se rakensi vahvan suojauspinon, joka ulottuu yhtä syvälle kuin sirubiosytimen kone ja ulottuu aina loppukäyttäjäkokemuksiin asti. Nämä syväsijoitukset jatkuvat, ja nykyään yli 3 500 Microsoftin insinööriä on mukana rakentamassa ja parantamassa Microsoftin suojauspinoa ja aktiivista yhä muuttuvaa uhkamaisemaa. Miljardeja tietokoneita, biljoonia kirjautumisia ja lukemattomia zettabyts-tietoja, jotka on annettu Microsoftin suojaksi, yhtiöllä on nyt teknologiateollisuuden edistynein turvallisuuspino, ja sitä pidetään laajasti maailmanlaajuisena johtajana pahantahtoisten toimijoiden vastaisessa taistelussa.

Power BI perustuu tähän vahvaan perustaan. Se käyttää samaa suojauspinoa, joka ansaitsi Azurelle oikeuden palvella ja suojata maailman arkaluonteisimpia tietoja, ja se integroituu Microsoft 365:n edistyneimpiin tietosuoja- ja yhteensopivuustyökaluihin. Lisäksi se tarjoaa suojausta monikerroksisilla suojaustoimilla, mikä tarjoaa alusta loppuun suojauksen, joka on suunniteltu vastaamaan pilvipalvelun aikakauden ainutlaatuisiin haasteisiin.

Jotta arkaluontoisten resurssien suojaamiseen voidaan tarjota päästä päähän -ratkaisu, tuotetiimin oli käsiteltävä asiakkaiden haastavia huolenaiheita useilla samanaikaisilla rintamilla:

• Miten hallitaan, kuka voi muodostaa yhteyden, mistä yhteys muodostetaan ja miten yhteys muodostetaan? Miten yhteyksiä voidaan hallita?
• Miten tiedot tallennetaan? Miten se salataan? Mitä ohjausobjekteja tiedoillani on?
• Miten voin hallita ja suojata luottamuksellisia tietojani? Miten voin varmistaa, että näitä tietoja ei voi vuotaa organisaation ulkopuolelle?
• Miten voin valvoa, kuka suorittaa mitäkin toimintoja? Miten voin reagoida nopeasti, jos palvelussa on epäilyttävää toimintaa?

Tämä artikkeli sisältää kattavan vastauksen kaikkiin näihin kysymyksiin. Se alkaa yleiskatsauksella palveluarkkitehtuurista ja kertoo, miten järjestelmän tärkeimmät työnkulut toimivat. Sen jälkeen kuvaillaan, miten käyttäjät todentavat Power BI:ssä, miten tietoyhteyksiä muodostetaan ja miten Power BI tallentaa ja siirtää tietoja palvelun kautta. Viimeisessä osiossa käsitellään suojausominaisuuksia, joiden avulla voit palvelun järjestelmänvalvojana suojata arvokkaimpia resurssejasi.

Power BI -palveluun liittyvät Microsoftin verkkopalvelujen ehdot ja Microsoftin yritystietosuojalausunto. Tietojenkäsittelyn sijainti on Microsoftin verkkopalvelujen ehtojen ja tietojen suojauksen lisäyksen kohdassa Tietojen käsittelyn sijainti. Yhteensopivuuden lisätietojen osalta Microsoft Trust Center on ensisijainen resurssi Power BI:lle. Power BI -tiimi tekee kovasti töitä saadakseen asiakkaidensa käyttöön uusimmat innovaatiot ja tuottavuuden. Lue lisää Microsoftin yhteensopivuustarjonnan vaatimustenmukaisuudesta.

Power BI -palvelu noudattaa suojauskehityksen elinkaarta (SDL), joka on tiukoinen suojauskäytäntö, joka tukee suojauksen valvonta- ja yhteensopivuusvaatimuksia. SDL auttaa kehittäjiä kehittämään suojatumpia ohjelmistoja vähentämällä ohjelmistojen haavoittuvuuksien määrää ja vakavuutta ja pienentämällä samalla kehityskustannuksia. Lisätietoja on kohdassa Microsoftin turvallisuuskehityksen elinkaarikäytännöt.

Power BI -arkkitehtuuri

Power BI -palvelu perustuu Microsoftin pilvitekniikkaympäristöön Azureen. Power BI on tällä hetkellä käytössä useissa tietokeskuksissa ympäri maailmaa – tarjolla on useita aktiivisia käyttöönottoja, joita kyseisten tietokeskusten alueella toimivat asiakkaat voivat käyttää, ja yhtä monta passiivista käyttöönottoa, jotka toimivat kunkin aktiivisen käyttöönoton varmuuskopioina.

Verkon edustaklusteri (WFE)

WFE-klusteri tarjoaa käyttäjän selaimelle sivuston alkuperäisen HTML-sivun sisällön ja osoittimet CDN-sisältöön, jota käytetään sivuston hahmontamiseen selaimessa.

WFE-klusteri koostuu ASP.NET verkkosivustosta, joka toimii Azure-sovelluspalvelu-ympäristössä. Kun käyttäjät yrittävät muodostaa yhteyden Power BI -palveluun, asiakkaan DNS-palvelu voi olla yhteydessä Azure-liikennehallintaan sopivimman (yleensä lähimmän) palvelinkeskuksen löytämiseksi Power BI -käyttöönotossa. Lisätietoja tästä prosessista on artikkelissa Suorituskyvyn liikenteen reititysmenetelmä Azure-liikennehallinnalle.

Staattiset resurssit, kuten *.js, *.css ja kuvatiedostot, tallennetaan useimmiten Azure-sisältöverkkoon (CDN), ja ne noudetaan suoraan selaimesta. Huomaa, että maakohtaisissa julkishallinnon klusterikäyttöönotoissa on poikkeus tähän sääntöön ja yhteensopivuussyistä jätetään pois CDN ja käytetään sen sijaan yhteensopivan alueen WFE-klusteria staattisen sisällön isännöintiin.

Power BI -taustaklusteri (BE)

Taustaklusteri on kaikkien Power BI:ssä käytettävissä olevien toimintojen runko. Se koostuu useista Web Front End- ja API-asiakkaiden kuluttamista palvelun päätepisteistä sekä taustatyöpalveluista, tietokannoista, välimuistista ja useista muista osista.

Tausta on käytettävissä useimmilla Azure-alueilla, ja se otetaan käyttöön uusilla alueilla, kun ne tulevat saataville. Yhdellä Azure-alueella isännöidä yhtä tai useampaa taustaklusteria, jotka mahdollistavat Power BI -palvelun rajoittamattoman vaakasuuntaisen skaalauksen, kun yksittäisen klusterin pystysuorat ja vaakasuuntaiset skaalausrajoitukset on käytetty loppuun.

Jokainen taustaklusteri on tilallinen ja isännöi kaikkia kyseiseen klusteriin määritettyjen vuokraajien tietoja. Tietyn vuokraajan tietoja sisältävää klusteria kutsutaan vuokraajan kotiklusteriksi. Todennetun käyttäjän kotiklusterin tiedot tarjoaa yleinen palvelu, ja Web Front End käyttää niitä pyyntöjen reititykseen vuokraajan kotiklusteriin.

Jokainen taustaklusteri koostuu useista näennäiskoneista, jotka on yhdistetty useisiin mukautettavissa oleviin skaalattaviin joukkoihin, jotka on viritetty tiettyjen tehtävien suorittamista varten, tilallisia resursseja, kuten SQL-tietokantoja, tallennustilejä, palveluväylät, välimuistit ja muita tarvittavia pilvikomponentteja.

Vuokraajan metatiedot ja tiedot tallennetaan klusterin rajoituksiin lukuun ottamatta tietojen replikointia toissijaiseen taustaklusteriin paripohjaisella Azure-alueella samalla Azuren maantieteellisellä alueella. Toissijainen taustaklusteri toimii vikasietoisuuden klusterina alueellisen katkoksen varalta ja on passiivinen milloin tahansa.

Taustatoimintoa palvelevat klusterin näennäisverkon eri koneissa suoritettavat mikropalvelut, jotka eivät ole käytettävissä ulkopuolelta, lukuun ottamatta kahta osaa, joita voidaan käyttää julkisesta Internetistä:

• Yhdyskäytäväpalvelu
• Azuren API-hallinta

Power BI Premium -infrastruktuuri

Power BI Premium tarjoaa palvelun tilaajille, jotka tarvitsevat Power BI:n premium-ominaisuuksia, kuten edistyneen tekoälyn, jakelun lisensoimattomille käyttäjille jne. Kun asiakas rekisteröityy Power BI Premium -tilausta varten, Premium-kapasiteetti luodaan Azure Resource Managerin kautta.

Power BI Premium -kapasiteetteja isännöidään taustaklustereissa, jotka ovat riippumattomia tavallisesta Power BI -taustasta – ks. yllä). Tämä mahdollistaa premium-tuotteen paremman eristämisen, resurssien kohdistuksen, tuettavuuden, suojauksen eristämisen ja skaalattavuuden.

Seuraava kaavio havainnollistaa Power BI Premium -infrastruktuurin arkkitehtuuria:

Yhteys Power BI Premium -infrastruktuuriin voidaan tehdä monella tavalla käyttäjäskenaarion mukaan. Power BI Premium -asiakkaat voivat olla käyttäjän selain, tavallinen Power BI -tausta, suorat yhteydet XMLA-asiakkaiden, ARM-ohjelmointirajapintojen kautta jne.

Azure-alueen Power BI Premium -infrastruktuuri koostuu useista Power BI Premium -klustereista (pienin arvo on yksi). Useimmat Premium-resurssit on kapseloitu klusterin sisälle (esimerkiksi käsittely), ja on olemassa joitain yhteisiä alueellisia resursseja (esimerkiksi metatietojen tallennus). Premium-infrastruktuurin avulla voit saavuttaa alueella horisontaalisen skaalattavuuden kahdella tavalla: lisäämällä resursseja klustereiden sisällä ja/tai lisäämällä klustereita tarvittaessa (jos klusteriresurssit lähestyvät rajojaan).

Kunkin klusterin runko ovat Virtual Machine Scale Setsin ja Azure Service Fabricin hallitsemat käsittelyresurssit. Virtual Machine Scale Sets ja Service Fabric mahdollistavat tietokonesolmujen nopean ja vaivattoman kasvun käytön kasvaessa ja hallitessa Power BI Premium -palveluiden ja -sovellusten käyttöönottoa, hallintaa ja seurantaa.

On olemassa useita ympäröiviä resursseja, jotka takaavat turvallisen ja luotettavan infrastruktuurin: kuormituksentasain, näennäisverkot, verkon käyttöoikeusryhmät, palveluväylän, tallennustilan jne. Power BI Premiumin edellyttämiä salaisuuksia, avaimia ja varmenteita hallitsee vain Azure Key Vault . Mikä tahansa todentaminen tehdään integroimalla Microsoft Entra -tunnus yksinomaan.

Kaikki Power BI Premium -infrastruktuuriin tulevat pyynnöt menevät ensin edustasolmuihin – ne ovat ainoita ulkoisille yhteyksille käytettävissä olevia solmuja. Muut resurssit on piilotettu näennäisverkkojen taakse. Edustasolmut todentavat pyynnön, käsittelevät sitä tai välittää sen asianmukaisiin resursseihin (esimerkiksi taustasolmuihin).

Taustasolmut tarjoavat suurimman osan Power BI Premiumin ominaisuuksista ja ominaisuuksista.

Power BI Mobile

Power BI Mobile on kokoelma sovelluksia, jotka on suunniteltu kolmea ensisijaista mobiiliympäristöä varten: Android, iOS ja Windows (UWP). Power BI -mobiilisovellusten suojausta tulee harkita kahdesta luokasta:

• Laitteiden välinen tietoliikenne
• Laitteessa olevat sovellukset ja tiedot

Laitteiden tiedonsiirrossa kaikki Power BI -mobiilisovellukset ovat yhteydessä Power BI -palveluun sekä käyttävät samaa yhteyttä ja käyttöoikeuksien tarkistussekvenssejä kuin selaimet; nämä on kuvattu tarkemmin aiemmin tässä raportissa. Power BI:n iOS- ja Android-mobiilisovellukset tuovat selainistunnon itse sovellukseen, kun taas Windows-mobiilisovellus ottaa käyttöön välittäjän, joka muodostaa viestintäkanavan Power BI:n kanssa (kirjautumisprosessia varten).

Seuraavassa taulukossa esitetään Power BI Mobilen varmennepohjainen todennus (CBA) -tuki mobiililaiteympäristön mukaan:

CBA-tuki	iOS	Android	Ikkunat
Power BI (palveluun kirjautuminen)	Tuettu	Tuettu	Ei tueta
Paikallinen SSRS-ADFS (yhteys SSRS-palvelimeen)	Ei tueta	Tuettu	Ei tueta
SSRS-sovellusvälityspalvelin	Tuettu	Tuettu	Ei tueta

Power BI Mobile -sovellukset ovat aktiivisesti yhteydessä Power BI -palvelun kanssa. Telemetrian avulla kerätään mobiilisovelluksen käyttötilastoja ja vastaavaa tietoa, jotka toimitetaan palveluihin, joilla valvotaan käyttöä ja aktiivisuutta. telemetrian yhteydessä ei lähetetä asiakastietoja.

Power BI -sovellus tallentaa tietoja laitteeseen, joka helpottaa sovelluksen käyttöä:

• Microsoft Entra -tunnukset ja päivitystunnukset tallennetaan laitteessa suojattuun mekanismiin käyttämällä alan vakiomuotoisia suojausmenetelmiä.
• Tiedot ja asetukset (käyttäjän määrityksen avain-arvoparit) tallennetaan laitteen tallennustilaan, ja ne voidaan salata käyttöjärjestelmässä. iOS:ssä tämä tehdään automaattisesti, kun käyttäjä asettaa tunnuskoodin. Androidissa tämä voidaan määrittää asetuksissa. Windowsissa se tehdään BitLockerilla.
• Android- ja iOS-sovellusten tiedot ja asetukset (käyttäjän määrityksen avain-arvoparit) tallennetaan laitteen tallennustilaan eristyksessä ja sisäisessä tallennustilassa, jota voivat käyttää vain sovellus. Windows-sovelluksessa tiedot ovat vain käyttäjän (ja järjestelmänvalvojan) käytettävissä.
• Käyttäjä ottaa maantieteellisen paikan käyttöön tai poistaa sen käytöstä erikseen. Jos toiminto on käytössä, paikannustietoja ei tallenneta laitteeseen eikä tietoja jaeta Microsoftin kanssa.
• Käyttäjä ottaa ilmoitukset käyttöön tai poistaa ne käytöstä erikseen. Jos käytössä, Android ja iOS eivät tue ilmoitusten maantieteellisten tietojen sijaintivaatimuksia.

Tietojen salausta voidaan parantaa käyttämällä tiedostotason salausta Microsoft Intune -ohjelmistopalvelun kautta, joka tarjoaa mobiililaitteiden ja sovellusten hallinnan. Kaikki kolme ympäristöä, joissa Power BI Mobile on saatavilla, tukevat Intunea. Kun Intune on otettu käyttöön ja määritetty, mobiililaitteen tiedot salataan eikä itse Power BI -sovellusta voi asentaa SD-korttiin. Lue lisää Microsoft Intunesta.

Windows-sovellus tukee myös Windows Information Protectionia (WIP).

Tunnuspohjaiseen todentamiseen liittyvät suojatut tallennusarvot ovat käytettävissä muissa Microsoftin ensimmäisen osapuolen sovelluksissa (kuten Microsoft Authenticator) ja niitä hallitsee Microsoftin todentamiskirjasto (MSAL).

Power BI Mobilen välimuistiin tallennetut tiedot poistetaan, kun sovellus poistetaan, kun käyttäjä kirjautuu ulos Power BI Mobilesta tai kun käyttäjä ei onnistu kirjautumaan sisään (esimerkiksi tunnuksen vanhentumistapahtuman tai salasanan vaihtamisen jälkeen). Välimuisti sisältää koontinäytöt ja raportit, joita on aiemmin käytetään Power BI -mobiilisovelluksesta.

Power BI Mobile ei käytä laitteen muita sovelluskansioita tai tiedostoja.

Power BI:n iOS- ja Android-sovellusten avulla voit suojata tiedot määrittämällä lisätunnin, kuten Face ID:n, Touch ID:n tai iOS-tunnuskoodin sekä androidin biometriset tiedot (sormenjälkitunnuksen). Lue lisätietoja lisätunnuksista.

Todentaminen Power BI -palvelussa

Käyttäjän todentaminen Power BI -palvelussa koostuu pyynnöistä, vastauksista ja uudelleenohjauksista käyttäjän selaimen ja Power BI -palvelun tai Power BI:n käyttämien Azure-palveluiden välillä. Kyseinen vaihe kuvaa käyttäjän todentamisprosessia Power BI:ssä, joka noudattaa Microsoft Entra -todennuskoodin myöntämisen työnkulkua. Lisätietoja organisaation käyttäjien todentamismallien (kirjautumismallien) vaihtoehdoista on kohdassa Microsoft 365 -kirjautumismallin valitseminen.

Todentamisjakso

Power BI -palvelun käyttäjän todentamisjakso tapahtuu seuraavissa vaiheissa kuvatulla tavalla, ja vaiheet on kuvattu niitä seuraavassa kuvassa.

1. Käyttäjä käynnistää yhteyden Power BI -palveluun selaimesta joko kirjoittamalla osoiteriville Power BI -osoitteen tai valitsemalla Power BI:n markkinointisivulta (https://powerbi.microsoft.com). Yhteys muodostetaan TLS: n ja HTTPS: n avulla, ja kaikki myöhempi tietoliikenne selaimen ja Power BI -palvelun välillä käyttää HTTPS:ää.

2. Azure-liikennehallinta tarkistaa käyttäjän DNS-tietueen ja määrittää sopivimman (yleensä lähimmän) palvelinkeskuksen, jossa Power BI otetaan käyttöön, ja vastaa DNS:ään sen WFE-klusterin IP-osoitteella, johon käyttäjä tulee lähettää.

3. WFE palauttaa sitten selainasiakkaaseen HTML-sivun, joka sisältää MSAL.js-kirjastoviittauksen, jota tarvitaan kirjautumistyönkulun aloittamiseen.

4. Selainasiakas lataa WFE:ltä vastaanotetun HTML-sivun ja ohjaa käyttäjän Microsoft Online Services -kirjautumissivulle.

5. Kun käyttäjä on todennettu, kirjautumissivu ohjaa käyttäjän takaisin Power BI:n WFE-sivulle todennuskoodilla.

6. Selainasiakas lataa HTML-sivun ja pyytää todennuskoodin avulla tunnuksia (käyttöoikeus, tunnus, päivitys) Microsoft Entra -tunnuksesta.

7. Selainasiakas käyttää käyttäjän vuokraajatunnusta kyselyn aikana Power BI:n yleiseen palveluun, joka ylläpitää vuokraajien luetteloa ja vuokraajien Power BI -taustaklusterien sijainteja. Power BI:n yleinen palvelu määrittää, mikä Power BI -taustapalvelun klusteri sisältää käyttäjän vuokraajan, ja palauttaa Power BI -taustaklusterin URL-osoitteen takaisin asiakkaaseen.

8. Asiakas voi nyt viestiä Power BI -klusterin URL-ohjelmointirajapinnan kanssa käyttämällä HTTP-pyyntöjen Valtuutus-otsikon käyttöoikeustietuetta. Microsoft Entra -käyttöoikeustietueessa on vanhentumispäivä Microsoft Entran käytäntöjen mukaisesti, ja nykyisen istunnon säilyttämiseksi käyttäjän selaimessa oleva Power BI -asiakasohjelma tekee säännöllisiä pyyntöjä käyttöoikeustietueen uusimiseksi ennen sen vanhenemista.

Harvinaisissa tapauksissa, joissa asiakaspuolen todennus epäonnistuu odottamattoman virheen vuoksi, koodi yrittää palata käyttämään palvelinpuolen todennusta WFE:ssä. Lisätietoja palvelinpuolen todentamisen työnkulusta on tämän asiakirjan lopussa olevassa Kysymykset ja vastaukset -osassa.

Tietojen sijainti

Ellei dokumentaatiossa ole toisin mainittu, Power BI tallentaa asiakastiedot Azuren maantieteellisellä alueella, joka määritetään, kun Microsoft Entra -vuokraaja rekisteröityy Power BI -palveluihin ensimmäistä kertaa. Microsoft Entra -vuokraaja säilyttää käyttäjän ja sovelluksen käyttäjätiedot, ryhmät ja muut olennaiset tiedot, jotka liittyvät organisaatioon ja sen suojaukseen.

Azuren maantieteellisen alueen määrittäminen vuokraajan tietojen tallennusta varten tehdään yhdistämällä Maa tai alue, joka on valittu osana Microsoft Entra -vuokraajan määritystä, sopivimpaan Azure-maantieteelliseen alueeseen, jossa Power BI -käyttöönotto on. Kun tämä määritys on tehty, kaikki Power BI:n asiakastiedot tallennetaan tälle valitulle Azuren maantieteelliselle alueelle (tunnetaan myös kotimaantieteenä), lukuun ottamatta tapauksia, joissa organisaatiot hyödyntävät multi-geo-käyttöönottoja.

Useita alueita (Multi-Geo)

Joillakin organisaatioilla on yleinen läsnäolo ja ne saattavat vaatia Power BI -palveluita useilla Azuren maantieteellisillä alueilla. Yrityksen pääkonttori voi olla esimerkiksi Yhdysvalloissa, mutta se voi harjoittaa liiketoimintaa myös muilla maantieteellisillä alueilla, kuten Australiassa. Tällaisissa tapauksissa yritys voi vaatia, että tietyt Power BI -tiedot säilytetään levossa etäalueella paikallisia säädöksiä noudattaen. Tätä Power BI -palvelun ominaisuutta kutsutaan Multi-Geoksi.

Kyselyn suorituskerros, kyselyn välimuistit ja Multi-Geo-työtilaan määritetyt artefaktitiedot isännöidään, ja ne pysyvät Azuren maantieteellisellä etäkapasiteetilla. Jotkin artefaktin metatiedot, kuten raporttirakenne, saattavat kuitenkin jäädä lepäämään vuokraajan kotialueen sijaintitietoihin. Lisäksi osa tietojen siirrosta ja käsittelystä voi edelleen tapahtua vuokraajan kotiympäristössä myös työtiloissa, joita isännöidään Multi-Geo Premium -kapasiteetissa.

Lisätietoja Power BI -käyttöönottojen luomisesta ja hallinnasta useilla Azuren maantieteellisillä alueilla on artikkelissa Power BI Premiumin Multi-Geo-tuen määrittäminen.

Alueet ja palvelinkeskukset

Power BI -palvelut ovat saatavilla tietyillä Azuren maantieteellisillä alueilla Microsoft Trust Centerissä kuvatulla tavalla. Lisätietoja siitä, mihin tietosi tallennetaan ja miten niitä käytetään, on Microsoft Trust Centerissä. Sitoumukset levossa säilytettävien asiakastietojen sijainnista määritetään kohdassa Tietojenkäsittelyehdot verkkopalvelujen ehdoissa.

Microsoft tarjoaa palvelinkeskuksia myös maakohtaisille entiteeteille. Lisätietoja Power BI -palvelun käytettävyydestä kansallisissa/alueellisissa pilvipalveluissa on artikkelissa Power BI:n kansalliset/alueelliset pilvipalvelut.

Tietojen käsittely

Tässä osiossa esitellään Power BI:n tietojenkäsittelykäytännöt asiakastietojen tallentamisessa, käsittelyssä ja siirtämisessä.

Levossa säilytettävät tiedot

Power BI käyttää kahta ensisijaista tietojen tallennusresurssityyppiä:

• Azure-tallennus
• Microsoft Azuren SQL-tietokanta

Useimmissa skenaarioissa Azure-tallennus käytetään Power BI -artefaktien tietojen säilymiseen, kun taas Azure SQL -tietokantoja käytetään artefaktin metatietojen säilymiseen.

Kaikki Power BI:n säilyvät tiedot salataan oletusarvoisesti Microsoftin hallitsemilla avaimilla. Azure SQL -tietokantoihin tallennetut asiakastiedot salataan täysin käyttämällä Azure SQL:n TDE (Transparent Data Encryption) -tekniikkaa. Azure Blob -säilöön tallennetut asiakastiedot salataan Azure-tallennus salauksella.

Vaihtoehtoisesti organisaatiot voivat käyttää Power BI Premiumia omien avaimien avulla lepäävien tietojen salaamiseen semanttiseen malliin tuotujen tietojen salaamiseen. Tätä menetelmää kuvataan usein nimellä Bring your own key (BYOK). BYOK:n käyttö auttaa varmistamaan, että palveluoperaattorin virhetilanteessa asiakastietoja ei näytetä – mikä ei ole helppoa läpinäkyvää palvelupuolen salausta käyttämällä. Lisätietoja on artikkelissa Omien salausavainten tuominen Power BI :hin.

Power BI:n semanttiset mallit mahdollistavat erilaisia tietolähteen yhteystiloja, jotka määrittävät, pysyvätkö tietolähdetiedot palvelussa vai eivät.

Semanttinen mallitila (laji)	Power BI:ssä säilyneet tiedot
Tuo	Kyllä
DirectQuery	En
Reaaliaikainen yhteys	En
Komposiitti	Jos sisältää tuonnin tietolähteen
Suoratoisto	Jos on määritetty pysyväksi

Käytetystä semanttisesta mallitilasta riippumatta Power BI voi tilapäisesti tallentaa noudetut tiedot välimuistiin kyselyn ja raportin lataamisen suorituskyvyn optimoimiseksi.

Tietoja käsitellään

Tietoja käsitellään, kun yksi tai useampi käyttäjä käyttää niitä aktiivisesti osana vuorovaikutteista skenaariota tai kun näitä tietoja käsitellään taustaprosessissa, kuten päivityksessä. Power BI lataa aktiivisen käsittelyn tiedot yhden tai useamman huoltokuormituksen muistitilaan. Kuormituksen vaatiman toiminnon helpottamiseksi muistissa olevia käsiteltyjä tietoja ei salata.

Tietoja siirretään

Power BI edellyttää, että kaikki saapuva HTTP-liikenne salataan käyttäen TLS 1.2:ta tai uudempaa. Kaikki pyynnöt, jotka yrittävät käyttää palvelua TLS 1.1:n tai tätä pienemmän suojauksen kanssa, hylätään.

Todentaminen tietolähteissä

Kun muodostat yhteyden tietolähteeseen, käyttäjä voi tuoda kopion tiedoista Power BI:hin tai muodostaa yhteyden suoraan tietolähteeseen.

Tuonnin yhteydessä käyttäjä muodostaa yhteyden käyttäjän sisäänkirjautumisen perusteella ja käsittelee tietoja tunnistetiedoilla. Kun semanttinen malli on julkaistu Power BI -palveluun, Power BI käyttää aina tämän käyttäjän tunnistetietoja tietojen tuomiseen. Kun tiedot on tuotu, tietojen tarkasteleminen raporteissa ja koontinäytöissä ei käytä pohjana olevaa tietolähdettä. Power BI tukee kertakirjautumistodennusta valituille tietolähteille. Jos yhteys on määritetty käyttämään kertakirjautumista, tietolähteeseen muodostetaan yhteys semanttisen mallin omistajan tunnistetiedoilla.

Jos tietolähde on yhdistetty suoraan esimääritetyillä tunnistetiedoilla, esimääritettyjä tunnistetietoja käytetään yhteyden muodostamiseen tietolähteeseen, kun käyttäjä tarkastelee tietoja. Jos tietolähde on yhdistetty suoraan kertakirjautumisen avulla, nykyisen käyttäjän tunnistetietoja käytetään yhteyden muodostamiseen tietolähteeseen, kun käyttäjä tarkastelee tietoja. Kertakirjautumista käytettäessä rivitason suojaus (RLS) ja/tai objektitason suojaus (OLS) voidaan ottaa käyttöön tietolähteessä. Näin käyttäjät voivat tarkastella vain tietoja, joihin heillä on oikeudet. Kun yhteys on pilvipalvelussa sijaitseviin tietolähteisiin, Microsoft Entra -todennusta käytetään kertakirjautumista varten. Paikallisia tietolähteitä, Kerberosta, Security Assertion Markup Languagea (SAML) ja Microsoft Entra ID:tä tuetaan.

Jos tietolähde on Azure Analysis Services tai paikallinen Analysis Services ja RLS ja/tai OLS on määritetty, Power BI -palvelu käyttää kyseisen rivitason suojausta ja käyttäjät, joilla ei ole riittävästi tunnistetietoja pohjana olevien tietojen käyttämiseen (esimerkiksi koontinäytössä, raportissa tai muussa tieto-artefaktissa käytetty kysely), eivät näe tietoja, joihin heillä ei ole riittäviä käyttöoikeuksia.

Premium-ominaisuudet

Tietovoiden arkkitehtuuri

Tietovoiden avulla käyttäjät voivat määrittää taustatietojen käsittelytoimintoja, jotka poimivat tietoja polymorfisia tietolähteistä, suorittavat muunnoslogiikkaa tiedoille ja päätyvät sitten kohdemalliin käytettäväksi erilaisissa raportointiesitystekniikoissa. Kuka tahansa käyttäjä, jolla on joko jäsenen, osallistujan tai järjestelmänvalvojan rooli työtilassa, voi luoda tietovuon. Katselijan roolissa olevat käyttäjät voivat tarkastella tietovuon käsittelemiä tietoja, mutta he eivät välttämättä tee muutoksia sen kokoonpanoon. Kun tietovuo on luotu, kuka tahansa työtilan jäsen, osallistuja tai järjestelmänvalvoja voi ajoittaa päivitykset sekä tarkastella ja muokata tietovuota ottamalla sen omistajuuden.

Jokainen määritetty tietolähde on sidottu asiakastekniikkaan kyseisen tietolähteen käyttöä varten. Niiden käyttämiseen tarvittavien tunnistetietojen rakenne muotoillaan vastaamaan tietolähteen vaadittuja toteutustietoja. Power Query -palvelut soveltavat muunnoslogiikkaa, kun tiedot ovat lennossa. Premium-tietovoissa Power Query -palvelut suoritetaan taustasolmuissa. Tiedot voidaan noutaa suoraan pilvilähteistä tai paikallisesti asennetun yhdyskäytävän kautta. Kun siirto noudetaan suoraan pilvipalvelulähteestä palveluun tai yhdyskäytävään, se käyttää soveltuvissa tapauksissa asiakastekniikkaan liittyviä suojausmenetelmiä. Kun tietoja siirretään yhdyskäytävästä pilvipalveluun, ne salataan. Katso yllä oleva Tiedot siirrossa -osio.

Kun asiakkaan määrittämät tietolähteet edellyttävät tunnistetietoja käyttöä varten, tietovuon omistaja/tekijä antaa ne luonnin aikana. Ne tallennetaan käyttämällä tuotteen laajuista perustunnistetietojen tallennustilaa. Katso yllä oleva Todennus tietolähteissä -osio. Käyttäjät voivat määrittää useita eri menetelmiä tietojen pysyvyyden ja käytön optimoimiseksi. Oletusarvoisesti tiedot sijoitetaan Power BI:n omistamalle ja suojatulle tallennustilille. Tallennustilan salaus on käytössä Blob-säilöissä tietojen suojaamiseksi levossa. Katso alla oleva Tiedot levossa -osio. Käyttäjät voivat kuitenkin määrittää oman Azure-tilaukseensa liittyvän tallennustilinsä. Tällöin Power BI -palvelun päänimelle myönnetään käyttöoikeus kyseiseen tallennustiliin, jotta se voi kirjoittaa tiedot sinne päivityksen aikana. Tässä tapauksessa tallennustilan resurssin omistaja on vastuussa salauksen määrittämisestä määritetylle ADLS-tallennustilille. Tiedot siirretään aina Blob-säilöön salauksen avulla.

Koska joidenkin tietojen suorituskyky saattaa olla joidenkin tietojen kannalta epäoptimaalinen, käyttäjät voivat myös käyttää Power BI -isännöimää laskentamoduulia suorituskyvyn parantamiseksi. Tässä tapauksessa tiedot tallennetaan tarpeettomasti SQL-tietokantaan, joka on DirectQueryn käytettävissä tausta Power BI -järjestelmän käytön kautta. Tiedot salataan aina tiedostojärjestelmässä. Jos käyttäjä antaa avaimen SQL-tietokantaan tallennettujen tietojen salaamiseen, kyseistä avainta käytetään sen salaamiseen kaksin verroin.

Kun kysely tehdään DirectQueryllä, ohjelmointirajapinnan käyttämiseen käytetään salattua HTTPS-siirtoprotokollaa. DirectQueryn kaikkea toissijaista tai epäsuoraa käyttöä hallitaan samoilla käyttöoikeuksien valvonnilla, jotka kuvattiin aiemmin. Koska tietovuot on aina sidottu työtilaan, tietojen käyttöoikeus perustuu aina käyttäjän rooliin kyseisessä työtilassa. Käyttäjällä on oltava vähintään lukuoikeus, jotta hän voi kysellä tietoja millä tahansa tavalla.

Kun Power BI Desktopilla käsitellään tietovuon tietoja, käyttäjä on ensin todennettava Microsoft Entra -tunnuksen avulla sen määrittämiseksi, onko käyttäjällä riittävät oikeudet tietojen tarkasteluun. Jos näin on, SaS-avain hankitaan ja sitä käytetään tallennukseen suoraan salatulla HTTPS-siirtoprotokollalla.

Koko jakson tietojen käsittely aiheuttaa Office 365:n valvontatapahtumia. Jotkin näistä tapahtumista tallentavat tietoturvaan ja tietosuojaan liittyviä toimintoja.

sivuerotellut raportit

Sivutetut raportit on suunniteltu tulostettaviksi tai jaettaviksi. Niitä kutsutaan sivutetuiksi, koska ne on muotoiltu sopimaan hyvin sivulle. Ne näyttävät kaikki tiedot taulukossa, vaikka taulukko olisi useita sivuja pitkä. Voit hallita tarkasti niiden asettelua raportin sivulla.

Sivutetut raportit tukevat Microsoft Visual Basic .NET:illä kirjoitettuja monipuolisia ja tehokkaita lausekkeita. Lausekkeita käytetään yleisesti Power BI:n raporttien muodostimessa tietojen noutamiseen, laskemiseen, näyttämiseen, ryhmittelyun, lajitteluun, suodattamiseen, parametrisoitumiseen ja muotoiluun.

Lausekkeet luo raportin tekijä, ja sillä on käyttöoikeus moniin .NET Frameworkin ominaisuuksiin. Sivutettujen raporttien käsittely ja suorittaminen suoritetaan eristyksen sisällä.

Sivutettujen raporttien määritykset (.rdl) tallennetaan Power BI:hin, ja sivutetun raportin julkaisemiseksi ja/tai hahmontamiseksi käyttäjän on todennettava ja valtuutettava samalla tavalla kuin yllä olevassa Power BI -palvelun todentaminen -osiossa on kuvattu.

Todennuksen aikana saatua Microsoft Entra -tunnusta käytetään viestimään suoraan selaimesta Power BI Premium -klusteriin.

Power BI Premiumissa Power BI -palvelun suorituspalvelu tarjoaa jokaiselle raportin hahmonnmiselle asianmukaisesti eristetyn suoritusympäristön. Tämä koskee myös tapauksia, joissa hahmonnetut raportit kuuluvat samaan kapasiteettiin määritettyihin työtiloihin.

Sivutetulla raportilla voidaan käyttää laaja joukkoa tietolähteitä osana raportin hahmontamista. Eristys ei viesti suoraan minkään tietolähteen kanssa, vaan se viestii luotettavan prosessin kanssa tietojen pyytämiseksi, minkä jälkeen luotettu prosessi liittää tarvittavat tunnistetiedot yhteyteen. Tällä tavalla eristyksessä ei koskaan ole tunnistetietojen tai salaisten tietojen käyttöoikeutta.

Eristys käyttää Internetiä tukeakseen ominaisuuksia, kuten Bing -karttoja tai Azure-funktiot -kutsuja.

Upotettu Power BI -analytiikka

Itsenäisillä ohjelmistotoimittajilla ja -ratkaisujen tarjoajilla on kaksi päätilaa Power BI -artefaktien upottamiseen verkkosovelluksiin ja portaaleihin: upottaminen organisaatiollesi ja upottaminen asiakkaillesi. Artefakti upotetaan IFrameen sovelluksessa tai portaalissa. IFrame ei saa lukea tai kirjoittaa tietoja ulkoisesta verkkosovelluksesta tai portaalista, ja viestintä IFramen kanssa tehdään käyttämällä Power BI -asiakas-SDK:ta POST-viestien avulla.

Microsoft Entra -käyttäjät käyttävät omaa Power BI -sisältöään organisaatiosi käyttöön upottamisen yhteydessä yritystensä ja IT-palveluidensa mukauttamien portaaleihin. Kaikki tässä raportissa kuvatut Power BI -käytännöt ja -ominaisuudet, kuten rivitason suojaus (RLS) ja objektitason suojaus (OLS), otetaan automaattisesti käyttöön kaikille käyttäjille riippumatta siitä, käyttävätkö he Power BI:tä Power BI -portaalin vai mukautettujen portaalien kautta.

Upottaminen asiakkaillesi -skenaariossa itsenäiset ohjelmistotoimittajat omistavat yleensä Power BI -vuokraajia ja Power BI -kohteita (koontinäytöt, raportit, semanttiset mallit ja muut). ISV-taustapalvelun vastuulla on todentaa loppukäyttäjät ja päättää, mitkä artefaktit ja mikä käyttöoikeustaso sopii kyseiselle käyttäjälle. ISV-käytäntöpäätökset salataan Power BI:n luomassa upotustunnuksella ja välitetään ISV-taustalle, jotta ne voidaan jakaa edelleen käyttäjille ISV:n liiketoimintalogiikan mukaisesti. Selaimen tai muiden asiakassovellusten käyttäjät eivät voi purkaa tai muokata upotustunnuksia. Client-side SDK:t, kuten Power BI -asiakasohjelman ohjelmointirajapinnat , liittävät salatun upotustunnuksen automaattisesti Power BI -pyyntöihin valtuutustietona : EmbedToken-otsikko . Tämän ylätunnisteen perusteella Power BI valvoo kaikkien käytäntöjen (kuten käyttöoikeuden tai rivitason suojauksen) tarkasti sellaisena kuin ISV on määrittänyt luonnin aikana.

Upottamisen ja automatisoinnin mahdollistamiseksi ja yllä kuvattujen upotustunnusten luomiseksi Power BI näyttää monipuolisen joukon REST-ohjelmointirajapintoja. Nämä Power BI REST -ohjelmointirajapinnat tukevat sekä käyttäjän delegointia että palvelun päänimeä Microsoft Entran todentamis- ja valtuutusmenetelmiä.

Upotettu Power BI -analytiikka ja sen REST-ohjelmointirajapinnat tukevat kaikkia tässä artikkelissa kuvattuja Power BI -verkon eristystoimintoja: esimerkiksi palvelutunnisteita ja yksityisiä linkkejä.

Tekoälyominaisuudet

Power BI tukee tällä hetkellä tuotteessa kahta laajaa tekoälyominaisuuksien luokkaa: tekoälyvisualisointeja ja tekoälyn täydennyksiä. Visualisointitason tekoälyominaisuudet sisältävät ominaisuuksia, kuten tärkeimmät vaikuttajat, hajotuspuu, älykäs kertomus, poikkeamien tunnistaminen, R-visualisointi, Python-visualisointi, klusterointi, ennustaminen, Q&A, nopeat merkitykselliset tiedot jne. Tekoälyn rikastusominaisuudet sisältävät ominaisuuksia, kuten automaattianalyysipalvelut, Azure Machine Learning, cognitiveServices-, R/Python-muunnokset jne.

Suurin osa edellä mainituista ominaisuuksista on tuettu sekä jaetuissa että Premium-työtiloissa tällä hetkellä. Automaattianalyysipalveluita ja CognitiveServices-palveluita tuetaan kuitenkin vain Premium-työtiloissa IP-rajoitusten vuoksi. Tällä hetkellä käyttäjä voi Power BI:n automaattianalyysipalveluiden integroinnin myötä luoda ja harjoittaa mukautetun koneoppimismallin (esimerkiksi ennuste, luokitus, regressio jne.) ja käyttää sitä ennusteiden noutamiseen ladattaessa tietoja Premium-työtilassa määritettyyn tietovuohon. Lisäksi Power BI -käyttäjät voivat käyttää useita CognitiveServices-ohjelmointirajapintoja, kuten TextAnalytics ja ImageTagging, tietojen muuntamiseen ennen niiden lataamista Premium-työtilassa määritettyyn tietovuohon tai semanttiseen malliin.

Premium-tekoälyn täydennysominaisuudet voidaan parhaiten pitää kokoelmana tilattomia tekoälyfunktioita tai muunnoksia, joita Power BI -käyttäjät voivat käyttää tietojen integrointijaksoissa, joita Power BI:n semanttinen malli tai tietovuo voi käyttää. Huomaa, että näitä funktioita voi käyttää myös nykyisten tietovoiden tai semanttisen mallin luontiympäristöjen kautta Power BI -palvelussa ja Power BI Desktopissa. Nämä tekoälyfunktiot/muunnokset suoritetaan aina Premium-työtilassa/kapasiteetissa. Nämä funktiot tuodaan power BI:ssä esiin tietolähteenä, joka edellyttää Microsoft Entra -tunnusta tekoälytoimintoa käyttävälle Power BI -käyttäjälle. Nämä tekoälytietolähteet ovat erityisiä, koska ne eivät näytä mitään omista tiedoistaan ja ne toimittavat vain nämä funktiot tai muunnokset. Suorituksen aikana nämä ominaisuudet eivät tee lähteviä kutsuja muihin palveluihin asiakkaan tietojen välittämistä varten. Tutustutaanpa Premium-skenaarioihin yksitellen, jotta voimme ymmärtää niihin liittyvät viestintätavat ja niihin liittyvät tietoturvaan liittyvät tiedot.

Automaattianalyysipalvelumallin harjoittamisessa ja käytössä Power BI käyttää Azure AutoML SDK:ta ja suorittaa kaiken koulutuksen asiakkaan Power BI -kapasiteetissa. Harjoittamisen iteroinnin aikana Power BI kutsuu kokeilua Azure Machine Learning -palveluksi sopivan mallin ja hyperparametrien valitsemiseksi nykyiselle iteraatiolle. Tässä lähtevän kutsun yhteydessä lähetetään vain oleelliset kokeilun metatiedot (esimerkiksi tarkkuus, koneoppimisalgoritmi, algoritmiparametrit jne.) edellisestä iteraatiosta. Automaattianalyysipalveluiden koulutus tuottaa ONNX-mallin ja harjoittamisen raporttitiedot, jotka tallennetaan sitten tietovuohon. Myöhemmin Power BI -käyttäjät voivat käyttää harjoitettua koneoppimismallia muunnoksena koneoppimismallin ajoitetusti operationalisoimiseksi. TextAnalytics- ja ImageTagging-ohjelmointirajapinnoille Power BI ei kutsu suoraan CognitiveServices-palvelun ohjelmointirajapintoja vaan käyttää sisäistä SDK:ta ohjelmointirajapintojen suorittamiseen Power BI Premium -kapasiteetissa. Nykyään näitä ohjelmointirajapintoja tuetaan sekä Power BI -tietovoissa että semanttisissa malleissa. Tietomallin luomisen aikana Power BI Desktopissa käyttäjät voivat käyttää tätä toimintoa vain, jos heillä on käyttöoikeus Premium Power BI -työtilaan. Siksi asiakkaita kehotetaan antamaan Microsoft Entra -tunnistetietonsa.

Verkon eristäminen

Tässä osiossa esitellään Power BI:n suojauksen lisäominaisuudet. Joillakin ominaisuuksilla on tiettyjä käyttöoikeusvaatimuksia. Katso lisätietoja alla olevasta osiosta.

Palvelutunnisteet

Palvelutunniste tarkoittaa tietyn Azure-palvelun IP-osoitteiden etuliitteiden ryhmää. Se auttaa minimoimaan verkon suojaussääntöjen usein päivitysten monimutkaisuuden. Asiakkaat voivat käyttää palvelutunnisteita verkkokäytön hallinnan määrittämiseen verkon käyttöoikeusryhmissä tai Azure-palomuuri. Asiakkaat voivat käyttää palvelutunnisteita tiettyjen IP-osoitteiden asetuksissa suojaussääntöjä luodessaan. Määrittämällä palvelutunnisteen nimen (kuten PowerBI) säännön sopivaan lähde- tai kohdekenttään (ohjelmointirajapinnoille) asiakkaat voivat sallia tai kieltää liikenteen vastaavassa palvelussa. Microsoft hallitsee palvelutunnisteen sisältämiä osoiteetuliitteitä ja päivittää automaattisesti palvelutunnisteen, kun osoitteet muuttuvat.

Yksityisen linkin integrointi

Azure-verkkopalvelut tarjoavat Azuren yksityisen linkin, jonka avulla Power BI voi tarjota suojatun käytön Azure-verkkopalveluiden yksityisten päätepisteiden kautta. Azuren yksityisen linkin ja yksityisten päätepisteiden avulla tietoliikenne lähetetään yksityisesti käyttämällä Microsoftin runkoverkon infrastruktuuria, jolloin tiedot eivät kulje Internetin kautta.

Yksityinen linkki varmistaa, että Power BI -käyttäjät käyttävät Microsoftin yksityistä runkoverkkoa siirtymällä Power BI -palvelun resursseihin.

Yksityisen linkin käyttö Power BI:n kanssa tarjoaa seuraavat edut:

• Yksityinen linkki varmistaa, että liikenne kulkee Azuren runkoverkon kautta yksityiseen Azuren pilvipohjaisille resursseille tarkoitettuun päätepisteeseen.
• Verkkoliikenteen eristäminen muista kuin Azure-pohjaisista infrastruktuureista, kuten paikallisesta käytöstä, edellyttäisi, että asiakkaille on määritetty ExpressRoute tai näennäinen yksityisverkko (VPN).

Lisätietoja on artikkelissa Yksityiset linkit Power BI :n käyttöä varten.

VNet-yhteydet

Vaikka Yksityisen linkin integrointi -ominaisuus tarjoaa suojatut saapuvat yhteydet Power BI:hin, VNet-yhteysominaisuus mahdollistaa suojatun lähtevän yhteyden Power BI:stä VNetissä sijaitseviin tietolähteisiin.

VNet-yhdyskäytävät (Microsoftin hallitsemat) eivät korvaa paikallisten tietoyhdyskäytävien asentamista ja valvontaa VNetiin liittyvien tietolähteiden yhdistämisessä. Järjestelmänvalvojat noudattavat kuitenkin yhä tuttua suojaus- ja tietolähteiden hallintaprosessia paikallisen tietoyhdyskäytävän tapaan.

Seuraavassa on yleiskatsaus siitä, mitä tapahtuu, kun käsittelet Power BI -raporttia, joka on yhdistetty VNetissä olevaan tietolähteeseen VNet-yhdyskäytävien avulla:

1. Power BI -pilvipalvelu (tai jokin muu tuetuista pilvipalveluista) käynnistää kyselyn ja lähettää kyselyn, tietolähteen tiedot ja tunnistetiedot Power Platform VNet -palveluun (PP VNet).

2. PP VNet -palvelu lisää sitten suojatusti aliverkkoon säilön, jossa on käytössä VNet-yhdyskäytävä. Tämä säilö voi nyt muodostaa yhteyden tässä aliverkossa käytettävissä olevaan tietopalveluun.

3. PP VNet -palvelu lähettää sitten kyselyn, tietolähteen tiedot ja tunnistetiedot VNet-yhdyskäytävään.

4. VNet-yhdyskäytävä hakee kyselyn ja muodostaa yhteyden tietolähteisiin kyseisillä tunnistetiedoilla.

5. Tämän jälkeen kysely lähetetään tietolähteeseen suoritusta varten.

6. Suorittamisen jälkeen tulokset lähetetään VNet-yhdyskäytävään ja PP VNet -palvelu siirtää tiedot turvallisesti säilöstä Power BI -pilvipalveluun.

Palveluiden päänimet

Power BI tukee palvelun päänimien käyttöä. Tallenna kaikki salaukseen tai Power BI:n käyttämiseen käytetyt palvelun päänimen tunnistetiedot avainsäilöön, määritä säilöön asianmukaiset käyttöoikeuskäytännöt ja tarkista käyttöoikeudet säännöllisesti.

Saat lisätietoja ohjeartikkelista Premium-työtilan ja semanttisen mallin tehtävien automatisoiminen palvelujen päänimien avulla.

Microsoft Purview for Power BI

Microsoft Purview Information Protection

Power BI on integroitu syvästi Microsoft Purview Information Protectioniin. Microsoft Purview Information Protectionin avulla organisaatiot voivat luoda yhden integroidun ratkaisun luokitukseen, merkintään, valvontaan ja vaatimustenmukaisuuteen Azuressa, Power BI:ssä ja Officessa.

Kun tietojen suojaus on käytössä Power BI:ssä:

• Arkaluontoisia tietoja (sekä Power BI -palvelussa että Power BI Desktopissa) voidaan luokitella ja merkitä samoilla luottamuksellisuustunnisteilla, joita käytetään Officessa ja Azuressa.
• Hallintokäytännöt voidaan pakottaa, kun Power BI -sisältöä viedään Excel-, PowerPoint-, PDF-, Word- tai .pbix-tiedostoihin . Näin voidaan varmistaa, että tiedot ovat suojattuja silloinkin, kun ne viedään Power BI:stä.
• .pbix-tiedostojen luokitteleminen ja suojaaminen Power BI Desktopissa on helppoa samalla tavalla kuin Excel-, Word- ja PowerPoint-sovelluksissa. Tiedostot voidaan helposti merkitä niiden luottamuksellisuustason mukaan. Lisäksi ne voidaan salata, jos ne sisältävät liiketoiminnallisia luottamuksellisia tietoja, mikä varmistaa, että vain valtuutetut käyttäjät voivat muokata näitä tiedostoja.
• Excel-työkirjat perivät luottamuksellisuustunnisteet automaattisesti, kun ne muodostavat yhteyden Power BI:hin (esiversio), mikä mahdollistaa luokituksen säilyttämisen alusta loppuun ja suojauksen käytön, kun Power BI:n semanttisia malleja analysoidaan Excelissä.
• Power BI -raporteissa ja koontinäytöissä käytettävät luottamuksellisuustunnisteet näkyvät Power BI:n iOS- ja Android-mobiilisovelluksissa.
• Luottamuksellisuustunnisteet säilyvät, kun Power BI -raportti upotetaan Teamsiin, SharePointiin tai suojattuun sivustoon. Tämä auttaa organisaatioita säilyttämään luokituksen ja suojauksen vietäessä, kun upotat Power BI -sisältöä.
• Tunnisteiden periytyminen luotaessa uutta sisältöä Power BI -palvelussa varmistaa, että Power BI -palvelussa semanttisissa malleissa tai tietomarteissa käytettyjä tunnisteita käytetään uuteen sisältöön, joka on luotu näiden semanttisten mallien ja tietojoukkojen lisäksi.
• Power BI -järjestelmänvalvojan skannauksen ohjelmointirajapinnat voivat poimia Power BI -kohteen luottamuksellisuustunnisteen, jolloin Power BI- ja InfoSec-järjestelmänvalvojat voivat valvoa tunnisteita Power BI -palvelussa ja tuottaa johdon raportteja.
• Power BI -järjestelmänvalvojan ohjelmointirajapintojen avulla keskitettyjen tiimien on mahdollista käyttää luottamuksellisuustunnisteita ohjelmallisesti Power BI -palvelun sisällössä.
• Keskitetty tiimi voi luoda pakollisia otsikkokäytäntöjä, joilla pakotetaan tunnisteiden käyttö uudessa tai muokatussa sisällössä Power BI:ssä.
• Keskitetty tiimi voi luoda oletusarvoisia tunnistekäytäntöjä varmistaakseen, että luottamuksellisuustunnistetta käytetään kaikkeen uuteen tai muutettuun Power BI -sisältöön.
• Automaattinen luottamuksellisuustunnisteet Power BI -palvelussa varmistavat, että kun semanttisen mallin tai tietomartin tunnistetta käytetään tai muutetaan, tunniste otetaan automaattisesti käyttöön tai muutetaan kaikissa semanttiseen malliin tai tietomartiin yhdistetyssä lopputason sisällössä.

Lisätietoja on artikkelissa Luottamuksellisuustunnisteet Power BI:ssä.

Microsoft Purview Data Loss Prevention (DLP) -käytännöt Power BI:lle

Microsoft Purview'n DLP-käytäntöjen avulla organisaatiot voivat pienentää luottamuksellisten yritystietojen vuotamisriskiä Power BI:stä. DLP-käytäntöjen avulla he voivat täyttää julkishallinnon tai toimialan säädösten vaatimustenmukaisuusvaatimukset, kuten GDPR:n (Euroopan unionin yleinen tietosuoja-asetus) tai CCPA:n (Kalifornian kuluttajansuojalaki) ja varmistaa, että niiden Power BI:ssä olevia tietoja hallitaan.

Kun Power BI:n DLP-käytäntöjä määritetään:

• Käytäntö arvioi kaikki käytäntöön määritettyjen työtilojen semanttiset mallit.
• Voit tunnistaa, milloin luottamuksellisia tietoja ladataan Premium-kapasiteetteihin. DLP-käytännöt voivat tunnistaa:
  • Luottamuksellisuustunnisteet.
  • Arkaluontoisia tietotyyppejä. Tuettuja tyyppejä on yli 260. Luottamuksellisten tietojen tyypin havaitseminen edellyttää Microsoft Purview -sisällön tarkistamista.
• Kun kohtaat arkaluonteiseksi määritetyn semanttisen mallin, näet mukautetun käytäntövihjeen, joka auttaa ymmärtämään, mitä sinun tulisi tehdä.
• Jos olet semanttisen mallin omistaja, voit ohittaa käytännön ja estää semanttisen mallin tunnistamisen "arkaluonteiseksi", jos sinulla on pätevä syy tehdä niin.
• Jos olet semanttisen mallin omistaja, voit ilmoittaa ongelmasta käytännön avulla, jos huomaat, että arkaluontoinen tietotyyppi on tunnistettu virheellisesti.
• Voit käynnistää automaattisia riskienhallintamenetelmiä, kuten hälytyksiä suojauksen järjestelmänvalvojalle.

Lisätietoja on artikkelissa Fabric Power BI:n tietojen menetyksen estämiskäytännöt.

Microsoft Defender for Cloud Apps for Power BI

Microsoft Defender for Cloud Apps on yksi maailman johtavista pilvipalvelujen käytön suojauksen välittäjistä, joka on nimetty johtavaksi Gartnerin Magic Quadrant -pilvikäyttötietovälittäjän (CASB) markkinoilla. Defender for Cloud Appsia käytetään pilvisovellusten käytön suojaamiseen. Sen avulla organisaatiot voivat valvoa ja hallita reaaliaikaisesti riskialttiita Power BI -istuntoja, kuten käyttäjien käyttöoikeuksia hallitsemattomista laitteista. Suojauksenvalvojat voivat määrittää käytäntöjä, joilla hallitaan käyttäjien toimintoja, kuten arkaluontoisia tietoja sisältävien raporttien lataamista.

Defender for Cloud Appsin avulla organisaatiot voivat saada seuraavat DLP-ominaisuudet:

• Ota käyttöön riskialttiita käyttäjäistuntoja Power BI:ssä määrittämällä reaaliaikaisia ohjausobjekteja. Jos käyttäjä esimerkiksi muodostaa yhteyden Power BI:hin maan tai alueen ulkopuolelta, Defender for Cloud Apps -reaaliaikaiset ohjausobjektit voivat valvoa istuntoa. Lisäksi riskialttiita toimintoja, kuten Erittäin luottamuksellisuustunnisteella merkittyjen tietojen lataaminen voidaan estää välittömästi.
• Tutki Power BI:n käyttäjien toimintaa Defender for Cloud Appsin toimintalokin avulla. Defender for Cloud Apps -toimintaloki sisältää Power BI -toiminnan, joka on tallennettu Office 365:n valvontalokiin, joka sisältää tietoja kaikista käyttäjien ja järjestelmänvalvojien toimista, sekä luottamuksellisuustunnisteen tiedot soveltuvista toiminnoista, kuten käyttö, muutos ja tunnisteen poistaminen. Järjestelmänvalvojat voivat hyödyntää Defender for Cloud Appsin kehittyneitä suodattimia ja pikatoimintoja tehokkaiden aiheiden tutkimiseen.
• Luo mukautetut käytännöt, joiden avulla voit ilmoittaa epäilyttävästä käyttäjän toiminnasta Power BI:ssä. Defender for Cloud Apps -toimintakäytäntöominaisuutta voidaan hyödyntää omien mukautettujen sääntöjen määrittämisessä, jotta voit havaita normista poikkeavan käyttäjän toiminnan ja jopa mahdollisesti toimia sen jälkeen automaattisesti, jos se vaikuttaa liian vaaralliselta.
• Työskentele Defender for Cloud Appsin valmiiden poikkeamien tunnistamisen kanssa. Defender for Cloud Appsin poikkeamien tunnistamisen käytännöt tarjoavat valmista käyttäjien käyttäytymisanalytiikkaa ja koneoppimista niin, että olet valmis alusta alkaen suorittamaan kehittyneen uhkien tunnistamisen pilviympäristössäsi. Kun poikkeamien tunnistamisen käytäntö tunnistaa epäilyttävän käyttäytymisen, se käynnistää suojausilmoituksen.
• Power BI -järjestelmänvalvojan rooli Defender for Cloud Apps -portaalissa. Defender for Cloud Apps tarjoaa sovelluskohtaisen järjestelmänvalvojaroolin, jonka avulla Power BI -järjestelmänvalvojat voivat myöntää Power BI -järjestelmänvalvojille vain käyttöoikeudet, joita he tarvitsevat käyttääkseen Power BI:n kannalta merkityksellisiä tietoja portaalissa, kuten hälytyksiä, riskialttiita käyttäjiä, toimintalokeja ja muita Power BI:hin liittyviä tietoja.

Lisätietoja on artikkelissa Microsoft Defender for Cloud Apps -ohjausobjektien käyttäminen Power BI:ssä .

Esikatsele suojausominaisuuksia

Tässä osiossa on luettelo ominaisuuksista, jotka on tarkoitus julkaista maaliskuuhun 2021 asti. Koska tässä aiheessa luetellaan ominaisuuksia, joita ei ehkä ole vielä julkaistu, toimitusaikajanat saattavat muuttua ja arvioidut toiminnot voidaan julkaista myöhemmin kuin maaliskuussa 2021 tai niitä ei ehkä julkaista lainkaan. Saat lisätietoja esiversioista online-palveluiden ehdoista.

Tuo oma logalytiikkasi (BYOLA)

Bring Your Own Log Analytics mahdollistaa integroinnin Power BI:n ja Azure Log Analyticsin välillä. Tämä integrointi sisältää Azure Log Analyticsin kehittyneen analytiikkamoduulin, vuorovaikutteisen kyselykielen ja sisäiset koneoppimisrakenteet.

Power BI:n suojaukseen liittyvät kysymykset ja vastaukset

Seuraavat kysymykset ovat yleisiä Power BI:n suojaukseen liittyviä kysymyksiä ja vastauksia. Ne on järjestetty sen mukaan, milloin ne lisättiin tähän raporttiin, jotta löytäisit uudet kysymykset ja vastaukset nopeasti, kun niitä lisätään. Uusimmat kysymykset lisätään tämän luettelon loppuun.

Miten käyttäjät muodostavat yhteyden tietolähteisiin ja pääsevät käyttämään tietolähteitä Power BI:tä käyttäessään?

• Power BI hallitsee kunkin käyttäjän tietolähteiden tunnistetietoja pilvipalvelun tunnistetietojen tai henkilökohtaisen yhdyskäytävän kautta käytettäväksi. Paikallisen tietoyhdyskäytävän hallitsemat tietolähteet voidaan jakaa yrityksen kesken, ja yhdyskäytävän järjestelmänvalvoja voi hallita näiden tietolähteiden käyttöoikeuksia. Kun määrität semanttista mallia, käyttäjällä on oikeus valita tunnistetiedot omasta säilöstään tai käyttää jaettua tunnistetietoa paikallisen tietoyhdyskäytävän avulla.

  Tuontitapauksessa käyttäjä muodostaa yhteyden käyttäjän sisäänkirjautumisen perusteella ja käsittelee tietoja tunnistetiedoilla. Kun semanttinen malli on julkaistu Power BI -palveluun, Power BI käyttää aina tämän käyttäjän tunnistetietoja tietojen tuomiseen. Kun tiedot on tuotu, tietojen tarkasteleminen raporteissa ja koontinäytössä ei käytä pohjana olevaa tietolähdettä. Power BI tukee kertakirjautumistodennusta valituille tietolähteille. Jos yhteys on määritetty käyttämään kertakirjautumista, tietolähteeseen muodostetaan yhteys semanttisen mallin omistajan tunnistetiedoilla.

  DirectQueryyn yhdistetyissä raporteissa tietolähde on yhdistetty suoraan esimääritetyllä tunnistetiedoilla. Esimääritettyä tunnistetietoa käytetään yhteyden muodostamiseen tietolähteeseen, kun käyttäjä tarkastelee tietoja. Jos tietolähde on yhdistetty suoraan kertakirjautumisen avulla, nykyisen käyttäjän tunnistetiedoilla muodostetaan yhteys tietolähteeseen, kun käyttäjä tarkastelee tietoja. Kun käytät kertakirjautumista, rivitason suojaus (RLS) ja/tai objektitason suojaus (OLS) voidaan ottaa käyttöön tietolähteessä, jolloin käyttäjät voivat tarkastella tietoja, joihin heillä on oikeudet. Kun yhteys on pilvipalvelussa sijaitseviin tietolähteisiin, Microsoft Entra -todennusta käytetään kertakirjautumista varten. Paikallisia tietolähteitä, Kerberosta, SAML:ää ja Microsoft Entra -tunnusta tuetaan.

  Kun muodostat yhteyden Kerberokseen, käyttäjän UPN välitetään yhdyskäytävään ja rajoitetun Kerberos-delegoinnin avulla käyttäjäksi tekeydytään ja muodostetaan yhteys vastaaviin tietolähteisiin. SAML:ää tuetaan myös SAP HANA -tietolähteen yhdyskäytävässä. Lisätietoja on yhdyskäytävien kertakirjautumisen yleiskatsauksessa.

  Jos tietolähde on Azure Analysis Services tai paikallinen Analysis Services ja rivitason suojaus (RLS) ja/tai objektitason suojaus (OLS) on määritetty, Power BI -palvelu käyttää kyseisen rivitason suojausta, ja käyttäjät, joilla ei ole riittävästi tunnistetietoja pohjana olevien tietojen käsittelyyn (mikä voi olla koontinäytössä, raportissa tai muussa tietoarteaktissa käytetty kysely), eivät näe tietoja, joihin käyttäjällä ei ole riittävästi tunnistetietoja. Oikeudet.

  Power BI :n rivitason suojauksen avulla tietojen käyttöä voidaan rajoittaa tietyille käyttäjille. Suodattimet rajoittavat tietojen käyttöä rivitasolla ja voit määrittää roolin sisäisiä suodattimia.

  Objektitason suojausta (OLS) voidaan käyttää luottamuksellisten taulukoiden tai sarakkeiden suojaamiseen. Toisin kuin rivitason suojaus, objektitason suojaus suojaa kuitenkin myös objektien nimet ja metatiedot. Tämä auttaa estämään pahantahtoisia käyttäjiä tutustumasta edes tällaisten objektien olemassaoloon. Suojatut taulukot ja sarakkeet piilotetaan kenttäluettelossa, kun käytetään raportointityökaluja, kuten Exceliä tai Power BI:tä, ja lisäksi käyttäjät, joilla ei ole oikeuksia, eivät voi käyttää suojattuja metatieto-objekteja DAX:n tai minkään muun menetelmän kautta. Käyttäjien, joilla ei ole asianmukaisia käyttöoikeuksia, suojattuja taulukoita ja sarakkeita ei yksinkertaisesti ole olemassa.

  Objektitason suojaus ja rivitason suojaus mahdollistavat parannetun yritystason suojauksen raporteissa ja semanttisissa malleissa, mikä varmistaa, että vain käyttäjillä, joilla on tarvittavat käyttöoikeudet, on oikeus tarkastella ja käsitellä luottamuksellisia tietoja.

Miten tietoja siirretään Power BI:hin?

• Kaikki Power BI:n pyytämät ja välittämät tiedot salataan siirrettäessä HTTPS:n avulla (paitsi silloin, kun asiakkaan valitsema tietolähde ei tue HTTPS:ää) yhteyden muodostamiseksi tietolähteestä Power BI -palveluun. Tietopalvelun kanssa muodostetaan suojattu yhteys ja tiedot kulkevat verkossa vasta, kun yhteys on muodostettu.

Miten Power BI tallentaa välimuistiin raportti-, koontinäyttö- tai mallitietoja, ja onko se turvallinen?

• Kun tietolähdettä käytetään, Power BI -palvelu suorittaa tämän asiakirjan aiemmassa Todennus tietolähteissä -osiossa kuvatun prosessin.

Tallentavatko asiakkaat verkkosivujen tietoja paikallisesti välimuistiin?

• Kun selainasiakkaat käyttävät Power BI:tä, Power BI -verkkopalvelimet määrittävät Cache-Control-direktiivin arvoksi no-store. Tämä no-store-direktiivi määrittää, että selaimet eivät tallenna välimuistiin käyttäjän katsomia verkkosivuja eivätkä tallenna verkkosivua asiakkaan välimuistikansioon.

Entä roolipohjainen suojaus, raporttien tai koontinäyttöjen jakaminen ja tietoyhteydet? Miten ne toimivat tietojen käytön, koontinäytön tarkastelun, raportin käytön tai päivityksen osalta?

• Jos kyseessä on muu kuin roolitason suojaus (RLS) käytössä oleva tietolähde ja jos koontinäyttö, raportti tai tietomalli jaetaan muiden käyttäjien kanssa Power BI:n kautta, tiedot ovat niiden käyttäjien käytettävissä, joiden kanssa tiedot on jaettu, ja niitä voidaan tarkastella ja käsitellä. Power BI ei todenna käyttäjiä uudelleen tietojen alkuperäisestä lähteestä; kun tiedot on ladattu Power BI:hin, lähdetietojen avulla todennettu käyttäjä on vastuussa sen hallinnasta, ketkä muut käyttäjät ja ryhmät voivat tarkastella tietoja.

  Kun tietoyhteyksiä muodostetaan RLS-yhteensopivaan tietolähteeseen, kuten Analysis Services -tietolähteeseen, Power BI:n välimuistiin tallennetaan vain koontinäytön tiedot. Aina, kun raporttia tai semanttista mallia tarkastellaan tai käsitellään Power BI:ssä, joka käyttää RLS-yhteensopivaa tietolähdettä, Power BI -palvelu käyttää tietolähdettä käyttäjän tunnistetietojen perusteella noutaakseen tietoja, ja jos tunnistetietoihin on olemassa riittävät käyttöoikeudet, tiedot ladataan käyttäjän raporttiin tai tietomalliin. Jos todentaminen epäonnistuu, käyttäjä näkee virheen.

  Lisätietoja on tämän asiakirjan aiemmassa kohdassa Todentaminen tietolähteissä .

Käyttäjämme muodostavat jatkuvasti yhteyksiä samoihin tietolähteisiin, joista osa edellyttää eri tunnistetietoja kuin käyttäjien toimialueen tunnistetiedot. Miten käyttäjien ei tarvitsisi antaa näitä tunnistetietoja aina, kun he muodostavat tietoyhteyden?

• Power BI tarjoaa henkilökohtaisen Power BI -yhdyskäytävän, jonka avulla käyttäjät voivat luoda tunnistetiedot useille eri tietolähteille ja käyttää kyseisiä tunnistetietoja automaattisesti, kun he sitten käsittelevät kutakin näistä tietolähteistä. Jos haluat lisätietoja, katso Henkilökohtainen Power BI -yhdyskäytävä.

Mitä portteja paikallinen tietoyhdyskäytävä ja henkilökohtainen yhdyskäytävä käyttävät? Onko sellaisia toimialuenimiä, jotka on sallittava yhteyksiä varten?

• Yksityiskohtainen vastaus tähän kysymykseen on saatavilla seuraavasta linkistä: Yhdyskäytäväportit

Kun käytössä on paikallinen tietoyhdyskäytävä, miten palautusavaimia käytetään ja mihin ne on tallennettu? Entä suojattu tunnistetietojen hallinta?

• Yhdyskäytävän asennuksen ja määrittämisen aikana järjestelmänvalvoja kirjoittaa yhdyskäytävän palautusavaimen. Tämän palautusavaimen avulla luodaan vahva symmetrinen AES-avain. Epäsymmetrinen RSA-avain luodaan myös samanaikaisesti.

  Luodut avaimet (RSA ja AES) tallennetaan tiedostoon paikallisessa koneessa. Tiedosto on myös salattu. Tiedoston sisällön salauksen voi purkaa vain kyseisellä Windows-koneella, ja vain kyseisellä yhdyskäytävän palvelutilillä.

  Kun käyttäjä kirjoittaa tietolähteen tunnistetiedot Power BI -palvelun käyttöliittymään, tunnistetiedot salataan selaimessa julkisella avaimella. Yhdyskäytävä purkaa tunnistetietojen salauksen käyttämällä RSA:n yksityistä avainta ja salaa ne uudelleen symmetrisellä AES-avaimella, ennen kuin tiedot tallennetaan Power BI -palveluun. Tämän prosessin ansiosta Power BI -palvelussa ei koskaan ole salaamattomia tietoja.

Mitä kommunikaatioprotokollia paikallinen tietoyhdyskäytävä käyttää, ja miten ne on suojattu?

• Yhdyskäytävä tukee seuraavia kahta kommunikaatioprotokollaa:

  • AMQP 1.0 – TCP + TLS: Tämä protokolla edellyttää, että portit 443, 5671-5672 ja 9350-9354 ovat avoinna lähtevää tietoliikennepalvelua varten. Tätä protokollaa suositellaan, koska sen viestintäkuormitukset ovat pienemmät.

  • HTTPS – WebSockets ja HTTPS + TLS: Tämä protokolla käyttää vain porttia 443. WebSocket käynnistetään yksittäisellä HTTP CONNECT -viestillä. Kun kanava on muodostettu, tietoliikenne on käytännössä muotoa TCP + TLS. Voit pakottaa yhdyskäytävän käyttämään tätä protokollaa muokkaamalla asetusta, joka on kuvattu paikallisen yhdyskäytävän artikkelissa.

Mikä on Azure-sisältöverkko rooli Power BI:ssä?

• Kuten aiemmin mainittiin, Power BI käyttää Azure Content Delivery Networkia (CDN) tarpeellisen staattisen sisällön ja tiedostojen jakamiseen käyttäjille aluekohtaisten asetusten perusteella. Tarkemmin sanottuna Power BI -palvelu käyttää useita CDN-sisältöjä, jotta se saa tehokkaasti jaettua tarpeellisen staattisen sisällön ja tiedostot käyttäjille julkisen Internetin kautta. Näitä staattisia tiedostoja ovat tuotelataukset (kuten Power BI Desktop, paikallinen tietoyhdyskäytävä tai riippumattomien palveluntarjoajien Power BI -sovellukset), selaimen määritystiedostot, joita käytetään alustamaan ja muodostamaan myöhempiä yhteyksiä Power BI -palvelulle, sekä alkuperäinen turvallinen Power BI -kirjautumissivu.

  Ensimmäisen Power BI -palveluyhteyden aikana toimitettujen tietojen perusteella käyttäjän selain muodostaa yhteyden määritettyyn Azure-sisältöverkko (tai joidenkin tiedostojen yhteydessä WFE:hen) ja lataa kokoelman määritettyjä yleisiä tiedostoja, joiden avulla selain voi olla vuorovaikutuksessa Power BI -palvelun kanssa. Selaimen sivu sisältää Microsoft Entra -tunnuksen, istunnon tiedot, istuntoon liittyvän taustaklusterin sijainnin sekä kokoelman tiedostoja, jotka on ladattu Azure-sisältöverkko- ja WFE-klusterista Power BI -palvelun selainistunnon ajaksi.

Suorittaako Microsoft Power BI -visualisoinneissa minkäänlaista mukautetun visualisointikoodin arviointia suojauksen tai tietosuojan kannalta ennen kohteiden julkaisemista Valikoimaan?

• Ei. On asiakkaan vastuulla tarkistaa mukautettu visualisointikoodi ja päättää, voiko siihen luottaa. Kaikkia mukautettuja visualisointikoodteja käytetään eristysympäristössä, joten mukautetun visualisoinnin virheelliset koodit eivät vaikuta haitallisesti muuhun Power BI -palveluun.

Lähettävätkö muut Power BI -visualisoinnit tietoja asiakasverkon ulkopuolelle?

• Kyllä. Bing Maps- ja ESRI-visualisoinnit siirtävät tietoja Power BI -palvelusta näitä palveluja käyttäviin visualisointeihin.

Suorittaako Microsoft mallisovelluksissa minkäänlaista mallisovelluksen arviointia suojauksen tai tietosuojan suhteen ennen kohteiden julkaisemista Valikoimaan?

• Ei. Sovelluksen julkaisija on vastuussa sisällöstä, kun on asiakkaan vastuulla tarkistaa mallisovelluksen julkaisija ja päättää, voiko siihen luottaa.

Onko olemassa mallisovelluksia, jotka voivat lähettää tietoja asiakasverkon ulkopuolelle?

• Kyllä. On asiakkaan vastuulla tarkistaa julkaisijan tietosuojakäytäntö ja päättää, asennetaanko mallisovellus vuokraajaan. Julkaisija on vastuussa sovelluksen toiminnasta ja ominaisuuksista ilmoittamisesta asiakkaalle.

Entä tietojen suvereniteetti? Voimmeko valmistella vuokraajat palvelinkeskuksissa, jotka sijaitsevat tietyillä maantieteellisillä alueilla, jotta tiedot eivät siirry maan tai alueen rajojen yli?

• Tietyillä maantieteellisillä alueilla jotkut asiakkaat voivat luoda vuokraajan kansallisessa tai alueellisessa pilvipalvelussa, jossa tietojen tallennus ja käsittely suoritetaan erillään kaikista muista palvelinkeskuksista. Kansallisissa/alueellisissa pilvipalveluissa suojaus toteutetaan hieman eri tavalla, koska erillinen tietojen valtuuttaja käyttää kansallista/alueellista Power BI -palvelua Microsoftin puolesta.

  Vaihtoehtoisesti asiakkaat voivat myös määrittää vuokraajan tietyllä alueella. Tällaisilla vuokraajilla ei kuitenkaan ole erillistä tietojen edunvalvojaa Microsoftista. Kansallisten tai alueellisten pilvipalveluiden hinnoittelu eroaa yleisesti saatavilla olevasta kaupallisesta Power BI -palvelusta. Lisätietoja Power BI -palvelun käytettävyydestä kansallisissa/alueellisissa pilvipalveluissa on artikkelissa Power BI:n kansalliset/alueelliset pilvipalvelut.

Miten Microsoft käsittelee power BI Premium -tilauksia käyttävien asiakkaiden yhteydet? Eroavako kyseiset yhteydet niistä yhteyksistä, joita on muodostettu muille kuin Premium Power BI -palveluille?

• Power BI Premium -tilauksia saaneille asiakkaille luodut yhteydet käyttävät Microsoft Entra business-to-business (B2B) -valtuutusprosessia, jossa Microsoft Entra -tunnuksen avulla voidaan ottaa käyttöön käyttöoikeuksien valvonta ja valtuutus. Power BI käsittelee Power BI Premium -tilaajien yhteydet Power BI Premium -resursseihin samalla tavalla kuin kaikkien Microsoft Entra -käyttäjien.

Miten palvelinpuolen todentaminen toimii WFE:ssä?

• Käyttäjän todentamisen todentamisen palvelupuolen todentaminen tapahtuu seuraavissa vaiheissa kuvatulla tavalla, ja ne on kuvattu niitä seuraavassa kuvassa.

1. Käyttäjä käynnistää yhteyden Power BI -palveluun selaimesta joko kirjoittamalla osoiteriville Power BI -osoitteen tai valitsemalla Power BI:n markkinointisivulta (https://powerbi.microsoft.com). Yhteys muodostetaan TLS 1.2:n ja HTTPS:n avulla, ja kaikkeen seuraavaan tiedonsiirtoon selaimen ja Power BI -palvelun välillä käytetään HTTPS-yhteyttä.

2. Azure-liikennehallinta tarkistaa käyttäjän DNS-tietueen ja määrittää sopivimman (yleensä lähimmän) palvelinkeskuksen, jossa Power BI otetaan käyttöön, ja vastaa DNS:ään sen WFE-klusterin IP-osoitteella, johon käyttäjä tulee lähettää.

3. WFE ohjaa käyttäjän sitten Microsoft Online Servicesin kirjautumissivulle.

4. Kun käyttäjä on todennettu, kirjautumissivu ohjaa käyttäjän aiemmin määritettyyn lähimpään Power BI -palvelun WFE-klusteriin todennuskoodilla.

5. WFE-klusteri tarkistaa Microsoft Entra -tunnuksella Microsoft Entra -suojaustunnuksen todennuskoodin avulla. Kun Microsoft Entra ID palauttaa käyttäjän onnistuneen todennuksen ja palauttaa Microsoft Entra -suojaustunnuksen, WFE-klusteri konsultoi Power BI:n yleistä palvelua, joka ylläpitää vuokraajien luetteloa ja vuokraajien Power BI -taustaklusterien sijainteja, ja määrittää, mikä Power BI-taustapalvelun klusteri sisältää käyttäjän vuokraajan. WFE-klusteri palauttaa sitten käyttäjän selaimeen sovellussivun, joka sisältää istunnon, käyttöoikeuden ja reititystiedot, joita käyttäjän toiminta edellyttää.

6. Kun asiakkaan selain nyt edellyttää asiakastietoja, se lähettää pyynnöt taustaklusterin osoitteeseen, jossa On Microsoft Entra -käyttöoikeustietue Valtuutus-otsikossa. Power BI -taustaklusteri lukee Microsoft Entran käyttöoikeustietueen ja vahvistaa allekirjoituksen varmistaakseen, että pyynnön käyttäjätiedot ovat kelvollisia. Microsoft Entra -käyttöoikeustietueessa on vanhentumispäivä Microsoft Entran käytäntöjen mukaisesti, ja nykyisen istunnon säilyttämiseksi käyttäjän selaimessa oleva Power BI -asiakasohjelma tekee säännöllisiä pyyntöjä käyttöoikeustietueen uusimiseksi ennen sen vanhenemista.

Lisäresurssit

Lisätietoja Power BI -palvelusta saat seuraavista resursseista.

• Power BI Desktopin käytön aloittaminen
• Power BI REST -ohjelmointirajapinnan yleiskatsaus
• Power BI -ohjelmointirajapinnan viittaus
• Paikallinen tietoyhdyskäytävä
• Power BI:n kansalliset/alueelliset pilvipalvelut
• Power BI Premium
• Yleiskatsaus kertakirjautumisen (SSO) käyttämiseen Power BI -yhdyskäytäville