NIST SP 800-63-4: salasanojen, MFA:n ja pääsyavainten auditointinäyttö

Maanantaina klo 08.10 fintech-yhtiön tietoturvajohtaja saa viestin, jota jokainen tietoturvasta vastaava pelkää: ”Taloushallinnon ylläpitoportaaliin kohdistuu epäilyttäviä kirjautumisia. MFA hyväksyttiin, mutta käyttäjä sanoo, ettei hyväksyntä ollut hänen tekemänsä.”

Klo 08.25 SOC tunnistaa kaavan. Hyökkääjä ei murtanut salausta, hyödyntänyt zero-day-haavoittuvuutta tai ohittanut palomuuria. Hän kalasteli salasanan, käynnisti push-ilmoituksena lähetettävän hyväksyntäpyynnön ja odotti käyttäjän väsyvän. Yksi hyväksyntä riitti. Tilillä oli korotetut käyttöoikeudet asiakkaiden laskutusvienteihin, auditointilokeihin ja kolmannen osapuolen selvitysjärjestelmän hallintanäkymään.

Klo 09.00 lakitiimi kysyy, onko kyseessä GDPR:n mukainen henkilötietojen tietoturvaloukkaus. Riskitiimi kysyy, laukaiseeko tapahtuma DORA-raportoinnin. Hallitus haluaa tietää, pitikö yhtiön ”MFA kaikkialla” -lausuma todella paikkansa. ISO 27001 -auditoija, jonka auditointi on jo sovittu seuraavalle kuukaudelle, pyytää nyt näyttöä turvallisesta todennuksesta, pääsynhallinnasta, lokituksesta ja korjaavista toimenpiteistä.

Siksi NIST SP 800-63-4:llä on merkitystä vuonna 2026.

Tietoturvajohtajille, vaatimustenmukaisuuspäälliköille ja liiketoimintavastaaville NIST SP 800-63-4 ei ole vain yksi identiteettiohje lisää. Siitä on tulossa käytännön viitekohta nykyaikaiselle salasanapolitiikalle, tietojenkalastelua kestävälle MFA:lle, pääsyavaimille, salasanattomalle todennukselle ja todentajien elinkaaren hallinnalle. Todellinen haaste ei ole ohjeistuksen lukeminen. Haaste on toteutuksen osoittaminen ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR-, NIST CSF 2.0-, COBIT 2019- ja sisäisen tarkastuksen odotuksia vasten.

Clarysecin kanta on yksinkertainen: identiteettikontrollit epäonnistuvat, kun niitä käsitellään asetuksina eikä hallintana. Salasanat, MFA, pääsyavaimet, palautusprosessit, istuntotunnisteet, etuoikeutetut käyttöoikeudet, palvelutilit ja todennuslokit on suunniteltava yhtenä näyttöä tuottavana kontrollijärjestelmänä.

Tätä näkökulmaa käytetään Zenith Blueprint: auditoijan 30 vaiheen tiekartassa, Clarysecin politiikkakirjastossa ja Zenith Controls: vaatimustenmukaisuuden ristiinkartoitusoppaassa. Zenith Controls ei luo uusia kontrolleja. Se kartoittaa ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -kontrolliodotukset muihin standardeihin, säädöksiin ja auditointinäkökulmiin, jotta organisaatiot voivat välttää pirstaleisen näytön ja päällekkäisen vaatimustenmukaisuustyön.

”MFA käytössä” ei ole auditointivastaus

Monet organisaatiot ovat viime vuosina uskoneet, että MFA:n käyttöönotto sulki identiteettiriskikeskustelun. Vuonna 2026 tämä oletus ei ole turvallinen.

Auditoijat ja valvovat viranomaiset esittävät nyt täsmällisempiä kysymyksiä:

• Onko MFA pakotettu kaikelle etuoikeutetulle käytölle, etäkäytölle ja korkean riskin pääsylle?
• Onko todennus tietojenkalastelua kestävää siellä, missä riski sitä edellyttää?
• Hallitaanko pääsyavaimia tai FIDO2-todentajia rekisteröinnin, palautuksen, peruuttamisen ja laitteen elinkaaren kautta?
• Seulotaanko salasanat vuotaneiden ja yleisten tunnistetietoluetteloiden perusteella?
• Käynnistyvätkö salasanavaihdot vaarantumisesta eivätkä mielivaltaisesta kalenterikierrosta?
• Voivatko käyttäjät liittää salasanoja salasanojen hallintatyökaluista?
• Kirjataanko todentajatapahtumat lokiin ja katselmoidaanko ne?
• Ovatko käyttäjätilin palautusprosessit yhtä vahvoja kuin kirjautumisprosessit?
• Hallitaanko API-salaisuuksia, OAuth-tokeneita, SSH-avaimia ja palvelutilien tunnistetietoja samalla kurinalaisuudella?

NIST SP 800-63-4 ohjaa organisaatioita kohti riskiperusteista digitaalisen identiteetin varmistamista, todentajan vahvuutta ja elinkaarinäyttöä. Salasanojen modernisoinnissa tämä tarkoittaa siirtymistä pois vanhentuneista käytännöistä, kuten pakotetuista määräaikaisista salasanavaihdoista silloin, kun vaarantumisesta ei ole merkkejä, samalla kun vahvistetaan pituutta, vuotaneiden salasanojen seulontaa, nopeusrajoitusta, turvallista säilytystä ja palautuskontrolleja. MFA:n ja pääsyavainten osalta se tarkoittaa keskittymistä todentajan varmuuteen, tietojenkalastelun kestävyyteen, turvalliseen rekisteröintiin, käyttäjätiliin sitomiseen, peruuttamiseen ja auditoitavuuteen.

Zenith Blueprint kuvaa tämän muutoksen kohdassa Kontrollit käytännössä, vaihe 19, teknologiset kontrollit I, turvallista todennusta käsiteltäessä:

Todennus on ensimmäinen ja kriittisin puolustuslinja uhkatoimijan ja järjestelmiesi, tietojesi ja palvelujesi välillä. Jos todennus on heikko, kaikki muu — salaus, seuranta ja segmentointi — voidaan ohittaa. Kontrolli 8.5 varmistaa, että todennusmekanismit ovat turvallisesti suunniteltuja, johdonmukaisesti sovellettuja ja tunnettuja hyökkäysmenetelmiä kestäviä.

Tämä lause on vuoden 2026 identiteettiauditoinnin ydin. Kysymys ei enää ole ”Onko teillä salasanat ja MFA?” Kysymys on ”Voitteko osoittaa, että todennusarkkitehtuurinne on riskiperusteinen, tunnettuja hyökkäysmenetelmiä kestävä, johdonmukaisesti toteutettu ja valvottu?”

Rakenna kontrollijärjestelmä identiteetin, todennustietojen ja turvallisen todennuksen ympärille

Hyödyllisin tapa muuntaa NIST SP 800-63-4 ISO/IEC 27001:2022 -näytöksi on käsitellä identiteettiä toisiinsa kytkeytyvänä kontrollijärjestelmänä.

Zenith Controlsin avulla Clarysec tunnistaa kolme keskeistä ISO/IEC 27002:2022 -kontrollialuetta NIST SP 800-63-4 -yhteensopivuudelle: 5.16 Identity management, 5.17 Authentication information ja 8.5 Secure authentication. ISO/IEC 27001:2022 liite A:ssa nämä ovat A.5.16, A.5.17 ja A.8.5.

Erottelu on olennainen. A.5.16 kysyy: ”Kenellä on identiteetti?” A.5.17 kysyy: ”Miten tämän identiteetin todentamiseen käytettävä näyttö suojataan?” A.8.5 kysyy: ”Miten todennus suoritetaan järjestelmissä turvallisesti?”

Kun organisaatiot epäonnistuvat auditoinneissa, syynä on usein se, että yksi kerros toteutetaan ilman muita. Pääsyavaimet otetaan käyttöön, mutta peruutusnäyttöä ei voida esittää. MFA pakotetaan, mutta ei vanhassa ylläpitokonsolissa. Salasanasäännöt asetetaan, mutta vuotaneita salasanoja ei seulota. Käyttäjätili poistetaan käytöstä, mutta aktiiviset istunnot tai palautustokenit unohtuvat.

Zenith Blueprintissä, kohdassa Kontrollit käytännössä, vaihe 22, organisatoriset kontrollit, Clarysec selittää A.5.17:n elinkaarikysymyksenä:

Jos identiteetti on kysymys ”Kuka olet?”, todennus on vastaus ja näyttö. Kontrolli 5.17 on kohta, jossa teoria muuttuu luottamukseksi. Se edellyttää, että todennustietoja hallitaan turvallisesti koko niiden elinkaaren ajan, jotta identiteetin varmentamiseen käytettävät menetelmät ja tunnistetiedot eivät itse muodostu heikoimmaksi lenkiksi.

Pääsyavain ei ole vaatimustenmukainen vain siksi, että se on olemassa. Se muuttuu perusteltavaksi, kun voidaan osoittaa, miten se rekisteröidään, sidotaan, suojataan, palautetaan, peruutetaan, kirjataan lokiin ja katselmoidaan.

Modernisoi salasanat menettämättä auditointijälkeä

Monilla yrityksillä on edelleen salasanapolitiikkoja, jotka on kirjoitettu erilaista uhkamallia varten. ”Kaksitoista merkkiä, erikoismerkkejä, vaihto 90 päivän välein” kuulostaa tutulta, mutta tuttuus ei ole sama asia kuin häiriönsietokyky.

NIST SP 800-63-4 vahvistaa nykyaikaisempaa lähestymistapaa: pidemmät salasanat ja salalauseet, seulonta vuotaneita tai yleisesti käytettyjä salasanoja vasten, nopeusrajoitus, turvallinen nollaus, ei mielivaltaisia määräaikaisia vaihtoja ilman epäilyä vaarantumisesta sekä käyttäjäystävälliset kontrollit, jotka tukevat salasanojen hallintatyökaluja. Tämä ei tarkoita, että jokaisen organisaation on kirjoitettava kaikki politiikat uudelleen yhdessä yössä. Se tarkoittaa, että salasanavaatimusten tulee olla riskiperusteisia, teknisesti toteutettuja ja sovitettuja ISO 27001 -näyttöön.

Clarysecin pk-yritysten politiikkakirjasto antaa pienemmille organisaatioille käytännöllisen perustason, jota voidaan parantaa kypsyystason kasvaessa. Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - SME toteaa:

Salasanojen tulee täyttää monimutkaisuusvaatimukset (esim. vähintään 12 merkkiä, kirjaimia ja numeroita sekä symboleja) ja ne tulee vaihtaa vähintään 90 päivän välein.

Tämä on pk-yrityksille hyödyllinen ja sovellettavissa oleva lähtötaso. Vuoden 2026 NIST SP 800-63-4 -modernisointihankkeessa tulisi kuitenkin tarkastella, onko kiinteä 90 päivän vanhenemisaika edelleen tarkoituksenmukainen kullekin järjestelmälle, erityisesti silloin, kun MFA, vuotaneiden salasanojen seulonta, vahva salasanan pituus ja vaarantumisen perusteella käynnistyvät nollaustyönkulut ovat käytössä. Käytännössä monet organisaatiot säilyttävät perustason siirtymävaiheen aikana ja lisäävät sen jälkeen salasanojen modernisointia koskevan lisäyksen, joka hyväksytään riskien käsittelyn ja soveltuvuuslausunnon kautta.

Yritysympäristöihin Clarysecin Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka tarjoaa hallintaan kytkeytyvän kohdan sen sijaan, että jokainen salasanasääntö kovakoodattaisiin:

Kaikilla käyttäjätileillä tulee soveltaa salasanojen monimutkaisuutta ja vanhenemista organisaation salasanapolitiikan mukaisesti.

Tämä muotoilu antaa tietoturvajohtajalle mahdollisuuden päivittää salasanapolitiikka NIST SP 800-63-4:n mukaiseksi ilman, että koko pääsynhallinnan viitekehys kirjoitetaan uudelleen.

Käytännöllisen salasanojen modernisoinnin näyttöpaketin tulisi sisältää:

• Nykyinen salasanapolitiikka ja hyväksytty modernisointilisäys.
• IdP-konfiguraatio, josta näkyvät vähimmäispituus, enimmäispituus ja sallitut merkit.
• Näyttö siitä, että salasanojen hallintatyökalut ovat sallittuja, mukaan lukien liittämistoiminto tarvittaessa.
• Vuotaneiden, heikkojen ja yleisten salasanojen seulontamääritykset.
• Nopeusrajoitus tai lukituskäytäntö verkossa tapahtuvia arvailuhyökkäyksiä varten.
• Salasanan nollaustyönkulku, joka edellyttää riittävää identiteetin varmentamista.
• Salasanatiivisteiden säilytysarkkitehtuuri sovelluksille, jotka säilyttävät tunnistetietoja.
• Poikkeusrekisteri vanhoille järjestelmille, jotka eivät tue moderneja asetuksia.
• Vaarantumisen perusteella käynnistyvä nollausmenettely ja sen yhteys tietoturvapoikkeamiin reagointiin.
• Käyttäjäviestinnän ja koulutuksen näyttö.

Tavoitteena ei ole voittaa väittelyä yksittäisestä salasanan pituudesta. Tavoitteena on osoittaa, että salasanatodennus on hallittua, mitattavaa ja integroitu ISMS:ään.

Siirrä MFA ja pääsyavaimet ”toisesta tekijästä” varmuuteen

Maanantaiaamun poikkeama alkoi MFA-väsymyksestä. Siksi auditoijat kysyvät yhä useammin, onko MFA tietojenkalastelua kestävä, ei vain sitä, onko se olemassa.

Perinteiset MFA-menetelmät, kuten SMS, sähköposti-OTP, TOTP-sovellukset ja push-ilmoitukset, voivat vähentää riskiä, mutta ne eivät ole samanarvoisia. Pääsyavaimet ja FIDO2/WebAuthn-todentajat tarjoavat vahvemman suojan tietojenkalastelua vastaan, koska todennus on sidottu oikeaan alkuperään ja käyttää julkisen avaimen kryptografiaa. Korkean riskin käyttäjille, etuoikeutetuille ylläpitäjille, taloushyväksyjille, tuotantoympäristön käyttöoikeudet omaaville kehittäjille ja etäkäyttöpoluille tietojenkalastelua kestävää MFA:ta tulisi käsitellä tavoitetilana, ellei dokumentoitua ja hyväksyttyä poikkeusta ole.

Clarysecin yritystason Turvallisen viestinnän ja monivaiheisen todennuksen (MFA) politiikka asettaa perustason:

Monivaiheinen todennus (MFA): Kaikki pääsy organisaation verkkoon ja tietojärjestelmiin, erityisesti etuoikeutettu käyttöoikeus tai etäkäyttö, edellyttää monivaiheista todennusta (MFA) (esim. salasana ja OTP-token tai biometrinen tekijä). Monivaiheisen todennuksen (MFA) ratkaisujen tulee olla alan parhaiden käytäntöjen mukaisia (esim. aikaperusteiset kertakäyttökoodit tai laitteistoavaimet), ja ne tulee määrittää suojaamaan luvattomalta pääsyltä.

Pk-yrityksille Pääsynhallintapolitiikka - SME toteaa:

Etuoikeutettujen tilien tulee käyttää monivaiheista todennusta (MFA), jos järjestelmä tukee sitä.

Ilmaus ”jos järjestelmä tukee sitä” antaa pk-yrityksille realistisen toteutuspolun, mutta luo samalla auditointivelvoitteen. Jos etuoikeutettu järjestelmä ei tue MFA:ta, organisaation tulisi dokumentoida korvaavat kontrollit, kuten verkkorajoitukset, etuoikeutetun pääsyn hallinta, hyppypalvelimet, lyhyemmät istunnot, valvonta, holvitus ja migraatiosuunnitelma.

Zenith Blueprint, Kontrollit käytännössä, vaihe 19, kuvaa kehityssuunnan suoraan:

Mahdollisuuksien mukaan pelkkään salasanaan perustuvaa todennusta tulisi välttää, erityisesti ylläpitotileillä, pilvikonsoleissa, etäkäyttötyökaluissa ja kaikissa internetiin avautuvissa järjestelmissä. MFA, jossa käytetään toista tekijää, kuten laitteistoavainta, mobiilisovellusta tai biometrista tunnistetta, on nyt perustaso eikä ylellisyys.

Pääsyavaimet sopivat tähän kokonaisuuteen luontevasti. Pääsyavainkäyttöönottoa ei tule esittää pelkkänä teknologiapäivityksenä. Se tulee dokumentoida riskien käsittelynä tietojenkalastelua, credential stuffing -hyökkäyksiä, MFA-väsymystä, salasanojen uudelleenkäyttöä ja käyttäjätilien haltuunottoa vastaan.

Auditoijien tarvitsema pääsyavainnäyttömalli

Pääsyavaimet voivat olla synkronoitavia, laitesidonnaisia, laitteistolla tuettuja, alustapohjaisia tai siirrettäviä todentajasta ja ekosysteemistä riippuen. Varmuus riippuu rekisteröinnistä, laitteen luottamuksesta, palautuksesta, tilisidonnasta ja peruuttamisesta. Pääsyavainhanke, josta puuttuu näyttö, voi aiheuttaa auditoinnissa epäselvyyttä, vaikka teknologia olisi vahva.

Käytä tätä mallia auditointivalmiin pääsyavainkäyttöönoton valmisteluun.

Tämä on suoraan linjassa ISO/IEC 27001:2022:n kanssa. Kohdat 4.1–4.4 edellyttävät, että organisaatiot ymmärtävät toimintaympäristön, sidosryhmät, ISMS:n soveltamisalan ja toimintaprosessit. Kohdat 5.1–5.3 edellyttävät johtajuutta, politiikkaa, organisaatiorooleja ja vastuullisuutta. Kohdat 6.1.2 ja 6.1.3 edellyttävät toistettavaa tietoturvariskien arviointi- ja riskien käsittelyprosessia, mukaan lukien kontrollien valinta, vertailu liite A:han, soveltuvuuslausunto ja riskinomistajan hyväksyntä jäännösriskille. Kohta 6.2 edellyttää mitattavia tietoturvatavoitteita.

Tämä tarkoittaa, että pääsyavainkäyttöönoton tulisi näkyä ISMS:ssä seuraavasti:

• Riskien käsittelynä tunnistetietojen varkautta ja tietojenkalastelua vastaan.
• Tavoitteena, kuten ”90 prosenttia etuoikeutetusta pääsystä siirretty tietojenkalastelua kestävään MFA:han Q3:een mennessä”.
• Soveltuvuuslausunnon perusteluna, joka liittyy A.5.16-, A.5.17- ja A.8.5-kontrolleihin.
• Pääsynhallintapolitiikan päivityksenä.
• Lokitus- ja valvontakäyttötapauksena.
• Auditointinäyttöpakettina.

Zenith Blueprintissä, riskienhallintavaiheessa, vaihe 13, riskienkäsittelysuunnittelu ja soveltuvuuslausunto, Clarysec kuvaa SoA:n siltana:

SoA on käytännössä siltadokumentti: se yhdistää riskien arvioinnin ja riskien käsittelyn käytössä oleviin todellisiin kontrolleihin. Kun täytät sen, tarkistat samalla, jäikö jokin kontrolli huomioimatta.

NIST SP 800-63-4:n osalta tämä silta on paikka, jossa salasanoja, MFA:ta ja pääsyavaimia koskevista päätöksistä tulee auditoitavia.

Vaatimustenmukaisuuden ristiinkartoitus ISO 27001:een, NIS2:een, DORA:an, GDPR:ään, NIST CSF:ään ja COBIT:iin

Identiteettinäyttö on tehokasta, kun sama kontrollikokonaisuus täyttää useita velvoitteita.

NIS2 Article 21 edellyttää, että keskeiset ja tärkeät toimijat toteuttavat asianmukaiset ja oikeasuhtaiset tekniset, operatiiviset ja organisatoriset toimenpiteet, jotka huomioivat riskin, teknisen kehityksen tason, toteutuskustannukset, koon ja poikkeaman vaikutuksen. Article 21(2) sisältää riskianalyysin, politiikat, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun turvallisuuden, turvallisen kehittämisen, kontrollien tehokkuuden arvioinnin, kyberhygienian ja koulutuksen, kryptografian, HR-turvallisuuden, pääsynhallinnan, omaisuudenhallinnan sekä tarvittaessa monivaiheisen tai jatkuvan todennuksen. Article 20 tekee johdon hyväksynnästä, valvonnasta ja kyberturvallisuuskoulutuksesta hallintovelvoitteen.

DORA tuo saman identiteettikysymyksen rahoitusalan operatiiviseen häiriönsietokykyyn. Soveltamisalaan kuuluvien finanssialan toimijoiden on ylläpidettävä dokumentoitua ICT-riskien hallinnan viitekehystä, joka sisältää hallintoelimen vastuun, suojaus- ja ennaltaehkäisevät kontrollit, pääsynhallinnan, todennuksen, valvonnan, poikkeamien havaitsemisen, jatkuvuuden, reagoinnin, palautumisen ja koulutuksen. Articles 8–10 ovat erityisen olennaisia ICT-omaisuuden ja riippuvuuksien tunnistamisessa, ICT-järjestelmien suojaamisessa, pääsynhallinnassa, vahvassa todennuksessa, valvonnassa ja havaitsemisessa. Articles 17–19 kytkevät saman näytön ICT:hen liittyvien poikkeamien hallintaan ja raportointiin.

GDPR soveltuu aina, kun henkilötietoja käsitellään sen alueellisen ja aineellisen soveltamisalan puitteissa. Article 5(1)(f) edellyttää, että henkilötietoja käsitellään asianmukaisella turvallisuudella. Article 5(2) edellyttää osoitusvelvollisuutta. Article 32 edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä riskitasoon nähden asianmukaisen turvallisuustason varmistamiseksi. Varastettu salasana tai vaarantunut todentaja voi muodostua henkilötietojen tietoturvaloukkaukseksi, jos se aiheuttaa luvattoman pääsyn henkilötietoihin.

NIST CSF 2.0 lisää hyödyllisen hallinnan tason. Sen GOVERN-toiminto edellyttää, että lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset kyberturvallisuusvaatimukset, mukaan lukien tietosuojavelvoitteet, ymmärretään ja hallitaan. CSF-profiilit auttavat organisaatioita vertaamaan nyky- ja tavoitetiloja sekä laatimaan priorisoituja toimintasuunnitelmia.

COBIT 2019 ja ISACA:n auditointilähestymistavat kysyvät, tukevatko identiteetin- ja pääsynhallinnan kontrollit hallintotavoitteita, onko hallintakäytännöt määritelty, vastaako todennuksen vahvuus riskiä ja onko kontrollin toiminnasta näyttöä.

Sama IdP:n ehdollisen pääsyn raportti voi tukea ISO 27001 -pääsynhallintaa, NIS2:n MFA-odotuksia, DORA-todennusta, GDPR:n turvallisuuden osoitusvelvollisuutta ja NIST CSF:n tavoiteprofiilin etenemistä.

Rakenna todentajan näyttöpaketti yhdessä iltapäivässä

Tietoturvajohtaja, vaatimustenmukaisuuspäällikkö tai IT-vastaava voi luoda nopeasti arvokkaan näyttöpaketin keskittymällä yhteen korkean riskin järjestelmään, kuten pilvikonsoliin, talousalustaan, asiakkaiden hallintaportaaliin tai tuotantokäyttöönottoympäristöön.

Määritä ensin soveltamisala. Tunnista liiketoimintavastaava, tietojen luokittelu, käyttäjäryhmät, etuoikeutetut roolit, etäkäyttöpolut, nykyiset todentajat, käsiteltävät henkilötiedot ja kolmansien osapuolten riippuvuudet. Tämä tukee ISO/IEC 27001:2022 kohtia 4.1–4.4, koska soveltamisala, sidosryhmävaatimukset ja riippuvuudet on ymmärrettävä.

Tallenna toiseksi nykyiset todennusasetukset. Vie tai ota kuvakaappaus salasanapolitiikasta, MFA:n pakottamisesta, pääsyavain- tai FIDO2-konfiguraatiosta, ehdollisen pääsyn säännöistä, istunnon aikakatkaisusta, palautusmenetelmistä, hätäkäyttötileistä ja vanhan todennuksen tilasta. Jos järjestelmä käyttää paikallista todennusta, dokumentoi syy ja määritä migraatiopolku.

Vertaa kolmanneksi selkeään tavoitetilaan:

• Salasanat seulotaan heikkojen, yleisten ja vuotaneiden tunnistetietojen varalta.
• Pelkkää salasanaa ei sallita etuoikeutetuille, etäkäytössä oleville tai internetiin avautuville järjestelmille.
• Tietojenkalastelua kestävä MFA on käytössä ylläpitäjille ja korkean riskin käyttäjille.
• Rekisteröinti ja palautus ovat turvallisia.
• Todentajat peruutetaan työsuhteen päättämisen tai laitteen katoamisen yhteydessä.
• Onnistunut ja epäonnistunut todennus, MFA:n käyttö ja todentajamuutokset kirjataan lokiin.
• Hälytykset kattavat mahdottoman matkustamisen, toistuvat epäonnistumiset, uuden todentajan rekisteröinnin ja riskialttiit kirjautumiset.

Liitä neljänneksi politiikkanäyttö. Pk-yrityksen Pääsynhallintapolitiikka - SME edellyttää:

Yksilölliset käyttäjätunnukset ovat pakollisia; jaetut tunnukset ovat kiellettyjä.

Käyttäjätilin elinkaarinäytön osalta pk-yrityksen Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka - SME toteaa:

Käyttäjätilien luontia, käyttäjätilien käytöstäpoistoa ja käyttöoikeusmuutoksia koskevat lokit tulee säilyttää turvallisesti vähintään 12 kuukautta.

Todennuksen lokituksen osalta Clarysecin Lokitus- ja valvontapolitiikka - SME määrittää:

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

Yritystason toteutuksissa Lokitus- ja valvontapolitiikka edellyttää lokitusta seuraavista:

Käyttäjän todennus- ja käyttöyritykset

Päivitä viidenneksi soveltuvuuslausunto. Merkitse A.5.16, A.5.17 ja A.8.5 soveltuviksi ja lisää esimerkiksi seuraavat huomiot:

• Tukee NIST SP 800-63-4:n todentajan elinkaaren odotuksia.
• Tukee NIS2 Article 21:n pääsynhallinta- ja MFA-odotuksia.
• Tukee DORA:n ICT-riskien hallinnan todennus- ja valvontavaatimuksia.
• Tukee GDPR Article 32:n turvallisuutta ja osoitusvelvollisuutta henkilötietoihin pääsyssä.
• Poikkeus: vanha selvitysportaali ei tue FIDO2:ta. Korvaavia kontrolleja ovat VPN-rajoitus, etuoikeutettujen istuntojen valvonta, toimittajan korjaussuunnitelma ja kuukausittainen käyttöoikeuskatselmointi.

Lopuksi valmistele kansio nimeltä ”Todennuksen näyttöpaketti - Q2 2026”, joka sisältää politiikkaotteet, riskien arvioinnin, käsittelytallenteen, SoA-otteen, IdP-konfiguraation, MFA- ja pääsyavainkattavuusraportin, etuoikeutettujen käyttäjien luettelon, poikkeusrekisterin, rekisteröinti- ja peruutuslokit, työsuhteen päättämisen testiotoksen, SIEM-kyselyt, hälytyskuvakaappaukset, otteen tietoturvapoikkeamiin reagoinnin pelikirjasta sekä käyttäjien tietoisuusviestinnän.

Tämä on ero väitteen ”käytämme MFA:ta” ja toteamuksen ”voimme osoittaa turvallisen todennuksen hallinnan” välillä.

Miten eri auditoijat testaavat samoja identiteettikontrolleja

Kypsä identiteettiohjelma ennakoi eri auditointinäkökulmat.

ISO 27001 -auditoija aloittaa hallintajärjestelmästä. Hän kysyy, miten identiteettiriskit arvioitiin, miksi kontrollit valittiin, miten ne näkyvät SoA:ssa, onko politiikat hyväksytty, onko vastuut osoitettu ja osoittaako näyttö toiminnan ajan kuluessa. Hän testaa riskirekisterin, pääsynhallintapolitiikan, IdP-asetusten ja lokien johdonmukaisuutta.

Zenith Blueprint, Kontrollit käytännössä -vaihe, vaihe 19, kontrollien 8.1–8.5 auditoinnin tarkistuslista, kuvaa käytännön auditointipyynnön:

Auditoijat kysyvät salasanojen monimutkaisuusasetuksista ja siitä, miten niitä sovelletaan (Active Directory GPO:t, IdP-politiikat jne.). Esitä dokumentaatio MFA:n käyttöönotosta, keihin sitä sovelletaan, missä se on pakotettu käyttöön ja mitä järjestelmiä se suojaa.

DORA- tai NIS2-auditoija keskittyy hallintaan, häiriönsietokykyyn ja järjestelmätason riskiin. Hän voi pyytää näyttöä hallituksen tai hallintoelimen valvonnasta, kriittisten järjestelmien kattavuudesta, kolmansien osapuolten todennusvelvoitteista, jatkuvuustesteistä ja siitä, että palautusmenettelyt voivat käynnistyä vain todennettujen henkilöiden toimesta.

GDPR-tarkastelija keskittyy henkilötietoihin. Hän kysyy, suojaako todennus henkilötietoja luvattomalta pääsyltä, onko pääsy rajattu välttämättömään, tukevatko lokit loukkauksen arviointia ja voiko organisaatio osoittaa osoitusvelvollisuuden toteutumisen.

NIST-lähtöinen arvioija voi käyttää NIST CSF 2.0 -profiileja nyky- ja tavoitetilojen vertailuun. Hän haluaa priorisoidun toimintasuunnitelman, joka kattaa hallinnan, politiikan, pääsynhallinnan, havaitsemisen ja reagoinnin tulokset.

COBIT 2019- tai ISACA-auditoija arvioi, tukevatko identiteetti- ja todennuskäytännöt hallintotavoitteita, kontrollisuunnittelua, kontrollin toimintaa, tehtävien eriyttämistä, etuoikeutettua pääsyä ja valvontaa. Hänelle ei välttämättä ole merkitystä, minkä merkkistä pääsyavainratkaisua käytätte. Merkitystä on sillä, onko kontrollia hallittu, mitattu, omistettu ja parannettu.

Älä unohda työsuhteen päättämistä, palautusta ja ei-inhimillisiä identiteettejä

Monet todennusohjelmat näyttävät vahvoilta kirjautumisessa ja heikoilta kaikkialla muualla.

Työsuhteen päättäminen on yleinen epäonnistumiskohta. Clarysecin Perehdytys- ja työsuhteen päättämispolitiikka sisältää nimenomaisesti:

MFA-/SSO-tokenien, älykorttien tai varmenteiden peruuttaminen

Tämä lauseke tulee testata. Valitse kolme työsuhteensa päättänyttä käyttäjää ja osoita, että käyttäjätilit, istunnot, MFA-laitteet, pääsyavaimet, varmenteet ja palautusmenetelmät peruutettiin ajallaan. Jos et voi osoittaa tokenien peruuttamista, työsuhteen päättämiskontrolli on puutteellinen.

Palautus on toinen heikko kohta. Jos helpdesk voi nollata MFA:n kahteen helppoon kysymykseen vastaamisen jälkeen, hyökkääjä kohdistaa hyökkäyksen helpdesk-palautukseen kirjautumisen sijaan. Palautusmenettelyjen tulee edellyttää vahvaa varmentamista, tikettien lokitusta, hyväksyntää etuoikeutetuille käyttäjille, käyttäjän ilmoittamista ja palautuksen jälkeisen toiminnan valvontaa.

Ei-inhimilliset identiteetit ovat kolmas sokea piste. Zenith Blueprint vaihe 22 tekee selväksi, että todennustiedot sisältävät ”salasanat, PIN-koodit, kryptografiset avaimet, biometriset mallit, älykortit, tokenit, varmenteet, OAuth-tokenit, SSH-avaimet ja API-salaisuudet.” Hyökkääjät käyttävät usein API-tokeneita, palvelutilien avaimia ja OAuth-valtuutuksia pysyvyyden säilyttämiseen. Käsittele näitä tunnistetietoja A.5.17:n mukaisesti: holvitus, omistajuus, kierto, peruuttaminen ja lokitus.

Miltä hyvä näyttää vuonna 2026

Kypsällä vuoden 2026 identiteettikontrolliympäristöllä on seuraavat ominaisuudet:

• Hallitus tai hallintoelin ymmärtää identiteettiriskin ja hyväksyy suunnan.
• Salasanapolitiikka on modernisoitu, käyttäjäystävällinen ja teknisesti toteutettu.
• Pelkkään salasanaan perustuva pääsy on poistettu etuoikeutetuista, etäkäytössä olevista ja internetiin avautuvista järjestelmistä.
• Pääsyavaimet tai FIDO2-todentajat priorisoidaan korkean riskin pääsyssä.
• MFA-poikkeukset dokumentoidaan, hyväksytään, aikarajoitetaan ja kompensoidaan.
• Todentajan rekisteröintiä, palautusta ja peruuttamista valvotaan.
• Työsuhteen päättäminen sisältää käyttäjätilien, tokenien, varmenteiden, istuntojen ja pääsyavainten peruuttamisen.
• Todennuslokit sisältävät onnistumiset, epäonnistumiset, MFA:n käytön, istunnon keston ja todentajamuutokset.
• SIEM-käyttötapaukset havaitsevat credential stuffing -hyökkäykset, mahdottoman matkustamisen, epäilyttävän rekisteröinnin ja MFA-väsymyksen.
• SoA selittää, miksi A.5.16, A.5.17 ja A.8.5 soveltuvat.
• NIS2-, DORA-, GDPR- ja NIST CSF -kartoitukset kirjataan kerran ja käytetään uudelleen.
• Näyttöä kerätään jatkuvasti eikä koottuna paniikissa juuri ennen auditointia.

Näin NIST SP 800-63-4:stä tulee enemmän kuin viiteasiakirja. Siitä tulee elävä kontrollijärjestelmä, joka tukee tietoturvaa, tietosuojaa, häiriönsietokykyä ja valmiutta osoittaa vaatimustenmukaisuus.

Muunna identiteettikontrollit auditointivalmiiksi näytöksi

Jos organisaatiosi päivittää salasanasääntöjä, ottaa käyttöön tietojenkalastelua kestävää MFA:ta, tuo käyttöön pääsyavaimia tai valmistautuu ISO 27001-, NIS2-, DORA- tai GDPR-auditointikysymyksiin, älä aloita pelkästä työkalukonfiguraatiosta.

Aloita näyttömallista.

Clarysec voi auttaa sinua:

• Kartoittamaan NIST SP 800-63-4:n salasana-, MFA- ja pääsyavainodotukset ISO/IEC 27001:2022:een.
• Rakentamaan todentajan elinkaaripolitiikan ja näyttöpaketin.
• Päivittämään pääsynhallinta-, MFA-, lokitus-, perehdytys- ja työsuhteen päättämispolitiikat.
• Valmistelemaan soveltuvuuslausunnon, joka yhdistää identiteettiriskin kontrolleihin.
• Käyttämään Zenith Blueprintiä toteutusvaiheiden ja auditointivalmiuden jäsentämiseen.
• Käyttämään Zenith Controlsia identiteettikontrollien ristiinkartoitukseen NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n ja COBIT 2019:n välillä.

Paras hetki havaita heikko palautus, puuttuva pääsyavaimen peruuttaminen tai puutteellinen MFA:n soveltaminen on ennen poikkeamaa, ennen viranomaista ja ennen kuin auditoija kysyy.

Tee seuraavasta pääsynhallinnan katselmoinnistasi NIST SP 800-63-4 -näytön katselmointi. Lataa asiaankuuluvat Clarysec-politiikat, tutustu Zenith Blueprintiin ja käytä Zenith Controlsia muuntaaksesi salasanojen, MFA:n ja pääsyavainten toteutuksen yhdeksi käytännölliseksi, oikeasuhtaiseksi ja auditointivalmiiksi vaatimustenmukaisuuskokonaisuudeksi.