Mitmikverifitseerimine, sageli nimetatakse MFA-ks, on teene kontrollimine parooliõigusega: kood rakendusest, SMS-iga või füüsilise võtmega. Küsimus, kas see on kohustuslik tarkvarafirmale, ei saa vastata lihtsa jah või ei, sest NIS2-richtlijn ei näe ette konkreetset tehnikat. Artikkel 21 kohustab organisatsioone, mis kuuluvad hoolsusmääruse ulatusesse, võtma asjakohaseid meetmeid juurdepääsu kaitseks ja mitmikautentimiseks, ning järelvalvijad vaatavad, kus on risk kõige suurem.
Tarkvarafirma jaoks on see praktikas kaks väga erinevat kohta: arendustee, millega te ise töötate, ja tarkvara, mille te klientidele tarnitakse. Mõlemad nõuavad oma hinnangut, ja see hinnang ei ole kõikjal sama range.
Kaks kohta, kus mitmikverifitseerimine on oluline
Esimene koht on sisemine: keskkond, kus teie arendajad töötavad. Lähtekood, arenduslahendus, pilvekonsolid ja süsteemid, millega te tootmisse liigute. Teine koht on tootes endas: kui teie ehitatud või pakutava tarkvara kasutajaliideses on sisselogimise ekraan, on mitmikverifitseerimine ka seal teema, nii teie endi kasutajatele kui ka teie kliendi lõppkasutajatele. Tellijale kuuluva turvalahenduse küsimustik küsib peaaegu alati mõlemat, sageli eraldi küsimustena, mis on formuleeritud teisiti, kui te ootaksite.
Teie arendustee juurdepääsuks
Siin on tugevaim ootus. Kellel on juurdepääs lähtekoodile, kes saab tootmisse avaldada ja kellel on administraatoripäigused pilveülkonnas, moodustab suurima riski, kui parooli varastatakse või taaskasutatakse. Nende kontode puhul on mitmikverifitseerimine peaaegu igal turvalahenduse raamistikul alusmeetme ja see on ka see, mida järelvalvijad ja kliendid esmalt ootavad. Versioonihaldus, arenduslahendus ise ja eriti iga konto, millel on õigus kood tootmisse tuua, kuulub praktikas eranditult teise astme taha.
Sellega kaasneb ka pilk, kes tegelikult seda juurdepääsu veel vajab. Dokumendis, mis näitab iga süsteemi kohta, kes võib sinna juurde pääseda ja miks, on lihtsam vastata küsimustike küsimustele konkreetse vastusega rohkem oletuste asemel. kuidas juurdepääsu juhtimine ja mitmikverifitseerimine teema kaupa on seletatud annab selle jaoks alguspunkti.
Tarkvara puhul, mille te tarnite
Teine tasand on tarkvara ise. Kui teie toote sisselogimistegevus olemas, tuleb küsimus, kas pakute mitmikverifitseerimist, peaaegu alati küsimustikus tagasi, ja mõnikord isegi lepinguna. See on teistsugune hinnang kui teie enda arendustee: siin ei käi sellest, mida te ise kasutate, vaid sellest, mida te oma kliendile tarnitavate. Tellija, kes ise kuulub hoolsusmääruse alla, peab artikli 21 kohaselt hindama ka oma ketis, ja küsimus, kas teie toode toetab tugevat autentimist, kuulub sinna.
Vastus ei pea olema, et see on kõikjal kohustuslikult sisse lülitatud. Sageli piisab näitamisest, et võimalus on olemas, et kasutajaid soogitatakse seda kasutama, ja teil on plaan seda laiendada, kus risk seda õigustab.
Kus see on vähem enesestmõistetav
Mitte igal kontol või keskkonnale ei pea olema sama tase turvalisust. Testkeskkond ilma tõeliste klientandmeteta, sisemine dokumentatsioonisüsteem ainult lugemisõigusega või eraldiseisev tööriist, mida üks arendaja aeg-ajalt kasutab, on teistsuguse riskiga kui konto, millel on juurdepääs tootmiskeskkonnale. Küberturvalisuse eeskirjad nõuavad meetmeid, mis vastavad riskidele, mitte ühesuguse kõrge taseme rakendamist kõikjal. Järelevalveasutused hindavad seda proportsionaalsuse alusel, mis tähendab, et põhjendatud otsus, et kuskil mitmeastmelist autentimist ei kasutata, võib olla dossieesse kirjutatud täpselt niisama hästi kui kohad, kus seda kasutatakse.
Põhjendamine on siin kõige olulisem sõna. Valik ilma selgituseta näeb küsimustikus kiiresti välja kui puudus, samal ajal kui sama valik koos lühikese põhjendusega on sageli just see vastus, mida tellijale vaja on.
Mida see tähendab suhtlemisel tellijaga
Tellijat, kes küsimustiku saadab, tavaliselt ei huvita, kas te täidate iga tähe järgi nõuet, vaid kas teate, kus asuvad teie riskid ja kas te nendega teadlikult ümber käite. Mitmeastmelise autentimise puhul tähendab see: näidata, mis on arendusreal, mis on tootesüsteemis ja miks ülejäänu on teisiti korraldatud. Kes on seda süsteemi kaupa olekuga ja vastutavaga fikseerinud, pole pärast küsimustiku saamist vaja küsimust uuesti lahti otsida.
Kas ja kuidas see teie organisatsiooni jaoks täpselt välja kujuneb, sõltub teie rollist ahelas ja sellest, mida teie kliendid konkreetselt küsivad; kahtluse korral vaadake richtlini teksti ennast või pöörduge nõustaja poole. Kui soovite kõigepealt teada, kus te seisate, siis annab tasuta kontroll paar küsimusega esimese indikaatori, ja selgitus, kust informatsioon pärineb näitab, kuidas see indikaator tekkinud on.
Kui soovite lagemalt lugeda, kuidas see teema seostub teiste küberturvalisuse eeskirjade muude meetmete omavahel, leiate selle iga olukorra teemade ülevaates. Kiirbörsianalüüs ja teadmusbaas on vabalt kättesaadavad, ilma et peaksite selleks kontot looma.