Control acces ISO 27001: politica si implementare

Un administrator de sistem dintr-o firma de fintech din Cluj a plecat din companie vineri la ora 17. Luni dimineata, contul lui Active Directory inca functiona. Baza de date cu tranzactii, serverul de productie, repository-ul Git, toate accesibile cu aceleasi credentiale. Nimeni nu revocase drepturile de acces. Incidentul nu a fost descoperit decat dupa doua saptamani, cand un audit intern a verificat log-urile de autentificare.

Controlul accesului nu este o problema de software. Este o problema de politica, procedura si disciplina. ISO 27001:2022 dedica mai multe controale din Anexa A acestui subiect: A.5.15 (politica de control acces), A.5.18 (drepturi de acces), A.8.5 (autentificare securizata), A.7.2 (acces fizic). OUG 155/2024 (transpunerea Directivei NIS2) cere explicit firmelor vizate sa implementeze politici de control al accesului si autentificare multifactor.

De ce ai nevoie de o politica de control acces?

Fara o politica scrisa, fiecare departament isi face regulile proprii. IT-ul acorda drepturi pe baza de email sau cerere verbala, nimeni nu verifica periodic cine are acces la ce, iar la plecarea unui angajat se dezactiveaza contul de email si se uita restul.

Controlul A.5.15 din ISO 27001:2022 cere o politica documentata care stabileste regulile pentru accesul fizic si logic la informatii. Politica trebuie sa acopere cel putin:

  • Cine aproba acordarea accesului (nu cel care il si implementeaza)
  • Pe baza caror criterii se acorda (rolul in organizatie, nu cererea individuala)
  • Cum se revizuiesc periodic drepturile existente
  • Ce se intampla cand cineva isi schimba rolul sau paraseste firma
  • Regulile pentru acces de la distanta si pentru contractori

Aceasta politica este separata de politica generala de securitate a informatiei ceruta de clauza 5.2. Ambele sunt obligatorii, dar au scopuri diferite: prima stabileste directia generala, politica de control acces reglementeaza cine primeste acces, cum si cand.

Principiul celui mai mic privilegiu si matricea de acces

Controlul A.8.2 cere sa limitezi drepturile privilegiate la minimul necesar. In practica, asta inseamna ca un contabil nu are acces la serverul de productie, iar un dezvoltator nu vede datele financiare. Reducerea privilegiilor excesive poate micsora suprafata de atac cu pana la 80%.

Cel mai simplu instrument de implementare este matricea de acces. Grupezi utilizatorii pe roluri si documentezi ce resurse poate accesa fiecare rol.

RolERP ContabilitateServer productieRepository codEmailBackup admin
Director generalCitireCitireNuDaNu
ContabilCitire/ScriereNuNuDaNu
DezvoltatorNuCitire/ScriereCitire/ScriereDaNu
Administrator ITCitireCitire/ScriereCitireDaDa
Contractor externNuNuCitire (limitat)NuNu

Cand vine un angajat nou, ii atribui un rol din matrice. Cand isi schimba pozitia, ii actualizezi rolul. Cand pleaca, ii revoci tot. Matricea face auditabil tot procesul.

Autentificarea securizata si MFA

Controlul A.8.5 cere mecanisme de autentificare proportionale cu sensibilitatea datelor. Un cont de email intern nu are aceleasi cerinte ca accesul la baza de date cu tranzactii financiare.

Pentru sistemele cu date sensibile, ISO 27001 recomanda autentificare multifactor (MFA). OUG 155/2024 merge mai departe si o cere explicit: art. 10 mentioneaza “utilizarea solutiilor de autentificare multifactor sau de autentificare continua”. Daca firma ta intra sub incidenta NIS2 (furnizor de servicii digitale, infrastructura critica, sanatate, energie), MFA nu mai este optionala.

Concret, MFA inseamna combinarea a doua din trei elemente: ceva ce stii (parola), ceva ce ai (telefon, token fizic) si ceva ce esti (amprenta, recunoastere faciala). Solutii practice: Microsoft Authenticator sau Google Authenticator pentru aplicatii cloud, YubiKey pentru acces la servere critice.

Ce faci cand cineva pleaca din firma

Controlul A.5.18 din versiunea 2022 a adaugat cerinte noi fata de editia anterioara: drepturile temporare trebuie revocate imediat la terminarea contractului, iar orice modificare a drepturilor de acces trebuie documentata.

Sa zicem ca ai o firma de servicii IT cu 35 de angajati din Timisoara. Un project manager cu acces la platforma de ticketing, CRM-ul cu 2.400 de clienti, drive-ul partajat al echipei si VPN-ul companiei isi da demisia. Checklist-ul de off-boarding arata asa:

  1. Dezactiveaza contul Active Directory/SSO in ziua ultimei zile de lucru
  2. Revoca accesul la toate aplicatiile cloud (CRM, ticketing, drive partajat)
  3. Schimba parolele conturilor partajate la care a avut acces
  4. Recupereaza echipamentele fizice (laptop, token de acces, badge)
  5. Revoca accesul VPN si sterge certificatele digitale
  6. Verifica si anuleaza orice drepturi delegate (acces in numele altcuiva)
  7. Documenteaza tot procesul cu data si ora fiecarei actiuni

Termenul realist: toate actiunile din lista trebuie finalizate in maximum 24 de ore de la ultima zi de lucru. Daca amani, cresti riscul de acces neautorizat exact ca in exemplul de la inceput.

Revizuirea periodica a drepturilor

Nu e suficient sa configurezi drepturile o data. Controlul A.5.18 cere revizuire periodica. Frecventa depinde de nivelul de risc:

  • Conturile cu drepturi administrative: verificare lunara sau trimestriala
  • Accesul la date cu caracter personal (relevant si pentru GDPR art. 32): verificare trimestriala
  • Accesul la aplicatii de birou cu risc scazut: verificare anuala

La fiecare revizuire, verifici: mai exista acest cont? Persoana are inca nevoie de acest nivel de acces? Exista conturi partajate neautorizate? Rezultatele se documenteaza si se pastreaza ca dovada pentru audit.

Cerinte legale in Romania: OUG 155/2024 si GDPR

Controlul accesului nu este doar o cerinta ISO 27001. Doua reglementari din Romania il cer direct.

OUG 155/2024 (in vigoare din 30 decembrie 2024, transpune Directiva NIS2) obliga entitatile esentiale si importante sa implementeze politici de control al accesului si gestionare a activelor. DNSC (Directoratul National de Securitate Cibernetica) este autoritatea care monitorizeaza conformitatea.

GDPR, prin Articolul 32, cere masuri tehnice si organizatorice adecvate pentru securitatea datelor personale. Controlul accesului este una dintre acele masuri. ANSPDCP a aplicat in 2025 amenzi totale de 230.500 EUR firmelor din Romania pentru incalcari GDPR. Intr-un caz din 2026, o firma de software a primit o amenda de 14.929 lei (3.000 EUR) pentru incalcarea art. 32, inclusiv masuri inadecvate de securitate a datelor.

Daca implementezi controlul accesului conform ISO 27001, acoperi automat si cerintele din OUG 155/2024 si GDPR art. 32 legate de aceasta zona. Un singur set de politici si proceduri, trei cadre de conformitate acoperite.

Intrebari frecvente

Ce diferenta este intre politica de control acces si politica de securitate a informatiei?

Politica de securitate a informatiei (clauza 5.2) stabileste directia generala a SMSI: obiective, angajamente, domeniu de aplicare. Politica de control acces (controlul A.5.15) reglementeaza concret cine primeste acces la ce resurse, cum se aproba si cum se revoca.

Trebuie sa implementez MFA daca nu intru sub NIS2?

ISO 27001 nu impune MFA explicit, dar controlul A.8.5 cere autentificare proportionala cu riscul. Daca ai date sensibile (financiare, personale, medicale), un auditor va intreba de ce nu ai MFA. In practica, MFA a devenit standard pentru orice sistem accesibil de la distanta.

Cat de des trebuie sa revizuiesc drepturile de acces?

Depinde de risc. Conturile administrative, lunar sau trimestrial. Accesul la date personale, trimestrial. Restul, anual. Revizuirea trebuie documentata si pastrata ca dovada de audit conform Declaratiei de Aplicabilitate.