Vaatiiko avoin lähdekoodi oman ohjelmistotiimin? Miten korkeakoulu hallitsee IGA- ja IAM-alustaa ilman resurssipulaa

Edellisissä artikkeleissamme käsittelimme korkeakoulujen elinkaaririskejä sekä sitä, miten vanha identiteettien ja käyttöoikeuksien hallinta (IGA) voidaan korvata hallitusti ilman palvelukatkoksia. Kun sopivaa kokonaisvaltaista IAM-arkkitehtuuria (Identity and Access Management) pohditaan, tietohallinnon pöydälle nousee usein viimeinen, kriittisin kysymys: Onko meillä resursseja pyörittää tätä? Jäämmekö järjestelmän kanssa yksin, jos oma asiantuntijamme vaihtaa taloa?

Mielikuva avoimesta lähdekoodista ”yksinäisenä koodausprojektina” on vanhentunut. Nykyaikainen avoimen lähdekoodin IGA-alusta yhdistää riippumattomuuden, valmiin muokattavuuden (konfiguroitavuus)  sekä asiantuntevan kumppaniverkoston tuen. Avoimen lähdekoodin hyödyntäminen ei tarkoita oman ohjelmistotalon perustamista, kun järjestelmän ylläpito rakentuu selkeille toimintamalleille, valmistajan viralliselle tuelle ja kokeneelle kumppanuudelle.

Pitääkö avoimen lähdekoodin IGA/IAM-järjestelmä koodata itse tyhjästä?

Ei pidä, sillä nykyaikaisen avoimen lähdekoodin IGA-alustan käyttöönotto ja arki perustuvat pääosin valmiisiin komponentteihin, liityntöihin (konnektoreihin) ja konfiguraatioihin.

Yksi yleisimmistä väärinkäsityksistä on ajatella, että avoin lähdekoodi tarkoittaisi tuhansien rivien kirjoittamista uutta ohjelmistokoodia. Nykyisissä edistyksellisissä IGA-alustoissa valtaosa toiminnoista, kuten roolisäännöt, käyttöoikeuksien laskenta, Joiner-Mover-Leaver (JML) -elinkaarenhallinta, raportointi ja tietojen synkronointi toteutetaan järjestelmän valmiilla  konfiguraatiomalleilla ja säännöillä.

Tapauskohtaista skriptausta tai sovelluskehitystä tarvitaan lähinnä silloin, kun kytketään poikkeuksellisen monimutkaisia tai räätälöityjä asiakaskohtaisia integraatioita. Tämä tekee järjestelmän ylläpidosta huomattavasti kevyempää ja poistaa oppilaitoksen riippuvuuden yksittäisistä koodareista.

Jääkö korkeakoulu yksin avoimen lähdekoodin ylläpidon ja kehityksen kanssa?

Korkeakoulu ei jää yksin, kun ratkaisua toteutetaan ja ylläpidetään yhdessä kokeneen ratkaisukumppanin, ja laajempien asiantuntijaverkostojen kanssa.

Tuotantokäytössä avoimen koodin vapaus vaatii rinnalleen asiantuntevan kumppanin, joka vastaa kokonaisuuden toimivuudesta. CSIT Finlandin kaltainen identiteettien ja käyttöoikeuksien hallintaan erikoistunut ratkaisukehittäjä toimii korkeakoulun rinnalla ja yhdistää kotimaisen arkkitehtuuriosaamisen, teknologiavalmistajan alustakehityksen sekä kumppaniverkoston tietotaidon.

Miten palveluiden jatkuvuus ja tietoturva varmistetaan pitkällä tähtäimellä?

Jatkuvuus varmistetaan hallituilla pitkän tuen versiointimalleilla (Long-Term Support, LTS), auditointikyvyllä ja säännöllisellä nykytilan arvioinnilla.

Järjestelmän pitkäaikainen turvallisuus ei ole sattuman varassa. Tuotantokäytössä hyödynnetään valmistajan tukemaa pitkän elinkaaren versiota sekä sovittua päivitys- ja testausmallia, jotka takaavat tietoturvapäivitysten, tarvittaessa vikasietoisuuden (klusterointi) ja raportoinnin toimivuuden ilman yllätyksiä.

Tärkeintä on, että tietohallinto säilyttää kontrollin ja läpinäkyvyyden omaan dataansa. Kokenut kumppani auttaa kartoittamaan identiteetin- ja käyttöoikeuksien hallinnan nykytilan, tunnistamaan kehityskohteet ja rakentamaan ratkaisun, joka mahdollistaa sujuvan ja keskeytymättömän työnteon ilman, että oppilaitoksen oma IT-tiimi kuormittuu liikaa.

Jatketaanko keskustelua ensi viikolla Korkeakoulujen IT-päivillä Turussa?

Pohditteko teidän korkeakoulussanne, millaisella arkkitehtuurilla ja resursseilla identiteetinhallinnan kokonaisuus (IAM/IGA) kannattaisi uudistaa? CSIT Finland on mukana Turun IT-päivillä – tule piipahtamaan ständillämme tai varaa kanssamme napakka sparrausaika paikan päälle. Käydään läpi oppilaitoksenne tilanne ja kartoitetaan polku turvalliseen ja keskeytymättömään työntekoon.