HR tietää, kuka lähti, mutta Entra ID ei

Jos lähteneen työntekijän tunnuksen sulkeminen jää ainoastaan HR:n IT-tuelle lähettämän Teams-viestin varaan, tunnukset voivat pahimmassa tapauksessa jäädä auki kuukausiksi tai jopa vuosiksi. Kun HR-järjestelmästä tehdään Microsoftin API-pohjaisella provisioinnilla käyttäjätunnusten lähde, Entra ID luo ja disabloi tunnukset HR-datan mukaan jo P1-lisenssillä. Governancea tarvitaan vasta, kun tunnuksen ympärille halutaan kehittyneempi joiner-, mover- ja leaver-prosessi.

Keskustelin erään asiakkaamme kanssa, joka työskentelee noin sadan hengen yrityksessä. Heillä oli HR-järjestelmä ajan tasalla, mutta Entra ID ei. Lähteneiden tunnukset olivat yhä aktiivisina, osa kuukausia lähdön jälkeen. Kysyin, kuka vastaa tunnusten sulkemisesta. Vastaus oli: ”HR laittaa siitä Teamsissa viestin. Yleensä”. Jokainen IT-tuessa tai ylläpidossa työskennellyt tietää sen tunteen, kun iltapäivällä klo 15.47 tulee viesti: "Voitko poistaa lähteneen henkilön tunnukset?", ja olet juuri siinä vaiheessa sulkemassa työkonetta.

Käsin tehty käyttäjähallinta menee tyypillisesti näin: Entra-portaali auki, käyttäjä sisään, lisenssi kiinni, ryhmät kohdilleen ja väliaikainen salasana esihenkilölle. Lopputulos toimii, mutta homma vie puolisen tuntia, ja yleensä joku ryhmäjäsenyys unohtuu. Pienessä mittakaavassa tämä on ihan kohtuullista, mutta jokainen käsin tehty joiner-, mover- tai leaver-prosessi on silti mahdollisuus unohtaa jotain, ja leaver-päässä unohdus on tietoturvariski.

Mitä Entra ID -provisiointi oikeastaan tekee?

Lyhyesti: HR-järjestelmästä tulee tunnusten lähde, ja Entra ID seuraa perässä. Ennen tämä tarkoitti käytännössä Workdayta tai SuccessFactorsia, joille Microsoftilla on valmiit yhteydet. Pienemmille organisaatioille ne ovat usein aivan liian raskaita.

Peli muuttui Microsoftin API-pohjaisen provisioinnin myötä. Tunnusdatan lähde voi olla HR-sovellus, SQL-taulu tai käytännössä mikä tahansa järjestelmä, jota voi koneellisesti lukea. Lähde liitetään Entraan millä tahansa automaatiotyökalulla, oli se sitten PowerShell-skripti, Logic App tai Power Automate. Karkeasti kuvio menee näin:

1. Entraan luodaan Microsoftin galleriasta löytyvä API-driven inbound provisioning -sovellus. Huomaa, että sovelluksia on kaksi: toinen Entra ID -identiteeteille ja toinen ympäristöihin, joissa on perinteinen Active Directory -toimialue.
2. Sovelluksessa määritellään, mihin käyttäjätunnuksen kenttään mikäkin HR-tieto menee. Samalla tietoa voidaan muotoilla, esimerkiksi muodostaa käyttäjälle automaattisesti etu- ja sukunimestä sähköpostiosoite.
3. Automaatio lukee henkilötiedot lähteestä ja lähettää ne JSON-muodossa rajapinnalle.
4. Provisiointipalvelu päättää itse, luodaanko käyttäjä, päivitetäänkö, aktivoidaanko vai disabloidaanko hänet.
5. Tämä kaikki näkyy Entra ID:n lokeissa eli jälkikäteen voidaan osoittaa mitä tapahtui ja miksi.

Merkittävin ero aiempiin malleihin on, että Entra hoitaa kaiken vertailun ja logiikan. Välissä oleva skripti vain välittää tietoa HR-järjestelmän ja rajapinnan välillä.

Mitä kevyillä lisensseillä saa?

API-pohjainen inbound-provisiointi on saatavilla jo Entra ID P1 -lisenssillä. Kun siihen lisätään dynaamiset ryhmät ja ryhmäpohjainen lisensointi, perusputki on aika valmis. Uusi työntekijä lisätään HR-järjestelmään, Entra luo tunnuksen, dynaaminen ryhmä nappaa hänet osaston perusteella, ja lisenssit ja sovellukset seuraavat perässä. Kukaan ei klikkaa mitään.

Yksi rajoite kannattaa tietää. P1/P2-lisenssillä tenantilla on 2 000 API-kutsun vuorokausiraja ja Governance-lisenssillä 6 000. Yhteen kutsuun mahtuu 50 operaatiota, joten pienen ja keskisuuren organisaation tarpeisiin tämä riittää reilusti, kunhan kutsuja ei tehdä käyttäjä kerrallaan.

Entra ID Governance hoitaa sen, mitä tunnuksen ympärillä tapahtuu

Lifecycle Workflows vaatii Entra ID Governance -lisenssin, joka sisältyy esimerkiksi Entra Suite -pakettiin. Workflowt käynnistyvät HR:stä tulevien attribuuttien perusteella: employeeHireDate käynnistää joinerin ja employeeLeaveDateTime leaverin. Provisiointi siis tuo päivämäärät, ja Governance tekee niiden pohjalta automaatioita. Muutama esimerkki valmiista tehtävistä:

• Joiner: Temporary Access Pass generoidaan ja lähetetään esihenkilölle sähköpostilla, ja se alkaa olla voimassa työsuhteen alkamispäivänä. Lisäksi uusi työntekijä saa tervetuloviestin ja esihenkilö muistutuksen ennen aloitusta.
• Mover: Esihenkilö saa tiedon siirrosta, ja vanhat käyttöoikeudet voidaan purkaa ajastetusti. Tämä on se kohta, jossa ”kymmenen vuotta talossa, oikeudet kaikkialle” -ongelma yleensä ratkeaa.
• Leaver: Esihenkilö saa sähköpostin ennen viimeistä päivää, viimeisenä päivänä ja sen jälkeen. Tili disabloidaan, tokenit mitätöidään, ryhmä-, Teams- ja lisenssijäsenyydet poistetaan, ja lopulta tili poistetaan.

Jos valmiit tehtävät eivät riitä, mukaan voi kytkeä Logic Appin custom task extensionina. Sillä voi hoitaa vaikkapa tiketin avaamisen, läppärin palautuspyynnön tai minkä tahansa muun asian, johon on rajapinta.

Mitä sitten kannattaisi tehdä?

On vaikea antaa yleispätevää ohjetta, sillä lähtötilanne ei ole koskaan vakio. Suosittelemme Not Bad Securityllä asiakkaille karkeasti seuraavaa mallia:

1. Ensin kuntoon totuuden lähde. Jos HR-data on kolmessa Excelissä ja yhden ihmisen päässä, mikään automaatio ei pelasta tilannetta. Henkilön nimi, osasto, esihenkilö, aloitus- ja lopetuspäivä yhdessä paikassa riittävät alkuun.
2. Jos tunnukset syntyvät ja disabloituvat HR-datan mukaan, moni pieni organisaatio pärjää P1-tason perusprovisioinnilla pitkälle. API-pohjainen inbound-sovellus, pieni PowerShell- tai Logic App -putki HR:stä Entraan, dynaamiset ryhmät ja ryhmäpohjainen lisensointi.
3. Governance kannattaa ottaa mukaan, kun automaatiota halutaan laajentaa tunnuksen ympärille, viimeistään silloin, kun käsityö alkaa näkyä riskinä tai kustannuksena. Erityisesti Lifecycle Workflows maksaa itsensä takaisin aika nopeasti.

Onko se todella näin simppeliä?

Suoraan sanottuna, ei. HR-data on harvoin niin siistiä kuin toivoisi. Esihenkilökentät ovat usein tyhjiä, ja joku on aina "vähän konsultti ja vähän työntekijä". Mutta jos vaihtoehto on HR:n Teams-viesti "yleensä", on aika vaikea seisoa vakuuttavan tietoturvan takana itsekään. Jos vastaus kysymykseen "kuka sulkee lähteneen tunnukset" on "se, joka huomaa", on aika pysähtyä ja pohtia, mikä prosessissa täytyy korjata. Tekniset kontrollit hoitavat oman osansa, mutta ne tarvitsevat ajantasaisen datan, jonka varassa toimia.

Seuraavan kerran, kun joku pyytää tunnuksia uudelle aloittajalle, pysähdy hetkeksi miettimään: kuka tietää, että tämä ihminen on olemassa, kuka tietää, kun hän lähtee, ja kuka varmistaa, että tunnus lähtee hänen mukanaan?