ATK-Miehen kesäinen erityistehtävä johtoryhmän boomereilta – Inspiroippa NDA-sopimuksen automaatio meille huomiseksi
Disclaimeri
Tämän postauksen graafiset kuvitukset ovat vain esimerkkejä. Kohtele palkkakulejasi, kuin erityisherkkiä indigolapsia ja he vastaavasti saattavat jopa sitoutua konsernisi pelimerkkeihin.
Disclaimeri päättyy
Sitten siihen pihviin eli asiaan.
Kuvitellaan taas skenaario, eli olet saanut konsernin ainoana ATK-miehenä tehtävän, jonka puitteissa halutaan automatisoida seuraavat käsityötoimet:
- Haluamme esittää kaikille uusille käyttäjille automaattisesti konsernin käyttöehto- ja NDA-sopimuksen
- Haluamme hyväksymisistä ja kieltäytymisistä selkeän listan, eli kuka ja milloin
- Eli haluamme rimpuilla irti penseästä käsityökulttuurista
- Ja huomiseksi MVP tulille kiitos
Kuten kaikki hienot tehtävät, niin tämäkin hanke aloitetaan sillä, että ruinataan mieluiten lakiosastolta tai edes vuokrajuristilta se lappu PDF-formaatissa ulos, jota sitten automagian merkeissä esitellään uusille rekryille. Vaikkakin ATK-osasto on täynnä valopäitä, osaajia sekä tekstuaalisesti usein kyvykkäitä vesseleitä, niin on kuitenkin parasta, että sopimukset laatii joku kyseisen alan asiantuntija.
Ja toteutuksen kimppuun
Kun lappu on leivottu sieluttomasta koneesta ulos, on aika siirtyä Azure AD:n puolelle ja tarkemmin siellä Conditional Accessin aina niin säkenöivään maailmaan:
Täältäpä sitten löytyy hallintarajapintaa terms of usen esittelyyn:
Tässä esimerkissä teimme vain yhdellä kielellä julkaistavan Terms of Use -määrityksen, joka pitää avata laajemmaksi hyväksymisen/hylkäyksen yhteydessä.
Kyseinen soppari ei myöskään vanhene eikä sitä tarvitse uudelleen hyväksyä tietyin intervallein. Lisäksi naitamme pilveen määritellyn ToU:n myöhemmässä vaiheessa uuteen ja sähäkkään CA-politiikkaan (kohta Create CA policy later). Samaan ToU-määritykseen voimme siis naittaa useamman eri kielisen näkemyksen lapusta ja voimme myös määrittää lapukkeiden automaattisen vanhenemisen.
Kun lappu on pilven suurkoneessa, siirrymme CA-politiikan määrittelyyn.
Käytännössä vain mielikuvitus on taas rajana, miten organisaatio haluaa määritellä kohdat users, cloud apps or actions ja conditions. ToU:n tulkintapakko sitten päjähtää näiden ja vars. ToU-määrityksien mukaisesti halutuille käyttäjille tai käyttäjäryhmille.
Tarkkasilmäisimmät teistä huomasivat, että CA-politiikkapatteristo antaa mahdollisuuden pakottaa erityyppisiä soppareita, erityyppisten sovelluksien käyttäjille ja/tai käyttäjäryhmille. Esim. vaikkapa niin, että koululaitoksen opettajat hyväksyvät erihenkistä lappua vs. laitoksen aikuisopiskelijat.
Ahoyy ja kohti loppukäyttäjäkokemusta aiheen tiimoilta
Julkaisimme siis yhden kieliversion lapusta, teimme sähäkän CA-politiikan ja kohdistimme sen testimielisesti Teppoon. Teppo, kun kirjautuu seuraavalla kerralla organisaation helmoihin:
Ja pakkohan se on sääntöjen mukaan laajentaa, jotta pääsee Teppo lukemaan, että millaiseen enkelimurskaamoon sitä on päädyttykään töihin taas.
Ps.
Mobiliiystävällinen sopparin taitto on myös mahdollista tehdä, tällöin kannattaa hyödyntää hieman suurempaa fonttia PDF-dokkarissa.
Kun soppari on avoinna, on Teppolla tosiaan vaihtoehdot tasolla ei tai joo. Jos Teppo suuressa viisaudessaan vastaa, että ei eli decline, on tulos tämä:
Eli riippuen mihin appeihin etc. CA-politiikka kohdistettiin, niin Teppolla on kieltäytymisen jälkeen aika vähän tuottavuustilbehöörejä käytössään.
Teppo ajetaan siis henkiseen nurkkaan ja pakkopakottaen hän painaa acceptia. Tuottava työ saa siis alkaa viimein.
Ja sitten se hyväksyntien auditointi ja hilloaminen
Microsoftin virallinen liturgia ilmaisee hieman hähmäisesti, että kuinka kauan ja missä tätä taulua säilytellään, mutta käytännössä lupaus on, että niin kauan kuin julkaistu ToU on mukana menossa, on siihen mahdollista palata kiinnostuskiikarein.
Kaivetaan julkaisu esiin Azure AD:n syövereistä ja klikataan sitä:
Vaikkakin tässä esimerkissä Teppo kaatuili jo hyväksyntään, näyttävät saldot vielä nollaa. Klikataan nollatili auki ja tutkitaan se todellinen todellisuus. Numeroarvojen päivittymiseen nimittäin saattaa kulua hieman Microsoft-aikaa:
Jos luotto Microsoftin pysyväisyyssäilytykseen ei ole aivan täysin jiirissä tai joku compliancen jännittävä prosessi vaatii muuta varannetta käyttöön, kohdasta download voi kotiuttaa CSV-tiedostona koko pumaskan. Aina 250.000 rekkariin asti.
Testeissä rekkari näyttäisi pysyvän liki muuttumattomana, vaikka käyttäjäobjekti poistuisi välillä roskakorin kautta bittitaivaaseen. Kunhan se itse ToU-lappu pysyy järjestelmässä.
Tarkan proseduraaliset organisaatiot saattanevat haluta kuitenkin ottaa ajoittain audit trailin alas. Varsinkin, jos tämä rekkari on mielletty säilytettävä pysyvästi(SP) -henkiseksi.
Käyttistä – Onko sitä?
Käyttökohteet ja lappujen lopulliset kohdistukset (käyttäjä, alusta, palvelu tai jopa sovellus) riippuvat sitten paljon itse organisaatiosta. Riittääkö esim. yksi ainoa universaali kieltojen täyttämä lappu vai toivotaanko jotain hienojakoisempaa menettelyä.
Kaiketi tätä kanavaa voi myös käyttää piskuiseen kriisiviestintään tyyliin ” 26.5.2023 alkavat konsernimme YT-neuvottelut. Pitäkää huiveistanne kiinni! t. Toimari.”
Näihin kuvituksiin ja tunnelmiin, kohti seuraavaa kertaa ja sen yli!
