Power Platform -ympäristön suunnittelu ja hallinnointi 1/2: perustaminen ja suunnittelu

Tässä blogissa käsittelemme Power Platformin anatomiaa ja hallinnollisia kysymyksiä. Keskitymme ympäristön ymmärtämiseen, suunnitteluun ja hallinnointiin teoreettisella tasolla.

Power Platform ja siihen siirtyminen tarjoavat organisaatiolle joustavuutta, tehostettua kehitystä ja mahdollisuuden hyödyntää yrityksen täyttä potentiaalia osallistuttamalla mahdollisimman laaja osa henkilöstöstä yhteisen ja oman toiminnan kehittämiseen. Citizen-kehittäjien osallistuttaminen ja datan avaaminen organisaation eri käyttäjille mahdollistaa paljon, mutta se vaatii myös hallinnollista työtä ja käytänteitä.

Tietohallinnon näkökulmasta toimintasuunnitelma ja tehtävälista voitaisiin kuvata alla olevalla tavalla:

1. Ymmärrä - Tunne Power Platformin anatomia ja sen hallintaan tarkoitetut portaalit.
2. Suunnittele – Power Platform ympäristöjen perustaminen ja käytön määrittely
3. Turvaa - Tietoturva ja käyttäjähallinta Power Platformissa
4. Hallinnoi - Ylläpitoroolien ja ylläpitovastuiden määritteleminen
5. Toteuta ja tue- Ylläpidon työkalut ja prosessien tukeminen

Tämä on ensimmäinen blogikirjoitus kaksiosaisessa julkaisussa, jossa perehdymme ylätasolla Power Platformin ympäristön perustamisen ja hallinnoinnin kannalta olennaisiin osa-alueisiin, nikseihin ja tietohallintoa tukeviin käytänteisiin ja työkaluihin. Tässä kirjoituksessa käsittelemme Power Platformin anatomiaa ja hallinnollisia kysymyksiä. Keskitymme ensimmäisessä blogissa ympäristön ymmärtämiseen, suunnitteluun ja hallinnointiin teoreettisella tasolla. Tämän jälkeen perehdymme toisessa blogissa käytännön työkaluihin, joilla tietohallinto voi ylläpitää ja tukea prosesseja Power Platform ympäristössä.

Power Platformin anatomia

Jokaista Power Platformin päälle perustettua ympäristöä voidaan pitää säiliönä, joka yhdistää ympäristön olennaiset komponentit toisiinsa (alla olevassa kuvassa oikealla), mahdollistaen niiden keskinäisen käytön ja ylläpidon. Power Platform -ympäristöt on sidottu organisaation Microsoft 365 ja Azure AD -tenanttiin. Jokainen tenantti sisältää Default-ympäristön ja n. määrän organisaation itsensä määrittelemiä ympäristöjä.

Power Platform on Azure-pilvialustan päällä oleva palvelu, jolloin siihen myös vaikuttavat Azure AD:ssa määriteltävät säännöt ja käyttäjähallinnan rajoitukset. Käytännössä kaikki Power Platformin logiikka ja data on Azuren pilvipalvelun komponenteilla toteutettu, mutta tekninen toteutus on käyttäjältä piilossa. Tämän vuoksi Azure-pilviympäristössä toteutetut komponentit ovat yhteensopivia Power Platformin kanssa. Lisenssien hallinnan osalta Power Platformin ja Dynamics 365 -lisenssien hallinnointi nivoutuu Microsoft 365 -tenanttiin ja sitä kautta lisenssihallinnointiportaaliin. Toisin sanoen pääsyn ylätason hallinta tapahtuu Azure AD:ssa ja käyttäjien lisenssi hallinnointi Microsoft 365 -portaalissa. Arkkitehtuuri kuvattu kuvassa 1 alla. 

Kuva 1: Power Platform -arkkitehtuuri

Power Platform -ympäristöjen hallinnointi tapahtuu hyödyntämällä työkaluiksi tarkoitettuja Microsoftin portaaleita, joilla jokaisella on oma tarkoitus. Portaalit jakautuvat kahteen aliryhmään, jotka on kuvattu alla kuvassa 2:

1. Hallinnointiportaaleihin, joissa suoritetaan ympäristöjen, kokonaisuuden ja lisenssien hallintaa.
2. Tekijäportaaleihin, joissa hallinnoidaan ja kehitetään ympäristöjen sisällä olevia komponentteja kuten Power Appeja, Power Automateja ja CDS Entiteettejä.

Kuva 2: Power Platform -hallintaportaalit

Power Platform-ympäristöjen perustaminen ja käytön määrittely

Organisaation siirtyessä Power Platform -alustalle on ensimmäiseksi hyvä määritellä, miten organisaatiossa halutaan kehittää Power Platform -ratkaisuja, sekä miten niiden sovellusten kehittämisen prosessia ja elinkaaren hallintaa halutaan toteuttaa käytännössä. Tarvitaan operatiivisen tason toteutussuunnitelma sekä strategia, jotka määrittelevät mitä vaatimuksia kehitystoiminta asettaa Power Platform -ympäristöille ja minkälaisia ympäristöjä halutaan organisaatiossa käyttää.

Toisin sanoen määritellään Power Platformin ympäristöstrategia. Vastaavanlainen strategia määritetään myös paikallisverkon arkkitehtuurissa palvelinympäristölle, jolloin määritetään miten palvelimia tullaan käyttämään ja mitkä palvelimista palvelevat mitäkin ratkaisua. Strategian tarkoitus on määritellä selkeästi Power Platformin osalta:

• Ympäristön perustamiskäytännöt eli kuka organisaatiossa saa perustaa Power Platform -ympäristöjä ja millaisella hyväksyntäprosessilla päätetään ympäristön perustamisesta. Tähän liittyen on hyvä myös määritellä vastuut ympäristöjen perustamisen ja ylläpidon osalta. Yleensä ylläpitäjät päättävät ympäristöjen perustamisesta ja perustavat niitä erinäisten kehitysprojektien käyttöön. Tällöin kehittäjät pyytävät ylläpitäjiltä uutta ympäristöä ja ylläpitäjät luovat ympäristön tarpeen mukaisesti.
• Ympäristökohtainen tietoturvamäärittely eli mitä tietoja kussakin ympäristössä käsitellään ja miten tätä tietoa siirretään ympäristöjen välillä. Voidaan esimerkiksi päättää, että tietyn yksikön tietoja ei haluta jakaa toisille yksiköille tai että tuotantodataa ei haluta replikoida yksittäisten projektien kehitysympäristöihin.
• Kehitettävien sovellusten elinkaarihallinta ja sen tukeminen ympäristöillä. Käytännössä kehitys, testaus ja tuotantoympäristöjen ja niiden tarpeiden tunnistaminen ja kuvaus siitä miten sovelluksen kehitys ja ympäristöjen välinen siirto toteutetaan.
• Ympäristöjen jaottelu liiketoimintojen, maa-alueiden tai vastaavien mukaan. Isommissa organisaatioissa voi tulla tarve jakaa ympäristöjä eri toimipisteiden, maa-alueiden tai tulosyksiköiden välillä. Näissä jaoissa tulisi aina huomioida yhteisen datan saatavuus ja sen turvaaminen. Jokaisessa ympäristössä on oma datansa, joka ei näy toiseen ympäristöön, ellei sitä integraation kautta replikoida.

Yleisimmin käytetty jakotapa on Dynamics 365 CE -kehityksestä tuttu kehitys-, testi- ja tuotantoympäristöön jakaminen. Tämä jako on kuvattu alla olevassa kuvassa 3. Yleensä yhdellä organisaatiolla on nämä kolme ympäristöä, joissa tarvittava kehittäminen tapahtuu.

Kuva 3: Tarvekohtainen ympäristöjako

Default-ympäristö jätetään henkilökohtaisen kehittämisen ja kokeilun ympäristöksi, jossa käyttäjät voivat tehdä henkilökohtaisia sovelluksia ja omaa työtä helpottavia Power Automate -ratkaisuja. Näiden lisäksi kriittisille projekteille voidaan luoda ympäristöt, joissa kehitetään vain tämän projektin sovelluksia. Tästä ympäristöstä voidaan sitten viedä muutoksia yhteiseen kehitysympäristöön.

Mikäli organisaatio jakautuu useampaan yhtiöön tytär- ja emoyhtiösuhteilla, voidaan ympäristöjä tehdä kunkin yhtiön omaan tarkoitukseen. Näin on järkevä toimia, jos yhtiöiden data on täysin erillistä, jolloin integraatiotarpeita ei synny. Sama pätee toimipistekohtaisiin ratkaisuihin. Molemmissa tapauksissa erilliset ympäristöt voivat muodostua ongelmaksi yhteisesti käytetyn datan osalta turhan replikoinnin, tietokapasiteetin tuhlaamisen ja kokonaisuuden kompleksisuuden muodossa.

Kuvassa 4 on kuvattu Contoso -konsernin ympäristöt, jotka on jaettu maa-alueittain ja joissa jokaiselle maa-alueelle on annettu oma kehitys-, testi- ja tuotantoympäristö. Kun ympäristöstrategia tai käytänteet on päätetty, voidaan siirtyä määrittelemään tietoturva- ja käyttäjähallintakäytänteitä, joilla tieto ja käyttö ympäristöissä turvataan.

Kuva 4: Kuvitteellisen Contoso-konsernin maantieteellisiin alueisiin pohjautuva ympäristöjako.

Tietoturva ja käyttäjähallinta Power Platformissa

Power Platform-ympäristöjen datan turvallisuuden ja käyttäjähallinta muodostuvat viidestä kerroksesta. Alla oleva kuva 5 havainnollistaa kerrokset järjestyksessä, josta voi myös hahmottaa miten pääsynhallinta määräytyy ylhäältä alaspäin.

Kuva 5: Power Platform -pääsynhallinnan kerrostumat.

Kerroksista ensimmäinen on koko Azurea määrittävä Azure AD Conditional Access -kerros. Tämän tietoturvan määrittely tapahtuu Azure-portaalin kautta ja se määrittää:

1. Käyttäjät, joilla on pääsy Azure tenanttiin. Pääsy määritetään Microsoft 365 -tunnusten perusteella.
2. Azure security -käyttäjäryhmät, joilla voidaan hallinnoida samaan ryhmään kuuluvien käyttäjien oikeuksia. Näillä voidaan esim. määritellä tietyn Dynamics 365 Customer Engagement -ympäristön kaikki käyttäjät tai vaikkapa asiakaspalveluntyöntekijät, joilla on samat alustan käyttötarpeet.
3. IP-osoiterajoitukset, joilla voidaan päästää sisään vain yrityksen oman IP-avaruuden sisältä tuleva liikenne.
4. Laitekohtaiset rajoitukset, jolloin vain erikseen luvitetuilla laitteilla pääsee organisaation Azure tenanttiin.
5. MFA eli Multi Factor Authentication -tunnistus, joka vaatii käyttäjän tunnistautumisen esim. matkapuhelimella sisäänkirjautumisen yhteydessä.
6. OAUTH2-protokolla, jolla voidaan rajata vain hyväksyttyjen sovellusten liikenne Azure tenantissa.

Käytännössä Azure tenantin tällä tasolla voidaan ottaa käyttöön saman tasoisia suojauksia, joita tavallisesti on totuttu käyttämään paikallisissa yritysverkoissa. Erona on huomattavasti helpommin toteutettava ratkaisu, jota tuetaan Azure-portaalin käyttöliittymällä. Lisäksi organisaatio voi valita eri pääsynhallinnan rajoitukset juuri omien tarpeidensa mukaan.

Toinen, kolmas ja neljäs kerros ovat niin kutsuttuja ympäristön turvallisuus- ja pääsynhallintakerroksia. Näillä voidaan määritellä ympäristökohtaisesti käyttäjien pääsy ja oikeudet ympäristön komponentti- ja datatasolla. Ympäristötason turvallisuus- ja pääsynhallinnan luonne määräytyy vahvasti sillä, onko ympäristössä käytössä Common Data Service eli CDS vai ei.

Mikäli CDS ei ole käytössä, käyttöoikeusroolivaihtoehdot ovat käytännössä ympäristön tekijä ja ympäristön järjestelmänvalvoja. CDS-tietokannan provisioinnin mukana ympäristöön tulee tietokanta ja sen hallinta, jonka tietueiden hallintaa hallinnoidaan laajemmalla käyttöoikeusroolituksella, jolla otetaan kantaa tiedon omistajuuteen. Tällöin hallinnoinnista vastaavat henkilöt voivat määritellä omat käyttöoikeusroolit tai käyttää standardirooleja CDS-datan hallintaan. CDS-tietokannan sisältävässä ympäristössä ympäristö tekijän roolin lisäksi kehittäjät tarvitsevat järjestelmän mukauttajaroolin.

Azure AD -käyttäjähallinnan ja käyttäjäroolien hallinnan lisäksi Power Platformissa on viides pääsynhallintakerros, jolla hallinnoidaan Azure tenanttien välistä liikennettä käyttämällä tenanttirajoituksia. Tenanttirajoituksilla tietohallinto voi hallita eri Azure tenanttien välistä liikennettä joko omasta tenantista ulos päin tai ulkoa oman tenantin sisälle. Tenanttien välissä voi olla liikennettä eri sovellusten yhdistimien (connectoreiden) ja API-rajapintojen kautta. Tämä toki edellyttää käyttöoikeuksia. Joissain tapauksissa tällaista käyttöä halutaan estää tai hallita tarkasti, mitkä tenantit saavat kommunikoida keskenään. Tenanttien välistä liikennettä voidaan hallita joko Azuren tenant restriction -toimintoja käyttäen kaikilta Azure Saas -palveluilta tai erillisillä tukitiketeillä vain API-rajapinnoilta, joita käyttävät Canvas Apit ja Power Automate -ratkaisut.

Ylläpitoroolien ja ylläpitovastuiden määritteleminen

Microsoft tarjoaa valmiiksi luontaiseen jaotteluun perustuvat ylläpitoroolit Power Platformin, Azuren ja Microsoft 365:n osalta. Tärkeimmät ylläpitoroolit Power Platform ja Dynamics 365 CE -ympäristöjen osalta ovat Azure AD:sta vastaava Azure Global Administrator, Microsoft 365 tenantista vastaava Microsoft 365 Global Administrator ja Power Platform/Dynamics 365 Service Administrator. Alla olevassa kuvassa 6 näkyy ylläpitäjäroolien vastuualue ja toiminnot. Lisäksi kuvassa on kuvattu miten Power Platform ympäristö rakentuu suhteessa Microsoft 365 tenanttiin ja Azure Ad:hen ja miten käyttäjäoikeudet tarkentuvat, kun mennään ylimmältä tasolta (Azure AD) alimmalle tasolle (yksittäiset Power Platform ja Dynamics 365 CE -ympäristöt).

Kuva 6: Ylläpitoroolit, vastuut ja tehtävät sekä pääsynhallinakerrostuma.

Ylläkuvattujen roolien ja niiden yhdistelmien käyttö IT-organisaation sisällä voi vaihdella suuresti organisaatiokohtaisesti perustuen kunkin IT-organisaation henkilöstö- ja vastuurakenteisiin.

1. Pienessä organisaatiossa voi olla yksi ylläpitäjä, jolloin hänellä on kaikki yllä mainitut roolit.
2. Toisaalta jos organisaatiossa on useampi henkilö, voidaan roolit jakaa henkilöiden vastuiden mukaisesti.
3. Organisaation käyttäessä alihankkijoita ja konsultteja voidaan ylläpitoroolit jakaa kunkin alihankkijan vastuualueen mukaan.

Näin ylläpitoprosessiin saadaan selkeät vastuualueet, joilla kunkin toimijan vastuut selkeytetään ja valtuudet ylläpidetään.

Esimerkiksi organisaation oma IT vastaa Office-työkaluista ja lisensseistä, pilvialusta eli Azure hankitaan pilvipalveluntarjoajalta (CSP) ja Power Platform -kehittäminen ja ylläpito hankitaan konsulttiyritykseltä. Tällöin luontainen jako olisi antaa oman IT:n edustajalle Microsoft 365 Global Administrator -oikeudet, CSP:lle Azure Global Admistrator -oikeudet ja Power Platformista vastaavalle konsulttitalolle Power Platform Service Administrator -oikeudet. Tämän yhteydessä olisi hyvä sopia käyttöoikeuksien ja pääsynhallinnan tilaamisesta toimijoiden välillä ja määritellä toimintatapa, jolla varmistetaan sulava toimivuus eri toimijoiden kesken. Käyttöoikeuksien avulla voidaan selkeästi määritellä kunkin toimijan vastuut ja velvollisuudet.