IGA-hallinta
Tämä artikkeli kuvaa IGA-järjestelmänvalvojien tehtäviä, toiminnallisuuksia ja vastuita identiteettien ja käyttöoikeuksien hallintaa ja auditointia varten. Tämä artikkeli ei kuvaa määritysohjeita, vaan kaikki toimet tehdään järjestelmänvalvojan/agentin käyttöliittymästä.
IGA-järjestelmänvalvoja on uusi rooli organisaatioille, jotka ottavat käyttöön ensimmäistä IGA-ratkaisuaan. On tärkeää ymmärtää, että hallintatyö vaatii vähintään yhden tai kaksi henkilöä myös käyttöönoton jälkeen. Samalla on yhtä tärkeää tiedostaa, että IGA-järjestelmänvalvojan työhön tarvittava resursointi on suurimmillaan juuri ratkaisun käyttöönoton jälkeen. Se tasaantuu vähitellen päivittäisiksi rutiineiksi, jolloin aikaa vapautuu myös muihin tehtäviin.
IGA-järjestelmänvalvoja on eri rooli kuin IGA-määritysten järjestelmänvalvoja, ja näiden kahden ero on siinä, että jälkimmäisellä on pääsy määrityksiin. Asiakas voi päättää, annetaanko nämä roolit yhdelle henkilölle vai onko tarpeen pitää ne erillään.
Ensimmäiset tehtävät
Kun IGA-ratkaisu on asennettu, se toimii täsmälleen käyttötapauksissa kuvatulla tavalla ennen kuin asiakaskohtainen määritys aloitetaan. IGA-järjestelmänvalvojan työhön liittyvät käyttötapaukset toimivat suoraan käyttöönoton jälkeen, mikä tarkoittaa, että kun datan luku on testattu testiympäristössä, on tärkeää saada data tuotantoon mahdollisimman pian, koska se mahdollistaa IGA-järjestelmänvalvojan ensimmäisten tehtävien aloittamisen ja valmiiden raporttien käytön datan laadun varmistamiseksi sekä työjakson ja tilinhallinnan tarvitsemien tietojen täyttämiseksi.
Ensimmäinen datan luku
On tärkeää erottaa ensimmäisten datan lukujen merkitys jatkuvista datan luvuista.
Ensimmäinen datan luku tarvitaan varmistamaan, että kartoitukset ja suhteet on määritetty oikein, ja se mahdollistaa IGA-järjestelmänvalvojille datan laadun validoinnin aloittamisen ja automaation rakentamisen seuraavassa vaiheessa.
Jatkuva datan luku on yleensä ajastettu (esimerkiksi hakemistodatan lukemisessa), ja riippuen siitä, onko ja millainen HR-integraatio on käytössä, datan luvut voivat vaihdella paljon.
Ensimmäistä datan lukua varten asiakkaan on toimitettava:
| Data | Kuvaus | Tyyppi |
| Tilit ja ryhmät (entitlements) |
Asiakkaan on toimitettava tiedot testi- ja tuotantohakemistoyhteydestä/-yhteyksistä. Aikataulusta sovitaan yhdessä asiakkaan kanssa.
Hakemiston tilit luetaan IGA Account -datakortteihin ja ryhmät IGA Entitlement -datakortteihin. Kustannuspaikka-, organisaatioyksikkö- ja titteli-datakortit luodaan IGA-ratkaisuun kaikkien käyttäjiin liittyvien kustannuspaikkojen, organisaatioyksiköiden ja titteleiden perusteella. IGA Access Right Record -tietueet luodaan ryhmäjäsenyyksien perusteella. |
Ajastettu datan luku natiivikonnektorilla |
| Sovellusluettelo |
Tarvitaan, jotta IGA-järjestelmänvalvoja voi aloittaa entitlement-tietojen täyttämisen, koska jokaisen käyttöoikeuden on liityttävä johonkin sovellukseen/palveluun/tietokantaan jne.
Yleensä tämä on kertaluonteinen tuonti, jonka jälkeen sovellusluetteloa ylläpidetään IGA-ratkaisussa. Sovellusluettelo voidaan lukea myös natiivikonnektoreilla, jos asiakas säilyttää sitä toisessa sovelluksessa. |
Kertaluonteinen tuonti |
| HR-tiedosto (testikäyttäjät) |
Tämä vaaditaan, kun HR-integraatio kuuluu IGA-toimituksen laajuuteen.
Käyttäjään liittyvä data luetaan IGA Work Period -datakortteihin, ja kustannuspaikka-, organisaatioyksikkö- ja titteli-datakortit luodaan IGA-ratkaisuun kaikkien käyttäjiin liittyvien kustannuspaikkojen, organisaatioyksiköiden ja titteleiden perusteella.
Tiedosto luetaan testiympäristöön.
Vaikka HR-ratkaisun integraatio toteutettaisiin muulla tavalla kuin tiedostopohjaisena integraationa, ensimmäistä datan lukua varten asiakkaan on toimitettava tiedosto testikäyttäjillä, ja attribuuttien tulee vastata tuotantotiedostoa. |
Kertaluonteinen tuonti ensimmäistä datan lukua varten |
| HR-tiedosto (todelliset käyttäjät) |
Tämä vaaditaan, kun HR-integraatio kuuluu IGA-toimituksen laajuuteen.
Käyttäjään liittyvä data luetaan IGA Work Period -datakortteihin, ja kustannuspaikka-, organisaatioyksikkö- ja titteli-datakortit luodaan IGA-ratkaisuun kaikkien käyttäjiin liittyvien kustannuspaikkojen, organisaatioyksiköiden ja titteleiden perusteella.
Tiedosto luetaan tuotantoympäristöön.
Vaikka HR-ratkaisun integraatio toteutettaisiin muulla tavalla kuin tiedostopohjaisena integraationa, ensimmäistä datan lukua varten asiakkaan on toimitettava tiedosto testikäyttäjillä, ja attribuuttien tulee vastata tuotantotiedostoa. |
Kertaluonteinen tuonti ensimmäistä datan lukua varten |
Datan laadun validointi
Datan laatu on perusta kaikille IGA-käyttötapauksille, ja jos data ei ole ajan tasalla, kestävän ja luotettavan automaation rakentaminen mihinkään IGA-käyttötapaukseen on mahdotonta.
IGA-ratkaisu sisältää työkaluja datan laadun validointiin, ja se on IGA-ratkaisun tärkein ja ensimmäinen vaihe, mutta se on myös tärkeä osa päivittäisiä toimia esimerkiksi silloin, kun IGA-ratkaisu ei voi viedä prosesseja loppuun puuttuvien tai virheellisten tietojen vuoksi.
Datan luvun aikana provisiointi hakemistoon/hakemistoihin on pois käytöstä. Provisiointi voidaan käynnistää vasta, kun datan laatu on varmistettu.
Mitä IGA-järjestelmänvalvojan tulee tehdä?
Tämä tehtävä liittyy organisaatiossa käytettyyn dataan, mutta esimerkkinä IGA-järjestelmänvalvojan on validoitava,
- Organisaatioon liittyvä data on oikein (organisaatioyksiköt, kustannuspaikat, titteli jne.). Datakortit luodaan joko hakemistosta ja/tai HR-ratkaisusta luetun datan perusteella.
- Kutakin organisaatioyksikköä, kustannuspaikkaa ja titteliä kohden on vain yksi datakortti
- Jos niitä on useita, IGA-järjestelmänvalvojan on siivottava data, jotta se vastaa todellista organisaatiodataa.
- Henkilöt ja identiteetit liittyvät oikeaan organisaatiotietoon
- Vain voimassa olevaa dataa on olemassa
- Kutakin organisaatioyksikköä, kustannuspaikkaa ja titteliä kohden on vain yksi datakortti
- Tilit liittyvät oikeisiin henkilöihin ja identiteetteihin
- Työjaksot liittyvät identiteetteihin, henkilöihin ja tileihin.
- IGA Access Right Record -tietueet luodaan oikein hakemiston ryhmäjäsenyyksien perusteella
- Jos HR:stä luetussa datassa on laatuongelmia, ne on korjattava lähdejärjestelmässä ja datan luku IGA-ratkaisuun on ajettava uudelleen
Kuinka paljon aikaa tämä tehtävä vie IGA-järjestelmänvalvojalta?
Se riippuu täysin asiakkaan datan laadun nykytilasta ja HR-ratkaisussa ja/tai hakemistoissa käytettävissä olevasta tiedosta, kuinka paljon aikaa datan laadun parantamiseen tarvitaan. Siksi suositellaan varaamaan aikaa myös HR-asiantuntijalta datan parantamiseen, erityisesti kun tieto tulee HR-ratkaisusta.
Suositus on varata IGA-järjestelmänvalvojalle vähintään kaksi (2) työpäivää datan analysointiin, mutta jos jo tiedetään, että datan laatu on huono ja vaatii paljon parannuksia, suositus on varata viidestä (5) kahdeksaan (8) työpäivään.
Työjakson ja tilinhallinnan asetukset
Työjakson ja tilinhallinnan tiedot on pakko määrittää IGA-ratkaisuun, ja IGA-järjestelmänvalvoja voi helposti muuttaa tai luoda uuden sääntöjoukon eri käyttäjätyypeille.
Yleensä nämä asetukset määritetään IGA-toimituksen alussa, mutta esimerkiksi asiakkaan organisaatiomuutosten tai lisättävien birth right -oikeuksien vuoksi IGA-järjestelmänvalvojan on ajoittain ylläpidettävä myös näitä asetuksia.
-
Työjakson hallinta
- Sisältää asetusesimerkin:
- Käyttäjän henkilö- ja työsuhdetietojen vastaanottaminen.
- Asetukset useille työjaksoille ja tileille
- Näitä asetuksia muutetaan harvoin, mutta esimerkiksi uuden käyttäjätyypin tullessa asiakkaan on määritettävä uusi sääntöjoukko kyseiselle käyttäjätyypille.
- Sisältää asetusesimerkin:
-
Tilinhallinta
- Tämä sisältää asetukset käyttäjätilien ja käyttöoikeuksien (ryhmäjäsenyyksien) toimittamiseen (provisiointiin) hakemistoon/hakemistoihin, kuten esimerkiksi millainen sähköpostiosoite luodaan eri käyttäjätyypeille ja mitä birth right -oikeuksia myönnetään jne.
Rakentaminen ja ylläpito
Yleinen oletus on, että kun tuotantokäyttö alkaa, jokainen prosessi ja käyttötapaus toimii ja automaatio pyörii täydellä teholla, mutta IGA-ratkaisun tuotantokäyttö alkaa tarjoamalla työkalut, joilla aloitetaan rakentaminen ja automaation tasoa nostetaan vähitellen. Tämä tarkoittaa sitä, että roolienhallintaa ei tehdä Excelissä, vaan se tehdään IGA-ratkaisussa, ja kun roolit on rakennettu, IGA-järjestelmänvalvoja voi myöntää niitä rakentamalla automatisoituja sääntöjä tai julkaisemalla liiketoimintarooleja ja käyttöoikeuksia Self-Serviceen, jotta loppukäyttäjät voivat pyytää niitä.
Rakennusvaihe on IGA-järjestelmänvalvojille suurin työmäärä, mutta työn edetessä tarvittava IGA-järjestelmänvalvojan työmäärä vähenee ylläpitotasolle.
Alussa IGA-ratkaisu tarjoaa työkalut IGA-järjestelmänvalvojille, ja vähitellen tehtävien valmistuessa automaation taso nousee ja yhä useampi palvelu tulee saataville loppukäyttäjille Self-Servicessä.
Automaation rakentaminen ja ylläpito
IGA-järjestelmänvalvojalla on eri työkaluja automaation tason nostamiseen, mutta on tärkeää, että rakentaminen tehdään oikeassa järjestyksessä, jotta jokaisen toiminnallisuuden tarvitsema data on saatavilla.
| Käyttötapaus | Rakentaminen | Ylläpito | Tarvittava aika |
| Entitlementtien hallinta | Kaikki IGA-ratkaisussa liittyy entitlementteihin, jotka kuvastavat yhtä hakemistosta/hakemistoista luettua käyttöoikeutta (ryhmää), IGA-järjestelmänvalvojan luomaa manuaalista entitlementtiä tai mitä tahansa muuta sovellusoikeutta. Suurin massa tulee yleensä hakemiston ryhmistä, ja IGA-järjestelmänvalvojan on täydennettävä tiedot, joita ei voida lukea hakemistosta, kuten esimerkiksi antaa ystävällinen nimi ja kuvaus. |
IGA-järjestelmänvalvojan työtä tarvitaan, kun
Tämä tehtävä voidaan delegoida entitlementin tai sovelluksen omistajalle. |
Kun tuotantokäyttö alkaa, suositus on varata vähintään 4 työpäivää, mikä antaa IGA-järjestelmänvalvojille hyvän alun jatkaa entitlement-tietojen täyttämistä. Kokonaistarvittava aika riippuu asiakkaan käyttöoikeushallinnan nykytilasta, ja ohjeellisesti tämä vaatii IGA-järjestelmänvalvojilta viikoittaista aikaa vähintään 4-6 kuukauden ajan. |
| Liiketoimintaroolien hallinta |
Ovat entitlementtien kokoelmia, ja ne voidaan myöntää käyttäjille automaattisesti automatisoiduilla säännöillä, tai ne voidaan julkaista Self-Serviceen, jotta loppukäyttäjät voivat pyytää/poistaa niitä.
IGA-järjestelmänvalvoja voi aloittaa liiketoimintaroolien rakentamisen heti, kun ratkaisu on tuotantokäytössä, mutta on suositeltavaa, että entitlementeillä on riittävästi tietoa ja datan laatu on varmistettu ennen liiketoimintaroolien rakentamista. |
IGA-järjestelmänvalvojan työtä tarvitaan, kun
Tämä tehtävä voidaan delegoida entitlementin tai sovelluksen omistajalle. |
Yhden (1) liiketoimintaroolin rakentaminen vie muutaman minuutin, ja provisiointiaika riippuu siitä, kuinka paljon käyttöoikeuksia myönnetään/poistetaan. |
| Automatisoitujen sääntöjen hallinta |
Automatisoituja sääntöjä käytetään entitlementtien ja liiketoimintaroolien myöntämiseen ja poistamiseen automaattisesti käyttäjän työsuhdetietojen perusteella. Säännön tyyppi voi olla jatkuva sääntö tai kertaluonteinen sääntö.
Kun uusia sääntöjä luodaan tai olemassa olevia päivitetään tai poistetaan, IGA-järjestelmänvalvoja voi esikatsella provisiointimuutokset ennen varsinaisen provisioinnin käynnistämistä.
|
IGA-järjestelmänvalvojan työtä tarvitaan, kun
Yleensä tätä tehtävää ei delegoida omistajille, joiden käyttöoikeudet liittyvät sääntöön. |
Yhden (1) automatisoidun säännön rakentaminen vie muutaman minuutin, ja provisiointiaika riippuu siitä, kuinka paljon käyttöoikeuksia myönnetään/poistetaan. |
| Pyyntökatalogin hallinta |
Näkyy loppukäyttäjille ja ohjaa heitä löytämään ja pyytämään oikeat käyttöoikeudet Self-Servicestä
Pyyntökatalogia rakennettaessa on tärkeää ottaa loppukäyttäjät (käyttäjät ja esihenkilöt) mukaan suunnitteluprosessiin, koska loppukäyttäjät ovat niitä, jotka sitä käyttävät.
Tämä saattaa vaatia useita iteraatioita, ja IGA-järjestelmänvalvojan on ehkä muutettava kategorisointia loppukäyttäjien palautteen perusteella. |
IGA-järjestelmänvalvojan työtä tarvitaan, kun
IGA-järjestelmänvalvoja tai omistaja voi määrittää, missä kategorioissa käyttöoikeus tai liiketoimintaroolit näkyvät näihin kohteisiin liittyviltä datakorteilta, mutta IGA-järjestelmänvalvoja hallinnoi koko katalogia ja kategorioita. |
Yhden uuden kategorian luominen vie muutaman minuutin, ja sen jälkeen entitlementit ja liiketoimintaroolit voidaan julkaista kategoriaan. |
Päivittäiset toimet
Päivittäiset toimet eivät tarkoita, että tehtävä ilmenisi joka päivä, vaan sitä, että prosessissa saattaa olla tehtäviä, jotka vaativat IGA-järjestelmänvalvojan puuttumista. Päivittäiset tehtävät riippuvat asiakkaan asetuksista ja IGA-ratkaisussa käytössä olevista käyttötapauksista.
Ohjeet päivittäisiin toimiin
Alla on lueteltu ja kuvattu toiminnallisuudet ja tehtävät, jotka IGA-järjestelmänvalvojan on suoritettava heti niiden ilmaannuttua tai tarpeen mukaan.
Päivittäiset toimet on jaoteltu kolmeen (3) kategoriaan, ja jos tehtävän skenaario koskee asiakkaan käyttötapauksia, näitä tehtäviä on suositeltavaa tarkistaa päivittäin.
Ongelmanratkaisu, nämä tehtävät ilmenevät, kun työnkuluissa, logiikassa tai provisioinnissa on ongelmia.
Ylläpitotoimet riippuvat asiakkaan asetuksista, kuten esimerkiksi siitä, tarvitaanko manuaalista puuttumista käyttäjän luonnin aikana, tai onko manuaalisia käyttöoikeuspyyntöjä, raportointi-/auditointitarpeita jne.
Datapoikkeamat ovat tilanteita, joissa IGA-ratkaisu toimii oikein, mutta se ei voi viedä prosesseja loppuun datan ongelmien, kuten puuttuvan esihenkilötiedon jne. vuoksi.
| Tehtävä/toimi | Kuvaus | Toistuvuus |
| Datan simulointi ennen provisiointia |
Tämä tehtävä koskee käyttäjän elinkaarenhallinnan käyttötapauksia, ja se on suositeltavaa ottaa käyttöön (ainakin jonkin aikaa), kun HR-integraatio otetaan käyttöön, ja kun datan laatu on varmistettu, se voidaan kytkeä pois päältä.
|
Ylläpitotoimi |
| Samannimiset käyttäjät |
Tämä koskee käyttäjän elinkaarenhallinnan käyttötapauksia, kun asiakas vaatii, että samannimisyystapauksissa molemmat käyttäjät saavat etu- tai jälkiliitteen ainutkertaisiin attribuutteihin, kuten sähköpostiosoitteeseen.
|
Ylläpitotoimi |
| Ainutkertaisia attribuutteja ei voida määrittää automaattisesti tilinhallintaa varten |
Tämä koskee käyttäjän elinkaarenhallinnan käyttötapauksia, joissa hakemistoon liittyviä ainutkertaisia attribuutteja ei voida luoda automaattisesti ja IGA-järjestelmänvalvojan on puututtava prosessiin manuaalisesti (esimerkiksi kun sähköpostiosoitteen luonnissa vaihtoehdot loppuvat).
|
Ongelmanratkaisu |
| Ensisijaisen työjakson vaihtaminen |
Tämä koskee käyttäjän elinkaarenhallinnan käyttötapauksia, joissa käyttäjällä voi olla useita työjaksoja.
|
Ylläpitotoimi |
| Ensisijaisen tilin tietojen vaihtaminen |
Tämä koskee tilinhallinnan käyttötapauksia, joissa käyttäjällä voi olla useita tilejä.
|
Ylläpitotoimi |
| Epäonnistuneen provisioinnin ajaminen uudelleen käyttäjän luontia tai päivitystä varten. |
Tämä koskee käyttäjän elinkaarenhallinnan käyttötapauksia.
|
Ongelmanratkaisu |
| Epäonnistuneen palvelupyynnön ajaminen uudelleen entitlementin pyytämistä tai poistamista varten |
Tämä koskee tilannetta, jossa provisiointi epäonnistuu Self-Servicestä tehdyn käyttöoikeuspyynnön/-poiston aikana.
Ryhmäjäsenyyksien lisääminen ja poistaminen tapahtuu IGA Service request -pyynnöllä. Jos ryhmäjäsenyyden provisiointi epäonnistuu (esimerkiksi yhteys-, sertifikaatti- tai tunnusongelmien vuoksi), työnkulku pysähtyy ja luo IGA Administration task -datakortin.
|
Ongelmanratkaisu |
| Epäonnistuneen IGA access right record -tietueen ajaminen uudelleen |
Tämä koskee useita käyttötapauksia, ja IGA-järjestelmänvalvojan on ehkä tehtävä tämä, kun
|
Ongelmanhallinta |
| Raportointi ja auditointi | Katso auditointia ja raportointia käsittelevä oma luku. |
Ylläpitotoimi |
| Manuaalinen käyttöoikeuspyyntö |
Kun entitlement-asetuksissa provisioinnin tyypiksi on asetettu manual tai combined, ja manuaalisen pyynnön kohteeksi on valittu team, ja tiimiksi on valittu IGA admin team.
|
Ylläpitotoimi |
| Esihenkilö puuttuu käyttöoikeuspyynnöistä/-poistoista |
Tämä koskee käyttöoikeuksien pyytämisen/poistamisen käyttötapauksia, kun esihenkilötieto puuttuu esihenkilön hyväksyntää vaativista pyynnöistä.
|
Datapoikkeama |
| Tilinhallinta-asetukset puuttuvat |
Tämä tapahtuu, kun IGA set account -datakortti puuttuu eikä käyttäjätietoja voida määrittää tai provisioida hakemistoon/hakemistoihin.
|
Ongelmanratkaisu |
| Käyttäjä löytyy hakemistosta, mutta ei IGA:sta |
Tämä tapahtuu käyttäjän elinkaarenhallinnan käyttötapauksissa, mutta se on myös osa governance-käyttötapauksia, erityisesti prosessin ulkopuolella tehtyjen käyttäjän luontien raportointia varten.
Tämä tilanne ilmenee vain silloin, kun käyttäjän luonnin aikana hakemistosta löytyy tili, jolla on sama työntekijätunnus.
|
Datapoikkeama |
| Lähtevän käyttäjän tieto ei täsmää IGA:n ja hakemiston välillä |
Tämä tapahtuu käyttäjän elinkaarenhallinnassa lähtevän käyttäjän käyttötapauksessa, ja se on myös osa governance-käyttötapauksia, koska se osoittaa tilanteen, jossa käyttäjätili on aktiivinen hakemistossa, vaikka IGA-ratkaisun tietojen mukaan käyttäjä pitäisi poistaa käytöstä.
|
Datapoikkeama |
| Kun käytöstä poistaminen epäonnistuu tai siirto OU:hun epäonnistuu (lähtevä käyttäjä) |
Tämä liittyy käyttäjän elinkaarenhallintaan, erityisesti lähtevän käyttäjän käyttötapaukseen, kun asiakkaan hakemisto käyttää OU-rakennetta (kuten esimerkiksi Active Directory AD).
|
Ongelmanratkaisu |
Raportointi ja auditointi
IGA-järjestelmänvalvojille on 70-100 valmista raporttia, näkymää tai dashboardia, ja raportoinnin ja auditoinnin tarpeet vaihtelevat IGA-ratkaisun kypsyystason mukaan, kuten esimerkiksi kuinka kauan sitä on käytetty tai missä käyttöönoton vaiheessa ollaan.
IGA-järjestelmänvalvoja voi muokata, poistaa, järjestää uudelleen, nimetä uudelleen jne. valmiita raportteja, näkymiä ja dashboardeja, tai IGA-järjestelmänvalvoja voi helposti luoda uusia raportteja, näkymiä ja dashboardeja ja tallentaa ne omaan käyttöön tai julkaista ne muille käyttäjille.
- Ensimmäisten datan lukujen jälkeen IGA-järjestelmänvalvojalla on valmiit raportit, näkymät ja dashboardit vastaanotetun datan tarkistamiseen ja datan laadun varmistamiseen.
- Automaatiota rakennettaessa ja ylläpidettäessä IGA-järjestelmänvalvoja tarvitsee raportteja, kuten liiketoimintaroolien välisiä suhteita (role mining), pyyntökatalogeja, automatisoituja sääntöjä, titteleitä, kustannuspaikkoja jne.
- Päivittäiset hallintatehtävät, tarvitaan ylläpitotoimia tehtäessä tai ongelmia ja datapoikkeamia ratkaistaessa.
- Tilastot -raportit tarvitsevat aikaa kerätäkseen riittävästi tietoa raportointia varten, kuten esimerkiksi eniten käytetyt palvelut, eniten pyydetyt käyttöoikeudet jne.
- Governance -raportit vaihtelevat asiakkaan auditointivaatimusten mukaan, ja esimerkiksi uudelleensertifiointiraportit ja turvallisuuteen liittyvät toimet näkyvät Governance-raporteissa.
- Extended access right management -raportit sisältävät tietoa esimerkiksi fyysisistä käyttöoikeuksista, etuoikeutettujen käyttöoikeuksien hallinnasta jne.
-
Review data -raportit sisältävät tietoa:
- Millaista käyttäjään, työsuhteeseen, tiliin jne. liittyvää dataa IGA-ratkaisuun on vastaanotettu.
- IGA-järjestelmänvalvojan on pakko tarkistaa kaikki nämä raportit, kun data vastaanotetaan IGA-ratkaisuun ensimmäistä kertaa.
- Jos data ei ole kelvollista tai ajan tasalla, IGA-järjestelmänvalvojan on tehtävä muutoksia dataan.
- Viikoittain/kuukausittain on suositeltavaa tarkistaa vähintään orpotilien raportit ja muut turvallisuuteen liittyvät raportit (tai siirtää ne esimerkiksi Daily administration -raportteihin).
- HR- ja/tai hakemistodatan tarkistus
- Analyze data before provisioning -raportteja tarvitaan silloin, kun IGA-järjestelmänvalvoja simuloi vastaanotettua dataa ennen sen provisiointia hakemistoon/hakemistoihin.
-
Role mining -raportteja käytetään liiketoimintaroolien ja automatisoitujen sääntöjen luomiseen. IGA-järjestelmänvalvoja voi tarkistaa esimerkiksi:
- Käyttäjät, joilla on sama titteli, kustannuspaikka tai organisaatioyksikkö.
- Tilit, joilla on sama entitlement.
-
Build request catalog -raportit auttavat IGA-järjestelmänvalvojaa rakentamaan käyttöoikeuksien pyyntökatalogin Self-Serviceen, esimerkiksi:
- Entitlementit, joista puuttuu pakollinen tieto.
- Self-Serviceen julkaistut entitlementit.
- Sovelluksiin liittyvät entitlementit.
-
Daily administration -raportteja on seurattava jatkuvasti, kun IGA-ratkaisu on tuotantokäytössä:
- Provisiointia odottavat pyynnöt.
- Julkaistut entitlementit, joista puuttuu hyväksyjätieto.
- Päivittäinen provisioinnin onnistumisprosentti.
- Tilitoimet (salasanan vaihdot jne.).
-
Auditointiraportteja käytetään yksityiskohtaisen tiedon hakemiseen käyttäjistä ja heidän käyttöoikeuksistaan, esimerkiksi:
- Kenellä oli käyttöoikeus X aktiivisena 1.1-31.12.2024.
- Kuka hyväksyi pyynnön X.
- Käyttäjän ja käyttöoikeuden historia.
-
Statistics-raportit ovat hyödyllisiä, kun IGA-ratkaisua on käytetty jonkin aikaa ja raportoitavaa dataa on kertynyt:
- Kaikkien aikojen provisioinnin onnistumisprosentti.
- Eniten käytetyt palvelut Self-Servicessä.
- Kaikki käyttäjien luonnit, päivitykset, lähtevät käyttäjät (%).
-
Governance-raportteja käytetään esimerkiksi varmistamaan, ettei haitallista toimintaa esiinny, sekä uudelleensertifiointien hallintaan jne.
- Pyynnöt, jotka sama käyttäjä on sekä pyytänyt että hyväksynyt.
- Pyynnöt, joissa hyväksyjä on eri kuin pyytäjä.
- Tilit, joita IGA ei ole luonut.
- Kaikki IGA-järjestelmänvalvojan toimet.
Governance
Governanceen liittyvät tehtävät toistuvat yleensä kuukausittain tai vuosittain, mutta ne liittyvät aina asiakkaan käytäntöihin ja turvallisuusvaatimuksiin.
On tavallista, että esimerkiksi asiakkaan tietoturvavastaavalla on myös pääsy IGA-ratkaisuun, ja hän voi raportoida ja auditoida tarvittavat identiteetti- ja käyttöoikeustiedot ja/tai käynnistää uudelleensertifiointipyyntöjä.
Governance on osa jokaista IGA-käyttötapausta ja -prosessia, mutta on olemassa erilaisia toiminnallisuuksia sen varmistamiseksi, että esimerkiksi vaatimustenmukaisuusvaatimukset täyttyvät.
- Uudelleensertifiointi
- Toksiset yhdistelmät
- Riskitason laskenta ja korkean riskin käyttäjien ja käyttöoikeuksien tarkistus
- Auditointi asiakasorganisaation vaatimusten mukaisesti
- Uusien raporttien luominen
- Raportointi sidosryhmille
- Auditointivaatimusten täyttäminen
Kehittäminen
Seuraa, miten IGA-ratkaisusi tuo automaatiota organisaation prosesseihin, ja paranna sitä havaintojen perusteella. Pidä yllä IGA-ratkaisusi backlog-listaa ja varmista, että organisaation muutokset huomioidaan myös IGA-prosesseissa.
On tärkeää antaa palautetta tuotteesta, kommentoida ja tykätä muiden käyttäjien parannusideoista sekä seurata tuotteeseen liittyviä versiopäivityksiä, jotka tuovat uusia ominaisuuksia IGA-ratkaisuusi!
Pidä yllä backlogia ja sidosryhmäsuhteita
On tärkeää tunnistaa muutokset, jotka vaikuttavat IGA-ratkaisuun, sen määrityksiin tai automaatioon, koska nämä muutokset voivat käynnistää valtavan määrän provisiointeja hakemistoon/hakemistoihin tai muuttaa määritystä siten, että provisiointi epäonnistuu.
Pidä yllä backlogia
Toimitusvaiheessa Matrix42 delivery management -työkalua (EDM) käytetään toimitustehtäviin, testitapauksiin, testihavaintoihin ja myös jatkokehitysideoihin. Tämä on erittäin hyödyllinen backlog-kohteiden keräämiseen IGA-kehitystarpeita varten. Työkalu on asennettu asiakkaan IGA-testiympäristöön, eikä siitä aiheudu lisäkustannuksia (se sopii hyvin myös testitapausten yms. tallentamiseen uusia ominaisuuksia/toiminnallisuuksia testattaessa).
- IGA-järjestelmänvalvoja
- Luo uuden toimituskohteen, jonka tyyppi on further development
- Priorisoi kohteet
- Kohdistaa uuden kohteen IGA-määritysten järjestelmänvalvojalle (voi olla myös Matrix42-konsultti)
- IGA-määritysten järjestelmänvalvoja tarkistaa kohteen ja lisää siihen työarvion
- Suuremmat kohteet saattavat vaatia myös projektipäällikön tarkistuksen
- IGA-järjestelmänvalvoja keskustelee sidosryhmien kanssa
- Jos kohde hyväksytään toteutettavaksi, IGA-järjestelmänvalvoja aikatauluttaa muutokset tarvittavien osallistujien kanssa ja muuttaa kohteen tilan arvoksi done.
- Jos kohde hylätään, IGA-järjestelmänvalvoja muuttaa kohteen tilan arvoksi Cancelled (not needed/removed).
- IGA-järjestelmänvalvoja voi käyttää Kanban- tai muita näkymiä backlog-kohteiden raportointiin ja priorisointiin.
On tärkeää toteuttaa ja testata kaikki muutokset ensin testiympäristössä, erityisesti jos ne aiheuttavat muutoksia määrityksiin tai suuren määrän provisiointeja hakemistoon/hakemistoihin.
Pidä yllä sidosryhmäsuhteita
Vaihe 1 on tunnistaa kaikki sidosryhmät ja perustaa toistuvat kokoukset, joissa muutoksia tarkastellaan, vaikutuksia arvioidaan ja aikataulusta sovitaan. Yleisesti tarvittavia sidosryhmiä ovat
HR-asiantuntijat, tarvitaan, kun HR-integraatio on käytössä
Suositus on pitää toistuvia kokouksia ennen organisaatiomuutoksia, yleensä kolmesta (3) neljään (4) kertaan vuodessa.
- Organisaatiorakenteen muutokset (uudet organisaatioyksiköt, vanhojen yksiköiden poistaminen jne.) saattavat aiheuttaa paljon provisiointeja hakemistoon, ja joissakin tapauksissa nämä provisioinnit eivät välttämättä ole kelvollisia.
- Uusi kustannuspaikka, organisaatioyksikkö tai titteli (jos automatisoitujen sääntöjen on myönnettävä käyttöoikeuksia)
- Minkä tahansa organisaatiotiedon päättymisellä on myös vaikutus automatisoituihin sääntöihin, jos ne myöntävät käyttöoikeuksia poistetun tiedon perusteella
- Tarkasta suunnitellut muutokset yhdessä HR-asiantuntijoiden kanssa ja
- Listaa backlogiin kaikki IGA-ratkaisuun vaikuttavat muutokset
- Varaa tarvittavat resurssit muutosten toteuttamiseen
- Varaa aina IGA-järjestelmänvalvoja saataville HR-ratkaisuun liittyvien muutosten aikana ja niiden jälkeen
Simuloi muutokset ennen provisiointia
On erittäin suositeltavaa ottaa käyttöön datan tarkistaminen ennen provisiointia -asetus (IGA set account information -datakortilla, muista tehdä tämä kaikille HR-ratkaisusta tuleville käyttäjätyypeille). Tällä asetuksella työnkulku vastaanottaa tiedon HR-ratkaisusta, mutta ennen provisiointia IGA-järjestelmänvalvoja tarkistaa, että kaikki muutokset ovat oikein ja kelvollisia ennen provisiointiin jatkamista.
Hakemistoasiantuntijat,
Ovat usein myös IGA-järjestelmänvalvojia ja vastaavat kaikista hakemistossa tapahtuvista muutoksista, joilla voi olla vaikutus IGA-ratkaisuun ja sen automaatioon.
Suositus on pitää toistuvia kokouksia hakemistoasiantuntijan kanssa vähintään kerran (1) kuukaudessa ja ottaa hakemistoasiantuntija mukaan myös HR-asiantuntijoiden kanssa pidettäviin kokouksiin.
Yleisimmät hakemiston muutokset, jotka aiheuttavat provisiointivirheitä
- Uudet organisaatioyksiköt (OU), koskee OU-rakennetta käyttäviä hakemistoja.
- IGA-järjestelmänvalvoja tarkistaa, tarvitseeko IGA set account information -datakortteja päivittää vai luoda uusia.
- IGA-määritysten järjestelmänvalvoja varmistaa, että uudet OU:t luetaan hakemistosta ja tekniselle käyttäjälle on kirjoitusoikeus uuteen OU:hun.
- Uudet käyttäjätilin attribuutit
- IGA-järjestelmänvalvoja tarkistaa, että uudet attribuutit luetaan oikeisiin attribuutteihin IGA account -datakorteilla
- IGA-määritysten järjestelmänvalvoja varmistaa, että uudet attribuutit sisältyvät konnektorin kartoituksiin datan lukemista (scheduled-tasks) ja kirjoittamista (event-tasks) varten.
- Uudet ryhmäattribuutit
- IGA-järjestelmänvalvoja tarkistaa, että uudet attribuutit luetaan oikeisiin attribuutteihin IGA entitlement -datakorteilla
- IGA-määritysten järjestelmänvalvoja varmistaa, että uudet attribuutit sisältyvät konnektorin kartoituksiin datan lukemista (scheduled-tasks) ja kirjoittamista (event-tasks) varten.
- Muutokset sertifikaateissa, salaisissa avaimissa jne.
- IGA-määritysten järjestelmänvalvoja voi päivittää sertifikaatit, salaiset avaimet jne. konnektorin asetuksista
- Muutokset teknisessä käyttäjätilissä (jota IGA-ratkaisu käyttää)
- Kaikista muutoksista palvelutiliin, jota IGA-ratkaisu käyttää datan lukemiseen ja kirjoittamiseen hakemistoon/hakemistosta, on keskusteltava IGA-järjestelmänvalvojan kanssa vakavien häiriöiden estämiseksi. Esimerkiksi jos tekninen käyttäjätili (palvelutili) jostain syystä poistettaisiin hakemistosta, kaikki provisioinnit päätyisivät virheisiin
Omistajat
Suositus on pitää toistuvia kokouksia kaikkien omistajien kanssa kuukausittain tai vähintään neljännesvuosittain.
On erilaisia omistajatyyppejä, joille on ehkä tiedotettava HR-ratkaisussa tai hakemistossa/hakemistoissa tapahtuvista muutoksista, koska ne saattavat esimerkiksi muuttaa tarvetta hyväksyä automaatiosääntöjen muutoksia.
Omistajan tehtävät riippuvat siitä, miten vastuut on sovittu IGA-järjestelmänvalvojan, tietoturvavastaavan ja omistajien kesken asiakkaan organisaatiossa. Alla on lueteltu tehtäväesimerkkejä eri omistajille, mutta kuten sanottu, kaikki nämä voisivat olla myös IGA-järjestelmänvalvojan vastuulla.
- Sovellusten omistajat vastaavat
- sovellukseen liittyvän tiedon ylläpidosta, jos esimerkiksi sovelluksen nimi tai tekniset tiedot/riippuvuudet muuttuvat.
- sidosryhmien tiedottamisesta sovelluksen muutoksista
- raportoinnista organisaation auditointivaatimusten mukaisesti
- Entitlementtien omistajat vastaavat
- omistamiinsa entitlementteihin liittyvän tiedon ylläpidosta, kuten esimerkiksi hyväksyjätiedosta, näkyvyydestä pyyntökatalogissa, nimestä, kuvauksista jne.
- sen selvittämisestä, vaikuttavatko sovelluksen muutokset IGA-ratkaisuun
- kohteiden lisäämisestä backlogiin ja priorisoinnista
- omistamiensa entitlementtien uudelleensertifioinnista
- raportoinnista organisaation auditointivaatimusten mukaisesti
- Liiketoimintaroolien omistajat vastaavat
- omistamiinsa liiketoimintarooleihin liittyvän tiedon ylläpidosta, kuten esimerkiksi hyväksyjätiedosta, näkyvyydestä pyyntökatalogissa, nimestä, kuvauksista jne.
- sen selvittämisestä, vaikuttavatko HR-muutokset liiketoimintaroolin sisältöön tai kohderyhmään
- omistamiensa liiketoimintaroolien uudelleensertifioinnista
- raportoinnista organisaation auditointivaatimusten mukaisesti
Tietoturvavastaava
Tietoturvavastaava omistaa usein IGA-ratkaisun ja kaikki sen prosessit. Yleensä tietoturvavastaava vastaa auditointivaatimusten määrittämisestä päivittäistä/viikoittaista/kuukausittaista/neljännesvuosittaista/vuosittaista raportointia varten sekä tarvittavista toimista esimerkiksi haitallisen toiminnan havaitsemisen yhteydessä.
Uudelleensertifiointi ja toksiset yhdistelmät saattavat kuulua joko IGA-järjestelmänvalvojan, tietoturvavastaavan tai jonkin omistajan vastuulle - tämä riippuu täysin siitä, miten vastuut on jaettu tietoturvavastaavan, IGA-järjestelmänvalvojan ja omistajien kesken.
Uudet tuoteominaisuudet ja toiminnallisuudet
Uusi versio julkaistaan 2-3 kertaa vuodessa, ja se asennetaan automaattisesti asiakkaiden ympäristöihin julkaisuviestinnän mukaisesti (asiakkaalle ilmoitetaan ennen versiopäivitystä testi- tai tuotantoympäristössä). Päivityksen jälkeen on hyvä tehdä perusvalidointi, että kaikki toimii, ja jos päivitysten jälkeen ilmenee ongelmia, ota yhteyttä osoitteeseen servicedesk@efecte.com.
Muista seurata,
Release notes - tekniset tiedot IGA-ratkaisun, alustan, Self-Servicen, konnektorien jne. parannuksista ja uusista toiminnallisuuksista.
Community - joka sisältää ylätason kuvauksen julkaistuista kohteista ja tulevista roadmap-kohteista. Community on myös oikea paikka ehdottaa uusia tuoteominaisuuksia tai tarkastella, mitä muut asiakkaat ovat pyytäneet.
Table of Contents