Managementul secretelor pentru identități non-umane în auditurile din 2026

Alerta de la 02:13 pe care nimeni nu o putea atribui

La 02:13, într-o dimineață de marți, canalul echipei de operațiuni de securitate se activează. Un export al unei baze de date de producție a pornit dintr-un cont intern de automatizare. Calea de acces este legitimă. Tokenul este valid. Adresa IP sursă aparține unui runner în cloud utilizat de echipa de inginerie. Nu este vizibil niciun malware. Nu există niciun raport de phishing.

CISO pune prima întrebare evidentă: „Cine deține această identitate?”

Tăcere.

Responsabilul DevOps își amintește că tokenul a fost creat în timpul unei migrări de client, cu doi ani în urmă. Echipa de platformă spune că ar putea fi utilizat de o integrare de facturare. Administratorul bazei de date spune că are acces doar în citire, deoarece eliminarea lui a întrerupt cândva o sarcină nocturnă. Departamentul juridic întreabă dacă au fost implicate date cu caracter personal. Funcția de conformitate întreabă dacă este un incident raportabil conform NIS2, DORA sau GDPR. Auditorul solicită dovezi că sunt inventariate, revizuite, rotite, monitorizate și revocate conturile de serviciu, cheile API, certificatele și secretele CI/CD.

Până la ora 09:00, proiectul constatării de audit începe deja să prindă contur. O cheie API inclusă direct în cod și nerotită a fost descoperită într-un microserviciu uitat. Aceasta acordă acces extins la o bază de date de producție cu tranzacții ale clienților. Dezvoltatorul care a creat-o a plecat acum doi ani. Sistemul nu are proprietar desemnat, scop documentat, înregistrare de rotație sau regulă de monitorizare.

Aceasta este problema identităților non-umane în 2026.

Majoritatea organizațiilor au îmbunătățit controlul accesului pentru utilizatorii umani. Au MFA, fluxuri pentru încadrare, schimbare de rol și încetare a colaborării, revizuiri ale accesului privilegiat și jurnale ale furnizorilor de identitate. Însă identitățile de mașină s-au multiplicat mai rapid decât guvernanța. Conturile de serviciu, identitățile de sarcină de lucru, cheile API, tokenurile OAuth, cheile SSH, certificatele, secretele Kubernetes, tokenurile de integrare SaaS, conturile de automatizare robotică a proceselor și credențialele de implementare CI/CD execută acum acțiuni critice pentru organizație fără a fi „utilizatori” în sens uman.

Pentru furnizorii SaaS, fintech-uri, furnizori de servicii administrate, operatori cloud și IMM-uri cu volum ridicat de date, identitățile non-umane neadministrate nu mai sunt o simplă problemă de igienă tehnică. Ele reprezintă un risc de reziliență și conformitate la nivelul consiliului de administrație. NIS2 tratează controlul accesului, managementul activelor, securitatea lanțului de aprovizionare, gestionarea incidentelor și igiena cibernetică drept măsuri de bază pentru managementul riscurilor de securitate cibernetică. DORA plasează riscul TIC, reziliența operațională, raportarea incidentelor și riscul TIC asociat terților sub responsabilitatea organului de conducere pentru entitățile financiare. GDPR impune operatorilor și persoanelor împuternicite să protejeze datele cu caracter personal și să demonstreze responsabilitatea.

Dificultatea nu este să demonstrezi că secretele există. Dificultatea este să demonstrezi că fiecare identitate non-umană are proprietar, scop, ciclu de viață, nivel de risc, acces aprobat, metodă securizată de stocare, regulă de rotație, acoperire de monitorizare și cale de revocare.

De ce identitățile non-umane au devenit noua problemă a accesului privilegiat

O identitate non-umană, sau NHI, este orice identitate digitală utilizată de software, infrastructură sau procese automatizate, nu de o persoană. În practică, aceasta include conturi de serviciu utilizate de aplicații, chei API utilizate de integrări SaaS, tokenuri OAuth și refresh utilizate de aplicații terțe, chei SSH utilizate de automatizări, certificate TLS și chei private, secrete CI/CD, identități cloud pentru sarcini de lucru, șiruri de conexiune la baze de date, credențiale încorporate, conturi de boți RPA și credențiale de integrare administrate de furnizori.

Aceste identități au adesea trei caracteristici care îi îngrijorează pe auditori.

În primul rând, sunt longevive. Un utilizator uman își poate roti credențialele, își poate schimba rolul și poate părăsi organizația printr-un proces formal de încetare a colaborării. Un token API creat într-o fereastră de lansare poate rămâne activ ani la rând, deoarece nimeni nu vrea să riște întreruperea producției.

În al doilea rând, sunt puternice. Un token de implementare poate modifica infrastructura. Un principal de serviciu cloud poate crea stocare. Un cont de bază de date poate exporta înregistrări despre clienți. O cheie de semnare poate compromite integritatea lanțului de aprovizionare software.

În al treilea rând, sunt greu de atribuit. Identitățile umane sunt legate de înregistrări HR. Identitățile non-umane sunt adesea legate de scripturi, pipeline-uri, furnizori, proiecte uitate sau integrări nedocumentate.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de la Clarysec Zenith Blueprint evidențiază direct acest aspect în faza Punerea controalelor în practică, pasul 22:

Și nu uitați identitățile non-umane. Aici auditurile descoperă adesea expuneri tăcute. Sunt urmărite tokenurile API? Conturile de integrare sunt asociate cu persoane sau plutesc în incertitudine? Când a fost rotit ultima dată acel șir de acces la baza de date, încorporat într-un script vechi de decenii?

Managementul identității nu este spectaculos, dar este structural. Fără el, SMSI-ul dvs. este doar o colecție de uși încuiate, fără nicio modalitate de a ști sigur cine deține cheile.

Ultima propoziție este esențială. O companie poate avea o Politică de control al accesului bine redactată și totuși poate eșua la audit dacă identitățile de mașină nu sunt administrate. Un SMSI care nu poate explica cine deține un secret, de ce există și când a fost revizuit ultima dată nu funcționează încă drept sistem controlat.

ISO/IEC 27001:2022 transformă managementul secretelor în dovezi

ISO/IEC 27001:2022 este eficace deoarece nu tratează managementul secretelor ca pe o sarcină izolată de inginerie. Standardul impune un SMSI bazat pe risc, cu domeniu de aplicare definit, cerințe ale părților interesate, responsabilitate a conducerii, evaluarea riscurilor, tratarea riscurilor, selectarea controalelor, Declarație de aplicabilitate și îmbunătățire continuă.

Pentru identitățile non-umane, organizația nu ar trebui să înceapă prin achiziția unui instrument. Ar trebui să înceapă cu domeniul de aplicare și obligațiile.

Conform clauzelor ISO/IEC 27001:2022 4.1 până la 4.4, organizația determină aspectele interne și externe, părțile interesate, cerințele legale, de reglementare și contractuale, interfețele și dependențele. În context NHI, domeniul de aplicare al SMSI trebuie să identifice mediile cloud, platformele SaaS, sistemele CI/CD, aplicațiile de producție, integrările cu clienți, persoanele împuternicite, furnizorii de servicii administrate și serviciile criptografice în care există credențiale de mașină.

Clauzele 5.1 până la 5.3 fac conducerea responsabilă pentru politică, resurse, roluri și raportarea performanței. Acest lucru contează deoarece remedierea NHI generează adesea tensiuni operaționale. Rotirea unei credențiale pentru o bază de date de producție, înlocuirea unui cont de serviciu partajat moștenit sau impunerea injectării secretelor pe bază de seif poate întrerupe fluxuri fragile. Fără sponsor executiv, echipele amână curățarea.

Clauzele 6.1.1 până la 6.1.3 și 6.2 furnizează motorul de control. Organizația definește criterii de risc, identifică riscurile privind confidențialitatea, integritatea și disponibilitatea, atribuie proprietari de risc, evaluează probabilitatea și impactul, alege opțiuni de tratare, selectează controale, produce Declarația de aplicabilitate și urmărește obiective măsurabile.

În termeni practici, un plan de tratare a riscurilor pentru identități non-umane trebuie să răspundă la următoarele întrebări:

• Ce sisteme și servicii ale organizației depind de NHI?
• Ce secrete pot accesa date cu caracter personal, servicii financiare reglementate, infrastructură de producție sau servicii critice pentru clienți?
• Ce identități sunt privilegiate, inactive, partajate, administrate de furnizori sau neadministrate?
• Ce controale reduc riscul, cum ar fi stocarea în seifuri, rotirea, principiul privilegiului minim, expirarea, managementul ciclului de viață al certificatelor, scanarea CI/CD, monitorizarea și revocarea de urgență?
• Ce riscuri reziduale necesită aprobarea organizației?

ISO/IEC 27002:2022 furnizează apoi catalogul de controale din Anexa A. Cele mai relevante controale includ 5.9 Inventarul informațiilor și al altor active asociate, 5.15 Controlul accesului, 5.16 Managementul identității, 5.17 Informații de autentificare, 5.18 Drepturi de acces, 5.19 Securitatea informației în relațiile cu furnizorii, 5.20 Tratarea securității informației în acordurile cu furnizorii, 5.21 Managementul securității informației în lanțul de aprovizionare TIC, 5.23 Securitatea informației pentru utilizarea serviciilor cloud, 5.24 Planificarea și pregătirea managementului incidentelor, 5.28 Colectarea dovezilor, 8.2 Drepturi de acces privilegiat, 8.3 Restricționarea accesului la informații, 8.5 Autentificare securizată, 8.15 Jurnalizare, 8.16 Activități de monitorizare, 8.24 Utilizarea criptografiei, 8.25 Ciclul de viață al dezvoltării securizate, 8.26 Cerințe de securitate a aplicațiilor, 8.28 Programare securizată și 8.31 Separarea mediilor de dezvoltare, testare și producție.

Zenith Controls: The Cross-Compliance Guide de la Clarysec Zenith Controls mapează aceste relații ISO/IEC 27002:2022 într-un mod utilizabil de auditori și proprietari de control. Pentru controlul 5.16, Managementul identității, Zenith Controls explică legătura dintre identitate și credențiale:

Managementul identității stabilește cine, în timp ce informațiile de autentificare asigură cum, verificând că persoana care pretinde o identitate este legitimă. 5.16 guvernează gestionarea ciclului de viață al identității, în timp ce 5.17 asigură că parolele, tokenurile, certificatele și alte credențiale sunt legate în mod securizat de acele identități și administrate corespunzător pentru a susține autentificarea puternică.

Această relație este esențială pentru NHI. Un token fără proprietar al identității nu este verificabil în audit. Un cont de serviciu fără revizuirea drepturilor de acces nu respectă principiul privilegiului minim. Un certificat fără stare a ciclului de viață nu reprezintă criptografie controlată. O credențială de integrare cu furnizorul fără clauze contractuale nu reprezintă management eficace al riscului asociat terților.

Modelul de control Clarysec: identitate, secret, privilegiu, dovezi

Clarysec implementează managementul identităților non-umane și al secretelor printr-un model de control repetabil. Nu tratăm „secretele” ca fiind doar o preocupare DevOps sau „conturile de serviciu” ca fiind doar o preocupare IAM. Conectăm identitatea, secretul, privilegiul și dovezile.

Stratul de politică este locul în care acest lucru devine aplicabil.

Pentru IMM-uri, Politica pentru IMM-uri privind gestionarea conturilor de utilizator și a privilegiilor de la Clarysec User Account and Privilege Management Policy-sme prevede:

Conturile de serviciu (utilizate de sisteme sau aplicații) trebuie documentate, restricționate la sisteme specifice și nu trebuie utilizate niciodată pentru autentificări interactive.

Aceasta previne anti-tiparul clasic în care un cont de serviciu devine un cont de administrator partajat. De asemenea, oferă auditorului un test clar: prezentați inventarul conturilor de serviciu, demonstrați restricționarea la nivel de sistem și demonstrați că autentificarea interactivă este dezactivată sau prevenită tehnic.

Politica pentru IMM-uri privind managementul activelor de la Clarysec Asset Management Policy-sme extinde definiția activelor pentru a include:

Credențiale și servicii digitale: nume de domeniu, certificate digitale, chei API, conturi de e-mail, autentificări cloud

Acest aspect contează deoarece multe organizații inventariază doar servere, laptopuri și aplicații. În 2026, o cheie API poate fi mai sensibilă decât un laptop. Cheia privată a unui certificat poate fi un activ de autentificare de producție. O autentificare cloud utilizată de automatizare poate crea expunere a datelor reglementate. Tratarea credențialelor ca active reprezintă baza managementului secretelor pregătit pentru audit.

Pentru mediile enterprise, Politica privind gestionarea conturilor de utilizator și a privilegiilor de la Clarysec User Account and Privilege Management Policy ridică nivelul cerut al dovezilor:

Organizația trebuie să mențină un inventar detaliat al tuturor credențialelor active și inactive, al conturilor privilegiate și al conturilor de serviciu la nivel de sistem. Acest inventar trebuie actualizat continuu și revizuit trimestrial.

Revizuirea trimestrială este locul în care apar multe lacune. Credențialele inactive, principalii de serviciu orfani, utilizatorii de integrare vechi, conturile de furnizor neadministrate și tokenurile de urgență devin vizibile doar atunci când cineva compară registrul cu înregistrările reale din IAM, seifuri, CI/CD și cloud.

Secretele sunt informații de autentificare, nu facilități pentru dezvoltatori

Cea mai periculoasă expresie în managementul secretelor este „cheie temporară”.

Cheile temporare devin permanente. Credențialele de test ajung în producție. Codul sursă dezvăluie tokenuri. Jurnalele de build expun parole. Echipele de suport partajează certificate prin tichete. Dezvoltatorii copiază fișiere de mediu în chat. Un contractor creează un principal de serviciu cloud și pleacă.

Zenith Blueprint, faza Punerea controalelor în practică, pasul 22, descrie informațiile de autentificare în sens larg:

Acest control nu este doar despre parole, deși parolele fac, cu siguranță, parte din tablou. Este despre fiecare credențială utilizată pentru afirmarea identității: parole, PIN-uri, chei criptografice, șabloane biometrice, smartcarduri, tokenuri, certificate, tokenuri OAuth, chei SSH, secrete API. Acestea sunt cheile regatului, iar Controlul 5.17 asigură că aceste chei sunt tratate cu seriozitatea pe care o merită.

Să fim clari: managementul deficitar al autentificării rămâne una dintre principalele cauze-rădăcină ale încălcărilor. Parole slabe sau partajate. Credențiale incluse direct în codul sursă. Autentificări implicite neschimbate pe portaluri de administrare. Certificate expirate sau cu proprietate necunoscută. În fiecare dintre aceste cazuri, nu identitatea a eșuat, ci eșecul de a proteja și guverna mecanismul utilizat pentru a dovedi acea identitate.

Politicile Clarysec traduc acest lucru în reguli operaționale.

Politica pentru IMM-uri privind controalele criptografice de la Clarysec Cryptographic Controls Policy-sme prevede:

Cheile nu trebuie stocate în clar sau încorporate în cod sursă, documente sau e-mailuri

Politica pentru IMM-uri privind dezvoltarea securizată de la Clarysec Secure Development Policy-sme prevede:

Nu sunt permise credențiale sau secrete incluse direct în codul sursă

Pentru echipele enterprise, Politica de dezvoltare securizată Secure Development Policy prevede:

Secretele nu trebuie incluse direct în cod sau stocate în clar în depozite.

Iar Politica privind cerințele de securitate a aplicațiilor Application Security Requirements Policy este și mai directă:

Stocarea parolelor sau a cheilor criptografice în clar este strict interzisă.

Aceste clauze de politică creează o pistă de audit clară. Echipele de securitate pot testa depozite de cod, variabile CI/CD, imagini de containere, spații de stocare a configurațiilor, sisteme de urmărire a problemelor, platforme de documentație și jurnale față de cerințe explicite. Ele susțin și Article 32 din GDPR privind securitatea prelucrării, deoarece expunerea secretelor poate conduce direct la acces neautorizat la date cu caracter personal.

Guvernanța criptografică enterprise are nevoie și de proprietate. Politica privind controalele criptografice de la Clarysec Cryptographic Controls Policy impune:

Trebuie menținut un Registru centralizat de management al cheilor pentru a înregistra toate cheile criptografice, starea ciclului lor de viață, custozii desemnați și contextele de utilizare.

Pentru identitățile non-umane, acel registru trebuie să conecteze cheile de certificat, cheile de semnare, cheile API și cheile gestionate în cloud cu registrul NHI mai larg. Auditorul trebuie să poată urmări un certificat de producție de la serviciul organizației la proprietar, custode, expirare, dovezi de rotație și procedura de răspuns la incidente.

NIS2, DORA și GDPR: un singur model de dovezi, mai multe autorități

Guvernanța identităților non-umane este o problemă de conformitate transversală deoarece aceeași deficiență poate declanșa obligații multiple.

Un token API scurs la un furnizor SaaS poate cauza întreruperea serviciului conform NIS2, expunerea datelor cu caracter personal conform GDPR și raportarea contractuală a incidentelor către clienți financiari conform așteptărilor DORA privind lanțul de aprovizionare. Un secret CI/CD compromis la un furnizor de servicii TIC poate afecta reziliența clienților, integritatea software-ului și continuitatea operațională. Un cont de integrare cu furnizorul uitat poate crea acces la sisteme reglementate fără verificare prealabilă adecvată sau controale contractuale.

NIS2 Article 21 impune măsuri tehnice, operaționale și organizatorice adecvate și proporționale. Domeniile minime includ analiza riscurilor, politici de securitate a sistemelor informatice, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția, dezvoltarea și mentenanța securizate, gestionarea vulnerabilităților, evaluarea eficacității, igiena cibernetică, criptografia, securitatea HR, controlul accesului și managementul activelor și, după caz, MFA sau autentificare continuă. Identitățile non-umane se regăsesc în aproape toate aceste domenii. NIS2 Article 23 creează, de asemenea, raportarea etapizată a incidentelor semnificative, inclusiv avertizare timpurie în termen de 24 de ore, notificarea incidentului în termen de 72 de ore și un raport final cel târziu la o lună după notificarea incidentului.

DORA se aplică de la 17 ianuarie 2025 și acoperă managementul riscurilor TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței operaționale, schimbul de informații și riscul TIC asociat terților. Articles 5 și 6 impun guvernanță, responsabilitatea organului de conducere și un cadru documentat de management al riscurilor TIC. Article 8 impune identificarea funcțiilor organizației susținute de TIC, a activelor informaționale și a dependențelor. Articles 17 până la 19 impun managementul incidentelor, clasificare și raportare. Articles 28 până la 30 impun managementul riscurilor TIC asociate terților, registre contractuale, verificare prealabilă, standarde de securitate, drepturi de audit, suport pentru incidente, controale privind subcontractarea și strategii de ieșire.

GDPR se aplică oriunde sunt prelucrate date cu caracter personal în domeniul său teritorial. Article 5 impune integritate, confidențialitate și responsabilitate. Article 32 impune măsuri tehnice și organizatorice adecvate pentru securitatea prelucrării. Dacă un cont de serviciu sau o cheie API poate accesa date cu caracter personal, secretele neadministrate devin o deficiență a controalelor de confidențialitate, nu doar o problemă IT.

Aceleași dovezi pot susține certificarea ISO/IEC 27001:2022, supravegherea NIS2, examinările DORA și responsabilitatea GDPR atunci când sunt structurate corect.

NIST CSF 2.0 poate fi utilizat ca strat de comunicare pentru aceleași dovezi. Funcția sa GOVERN acoperă așteptările părților interesate, obligațiile legale și contractuale, apetitul la risc, responsabilitatea conducerii, politica și supravegherea. Rezultatele sale operaționale acoperă inventare de active, servicii furnizate de furnizori, managementul identității și al credențialelor, principiul privilegiului minim, securitatea datelor, jurnalizare, monitorizare, răspuns la incidente și recuperare.

COBIT 2019 și echipele de asigurare de tip ISACA vor analiza de regulă guvernanța și capabilitatea proceselor. Vor întreba dacă responsabilitatea este atribuită, dacă controalele sunt integrate în procesele operaționale, dacă excepțiile sunt aprobate, dacă metricile sunt raportate conducerii și dacă dovezile demonstrează repetabilitate, nu doar o curățare punctuală.

Un sprint practic pentru construirea unui registru al identităților non-umane

Un angajament practic Clarysec începe adesea cu un sprint concentrat, nu cu un program de instrumentare de șase luni. Scopul este producerea unui registru NHI defensabil, a unei prioritizări pe risc și a unui plan de remediere care să alimenteze planul de tratare a riscurilor ISO/IEC 27001:2022 și Declarația de aplicabilitate.

Începeți cu un singur serviciu al organizației, cum ar fi o platformă de facturare pentru clienți, o aplicație de tranzacționare, un portal pentru pacienți sau un sistem de management al tenantului SaaS. Includeți producția, staging, CI/CD, infrastructura cloud, instrumentele de monitorizare, bazele de date, integrările SaaS și serviciile administrate de furnizori.

Legați acest demers de Zenith Blueprint, faza Managementul riscurilor, pasul 14, unde Clarysec aliniază politicile de tratare cu trimiteri de conformitate transversală. În acel pas, controalele pentru dezvoltare securizată și pipeline includ absența secretelor incluse direct în cod, revizuirea codului de către colegi, analiza statică automatizată, scanarea dependențelor, separarea dezvoltării, testării și producției, MFA pentru accesul la pipeline, integritatea artefactelor de build și jurnalizarea CI/CD.

Colectați identități și secrete din furnizorul de identitate, IAM cloud, seiful de secrete, Kubernetes, variabilele CI/CD, setările depozitelor de cod, utilizatorii bazelor de date, consolele de administrare SaaS, instrumentele de management al certificatelor și documentația furnizorilor.

Evaluați riscul identităților care au acces la producție, drepturi privilegiate, acces la date cu caracter personal, dependență de o funcție critică sau importantă, control de către furnizor, tokenuri longevive, lipsă de proprietar, lipsă de rotație, lipsă de monitorizare sau stocare în cod. Utilizați criteriile de risc ISO/IEC 27001:2022 pentru a puncta probabilitatea și impactul. Utilizați analiza funcțiilor critice sau importante DORA acolo unde este aplicabil. Utilizați considerații de impact GDPR atunci când datele cu caracter personal sunt accesibile. Utilizați impactul asupra serviciilor NIS2 atunci când perturbarea sau prejudiciul pentru clienți este plauzibil.

Pentru fiecare NHI cu risc ridicat, aplicați acțiuni de tratare. Mutați secretele din cod sursă, documente și variabile CI/CD în clar într-un seif sau într-un depozit de secrete administrat. Înlocuiți conturile de serviciu partajate cu identități unice de sarcină de lucru. Dezactivați autentificarea interactivă pentru conturile de serviciu. Aplicați principiul privilegiului minim și credențiale specifice mediului. Configurați rotația, expirarea și revocarea de urgență. Asociați secretele cu proprietari și custozi. Adăugați jurnalizare pentru autentificare, utilizarea tokenurilor și acțiuni sensibile. Adăugați alerte pentru geografii anormale, intervale orare neobișnuite, volume neobișnuite sau acces la resurse noi. Actualizați contractele cu furnizorii pentru gestionarea credențialelor, suport la incidente și drepturi de audit. Documentați excepțiile cu aprobarea proprietarului de risc și dată de expirare.

Politica privind datele de test și mediile de testare Test Data and Test Environment Policy susține separarea mediilor:

Integrarea cu pipeline-urile CI/CD trebuie să impună separarea mediilor și a credențialelor de autentificare.

Această clauză este frecvent decisivă. Dacă dezvoltarea, testarea și producția partajează secrete, un mediu cu risc scăzut poate deveni o cale de încălcare către producție.

Sprintul trebuie să se încheie cu un pachet de dovezi, nu doar cu o listă de constatări. Includeți exportul registrului NHI, înregistrări de evaluare a riscurilor, planul de tratare, maparea Declarației de aplicabilitate, trimiteri la politici, capturi de ecran din seif, jurnale de rotație, aprobări ale revizuirii accesului, rezultate ale scanării secretelor CI/CD, definiții ale regulilor de monitorizare, matricea responsabilităților pentru credențialele furnizorilor, runbook-ul de incident și excepții cu proprietari și date de expirare.

Jurnalizare și detecție: demonstrarea vizibilității utilizării identităților de mașină

O identitate de mașină bine inventariată, dar invizibilă în jurnale, rămâne periculoasă. Detecția face parte din povestea controlului.

Politica pentru IMM-uri privind jurnalizarea și monitorizarea de la Clarysec Logging and Monitoring Policy-sme include dovezi de autentificare:

Jurnale de autentificare: tentative de autentificare reușite și eșuate, durata sesiunii, utilizarea MFA

Pentru NHI, adaptați această cerință la autentificarea mașinilor. Este posibil să nu aveți utilizare MFA pentru o identitate de sarcină de lucru, dar trebuie să aveți evenimente de autentificare, utilizare de token, utilizare de certificat, metadate ale apelurilor API, sarcină de lucru sursă, serviciu destinație, durată de viață a tokenului, evenimente de eșec și acțiuni privilegiate.

În Zenith Controls, controlul ISO/IEC 27002:2022 8.2, Drepturi de acces privilegiat, este legat de jurnalizare și monitorizare deoarece conturile privilegiate necesită înregistrări detaliate și supraveghere. Zenith Controls leagă de asemenea 8.2 de managementul identității, drepturile de acces, restricționarea accesului la informații și autentificarea securizată. Pentru auditori, aceasta înseamnă că identitățile non-umane privilegiate trebuie revizuite și monitorizate cu aceeași seriozitate ca administratorii umani, uneori chiar mai mult.

Întrebările bune de monitorizare includ:

• S-a autentificat un cont de serviciu dintr-o sarcină de lucru sau dintr-un interval IP neașteptat?
• A accesat o cheie API un endpoint sau un set de date nou?
• A fost utilizat un certificat după înlocuire?
• A implementat un token CI/CD în afara unui pipeline aprobat?
• A încercat un cont doar cu drepturi de citire să efectueze operațiuni de scriere?
• A devenit activă o credențială inactivă?
• A accesat o integrare cu furnizorul date în afara orelor sau volumelor agreate?

Când apare alerta de la 02:13, trebuie să puteți răspunde ce identitate a fost utilizată, ce secret a autentificat-o, ce drepturi de acces au fost exercitate, ce date sau sisteme au fost afectate, dacă activitatea era așteptată, ce proprietar o poate valida și dacă sunt îndeplinite pragurile de raportare a incidentelor.

Perspectiva auditorului: același proces, întrebări diferite

Cea mai solidă poziție de audit nu este „respectăm totul”. Este „operăm un proces controlat care produce dovezi pentru obligații multiple”. Auditori diferiți vor examina acel proces în mod diferit.

În toate aceste perspective, constatările recurente sunt previzibile: nu există un inventar NHI unic, nu există proprietar pentru identitățile de mașină, secretele sunt stocate în cod sau documentație, credențialele sunt partajate între medii, nu există rotație sau expirare, credențialele administrate de furnizori sunt în afara revizuirilor accesului, monitorizarea acoperă oamenii, dar nu și mașinile, iar runbook-urile de incident ignoră scurgerea secretelor.

Fiecare constatare se mapează natural la controalele, politicile și șabloanele de remediere Clarysec. Mai important, fiecare poate fi convertită în dovezi măsurabile în cadrul SMSI.

Cum vă ajută Clarysec să vă pregătiți pentru audit

Abordarea Clarysec este practică deoarece începe cu dovezile pe care auditorii le vor solicita și lucrează invers către controale, politici și rutine operaționale.

În Zenith Blueprint, faza Punerea controalelor în practică, pasul 19, Clarysec oferă îndrumări directe pentru autentificarea mașină-la-mașină:

Pentru autentificarea mașină-la-mașină, cum ar fi conturile de serviciu sau apelurile API, cheile, certificatele și tokenurile trebuie protejate la fel de riguros. Evitați încorporarea credențialelor în cod. Utilizați sisteme de management al secretelor sau seifuri pentru a le stoca și roti în siguranță.

Un flux de lucru Clarysec tipic pentru identități non-umane include descoperirea NHI în cloud, SaaS, CI/CD, depozite de cod, seifuri și baze de date, evaluarea lacunelor de politică față de seturile de politici Clarysec pentru IMM-uri sau enterprise, evaluarea riscurilor ISO/IEC 27001:2022 și maparea tratării, actualizări ale Declarației de aplicabilitate, maparea dovezilor NIS2, DORA, GDPR și NIST CSF, proiectarea registrului NHI, alinierea Registrului de management al cheilor, scanarea secretelor, procese de revizuire a accesului, matrice ale responsabilităților pentru credențialele furnizorilor, runbook-uri de incident și pachete de audit cu capturi de ecran, exporturi, jurnale, aprobări și înregistrări ale excepțiilor.

Pentru IMM-uri, abordarea este proporțională. Un furnizor SaaS cu 70 de persoane nu are nevoie de aceeași amprentă de instrumente ca o bancă globală, dar are nevoie de proprietate, politică, tratarea riscului și dovezi. Pentru entitățile financiare reglementate și furnizorii TIC, același model se extinde către maparea funcțiilor critice DORA, guvernanța riscului asociat terților și testarea rezilienței.

Dacă următorul audit este în 2026, nu așteptați ca auditorul să descopere identitățile non-umane în locul dvs. Începeți cu un serviciu critic și adresați cinci întrebări:

1. Cunoaștem fiecare cont de serviciu, cheie API, token, certificat și secret CI/CD utilizat de acest serviciu?
2. Are fiecare NHI un proprietar desemnat, custode, scop și nivel de risc?
3. Sunt secretele stocate în seifuri, rotite și protejate împotriva expunerii în cod sursă, documente, e-mailuri și stocare în clar?
4. Sunt identitățile de mașină privilegiate revizuite, monitorizate și restricționate împotriva utilizării interactive?
5. Putem produce dovezi pentru ISO/IEC 27001:2022, NIS2, DORA și GDPR dintr-un singur proces controlat?

Utilizați Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pentru a structura parcursul de implementare a SMSI. Utilizați Zenith Controls: The Cross-Compliance Guide Zenith Controls pentru a conecta controalele ISO/IEC 27002:2022 privind identitatea, autentificarea, privilegiile, jurnalizarea, criptografia, dezvoltarea securizată și furnizorii cu dovezile de reglementare. Utilizați biblioteca Clarysec de politici pentru IMM-uri și enterprise, inclusiv Politica pentru IMM-uri privind gestionarea conturilor de utilizator și a privilegiilor User Account and Privilege Management Policy-sme, Politica privind controalele criptografice Cryptographic Controls Policy, Politica de dezvoltare securizată Secure Development Policy și Politica privind cerințele de securitate a aplicațiilor Application Security Requirements Policy, pentru a transforma intențiile bune în cerințe aplicabile.

Alerta de la 02:13 va apărea undeva. Întrebarea este dacă organizația dvs. poate răspunde, cu dovezi, cine a deținut cheia, ce a deschis, de ce exista și cât de repede o puteți aduce într-o stare sigură.