PAM ja break-glass-tilit ISO 27001 -ympäristössä vuonna 2026

Sunnuntaiaamuna kello 02.14 poikkeamapäällikkö saa viestin, jota jokainen tietoturvajohtaja pelkää: ”Tuotannon todennus epäonnistuu. Hallintakonsoliin ei saada yhteyttä. Tietokannan failover on jumissa.”

Päivystävä pilvi-insinööri näkee ongelman, mutta ei voi korjata sitä. Hänen normaali etuoikeutettu roolinsa riippuu samasta identiteetintarjoajasta, jonka toiminta on nyt häiriintynyt. Operatiivinen vastuuhenkilö pyytää hätätilanteen ylläpitäjätunnusta. Vaatimustenmukaisuuspäällikkö kysyy, onko break-glass-tiliä koskaan testattu. Tietosuojavastaava kysyy, voiko pääsy tuotantotietokantaan paljastaa henkilötietoja. Tietoturvajohtaja esittää kysymyksen, joka ratkaisee, onko edessä hallittu palautuminen vai auditointipainajainen:

”Voimmeko osoittaa, kuka käytti hätätilanteen pääsyä, miksi, mitä hän teki ja että tili palautettiin käytön jälkeen?”

Toinen organisaatio voi kohdata saman ongelman hiljaisemmassa huoneessa. FinTech-yrityksen tietoturvajohtaja istuu ulkoisten auditoijien vastapäätä pilvitietokannan virheellisen konfiguraation jälkeen. Poikkeama korjattiin nopeasti, mutta juurisyy ei ollut rauhoittava. Kolmannen osapuolen kehittäjällä oli pysyvät ylläpitäjäoikeudet. Kun ensisijainen ylläpitäjä ei ollut käytettävissä, kehittäjä käytti break-glass-tiliä, joka perustui DevOps-tiimin saatavilla olevaan jaettuun salasanaan ”turvallisessa” muistiinpanossa.

Auditoijat eivät keskittyneet vain virheelliseen konfiguraatioon. He kysyivät, oliko pääsy aikarajoitettu, oliko vastuu yksilöllisesti kohdennettavissa, lokitettiinko komennot, suojattiinko henkilötiedot GDPR Article 32:n mukaisesti, täyttyivätkö DORA:n ICT-riskivelvoitteet ja olivatko NIS2:n kyberhygieniaa koskevat odotukset todennettavissa.

Tämä on etuoikeutetun pääsyn hallinnan ja break-glass-tilien todellinen painepiste vuonna 2026. PAM ei ole enää kapea identiteettiturvallisuuden hanke. Se on kohta, jossa kiristyshaittaohjelmat, pilviympäristön vaarantuminen, toimittajariski, tietosuoja, toiminnan häiriönsietokyky ja auditointinäyttö kohtaavat.

Etuoikeutettu pääsy on kohta, jossa hyökkääjät pyrkivät voittamaan. Break-glass-pääsy on kohta, jossa puolustajat pyrkivät palautumaan. Molemmat perustuvat samaan vaaralliseen kyvykkyyteen: korotettuun käyttöoikeuteen, jolla voidaan ohittaa kontrollit, muuttaa konfiguraatioita, lukea arkaluonteisia tietoja, kierrättää avaimia, poistaa lokitus käytöstä, palauttaa varmuuskopioita, ottaa koodia käyttöön tai tuhota todentavaa aineistoa.

Clarysecin käytännön näkemys on yksinkertainen: hätätilanteen pääsy on välttämätön, mutta hallitsematon hätätilanteen pääsy on hallitsematon riski. Oikea vastaus ei ole ”ei break-glass-tilejä”. Oikea vastaus on hallittu etuoikeutetun pääsyn toimintamalli, jossa on inventaario, hyväksyntä, aikarajat, vahva tunnistautuminen, istuntojen lokitus, käytön jälkeinen katselmointi, tunnistetietojen palautus ja auditointinäyttö.

Miksi etuoikeutettu pääsy on hallitustason vaatimustenmukaisuuskysymys

Matalamman kypsyystason ympäristöissä etuoikeutettua pääsyä käsitellään usein IT-ylläpitotehtävänä. Joku tarvitsee ylläpitäjäoikeudet, tiketti avataan, rooli myönnetään ja liiketoiminta jatkuu. Tällainen malli ei kestä nykyaikaisia kiristyshaittaohjelmia, pilvinatiivia infrastruktuuria, NIS2:n osoitusvelvollisuutta, DORA:n operatiivista häiriönsietokykyä tai GDPR-loukkausten tarkastelua.

NIS2-direktiivi tuo kyberturvallisuuden hallinnon johdon pöydälle. Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat niiden toteutusta ja osallistuvat kyberturvallisuuskoulutukseen. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, kontrollien tehokkuus, kyberhygienia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta sekä MFA tai jatkuva todennus silloin, kun se on tarkoituksenmukaista.

SaaS-palveluntarjoajille, hallinnoiduille palveluntarjoajille, hallinnoiduille tietoturvapalveluntarjoajille, pilvipalveluille, datakeskuksille ja muille digitaalisen infrastruktuurin organisaatioille NIS2:n soveltuminen riippuu toimialasta, koosta, roolista, rajat ylittävästä vaikutuksesta ja sijoittumisesta EU:hun. Operatiivinen opetus on suora: pääsynhallinta ei enää ole tekniseen liitteeseen piilotettu asia. Se on osa kyberhygienian perustasoa, joka johdon on hyväksyttävä, jota sen on seurattava ja jonka puutteet sen on korjattava.

Rahoitusalan toimijoille Digital Operational Resilience Act muuttaa kieltä, mutta ei taustalla olevaa riskiä. DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se luo yhdenmukaisen viitekehyksen ICT-riskienhallinnalle, merkittävien ICT:hen liittyvien poikkeamien raportoinnille, digitaalisen operatiivisen häiriönsietokyvyn testaukselle ja ICT-kolmansien osapuolten riskienhallinnalle. Article 5 edellyttää ICT-riskejä koskevia hallinto- ja kontrollijärjestelyjä, joissa johtoelin määrittelee, hyväksyy ja valvoo ICT-riskijärjestelyjä sekä vastaa niistä. Article 6 edellyttää dokumentoitua ICT-riskienhallinnan viitekehystä, jossa on politiikat, menettelyt, protokollat ja työkalut ICT-omaisuuserien suojaamiseksi. Article 17 edellyttää ICT:hen liittyvien poikkeamien hallintaprosessia, joka havaitsee, kirjaa, luokittelee, eskaloi ja palauttaa turvallisen toiminnan.

GDPR lisää tietosuojan ja osoitusvelvollisuuden näkökulman. Article 5(1)(f) edellyttää, että henkilötietoja käsitellään eheästi ja luottamuksellisesti. Article 5(2) edellyttää osoitusvelvollisuutta. Article 25 edellyttää sisäänrakennettua ja oletusarvoista tietosuojaa. Article 32 edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä käsittelyn turvallisuuden varmistamiseksi. Jos etuoikeutettu käyttäjä voi viedä asiakastietueita, käyttää erityisiin henkilötietoryhmiin kuuluvia tietoja, poistaa tarkastuslokit käytöstä tai muuttaa säilytysasetuksia ilman katselmointia, organisaatio ei ole tehnyt pelkästään IAM-virhettä. Se ei välttämättä pysty osoittamaan asianmukaista turvallisuutta.

ISO/IEC 27001:2022 on hallintajärjestelmän perusta, jonka avulla nämä velvoitteet voidaan käsitellä yhdessä integroidussa ohjelmassa. Clause 4.2 edellyttää, että organisaatio ymmärtää sidosryhmät ja niiden vaatimukset, mukaan lukien lakisääteiset, sääntelyyn perustuvat ja sopimusvelvoitteet. Clause 5.1 edellyttää johtajuutta ja sitoutumista. Clause 6.1.2 edellyttää tietoturvariskien arviointia. Clause 6.1.3 edellyttää riskien käsittelyä. Clause 8 edellyttää operatiivista suunnittelua ja ohjausta.

Etuoikeutetun pääsyn osalta tämä siirtää keskustelun kysymyksestä ”minkä PAM-työkalun ostamme?” kysymykseen ”mitä riskejä käsittelemme, mitkä kontrollit valitaan, kuka omistaa ne, miten niitä käytetään ja mikä näyttö osoittaa, että ne toimivat?”

PAM ei ole yksittäinen kontrolli vaan näyttöketju

PAM-työkalu voi säilyttää salasanoja holvissa, välittää istuntoja, tallentaa näppäilyjä, kierrättää tunnistetietoja ja toteuttaa just-in-time-pääsyn. Nämä kyvykkyydet ovat tärkeitä. Jos organisaatio ei kuitenkaan ole määritellyt etuoikeutettuja rooleja, hyväksynyt hätätilanteen pääsyä, kartoittanut pääsyä omaisuuseriin, katselmoinut käyttöoikeuksia, suojannut lokitietoja ja kouluttanut ylläpitäjiä, työkalusta tulee osittainen kontrolli, jonka auditointipuolustus on heikko.

Hyödyllisin tapa hallita etuoikeutettua pääsyä on ajatella kontrollituloksia, ei työkalujen nimiä.

Zenith Controls: The Cross-Compliance Guide Zenith Controls käsittelee ISO/IEC 27002:2022 -kontrollia 8.2, Privileged access rights, PAMin painopisteenä. Se luokittelee tämän kontrollin ennaltaehkäiseväksi, luottamuksellisuutta, eheyttä ja saatavuutta tukevaksi kontrolliksi, joka on linjassa kyberturvallisuuskonseptin Protect, operatiivisen kyvykkyyden Identity and access management ja turvallisuusalueen Protection kanssa.

Kontrolli 8.2 on vahva, koska se kytkeytyy ympäröiviin kontrolleihin, jotka tekevät etuoikeutetusta pääsystä auditoitavan:

Siksi auditoija harvoin pysähtyy kysymykseen: ”Onko teillä PAM-järjestelmä?” Vahvemmat auditointikysymykset ovat: Onko teillä etuoikeutettujen tilien inventaario? Onko etuoikeutetut roolit hyväksytty? Ovatko oikeudet aikarajoitettuja? Onko hätätilanteen tunnistetiedot suojattu? Voitteko osoittaa, kuka käytti niitä? Lokitetaanko komennot? Sisältyvätkö toimittajien ylläpitäjät? Katselmoidaanko käyttöoikeudet? Palautettiinko tunnistetiedot? Hyväksyttiinkö poikkeukset riskiperusteisesti?

Zenith Controls -materiaalin käyttöoikeuksien kartoitus ilmaisee asian suoraan: käyttöoikeuksien hallinta toteuttaa pääsynhallinnan periaatteita, kuten vähimmän oikeuden periaatetta, tarpeellisuusperiaatetta ja valtuutusta, kun taas etuoikeutetut tilit edellyttävät erityistä tarkastelua ja nopeaa perumista, kun niitä ei enää tarvita.

Politiikkavaatimukset luotettavalle break-glass-pääsylle

Break-glass-tili ei ole jaettu ylläpitäjäsalasana sinetöidyssä kirjekuoressa. Vuonna 2026 tämä malli on liian heikko pilvelle, fintechille, SaaS-palveluille, terveydenhuollolle, hallinnoiduille palveluille ja säännellyille digitaalisille toiminnoille.

Puolustettava break-glass-malli tarvitsee seitsemän vähimmäispolitiikkasääntöä:

1. Tili on dokumentoitava.
2. Tili on hyväksyttävä.
3. Käytön on oltava yksilöllisesti kohdennettavissa aina, kun se on teknisesti mahdollista.
4. Käyttö on rajattava todellisiin hätätilanteisiin.
5. Käyttö on lokitettava ja katselmoitava.
6. Tunnistetiedot tai todennustekijät on palautettava tai kierrätettävä käytön jälkeen.
7. Tili on testattava ja sisällytettävä auditoinnin soveltamisalaan.

Clarysecin politiikkakirjasto muuttaa nämä periaatteet käyttökelpoiseksi hallintakieleksi.

User Account and Privilege Management Policy-sme Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - SME toteaa:

”Hätätilanteen pääsy (esim. break-glass-ylläpitäjätilit) on dokumentoitava selkeästi, suojattava ja sitä saa käyttää vain ehdottoman välttämättömissä tilanteissa.”

Kohdasta ”Riskien käsittely ja poikkeukset”, politiikan kohta 7.3.1.

Sama pk-yrityksille tarkoitettu politiikka jatkaa:

”Tällaiset tilit on lokitettava, katselmoitava käytön jälkeen ja palautettava jokaisen hätätilannetapahtuman jälkeen.”

Kohdasta ”Riskien käsittely ja poikkeukset”, politiikan kohta 7.3.2.

Päivittäistä käyttöoikeuksien korotusta varten pk-yrityksille tarkoitettu politiikka edellyttää myös:

”Korotetut tai ylläpidolliset käyttöoikeudet edellyttävät toimitusjohtajan tai IT-vastaavan lisähyväksyntää, ja ne on dokumentoitava, aikarajoitettava ja katselmoitava säännöllisesti.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan kohta 6.2.2.

Suuremmissa organisaatioissa yritystason politiikkakokonaisuus menee pidemmälle. User Account and Privilege Management Policy Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka edellyttää, että:

”Etuoikeutetut istunnot on lokitettava kattavasti, mukaan lukien annetut komennot ja suoritetut toimet. Nimettyjen katselmoijien on katselmoitava lokit säännöllisesti.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan kohta 6.4.2.

Sama politiikka edellyttää, että tilapäiset tai hätätilanteessa käytettävät etuoikeutetut tilit noudattavat dokumentoitua break-glass-menettelyä kohdan 6.2.5 mukaisesti, ja kohta 7.4 määrittää kyseisen menettelyn vaatimukset.

Access Control Policy Pääsynhallintapolitiikka vahvistaa auditointia varten tehtävää säilyttämistä:

”Hyväksyntäpäätökset on kirjattava lokiin ja säilytettävä auditointitarkoituksia varten vähintään 2 vuoden ajan.”

Kohdasta ”Hallintavaatimukset”, politiikan kohta 5.3.2.

Logging and Monitoring Policy-sme Lokitus- ja valvontapolitiikka - SME määrittää todennuslokitusta koskevat odotukset:

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

Kohdasta ”Hallintavaatimukset”, politiikan kohta 5.4.2.

Yhdessä nämä kohdat muuttavat hätätilanteen pääsyn sankarillisesta kiertotiestä hallituksi tapahtumaksi. Tili on poikkeuksellinen, mutta hallinta ei ole.

Zenith Blueprint -lähestymistapa PAMin toteuttamiseen

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint käsittelee etuoikeutettua pääsyä käytännön toteutusongelmana, ei teoreettisena kontrollilauseena. Controls in Action -vaiheen Step 19, Technological Controls I, toteaa:

”Missä tahansa tietojärjestelmässä etuoikeutettu pääsy on valtaa, ja vallan mukana tulee riski.”

Controls in Action -vaiheesta, Step 19: Technological Controls I.

Step 19 edellyttää, että organisaatiot tunnistavat etuoikeutetut tilit omissa tiloissa toimivissa, pilvi-, SaaS-, kehitys- ja infrastruktuuriympäristöissä. Näihin kuuluvat toimialueen ylläpitäjät, root-käyttäjät, pilvivuokraajan ylläpitäjät, tietokannan superkäyttäjät ja CI/CD-putkien ohjaajat. Se korostaa myös etuoikeutetun pääsyn minimointia roolipohjaisen käyttöoikeuksien hallinnan, just-in-time-korotuksen ja hyväksyntätyönkulkujen avulla.

Tällä on merkitystä, koska monet vakavat poikkeamat eivät ala virallisesta break-glass-tilistä. Ne alkavat pysyvästä etuoikeudesta. Pilvi-insinöörillä säilyy omistajaoikeus ”varmuuden vuoksi”. Tietokannan ylläpitäjällä säilyy tuotantoympäristön käyttöoikeus tiimin vaihdon jälkeen. CI/CD-palvelutilillä on laajat käyttöoikeudet eri ympäristöihin. Hallinnoidun palveluntarjoajan tili on vapautettu MFA:sta, koska ”he tarvitsevat nopean pääsyn”.

Zenith Blueprintin Step 20 laajentaa saman ajattelun etuoikeutettuihin apuohjelmiin. Se ohjeistaa organisaatioita luomaan tai päivittämään etuoikeutettujen apuohjelmien inventaarion, rajoittamaan suorituksen valtuutetuille ylläpitäjille, varmistamaan, että käyttö lokitetaan ja siitä syntyy hälytyksiä, sekä harkitsemaan skriptilokitusta, kuten PowerShell-lokitusta ryhmäkäytännön kautta. Tämä on kriittistä, koska etuoikeutettu tili on usein vain sisäänpääsykohta. Vahinko syntyy, kun hyökkääjä käyttää työkaluja, jotka poistavat kontrolleja käytöstä, kaappaavat tunnistetietoja tai liikkuvat lateraalisesti.

Step 22 virallistaa pääsynhallinnan elinkaaren. Se edellyttää jäsenneltyä käyttöoikeuksien myöntämistä ja käyttöoikeuksien poistamista, mieluiten HR-integraatiolla ja käyttöoikeuspyyntöjen työnkuluilla tuettuna, sekä neljännesvuosittaisia dokumentoituja käyttöoikeuskatselmointeja. Step 16 kytkee elinkaaren palvelussuhteen päättämiseen edellyttämällä työntekijän työsuhteen päättämisen tarkistuslistaa, jota HR ja IT käyttävät yhdessä ja johon sisältyvät tilien poistaminen käytöstä, omaisuuden palautus ja NDA-muistutukset.

Zenith Blueprint tekee PAMista kytkeytyneen toimintamallin: identiteetti, HR, etuoikeutetut apuohjelmat, lokitus, tietoturvapoikkeamiin reagointi, käyttöoikeuskatselmoinnit ja auditointinäyttö vahvistavat toisiaan.

Käytännön break-glass-hallintamalli vuodelle 2026

Hyvin suunnitellun break-glass-prosessin on toimittava häiriön aikana. Jos se riippuu samasta identiteetintarjoajasta, tikettijärjestelmästä ja chat-palvelusta, jotka eivät ole käytettävissä katkoksen aikana, kyse on näennäiskontrollista.

Samaan aikaan hätätilanteen pääsy ei saa muuttua mukavuussyistä käytettäväksi ohituskanavaksi. Clarysec suunnittelee break-glass-hallinnan tyypillisesti neljän kerroksen ympärille: ennaltaehkäisy, aktivointi, havainnointi ja palautuminen.

Pilviympäristöissä mukaan on sisällytettävä vuokraajatasoiset ylläpitäjät, pilven root-tilit, hätätilanteen identiteetintarjoajan ylläpitäjät, etuoikeutetut palvelutilit, tietokannan master-käyttäjät, Kubernetesin cluster-admin-roolit, CI/CD-käyttöönottoavaimet, salaisuusholvien ylläpitäjät ja kolmannen osapuolen tukitilit.

Hybridiympäristöissä mukaan on sisällytettävä toimialueen ylläpitäjät, varmuuskopioinnin ylläpitäjät, hypervisor-ylläpitäjät, palomuurien ylläpitäjät, EDR-konsolin ylläpitäjät ja etuoikeutettujen apuohjelmien käyttäjät.

Tietosuojaherkkien ympäristöjen osalta mukaan on sisällytettävä ylläpitäjät, joilla on pääsy henkilötietoja sisältäviin tietokantoihin, tunnisteita sisältäviin lokitietoihin, HR-tallenteisiin, biometrisen identiteetin varmennustietoihin, petosten valvontajärjestelmiin tai asiakastuen työkaluihin.

Tavoitetila on helppo kuvata ja vaikea teeskennellä: jokainen hätätilanteen reitti on tunnettu, hyväksytty, suojattu, havaittavissa, palautettavissa ja katselmoitu.

60 minuutin break-glass-näyttöharjoitus

Tietoturvajohtaja tai vaatimustenmukaisuuspäällikkö voi toteuttaa hyödyllisen break-glass-harjoituksen jo tällä viikolla ilman uuden työkalun hankintaa. Tavoitteena ei ole vain vahvistaa, että tili toimii. Tavoitteena on osoittaa, että kontrolli tuottaa näyttöä.

Skenaario

Oletetaan, että ensisijainen identiteetintarjoaja toimii häiriötilassa. Normaali just-in-time-korotus ei ole käytettävissä. Tuotantotietokantaklusteri tarvitsee hätätilanteen konfiguraatiomuutoksia palvelun palauttamiseksi. Break-glass-pilviylläpitäjätili on aktivoitava.

Vaihe 1: Varmista, että tili on etuoikeutettujen tilien inventaariossa

Käytä Zenith Blueprintia, Controls in Action -vaiheen Step 19:ää, vahvistaaksesi, että tili näkyy etuoikeutettujen tilien inventaariossa. Kirjaa tilin nimi ja ympäristö, liiketoimintavastaava, tekninen omistaja, saavutettavissa olevat järjestelmät, henkilötietovaikutus, todennusmenetelmä, holvin sijainti, kiertomenetelmä ja viimeisin testauspäivä.

Jos tili puuttuu, käsittele se kontrollipuutteena ja lisää se riskirekisteriin.

Vaihe 2: Tarkista politiikanmukaisuus

Kartoita tapahtuma User Account and Privilege Management Policy -politiikan vaatimuksiin dokumentoiduista break-glass-menettelyistä ja etuoikeutettujen istuntojen lokituksesta. Jos olet pk-yritys, käytä User Account and Privilege Management Policy-sme -politiikan kohtia 7.3.1 ja 7.3.2 vähimmäistasona: dokumentoitu, suojattu, välttämätön, lokitettu, katselmoitu ja palautettu.

Kartoita hyväksyntöjen säilytys Access Control Policy -politiikan kohtaan 5.3.2, joka edellyttää hyväksyntäpäätösten lokittamista ja säilyttämistä vähintään 2 vuoden ajan.

Vaihe 3: Avaa hätätilanteen pääsytallenne

Luo tiketti tai poikkeamatallenne ennen aktivointia tai aktivoinnin yhteydessä. Sisällytä:

• Hätätilanteen syy
• Vaikutuksen kohteena oleva palvelu
• Pyydetty tili
• Pyytäjä
• Hyväksyjä
• Aloitusaika
• Odotettu päättymisaika
• Asiakas- tai sääntelyvaikutus
• GDPR:n mukainen henkilötietovaikutus
• NIS2- tai DORA-raportoinnin seurantamerkintä

Älä odota loppuun asti tarinan rekonstruoimiseksi. Auditointiarvo on vahvin, kun tallenne alkaa ennen kuin pääsyä käytetään.

Vaihe 4: Aktivoi ja havainnoi

Aktivoi break-glass-tili. Varmista, että MFA:ta tai korvaavaa todennusta käytetään, istunto tallennetaan, komennot tai ylläpidolliset toimet lokitetaan, lokit toimitetaan keskitettyyn lokitukseen, aikasynkronointi tukee aikajanan rekonstruointia ja hätätilanteen tilin käytöstä syntyy hälytys.

Tämä vastaa Zenith Controls -materiaalin 8.15 Logging -kontrollia, jossa lokitus kuvataan seurannan perustietokerrokseksi ja todetaan, että etuoikeutetut käyttäjät ja etuoikeutettujen apuohjelmien suorittaminen on lokitettava kattavasti.

Vaihe 5: Sulje, palauta ja katselmoi

Hätätilannetehtävän jälkeen poista tili käytöstä tai palauta se sinetöityyn tilaan, kierrätä tunnistetiedot tai palauta todennustekijä, katselmoi istuntolokit, dokumentoi komennot ja konfiguraatiomuutokset, vahvista ettei tarpeetonta tietojen käyttöä tapahtunut, päivitä poikkeamatallenne, kirjaa opit ja päätä, ylittyvätkö NIS2-, DORA- tai GDPR-ilmoituskynnykset.

Jos henkilötietoja käytettiin, osallista tietosuojavastaava. Jos tapahtuma aiheutti palvelukatkoksen tai voi aiheuttaa olennaisen vaikutuksen, osallista NIS2- tai DORA-raportoinnin omistaja. Jos break-glass-tili epäonnistui, dokumentoi se operatiivisen häiriönsietokyvyn havaintona, ei pelkkänä IAM-ongelmana.

PAM- ja break-glass-kontrollien poikkivaatimustenmukaisuuden kartoitus

Vahvin hallintamalli ei kopioi kontrolleja jokaiselle säädökselle. Se rakentaa yhden näyttöketjun, joka tukee useita velvoitteita.

NIST CSF 2.0 on erityisen hyödyllinen, kun PAM muunnetaan nykyprofiiliksi ja tavoiteprofiiliksi. Sen profiilimenetelmä alkaa soveltamisalasta ja kokoaa sen jälkeen politiikat, riskiprioriteetit, rekisterit, vaatimukset, käytännöt ja työroolit ennen priorisoidun toimintasuunnitelman laatimista. Etuoikeutetun pääsyn osalta tämä tarkoittaa profiilin rajaamista identiteettiturvallisuuteen, pilviylläpitoon, kiristyshaittaohjelmien sietokykyyn, kriittisiin rahoitusjärjestelmiin tai toimittajien pääsyyn.

DORA:n piiriin kuuluville rahoitusalan toimijoille DORA toimii toimialakohtaisena EU:n kyberhäiriönsietokyvyn järjestelmänä vastaaville NIS2-riskien ja poikkeamien velvoitteille. Tämä ei tee NIS2:sta merkityksetöntä. Se tarkoittaa, että rahoitusalan toimijan tulee käyttää DORA:a ICT-riski- ja poikkeamavaatimusten ensisijaisena järjestelmänä ja samalla ylläpitää koordinaatiota kansallisten kyberturvallisuusstrategioiden, toimivaltaisten viranomaisten ja soveltuvin osin CSIRT-toimijoiden kanssa.

Miten auditoijat testaavat etuoikeutetun pääsyn näyttöä

Auditoijat eivät arvioi PAMia vain lukemalla politiikkaa. He vertaavat politiikkaa, konfiguraatiota, lokeja, tikettejä, haastatteluja ja havaittua käytäntöä.

Zenith Controls -materiaalin etuoikeutettujen käyttöoikeuksien auditointimenetelmä viittaa ISO/IEC 19011:2018 -auditointikäytäntöihin. Auditoijat katselmoivat politiikat, jotka määrittävät korotetut oikeudet, käyttöoikeuksien myöntämisen, seurannan ja peruuttamismenettelyt. He tarkastavat käyttäjätilien inventaarioita, käyttöoikeuksien määritystallenteita ja lokeja. He vahvistavat näyttöä haastattelujen, PAM-työkalujen, hakemistopalvelujen ja lokinäytteiden avulla.

Käyttöoikeuksien osalta Zenith Controls toteaa, että auditoijat otostavat käyttäjien käyttöoikeuspyyntöjä, varmistavat dokumentoidut hyväksynnät ja vahvistavat, että IT myönsi vain hyväksytyn pääsyn. He myös vertaavat käyttäjärooleja todellisiin oikeuksiin ja tarkistavat, sovelletaanko vähimmän oikeuden periaatetta. Lokituksen osalta auditoijat tarkastavat lokituksen soveltamisalan, tapahtumatyypit, säilytysajat, suojaukset ja todelliset lokimerkinnät. He arvioivat, tallennetaanko ja katselmoidaanko epäonnistuneet kirjautumiset, arkaluonteisten tietojen käyttö ja konfiguraatiomuutokset.

Hyvä break-glass-näyttöpaketti sisältää:

• Hyväksytty hätätilanteen pääsypyyntö
• Poikkeaman tai katkoksen konteksti
• Pääsyn aktivoineen käyttäjän identiteetti
• Hyväksyjän identiteetti
• Aloitus- ja päättymisaika
• MFA- tai todennusnäyttö
• Istunnon tallennus tai komentoloki
• Järjestelmälokit ja SIEM-hälytys
• Tehdyt muutokset
• Vahvistus tunnistetietojen palautuksesta
• Käytön jälkeinen katselmointi
• Tietojen käytön arviointi
• Sääntelyilmoituksen arviointi
• Korjaavat toimenpiteet, jos jokin epäonnistui

Jos harjoituksesi ei pysty tuottamaan tätä pakettia, kontrolli ei ole auditointivalmis.

Piilevä epäonnistuminen: kolmansien osapuolten etuoikeutettu pääsy

Monet organisaatiot hallitsevat työntekijäylläpitäjiä paremmin kuin toimittajien ylläpitäjiä. Pilvi-, SaaS-, fintech- ja hallinnoitujen palvelujen ympäristöissä tämän pitäisi olla toisin päin.

NIS2 Article 21 sisältää toimitusketjun turvallisuuden sekä suhteet suoriin toimittajiin ja palveluntarjoajiin. DORA Articles 28–30 menevät rahoitusalan toimijoiden osalta pidemmälle ja edellyttävät ICT-kolmansien osapuolten riskistrategiaa, ICT-palvelusopimusten rekistereitä, due diligence -arviointia, keskittymäriskin arviointia, auditointioikeuksia, irtisanomisoikeuksia, exit-strategioita ja sopimukseen perustuvia turvallisuustoimenpiteitä.

Toimittajien etuoikeutetun pääsyn tulee kuulua PAMin soveltamisalaan, jos toimittaja voi ylläpitää tuotantoa, tukea kriittisiä tai tärkeitä toimintoja, käyttää henkilötietoja, muuttaa tietoturvakonfiguraatioita, hallita varmuuskopioita, ottaa koodia käyttöön tai operoida valvontatyökaluja.

Clarysec odottaa tyypillisesti, että toimittajien etuoikeutetun pääsyn kontrollit sisältävät:

• Nimetyt toimittajakäyttäjät, ei jaettuja toimittajatilejä
• Sopimusperusteiset tietoturvavaatimukset etuoikeutetulle pääsylle
• MFA ja turvallinen etäkäyttö
• Aikarajoitetut käyttöikkunat
• Asiakkaan hyväksyntä hätätilanteen pääsylle
• Istuntolokitus tai vastaavat auditointijäljet
• Välitön peruminen henkilöstömuutosten yhteydessä
• Poikkeamayhteistyötä koskevat velvoitteet
• Näytön säilytys asiakkaan auditointitarpeiden mukaisesti
• Exit-suunnitelma toimittajan pääsyn poistamiseksi

NIST CSF 2.0:n toimitusketjutulokset sopivat tähän vahvasti. Ne edellyttävät toimittajien rooleja ja vastuita, toimittajien priorisointia kriittisyyden perusteella, sopimusvaatimuksia, due diligence -arviointia, jatkuvaa seurantaa, toimittajien osallistamista poikkeamasuunnitteluun ja sopimuksen jälkeisiä riskisuunnitelmia.

Jos hallinnoidun palveluntarjoajan tili on vapautettu sisäisestä PAM-työnkulusta, kyse ei ole mukavuudesta. Se on korkean riskin poikkeus, joka kuuluu riskirekisteriin, toimittajarekisteriin ja käyttöoikeuskatselmointiin.

Yleiset PAM- ja break-glass-havainnot vuonna 2026

Clarysecin toimeksiannoissa havainnot ovat harvoin yllättäviä. Ne ovat yleensä yhdistelmiä hyvistä aikomuksista, operatiivisesta paineesta ja puutteellisesta näytöstä.

Yleisimmät havainnot ovat:

• Break-glass-tilejä on olemassa, mutta niitä ei ole listattu etuoikeutettujen tilien inventaarioon.
• Hätätilanteen tilit on jätetty normaalien käyttöoikeuskatselmointien ulkopuolelle.
• Organisaatio ei pysty osoittamaan, kuka käytti hätätilanteen tiliä.
• Tiliä ei palautettu käytön jälkeen.
• Etuoikeutetut istunnot lokitetaan, mutta komentoja ei.
• Lokit ovat paikallisesti olemassa, mutta niitä ei ole suojattu etuoikeutetuilta käyttäjiltä.
• Pilven root-tilejä ei testata.
• MFA-palautusprosessit ovat dokumentoimattomia.
• CI/CD-putkien ja palvelutilien etuoikeutettu pääsy sivuutetaan.
• Kolmannen osapuolen tukipääsy ohittaa sisäisen hyväksynnän.
• Pääsyn hyväksyntä on chat-viesteissä, mutta sitä ei säilytetä auditointinäyttönä.
• Palvelussuhteen päättäminen poistaa sähköpostin ja VPN:n, mutta ei SaaS-ylläpitäjäoikeuksia.
• Tietosuojavastaavaa ei osallisteta, kun etuoikeutettu pääsy voi paljastaa henkilötietoja.
• Poikkeamien pelikirjat eivät sisällä NIS2-, DORA- tai GDPR-ilmoituspäätöspisteitä.

Jokainen havainto voidaan käsitellä ISO/IEC 27001:2022 -standardin mukaisella riskien käsittelyllä. Tunnista riski, nimeä omistaja, valitse kontrollit, päivitä soveltuvuuslausunto, toteuta riskienkäsittelysuunnitelma ja säilytä dokumentoitu näyttö. Tässä on ISMS:n voima hajanaisten tietoturvatehtävien sijaan.

Miltä hyvä näyttää

Kypsässä PAM- ja break-glass-toimintamallissa on viisi toistuvaa rutiinia.

Ensinnäkin etuoikeutettu pääsy inventoidaan kuukausittain tai jatkuvasti. Mukaan sisällytetään ihmisylläpitäjät, palvelutilit, hätätilanteen tilit, pilviroolit, CI/CD-identiteetit, tietokantakäyttäjät, etuoikeutetut apuohjelmat ja kolmansien osapuolten ylläpitäjät.

Toiseksi vähimmän oikeuden periaatetta sovelletaan roolien, just-in-time-korotuksen ja hyväksyntöjen avulla. Pysyvien etuoikeuksien tulee olla harvinaisia, perusteltuja ja niitä tulee katselmoida useammin kuin tavanomaisia käyttäjäoikeuksia.

Kolmanneksi etuoikeutettua käyttäytymistä seurataan. Lokita todennus, istunnon kesto, MFA:n käyttö, komennot, konfiguraatiomuutokset, tietojen viennit, epäonnistuneet yritykset, käyttöoikeuksien korotus ja etuoikeutettujen apuohjelmien suorittaminen.

Neljänneksi break-glass-tilit testataan ennen hätätilannetta. Break-glass-tili, jota ei ole koskaan testattu, on oletus, ei kontrolli.

Viidenneksi raportoidaan johdolle. Sekä NIS2 että DORA nostavat kyberturvallisuuden ja ICT-riskin johtoelimen vastuulle. Hallitus ei tarvitse jokaista komentolokia, mutta se tarvitsee mittarit: etuoikeutettujen tilien määrä, myöhässä olevat katselmoinnit, hätätilanneaktivoinnit, toimittajien ylläpitäjätilit, epäonnistuneet testit, kriittiset poikkeukset ja korjaavien toimenpiteiden tila.

Tässä Clarysecin työkalupakista tulee käytännöllinen. Politiikkakirjasto antaa hallintakielen. Zenith Blueprint antaa toteutusjärjestyksen. Zenith Controls antaa poikkivaatimustenmukaisuuden kartoituksen, kontrollisuhteet, tukevat standardit ja auditointimenetelmän.

Seuraavat vaiheet: muuta hätätilanteen pääsy auditointivalmiiksi häiriönsietokyvyksi

Jos organisaatiosi ei ole testannut break-glass-pääsyä viimeisten 90 päivän aikana, aloita siitä. Älä aloita työkalun valintatyöpajalla. Aloita näytöstä.

1. Luo tai päivitä etuoikeutettujen tilien inventaario.
2. Tunnista jokainen break-glass-tili ja hätätilanteen ylläpitopolku.
3. Kartoita jokainen tili liiketoimintavastaavaan, järjestelmäomistajaan ja tietovaikutukseen.
4. Vahvista politiikkakattavuus käyttämällä Clarysecin User Account and Privilege Management Policy Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka -politiikkaa tai User Account and Privilege Management Policy-sme Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - SME -politiikkaa.
5. Käytä Zenith Blueprintia Zenith Blueprint, Controls in Action -vaiheen Steps 19, 20, 22 ja 16, yhdistääksesi etuoikeutetun pääsyn, etuoikeutetut apuohjelmat, elinkaarikatselmoinnit ja palvelussuhteen päättämisen.
6. Käytä Zenith Controlsia Zenith Controls kartoittaaksesi ISO/IEC 27002:2022 -kontrollit 8.2, 5.18 ja 8.15 NIS2-, DORA-, GDPR- ja NIST-näyttöodotuksiin.
7. Suorita break-glass-näyttöharjoitus ja kirjaa tulokset.
8. Lisää puutteet riskienkäsittelysuunnitelmaan ja seuraa korjaavia toimenpiteitä sulkemiseen asti.

Etuoikeutettu pääsy on valtaa. Break-glass-pääsy on hätätilanteen valtaa. Vuonna 2026 ne organisaatiot, jotka palautuvat hallitusti kiristyshaittaohjelmista, pilvikatkoksista ja identiteettihäiriöistä, pystyvät osoittamaan, että hätätilanteen pääsy oli hallittu ennen kriisiä, sen aikana ja sen jälkeen.

Clarysec voi auttaa rakentamaan tämän näytön politiikasta kontrollikartoitukseen ja auditointivalmiuden edellyttämään näyttöön. Aloita Zenith Blueprintista, yhdistä se User Account and Privilege Management Policy -politiikkaan ja Access Control Policy -politiikkaan ja käytä sen jälkeen Zenith Controlsia osoittaaksesi, miten PAM-ohjelmasi tukee ISO/IEC 27001:2022 -standardia, NIS2:ta, DORA:a, GDPR:ää, NIST CSF 2.0:aa ja COBIT 2019:ää.