Kun SaaS-yrityksesi alkaa tarjota asiakkaille upotettua raportointia, yksi kysymys nousee ylitse muiden: miten takaan, ettei asiakas A koskaan näe asiakas B:n lukuja?
Tämä on se kohta, jossa moni embedded analytics -projekti pysähtyy. Jos etsit verkosta termeillä "multi-tenant analytics security", "asiakaskohtainen raportointi" tai "monen asiakkaan dashboard", löydät paljon pelottelua ja vähän konkretiaa. Korjataan se. Käydään läpi, miten datan eristäminen oikeasti toimii — ja miksi me rakennamme asiakasportaalit nimenomaan Microsoft Power BI:n päälle.
Miksi yksi raportti riittää sadalle asiakkaalle
Houkutus on tehdä jokaiselle asiakkaalle oma raporttikopionsa omalla datalla. Se tuntuu turvalliselta — erilliset tiedostot, ei sekaantumisen vaaraa. Käytännössä se on ylläpidon painajainen: yhden visualisoinnin muutos pitää toistaa kymmeniin tai satoihin kopioihin.
Skaalautuva malli on yksi raportti, jonka data suodattuu automaattisesti katsojan mukaan. Tämän mahdollistaa Row-Level Security (RLS): raporttiin määritellään sääntö, joka rajaa näkyvät rivit sen perusteella, kuka raporttia katsoo. Yksi raportti, yksi datamalli — mutta jokaiselle asiakkaalle eri näkymä.
Miksi me valitsimme Power BI:n — RLS on siellä aikuisten oikeasti
Olemme rakentaneet monen asiakkaan analytiikkaa eri työkaluilla, ja Power BI:n Row-Level Security on syy, miksi se on meidän oletusvalintamme asiakasportaaleihin.
RLS ei ole Power BI:ssä päälle liimattu lisäominaisuus vaan osa datamallia. Suodatussääntö elää samassa paikassa kuin itse data, Microsoftin testaamana ja tuotantokovetettuna tuhansilla yrityksillä. Kun katsojan identiteetti välitetään raportille, suodatus tapahtuu palvelimella, datakerroksessa — ei sovelluskoodissa, jonka jokainen kehittäjä joutuisi toteuttamaan uudelleen ja jossa jokainen virhe on potentiaalinen vuoto.
Toisin sanoen: emme käytä Power BI:tä siitä huolimatta, että datan eristäminen on vaikeaa, vaan juuri siksi, että Power BI tekee siitä luotettavaa.
Kolme kerrosta, jotka pitävät asiakkaiden datan erillään
Turvallinen monen asiakkaan portaali ei nojaa yhteen tarkistukseen vaan kolmeen päällekkäiseen kerrokseen. Jos yksi pettää, seuraava pysäyttää vuodon.
1. Pääsynhallinta portaalissa — kuka ylipäätään saa nähdä raportin
Ennen kuin mitään dataa haetaan, portaali tarkistaa kirjautuneen käyttäjän istunnon ja sen, mihin raportteihin juuri hänen organisaatiollaan on oikeus. Tätä ei jätetä selaimen varaan: vaikka käyttäjä arvaisi toisen raportin tunnisteen ja yrittäisi avata sen suoraan, palvelin tarkistaa oikeuden tietokannasta — muuten vastaus on yksiselitteinen "ei pääsyä".
2. Datan suodatus embed-tokenissa — mitä rivejä raportti näyttää
Tämä on se kerros, joka tekee monen asiakkaan mallista turvallisen. Kun portaali pyytää Power BI:ltä näyttöluvan (embed token), se liittää pyyntöön katsojan identiteetin ja roolin. Mukaan menee asiakaskohtainen tunniste, jonka perusteella RLS-sääntö suodattaa datan jo Power BI:n päässä — ennen kuin yksikään rivi lähtee palvelimelta selaimeen.
Olennaista: asiakas ei saa "kaikkea dataa, josta osa piilotetaan", vaan fyysisesti vain omat rivinsä. Selaimen kehitystyökaluilla ei pääse käsiksi siihen, mitä ei koskaan lähetetty.
3. Lyhytikäinen token — kuinka kauan lupa on voimassa
Näyttölupa ei ole pysyvä. Embed token vanhenee oletuksena noin tunnissa, ja me rajaamme sen koskemaan vain yhtä raporttia kerrallaan. Vaikka token jotenkin vuotaisi, sen elinikä on minimaalinen eikä sillä pääse käsiksi muihin raportteihin tai datajoukkoihin.
Yleisin virhe: luottaa siihen, mitä selain kertoo
Suurin osa tämän mallin tietovuodoista ei johdu Power BI:stä vaan siitä, että pääsynhallinta on rakennettu väärään paikkaan. Jos sovellus päättää selaimen puolella mitä näytetään — esimerkiksi piilottaa "väärän" asiakkaan raportit vain käyttöliittymästä — data on silti haettavissa, jos joku osaa katsoa verkkoliikennettä.
Sääntö on yksinkertainen: jokainen datapyyntö tarkistetaan palvelimella, jokaisella kerralla. Käyttäjän istunto, organisaation oikeus juuri siihen raporttiin ja datan suodatus tehdään kaikki palvelinpuolella. Selain saa vain valmiiksi rajatun lopputuloksen.
Entä kun asiakkaita tulee lisää?
Tämän mallin kauneus on, että se skaalautuu ilman lisätyötä. Uusi asiakas tarkoittaa uutta riviä oikeustaulussa — ei uutta raporttia, ei koodimuutoksia, ei uutta tietoturva-arviointia. Sama testattu suodatuslogiikka pätee asiakkaaseen numero 2 ja asiakkaaseen numero 500.
Yhteenveto SaaS-johtajalle
Monen asiakkaan analytiikkaportaali on täysin turvallinen rakentaa, kun tietojen eristäminen tehdään oikeissa kerroksissa:
- Pääsynhallinta ratkaisee, kuka näkee raportin ylipäätään
- RLS embed-tokenissa ratkaisee, mitä dataa raportti näyttää
- Lyhytikäinen token rajaa, kuinka kauan ja mihin lupa pätee
Juuri tämän takia rakennamme asiakasportaalit Power BI:n päälle: datan eristäminen ei jää sovelluskoodin varaan, vaan nojaa Microsoftin tuotantokovetettuun RLS-malliin. Näin voit tarjota saman raportin sadalle asiakkaalle luottavaisin mielin — jokainen näkee vain omansa.