Autentificare multifactorială, adesea denumită MFA, este o a doua verificare pe lângă parolă: un cod dintr-o aplicație, un SMS sau o cheie fizică. Dacă acest lucru este obligatoriu pentru o companie de software nu poate fi răspuns cu un simplu da sau nu, deoarece Directiva NIS2 nu prescrie o tehnică specifică. Articolul 21 obliga organizațiile care se încadrează în obligația de diligență să adopte măsuri adecvate pentru protecția accesului și autentificarea multifactorială, iar autoritățile de supraveghere evaluează locurile în care riscul este cel mai mare.
Pentru o companie de software, acestea sunt în practică două locuri foarte diferite: linia de dezvoltare cu care lucrați dvs., și software-ul pe care îl livrez clienților. Fiecare necesită o evaluare proprie, și acea evaluare nu este la fel de strictă peste tot.
Două locuri în care autentificarea multifactorială joacă un rol
Primul loc este intern: mediul în care lucrează dezvoltatorii dvs. Codul sursă, linia de dezvoltare, consolele cloud și sistemele cu care implementați în producție. Al doilea loc se află în produs însuși: dacă software-ul pe care îl construiți sau livrați are o ecran de autentificare, autentificarea multifactorială este și acolo un subiect, atât pentru utilizatorii dvs. proprii cât și pentru utilizatorii finali ai clientului dvs. Un chestionar de securitate de la o parte care plătește întreabă aproape întotdeauna despre amândouă, adesea în întrebări separate care sunt formulate ușor diferit de cum ați aștepta.
La accesul la linia dvs. de dezvoltare
Aici sunt cele mai mari așteptări. Cine poate accesa codul sursă, cine poate implementa în producție și cine are drepturi administrative în mediul cloud formează cel mai mare risc dacă o parolă este doar furată sau refolosită. Pentru aceste conturi, autentificarea multifactorială în aproape fiecare cadru de securitate este o măsură de bază, și este și ceea ce autoritățile de supraveghere și clienții aștept în primul rând. Controlul versiunilor, linia de dezvoltare însuși și în special fiecare cont cu drepturi de a aduce codul în producție ar trebui în practică fără excepție să stea în spatele unui al doilea pas.
De aceea este important și o privire la cine are de fapt nevoie de acel acces. Un dosar în care pentru fiecare sistem este specificat cine poate accesa și de ce face mai ușor să răspundeți la această întrebare într-un chestionar cu un răspuns concret în loc de cu o presupunere. cum controlul accesului și autentificarea multifactorială sunt explicate per subiect oferă un punct de plecare pentru aceasta.
Pentru software-ul pe care îl livrați
Al doilea plan este software-ul însuși. Dacă produsul dvs. are o funcție de autentificare, întrebarea dacă oferiți autentificare multifactorială apare aproape întotdeauna într-un chestionar de securitate și uneori chiar ca o cerință contractuală. Aceasta este o evaluare diferită de cea a liniei dvs. de dezvoltare: aici nu este vorba despre ceea ce utilizați dvs. înșivă, ci despre ceea ce livrați clientului dvs. Un plătitor care se încadrează însuși în obligația de diligență trebuie conform articolului 21 să evalueze și lanțul său, iar întrebarea dacă produsul dvs. acceptă autentificarea puternică face parte din aceasta.
Răspunsul nu trebuie să fie că este obligatoriu activat peste tot. Adesea este suficient să arătați că posibilitatea există, că utilizatorii sunt încurajați să o folosească și că aveți un plan pentru a o extinde acolo unde riscul o justifică.
Unde este mai puțin evident
Nu orice cont sau mediu solicită aceeași grad de rigoare. Un mediu de testare fără date reale ale clienților, un sistem intern de documentație doar cu drepturi de citire, sau un instrument separat pe care un dezvoltator îl folosește ocazional, se cântăresc diferit decât un cont cu acces la producție. Obligația de diligență cere măsuri proporționale cu riscurile, nu aplicarea uniformă a unui nivel de protecție identic peste tot. Autoritățile de supraveghere evaluează aceasta pe baza proporționalității, ceea ce înseamnă că o decizie bine justificată de a nu aplica autentificarea multiplă într-un anumit loc poate fi la fel de valabilă într-un dosar ca și locurile în care aceasta este implementată.
Justificarea este cuvântul cel mai important aici. O decizie fără explicație pare ușor o omisiune într-un chestionar, în timp ce aceeași decizie însoțită de o scurtă motivație este adesea exact răspunsul pe care un client îl caută.
Ce înseamnă aceasta pentru discuția cu un client
Un client care trimite un chestionar de obicei nu dorește să știe dacă conformați cu fiecare detaliu, ci dacă cunoașteți riscurile și le gestionați în cunoștință de cauză. Pentru autentificarea multiplă, aceasta înseamnă: a putea prezenta ce se găsește în ruta de dezvoltare, ce se găsește în produs și de ce restul este configurat diferit. Cine a documentat aceasta per sistem cu o stare și un proprietar, nu trebuie să redescopere răspunsul de fiecare dată când sosește următorul chestionar.
Cum și dacă aceasta se aplică exact organizației dumneavoastră depinde de rolul dumneavoastră în lanț și de ceea ce clienții solicit specific; în caz de îndoială, consultați textul directivei însuși sau un consultant. Dacă doriți mai întâi să aflați unde vă situați, verificarea gratuită în câteva întrebări oferă o primă indicație, și o explicație privind sursa informației arată cum s-a ajuns la acea indicație.
Dacă doriți să citiți mai mult cum se conectează acest subiect cu alte măsuri din obligația de diligență, veți găsi aceasta în prezentarea generală a subiectelor după situație. Verificarea rapidă și baza de cunoștințe sunt accesibile gratuit, fără a fi nevoie să vă creați un cont.