Tulijat, siirtyjät ja lähtijät: pidä käyttöoikeudet vastuullisina

Käyttöoikeusmuutokset ovat koordinointiongelma siinä missä tekninenkin. Identiteettialusta ei voi poistaa alihankkijan tiliä, jos kukaan ei kerro omistajalle sopimuksen päättyneen. Samoin oikea-aikainen HR-ilmoitus ei todista, että jokainen sovellus lakkasi hyväksymästä henkilön tunnuksia.

Tulijat, siirtyjät ja lähtijät tarvitsevat prosessin, joka yhdistää liiketoimintatapahtuman hyväksyttyyn käyttöoikeustilaan, toteuttaa tarvittavat muutokset ja varmentaa tuloksen. Teknisen johdon näkökulmasta tärkeä kysymys ei ole se, onko olemassa poistumisen tarkistuslista. Kysymys on siitä, kattaako prosessi järjestelmät, joita ihmiset todella käyttävät, käsitteleekö se virhetilanteet ja jättääkö se näytön siitä, mitä muuttui ja milloin.

Määritä elinkaari ja sen vastuunsiirrot

Käsittele jokaista elinkaaritapahtumaa muutoksena henkilön valtuutettuihin käyttöoikeuksiin, ei pelkästään tikettinä tilin luomiseksi tai poistamiseksi käytöstä. Tapahtumakirjauksen tulee yksilöidä henkilö, työ- tai toimeksiantosuhteen tila, esihenkilö tai sponsori, voimaantulopäivä ja -aika sekä asianomainen rooli. Käytä pysyvää tunnistetta sen sijaan, että luottaisit pelkästään nimiin tai sähköpostiosoitteisiin.

HR käynnistää usein työntekijöitä koskevat tapahtumat. Hankinnan omistaja, projektipäällikkö tai sisäinen sponsori voi käynnistää alihankkijoita koskevat tapahtumat. Valitse kullekin joukolle määräävä lähde ja määritä, miten korjaukset, peruutetut aloitukset, sopimusten jatkot ja kiireelliset lähdöt välittyvät IT:lle.

Erota neljä vastuuta, vaikka pieni tiimi osoittaisi niistä useita samalle henkilölle:

Nimeä varahenkilöt ja eskalointireitti. Aikataulutettu lähtö ei saa riippua yhden ylläpitäjän tavoitettavuudesta. Arkaluonteisissa muutoksissa riippumaton katselmoija tarjoaa hyödyllisen tarkistuksen; jos henkilöstötilanne estää sen, dokumentoi järjestely ja tee jälkikäteinen katselmointi.

Määritä kullekin tapahtumalle valmistumiskriteerit. Tulija on valmis, kun hyväksytyt käyttöoikeudet ja vaaditut laitekontrollit on varmennettu. Siirtyjän tapahtuma on valmis, kun sekä lisäykset että poistot on tarkistettu. Lähtijän tapahtuma on valmis, kun pääsyreitit on suljettu ja ratkaisemattomilla laitteisiin, tietoihin tai tunnuksiin liittyvillä asioilla on nimetyt omistajat.

Nämä ovat käytännöllisiä hallintakeinojen suunnittelusuosituksia, eivät yleisiä lakisääteisiä määräaikoja. ISO 27001 -ISMS:n puitteissa käyttöoikeuksien hallintakeinojen tulee heijastaa organisaation soveltamisalaa ja riskien käsittelyä. Laajempi hallintakeinojen konteksti on kuvattu artikkelissa ISO 27001:n liite A käytännössä.

Varmista kattavuus ennen muutosten automatisointia

Aloita sovellusinventaariosta. Kirjaa kustakin järjestelmästä sen omistaja, identiteettilähde, käyttäjien hallintatapa, tunnistautumistapa, tuetut käyttöoikeuksien poistotoimet ja varmennustapa. Ota mukaan sekä keskitetysti hallitut sovellukset että sovellukset, joissa on paikallisia tilejä.

Kertakirjautuminen ei välttämättä tarkoita koko elinkaaren hallintaa. Sovellus voi käyttää tunnistautumiseen identiteetintarjoajaa ja silti ylläpitää paikallisia ylläpitäjiä, API-avaimia, aktiivisia istuntoja tai palautusvaihtoehtoja. Käyttäjien hallinnan liittymä voi poistaa käyttäjän käytöstä poistamatta jokaista oikeutta. Dokumentoi, mitä kukin mekanismi todella tekee.

Ota mukaan nämä vähemmän näkyvät pääsyreitit:

• Henkilön arkikäytön tilista erilliset etuoikeutetut tilit.
• VPN-pääsy, varmenteet, SSH-avaimet ja etätukityökalut.
• Henkilökohtaiset käyttötunnisteet, API-tunnukset ja sovelluskohtaiset salasanat.
• Jaetut tunnukset, jotka henkilö tiesi tai pystyi hakemaan.
• Vierastilit, ulkoiset yhteistyötilat ja asiakkaan hallinnoimat ympäristöt.
• Palveluidentiteetit, joiden omistaja tai tunnusten haltija vaihtuu.

Älä poista automaattisesti käytöstä jokaista lähtevään työntekijään liittyvää palveluidentiteettiä: se voi pyörittää tuotantokuormaa. Siirrä sen sijaan omistajuus, katselmoi oikeudet ja vaihda paljastuneet tunnukset tarpeen mukaan. Tavoitteena on poistaa henkilön pääsy aiheuttamatta vältettävissä olevaa katkosta.

Täsmäytä inventaario säännöllisesti identiteettivientien, laitetietojen, hankintatietojen ja tiimien ilmoitusten kanssa. Mikään yksittäinen lähde ei välttämättä paljasta jokaista sovellusta. Hallitsemattomien löydösten tulee siirtyä elinkaariprosessiin sen sijaan, että ne jäisivät epävirallisiksi poikkeuksiksi.

Tulijat: anna hallittu lähtötila

Rakenna roolikohtaiset perustasot rajatuin poikkeuksin

Määritä käyttöoikeuspaketit vastuiden, ei pelkkien tehtävänimikkeiden ympärille. Tukianalyytikko voi tarvita pääsyn asiakastiketteihin mutta ei laskutusvienteihin. Ohjelmistokehittäjä voi tarvita lähdekoodivarastot ja kehitysympäristöt saamatta oletuksena tuotannon ylläpito-oikeuksia.

Jokaisella perustasolla tulee olla omistaja, versio, siihen sisältyvät ryhmät tai oikeudet ja katselmointipäivä. Kirjaa, mikä versio tulijalle annettiin. Muuten myöhempi roolin päivitys vaikeuttaa historiallisten käyttöoikeuspäätösten rekonstruointia.

Pyydä lisäkäyttöoikeudet erikseen. Pyynnössä tulee ilmoittaa liiketoiminnallinen tarkoitus, hyväksyvä järjestelmän tai tietojen omistaja, oikeustaso ja tarvittaessa päättymisaika. Vältä kopioimasta olemassa olevan työntekijän koko oikeusjoukkoa: se voi toistaa aiemmista rooleista kertyneitä poikkeuksia ja etuoikeuksia.

Valmistele tilit tarvittaessa ennen aloituspäivää, mutta hallitse niiden aktivointia. Peruutetun rekrytoinnin tulee käynnistää valmisteltujen tilien, lähetettyjen laitteiden ja kutsujen siivous. Alihankkijoilla tulee olla sisäinen sponsori sekä päättymis- tai katselmointipäivä; jatkojen tulee edellyttää myönteistä päätöstä sen sijaan, että pääsy muuttuisi hiljaisesti pysyväksi.

Määritä laitteiden ja tunnistautumisen perustaso

Kirjaa laitteen tunniste, sille osoitettu henkilö, luovutuspäivä ja rekisteröinti laitehallintaan. Tarkista asiaankuuluva perustaso ennen arkaluonteisen pääsyn myöntämistä: tuettu käyttöjärjestelmä, päivitystila, levyn salaus, näytön lukitus, päätelaitesuojaus ja hyväksytty tunnistautumisasetus.

Nämä ovat riskiperusteisia toteutusvalintoja, eivät väite siitä, että jokaisen organisaation olisi käytettävä samoja asetuksia. Määritä henkilökohtaisten laitteiden osalta sallittu pääsy ja tietojen käsittely nimenomaisesti sen sijaan, että käsittelisit niitä hallittujen kannettavien veroisina.

Käytä mahdollisuuksien mukaan laitehallintajärjestelmien päivättyjä havaintoja. Manuaalinen inventaario voi silti olla hyödyllinen, jos se täsmäytetään ja sitä tukee näyttö; myös reaaliaikaista inventaariota on tarkasteltava kriittisesti, kun laite on lakannut raportoimasta. Säilytä havaintoajat, jotta vanhaa tervettä tilaa ei sekoiteta ajantasaiseen varmuuteen.

Varmenna tunnistautumisen käyttöönotto ja ensimmäisten tunnusten toimittaminen. Jos politiikkanne edellyttää monivaiheista tunnistautumista, varmista sen olevan aktiivinen ennen pääsyn alkamista sen sijaan, että kirjaisit vain käyttöönottokutsun lähettämisen. Pidä tunnukset ja palautuskoodit poissa elinkaaritiketeistä.

Siirtyjät: poista vanha rooli, älä vain lisää uutta

Siirrot ovat usein elinkaaren hankalimpia tapahtumia, koska henkilö on edelleen työsuhteessa ja hänen olemassa oleva tilinsä toimii edelleen. Uudet käyttöoikeudet saavat huomiota, koska puuttuvat oikeudet keskeyttävät työn. Vanhat käyttöoikeudet voivat säilyä ilman mitään näkyvää oiretta.

Käsittele siirtoa kolmen tilan vertailuna: nykyiset käyttöoikeudet, hyväksytty uusi perustaso ja hyväksytyt jatkuvat poikkeukset. Määritä, mitkä oikeudet on lisättävä, säilytettävä, rajattava tai poistettava. Tarkista suorat oikeudet sekä ryhmät, sisäkkäiset jäsenyydet, ylläpitoroolit ja sovellusten paikalliset oikeudet.

Edellisen esihenkilön tulee auttaa tunnistamaan päättyneet vastuut. Vastaanottava esihenkilö vahvistaa uudet tehtävät, kun taas järjestelmien tai tietojen omistajat hyväksyvät arkaluonteiset käyttöoikeudet. Tämä estää uutta esihenkilöä valtuuttamasta implisiittisesti säilytettyä pääsyä toisen osaston tietoihin.

Siirtymäjakso voi olla perusteltu. Taloushallinnosta siirtyvä voi tarvita rajatun pääsyn tehtävien luovuttamiseksi. Kirjaa yksilöity oikeus, perustelu, hyväksyvä omistaja ja päättymisaika. Korvaa mahdollisuuksien mukaan laajat kirjoitusoikeudet suppeammilla tai pelkillä lukuoikeuksilla. Kirjaa päättymisaika suoritettavaksi tehtäväksi tai järjestelmäasetukseksi, ei vain kommenttiin.

Muutokset voivat vaikuttaa myös laitteisiin, jaettuihin postilaatikoihin, tietojen omistajuuteen ja etuoikeutettuihin tehtäviin. Siirtyminen ylläpitorooliin ei saa automaattisesti muuttaa arkikäytön tiliä etuoikeutetuksi identiteetiksi.

Vertaa toteutuksen jälkeen todellista käyttöoikeusjoukkoa tarkoitettuun tulokseen. Osastosiirrossa uuden roolin myöntäminen voi olla helppoa. Tärkeä tarkistus on, säilyvätkö vanhat talous-, asiakas- tai ylläpitokäyttöoikeudet. Siirtyjäotos, joka tarkistaa vain uudet käyttöoikeudet, ohittaa tämän riskin.

Lähtijät: koordinoi käyttöoikeuksien poisto, laitteet ja liiketoiminnan jatkuvuus

Määritä ajoitus riskin ja olosuhteiden mukaan

Kirjaa käyttöoikeuksien poiston voimaantuloaika aikavyöhykkeineen. ”Viimeinen päivä” on liian monitulkintainen hajautetuille tiimeille ja ajastetulle automaatiolle. Erota suunniteltu lähtö kiireellisestä työsuhteen päättämisestä, epäillystä tietomurrosta tai odottamattomasta poissaolosta, joka edellyttää väliaikaista jäädyttämistä.

Sovi ajoituksesta HR:n ja asianomaisen johdon kanssa. Rajaa arkaluonteiset työsuhteen päättämistä koskevat tiedot niille, jotka tarvitsevat niitä, mutta varmista, että toteuttajat saavat riittävästi tietoa toimiakseen. Korkean riskin lähdöt voivat edellyttää koordinoitua välitöntä toimintaa; rutiinilähdöissä voidaan sallia suunniteltu luovutus ennen pääsyn päättymistä.

Älä anna tietojen siirron tai laitteiden lähettämisen viivästyttää käyttöoikeuksien poistoa. Näillä toiminnoilla voi olla erilliset valmistumispäivät ja omistajat. Jos laukaiseva tieto saapuu myöhässä, kirjaa tarkoitettu katkaisuhetki, todellinen toteutus ja altistumisjakso sen sijaan, että muuttaisit asiakirjoja niin, että tapahtuma näyttäisi oikea-aikaiselta.

Sulje kaikki olennaiset pääsyreitit

Poista ensisijainen identiteetti käytöstä ja toteuta sovelluskohtaiset toimenpiteet inventaarion mukaisesti. Käsittele tarpeen mukaan aktiiviset istunnot, päivitystunnisteet, paikalliset tilit, etuoikeutetut tilit, etäpääsy, varmenteet ja henkilökohtaiset tunnukset. Keskitetyn tilin poistaminen käytöstä ei todista, että jokainen olemassa oleva istunto tai erikseen myönnetty tunnus olisi muuttunut käyttökelvottomaksi.

Vaihda riskin mukaan jaetut salaisuudet, joihin henkilöllä oli pääsy, ja tarkista, ettei vaihto häiritse niistä riippuvia järjestelmiä. Poista palautusmenetelmät tai delegoidut oikeudet, joilla pääsy voitaisiin palauttaa. Jos asiakkaiden tai toimittajien ympäristöt ovat osallisina, pyydä käyttöoikeuksien poistoa niiden omistajalta ja säilytä vahvistus.

Tallenna yksittäiset tulokset. Liittymän aikakatkaisu ei ole onnistunut sulkeminen pelkästään siksi, että kokonaisajo päättyi. Ohjaa virheet nimetylle reagoijalle, käytä hyväksyttyä varamenettelyä ja varmenna lopputila. Kiireellisten ratkaisemattomien käyttöoikeuksien tulee siirtyä tietoturvan eskalointiprosessiin.

Palauta laitteet olettamatta etäkomentojen onnistuneen

Seuraa jokaista luovutettua laitetta palautuksen, tarkastuksen ja hyväksytyn nollauksen tai hävittämisen läpi. Kirjaa etätyöntekijöiden osalta lähetysjärjestelyt ja ratkaisematon hallussapito. Poista fyysinen pääsy ja ota tarvittaessa takaisin tunnisteet tai avaimet.

Jos palautus viivästyy, käytä käytettävissä olevia lukitus- tai tyhjennyskontrolleja politiikan ja riskin mukaisesti. Erota komennon antaminen siitä, että laite kuittaa ja suorittaa sen. Verkon ulkopuolella oleva kannettava ei välttämättä vastaanota komentoa. Arvioi jäännösaltistus salauksen tilan, paikallisten tunnusten, välimuistissa olevien tietojen ja käytettävissä olevien verkkorajoitusten perusteella sen sijaan, että pitäisit ”tyhjennys jonossa” -tilaa todisteena tietojen poistamisesta.

Säilytä tarvittavat tiedot ja ota lisenssit takaisin

Nimeä seuraaja liiketoiminnan asiakirjoille, koodivarastoille, jaetuille työnkuluille ja palveluiden omistajuudelle. Käytä valtuutettuja hallinnollisia siirtomekanismeja sen sijaan, että pyytäisit jotakuta esiintymään entisenä työntekijänä. Rajaa postilaatikko- tai tiedostopääsy, kirjaa tarkoitus ja rajoita pääsyn saavien ihmisten määrää.

Erota käyttöoikeuksien poisto, lisenssien takaisinotto, säilytys ja poistaminen. Lisenssin poistaminen voi vaikuttaa tietojen saatavuuteen eri sovelluksissa eri tavoin. Tarkista säilytysvaatimukset ja mahdolliset oikeudelliset säilytysvelvoitteet ennen peruuttamatonta siivousta.

Henkilötietojen osalta GDPR:n 5 artikla vahvistaa säilytyksen rajoittamisen periaatteen; se ei luo yhtä yleistä työntekijätilien poistamisen määräaikaa. Määritä perustellut säilytysajat ja siivousvastuut. 32 artikla edellyttää riskiin nähden asianmukaisia turvatoimia, joten dokumentoi poistumisvaiheen hallintakeinojen perustelut sen sijaan, että pitäisit tarkistuslistaa sellaisenaan lainmukaisuutena.

Säilytä näyttö todellisesta muutoksesta

Hyödyllinen kirjaus yhdistää valtuutetun päätöksen havaittuun tulokseen. Säilytä tapahtuma, hyväksyntä, asianomaiset järjestelmät, toteutusajat, varmennustulokset ja poikkeusten käsittely. Ota mukaan tarkoitettu voimaantuloaika, jotta katselmoijat voivat arvioida oikea-aikaisuutta.

Käytännöllinen näyttöpaketti sisältää:

• Pysyvän henkilö- ja tapahtumatunnisteen sekä käynnistäneen lähteen.
• Hyväksytyn perustason sekä mahdolliset säilytetyt tai lisätyt oikeudet.
• Järjestelmäkohtaiset toimenpiteet, tulokset, aikaleimat ja olennaiset lokiviittaukset.
• Varmennuksen, joka osoittaa lopullisen käyttöoikeustilan.
• Laitteisiin, tietojen siirtoon ja lisensseihin liittyvät tulokset tarvittaessa.
• Epäonnistuneet toimenpiteet ja poikkeukset omistajineen, määräaikoineen ja sulkemisnäyttöineen.

Politiikka osoittaa aikomuksen. Tiketti osoittaa koordinoinnin. Sovelluksen tulos tai käyttöoikeusvienti auttaa osoittamaan toteutuksen. Mitään niistä ei pidä käyttää muiden korvikkeena. Kuvakaappaukset voivat olla hyödyllisiä, kun vahvempia vientejä ei ole saatavilla, mutta niihin on sisällytettävä riittävästi kontekstia järjestelmän, kohteen ja havaintoajan tunnistamiseksi.

Suojaa nämä kirjaukset: ne sisältävät työsuhdetietoja ja tietoturvan kannalta arkaluonteisia yksityiskohtia. Sovella pääsyrajoituksia ja säilytysaikataulua, äläkä kerää näytöksi salasanoja, tarpeettomia kuvauksia työsuhteen päättymisestä tai kokonaisia postilaatikoita. Historiallisten kirjausten tulee pysyä ymmärrettävinä myös sen jälkeen, kun operatiiviset tilit on poistettu.

Esimerkki: siirto, jota seuraa lähtö

Tarkastellaan havainnollistavaa yritystä, jolla on keskitetty identiteetintarjoaja, hallitut kannettavat ja taloussovellus paikallisine oikeuksineen. Oletetaan, että työntekijä siirtyy taloushallinnon operaatioista asiakaspalveluun 1. kesäkuuta, tarvitsee viiden työpäivän luovutusjakson ja lähtee myöhemmin yrityksestä 30. syyskuuta. Nämä päivämäärät ja järjestelyt ovat esimerkkioletuksia, eivät määrättyjä aikoja.

Siirtoa varten IT tallentaa nykyiset oikeudet. Asiakaspalvelun käyttöoikeudet hyväksytään, talouden kirjoitusoikeudet poistetaan voimaantulohetkellä ja rajattu lukuoikeus talouteen säilytetään luovutusjakson päättymiseen asti. Talouden omistaja hyväksyy poikkeuksen. Koska taloussovellus ylläpitää paikallisia oikeuksia, sen ylläpitäjä toteuttaa ja varmentaa muutoksen erillään identiteetintarjoajan ryhmäpäivityksestä.

Jakson päättyessä varmennuksessa havaitaan, että paikallinen vientioikeus on jäänyt voimaan. Siirtokirjaus pysyy avoinna, ylläpitäjä poistaa oikeuden ja katselmoija kirjaa lopputilan. Opetus on täsmällinen: roolinmuutos onnistui keskitetysti, mutta sovelluksen oikeusmalli edellytti lisätoimenpidettä.

Myöhempää lähtöä varten prosessi asettaa tarkan katkaisuhetken, siirtää liiketoiminnan tiedostot hyväksytylle seuraajalle, poistaa identiteetit käytöstä, mitätöi sovellettavat istunnot ja tunnisteet ja tarkistaa taloussovelluksen tilin suoraan. Kannettava ei ole vielä saapunut kuriirilla. Sen palautus jää laitepoikkeukseksi, ja rajaamistoimet ja laitehavainnot kirjataan erillään käyttöoikeuksien poistosta.

Syntyvä näyttö osoittaa sekä onnistuneet muutokset että alkuperäisen poiston epäonnistumisen. Virheen kätkeminen hävittäisi tiedon, jota tarvitaan työnkulun parantamiseen.

Testaa kattavuus ja tee seuraava parannus konkreettiseksi

Ota otos todellisista elinkaaritapahtumista ja vertaa niitä sovellusinventaarioon. Ota mukaan alihankkijat, etuoikeutetut käyttäjät, etätyöntekijät, siirtyjät väliaikaisella päällekkäisyydellä ja identiteetintarjoajan ulkopuoliset sovellukset. Käyttöoikeuskatselmoinneissa tulee myös tarkastella, vastaavatko nykyiset oikeudet edelleen kunkin henkilön vastuita; ne täydentävät tapahtumapohjaisia muutoksia eivätkä korvaa niitä.

Testaa virhepolut tavanomaisen toteutuksen lisäksi: väliin jäänyt HR-tapahtuma, epäonnistunut liittymä, tavoittamaton ylläpitäjä, viivästynyt laitteen palautus tai peruutettu aloitus. Tarkista, että hälytykset tavoittavat reagoijan ja että uudelleenyritykset tai manuaaliset toimenpiteet tuottavat varmennettavia tuloksia.

Hyödyllisiä mittareita ovat käyttöoikeuksien poiston viive suhteessa sovittuun katkaisuhetkeen, ratkaisua odottavat epäonnistuneet toimenpiteet, erääntyneet väliaikaiset käyttöoikeudet ja ilman varmennusta suljetut tapahtumat. Määritä, mitä kukin mittari laskee. Hyvä keskiarvo voi kätkeä yhden pitkäikäisen etuoikeutetun poikkeuksen. Käytä havaintoja roolien perustasojen, liittymien toiminnan, omistajuuden ja eskalointisääntöjen päivittämiseen.

Secani voi tukea katselmoitavaa hallintakeinokirjausta yhdistämällä vaatimukset järjestelmiin, omistajiin, näyttöön ja päätöksiin. Pidä tilimuutokset operatiivisissa identiteetti- ja laitehallintajärjestelmissä; käytä vaatimustenmukaisuuden työtilaa soveltamisalan, ladattujen tulosten, poikkeusten ja katselmointipäätösten säilyttämiseen. Ihmiskatselmoijien tulee validoida tekoälyavusteiset näyttöä koskevat johtopäätökset ennen niihin luottamista.

Aloita yhdestä edustavasta tiimistä ja äskettäisestä tulijasta, siirtyjästä ja lähtijästä. Jäljitä kukin tapahtuma ilmoituksesta järjestelmän todelliseen tilaan. Korjaa ensimmäinen esiin tullut vastuunsiirto tai pääsyreitti, nimeä sille omistaja ja testaa se uudelleen ennen prosessin laajentamista.