Monivaiheinen todentaminen, usein MFA:ksi kutsuttu, on toinen tarkistus salasanan lisäksi: koodi sovelluksesta, tekstiviesti tai fyysinen avain. Kysymys siitä, onko tämä pakollista ohjelmistoyritykselle, ei ole vastattavissa yksinkertaisesti kyllä tai ei, koska NIS2-direktiivi ei määrää tiettyä tekniikkaa. Artikla 21 velvoittaa organisaatiot, jotka kuuluvat hoitovelvollisuuden piiriin, asianmukaisiin toimenpiteisiin pääsynvalvontaan ja monivaiheiseen todentamiseen, ja valvontaviranomaiset tarkastelevat, missä riski on suurin.
Ohjelmistoyrityksen kannalta se on käytännössä kaksi hyvin erilaista paikkaa: kehitysputki, jolla te itse työskentelet, ja ohjelmisto, jonka luovutatte asiakkaille. Molemmat edellyttävät omaa harkintaa, eikä harkinta ole kaikkialla yhtä tiukka.
Kaksi paikkaa, joissa monivaiheinen todentaminen on merkityksellinen
Ensimmäinen paikka on sisäinen: ympäristö, jossa kehittäjät työskentelevät. Lähdekoodi, kehitysputki, pilvipalvelun konsoolit ja järjestelmät, joilla voitte julkaista tuotantoon. Toinen paikka on itse tuotteessa: jos ohjelmistolla, jonka rakennatte tai toimitate, on kirjautumisruutu, monivaiheinen todentaminen on myös siellä aihe sekä omille käyttäjille että asiakkaanne loppukäyttäjille. Tilaajayhteisön turvallisuuskysymyslomake pyytää melkein aina vastaukset molempiin, usein erillisillä kysymyksillä, jotka on muotoiltu hieman eri tavalla kuin odottaisitte.
Kehitysputkeen pääsyn osalta
Odotus on tässä vahvin. Jos pääsee lähdekoodiin, jos voi julkaista tuotantoon ja jos on pilvialueella järjestelmänvalvojan oikeuksia, riski on suurin, jos salasana vain varastetaan tai käytetään uudelleen. Näille tileille monivaiheinen todentaminen on lähes kaikissa tietoturvaviitekehyksissä perustoimi, ja se on myös se, mitä valvontaviranomaiset ja asiakkaat odottavat ensin. Versioiden hallinta, kehitysputki itse ja erityisesti jokainen tili, jolla on oikeus viedä koodi tuotantoon, kuuluu käytännössä poikkeuksetta toisen vaiheen taakse.
Siihen liittyy myös katsaus siihen, kenen tuo pääsy vielä oikeasti tarvitsee. Dossie, jossa on jokaisen järjestelmän osalta merkitty, kuka saa päästä sinne ja miksi, tekee helpommaksi vastata tähän kysymykseen kysymyslomakkeessa konkreetilla vastauksella sen sijaan, että tekisitte oletuksen. miten pääsynvalvonta ja monivaiheinen todentaminen selitetään aiheittain antaa sille hyvän lähtöpisteen.
Ohjelmistosta, jonka toimitate
Toinen taso on itse ohjelmisto. Jos tuotteellanne on kirjautumistoiminto, kysymys siitä, tarjoatteko monivaiheista todentamista, palautuu melkein aina turvallisuuskysymyslomakkeessa, ja joskus jopa sopimuksellisena vaatimuksena. Se on eri harkinta kuin omassa kehitysputkessanne: tässä ei ole kyse siitä, mitä te itse käytätte, vaan siitä, mitä tarjoatte asiakkaallenne. Tilaaja, joka itse kuuluu hoitovelvollisuuden piiriin, on artiklassa 21 velvollinen arvioimaan myös ketjunsa, ja kysymys siitä, tukeeko tuotteenne vahvaa todentamista, kuuluu siihen.
Vastaus ei tarvitse olla, että se on pakollisesti päällä kaikkialla. Usein riittää osoittaa, että mahdollisuus on olemassa, että käyttäjiä kehotetaan käyttämään sitä, ja että teillä on suunnitelma sen laajentamiseksi silloin, kun riski sen oikeuttaa.
Missä se on vähemmän itsestään selvää
Kaikki tilit ja ympäristöt eivät vaadi samaa riskitasoa. Testiympäristö, jossa ei ole oikeitaasiakastietoja, sisäinen asiakirjajärjestelmä, jossa on vain lukuoikeudet, tai irrotettu työkalu, jota yksi kehittäjä käyttää satunnaisesti, on eri riskiluokassa kuin tili, jolla on tuotantokäyttöoikeus. Kyberturvallisuuden hallintavelvoite edellyttää toimenpiteitä, jotka vastaavat riskeihin, eikä kaikkiin paikkoihin samalla tavalla raskaiden kontrollien soveltamista. Valvontaviranomaiset arvioivat tämän suhteellisuusperiaatteen perusteella, ja se tarkoittaa, että perusteltu päätös olla soveltamatta monivaiheista todennusta jossakin paikassa voi olla yhtä hyvin osa dokumentointia kuin paikat, joissa se on käytössä.
Perustelun antaminen on tässä tärkein sana. Valinta ilman selitystä näyttää kyselylomakkeessa helposti puutteelta, kun taas sama valinta lyhyen perustelun kanssa on usein juuri vastaus, jota tilaaja etsii.
Mitä tämä merkitsee keskustelulle tilaajaorganisaation kanssa
Tilaaja, joka lähettää kyselylomakkeen, haluaa yleensä tietää, pysytkö jokaisen kohdan vaatimuksissa, vaan ymmärrätkö, missä riskisi sijaitsevat ja hallitsetko niitä tietoisesti. Monivaiheisen todennuksen osalta se tarkoittaa: pystyä näyttämään, mitä kehitysympäristöön on asetettu, mitä tuotteeseen on asetettu, ja miksi loput on järjestetty toisin. Jos olet dokumentoinut tämän järjestelmäkohtaisesti omistajien ja tilojen kanssa, sinun ei tarvitse etsiä vastausta uudelleen seuraavan kyselylomakkeen tullessa.
Se, miten ja missä määrin tämä vaikuttaa organisaatioosi, riippuu roolista toimitusketjussa ja siitä, mitä asiakkaasi erityisesti kyselevät; kysy epävarmuuden tapauksessa itse direktiivin teksteistä tai neuvonantajalta. Jos haluat ensin tietää, missä olet, ilmainen tarkistus muutamalla kysymyksellä antaa ensimmäisen osoituksen, ja selitysta sille, mistä tieto tulee näyttää, miten osoitus muodostuu.
Jos haluat laajemmin lukea, miten tämä aihe liittyy muihin kyberturvallisuuden hallintavelvoitteen toimenpiteisiin, löydät sen osoitteesta tilanteittain olevia aiheita käsittelevästä yleiskatsauksesta. Pika-arviointi ja tietovaranto ovat avoimesti saatavilla ilman, että sinun tarvitsee luoda tiliä.