A többfaktoros hitelesítés, gyakran MFA-nak genannt, egy második ellenőrzés a jelszó mellett: egy kód egy alkalmazásból, egy SMS vagy egy fizikai kulcs. Az a kérdés, hogy egy szoftvervállalatnak kötelező-e, nem igen vagy nem válasszal válaszolható meg, mivel a NIS2-irányelv nem írja elő a konkrét technikákat. A 21. cikk azonban kötelezi a szorgalmi kötelezettség alá tartozó szervezeteket a megfelelő intézkedésekre a hozzáférési biztonság és a többfaktoros hitelesítés terén, és a felügyeleti hatóságok azt nézik, hogy hol a legnagyobb a kockázat.
Egy szoftvervállalatnak a gyakorlatban ezt két nagyon eltérő helyen kell értékelnie: a saját fejlesztési folyamatban, és az ügyfeleknek szállított szoftverben. Mindkettőhöz saját mérlegelés szükséges, és ez a mérlegelés nem mindenütt egyforma szigor alá esik.
Két hely, ahol a többfaktoros hitelesítés szerepet játszik
Az első hely a belső: az a környezet, ahol a fejlesztőik dolgoznak. Forráskód, fejlesztési folyamat, felhőkonzolok és a rendszerek, amelyeken keresztül élesítésre küld. A második hely magában a termékben található: ha az Ön által épített vagy szállított szoftvernek van bejelentkezési képernyője, a többfaktoros hitelesítés ott is téma, mind az Ön saját felhasználói, mind az Ön ügyfele végfelhasználói számára. Egy megbízó biztonsági kérdőíve szinte mindig mindkettőt kérdezi meg, gyakran külön kérdésekben, amelyek másként vannak megfogalmazva, mint ahogy Ön várná.
A fejlesztési folyamatához való hozzáférésben
Itt van a legerősebb elvárás. Aki hozzáférhet a forráskódhoz, ki tud élesíteni, és kinek vannak rendszergazdai jogai a felhőkörnyezetben, az jelent a legnagyobb kockázatot, ha egy jelszó csak ellopásra vagy újrafelhasználásra kerül. Ezekhez a fiókokhoz a többfaktoros hitelesítés gyakorlatilag minden biztonsági keretrendszerben alapintézkedésnek számít, és ez is az első, amit a felügyeleti hatóságok és az ügyfelek várnak. A verziókontroll, maga a fejlesztési folyamat, és különösen minden olyan fiók, amely jogot ad a kód élesítésére, a gyakorlatban kivétel nélkül egy második lépés mögött van.
Ehhez tartozik az is, hogy megnézzük, kinek van valójában még szüksége erre a hozzáférésre. Egy dosszie, amely rendszerenként tartalmazza, hogy ki és miért férhet hozzá, megkönnyíti, hogy erre a kérdésre egy konkrét válasszal válaszoljunk egy kérdőívben, ahelyett, hogy feltételezésre utalnánk. hogyan magyarázható meg a hozzáféréskezelés és a többfaktoros hitelesítés témánként egy kiindulópontot nyújt ehhez.
Az Ön által szállított szoftverben
A második síkvetület maga a szoftver. Ha az Ön termékének van bejelentkezési funkciója, a többfaktoros hitelesítés nyújtásának kérdése szinte mindig visszatér egy biztonsági kérdőívben, és néha még szerződéses feltételként is. Ez egy másik mérlegelés, mint az Ön saját fejlesztési folyamata: itt nem arról van szó, amit Ön maga használ, hanem arról, amit szállít az ügyfelének. Az olyan megbízó, aki maga is a szorgalmi kötelezettség alá tartozik, a 21. cikk szerint kiterjesztenie kell az értékelést az ellátási láncra is, és az a kérdés, hogy az Ön terméke támogatja-e az erős hitelesítést, ide tartozik.
A válasz nem szükséges, hogy az mindenhol kötelezően be legyen kapcsolva. Gyakran elegendő annak igazolása, hogy a lehetőség létezik, a felhasználókat ösztönzik erre, és van egy terve annak kiterjesztésére, ahol a kockázat azt indokolja.
Ahol ez kevésbé magától értetődő
Nem minden fiók vagy környezet igényel ugyanolyan szigorúságot. Egy valódi ügyféladatok nélküli tesztkörnyezet, egy csak olvasási jogosultsággal rendelkező belső dokumentációs rendszer, vagy egy alkalmi eszköz, amelyet egy fejlesztő időnként használ, máshogy értékelendő, mint egy termelési hozzáféréssel rendelkező fiók. A gondossági kötelezettség olyan intézkedéseket igényel, amelyek megfelelnek a kockázatoknak, nem pedig mindenhová egyforma súlyos védelmet. A felügyeleti hatóságok ezt az arányosság alapján értékelik, ami azt jelenti, hogy egy alátámasztott döntés arra vonatkozóan, hogy valahol ne alkalmazzenek többtényezős hitelesítést, ugyanúgy része lehet egy dokumentációnak, mint azok a helyek, ahol ezt alkalmazzák.
Az alátámasztás itt a legfontosabb szó. Egy indoklás nélküli döntés egy kérdőívben könnyen hiányosságnak tűnik, míg ugyanez a döntés egy rövid magyarázattal gyakran pontosan az a válasz, amelyet a megrendelő keres.
Mit jelent ez a megrendelővel való beszélgetésben
Egy megrendelő, aki kérdőívet küld, általában nem azt szeretné megtudni, hogy Ön minden egyes követelménynek megfelel-e, hanem azt, hogy Ön ismeri-e a kockázatait, és tudatosan kezel-e velük. A többtényezős hitelesítés tekintetében ez azt jelenti: meg tudjuk mutatni, hogy mi van a fejlesztési sor szintjén, mi van a termékben, és miért van másképpen felépítve a többi rész. Aki ezt rendszerre lebontva dokumentálta az státusszal és a felelős személlyel, nem kell újra keresnie a választ, amint a következő kérdőív érkezik.
Hogy és hogyan fejt ki ezt pontosan az Ön szervezete, az függ az Ön szerepétől az értékláncban és attól, hogy ügyfeleik mit kérnek konkrétan; kétség esetén konzultáljon magával a direktívaszöveggel vagy egy tanácsadóval. Ha először szeretné megtudni, hogy hol áll, az ingyenes ellenőrzés néhány kérdésben egy első jelzést ad, és magyarázatot nyújt arról, hogy az információ honnan származik bemutatja, hogyan alakult ki az a jelzés.
Ha szélesebb körben szeretne olvasni, hogy ez a téma hogyan kapcsolódik a gondossági kötelezettségből eredő egyéb intézkedésekhez, a témák szituációnkénti áttekintésében találod megitt találhatja. A gyors vizsgálat és az ismeretbázis szabadon hozzáférhető, anélkül, hogy ehhez fiók szükséges lenne.