Emme me voi noin vain antaa kaikkien tehdä sovelluksia! Miten me voimme silloin varmistua siitä kuka voi nähdä ja muokata tietoja x?

Kuulen tätä (ja monia muita Power Platformin tietoturvaan liittyviä huolia) usein. Onkin korkea aika hälventää savuverhoa Power Platformin ja sen tietoturvan osalta. Ja nimenomaan siitä, miten Power Platform-ratkaisuissa käyttäjät pääsevät eri tietoihin käsiksi.

Power Platformin ytimessä ovat yhdistimet (connector). Niiden avulla ratkaisujen tekijät voivat helposti hyödyntää erilaisia tietolähteitä (SharePoint, Dynamics 365, Salesforce, SQL-kannat, Googlen palvelut jne). Yhdistimiä on lähes 400 ja niitä tulee lisää kokoajan.

Kaikki tietojen haku, muokkaus, lisäys ja poisto -toiminnot rakennetaan yhdistimiä hyödyntäen.

Yhdistimien yhteydet (connections)

Kuvitellaan että meillä on (Canvas) Power Apps, jonka tietovarastona on SharePoint-lista. Kaikki SharePointiin liitttyvät toimenpiteet tehdään SharePoint-yhdistintä hyödyntäen.

Mitä tapahtuu käyttäjän käynnistäessä sovelluksen ensimmäisen kerran? Häneltä pyydetään lupa sovelluksen käyttämien tietolähteiden käyttöön (yhdistimien avulla). Antamalla suostumuksen, Power Platform luo käyttäjän käyttöön hänen omalla käyttäjätunnuksellaan tarvittavat yhteydet.

Office 365 palveluiden osalta tämä tapahtuu automaattisesti. Käyttäjähän on jo kirjautuneena Office 365:een. Mikäli ratkaisussa käytetään esimerkiksi Salesforcea, joutuu käyttäjä yhteyden luontia varten kirjautumaan Salesforceen omilla tunnuksillaan.

Käytännössä käyttäjien 1 ja 2 käyttäessä sovellusta, heillä on kaikkiin käytettäviin tietolähteisiin omat yhteytensä, joissa käytetään heidän omia tunnuksiaan.

Käyttäjät näkevät juuri ne rivit tietolähteestä, jotka heillä on oikeus nähdä. Sama tarina luonnollisesti rivien lisäämisen, muokkaamisen ja poistamisen suhteen.

Kaikki tehdään aina käyttäjien omilla tunnuksilla.

Melkein aina…

Jaetut yhteydet

Muutama yhteys toimii kuitenkin toisin. Niitä kutsutaan jaetuiksi yhteyksiksi. Klassinen esimerkki tästä on Azure SQL tietokannan hyödyntäminen SQL Serverin omaa loginia hyödyntäen.

Tällöin sovelluksen tekijä luo yhteyden ja jakaa sen kaikkien sovelluksen käyttäjien yhteiseen käyttöön.

Ja nyt on syytä tietää mitä tekee. Esimerkiksi default-ympäristössä jaetut yhteydet voivat olla todella vaarallisia.

Sovelluksen tekijää aiheesta kyllä varoitetaan sekä tekovaiheessa

että sovellusta jaettaessa.

Ikävä kyllä nämä varoitustekstit ovat usein täyttä hepreaa kansalaiskehittäjälle. Painetaan Confirm ja taas mennään.

Yhteyksien välillinen käyttö

Sovelluksen tekijän on itseasiassa vaikeaa tehdä ratkaisua, jossa käyttäjät voisivat tehdä toimenpiteitä joihin heillä ei ole oikeuksia. Tämä on kuitenkin mahdollista välillisesti.

Esimerkiksi sovellus, jolla käyttäjät luovat ja muokkaavat havaintoja (issues). Sovelluksen tekijä on luonut työnkulun (flow), joka kopioi havainnot samantien toiseen paikkaan (arkistoon). Sovelluksen käyttäjillä ei kuitenkaan ole oikeuksia koko arkistoon.

Sovellus kuitenkin toimii aivan kuten heillä olisi oikeudet luoda havaintoja myös arkistoon.

Välillistä käyttöä ei synny vahingossa, vaan se on tekijän tietoinen ratkaisu. Käyttöoikeuksien kiertämisen ohella se johtaa usein myös lisenssien kiertoon (multiplexing).

Vieraskäyttäjät (Guest users)

Canvas Power Appseja voi jakaa myös tenantin vieraskäyttäjille.

Mitä silloin tapahtuu yhteyksille?

Luodaan sovellus, joka käyttää Outlook ja SharePoint -yhdistimiä. Sovellus näyttää käyttäjän sähköpostit, sekä listaa SharePoint-listalla olevat havainnot.

Jaetaan sovellus tenantin ulkopuoliselle käyttäjälle (guest user).

Vieraskäyttäjän avatessa sovelluksen ensimmäistä kertaa, luodaan hänelle tarvittavat yhteydet.

Mutta mihin? Viesti on tältä osin hieman epäselvä.

Kyllä! Vieraskäyttäjä antoi juuri sovellukselle oikeuden lukea hänen kotitenanttinsa sähköpostilaatikon sisällön (ja kalenterin ja tehtävät), lähettää hänen nimissään sähköpostia jne.

SharePoint-yhteys osoittaa sentään sovelluksen kanssa samassa tenantissa olevaan SharePoint-listaan.

Yhdistimien ristiinkäyttöä tenanttien välillä voi rajoittaa. Toistaiseksi ominaisuus aktivoidaan tuen kautta, mutta eiköhän sen voi tulevaisuudessa konfigruoida myös käyttöliittymästä.

Ympäristöt

Yhteyksien lisäksi toinen keskeinen Power Platformin tietoturvaelementti on (Power Platform) ympäristöt.

Kaikki Power Platformin elementit (Power Appsit, Flow’t, yhteydet, ympäristömuuttujat, Dataverse, DLP-säännöt jne) sijaitsevat aina yhden ympäristön sisällä.

Esimerkiksi jos käyttäjä käyttää SharePointia hyödyntäviä Power Appseja, jotka sijaitsevat eri ympäristöissä, on käyttäjälle jokaisessa näistä ympäristöissä luotuna oma SharePoint-yhteys.

Jokaisessa ympäristössä voi olla myös (yksi) Dataverse tietovarasto. Tällöin ympäristöllä on myös oma käyttäjähallinta.

Ja jotta ympäristössä pääsee tekemään mitään tulee

  1. olla ympäristön käyttäjä
  2. käyttäjällä olla asetettuna tarvittavat käyttöoikeusroolit (security role) ja niillä pääsy ympäristön valittuihin tietoihin

Lähtökohtaisesti ympäristön käyttäjä ei pääse tekemään sovelluksia eikä näe ympäristöön luotujen taulujen sisältöjä.

Alussa on tärkeintä hahmotta että ratkaisuja voidaan lokeroida omiin ympäristöihinsä ja nämä ympäristöt sisältävät kattavat työkalut pääsyn- ja käyttöoikeuksien hallintaan.

Ja muistaa etteivät Power Platform ympäristöt ole sama asia kuin Office 365 tenant tai Azuren tilaus / resurssiryhmä.

DLP käytännöt (Data Loss Preventation Policy)

DLP käytäntöjen avulla voidaan rajata mitä yhdistimiä (connector) missäkin ympäristössä on sallittua käyttää. DLP käytäntöjä olen käsitellyt aiemmin ja suosittelen lukemaan seuraavat, mikäli aihe on uusi

DLP-käytännöt on havaintojeni mukaan alikäytetty ominaisuus. Suosittelen miettimään soveltuvia DLP-käytäntöjä heti Power Platformin käytön alussa.

Lähitulevaisuudessa on luvassa myös merkittäviä lisäominaisuuksia DLP-käytäntöihin, jotka tekevät niistä entistäkin tehokkaampia.

Käytettävät IP-avaruudet ja palvelut

Power Platform on luonteeltaan palvelu (PaaS, platform as a service). Se asuu julkiverkossa eikä sitä voi käyttää, mikäli sen käyttämät IP-osoitteet / palvelut on estetty.

Tieto Canvas Appsien käyttämistä IP-avaruuksista sekä palveluista löytyy täältä:

https://docs.microsoft.com/en-us/powerapps/maker/canvas-apps/limits-and-config

Samat Flow’n osalta täältä:

https://docs.microsoft.com/en-us/power-automate/ip-address-configuration

Yhteenveto

Canvas Power Appseissa kaikki tietolähteisiin liittyvät toimenpiteet tehdään (muutamaa tunnettua poikkeusta lukuunottamatta) loppukäyttäjän tunnuksilla ja käyttöoikeuksilla. Siltä osin syytä suureen huoleen ei ole.

Lisäksi Power Platform tarjoaa kohtuullisen kattavat mekanismit rajoittaa yhdistimien käyttöä ratkaisuissa.

Siirryttäessä Dataverseen, mukaan tulee Dynamics 365 -maailmasta tutut varsin laajat käyttäjien ja pääsyoikeuksien hallintaominaisuudet.

Nukun yöni hyvin.