Gestionarea Secretelor Г®n Pipeline-urile CI/CD pentru ApДѓrare: Vault, HSM И™i RotaИ›ia Cheilor

Fiecare sistem de software pentru apărare depinde de secrete: certificate TLS care autentifică identitățile serviciilor, chei API care autorizează accesul la servicii externe, parole de baze de date care protejează datele operaționale, chei de criptare care protejează informațiile clasificate și chei de semnare a codului care verifică integritatea firmware-ului și software-ului. Dacă aceste secrete sunt gestionate neglijent — stocate în fișiere de configurare, introduse în depozitele de cod sursă, transmise ca variabile de mediu în text simplu sau lăsate neschimbate pe termen nedefinit — devin vectori de atac care ocolesc toate celelalte controale de securitate.

Gestionarea secretelor Г®n pipeline-urile CI/CD pentru apДѓrare nu se referДѓ Г®n primul rГўnd la prevenirea greИ™elilor dezvoltatorilor (deИ™i face И™i asta). Este vorba despre implementarea unei arhitecturi de securitate unde secretele nu sunt niciodatДѓ Г®n text simplu Г®n afara contextului lor de utilizare autorizat, unde fiecare utilizare a unui secret este auditatДѓ, unde secretele au durate de viaИ›Дѓ definite И™i sunt rotite automat, И™i unde compromiterea oricДѓrui secret individual are un raza de acИ›iune limitatДѓ din cauza expirДѓrii scurte И™i a accesului delimitat.

Tipuri de Secrete Г®n Pipeline-urile pentru ApДѓrare

Pipeline-urile CI/CD pentru apДѓrare Г®ntГўlnesc o varietate mai largДѓ de tipuri de secrete decГўt echivalentele comerciale, deoarece sistemele pe care le desfДѓИ™oarДѓ au cerinИ›e mai stricte de control al accesului И™i autentificare:

Certificatele TLS autentificДѓ identitДѓИ›ile serviciilor Г®n desfДѓИ™urДѓrile mTLS И™i protejeazДѓ comunicaИ›iile de reИ›ea. ГЋntr-un cluster Kubernetes pentru apДѓrare cu o plasДѓ de servicii, fiecare microserviciu are propriul certificat, potenИ›ial mii de certificate Г®n total, toate necesitГўnd rotaИ›ie Г®nainte de expirare.

Cheile API И™i token-urile de acces autorizeazДѓ apelurile serviciu-la-serviciu, accesul la fluxuri externe de informaИ›ii despre ameninИ›Дѓri, accesul la API-urile SIEM И™i integrarea cu backend-urile sistemelor clasificate. Acestea sunt de obicei secrete statice (nu generate dinamic) И™i sunt cele mai susceptibile sДѓ aparДѓ Г®n depozitele de cod sursДѓ prin eroarea dezvoltatorului.

Acreditările bazelor de date protejează accesul la bazele de date operaționale și clasificate. Acreditările statice ale bazelor de date — o pereche de nume de utilizator și parolă care nu se schimbă niciodată — reprezintă un risc semnificativ de securitate: dacă acreditarea este compromisă, accesul persistă până când acreditarea este rotită manual, ceea ce poate să nu se întâmple luni sau ani. Acreditările dinamice cu durate de viață scurte sunt semnificativ mai sigure.

Cheile de semnare a codului sunt utilizate pentru a semna lansările de software, imaginile de containere, pachetele de firmware și bundle-urile de configurare. Aceste chei sunt extrem de sensibile — o cheie de semnare a codului compromisă permite unui atacator să semneze cod malițios care va fi de încredere de toate sistemele care au încredere în cheie. Cheile de semnare a codului ar trebui protejate de hardware HSM și ar trebui să necesite autorizare multi-parte pentru utilizare.

HashiCorp Vault: Secrete Dinamice И™i Jurnal de Audit

HashiCorp Vault este platforma standard de gestionare a secretelor pentru mediile DevSecOps pentru apДѓrare. Vault oferДѓ un magazin centralizat, auditat pentru secrete, un API unificat pentru recuperarea secretelor И™i un motor de secrete dinamice care genereazДѓ acreditДѓri cu timp limitat, specifice scopului, Г®n loc sДѓ necesite ca aplicaИ›iile sДѓ stocheze secrete statice de lungДѓ duratДѓ.

Secretele dinamice sunt cea mai puternică caracteristică de securitate a Vault. În loc să stocheze o parolă statică de bază de date pe care aplicațiile o recuperează, Vault generează dinamic un nou utilizator de bază de date cu o acreditare limitată în timp de fiecare dată când o aplicație solicită acces. Acreditarea expiră automat și utilizatorul bazei de date este revocat după perioada de lease (de obicei 1–24 ore). Un atacator care captează o acreditare dinamică a bazei de date are o fereastră îngustă de exploatare înainte să expire; un atacator care captează o acreditare statică are acces pe termen nedefinit până când acreditarea este rotită manual.

Motoarele de secrete dinamice ale Vault acoperă PostgreSQL, MySQL, MSSQL, MongoDB, Cassandra, Elasticsearch (pentru gestionarea jurnalelor), PKI (emiterea certificatelor), AWS IAM (acreditările cloud) și altele. Pentru mediile de apărare, motorul de secrete PKI — care permite Vault să acționeze ca CA intermediar emitând certificate TLS de scurtă durată la cerere — este deosebit de valoros.

Jurnalul de audit al Vault Г®nregistreazДѓ fiecare apel API la Vault: fiecare cerere de secret, fiecare Г®ncercare de autentificare, fiecare cДѓutare de politicДѓ. Jurnalul de audit este numai-adДѓugare И™i nu poate fi modificat de administratorii Vault. Pentru mediile de apДѓrare, jurnalul de audit oferДѓ traseul de dovezi necesar pentru acreditare: cine a accesat ce secret, cГўnd И™i de la ce sistem.

Module de Securitate Hardware: CГўnd Vault bazat pe Software este Insuficient

HashiCorp Vault își securizează propriile chei de criptare (cheia master utilizată pentru a desigilă Vault și a cripta magazinul de secrete) folosind o abordare de criptare a cheilor bazată pe software. Pentru cele mai multe medii, aceasta este securitate adecvată. Pentru mediile de apărare cu cerințe FIPS 140-2 Nivel 3 — care se aplică Sistemelor de Securitate Națională și sistemelor care gestionează material de cheie criptografică clasificată — cheile root trebuie protejate de hardware, nu software.

FIPS 140-2 Nivel 3 necesitДѓ securitate fizicДѓ cu dovezi de manipulare, autentificare bazatДѓ pe identitate pentru operatori И™i parametri critici de securitate (chei private) care nu sunt exportaИ›i niciodatДѓ Г®n text simplu. Magazinele de chei bazate pe software, oricГўt de bine criptate ar fi, nu satisfac aceastДѓ cerinИ›Дѓ deoarece cheia de criptare Г®n sine existДѓ Г®n memoria software unde este potenИ›ial accesibilДѓ unui atacator cu privilegii software.

Auto-desigilarea HSM pentru Vault este arhitectura standard: cheia master a Vault este înfășurată de o cheie HSM, iar Vault se auto-desigilează trimițând cheia sa master înfășurată la HSM pentru desfășurare la pornire. HSM efectuează decriptarea în limita sa rezistentă la manipulare — cheia master nu există niciodată în text simplu în afara HSM. Această arhitectură satisface cerințele FIPS 140-2 Nivel 3 pentru stratul de protecție a cheii root.

Integrarea HSM suportată pentru HashiCorp Vault Enterprise include Thales (anterior SafeNet) Luna, nCipher nShield, AWS CloudHSM și Azure Dedicated HSM. Pentru mediile de apărare air-gapped, opțiunile HSM on-premises (Thales Luna, nCipher nShield) sunt necesare — serviciile HSM bazate pe cloud nu sunt accesibile din rețele air-gapped.

RotaИ›ia Cheilor fДѓrДѓ Timp de NefuncИ›ionare

Rotația cheilor — înlocuirea unei chei criptografice existente cu una nouă — este esențială pentru igiena securității: limitează fereastra de expunere dacă o cheie este compromisă și satisface cerințele de reglementare pentru limitele de durata de viață a cheilor. Dar rotația cheilor care necesită timp de nefuncționare al aplicației sau coordonare manuală complexă este adesea amânată pe termen nedefinit, negând valoarea sa de securitate.

Versionarea cheilor Vault permite rotaИ›ia fДѓrДѓ timp de nefuncИ›ionare pentru secrete И™i chei de criptare. CГўnd motorul de criptare Г®n tranzit al Vault (care oferДѓ criptare-ca-serviciu pentru aplicaИ›ii) roteИ™te o cheie, creeazДѓ o versiune nouДѓ a cheii pДѓstrГўnd Г®n acelaИ™i timp versiunile mai vechi pentru decriptarea datelor criptate cu versiunile anterioare. AplicaИ›iile care cripteazДѓ date noi folosesc versiunea curentДѓ a cheii; textul cifrat existent poate fi Г®n continuare decriptat folosind versiunea veche pГўnДѓ cГўnd aplicaИ›ia este actualizatДѓ pentru a-l recripta.

Perioadele de graИ›ie pentru rotaИ›ia certificatelor permit distribuirea treptatДѓ a certificatelor noi: noul certificat este distribuit И™i de Г®ncredere Г®nainte ca certificatul vechi sДѓ fie revocat, astfel Г®ncГўt sДѓ nu existe o fereastrДѓ Г®n care unele servicii au noul certificat iar altele nu l-au primit Г®ncДѓ.

Integrarea CI/CD: Tipare de Injectare a Secretelor

Secretele trebuie sДѓ ajungДѓ la aplicaИ›iile И™i componentele de infrastructurДѓ care au nevoie de ele fДѓrДѓ a fi expuse Г®n jurnalele pipeline-urilor CI/CD, dump-urile de variabile de mediu sau straturile de imagini de containere. Trei tipare de integrare dominДѓ mediile CI/CD pentru apДѓrare:

Vault agent sidecar (în Kubernetes) desfășoară un container Vault Agent alături de containerul aplicației. Vault Agent se autentifică la Vault folosind identitatea contului de serviciu Kubernetes al pod-ului, recuperează secretele configurate și le scrie în un volum in-memory partajat sau le injectează în mediul containerului aplicației. Secretele nu apar niciodată în specificația pod-ului sau în imaginea containerului — sunt injectate la runtime din Vault.

External Secrets Operator este un operator Kubernetes care sincronizeazДѓ secretele din magazinele de secrete externe (Vault, AWS Secrets Manager, Azure Key Vault) Г®n Secretele Kubernetes. OferДѓ o abordare declarativДѓ, compatibilДѓ GitOps: resursa personalizatДѓ ExternalSecret din configuraИ›ia GitLab/Kubernetes declarДѓ ce secrete sunt necesare И™i de unde provin; operatorul gestioneazДѓ recuperarea И™i sincronizarea.

Pentru pipeline-urile GitLab CI, integrarea GitLab-Vault (integrarea CI/CD Vault GitLab, folosind autentificarea JWT) permite job-urilor pipeline sДѓ se autentifice la Vault folosind identitatea JWT GitLab И™i sДѓ recupereze secretele pe durata job-ului pipeline. Secretele sunt disponibile ca variabile de mediu Г®n cadrul job-ului И™i nu sunt niciodatДѓ stocate Г®n configuraИ›ia GitLab CI sau depozit.