Ei-inhimillisten identiteettien salaisuuksien hallinta vuoden 2026 auditointeja varten

Hälytys kello 02.13, jota kukaan ei osannut kohdistaa

Tiistaiaamuna kello 02.13 tietoturvaoperaatioiden kanava aktivoituu. Tuotantotietokannan vienti on käynnistynyt sisäiseltä automaatiotililtä. Pääsypolku on oikeutettu. Token on voimassa. Lähde-IP kuuluu pilviajoympäristöön, jota kehitystiimi käyttää. Haittaohjelmia ei näy. Tietojenkalasteluilmoitusta ei ole.

Tietoturvajohtaja esittää ensimmäisen ilmeisen kysymyksen: “Kuka omistaa tämän identiteetin?”

Hiljaisuus.

DevOps-vastaava muistaa, että token luotiin asiakkaan migraation yhteydessä kaksi vuotta sitten. Alustatiimi sanoo, että sitä saatetaan käyttää laskutusintegraatiossa. Tietokannan ylläpitäjä kertoo, että sillä on lukuoikeus, koska sen poistaminen rikkoi kerran yöajon. Lakitiimi kysyy, oliko mukana henkilötietoja. Vaatimustenmukaisuustiimi kysyy, onko kyseessä NIS2:n, DORA:n tai GDPR:n mukaisesti ilmoitettava poikkeama. Auditoija pyytää näyttöä siitä, että palvelutilit, API-avaimet, varmenteet ja CI/CD-salaisuudet on inventoitu, katselmoitu, kierrätetty, seurattu ja poistettu käytöstä tarvittaessa.

Kello 09.00 auditointihavainnon luonnos alkaa jo hahmottua. Unohdetusta mikropalvelusta löytyi kovakoodattu API-avain, jota ei ollut kierrätetty. Se antaa laajat oikeudet tuotannon asiakastapahtumatietokantaan. Sen luonut kehittäjä lähti organisaatiosta kaksi vuotta sitten. Järjestelmällä ei ole nimettyä omistajaa, dokumentoitua tarkoitusta, kiertolokia eikä valvontasääntöä.

Tämä on vuoden 2026 ei-inhimillisten identiteettien ongelma.

Useimmat organisaatiot ovat parantaneet ihmiskäyttäjien pääsynhallintaa. Niillä on MFA, JML-prosessit, etuoikeutettujen käyttöoikeuksien katselmoinnit ja identiteetintarjoajien lokit. Koneidentiteetit ovat kuitenkin lisääntyneet nopeammin kuin niiden hallinta. Palvelutilit, työkuormaidentiteetit, API-avaimet, OAuth-tokenit, SSH-avaimet, varmenteet, Kubernetes-salaisuudet, SaaS-integraatiotokenit, ohjelmistorobotiikan tilit ja CI/CD-käyttöönottojen tunnistetiedot suorittavat nyt kriittisiä liiketoimintatoimia olematta “käyttäjiä” ihmiskäyttäjän merkityksessä.

SaaS-palveluntarjoajille, fintech-yhtiöille, hallinnoiduille palveluntarjoajille, pilvioperaattoreille ja datavaltaisille pk-yrityksille hallitsemattomat ei-inhimilliset identiteetit eivät ole enää tekninen hygieniaongelma. Ne ovat hallitustason resilienssi- ja vaatimustenmukaisuusriski. NIS2 käsittelee pääsynhallintaa, omaisuudenhallintaa, toimitusketjun tietoturvaa, poikkeamien käsittelyä ja kyberhygieniaa keskeisinä kyberturvallisuusriskien hallintatoimenpiteinä. DORA asettaa ICT-riskin, toiminnallisen häiriönsietokyvyn, poikkeamien raportoinnin ja ICT-kolmansien osapuolten riskin finanssialan toimijoiden hallintoelimen vastuulle. GDPR edellyttää, että rekisterinpitäjät ja henkilötietojen käsittelijät suojaavat henkilötietoja ja osoittavat vastuullisuuden.

Vaikeinta ei ole osoittaa, että salaisuuksia on olemassa. Vaikeinta on osoittaa, että jokaisella ei-inhimillisellä identiteetillä on omistaja, tarkoitus, elinkaari, riskiluokitus, hyväksytty käyttöoikeus, turvallinen säilytysmenetelmä, kiertoperiaate, seurannan kattavuus ja käytöstäpoistopolku.

Miksi ei-inhimillisistä identiteeteistä tuli uusi etuoikeutetun pääsyn ongelma

Ei-inhimillinen identiteetti, eli NHI, on mikä tahansa digitaalinen identiteetti, jota käyttää ohjelmisto, infrastruktuuri tai automatisoitu prosessi ihmisen sijaan. Käytännössä se kattaa sovellusten käyttämät palvelutilit, SaaS-integraatioiden API-avaimet, kolmannen osapuolen sovellusten käyttämät OAuth- ja refresh-tokenit, automaation käyttämät SSH-avaimet, TLS-varmenteet ja yksityiset avaimet, CI/CD-salaisuudet, pilvityökuormien identiteetit, tietokantayhteysmerkkijonot, upotetut tunnistetiedot, RPA-bottitilit ja toimittajien hallinnoimat integraatiotunnistetiedot.

Näillä identiteeteillä on usein kolme ominaisuutta, jotka huolestuttavat auditoijia.

Ensinnäkin ne ovat pitkäikäisiä. Ihmiskäyttäjä voi kierrättää tunnistetietoja, vaihtaa roolia ja poistua muodollisen työsuhteen päättämisprosessin kautta. Julkaisuikkunan aikana luotu API-token voi pysyä aktiivisena vuosia, koska kukaan ei halua ottaa riskiä tuotannon rikkoutumisesta.

Toiseksi ne ovat vaikutusvaltaisia. Käyttöönoton token voi muuttaa infrastruktuuria. Pilvipalvelun palveluidentiteetti voi luoda tallennustilaa. Tietokantatili voi viedä asiakastietueita. Allekirjoitusavain voi vaarantaa ohjelmistojen toimitusketjun eheyden.

Kolmanneksi niitä on vaikea kohdistaa vastuuhenkilöön. Ihmiskäyttäjien identiteetit kytkeytyvät henkilöstöhallinnon tietoihin. Ei-inhimilliset identiteetit kytkeytyvät usein skripteihin, putkiin, toimittajiin, unohdettuihin projekteihin tai dokumentoimattomiin integraatioihin.

Clarysecin Zenith Blueprint: auditoijan 30 askeleen tiekartta Zenith Blueprint nostaa tämän suoraan esiin Controls in Action -vaiheen vaiheessa 22:

Älä myöskään unohda ei-inhimillisiä identiteettejä. Juuri tässä auditoinnit paljastavat usein hiljaisen altistumisen. Seurataanko API-tokeneita? Onko integraatiotilit kytketty henkilöihin vai leijuvatko ne vailla omistajaa? Milloin viimeksi vuosikymmeniä vanhaan skriptiin upotettu tietokannan käyttöoikeusmerkkijono kierrätettiin?

Identiteetinhallinta ei ole näyttävää, mutta se on rakenteellista. Ilman sitä ISMS on vain kokoelma lukittuja ovia ilman varmuutta siitä, kenellä avaimet ovat.

Viimeinen lause kiteyttää asian. Yrityksellä voi olla viimeistelty pääsynhallintapolitiikka ja se voi silti epäonnistua auditoinnissa, jos koneidentiteettejä ei hallita. ISMS, joka ei pysty selittämään, kuka omistaa salaisuuden, miksi se on olemassa ja milloin se on viimeksi katselmoitu, ei vielä toimi hallittuna järjestelmänä.

ISO/IEC 27001:2022 muuttaa salaisuuksien hallinnan näytöksi

ISO/IEC 27001:2022 on tehokas, koska se ei käsittele salaisuuksien hallintaa erillisenä suunnittelutehtävänä. Se edellyttää riskiperusteista ISMS:ää, jolla on määritelty soveltamisala, sidosryhmien vaatimukset, johdon vastuu, riskien arviointi, riskien käsittely, hallintakeinojen valinta, soveltuvuuslausunto ja jatkuva parantaminen.

Ei-inhimillisten identiteettien osalta organisaation ei tule aloittaa työkaluhankinnasta. Sen tulee aloittaa soveltamisalasta ja velvoitteista.

ISO/IEC 27001:2022:n kohtien 4.1–4.4 mukaisesti organisaatio määrittää sisäiset ja ulkoiset tekijät, sidosryhmät, lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset vaatimukset sekä rajapinnat ja riippuvuudet. NHI-kontekstissa ISMS:n soveltamisalan tulee tunnistaa pilviympäristöt, SaaS-alustat, CI/CD-järjestelmät, tuotantosovellukset, asiakasintegraatiot, henkilötietojen käsittelijät, hallinnoidut palveluntarjoajat ja kryptografiset palvelut, joissa koneiden tunnistetietoja on.

Kohdat 5.1–5.3 asettavat johdon vastuuseen politiikasta, resursseista, rooleista ja suorituskyvyn raportoinnista. Tämä on tärkeää, koska NHI-korjaustoimenpiteet aiheuttavat usein operatiivista jännitettä. Tuotantotietokannan tunnistetiedon kierrättäminen, vanhan jaetun palvelutilin korvaaminen tai holvipohjaisen salaisuuksien injektoinnin käyttöönotto voi rikkoa hauraita työnkulkuja. Ilman ylimmän johdon tukea tiimit lykkäävät siivousta.

Kohdat 6.1.1–6.1.3 ja 6.2 muodostavat hallintakeinojen moottorin. Organisaatio määrittää riskikriteerit, tunnistaa luottamuksellisuuteen, eheyteen ja saatavuuteen kohdistuvat riskit, nimeää riskinomistajat, arvioi todennäköisyyden ja vaikutuksen, valitsee käsittelyvaihtoehdot, valitsee hallintakeinot, tuottaa soveltuvuuslausunnon ja seuraa mitattavia tavoitteita.

Käytännössä ei-inhimillisten identiteettien riskienkäsittelysuunnitelman tulee vastata seuraaviin kysymyksiin:

• Mitkä järjestelmät ja liiketoimintapalvelut ovat riippuvaisia NHI-identiteeteistä?
• Mitkä salaisuudet voivat käyttää henkilötietoja, säänneltyjä finanssipalveluja, tuotantoinfrastruktuuria tai kriittisiä asiakaspalveluja?
• Mitkä identiteetit ovat etuoikeutettuja, passiivisia, jaettuja, toimittajan hallinnoimia tai hallitsemattomia?
• Mitkä hallintakeinot vähentävät riskiä, kuten holvitus, avainten kierto, vähimmän oikeuden periaate, vanheneminen, varmenteiden elinkaaren hallinta, CI/CD-skannaus, seuranta ja hätäperuutus?
• Mitkä jäännösriskit edellyttävät liiketoiminnan hyväksyntää?

ISO/IEC 27002:2022 tarjoaa tämän jälkeen liite A:n hallintakeinoluettelon. Keskeisimpiä hallintakeinoja ovat 5.9 tieto- ja muiden niihin liittyvien omaisuuserien luettelo, 5.15 pääsynhallinta, 5.16 identiteetinhallinta, 5.17 todennustiedot, 5.18 käyttöoikeudet, 5.19 tietoturvallisuus toimittajasuhteissa, 5.20 tietoturvallisuuden käsittely toimittajasopimuksissa, 5.21 tietoturvallisuuden hallinta ICT-toimitusketjussa, 5.23 tietoturvallisuus pilvipalvelujen käytössä, 5.24 poikkeamien hallinnan suunnittelu ja valmistelu, 5.28 todentavan aineiston kerääminen, 8.2 etuoikeutetut käyttöoikeudet, 8.3 tiedonsaannin rajoittaminen, 8.5 turvallinen todennus, 8.15 lokitus, 8.16 seurantatoiminnot, 8.24 kryptografian käyttö, 8.25 turvallisen kehittämisen elinkaari, 8.26 sovellusturvallisuusvaatimukset, 8.28 turvallinen ohjelmointi ja 8.31 kehitys-, testi- ja tuotantoympäristöjen erottaminen.

Clarysecin Zenith Controls: vaatimustenmukaisuuksien välinen opas Zenith Controls kartoittaa nämä ISO/IEC 27002:2022 -suhteet tavalla, jota auditoijat ja kontrollien omistajat voivat käyttää. Hallintakeinon 5.16, identiteetinhallinta, osalta Zenith Controls selittää identiteetin ja tunnistetietojen välisen yhteyden:

Identiteetinhallinta määrittää kuka, kun taas todennustiedot varmistavat miten eli sen, että identiteettiä väittävä henkilö on oikeutettu. 5.16 ohjaa identiteetin elinkaaren hallintaa, kun taas 5.17 varmistaa, että salasanat, tokenit, varmenteet ja muut tunnistetiedot on turvallisesti kytketty kyseisiin identiteetteihin ja hallittu asianmukaisesti vahvan tunnistautumisen tueksi.

Tämä suhde on NHI-identiteeteille olennainen. Token ilman identiteetin omistajaa ei ole auditoitavissa. Palvelutili ilman käyttöoikeuskatselmointia ei noudata vähimmän oikeuden periaatetta. Varmenne ilman elinkaaritilaa ei ole hallittua kryptografiaa. Toimittajan integraatiotunnistetieto ilman sopimusehtoja ei ole tehokasta kolmannen osapuolen riskienhallintaa.

Clarysecin kontrollimalli: identiteetti, salaisuus, käyttöoikeus, näyttö

Clarysec toteuttaa ei-inhimillisten identiteettien ja salaisuuksien hallinnan toistettavan kontrollimallin avulla. Emme käsittele “salaisuuksia” vain DevOps-asiana emmekä “palvelutilejä” vain IAM-asiana. Yhdistämme identiteetin, salaisuuden, käyttöoikeuden ja näytön.

Politiikkatasolla tästä tulee täytäntöönpantavaa.

Pk-yrityksille Clarysecin Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka-sme Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka-sme toteaa:

Palvelutilit (joita järjestelmät tai sovellukset käyttävät) on dokumentoitava, rajattava tiettyihin järjestelmiin eikä niitä saa koskaan käyttää interaktiivisiin kirjautumisiin.

Tämä estää klassisen virhemallin, jossa palvelutilistä tulee jaettu ylläpitäjäkirjautuminen. Se antaa myös auditoijalle selkeän testin: näytä palvelutililuettelo, näytä järjestelmärajaus ja näytä, että interaktiivinen kirjautuminen on poistettu käytöstä tai teknisesti estetty.

Clarysecin omaisuuden hallintapolitiikka-sme omaisuuden hallintapolitiikka-sme laajentaa omaisuuserien määritelmän kattamaan:

Digitaaliset tunnistetiedot ja palvelut: verkkotunnukset, digitaaliset varmenteet, API-avaimet, sähköpostitilit, pilvikirjautumiset

Tämä on tärkeää, koska monet organisaatiot inventoivat vain palvelimet, kannettavat työasemat ja sovellukset. Vuonna 2026 API-avain voi olla arkaluonteisempi kuin kannettava työasema. Varmenteen yksityinen avain voi olla tuotannon todennusomaisuuserä. Automaation käyttämä pilvikirjautuminen voi aiheuttaa sääntelyn alaisten tietojen altistumisen. Tunnistetietojen käsitteleminen omaisuuserinä on auditointivalmiin salaisuuksien hallinnan perusta.

Yritysympäristöissä Clarysecin Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka nostaa näyttövaatimusten tasoa:

Organisaation on ylläpidettävä yksityiskohtaista luetteloa kaikista aktiivisista ja passiivisista tunnistetiedoista, etuoikeutetuista tileistä ja järjestelmätason palvelutileistä. Tätä luetteloa on päivitettävä jatkuvasti ja katselmoitava neljännesvuosittain.

Neljännesvuosittainen katselmointi paljastaa monet puutteet. Passiiviset tunnistetiedot, orvot palveluidentiteetit, vanhat integraatiokäyttäjät, hallitsemattomat toimittajatilit ja hätätilanteiden tokenit tulevat näkyviin vasta, kun joku vertaa rekisteriä todellisiin IAM-, holvi-, CI/CD- ja pilvitallenteisiin.

Salaisuudet ovat todennustietoja, eivät kehittäjien mukavuustekijä

Vaarallisin ilmaus salaisuuksien hallinnassa on “väliaikainen avain”.

Väliaikaisista avaimista tulee pysyviä. Testitunnistetiedot päätyvät tuotantoon. Lähdekoodi paljastaa tokeneita. Build-lokit paljastavat salasanoja. Tukitiimit jakavat varmenteita tikettien kautta. Kehittäjät kopioivat ympäristötiedostoja chattiin. Toimeksisaaja luo pilvipalvelun palveluidentiteetin ja poistuu.

Zenith Blueprint, Controls in Action -vaiheen vaihe 22, kuvaa todennustietoja laajasti:

Tämä hallintakeino ei koske pelkästään salasanoja, vaikka salasanat ovatkin osa kokonaisuutta. Se koskee jokaista tunnistetietoa, jolla identiteetti esitetään: salasanat, PIN-koodit, kryptografiset avaimet, biometriset mallit, älykortit, tokenit, varmenteet, OAuth-tokenit, SSH-avaimet, API- salaisuudet. Ne ovat valtakunnan avaimet, ja hallintakeino 5.17 varmistaa, että niitä käsitellään niiden ansaitsemalla vakavuudella.

Todetaan selkeästi: heikko todennuksen hallinta on edelleen yksi merkittävimmistä tietomurtojen juurisyistä. Heikot tai jaetut salasanat. Kovakoodatut tunnistetiedot lähdekoodissa. Muuttamattomat oletuskirjautumiset hallintaportaaleissa. Varmenteet, joiden omistajuus on vanhentunut tai tuntematon. Jokaisessa näistä tapauksista epäonnistunut osa ei ole identiteetti, vaan kyvyttömyys suojata ja hallinnoida mekanismia, jolla identiteetti todistetaan.

Clarysecin politiikat muuttavat tämän operatiivisiksi säännöiksi.

Kryptografisten hallintakeinojen politiikka-sme Kryptografisten hallintakeinojen politiikka-sme toteaa:

Avaimia ei saa säilyttää selväkielisinä eikä upottaa lähdekoodiin, asiakirjoihin tai sähköposteihin

Turvallisen kehityksen politiikka-sme Turvallisen kehityksen politiikka-sme toteaa:

Ei kovakoodattuja tunnistetietoja tai salaisuuksia lähdekoodissa

Yritystiimeille Turvallisen kehityksen politiikka Turvallisen kehityksen politiikka toteaa:

Salaisuuksia ei saa kovakoodata eikä tallentaa selväkielisinä tietovarastoihin.

Ja Sovellusturvallisuusvaatimusten politiikka Sovellusturvallisuusvaatimusten politiikka on vielä suorempi:

Salasanojen tai kryptografisten avainten tallentaminen selväkielisinä on ehdottomasti kielletty.

Nämä politiikkalausekkeet luovat selkeän auditointijäljen. Tietoturvatiimit voivat testata tietovarastoja, CI/CD-muuttujia, konttikuvia, konfiguraatiovarastoja, asianhallintajärjestelmiä, dokumentaatioalustoja ja lokeja nimenomaisia vaatimuksia vasten. Ne tukevat myös GDPR:n Article 32 mukaista käsittelyn turvallisuutta, koska salaisuuksien paljastuminen voi johtaa suoraan luvattomaan pääsyyn henkilötietoihin.

Yritystason kryptografinen hallinta tarvitsee myös omistajuuden. Clarysecin Kryptografisten hallintakeinojen politiikka Kryptografisten hallintakeinojen politiikka edellyttää:

Keskitettyä avaintenhallintarekisteriä on ylläpidettävä kaikkien kryptografisten avainten, niiden elinkaaritilan, nimettyjen vastuuhenkilöiden ja käyttökontekstien kirjaamiseksi.

Ei-inhimillisten identiteettien osalta rekisterin tulee yhdistää varmenneavaimet, allekirjoitusavaimet, API-avaimet ja pilven hallinnoimat avaimet laajempaan NHI-rekisteriin. Auditoijan tulee pystyä jäljittämään tuotantovarmenne liiketoimintapalvelusta omistajaan, vastuuhenkilöön, vanhenemiseen, kiertonäyttöön ja tietoturvapoikkeamiin reagoinnin menettelyyn.

NIS2, DORA ja GDPR: yksi näyttömalli, monta valvojaa

Ei-inhimillisten identiteettien hallinta on vaatimustenmukaisuuksien välinen ongelma, koska sama epäonnistuminen voi laukaista useita velvoitteita.

SaaS-palveluntarjoajalta vuotanut API-token voi aiheuttaa palveluhäiriön NIS2:n näkökulmasta, henkilötietojen altistumisen GDPR:n näkökulmasta ja sopimusperusteisen poikkeamaraportoinnin finanssiasiakkaille DORA:n toimitusketjuodotusten mukaisesti. ICT-palveluntarjoajan vaarantunut CI/CD-salaisuus voi vaikuttaa asiakkaiden häiriönsietokykyyn, ohjelmistojen eheyteen ja toiminnan jatkuvuuteen. Unohdettu toimittajan integraatiotili voi luoda pääsyn säänneltyihin järjestelmiin ilman asianmukaista huolellisuutta tai sopimuskontrolleja.

NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä. Vähimmäisalueisiin kuuluvat riskianalyysi, tietojärjestelmien tietoturvapolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, turvallinen hankinta, kehittäminen ja ylläpito, haavoittuvuuksien käsittely, vaikuttavuuden arviointi, kyberhygienia, kryptografia, henkilöstöturvallisuus, pääsynhallinta ja omaisuudenhallinta sekä tarvittaessa MFA tai jatkuva todennus. Ei-inhimilliset identiteetit ulottuvat lähes kaikkiin näihin alueisiin. NIS2 Article 23 luo myös vaiheistetun merkittävien poikkeamien raportoinnin, johon sisältyvät ennakkovaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa ja loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta.

DORA soveltuu 17. tammikuuta 2025 alkaen ja kattaa ICT-riskien hallinnan, merkittävien ICT:hen liittyvien poikkeamien raportoinnin, toiminnallisen häiriönsietokyvyn testauksen, tietojen jakamisen ja ICT-kolmansien osapuolten riskin. Article 5 ja Article 6 edellyttävät hallinnointia, hallintoelimen vastuuta ja dokumentoitua ICT-riskienhallinnan viitekehystä. Article 8 edellyttää ICT:n tukemien liiketoimintatoimintojen, tietovarojen ja riippuvuuksien tunnistamista. Article 17–19 edellyttävät poikkeamien hallintaa, luokittelua ja raportointia. Article 28–30 edellyttävät ICT-kolmansien osapuolten riskienhallintaa, sopimusrekistereitä, huolellisuutta, tietoturvastandardeja, auditointioikeuksia, poikkeamatukea, alihankinnan kontrolleja ja irtautumisstrategioita.

GDPR soveltuu kaikkialla, missä henkilötietoja käsitellään sen alueellisen soveltamisalan mukaisesti. Article 5 edellyttää eheyttä, luottamuksellisuutta ja vastuullisuutta. Article 32 edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä käsittelyn turvallisuuden varmistamiseksi. Jos palvelutili tai API-avain voi käyttää henkilötietoja, hallitsemattomista salaisuuksista tulee tietosuojakontrollin epäonnistuminen, ei pelkkä IT-asia.

Sama näyttö voi tukea ISO/IEC 27001:2022 -sertifiointia, NIS2-valvontaa, DORA-tarkastuksia ja GDPR:n mukaista vastuullisuutta, kun se on jäsennetty oikein.

NIST CSF 2.0 voi toimia saman näytön viestintäkerroksena. Sen GOVERN-toiminto kattaa sidosryhmien odotukset, lakisääteiset ja sopimusperusteiset velvoitteet, riskinottohalukkuuden, johdon vastuun, politiikan ja valvonnan. Sen operatiiviset tulokset kattavat omaisuusluettelot, toimittajien tuottamat palvelut, identiteetin- ja tunnistetietojen hallinnan, vähimmän oikeuden periaatteen, tietoturvan, lokituksen, seurannan, tietoturvapoikkeamiin reagoinnin ja palautumisen.

COBIT 2019- ja ISACA-tyyppiset varmentamistiimit tarkastelevat yleensä hallintoa ja prosessikyvykkyyttä. Ne kysyvät, onko vastuu osoitettu, onko kontrollit upotettu operatiivisiin prosesseihin, hyväksytäänkö poikkeukset, raportoidaanko mittareita johdolle ja osoittaako näyttö toistettavuutta eikä vain kertaluonteista siivousta.

Käytännön sprintti ei-inhimillisten identiteettien rekisterin rakentamiseen

Käytännön Clarysec-toimeksianto alkaa usein kohdennetulla sprintillä, ei kuuden kuukauden työkaluhankkeella. Tavoitteena on tuottaa puolustettava NHI-rekisteri, riskijärjestys ja korjaussuunnitelma, jotka voidaan syöttää ISO/IEC 27001:2022 -riskienkäsittelysuunnitelmaan ja soveltuvuuslausuntoon.

Aloita yhdestä liiketoimintapalvelusta, kuten asiakaslaskutusalustasta, kaupankäyntisovelluksesta, potilasportaalista tai SaaS-vuokralaisten hallintajärjestelmästä. Sisällytä tuotanto, staging, CI/CD, pilvi-infrastruktuuri, seurantatyökalut, tietokannat, SaaS-integraatiot ja toimittajien hallinnoimat palvelut.

Kytke tämä Zenith Blueprintin Risk Management -vaiheen vaiheeseen 14, jossa Clarysec yhdenmukaistaa käsittelypolitiikat sääntelyn ristiviittausten kanssa. Tässä vaiheessa turvallisen kehityksen ja putkien kontrollit sisältävät kovakoodattujen salaisuuksien kiellon, vertaiskatselmoinnin, automatisoidun staattisen analyysin, riippuvuusskannauksen, kehitys-, testi- ja tuotantoympäristöjen erottamisen, MFA:n putkiin pääsyssä, build-artefaktien eheyden ja CI/CD-lokituksen.

Kerää identiteetit ja salaisuudet identiteetintarjoajasta, pilvi-IAM:stä, salaisuuksien holvista, Kubernetesista, CI/CD-muuttujista, tietovaraston asetuksista, tietokantakäyttäjistä, SaaS-hallintakonsoleista, varmenteiden hallintatyökaluista ja toimittajadokumentaatiosta.

Riskiluokittele identiteetit, joilla on tuotantopääsy, etuoikeutetut käyttöoikeudet, pääsy henkilötietoihin, kriittisen tai tärkeän toiminnon riippuvuus, toimittajan hallinta, pitkäikäisiä tokeneita, ei omistajaa, ei kiertoa, ei seurantaa tai kovakoodattu säilytys. Käytä ISO/IEC 27001:2022 -riskikriteerejä todennäköisyyden ja vaikutuksen pisteyttämiseen. Käytä DORA:n kriittisen tai tärkeän toiminnon analyysiä soveltuvin osin. Käytä GDPR:n vaikutusnäkökulmia, kun henkilötiedot ovat käytettävissä. Käytä NIS2:n palveluvaikutusta, kun häiriö tai asiakashaitta on uskottava.

Sovella käsittelytoimia jokaiseen korkean riskin NHI-identiteettiin. Siirrä salaisuudet lähdekoodista, asiakirjoista ja CI/CD:n selväkielisistä muuttujista holviin tai hallittuun salaisuuksien säilytyspalveluun. Korvaa jaetut palvelutilit yksilöllisillä työkuormaidentiteeteillä. Poista palvelutilien interaktiivinen kirjautuminen käytöstä. Sovella vähimmän oikeuden periaatetta ja ympäristökohtaisia tunnistetietoja. Määritä kierto, vanheneminen ja hätäperuutus. Kytke salaisuudet omistajiin ja vastuuhenkilöihin. Lisää lokitus todennukselle, tokenien käytölle ja arkaluonteisille toiminnoille. Lisää hälytykset poikkeavasta maantieteellisestä sijainnista, epätavallisesta ajankohdasta, epätavallisesta volyymista tai uudesta resurssipääsystä. Päivitä toimittajasopimukset tunnistetietojen käsittelyn, poikkeamatuen ja auditointioikeuksien osalta. Dokumentoi poikkeukset riskinomistajan hyväksynnällä ja päättymispäivällä.

Testidata- ja testiympäristöpolitiikka Testidata- ja testiympäristöpolitiikka tukee ympäristöjen erottamista:

Integraation CI/CD-putkiin on varmistettava ympäristöjen ja todennustietojen erottaminen.

Tämä lauseke on usein ratkaiseva. Jos kehitys, testi ja tuotanto jakavat salaisuuksia, matalariskisestä ympäristöstä voi tulla tuotannon tietomurtopolku.

Sprintin tulee päättyä näyttöpakettiin, ei pelkkään havaintoluetteloon. Sisällytä NHI-rekisterin vienti, riskien arviointimerkinnät, käsittelysuunnitelma, soveltuvuuslausunnon kartoitus, politiikkaviittaukset, holvin kuvakaappaukset, kiertolokit, käyttöoikeuskatselmointien hyväksynnät, CI/CD-salaisuuksien skannaustulokset, seurantäsääntöjen määrittelyt, toimittajien tunnistetietojen vastuumatriisi, poikkeamien toimintamalli sekä poikkeukset omistajineen ja päättymispäivineen.

Lokitus ja havaitseminen: koneidentiteettien käytön näkyvyyden osoittaminen

Koneidentiteetti, joka on hyvin inventoitu mutta näkymätön lokeissa, on edelleen vaarallinen. Havaitseminen on osa kontrollitarinaa.

Clarysecin Lokitus- ja valvontapolitiikka-sme Lokitus- ja valvontapolitiikka-sme sisältää todennusnäytön:

Todennuslokit: onnistuneet ja epäonnistuneet kirjautumisyritykset, istunnon kesto, MFA:n käyttö

NHI-identiteettien osalta vaatimus on sovitettava koneiden todennukseen. Työkuormaidentiteetillä ei välttämättä ole MFA:n käyttöä, mutta käytettävissä tulee olla todennustapahtumat, tokenien käyttö, varmenteiden käyttö, API-kutsujen metatiedot, lähdetyökuorma, kohdepalvelu, tokenin elinikä, epäonnistumistapahtumat ja etuoikeutetut toiminnot.

Zenith Controls kytkee ISO/IEC 27002:2022 -hallintakeinon 8.2, etuoikeutetut käyttöoikeudet, lokitukseen ja seurantaan, koska etuoikeutetut tilit edellyttävät yksityiskohtaisia tallenteita ja valvontaa. Zenith Controls kytkee 8.2:n myös identiteetinhallintaan, käyttöoikeuksiin, tiedonsaannin rajoittamiseen ja turvalliseen todennukseen. Auditoijille tämä tarkoittaa, että etuoikeutetut ei-inhimilliset identiteetit tulee katselmoida ja valvoa samalla vakavuudella kuin ihmisten ylläpitäjätilit, joskus vielä vakavammin.

Hyviä seurantakysymyksiä ovat:

• Todensiko palvelutili odottamattomasta työkuormasta tai IP-alueesta?
• Käyttikö API-avain uutta päätepistettä tai tietoaineistoa?
• Käytettiinkö varmennetta sen korvaamisen jälkeen?
• Tekikö CI/CD-token käyttöönoton hyväksytyn putken ulkopuolella?
• Yrittikö vain luku -tili kirjoitustoimintoja?
• Muuttuiko passiivinen tunnistetieto aktiiviseksi?
• Käyttikö toimittajaintegraatio tietoja sovittujen aikojen tai volyymien ulkopuolella?

Kun 02.13-hälytys tapahtuu, sinun on pystyttävä vastaamaan, mitä identiteettiä käytettiin, mikä salaisuus todensi sen, mitä käyttöoikeuksia käytettiin, mihin tietoihin tai järjestelmiin toiminta vaikutti, oliko toiminta odotettua, mikä omistaja voi validoida sen ja täyttyvätkö poikkeamaraportoinnin kynnysarvot.

Auditoijan näkökulma: sama prosessi, eri kysymykset

Vahvin auditointiasema ei ole “noudatamme kaikkea”. Se on “käytämme yhtä hallittua prosessia, joka tuottaa näyttöä useisiin velvoitteisiin”. Eri auditoijat tarkastavat prosessia eri tavoin.

Näissä näkökulmissa toistuvat havainnot ovat ennakoitavia: ei yhtä NHI-luetteloa, ei omistajaa koneidentiteeteille, salaisuudet säilytetty koodissa tai dokumentaatiossa, jaetut tunnistetiedot ympäristöjen välillä, ei kiertoa tai vanhenemista, toimittajien hallinnoimat tunnistetiedot käyttöoikeuskatselmointien ulkopuolella, seuranta kattaa ihmiset mutta ei koneita, ja poikkeamien toimintamallit sivuuttavat salaisuuksien vuodot.

Jokainen havainto kytkeytyy luontevasti Clarysecin kontrolleihin, politiikkoihin ja korjauspohjiin. Vielä tärkeämpää on, että jokainen voidaan muuntaa mitattavaksi näytöksi ISMS:ssä.

Miten Clarysec auttaa saavuttamaan auditointivalmiuden

Clarysecin lähestymistapa on käytännöllinen, koska se alkaa näytöstä, jota auditoijat pyytävät, ja etenee siitä taaksepäin kontrolleihin, politiikkoihin ja operatiivisiin rutiineihin.

Zenith Blueprintin Controls in Action -vaiheen vaiheessa 19 Clarysec antaa suoraa ohjeistusta koneiden väliseen todennukseen:

Koneiden välisessä todennuksessa, kuten palvelutileillä tai API-kutsuissa, avaimia, varmenteita ja tokeneita on suojattava yhtä tiukasti. Vältä tunnistetietojen upottamista koodiin. Käytä salaisuuksien hallintajärjestelmiä tai holveja niiden turvalliseen säilyttämiseen ja kierrättämiseen.

Tyypillinen Clarysecin ei-inhimillisten identiteettien työnkulku sisältää NHI-löydön pilvestä, SaaS-palveluista, CI/CD:stä, tietovarastoista, holveista ja tietokannoista, politiikkapuutteiden arvioinnin Clarysecin pk-yritys- tai yritystason politiikkakokonaisuuksia vasten, ISO/IEC 27001:2022 -riskien arvioinnin ja käsittelykartoituksen, soveltuvuuslausunnon päivitykset, NIS2-, DORA-, GDPR- ja NIST CSF -näyttökartoituksen, NHI-rekisterin suunnittelun, avaintenhallintarekisterin yhdenmukaistamisen, salaisuuksien skannauksen, käyttöoikeuskatselmointiprosessit, toimittajien tunnistetietojen vastuumatriisit, poikkeamien toimintamallit ja auditointipaketit, joissa on kuvakaappauksia, vientejä, lokeja, hyväksyntöjä ja poikkeustallenteita.

Pk-yrityksille lähestymistapa on oikeasuhteinen. 70 hengen SaaS-palveluntarjoaja ei tarvitse samaa työkalujalanjälkeä kuin globaali pankki, mutta se tarvitsee omistajuuden, politiikan, riskien käsittelyn ja näytön. Säännellyille finanssialan toimijoille ja ICT-palveluntarjoajille sama malli skaalautuu DORA:n kriittisten toimintojen kartoitukseen, kolmansien osapuolten riskien hallintaan ja häiriönsietokyvyn testaukseen.

Jos seuraava auditointisi on vuonna 2026, älä odota, että auditoija löytää ei-inhimilliset identiteetit puolestasi. Aloita yhdestä kriittisestä palvelusta ja kysy viisi kysymystä:

1. Tunnemmeko jokaisen palvelutilin, API-avaimen, tokenin, varmenteen ja CI/CD-salaisuuden, jota tämä palvelu käyttää?
2. Onko jokaisella NHI-identiteetillä nimetty omistaja, vastuuhenkilö, tarkoitus ja riskiluokitus?
3. Säilytetäänkö salaisuudet holvissa, kierrätetäänkö ne ja suojataanko ne lähdekoodilta, asiakirjoilta, sähköposteilta ja selväkieliseltä tallennukselta?
4. Katselmoidaanko ja seurataanko etuoikeutettuja koneidentiteettejä ja onko niiden interaktiivinen käyttö estetty?
5. Voimmeko tuottaa näytön ISO/IEC 27001:2022:n, NIS2:n, DORA:n ja GDPR:n tueksi yhdestä hallitusta prosessista?

Käytä Zenith Blueprint: auditoijan 30 askeleen tiekartta Zenith Blueprint -opasta ISMS-toteutusmatkasi jäsentämiseen. Käytä Zenith Controls: vaatimustenmukaisuuksien välinen opas Zenith Controls -opasta kytkeäksesi ISO/IEC 27002:2022:n identiteetti-, todennus-, käyttöoikeus-, lokitus-, kryptografia-, turvallisen kehityksen ja toimittajakontrollit sääntelynäyttöön. Käytä Clarysecin pk-yritys- ja yritystason politiikkakirjastoa, mukaan lukien Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka-sme Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka-sme, Kryptografisten hallintakeinojen politiikka Kryptografisten hallintakeinojen politiikka, Turvallisen kehityksen politiikka Turvallisen kehityksen politiikka ja Sovellusturvallisuusvaatimusten politiikka Sovellusturvallisuusvaatimusten politiikka, jotta hyvät aikomukset muuttuvat täytäntöönpantaviksi vaatimuksiksi.

02.13-hälytys tapahtuu jossakin. Kysymys on, pystyykö organisaatiosi vastaamaan näytön avulla, kenellä oli avain, mitä se avasi, miksi se oli olemassa ja kuinka nopeasti voit tehdä siitä turvallisen.