Kryptografisten avainten hallinta ISO 27001:n, NIS2:n ja DORA:n näkökulmasta
Maanantaiaamuna klo 08.17 eurooppalaisen SaaS-yhtiön tietoturvajohtaja saa kehitystiimin vetäjältä viestin: ”Kierrätimme tietokannan salausavaimen viikonloppuna, mutta yksi integraatio ei enää pystynyt purkamaan tietueita. Palautimme tilanteen käyttämällä holvissa ollutta vanhaa avainta.”
Kymmenen minuuttia myöhemmin tietosuojavastaava kysyy, sisältävätkö vaikutuksen kohteena olevat tietueet EU:n henkilötietoja. Taloushallinto kysyy, voiko tästä tulla säänneltyä asiakasta koskeva ilmoitettava operatiivinen poikkeama. Hankinta kysyy, omistaako pilvipalveluntarjoaja vai yhtiö asiakkaan hallinnoiman avaimen. Toimitusjohtaja esittää hallituksen kannalta ainoan olennaisen kysymyksen: ”Voimmeko osoittaa, että hallitsimme tämän asian asianmukaisesti?”
Tämä on hetki, jolloin ”käytämme salausta” lakkaa olemasta rauhoittava toteamus ja muuttuu näyttökysymykseksi.
Vuonna 2026 kryptografisten avainten hallinta sijoittuu ISO/IEC 27001:2022 -hallintakeinojen, NIS2:n kyberhygienian, DORA:n ICT-riskienhallinnan, GDPR Article 32:n käsittelyn turvallisuutta koskevan näytön, pilven jaetun vastuun sekä post-kvanttisen kryptografisen ketteryyden suunnittelun leikkauspisteeseen. Varsinainen kysymys ei ole, onko salausta käytössä. Varsinainen kysymys on, pystyykö organisaatio osoittamaan tallenteilla, että avaimet luodaan turvallisesti, niille määritetään omistajat, ne säilytetään hyväksytyissä KMS- tai HSM-ympäristöissä, ne kierretään aikataulun mukaisesti, ne palautetaan turvallisesti, ne perutaan vaarantumistilanteissa ja ne on kytketty liiketoimintariskiin.
Clarysec näkee valmiustyössä saman kaavan toistuvasti. Salaus on toteutettu järjestelmä kerrallaan, mutta avaintenhallinta on hajanaista. Varmenteet elävät laskentataulukoissa. Pilvi-KMS:n käyttöoikeudet periytyvät vanhoista projekteista. Kehittäjät tietävät, millä salaisuuksilla on merkitystä, mutta ISMS ei tiedä sitä. Auditoijat saavat elinkaarinäytön sijaan kuvakaappauksia. NIS2- ja DORA-tiimit puhuvat häiriönsietokyvystä, tietosuojatiimit puhuvat GDPR:n mukaisesta salauksesta ja pseudonymisoinnista, eikä kukaan omista kryptografista kontrollitasoa päästä päähän.
Kypsä vastaus ei ole lisää kryptografiaa irrallisena teknisenä ratkaisuna. Se on hallittu kryptografisten avainten hallinta, joka on kytketty riskien käsittelyyn, pilviarkkitehtuuriin, toimittajien valvontaan, pääsynhallintaan, lokitukseen, tietoturvapoikkeamiin reagointiin ja sääntelynäyttöön.
Miksi avaintenhallinta on nyt hallinnointikysymys
NIS2 tekee kryptografia- ja salauskäytännöistä osan välttämättömien ja tärkeiden toimijoiden kyberturvallisuuden riskienhallinnan vähimmäistoimenpiteitä. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, jatkuvuus, toimitusketjun turvallisuus, turvallinen kehittäminen, kyberhygienia, pääsynhallinta, omaisuudenhallinta sekä kryptografia- ja salauskäytännöt. Se edellyttää myös, että johtamisesta vastaavat elimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet ja valvovat niitä.
SaaS-, pilvi-, hallinnoitujen palvelujen ja kyberturvallisuuspalvelujen tarjoajien osalta soveltamisala voi olla laajempi kuin moni tiimi olettaa. NIS2 kattaa aloja, kuten digitaalisen infrastruktuurin, pilvipalveluntarjoajat, datakeskuspalvelujen tarjoajat, DNS-palveluntarjoajat, luottamuspalvelujen tarjoajat, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, verkkomarkkinapaikat, hakukoneet ja sosiaalisen verkostoitumisen alustat, kun koko- tai kriittisyyskynnykset täyttyvät.
DORA nostaa vaatimustasoa finanssitoimijoille. 17. tammikuuta 2025 alkaen DORA edellyttää dokumentoitua ICT-riskienhallinnan viitekehystä, hallituksen vastuuvelvollisuutta, ICT-liiketoiminnan jatkuvuutta sekä reagointi- ja palautumissuunnitelmia, digitaalisen operatiivisen häiriönsietokyvyn testausta, ICT-kolmansien osapuolten riskienhallintaa ja poikkeamien raportointia. Finanssitoimijoille, jotka on tunnistettu NIS2:n kansallisten sääntöjen mukaisesti, DORA toimii sektorikohtaisena unionin säädöksenä vastaaville NIS2-velvoitteille. Fintech-yhtiön ei tule ylläpitää erillistä kryptografian hallinnointia NIS2:lle, DORA:lle ja ISO:lle. Se tarvitsee yhden puolustettavissa olevan hallintakeinomallin.
GDPR lisää tietosuojan näyttöulottuvuuden. GDPR Article 32 on kohta, jossa salausta arvioidaan yleisesti käsittelyn turvallisuuden suojatoimena, mutta ”tiedot on salattu” ei ole täydellinen vastaus. Valvontaviranomaiset ja auditoijat kysyvät, kuka hallitsee avaimia, miten pääsyä rajoitetaan, miten vaarantuminen havaitaan, miten palautus toimii ja vastaako suunnittelu rekisteröityihin kohdistuvaa riskiä.
ISO/IEC 27001:2022 antaa organisaatioille hallintajärjestelmän näiden velvoitteiden sitomiseksi yhteen. Kohdat 4.1–4.4 edellyttävät toimintaympäristöä, sidosryhmien vaatimuksia, ISMS:n soveltamisalaa ja vuorovaikutteisia prosesseja. Kohdat 5.1–5.3 edellyttävät johtajuutta, politiikkaa, resursseja ja osoitettuja vastuita. Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, hallintakeinojen valintaa, soveltuvuuslausuntoa ja riskinomistajan hyväksyntää. Kohdat 8.1–8.3 edellyttävät hallittua toimintaa, riskien uudelleenarviointia muutosten yhteydessä, riskienkäsittelysuunnitelmien toteutusta ja dokumentoitujen tulosten säilyttämistä.
Kryptografisten avainten hallinnan osalta ISMS:n tulee vastata viiteen kysymykseen:
- Mitkä tietovarat, tietovirrat ja palvelut edellyttävät kryptografista suojausta?
- Mitkä avaimet, varmenteet, salaisuudet ja kryptografiapalvelut suojaavat niitä?
- Kuka omistaa, ylläpitää, hyväksyy ja valvoo näitä kryptografisia omaisuuseriä?
- Miten luontia, säilytystä, käyttöä, kiertoa, escrow-järjestelyä, palautusta, perumista ja tuhoamista hallitaan?
- Mikä näyttö osoittaa, että hallintakeinot toimivat suunnitellusti?
ISO 27001:n hallintakeinorunko kryptografisten avainten hallinnalle
Clarysec käsittelee kryptografisten avainten hallintaa hallintakeinoketjuna, ei yksittäisenä hallintakeinona. Zenith Controls: The Cross-Compliance Guide -oppaassa Zenith Controls aihe kohdistuu ensisijaisesti ISO/IEC 27002:2022 control 8.24:ään, kryptografian käyttöön, ja sillä on tärkeitä tukisuhteita kohtiin 5.17, todentamistiedot, ja 5.23, pilvipalvelujen käytön tietoturva.
Tällä suhteella on merkitystä. Avaintenhallinnan epäonnistuminen on harvoin vain ”huonoa salausta”. Usein kyse on todentamisongelmasta, pilvihallinnoinnin ongelmasta, toimittajaongelmasta, lokituksen puutteesta tai muutoksenhallinnan epäonnistumisesta.
| ISO/IEC 27002:2022 -alue | Miksi se on olennainen avaintenhallinnalle | Tyypillinen näyttö |
|---|---|---|
| 8.24 Kryptografian käyttö | Määrittää hyväksytyt kryptografian käyttötapaukset, algoritmit, protokollat, avainten elinkaaren ja toteutusodotukset | Kryptografiapolitiikka, algoritmistandardi, avainten elinkaarimenettely, KMS-konfiguraatio, kiertotallenteet |
| 5.17 Todentamistiedot | Suojaa tunnistetiedot, salaisuudet, tokenit ja todentamismateriaalin, jotka liittyvät etuoikeutettuihin kryptografisiin operaatioihin | Salaisuuksien inventaario, holvin käyttölokit, etuoikeutettujen käyttöoikeuksien katselmoinnit, MFA-näyttö |
| 5.23 Pilvipalvelujen käytön tietoturva | Määrittää jaetun vastuun, pilviavainten omistajuuden, CMK- tai BYOK-päätökset ja palveluntarjoajan hallinnoinnin | Pilvipalvelurekisteri, jaetun vastuun matriisi, KMS-arkkitehtuuri, toimittajaturvallisuuden katselmointi |
| 5.19–5.22 Toimittajaturvallisuus | Varmistaa, että toimittajat ja ICT-palveluntarjoajat täyttävät salausta, avainten hallussapitoa, poikkeamia ja auditointia koskevat vaatimukset | Sopimukset, due diligence -arvioinnit, toimittajavarmennukset, seurantakatselmoinnit |
| 5.24–5.28 Poikkeamien hallinta | Kytkee epäillyn avaimen vaarantumisen tapahtuman arviointiin, reagointiin, oppimiseen ja todistusaineiston keräämiseen | Poikkeamien palautusohjeet, avaimen vaarantumisen pelikirjat, forensiset lokit, opit |
| 8.15 ja 8.16 Lokitus ja seuranta | Havaitsee luvattoman avainten käytön, epäilyttävät API-kutsut, epäonnistuneet salauksen purkuyritykset ja politiikkamuutokset | SIEM-hälytykset, KMS-auditointilokit, poikkeamien havaitsemissäännöt |
| 8.32 Muutoksenhallinta | Hallitsee kiertoja, migraatioita, algoritmipäivityksiä, hätäperumisia ja post-kvanttista siirtymätyötä | Muutospyynnöt, hyväksynnät, palautussuunnitelmat, testitulokset |
Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint tekee tästä operatiivista riskienhallintavaiheen kohdassa vaihe 14, riskienkäsittelypolitiikat ja sääntelyviittaukset. Sen kryptografiapolitiikan esimerkki toteaa, että organisaation tulee määrittää, missä kryptografiaa tarvitaan, hyväksyä algoritmit ja protokollat, määrittää avaintenhallinta, kattaa käyttötapaukset, kuten koko levyn salaus ja turvallinen viestintä, sekä kytkeä politiikka GDPR Article 32:een.
”Salausavaimet tulee säilyttää turvallisesti (esim. avainholvissa/HSM:ssä), ja pääsy tulee rajata valtuutetulle henkilöstölle.”
Lähde: Zenith Blueprint, riskienhallintavaihe, vaihe 14, riskienkäsittelypolitiikat ja sääntelyviittaukset Zenith Blueprint
Hallintakeinojen käyttöönoton vaiheessa, kohdassa vaihe 20, Zenith Blueprint menee syvemmälle. Kryptografiassa ei ole kyse siitä, että ”salaus kytketään päälle”. Kyse on kryptografian sisällyttämisestä suunnitteluun, politiikkaan ja elinkaaren hallintaan. Tämä kattaa lepotilassa olevat tiedot, siirrettävät tiedot, identiteettien ja tapahtumien todennuksen, hyväksytyt algoritmit, avainholvit, HSM:t, aikataulutetun kierron, perumisen sekä validoinnin penetraatiotestauksen ja koodikatselmoinnin avulla.
Mitä auditoijat odottavat pyytäessään näyttöä avaimista
Useimmat auditointihavainnot alkavat yksinkertaisella pyynnöllä: ”Näyttäkää salauspolitiikkanne ja avaintenhallinnan tallenteet.”
Heikkoja vastauksia ovat esimerkiksi:
- ”Pilvipalveluntarjoaja salaa kaiken oletuksena.”
- ”Käytämme TLS:ää.”
- ”Salaisuudet ovat holvissa.”
- ”Kehitystiimi hoitaa kierron.”
- ”Sovellus hallitsee avainta.”
Nämä väitteet voivat olla teknisesti totta, mutta ne eivät muodosta täydellistä näyttöä. ISO-auditoija kytkee avaintenhallinnan takaisin riskien arviointiin, soveltuvuuslausuntoon, politiikkavaatimuksiin, operatiiviseen hallintaan ja säilytettyyn dokumentaatioon. NIST CSF -arvioija kysyy, onko kryptografiset omaisuuserät tunnistettu, suojattu, valvottu ja palautettavissa. DORA-auditoija etsii hallituksen hyväksymää ICT-riskienhallintaa, kolmansien osapuolten riippuvuuksia, poikkeamien hallintaa ja häiriönsietokyvyn testausta. GDPR-arvioija kysyy, pienentävätkö salaus ja avainten eriyttäminen rekisteröityihin kohdistuvaa riskiä ja voiko rekisterinpitäjä osoittaa osoitusvelvollisuuden toteutumisen.
Clarysecin yritystason Kryptografisten hallintakeinojen politiikka Kryptografisten hallintakeinojen politiikka käsittelee näyttöpuutetta suoraan:
”Keskitettyä avaintenhallintarekisteriä tulee ylläpitää kaikkien kryptografisten avainten, niiden elinkaaren tilan, nimettyjen vastuuhenkilöiden ja käyttöyhteyksien kirjaamiseksi.”
Lähde: yrityspolitiikka, Kryptografisten hallintakeinojen politiikka, hallinnointivaatimukset, kohta 5.2 Kryptografisten hallintakeinojen politiikka
Tämä virke muuttaa auditointikeskustelun. Hiljaisen tiedon etsimisen sijaan organisaatio voi näyttää rekisterin, joka yhdistää avaimet omaisuuseriin, omistajiin, tietojen luokitteluihin, järjestelmiin, pilvitileihin, kiertopäiviin, käyttöyhteyksiin ja näyttöön.
Pk-yrityksille Clarysecin Kryptografisten hallintakeinojen politiikka SME Kryptografisten hallintakeinojen politiikka SME skaalaa saman odotuksen:
”IT-tukipalveluntarjoajan tulee ylläpitää ajantasaista inventaariota käytössä olevista kryptografisista työkaluista ja varmenteista”
Lähde: pk-yrityksen politiikka, Kryptografisten hallintakeinojen politiikka SME, hallinnointivaatimukset, kohta 5.1.2 Kryptografisten hallintakeinojen politiikka SME
Säännelty finanssilaitos voi tarvita HSM-seremonioita, jaettua tietämystä, kahden henkilön valvontaa, muodollisia vastuuhenkilöiden nimeämisiä ja neljännesvuosittaisia käyttöoikeuskatselmointeja. Pieni SaaS-palveluntarjoaja voi aloittaa ylläpidetystä inventaariosta, hyväksytyistä algoritmeista, dokumentoidusta KMS-omistajuudesta ja kiertonäytöstä. Molemmat tarvitsevat hallinnointia, joka on oikeasuhtaista riskiin nähden.
Avainten elinkaari, jota ISMS:n tulee hallita
Käytännöllinen avaintenhallintaohjelma seuraa elinkaarta. Jokainen vaihe tarvitsee omistajan, hyväksytyn menetelmän, teknisen hallintakeinon, muutostallenteen ja auditointinäytön.
| Elinkaarivaihe | Avaintenhallinnan hallinnointikysymys | Hallintakeino-odotus | Esimerkki näytöstä |
|---|---|---|---|
| Luokittelu | Mitkä tiedot tai tapahtumat tarvitsevat kryptografista suojausta? | Tietojen luokittelu tunnistaa henkilötiedot, taloustiedot, tunnistetiedot, lokit, varmuuskopiot ja arkaluonteiset konfiguraatiot | Tietojen luokittelurekisteri, salausvaatimusten matriisi |
| Suunnittelu | Mikä kryptografinen menetelmä on hyväksytty? | Hyväksytyt algoritmit, protokollat, kirjastot ja avainpituudet määritetään ja katselmoidaan | Kryptografiastandardi, arkkitehtuuripäätöksen tallenne |
| Luonti | Miten avaimet luodaan turvallisesti? | Avaimet luodaan hyväksytyissä KMS-, HSM- tai validoiduissa moduuleissa, ei manuaalisesti eikä lähdekoodissa | KMS:n avaimenluontilokit, HSM-seremonian tallenne |
| Kohdistaminen | Kuka omistaa ja ylläpitää avainta? | Liiketoimintavastaava, tekninen vastuuhenkilö ja varavastuuhenkilö nimetään | Avaintenhallintarekisteri |
| Säilytys | Missä avainta säilytetään? | Avaimet säilytetään KMS:ssä, HSM:ssä tai holvissa, joissa on pääsynhallinta ja auditointilokitus | KMS-politiikka, holvin konfiguraatio, käyttölokit |
| Käyttö | Mitkä järjestelmät voivat käyttää avainta? | Vähimmän oikeuden periaate, työkuorman identiteetti, tehtävien eriyttäminen ja hyväksytty API-pääsy toteutetaan | IAM-politiikka, palvelutilien kartoitus |
| Kierto | Milloin ja miksi avain kierretään? | Aikataulutettu kierto ja tapahtumaperusteinen kierto vaarantumisen tai roolimuutoksen vuoksi | Kiertoaikataulu, muutospyynnöt, testitulokset |
| Escrow ja palautus | Miten palvelut voidaan palauttaa paljastamatta avaimia? | Varmuuskopiointi- ja palautusmenettelyt testataan ja pääsyä hallitaan | Palautustesti, escrow-hyväksyntätallenne |
| Peruminen | Mitä tapahtuu vaarantumisen tai käytöstäpoiston jälkeen? | Avaimet ja varmenteet perutaan tai poistetaan käytöstä, ja riippuvat järjestelmät päivitetään | Poikkeamatiketti, perumisloki |
| Tuhoaminen | Miten käytöstä poistetut avaimet tuhotaan? | Turvallinen puhdistus tai kryptografinen poisto noudattaa säilytys- ja lakisääteisiä vaatimuksia | Tuhoamistallenne, KMS-poistoaikataulu |
Yritystason Kryptografisten hallintakeinojen politiikka vahvistaa turvallista luontia:
”Avainten luonti: Suoritetaan turvallisilla laitteisto- tai ohjelmistomoduuleilla (esim. HSM:t, FIPS 140-2 -validoidut järjestelmät).”
Lähde: yrityspolitiikka, Kryptografisten hallintakeinojen politiikka, politiikan toteutusvaatimukset, kohta 6.3.1 Kryptografisten hallintakeinojen politiikka
Se määrittää myös kierron:
”Avainten kierto: Vaaditaan määritellyin väliajoin tai välittömästi vaarantumisen tai roolimuutoksen yhteydessä.”
Lähde: yrityspolitiikka, Kryptografisten hallintakeinojen politiikka, politiikan toteutusvaatimukset, kohta 6.3.4 Kryptografisten hallintakeinojen politiikka
Pk-yrityksille sama periaate ilmaistaan yksinkertaisemmalla operatiivisella kielellä:
”Avainten kierto tulee suorittaa vanhenemisaikataulujen mukaisesti tai epäillyn vaarantumisen yhteydessä”
Lähde: pk-yrityksen politiikka, Kryptografisten hallintakeinojen politiikka SME, politiikan toteutusvaatimukset, kohta 6.3.4 Kryptografisten hallintakeinojen politiikka SME
Näillä kohdilla on merkitystä NIS2:n ja DORA:n kannalta, koska vanhentuneet tai heikosti hallinnoidut avaimet eivät ole vain luottamuksellisuuden heikkouksia. Ne voivat muodostua tietoturvapoikkeamiin reagoinnin esteiksi, toimittajariippuvuuksiin liittyviksi ongelmiksi, katastrofipalautuksen epäonnistumisiksi ja asiakasilmoitusten ongelmiksi.
Pilvi-KMS, HSM ja BYOK: jaetun vastuun ansa
Pilvisalaus on yksi yleisimmistä väärän varmuuden lähteistä. Pilvipalveluntarjoaja voi salata tallennuksen oletuksena, mutta se ei automaattisesti tarkoita, että organisaatiosi olisi hallinnut avainta.
Zenith Blueprint, hallintakeinojen käyttöönoton vaihe, vaihe 23, selittää ISO/IEC 27002:2022 control 5.23:a keskittymällä pilvihallinnointiin, näkyvyyteen ja jaettuun vastuuseen. Se korostaa, että palveluntarjoaja voi suojata infrastruktuurin, mutta asiakas vastaa edelleen tiedoistaan, konfiguraatioistaan, pääsypolitiikoistaan ja valmiudestaan reagoida tietoturvapoikkeamiin.
”Pilvipalveluntarjoajat suojaavat infrastruktuurin, mutta sinä olet edelleen vastuussa tiedoistasi, konfiguraatioistasi, pääsypolitiikoistasi ja valmiudestasi reagoida tietoturvapoikkeamiin.”
Lähde: Zenith Blueprint, hallintakeinojen käyttöönoton vaihe, vaihe 23, organisatoriset hallintakeinot 5.19–5.37 Zenith Blueprint
Tässä pilviavaimiin liittyvä vastuu muuttuu hallitustason riskiksi. SaaS-yhtiö voi käyttää palveluntarjoajan hallinnoimaa salausta vähäriskisille lokeille, asiakkaan hallinnoimia avaimia asiakastietokannoille, BYOK-ratkaisuja säännellyille tenant-ympäristöille ja HSM-taustaisia juuriavaimia allekirjoitukseen tai tokenisointiin. Jokaisella valinnalla on vaatimustenmukaisuusvaikutuksia.
Clarysecin yritystason Pilvipalvelujen käyttöpolitiikka Pilvipalvelujen käyttöpolitiikka antaa selkeän hallintakeinosuunnan:
”Asiakkaan hallinnoimia avaimia (CMK) tai Bring Your Own Key (BYOK) -mallia tulee käyttää, kun pilvipalveluntarjoaja tukee niitä.”
Lähde: yrityspolitiikka, Pilvipalvelujen käyttöpolitiikka, politiikan toteutusvaatimukset, kohta 6.4.2 Pilvipalvelujen käyttöpolitiikka
Tämä ei tarkoita, että jokaisen pilvipalvelun tulee käyttää BYOK-mallia. Se tarkoittaa, että organisaation tulee tehdä päätös tietoisesti riskin, asiakassitoumusten, sopimusvaatimusten ja palautuskelpoisuuden perusteella.
| Avainten omistusmalli | Soveltuva käyttötapaus | Hallinnoinnin painopiste |
|---|---|---|
| Palveluntarjoajan hallinnoimat avaimet | Vähäriskinen telemetria, ei-arkaluonteiset lokit, tavanomainen alustasalaus | Vahvista palveluntarjoajan hallintakeinot, dokumentoi riskiperuste, valvo palvelukonfiguraatiota |
| Asiakkaan hallinnoimat avaimet | Tuotantotietokannat, varmuuskopiot, asiakastietueet, säännellyt työkuormat | Nimeä omistaja, rajoita pääsyä, kirjaa avaimen käyttö lokiin, kierrätä ja testaa palautus |
| BYOK tai ulkoinen avaintenhallinta | Korkean riskin tenant-ympäristöt, sopimusperusteinen eriyttäminen, säännellyt asiakassitoumukset | Hallitse tuontia, hallussapitoa, perumista, toimittajaehtoja ja häiriönsietokyvyn testausta |
| HSM-taustaiset avaimet | Juuriavaimet allekirjoitukseen, varmentajat, tokenisointi ja korkean arvon salaisuudet | Sovella kahden henkilön valvontaa, seremoniamerkintöjä, tehtävien eriyttämistä ja tiukkaa pääsyn seurantaa |
DORA Article 28 ja Article 30 tekevät tästä erityisen olennaista finanssitoimijoille. Ne edellyttävät ICT-kolmansien osapuolten riskienhallintaa, ICT-sopimusjärjestelyjen rekistereitä, due diligence -arviointia, auditointi- ja tarkastusoikeuksia, poikkeama-apua, tietosuojaa ja pääsyä, palautusta sekä tietojen palauttamista koskevia määräyksiä. Jos pilvipalveluntarjoaja tai SaaS-toimittaja hallitsee salausavaimia kriittiselle tai tärkeälle toiminnolle, tämän suhteen tulee näkyä ICT-kolmansien osapuolten rekisterissä ja sopimusperusteisissa hallintakeinoissa.
NIS2 edellyttää myös toimitusketjun turvallisuutta, mukaan lukien toimittajakohtaiset haavoittuvuudet, kyberturvallisuuskäytännöt ja turvallisen kehittämisen menettelyt. Jos kriittinen toimittaja pitää hallussaan avaimiasi, operoi KMS:ääsi, toimittaa HSM:n, hallinnoi varmenteiden elinkaarta tai ylläpitää salattuja varmuuskopioita, toimittaja on osa kryptografista kontrolliympäristöäsi.
Algoritmien hyväksyntä ja kryptografinen ketteryys vuonna 2026
Vuoden 2026 avaintenhallintapolitiikan ei tule vain luetella ”AES-256” ja ”TLS 1.2 tai uudempi”. Sen tulee määrittää hyväksyntä- ja katselmointiprosessi, joka tukee kryptografista ketteryyttä. Kryptografinen ketteryys tarkoittaa, että organisaatio pystyy tunnistamaan, missä algoritmeja, protokollia, varmenteita ja avainpituuksia käytetään, arvioimaan altistumisen heikkouksille tai vanhentumiselle ja siirtymään hallitusti ilman paniikkia.
Clarysecin pk-yrityspolitiikka toteaa:
”Vain IT-tukipalveluntarjoajan hyväksymiä alan parhaiden käytäntöjen mukaisia algoritmeja ja protokollia saa käyttää (esim. AES-256, RSA 2048, TLS 1.2 tai uudempi)”
Lähde: pk-yrityksen politiikka, Kryptografisten hallintakeinojen politiikka SME, politiikan toteutusvaatimukset, kohta 6.2.1 Kryptografisten hallintakeinojen politiikka SME
Se edellyttää myös dokumentointia:
”Kaikki salausmenetelmät (esim. AES-256, TLS 1.2+) ja avaintenhallintaprosessit tulee dokumentoida”
Lähde: pk-yrityksen politiikka, Kryptografisten hallintakeinojen politiikka SME, hallinnointivaatimukset, kohta 5.3.1 Kryptografisten hallintakeinojen politiikka SME
Auditointivalmis versio on hyväksytty kryptografiastandardi, joka sisältää:
- Sallitut algoritmit ja protokollat lepotilassa oleville tiedoille, siirrettäville tiedoille, allekirjoituksille, salasanojen tiivistealgoritmeille, tokenisoinnille ja varmuuskopioille.
- Kielletyt algoritmit, protokollat ja kirjastot.
- Vähimmäisavainpituudet ja varmenteiden voimassaoloajat.
- Hyväksytyt KMS-, HSM-, varmentaja- ja salaisuuksienhallinta-alustat.
- Turvallisen satunnaislukujen luonnin vaatimukset.
- Kehittäjäohjeet kryptografisille kirjastoille.
- Poikkeusprosessi legacy-järjestelmille.
- Katselmoinnin herätteet haavoittuvuuksille, sääntelymuutoksille, toimittajamuutoksille ja post-kvanttisen siirtymän suunnittelulle.
Post-kvanttinen suunnittelu ei edellytä, että jokainen organisaatio korvaa kaiken kryptografian välittömästi. Se edellyttää inventaariota. Ilman kryptografista inventaariota et voi tietää, mitkä järjestelmät käyttävät pitkäikäistä julkisen avaimen salausta, mitkä varmenteet suojaavat kriittisiä palveluja, missä allekirjoitusavaimet sijaitsevat tai minkä toimittajien tulee tukea migraatiota. Avaintenhallintarekisteri ei ole byrokratiaa. Se on kryptografisen ketteryyden perusta.
90 minuutin avaintenhallinnan näyttösprintti
Clarysec käyttää usein lyhyttä näyttösprinttiä johdon, tietoturvan, pilven ja vaatimustenmukaisuuden tiimien kanssa. Tavoitteena on muuntaa hajallaan oleva avaintieto nopeasti auditointinäytöksi.
Vaihe 1: Valitse yksi kriittinen palvelu
Valitse järjestelmä, jolla on merkitystä NIS2:n, DORA:n tai GDPR:n kannalta. Esimerkkejä ovat asiakasidentiteetti, maksujen käsittely, tapahtumien seuranta, tuotannon asiakastietokanta, salattu varmuuskopiointialusta tai asiakasrajapinnan API.
Vaihe 2: Avaa avaintenhallintarekisteri
Käytä rakenteena Kryptografisten hallintakeinojen politiikan keskitettyä rekisteriä koskevaa vaatimusta. Jos sellaista ei vielä ole, luo yksinkertainen rekisteri seuraavilla kentillä:
| Rekisterikenttä | Esimerkkimerkintä |
|---|---|
| Avaimen tai varmenteen tunnus | prod-db-cmk-eu-west-01 |
| Käyttöyhteys | Tuotannon asiakastietokannan salaus |
| Suojatut tiedot | EU-asiakkaiden henkilötiedot ja laskutuksen metatiedot |
| Omistaja | Head of Platform |
| Vastuuhenkilö | Cloud Security Lead |
| Säilytyspaikka | Pilvi-KMS, EU-alue |
| Avaintyyppi | Asiakkaan hallinnoima symmetrinen avain |
| Luontipäivä | 2026-01-14 |
| Kiertotiheys | 180 päivää |
| Viimeisin kierto | 2026-04-10 |
| Seuraava kierto | 2026-10-07 |
| Pääsymalli | Vain palvelurooli, ylläpito break-glass-ryhmän kautta |
| Lokitus | KMS API -lokit välitetään SIEM:iin |
| Palautusmenetelmä | KMS-varmuuskopiointi ja testattu palautusmenettely |
| Toimittajariippuvuus | Pilvipalveluntarjoajan KMS |
| Vaatimustenmukaisuuskartoitus | ISO 8.24, 5.17, 5.23, GDPR Article 32, NIS2 Article 21, DORA ICT risk |
| Näyttölinkki | Muutospyyntö, KMS-kuvakaappaus, IAM-katselmointi, lokikysely, palautustesti |
Vaihe 3: Jäljitä pääsy ja kahden henkilön valvonta
Korkean vaikutuksen kryptografisiin operaatioihin tulee soveltaa kahden henkilön valvontaa ja vähimmän oikeuden periaatetta. Yritystason Kryptografisten hallintakeinojen politiikka toteaa:
”Kahden henkilön valvonnan ja vähimmän oikeuden periaatteita tulee soveltaa arkaluonteisiin kryptografisiin operaatioihin (esim. juuriavainten tuonti, HSM-ylläpito).”
Lähde: yrityspolitiikka, Kryptografisten hallintakeinojen politiikka, politiikan toteutusvaatimukset, kohta 6.6.2 Kryptografisten hallintakeinojen politiikka
Kysy:
- Kuka voi poistaa avaimen käytöstä tai poistaa sen?
- Kuka voi muuttaa avainpolitiikkaa?
- Kuka voi purkaa tiedot suoraan?
- Valvotaanko break-glass-rooleja ja ovatko ne aikarajoitettuja?
- Onko MFA käytössä etuoikeutetuissa avainoperaatioissa?
- Kirjataanko etuoikeutetut toimet lokiin ja katselmoidaanko ne?
Vaihe 4: Kerää viisi näyttötallennetta
Kerää viisi tallennetta, jotka osoittavat hallintakeinon toimivan:
- Avaimen luonti- tai tuontiloki.
- Nykyinen KMS- tai HSM-pääsypolitiikka.
- Viimeisimmän avainten kierron muutospyyntö.
- SIEM-kysely, joka näyttää avaimen käytön tai hallinnolliset toimet.
- Palautus- tai restore-testin näyttö.
Vaihe 5: Kytke riskiin ja sääntelyyn
Lisää lyhyt riskikuvaus: ”Tämän avaimen luvaton käyttö tai menetys voisi altistaa EU:n henkilötietoja, häiritä asiakaspalvelua ja heikentää kriittisten järjestelmien palautuskykyä.” Kytke se sitten asiaankuuluviin velvoitteisiin.
| Velvoite | Mitä näyttö tukee |
|---|---|
| ISO/IEC 27001:2022 kohdat 6 ja 8 | Riskien käsittely, operatiivinen hallinta, dokumentoidut tulokset |
| ISO/IEC 27002:2022 8.24 | Kryptografian hyväksytty käyttö ja avainten elinkaaren hallinta |
| NIS2 Article 21 | Kryptografia- ja salauskäytännöt, kyberhygienia, pääsynhallinta, omaisuudenhallinta |
| DORA Articles 5, 6, 17, 28 ja 30 | ICT-hallinnointi, ICT-riskien viitekehys, poikkeamaprosessi, kolmansien osapuolten riippuvuudet ja sopimukset |
| GDPR Article 5 ja Article 32 | Osoitusvelvollisuus, eheys ja luottamuksellisuus, käsittelyn turvallisuus |
| NIST CSF 2.0 | Omaisuuserien tunnistaminen, tietojen suojaaminen, poikkeamien havaitseminen, reagointi ja palautuminen |
90 minuutissa tiimi voi yleensä tunnistaa, onko avaintenhallinta todellista vai oletuksiin perustuvaa.
Poikkeamien ilmoittaminen: milloin avaimen vaarantuminen käynnistää kellon
Epäilty avaimen vaarantuminen ei automaattisesti ole ilmoitettava tietoturvaloukkaus, mutta se voi käynnistää sääntelyaikataulun.
NIS2:n mukaan välttämättömien ja tärkeiden toimijoiden tulee ilmoittaa palvelun tarjoamiseen vaikuttavista merkittävistä poikkeamista ilman aiheetonta viivytystä. Vaiheistettu malli sisältää varhaisvaroituksen 24 tunnin kuluessa tietoisuudesta, poikkeamailmoituksen 72 tunnin kuluessa, tilapäivitykset pyydettäessä ja loppuraportin viimeistään kuukauden kuluttua poikkeamailmoituksesta.
DORA:n mukaan finanssitoimijoiden tulee havaita, hallita ja ilmoittaa ICT:hen liittyvät poikkeamat, kirjata poikkeamat ja merkittävät kyberuhat, luokitella poikkeamat vakavuuden ja vaikutuksen kohteena olevan palvelun kriittisyyden perusteella, viestiä sidosryhmille, raportoida merkittävistä poikkeamista ylimmälle johdolle ja toimivaltaisille viranomaisille, tehdä juurisyyanalyysi ja toteuttaa korjaavat toimenpiteet. Raportoinnin ulkoistaminen voi olla mahdollista, mutta vastuu säilyy finanssitoimijalla.
GDPR:n osalta kysymys on, tapahtuiko henkilötietojen tietoturvaloukkaus eli henkilötietojen vahingossa tapahtunut tai lainvastainen tuhoaminen, häviäminen, muuttaminen, luvaton luovuttaminen tai luvaton pääsy henkilötietoihin. Vahva salaus vaarantumattomilla avaimilla voi olennaisesti muuttaa loukkausriskin analyysiä. Heikko avaintenhallinta voi murentaa tämän perustelun.
Avaimen vaarantumisen pelikirjojen tulee määrittää:
- Miten epäilty avaimen paljastuminen havaitaan.
- Kuka julistaa kryptografisen poikkeaman.
- Miten vaikutuksen kohteena olevat tiedot, palvelut, asiakkaat ja lainkäyttöalueet tunnistetaan.
- Miten avaimet perutaan tai kierretään.
- Miten riippuvat järjestelmät palautetaan.
- Miten todistusaineiston eheys säilytetään.
- Miten oikeudelliset, sääntelyyn liittyvät ja asiakasilmoituksia koskevat päätökset tehdään.
Avaintenhallintarekisteristä tulee tässä prosessissa välttämätön. Ilman sitä reagointitiimit käyttävät aikaa sen selvittämiseen, mitä avain suojasi. Sen avulla vaikutusalue voidaan rajata nopeasti.
Auditointinäkökulma: yksi hallintakeinokokonaisuus, monta näytön käyttäjää
Eri auditoijat lähestyvät kryptografisten avainten hallintaa eri taustoista, mutta he päätyvät samaan näyttöön.
| Auditoijan näkökulma | Todennäköinen auditointikysymys | Toimiva näyttö |
|---|---|---|
| ISO/IEC 27001:2022 -auditoija | Onko kryptografisten avainten hallinta valittu riskien käsittelyn kautta, dokumentoitu soveltuvuuslausunnossa ja toimiiko se suunnitellusti? | Riskien arviointi, soveltuvuuslausunto, kryptografiapolitiikka, avaintenhallintarekisteri, kiertotallenteet |
| NIST CSF -arvioija | Onko kryptografiset omaisuuserät tunnistettu, suojattu, valvottu ja palautettavissa? | Omaisuus- ja tietoaineistoinventaariot, pääsynhallinta, KMS-lokit, SIEM-hälytykset, reagointi- ja palautustallenteet |
| DORA-auditoija | Ovatko avainriippuvuudet osa ICT-riskienhallintaa, kolmansien osapuolten valvontaa, häiriönsietokyvyn testausta ja poikkeamien raportointia? | ICT-riskien viitekehys, kolmansien osapuolten rekisteri, pilvi-KMS-sopimukset, jatkuvuustestit, poikkeamien luokitteluprosessi |
| GDPR-arvioija | Pienentääkö salaus rekisteröityihin kohdistuvaa riskiä, ja voiko rekisterinpitäjä osoittaa osoitusvelvollisuuden toteutumisen? | Tietojen luokittelu, avainten eriyttäminen, käyttölokit, salaussuunnittelu, tietoturvaloukkauksen riskinarviointi |
| ISACA- tai COBIT 2019 -auditoija | Onko hallinnointitavoitteet, riskinomistajuus, hallintakeinojen suorituskyky ja johdon vastuuvelvollisuus määritetty? | RACI, hallintakeinomittarit, johdon katselmointi, poikkeusrekisteri, auditoinnin korjausten seuranta |
Vahva auditointipaketti kryptografisten avainten hallinnalle sisältää yleensä:
- Hyväksytty Kryptografisten hallintakeinojen politiikka.
- Hyväksytty Pilvipalvelujen käyttöpolitiikka, kun pilvisalaus on relevanttia.
- Kryptografiastandardi ja algoritmiluettelo.
- Avaintenhallintarekisteri.
- Varmenteiden ja salaisuuksien inventaario.
- KMS-, HSM- ja holviarkkitehtuuri.
- IAM- ja etuoikeutettujen käyttöoikeuksien katselmointien näyttö.
- Kierto- ja perumistallenteet.
- Varmuuskopiointi-, escrow- ja palautustestien näyttö.
- Lokitus- ja valvontasäännöt avaintoiminnalle.
- Toimittajien ja pilven jaetun vastuun kartoitus.
- Poikkeamapelikirja epäiltyä avaimen vaarantumista varten.
- Poikkeukset ja riskien hyväksynnät.
- Johdon katselmointi ja auditoinnin korjaustallenteet.
Tämä paketti muuttaa hallintakeinoväitteen todisteeksi.
Yleiset havainnot avaintenhallinnan auditoinneissa
Yleisimmät havainnot ovat vältettävissä:
- Avaimista, varmenteista ja kryptografisista työkaluista ei ole yhtä yhteistä inventaariota.
- Pilvipalveluntarjoajan oletussalausta pidetään täydellisenä avaintenhallintana.
- Tuotantoavaimille ei ole nimetty omistajaa tai vastuuhenkilöä.
- Kierto on olemassa varmenteille, mutta ei sovellusavaimille tai tietokantojen CMK-avaimille.
- Salaisuudet ja avaimet ovat samassa holvissa ilman luokittelua.
- Kehittäjät voivat luoda avaimia hyväksyttyjen mallien ulkopuolella.
- Ei ole näyttöä siitä, että KMS-ylläpitäjien käyttöoikeuksia katselmoidaan.
- Palautusmenettelyt ovat olemassa, mutta niitä ei ole koskaan testattu.
- Avaimen vaarantumista ei ole sisällytetty tietoturvapoikkeamiin reagoinnin pelikirjoihin.
- Legacy-algoritmit jäävät sisäisiin palveluihin, koska kukaan ei omista korjaamista.
- BYOK-sitoumuksia tehdään asiakassopimuksissa, mutta ne eivät näy operatiivisessa toiminnassa.
- Toimittajan hallinnoimaa salausta ei sisällytetä toimittajariskien katselmointeihin.
Jokainen havainto palautuu hallinnointiin. Siksi kryptografiaa ei voida käsitellä puhtaasti teknisenä kehitysprojektina. Sen tulee kytkeytyä ISMS:n soveltamisalaan, riskien käsittelyyn, politiikkaan, toimittajiin, pilveen, pääsyyn, lokitukseen, poikkeamiin ja jatkuvuuteen.
Tee avaintenhallinnasta auditointivalmista ennen seuraavaa poikkeamaa
Jos organisaatiosi valmistautuu NIS2:een, DORA:an, GDPR Article 32:n mukaiseen näyttöön, ISO/IEC 27001:2022 -sertifiointiin tai post-kvanttiseen kryptografiseen ketteryyteen, aloita yhdellä kysymyksellä: pystyttekö tuottamaan täydellisen avaintenhallintarekisterin tänään?
Jos ette, Clarysec voi auttaa rakentamaan sen ympärille hallintakeinojärjestelmän.
Käytä Zenith Blueprint -opasta Zenith Blueprint työn jäsentämiseen riskienhallintavaiheen vaiheen 14 ja hallintakeinojen käyttöönoton vaiheen 20 kautta. Käytä Zenith Controls -opasta Zenith Controls ISO/IEC 27002:2022 -hallintakeinojen 8.24, 5.17 ja 5.23 kartoittamiseen NIS2:n, DORA:n, GDPR:n, NIST:n ja auditointiodotusten yli. Käytä Clarysecin Kryptografisten hallintakeinojen politiikkaa Kryptografisten hallintakeinojen politiikka, Kryptografisten hallintakeinojen politiikka SME:tä Kryptografisten hallintakeinojen politiikka SME ja Pilvipalvelujen käyttöpolitiikkaa Pilvipalvelujen käyttöpolitiikka vaatimusten muuttamiseen operatiivisiksi säännöiksi.
Käytännön seuraava askel on yksinkertainen: valitse yksi kriittinen palvelu, inventoi sen avaimet, osoita omistajuus, tarkista käyttöoikeudet, kerää kiertonäyttö ja testaa palautus. Jos tähän menee yli päivä, kryptografinen hallinnointinne tarvitsee huomiota ennen kuin viranomainen, auditoija tai tietoturvapoikkeamiin reagointitiimi esittää saman kysymyksen paineen alla.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
