O politică de parole și autentificare stabilește cum sunt create, folosite, recuperate și retrase conturile care pot accesa date personale. Ea trebuie să acopere angajații, administratorii, furnizorii și conturile tehnice. O cerință despre lungimea parolei, singură, nu tratează recuperarea abuzivă a contului, accesul rămas după plecare ori secretele copiate în fișiere comune.
Articolul 32 RGPD cere măsuri de securitate adecvate riscului, fără a fixa o lungime universală a parolei ori un interval unic de schimbare. Alegerile tehnice trebuie justificate pentru sistemele și amenințările organizației și revizuite când contextul se schimbă. RGPD, articolul 32. Modelul de mai jos propune o structură operațională, nu o listă exhaustivă de standarde tehnice.
Model de politică completabilă
Domeniu: [aplicații, dispozitive, conturi umane și conturi tehnice acoperite].
Identificare: fiecare persoană utilizează un cont individual, cu rol aprobat. [Procedura pentru situațiile în care un cont comun nu poate fi eliminat imediat].
Parole: [cerințe potrivite sistemului, mecanism de evitare a parolelor compromise și soluție autorizată de păstrare]. Parolele nu sunt trimise prin canale neaprobate și nu sunt incluse în documentație ori jurnale.
Autentificare suplimentară: [conturile și situațiile pentru care se aplică, metode aprobate și gestionarea excepțiilor].
Recuperare: [verificarea identității, persoane autorizate, retragerea sesiunilor și informarea titularului].
Conturi privilegiate: [separare de utilizarea obișnuită, autorizare, urmărire și acces de urgență].
Încetarea accesului: [declanșatoare, responsabil, termen operațional potrivit riscului și verificare].
Incidente: [canal de alertă și acțiunile pentru suspiciunea compromiterii]. Versiune [data], proprietar [funcție].
Completați valorile tehnice prin analiza sistemului, nu prin copierea unei cifre prezentate ca „cerință GDPR”. O regulă imposibil de folosit poate conduce la reutilizare, notare nesigură și soluții ocolitoare. Verificați capacitățile aplicației și explicați angajaților mecanismele autorizate, inclusiv cum primesc ajutor fără să divulge parola.
Matricea conturilor
| Tip de cont | Control principal | Dovadă de verificat |
|---|---|---|
| Utilizator obișnuit | Identitate individuală și acces după atribuții | Lista rolurilor și aprobarea managerului |
| Administrator | Acces privilegiat separat și protecție suplimentară adecvată | Configurație, titular și revizuire a privilegiilor |
| Furnizor | Acces delimitat la serviciul și perioada necesare | Aprobare, jurnal și confirmarea retragerii |
| Cont tehnic | Secret gestionat controlat și permisiuni limitate | Proprietar, destinație și procedură de înlocuire |
| Acces de urgență | Utilizare excepțională documentată | Motiv, persoană, evenimente și verificare după folosire |
| Cont inactiv | Dezactivare ori eliminare potrivit regulii aprobate | Inventar reconciliat cu situația personalului |
Un cont tehnic fără proprietar devine dificil de schimbat fără a întrerupe serviciul. Inventariați cine îl folosește, ce operațiuni permite și unde este păstrat secretul. Evitați atribuirea unor drepturi administrative doar pentru a face o integrare să funcționeze mai repede; identificați permisiunile minime necesare și verificați dependențele.
Exemplu ipotetic: furnizor de mentenanță
O organizație fictivă oferă unui prestator acces la o aplicație cu date ale clienților. Inițial, trei tehnicieni folosesc aceeași parolă transmisă prin e-mail. Organizația nu poate stabili cine a efectuat modificările și nu știe dacă foști colaboratori mai cunosc parola. Politica nouă prevede conturi individuale și acordarea accesului pentru intervenții aprobate.
Administratorul configurează protecția suplimentară disponibilă, limitează privilegiile și verifică jurnalizarea operațiunilor relevante. Pentru o intervenție simulată, tehnicianul poate realiza mentenanța autorizată, dar nu poate exporta baza de date completă. După închiderea lucrării, accesul temporar este retras și rezultatul este confirmat.
O aplicație veche nu acceptă aceeași metodă de autentificare. Excepția este documentată cu riscul, restricțiile compensatorii și planul de înlocuire. Ea nu este numită „conformă” doar pentru că managerul a semnat. Dacă protecțiile nu sunt adecvate riscului, organizația trebuie să schimbe modul de acces ori să renunțe la utilizarea respectivă.
Recuperarea contului, punctul care trebuie exersat
Definiți cum confirmă echipa de suport identitatea solicitantului. Informațiile ușor disponibile public nu trebuie tratate automat drept dovadă suficientă pentru un cont sensibil. Nu trimiteți parola existentă; sistemul trebuie să permită un mecanism sigur de resetare ori recuperare potrivit arhitecturii sale.
Analizați ce se întâmplă cu sesiunile active și metodele suplimentare după resetare. Un atacator poate păstra accesul dacă se schimbă parola, dar sesiunea sa rămâne validă. În situații de suspiciune, coordonați retragerea sesiunilor, verificarea modificărilor și evaluarea unui posibil incident de date, fără a presupune că schimbarea parolei închide investigația.
Parole, secrete și instruire
Oferiți o soluție autorizată pentru gestionarea secretelor și instrucțiuni clare pentru partajarea excepțională. Parolele nu trebuie depozitate în tichete de suport, foi de calcul comune, capturi de ecran ori cod sursă. Dacă un secret a fost expus, eliminarea mesajului nu garantează că nu a fost copiat; procedura trebuie să trateze înlocuirea și verificarea accesului.
Explicați diferența dintre parola unui utilizator și cheile unei integrări. Schimbarea primeia poate afecta o singură persoană; schimbarea celei de-a doua poate întrerupe mai multe servicii. Planificați înlocuirea secretelor tehnice cu proprietarii dependențelor, păstrând o evidență a rezultatului și evitând includerea valorilor secrete în raport.
Intrare, schimbare de rol și plecare
Corelați inventarul conturilor cu situația personalului și a furnizorilor. La schimbarea rolului, retrageți drepturile vechi care nu mai sunt necesare. La plecare, verificați aplicațiile care nu folosesc autentificarea centrală, conturile locale și accesul la spații de fișiere. Dezactivarea unui singur cont central poate lăsa integrări ori sesiuni active.
Stabiliți un mecanism pentru absențe și urgențe care nu impune partajarea parolei personale. Delegarea autorizată sau accesul de urgență documentat oferă o cale mai controlabilă. După folosire, revizuiți operațiunile și retrageți drepturile temporare, păstrând motivul și persoana care a aprobat intervenția.
Probe și revizuire
Pentru un eșantion de conturi, verificați titularul, rolul, protecțiile active și ultima justificare a accesului. Simulați recuperarea cu date fictive și retragerea unui utilizator de probă. Verificați că persoana de suport nu cere parola și că mesajele de recuperare nu dezvăluie informații inutile.
ANSPDCP recomandă măsuri organizatorice, instruire și verificarea eficacității securității. Ghidul orientativ ANSPDCP. Păstrați rezultatele și tratați excepțiile ca acțiuni urmărite. Revizuiți politica la introducerea unei aplicații, după compromiterea unui cont ori când mecanismele tehnice disponibile se schimbă. Criteriul de succes este accesul controlat pe întreg ciclul contului, inclusiv atunci când lucrurile nu decurg normal.
Confirmarea accesului furnizorilor
La încetarea contractului, cereți proprietarului serviciului să identifice toate conturile și cheile acordate prestatorului. Verificați retragerea în fiecare aplicație relevantă și păstrați confirmarea administratorului. O clauză de confidențialitate care continuă după încetare nu substituie eliminarea accesului tehnic. Includeți și conturile create de prestator în timpul intervențiilor autorizate.
Documente conexe pentru aplicare
Folosiți documentele de mai jos pentru operațiunile care se întâlnesc în acest dosar. Păstrați același identificator al activității atunci când transferați informațiile între evidențe, pentru a putea explica diferențele dintre versiuni.