Power Platform Governancea ilman Premium-lisensointia tai kapasiteettia?

Power Platform Governancea ilman Premium-lisensointia tai kapasiteettia?

Power Platform Governancesta puhuttaessa isossa roolissa on aina Power Platform -ympäristöt, ja syystäkin sillä ne näyttelevät isoa roolia koko governance ajattelussa.

Ympäristöjen ideana on eriyttää Power Platform -toteutuksia omiin, loogisiin osioihin (=ympäristöihin). Näin niiden hallinta ja monitorointi on huomattavasti helpompaa ja jopa ”tietoturvallisempaa”.

Todettakoon myös, että ei ole olemassa vain yhtä oikeaa Governance-mallia joka sopii kaikille. Jokainen yritys/organisaatio määrittää itse itselleen sopivan ympäristöstrategian ja governancen niiden osalta.

Ihan ilmaista ympäristöjen luonti ei ole koska niiden luonti vaatii Power Platform -kapasiteettia jota saa, yllätys yllätys, erilaisilla lisensseillä/lisenssikomboilla.

Tähän voidaankin heti todeta että ei, tähän ei auta nyt ne Business Premium, M365E3/E5 -lisenssit, vaikka niissä kuinka niitä muita ihania kilkkeitä onkin.

Ympäristöt ja kapasiteetti

Kapasiteettiin vaaditaan Power Apps / Power Automate / Dynamics365 -pohjaisia lisenssejä jotka eivät sisälly M365-lisensseihin.

Esimerkiksi Power Apps Premium / Power Automate Premium -lisenssit antavat tuota kapasiteettia. Kapasiteettia saa myös erillisillä kapasiteetti addon -lisensseillä.

Alla yksi näkemys tai ajatus, millä tavalla erilaisia Power Platform -ympäristöjä voisi käsitellä:

Teams-pohjaiset ympäristöt

Yllä olevasta kuvasta puuttuu Teams-pohjaiset ympäristöt jotka syntyvät aina kun Teamin omistaja päättää aktivoida Teamsille Power-kyvykkyydet (luoda Teamille Dataversen).

Näitä syntyy helposti myös vahingossa kun Teamien omistajat seikkailevat Teamsissa ja löytävät tiensä Teamin Power Apps -osuuteen. Tässä helposti syntyy Teams-pohjainen ympäristö.

Teams-pohjaisten dataverse-sovellusten käyttö ei vaadi premium-lisenssiä käyttäjältä. Nämä ympäristöt ovat myös rajoittuneempia vs. ”täysveriset ympäristöt”.

Teams-ympäristöt myös tuhoutuvat itsestään jos niissä ei havaita käyttöä:

Entä jos syystä tai toisesta ei ole niitä Premium-lisenssejä eikä kapasiteettilisenssejä eikä niitä tulla myöskään saamaan?

Tietysti tilanne on tässä hieman kinkkinen ja jos jonkinlaista governancea haluaa tehdä, pitää myös sitten tehdä kompromisseja.

Kuten aikaisemmin tuossa todettiin, mahdollisuus eriyttää toteutuksia eri ympäristöihin on avaintekijä governancessa. Nyt jos tuo avaintekijä ei ole mahdollinen, tarkoittaa se käytännössä sitä, että ”kaikki munat ovat samassa korissa” eli toteutukset asuvat kaikki sitten siellä oletusympäristössä tai Teams-ympäristöissä (joissa on omat rajoitteensa)

Voimme siis tässä skenaariossa governoida tuota yhtä oletusympäristöä + Teams-pohjaisia ympäristöjä.

Oletusympäristön osalta helposti käy niin, että kun me luomme rajoituksia tuohon ympäristöön, astumme jonkun toteutuksen varpaille. Kun me sitten sallimme kyseisen toteutuksen käyttämät yhdistimet, sallimme ne samalla myös muille toteutuksille/tekijöille tässä ympäristössä.

Katsotaanpa mitä kaikkea voimme tehdä oletusympäristön ja näiden Teams -ympäristöjen osalta.

Tenantin yleiset Power Platform -asetukset

Power Platform Admin Centerissä on asetuksia jotka ovat koko tenantin laajuisia ja näiden vääntäminen oletusasetuksilta on suotavaa.

Näitä asetuksia kannatta myös tarkatella ja rukata vaikka olisikin ne premium-lisenssit ja kapasiteettia harrastaa ympäristöjen luontia. 🙂

Näistä voisi nopeasti todeta että:
– Copilot = Ei mitään syytä miksi ei kannattaisi laittaa päälle (ellei jo ole). Appien tekijät voivat sitten udella AI:ltä vinkkejä rakenteluun
– Developer- Production- Trial environment assignments kannattaa vääntää asentoon ”Only specific admins”
– Add-on capacity assigments kannattaa vääntää asentoon ”Only specific admins”
– Analytics kannattaa vääntää päälle
○ Tämän avulla saadaan hieman parempaa käyttöanalytiikkaa out-of-the-box
○ Analytiikkadata tallentuu maantieteellisesti sinne, jossa tenantin oletusympäristö asuu (eli sinne missä 365-tenantti asuu)

Data Loss Prevention (DLP) luonnit ja kohdennukset

Tässä ideana on luoda mahdollisimman tiukka policy sekä oletusympäristölle, että syntyville Teams-ympäristöille. Policyja voi tarvittaessa sitten aina höllentää ja kohdentaa eri tavalla jos havaitaan että jossakin ympäristössä tarvitaan jokin estetty yhdistin.

Policy oletusympäristöä varten

Lähdetään luomaan policya, joka kohdennetaan oletusympäristöön.

Annetaan policylle kuvaava nimi:

Seuraavaksi ideana on siirtää jokainen ei-blokattavissa oleva yhdistin ”Business” -kategoriaan:

 

Näiden lisäksi etsitään listalta vielä ”Microsoft Forms” -yhdistin ja siirretään se myös Business-kategoriaan. Tämä siksi että käytännössä näitä halutaan kuitenkin käyttää tai käytetään jo esim. organisaation sisäisissä prosesseissa.
Toki tämänkin voi tietysti blokata, jos haluaa. 🙂

Jos tiedossa on joitain muita yhdistimiä jotka syystä tai toisesta pitää tai halutaan sallia oletusympäristössä, siirretään nekin Business-kategoriaan.

Loput yhdistimet blokataan:

Otetaan vielä myös kantaa uusin yhdistimiin joita julkaistaan tasaisin väliajoin Power Platformiin. Asetetaan jokainen uusi yhdistin blokatuksi oletuksena:

Ruudun oikeasta yläkulmassa löytyy kohta:

Asetetaan tämä:

Seuraavaksi voidaan ottaa kantaa custom-yhdistimiin eli jos organisaatio esim. itse kehittää omia yhdistimiään.

Tässä tapauksessa estetään kaikenlaiset custom-yhdistimet, varsinkin oletusympäristössä:

Seuraavaksi päästäänkin kohdentamaan policy oletusympäristöön:

Valitaan oletusympäristö listalta (Type = Default)

Huom. kuvassa oletusympäristö on nimetty ”Personal” -nimiseksi. Lähtökohtaisesti nimi on sama kuin tenantin nimi.

Lopuksi tallennetaan policy:

Nyt meillä on luotuna policy joka ottaa kantaa oletusympäristöön. Vielä pitäisi luoda policy joka ottaa kantaan ”kaikkiin muihin” ympäristöihin eli tässä tapauksessa Teams-ympäristöihin koska muita ympäristöjä meille ei ole syntymässä ilman premium-lisenssejä/kapasiteettilisenssejä.

Käytännössä luodaan täysin saman sisältöinen policy mutta kohdennus menee eri tavalla:

Otetaan kohdennuksesta pois oletusympäristö:

Tämän jälkeen tallennetaan policy.

Lopputuloksena meillä on 2 policya:

– Policy oletusympäristöä varten
– Policy muita ympäristöjä (Teams-ympäristöt) varten

Olisiko voinut tehdä vain yhden policyn jonka kohdentaa kaikkiin ympäristöihin?
Kyllä, homman voi tehdä näinkin:

Mutta jos tulee tilanne vastaan jossa Teams-ympäristöissä halutaan sallia jokin yhdistin jota ei haluta sallia oletusympäristössä, niin sitten tullaan tietysti taas siihen että pitää luoda vähintään 2 policya.

 

Yhteenveto

Luonnollisesti, jos eteen alkaa tulemaan erilaisia ympäristökohtaisia tarpeita, pitää näitä policyja tarkastella ja mahdollisesti muuttaa niiden kohdennuksia sekä luoda ehkä lisääkin policyja joita sitten kohdennetaan niihin erikoiskohtelua vaativiin Teams-ympäristöihin.

Yrityksen/organisaation Power-tekijöille on myös hyvä muistuttaa että mitään kriittisiä tai edes semi-kriittisiä toteutuksia ei tehdä hurisemaan sen oman tunnuksen alle vaan esim. service-tunnuksen alle.

Vielä muistutuksena, tämä kirjoitelma oli tosiaan ajateltu sellaisiin tenantteihin, joihin ei syystä tai toisesta saada tehtyä muita ympäristöjä kuin se oletus + Teams-pohjaiset ympäristöt.

Jokaisen yrityksen ja organisaation tarpeet ovat erilaiset joten näitä säännöstöjä ja asetuksia pitää myös sillä silmällä katsoa. 🙂

 

– Pilviguru / Huru-ukko Jasu Snell