Pregătire NIS2: urmărește schimbările de acces și dovezile lor

01

Pornește de la o întrebare concretă despre acces

Articolul 21 NIS2 include securitatea resurselor umane, politicile de control al accesului și administrarea activelor în măsurile de gestionare a riscurilor. Aplicabilitatea și implementarea națională se analizează separat. Fluxul de mai jos organizează tehnic deciziile și dovezile, fără să transforme un instrument într-o confirmare generală de conformitate.

02

Leagă persoanele și responsabilitățile de sisteme

Inventariază sistemele din primul scop și proprietarii lor de business. Include conturi obișnuite, administrative, identități operaționale comune și accesul furnizorilor. Exportul din directorul central este util, dar poate omite conturi create direct într-o aplicație sau administrate extern.

Pentru fiecare acces, păstrează persoana ori responsabilul, sistemul, rolul, motivul și aprobarea. Conturile de serviciu au nevoie de un proprietar operațional, chiar dacă nu aparțin unui angajat. Accesul temporar al furnizorului trebuie legat de colaborarea pe care o susține. Astfel se poate verifica dacă permisiunea mai are o justificare actuală.

03

Definește intrarea, schimbarea rolului și plecarea

Un coleg nou are nevoie de o cerere și de aprobarea potrivită înainte de acordarea accesului. Mutarea într-un alt rol cere verificarea permisiunilor vechi, nu doar adăugarea celor noi. Plecarea necesită o listă explicită de sisteme și responsabili pentru retragere.

Sursa evenimentului contează. HR poate confirma statutul angajatului, în timp ce responsabilul unui proiect știe când se termină colaborarea externă. Agrează cum intră aceste semnale în flux și cine corectează informația greșită. O actualizare eronată nu trebuie să retragă în tăcere acces critic, fără procedura convenită.

04

Separă aprobarea de executare

Aprobarea retragerii dovedește o decizie. Nu dovedește dezactivarea contului în toate sistemele. Păstrează rezultatul interfeței acceptate sau confirmarea operatorului, cu destinația și momentul operațiunii.

Unele sisteme permit automatizare, altele cer intervenție autorizată. Pot apărea în aceeași evidență dacă regula de finalizare este clară. Acțiunile eșuate rămân vizibile și repartizate. Lista centrală nu trebuie să arate complet doar fiindcă a trimis un e-mail proprietarului aplicației.

05

Pregătește excepțiile cu responsabilitate reală

Un inginer care pleacă poate fi responsabilul unei integrări automate. Dezactivarea contului personal poate opri integrarea, lăsând totuși activ un token separat. Identifică dependențele și numește un succesor înaintea tranziției aprobate. Păstrează motivul și persoana care acceptă o excepție temporară.

Accesul de urgență are nevoie de un traseu propriu. Înregistrează motivul, aprobarea și verificarea utilizării. Excepția fără responsabil și fără punct de revizuire poate deveni permanentă. Aplicația trebuie să arate verificările restante, fără să presupună că orice permisiune poate fi retrasă automat fără efecte operaționale.

06

Păstrează dovezi, fără să creezi un depozit de secrete

Registrul arată permisiuni și decizii, nu parole, chei private sau coduri de recuperare. Configurațiile sensibile rămân în sistemele controlate. Limitează accesul la inventarul complet, deoarece poate dezvălui conturi privilegiate și dependențe importante.

Datele de personal trebuie tratate potrivit scopului. Pentru responsabilitate este suficient uneori statutul schimbării, fără motivul confidențial al plecării. Stabilește exportul, păstrarea și accesul pentru suport cu responsabilii de securitate și protecția datelor. O dovadă utilă nu presupune expunerea întregului dosar HR.

07

Verifică rezultatul în destinații

Alege câteva sisteme și repetă angajarea, mutarea într-un departament, încheierea unei colaborări și o retragere eșuată. Include o aplicație din afara furnizorului central de identitate. Confirmă starea destinației prin metoda agreată, nu doar eticheta sarcinii.

Măsoară conturile fără responsabil, schimbările aprobate fără dovadă de executare și accesul rămas după momentul convenit. Notează problemele care cer modificarea procesului, nu doar cod. Repetarea exercițiului după remediere trebuie să arate dacă lipsurile identificate au fost rezolvate efectiv.

08

Fă verificarea parte din operare

Numește persoana care urmărește evenimentele nerezolvate și responsabilul fiecărui sistem. Revizuirea identifică cereri vechi, integrări deconectate și excepții care cer decizie. Rezumatul trebuie să conducă direct la dovada din spatele fiecărui caz.

La adăugarea unei aplicații sau schimbarea furnizorului, actualizează inventarul și testează acordarea și retragerea accesului. Un proces poate deveni incomplet fără o defecțiune tehnică, doar prin schimbarea organizației. Acoperirea sistemelor trebuie întreținută și modificările făcute vizibile.

• Alege un angajat care părăsește organizația și verifică starea contului în fiecare sistem din scop, inclusiv o aplicație din afara furnizorului central de identitate.
• Identifică un cont de serviciu sau o integrare automată aflată în responsabilitatea sa și confirmă succesorul, fără expunerea credențialelor în registrul de dovezi.
• Examinează o excepție de acces și verifică motivul, persoana care a aprobat-o, momentul revizuirii și ultima decizie păstrată.
• Confirmă că raportul de retragere deosebește aprobarea de executarea efectivă și arată acțiunile eșuate la destinație împreună cu responsabilul rezolvării.

09

Definește implementarea în jurul unei lipsuri cunoscute

RDC poate construi inventarul accesului, legăturile cu evenimentele HR sau contractuale, aprobările și colectarea dovezilor. Oferta poate începe cu sistemele în care schimbarea accesului este astăzi greu de verificat.

Sunt utile procedura existentă, lista aplicațiilor și cazuri anonimizate rămase deschise. Mapăm integrările acceptate, responsabilitățile manuale și testele de recepție. Consultanții juridici și de securitate stabilesc obligațiile aplicabile, iar implementarea face controalele alese mai ușor de operat și demonstrat.