Politica de criptografie ISO 27001: controlul A.8.24

Controlul A.8.24 din ISO 27001:2022 cere o politica scrisa care stabileste cand folosesti criptografie, ce algoritmi accepti si cum gestionezi cheile. Inlocuieste fostele controale A.10.1.1 si A.10.1.2 din versiunea 2013 si este unul dintre cele mai verificate la audit, mai ales pentru firmele care prelucreaza date personale sau intra sub OUG 155/2024 (transpunerea NIS2).

Politica de criptografie nu este un document tehnic stufos. Este un ghid intern de 3-5 pagini care raspunde la trei intrebari: ce informatii cripteaza firma, cu ce algoritmi si cine raspunde de cheile criptografice.

Continutul minim al politicii de criptografie

Auditorul ISO 27001 verifica daca politica acopera concret urmatoarele puncte:

• Tipurile de informatii care trebuie criptate (date personale, parole, copii de siguranta, comunicare cu clientii)
• Algoritmii si lungimile de cheie acceptate, cu lista celor interzisi
• Modul de gestionare al cheilor pe tot ciclul de viata (generare, stocare, rotire, distrugere)
• Persoana responsabila de criptografie (de obicei seful IT sau ofiterul de securitate)
• Procedura cand o cheie este compromisa sau pierduta
• Lista exceptiilor: ce date nu se cripteaza si de ce

Politica face parte din setul de documente obligatorii pentru certificare, alaturi de Declaratia de Aplicabilitate si evaluarea de risc. In SoA, controlul A.8.24 este greu de exclus daca firma prelucreaza date personale sau financiare.

Trebuie sa cripteze tot ce inseamna informatie sensibila?

Nu. Standardul cere sa decizi pe baza riscului. Cripteaza ce e marcat ca fiind confidential sau secret in politica de clasificare a informatiilor, si ce circula in afara perimetrului tau (cloud, email, transferuri catre furnizori). Datele publice nu au nevoie de criptare.

Algoritmi si lungimi de cheie acceptate

Standardul nu impune o lista. Auditorul se uita la NIST SP 800-131A Rev.2 si la recomandarile BSI TR-02102-1 ca referinta. Tabelul urmator reflecta starea recomandata in 2026.

Tip operatie	Algoritmi acceptati	Algoritmi interzisi
Criptare simetrica	AES-128, AES-192, AES-256 (preferabil mod GCM)	DES, 3DES, RC4
Criptare asimetrica	RSA-OAEP minim 3072 biti, ECC pe P-256 sau P-384	RSA sub 2048 biti
Semnatura digitala	RSA-PSS minim 3072 biti, ECDSA P-256 sau P-384	RSA-PKCS1 v1.5 cu SHA-1
Functii de hash	SHA-256, SHA-384, SHA-512, SHA-3	MD5, SHA-1
Comunicatie in retea	TLS 1.3 (preferat) sau TLS 1.2 cu suite moderne	TLS 1.0, TLS 1.1, SSLv3
Stocare parole	Argon2id, bcrypt, scrypt, PBKDF2 cu peste 600.000 iteratii	Stocare in clar, MD5, SHA-1 fara salt

TLS 1.0 si 1.1 au fost depreciate oficial prin RFC 8996 in 2021. NIST a anuntat retragerea 3DES din 2023. Daca politica ta inca permite acesti algoritmi, auditorul emite neconformitate majora.

Pentru firmele care opereaza sub Regulamentul (UE) 2022/2554 (DORA, aplicabil din 17 ianuarie 2025), cerintele criptografice sunt mai stricte. La fel pentru institutiile financiare conform BNR Norma 4/2018.

Gestionarea cheilor pe ciclul de viata

Cheia este partea cea mai vulnerabila a oricarui sistem de criptare. Un AES-256 cu cheia salvata intr-un fisier text in repository-ul Git nu e criptografie, este teatru. Controlul A.8.24 cere sa documentezi cele 6 faze:

1. Generare. Foloseste un generator criptografic securizat. Nu Math.random(), nu hash dintr-o parola simpla. Pentru chei sensibile, generarea se face intr-un HSM sau intr-un KMS cloud (AWS KMS, Azure Key Vault, Google Cloud KMS).
2. Distribuire. Niciodata pe email in clar sau in mesaje de chat. Folosesti canale autentificate, scheme de schimb de cheie (Diffie-Hellman) sau seif comun cu drepturi separate.
3. Stocare. HSM, KMS cloud sau seif software cu MFA pe acces. Cheile master nu se afla niciodata pe acelasi server cu datele criptate.
4. Utilizare. Fiecare cheie are un scop unic declarat. Nu refolosesti cheia de criptare a bazei de date pentru a semna log-uri.
5. Rotire. La interval planificat sau imediat la suspiciune de compromitere. Pentru cheile master, anual sau la doi ani; pentru cheile de sesiune, la fiecare conexiune.
6. Distrugere. Zeroizare. Stergerea logica a unui fisier nu inseamna distrugere. Pe HSM, comanda de zeroizare scrie peste materialul cheie.

O firma de SaaS din Cluj cu 25 de angajati care opereaza o platforma de facturare electronica a primit o neconformitate la auditul de certificare pentru ca documentase doar fazele 1, 2 si 3. Procedura de rotire era pe email, “se va face cand simtim”, iar cheile vechi ramaneau pe serverul de backup. Auditorul a cerut completarea politicii cu cele 6 faze si introducerea unui jurnal cu data fiecarei rotiri si zeroizari.

Unde tin cheile criptografice, in software sau in HSM?

Pentru o firma cu sub 50 de angajati care nu are date financiare reglementate, un KMS cloud (AWS, Azure, GCP) acopera cerintele A.8.24 la cost de 50-200 EUR pe luna. HSM-ul fizic (15.000-40.000 EUR) se justifica pentru institutii financiare, autoritati de certificare digitala si firme care opereaza sub DORA. Auditorul accepta orice solutie care demonstreaza control si separare a accesului.

Cerinte legale: NIS2, GDPR si DORA

OUG 155/2024 (transpunerea Directivei NIS2, aprobata prin Legea 124/2025) cere la articolul 10 alineatul (2) folosirea de “politici si proceduri privind utilizarea criptografiei si, dupa caz, a criptarii”. Pentru entitatile esentiale, amenzile ajung la 10.000.000 EUR sau 2% din cifra de afaceri.

GDPR articolul 32(1)(a) numeste explicit criptarea ca masura tehnica adecvata pentru securitatea prelucrarii. ANSPDCP a aplicat in 2024-2025 amenzi pentru transmiterea de date personale fara criptare, mai multe vizand IMM-uri din IT si servicii.

DORA (Regulamentul UE 2022/2554, aplicabil din 17 ianuarie 2025) impune cerinte criptografice institutiilor financiare si tertelor parti ICT critice. Daca firma ta este furnizor de servicii cloud sau de procesare plati pentru o banca din Romania, BNR si ASF verifica direct conformitatea.

Implementarea corecta a controlului A.8.24 acopera simultan zona de criptografie din toate trei reglementarile.

Greseli frecvente la auditul controlului A.8.24

Cea mai comuna eroare: politica copiata dintr-un sablon englezesc, cu algoritmi declarati abstract (“se vor folosi algoritmi puternici”). Auditorul cere lista concreta. Daca scrii in politica “AES si RSA”, el intreaba ce lungime, ce mod de operare, ce padding. Fara raspuns, neconformitate.

A doua eroare: cheile in cod sursa. Un dezvoltator pune cheia API a serviciului de plati intr-un fisier de configuratie commitat in Git. La auditul tehnic, scanarea repository-ului gaseste materialul cheie. Reparatia: muta toate secretele in variabile de mediu sau intr-un manager de secrete (HashiCorp Vault, Doppler, AWS Secrets Manager) si revoca imediat cheile expuse.

A treia eroare: lipsa procedurii de rotire. Firma genereaza certificate TLS sau chei API la implementare si nu le mai schimba 5 ani. Procedura de rotire trebuie sa existe scrisa, cu un calendar si un responsabil. La audit, jurnalul de rotire este dovada functionala.

A patra eroare: criptare in tranzit ignorata. Datele se cripteaza la stocare, dar circula in clar pe SMTP intern sau pe API-uri HTTP. Controlul A.5.14 (Transferul informatiilor) si A.8.24 functioneaza impreuna; nu poti acoperi unul fara celalalt.

Cat de des trebuie sa rotesc cheile criptografice?

Depinde de tipul cheii. Cheile de sesiune TLS se rotesc automat la fiecare conexiune. Cheile de criptare a bazelor de date, anual sau la doi ani. Cheile de semnare cod, la 2-3 ani sau cand un angajat cu acces pleaca. Certificatele TLS publice, la maxim 13 luni (limita CA/Browser Forum din 2020). La orice suspiciune de compromitere, rotirea este imediata.