Identitățile non-umane din securitatea fizică

În prima zi a unui audit de securitate pe care-l efectuam la o unitate din sectorul energetic am solicitat consultarea a trei documente esențiale. Evaluarea de risc la securitatea fizică, planul de pază și proiectul sistemului de control al accesului. Situația părea în regulă. Documentele existau și erau semnate și aprobate de către conducere, precum și de autoritatea de reglementare. Am pus următoarea întrebare managerului de securitate: cine este proprietarul contului prin care sistemul pentru controlul accesului citește structura organizatorică din aplicația de resurse umane?

Managerul de securitate a răspuns scurt că este o chestiune ce ține de departamentul IT. Am pus aceeași întrebare și directorului departamentului IT care a afirmat că sistemul pentru controlul accesului nu intră în responsabilitatea sa, deoarece reprezintă un echipament de securitate. Inginerul sisteme de securitate al integratorului, companie care acum efectua operațiunile de service pe bază de contract, contactat telefonic, și-a amintit că proiectul de integrare fusese realizat de un coleg care părăsise compania în anul 2023.

În douăzeci de minute am elucidat situația. Contul avea drept de citire asupra întregii baze de date a personalului și drept de scriere în tabelul cu drepturi de acces. Parola era configurată să nu expire, deoarece, în caz contrar, „se întrerupea sincronizarea”. Funcționa în acest mod, neîntrerupt, de șase ani, iar această informație nu figura în niciun document intern.

Toți răspunseseră corect, din perspectiva proprie. Problema consta în faptul că întrebarea mea nu avea un destinatar clar, deoarece elementul vizat nu fusese niciodată definit în mod formal.

Respectivul cont deținea privilegii superioare oricărui angajat al unității. Avea acces permanent și nesupravegheat la datele care stabilesc permisiunile de acces fizic. Spre deosebire de personalul uman, acesta nu fusese niciodată recrutat sau evaluat și nu urma să plece vreodată în concediu, la pensie ori la o altă companie. Câte astfel de conturi estimați că funcționează în prezent în compania în care vă desfășurați activitatea?

Ce este, de fapt, o identitate non-umană

Cloud Security Alliance (CSA) a publicat, prin grupul de lucru pentru managementul identității și accesului, un document, “Defining Non-Human Identity” care propune un criteriu simplu de calificare. O entitate reprezintă o identitate non-umană doar dacă se poate autentifica, adică să își dovedească legitimitatea. Dacă poate fi autorizată, adică să primească permisiuni de acces la resurse, în mod direct sau indirect.

Criteriul este util tocmai pentru că exclude mai multe elemente decât include. O înregistrare de configurare nu constituie o identitate. Nu fac asta nici datele care descriu un echipament fără să îl reprezinte, sau un script lipsit de capacitatea de a se autentifica. O cheie sau un certificat nu este o identitate atât timp cât nu este asociată uneia. După aceste excluderi rămâne doar ceea ce documentul numește actori cu acces, iar acela este perimetrul căruia i se aplică guvernanța.

Al doilea element mi-a schimbat modul în care îmi analizez propriile proiecte: separarea dintre subiectul identității și mecanismul de autentificare. Subiectul este actorul căruia îi este atribuită identitatea: camera, contul prin care două aplicații schimbă date, modulul de analiză. Mecanismul este modul prin care acel actor dovedește că este cine pretinde că este: o parolă sau o cheie de acces care rămâne neschimbată până când cineva o schimbă. Un certificat, un jeton criptografic semnat, un element de validare ancorat într-un modul hardware ori o sesiune temporară emisă de un serviciu de tip cloud. Un singur subiect poate utiliza mai multe mecanisme, succesiv sau simultan.

Cunoaștem această situație de decenii, doar că am aplicat-o exclusiv oamenilor. Nimeni nu confundă angajatul cu cardul său de acces. Când o persoană pierde cardul, revocăm cardul, nu concediem angajatul. Știm foarte bine că actorul rămâne același, chiar dacă mijlocul prin care dovedește cine este se schimbă.

Cu echipamentele ne purtăm altfel, iar diferența se vede cel mai clar atunci când schimbăm o credențială. Angajatul care pierde cardul primește altul și își păstrează tot ce avea înainte: aceleași drepturi, același dosar, același șef. Camera video căreia îi schimbăm parola pornește de la zero. Nu pentru că am decis noi așa, ci pentru că istoricul era legat de credențială, nu de un actor. Nu exista niciun actor de care să fie legat.

Amploarea acestui fenomen nu este, deloc, marginală. Documentul elaborat de Cloud Security Alliance citează cercetarea CyberArk, care indică o proporție de aproximativ 82 la 1 între identitățile non-umane și cele umane în organizațiile moderne, precum și studii ale companiei Palo Alto Networks care raportează valori de peste 100 la 1. Întrebarea firească este în ce măsură aceste statistici ne privesc în mod direct.

Inventarul ascuns al securității fizice

Am preluat cele cinci categorii de subiecți din documentul elaborat de Cloud Security Alliance și le-am aplicat asupra infrastructurii unei clădiri pe care o cunosc în detaliu. Este vorba despre un sediu de birouri dotat cu recepție, control al accesului structurat pe trei niveluri, sistem de supraveghere video (VSS), sistem de detectare a intruziunilor, interfonie, soluție pentru gestiunea vizitatorilor și conexiune la dispeceratul de monitorizare.

1. Conturi de serviciu și de integrare. Aici se încadrează contul menționat în deschiderea articolului. Acestora li se adaugă contul prin care aplicația pentru gestiunea video interoghează sistemul de control al accesului, pentru a asocia evenimentul de acces fizic cu secvența înregistrată. Contul prin care aplicația dedicată vizitatorilor emite carduri temporare, legătura permanentă către dispecerat și contul de licențiere care validează zilnic numărul de canale active. Toate au o valabilitate îndelungată, se autentifică prin elemente criptografice statice și sunt rareori actualizate.
2. Identități de sarcină. Acestea includ modulele de analiză care rulează în containere pe serverul pentru gestiune video, precum și serviciile care expun evenimentele prin interfețe de programare către sistemul de management al clădirii. Un alt exemplu este reprezentat de platformele pentru controlul accesului livrate ca serviciu (SaaS), în cadrul cărora echipamentul de control local se autentifică la o instanță din mediul cloud. Aceste identități sunt generate și revocate odată cu rularea procesului, uneori de mii de ori pe zi.
3. Identități de infrastructură.  Aici intră: serverul de înregistrare, mașinile virtuale care găzduiesc aplicația pentru controlul accesului și echipamentele de la marginea rețelei (edge) care centralizează traficul senzorilor. Identitatea acestora este strict legată de ciclul de viață al resursei de calcul, nu de cel al aplicației care o utilizează.
4. Identități de dispozitiv. Aceasta este categoria cea mai numeroasă și, în contextul nostru, cea mai neglijată. Ea include fiecare cameră video, cititor, controler de acces, centrală de alarmare, post de interfon și senzor. O parte dintre acestea se autentifică prin intermediul unui certificat digital sau prin protocolul 802.1X. Aproape toate dețin însă și un al doilea set de elemente de validare destinat administrării, adesea identic la nivelul întregii flote de echipamente, din motive de simplificare a punerii în funcțiune.
5. Identități de agent. Categoria cea mai recentă și cu cel mai rapid ritm de creștere. Exemplele includ modulul de analiză care nu detectează doar o situație, ci și declanșează o acțiune. Sistemul de recunoaștere a numerelor de înmatriculare care comandă bariera fără intervenție umană și/sau motorul de reguli care, la îndeplinirea simultană a anumitor condiții, blochează accesul pe un întreg nivel al clădirii.

Peste aceste cinci categorii se suprapune un al șaselea nivel, care nu reprezintă o categorie distinctă, ci o modalitate de acces: conturile de mentenanță la distanță deținute de integrator. Aceste conturi funcționează la nivelul întregului sistem, beneficiind în mod obișnuit de drepturi de administrator absolut. În realitate, ele rămân funcționale mult timp după încheierea contractului sau chiar după ce compania care le-a generat și-a încetat activitatea.

Componentele menționate anterior nu reprezintă simple ipoteze, ci se regăsesc efectiv în proiecte reale. Particularitatea constă în faptul că ele au fost consemnate în documente doar ca simple echipamente, licențe sau servicii, fiind omise din rândul entităților cu drepturi de acces.

Dacă am presupune, fie și doar teoretic, că aceste entități sunt tratate ca actori, reacția profesională normală ar fi să le supunem regulilor consacrate: un mecanism de onboarding, evaluări periodice și protocoale clare de revocație a accesului. Însă tocmai aici se ascunde dificultatea esențială.

De ce guvernanța concepută pentru factorul uman nu funcționează în acest context

Orice angajat care se alătură organizației parcurge un proces bine definit, susținut de documente și de un responsabil. Acest proces include angajarea, transferul și încetarea activității. În terminologia managementului identității, ciclul este denumit “Joiner, Mover, Leaver”. Denumirile desemnează persoana, nu procedura: cel care intră, cel care își schimbă rolul, cel care pleacă. Însăși denumirea etapelor acestui model trădează concentrarea lui exclusivă în jurul individului.Procesul presupune un eveniment declanșator, o persoană autorizată care semnează și un moment precis în care accesul este revocat. În cazul unui echipament, precum o cameră video, acest cadru este inexistent.

Documentul elaborat de Cloud Security Alliance surprinde această diferență printr-o formulare relevantă. Identitățile non-umane sunt generate de evenimente asociate ciclului de viață al aplicațiilor software și al infrastructurii, nu de evenimente de afaceri. Acestea includ punerea în funcțiune, implementarea, inițierea unei sarcini sau execuția unei automatizări. În contextul instalațiilor tehnice, se adaugă un al treilea tip, corelat cu ciclul de viață al activului fizic: recepția echipamentului, montarea și dezafectarea acestuia.

Procesul-verbal de recepție pentru un sistem de securitate include seriile echipamentelor, rezultatele probelor funcționale și planurile conforme cu execuția (as-built). Acesta nu conține, însă, inventarul conturilor create, proprietarul fiecăruia, mecanismul de autentificare sau data expirării. Din zecile de astfel de procese-verbale pe care le-am văzut, niciunul nu includea această listă.

Cea mai evidentă consecință este apariția, așa numitelor “conturi orfane”. Când un angajat părăsește organizația, îi este retras cardul de acces și îi este dezactivat contul. La încetarea unui contract de mentenanță, sunt recuperate cheile fizice și, ocazional, sunt înlocuite încuietorile mecanice. Cu toate acestea, contul pentru acces la distanță al integratorului rămâne activ. Acest lucru provine din faptul că elementul vizat nu figurează în niciun document de predare-primire.

A doua consecință este acordarea permisiunilor excesive din motive de fiabilitate și automatizare. Pentru a preveni blocurile în sincronizare, se alocă frecvent privilegii extinse. Deși această decizie este justificată operațional pe moment, ea nu mai este reevaluată ulterior.

A treia consecință derivă din complexitatea și dimensiunea sistemului. Actualizarea constantă a datelor de validare pentru sute de camere din zeci de locații, fără oprirea activității, este un proces pe care puțini clienți îl pot gestiona. În plus, această sarcină este rareori inclusă în contractele de mentenanță.

Totodată, există o zonă de suprapunere unde granița dintre cele două medii dispare. Când un tehnician folosește interactiv un cont de serviciu pentru depanare, el acționează în afara oricărui cadru de guvernanță. În acest caz, nu i se aplică nici autentificarea MFA sau monitorizarea specifice utilizatorilor umani, dar scapă și de restricțiile impuse conturilor tehnice.

Toți acești factori devin și mai critici din cauza vitezei de execuție. Dacă o scăpare umană la acces oferă totuși un timp minim în care anomalia poate fi sesizată, un flux automatizat care procesează mii de acțiuni pe secundă șterge complet acest interval de siguranță, făcând reacția aproape imposibilă.

Aceste concluzii sunt valabile doar dacă entitatea respectivă execută exact instrucțiunile primite. Problemele reale apar însă în momentul în care acesta capătă libertatea de a decide singur ce măsuri să ia.

Agenții autonomi, categoria cu cea mai rapidă creștere și cu cele mai puține limite

Potrivit Cloud Security Alliance, identitățile de agent constituie segmentul cu cea mai accelerată expansiune, dar și cu cel mai imprecis cadru de securitate.

Exemplul oferit în document provine dintr-un mediu de birou. Un agent autorizat să citească agenda decide, în cadrul propriului lanț de acțiuni, să expedieze invitații. Nicio persoană nu i-a solicitat acest lucru, însă limitele mandatului său nu au fost stipulate.

Transpunând acest scenariu în domeniul securității fizice, un modul de analiză autorizat să semnaleze o aglomerare la un punct de trecere decide, la îndeplinirea simultană a anumitor condiții, să comande blocarea nivelului. Nu realizează acest lucru deoarece a fost programat explicit în acest sens, ci pentru că dispune de această acțiune, iar limitele mandatului său nu au fost definite formal.

Dificultatea majoră constă în lipsa de trasabilitate, nu în decizia propriu-zisă. Documentul subliniază că registrele de evenimente (logs) capturează rareori corelația completă dintre cine a ordonat acțiunea, ce agent a executat-o, cu ce scop și ce s-a întâmplat efectiv. Operational, dispecerul identifică doar efectul (ex: un nivel blocat), fără a avea vizibilitate asupra originii, delegării sau justificării comenzii. Această lipsă de transparență este accentuată de caracterul nedeterminist al sistemelor, care complică definirea și evaluarea anomaliilor.

În acest cadru se înscrie noul calendar legislativ european. Începând cu 2 august 2026, Regulamentul privind IA a intrat într-o nouă fază, activând cerințele de transparență (Articolul 50) și guvernanța pentru modelele de uz general. Totodată, prin regulamentul de modificare „AI Omnibus” (în vigoare din 27 iulie 2026), termenele de conformare au fost decalate: 2 decembrie 2027 pentru sistemele cu risc ridicat din Anexa III și 2 august 2028 pentru cele integrate în produse deja reglementate.

Implicațiile practice pentru infrastructurile de securitate sunt substanțiale. Sub incidența obligațiilor decalate (Anexa III) intră doar analitica video destinată identificării biometrice de la distanță. Funcționalitățile uzuale, cum ar fi numărarea persoanelor, detectarea obiectelor sau analiza comportamentală anonimă, nu sunt clasificate ca având risc ridicat. În plus, deși restricțiile privind practicile cu risc inacceptabil sunt în vigoare de la 2 februarie 2025, domeniul lor de aplicare este limitat.

Prin urmare, majoritatea sistemelor de astăzi nu au o obligație legală externă de conformare până la o anumită dată. Oricum, chiar și existența unei reguli nu ar rezolva fondul problemei. Regulamentul vizează doar sistemul în sine, cerând documentație, supraveghere, jurnalizare și evaluare. Nicio regulă nu identifică credențialele agentului, cine i-a acordat accesul și când expiră această autorizare. Așadar, cadrul juridic clarifică doar operațiunile efectuate de sistem, fără să-i definească identitatea. Rămâne de văzut dacă legislația națională va aduce completări în această privință. 

Ce prevede legislația din România și ce omisiuni persistă

O primă constatare, în urma reevaluării Legii nr. 333/2003, în forma modificată prin OUG nr. 37/2026, a fost că textul confirmă deja această abordare. Deși nu în mod explicit, prevederile sunt suficiente. Articolul 49^2 alineatul (1) stabilește că analiza de risc la securitatea fizică urmărește identificarea pericolelor și diminuarea riscurilor generate de operațiunile, procesele sau activele unității. Măsurile rezultate se valorifică prin planul de pază, prin proiectul sistemului de alarmare împotriva efracției și prin regulamente interne ori proceduri. 

Un cont tehnic ce deține drepturi de scriere asupra matricei de acces constituie o vulnerabilitate operațională neexceptată de lege. Trimiterea la „regulamente interne ori proceduri” indică exact mecanismul prin care ar trebui gestionate identitățile tehnice. Consider că nu avem nevoie de reguli noi pentru a susține acest lucru, ci doar de punerea în aplicare riguroasă și integrală a textului în vigoare.

A doua constatare privește ritmul actualizărilor. Articolul 49^3 alineatul (6) impune revizuirea analizei în cel mult 90 de zile de la modificarea parametrilor care generează riscuri, în cel mult 60 de zile de la un incident relevant de securitate fizică și în cel mult 30 de zile de la modificarea caracteristicilor arhitecturale sau funcționale. Aceasta este o frecvență proiectată pentru schimbări evidente. Expirarea unui certificat, menținerea accesului integratorului după încheierea contractului sau un modul creat și șters de o mie de ori zilnic nu se încadrează în niciunul dintre aceste trei criterii.

A treia constatare atrage atenția în mod deosebit. Articolul 18 alineatul (6), introdus prin OUG nr. 7/2026 și în vigoare din 27 martie 2026, prevede că în localitățile rurale care au instalate și utilizează sisteme tehnice de supraveghere video, autoritățile administrației publice locale nu mai au obligația de a asigura personal de pază.

Legiuitorul a acceptat, printr-o singură frază, ca un sistem tehnic să substituie resursa umană. Legea nu precizează cine deține identitatea camerei video și cine actualizează periodic elementele de validare ale acesteia. Nu precizează cine constată întreruperea fluxului de date și cine își asumă responsabilitatea dacă autoritatea publică locală nu semnează un contract de mentenanță. Personalul de pază, care deținea un atestat, un cazier judiciar și o fișă a postului, a fost înlocuit cu o entitate tehnică ale cărei atribute nu au fost definite formal.

Restul legii confirmă aceste omisiuni. Articolul 29 impune confidențialitatea informațiilor privind sistemele instalate sau aflate în întreținere. Articolul 31 solicită ca personalul tehnic să fie avizat și să dețină competențe specifice. Articolul 33 supune avizării regulamentele dispeceratelor de monitorizare. Articolul 50 litera j) obligă conducătorul unității să stabilească reguli privind accesul și circulația în interiorul obiectivului. Acestea sunt reguli destinate exclusiv persoanelor. Nu există nicio dispoziție referitoare la predarea elementelor de validare la finalul contractului, la jurnalizarea accesului de mentenanță la distanță sau la proprietarul fiecărui cont tehnic.

Se impune și observarea unui detaliu de vocabular. Articolul 27 alineatul (5) definește sistemul de alarmare împotriva efracției drept un ansamblu care poate include controlul accesului și televiziunea cu circuit închis. O lege actualizată în mai 2026 utilizează o denumire pe care standardul de referință a retras-o: SR EN IEC 62676-4:2025 Sisteme de supraveghere video utilizate în aplicaţii de securitate. Partea 4: Linii directoare pentru aplicaţii a înlocuit-o cu VSS. Aceasta este un indiciu că legea nu ține pasul cu evoluția domeniului pe care îl reglementează.

Restul cerințelor derivă din alte acte normative. OUG nr. 155/2024, aprobată prin Legea nr. 124/2025, impune entităților esențiale și importante măsuri de management al riscului și de securitate a lanțului de aprovizionare, iar accesul unui integrator la sistemul de securitate fizică reprezintă, în mod indubitabil, un risc asociat lanțului de aprovizionare. Standardul SR EN ISO/IEC 27001:2023 conține controale explicite privind gestionarea identității, informațiile de autentificare și drepturile de acces. Standardul SR EN 60839-11-1:2014 Sisteme de alarmă şi de securitate electronică. Partea 11-1: Sisteme electronice de control al accesului. Cerinţe pentru sistem şi componente prevede cerințe de jurnalizare, identificare și control al informațiilor pentru sistemele electronice de control al accesului. Regulamentul general privind protecția datelor impune urmărirea accesului la datele personale. Un cont de serviciu care citește întreaga bază de date a angajaților îndeplinește implicit această cerință.

Există trei cadre normative care stipulează măsurile necesare, în timp ce cadrul sectorial principal omite aceste aspecte.

Această lipsă de reglementare are, în prezent, un termen de soluționare. Articolul VI alineatul (1) din OUG nr. 37/2026 obliga Guvernul să modifice normele metodologice în termen de 90 de zile de la intrarea în vigoare a ordonanței, adică până la 4 august 2026. La momentul redactării acestui text, normele nu au fost adoptate.

Ce solicit în calitate de consultant de securitate și ce ar trebui să prevadă normele

O precizare conceptuală este obligatorie pentru fundamentarea raționamentului următor. În rolul meu de consultant de securitate, nu îndeplinesc atribuții de proiectare. Această etapă intră în sarcina proiectantului autorizat din echipa mea, în baza cadrului legal aplicabil. Delimitarea funcțională este fermă: eu definesc cerințele operaționale, iar el proiectează soluția corespunzătoare, respectând întotdeauna această ordine.

Această distincție este mai relevantă în acest context decât în oricare altul. Inventarul identităților tehnice este o problemă fundamentală de definire a cerințelor. Aceste cerințe se formulează anterior etapei de proiectare și nu se identifică pe parcursul acesteia. Dacă acestea nu sunt incluse în analiza de risc la securitatea fizică și în caietul de sarcini, proiectantul nu are ce transpune în soluție tehnică, integratorul nu are ce implementa, iar beneficiarul nu are ce recepționa.

Există cinci proceduri pe care le-am integrat în propria practică profesională, fără a aștepta o modificare normativă prealabilă:

1. Solicitarea inventarului identităților tehnice drept livrabil distinct. Acesta nu trebuie inclus în proiectul tehnic, ci în documentația de securitate a beneficiarului. Se detaliiază: entitatea care se autentifică, mecanismul utilizat, drepturile alocate și resursa vizată.
2. Desemnarea unui proprietar nominal pentru fiecare cont tehnic. Fiecare cont tehnic trebuie asociat unui singur titular responsabil. Propus ca proprietar, acesta va fi o persoană fizică desemnată clar prin nume și funcție, excluzând departamentele generice. Măsura asigură răspunderea directă și disponibilitatea rapidă în cazul unor incidente apărute în afara programului.
3. Impunerea unor clauze contractuale explicite. Acestea presupun actualizarea regulată a elementelor de autentificare. Se interzice utilizarea unor chei de acces identice pe mai multe echipamente. Predarea și revocarea drepturilor la finalizarea contractului vor fi consemnate oficial. Fiecare intervenție de la distanță trebuie înregistrată, identificând în mod expres persoana care a efectuat-o.
4. Efectuarea unor verificări riguroase la recepție. Pe lângă probele funcționale, solicit lista conturilor create și verific prin sondaj modificarea parolelor implicite. Deși reprezintă o etapă meticuloasă a recepției, este, totodată, cea mai eficientă din perspectiva securității.
5. Corelarea calendarului de reevaluare cu termenele de expirare. Datele de expirare ale certificatelor și termenele contractelor de mentenanță sunt integrate în calendarul de revizuire a analizei de risc, pentru a preveni omisiunea acestora între pragurile legale de 30, 60 și 90 de zile.

Implementarea acestor cinci recomandări nu depinde de modificarea cadrului legal existent. Este suficientă definirea adecvată a cerințelor pe parcursul derulării procesului. Cu toate acestea, normele metodologice urmează să fie actualizate, iar în cadrul acestui demers ar fi oportună integrarea a trei elemente esențiale:

1. În primul rând, inventarul identităților tehnice ar trebui stipulat drept element obligatoriu al documentației de securitate pentru unitățile supuse cerințelor minimale, putând fi structurat sub forma unui simplu tabel.
2. În al doilea rând, se impune desemnarea unui proprietar pentru fiecare cont tehnic, integrat în obligațiile conducătorului unității, prevăzute la articolul 50. În condițiile în care obligația de a stabili reguli de acces este deja reglementată, ar fi suficient ca aceste prevederi să nu se mai limiteze exclusiv la factorul uman.
3. În al treilea rând, trebuie introdusă obligația de predare și revocare a elementelor de validare la încetarea contractului cu societatea licențiată. În practică, sunt recuperate cheile fizice, însă este ignorat accesul de la distanță, care reprezintă, în realitate, elementul critic de acces.

Evaluarea acestor condiții nu impune autorităților de supraveghere expertiză tehnică complexă în domeniul cibernetic. Conformarea se dovedește ușor, pe baza unei documentații și a unei liste explicite, abordare aliniată perfect la structura cadrului normativ în vigoare.

Identitatea echipamentelor tehnice

Articolul 6^2 din Legea nr. 333/2003, introdus în mai 2026, definește perimetrul de securitate drept zona adiacentă limitei de proprietate, stabilită și delimitată prin planul de pază. Această abordare vizează o suprafață fizică, un spațiu cuantificabil în metri, care poate fi transpus pe un plan de situație și supravegheat prin mijloace specifice.

Aceasta este definiția utilizată în mod tradițional și din punct de vedere conceptual este pe deplin funcțională. Dificultatea apare din faptul că această abordare nu mai acoperă în totalitate perimetrul care necesită protecție în prezent.

Cea de-a doua dimensiune a perimetrului este lipsită de o delimitare geografică. Aceasta se manifestă prin conturile de integrare cu acces la baza de date a personalului, sesiunile de suport remote, certificatele digitale ale echipamentelor vechi ori algoritmii de analiză ce comandă blocaje automate. Imposibil de transpus pe un plan de situație, acest perimetru logic poate fi definit exclusiv prin inventariere și guvernanță riguroasă.

Acest articol a pornit de la o întrebare la care nimeni nu a avut un răspuns corect. Când s-a cerut identificarea proprietarului unui cont tehnic, prima reacție a fost tăcerea. După repetarea întrebării, răspunsurile nu au avut nicio legătură cu realitatea. Asta pentru că acel element nu fusese niciodată formalizat. Or, fără o definire clară, un activ nu are un titular desemnat, nu are un ciclu de viață stabilit și nici proceduri de revocare.

Activitatea din domeniul securității fizice a răspuns, timp de decenii, unei cerințe fundamentale: controlul accesului persoanelor. În jurul acestei cerințe au fost dezvoltate analize de risc, planuri de pază, licențe și un întreg cadru procedural, iar acest sistem a fost eficient deoarece actorii erau exclusiv persoane fizice, al căror acces era gestionat prin proceduri clare de primire și predare a mijloacelor de acces.

În prezent, așa cum am arătat, în localitățile rurale, cadrul normativ permite substituirea personalului de pază de către un sistem tehnic de supraveghere. Personalul de pază deținea atestat profesional, cazier judiciar și fișă a postului. În schimb, echipamentul tehnic funcționează adesea în baza unor elemente de validare neevidențiate și neasumate.

Guvernanța identităților non-umane în securitatea fizică nu necesită cunoștințe cibernetice, deoarece nu aparține acelui domeniu. Este vorba despre aplicarea regulilor existente actorilor neglijați până acum. Așa cum știm cine a adus un angajat, cine răspunde de el și când își pierde accesul. Putem cere exact același lucru pentru conturile de serviciu, certificatele camerelor sau conexiunile de mentenanță. Nu avem nevoie de bugete noi, instrumente sau reglementări suplimentare, ci doar de asumarea faptului că sistemul include mai mulți actori decât cei din statul de funcții.

La următoarea analiză de risc, la următoarea recepție, la următoarea reînnoire de contract de mentenanță, puneți întrebarea: ce se autentifică în sistemul meu, cine răspunde pentru fiecare, și cine îl oprește? Absența unui răspuns imediat, corect și documentat, confirmă existența unei vulnerabilități de guvernanță care necesită remediere.

Notă de transparență și metodologie

În pregătirea articolului am folosit Perplexity pentru identificarea și analiza surselor și ChatGPT pentru generarea suportului vizual pe baza indicațiilor formulate de mine. Referințele bibliografice au fost verificate în textele oficiale la 2 august 2026. Responsabilitatea pentru selecția informațiilor, pentru acuratețea datelor prezentate, pentru calitatea suportului vizual și pentru opiniile exprimate îmi aparține în totalitate. Această notă subliniază angajamentul meu pentru o utilizare etică, transparentă și asumată a tehnologiei în cercetare.

Referințe bibliografice

• Cloud Security Alliance, Defining Non-Human Identity, Identity and Access Management Working Group, 2026. Sursa de la care a pornit acest articol. https://cloudsecurityalliance.org
• SR EN IEC 62676-4:2025, Sisteme de supraveghere video utilizate în aplicații de securitate. Partea 4: Linii directoare pentru aplicații. Adoptat de ASRO, anunțat în Buletinul de Standardizare nr. 1/2026. Înlocuiește SR EN 62676-4:2016. Ediția internațională IEC 62676-4:2025 a fost publicată la 9 octombrie 2025. 
• SR EN 60839-11-1:2014, Sisteme de alarmă și de securitate electronică. Partea 11-1: Sisteme electronice de control al accesului. Cerințe pentru sistem și componente. Data aprobării: 31 ianuarie 2014. 
• SR EN ISO/IEC 27001:2023, Securitatea informației, securitatea cibernetică și protecția vieții private. Sisteme de management al securității informației. Cerințe. Data aprobării: 31 august 2023, modificat prin SR EN ISO/IEC 27001:2023/A1:2024. 
• Legea nr. 333/2003 privind paza obiectivelor, bunurilor, valorilor și protecția persoanelor, republicată în Monitorul Oficial nr. 189 din 18 martie 2014, cu modificările și completările ulterioare, între care Ordonanța de urgență nr. 7/2026 (Monitorul Oficial nr. 146 din 25 februarie 2026) și Ordonanța de urgență nr. 37/2026 (Monitorul Oficial nr. 381 din 6 mai 2026). 
• Ordonanța de urgență nr. 155/2024 privind instituirea unui cadru pentru securitatea cibernetică a rețelelor și sistemelor informatice din spațiul cibernetic național civil, aprobată prin Legea nr. 124/2025. 
• Regulamentul (UE) 2024/1689 de stabilire a unor norme armonizate privind inteligența artificială. Calendarul oficial de implementare, actualizat prin regulamentul de modificare cunoscut ca AI Omnibus, publicat în Jurnalul Oficial L 2026/1744 și intrat în vigoare la 27 iulie 2026.
• Regulamentul (UE) 2016/679 privind protecția persoanelor fizice în ceea ce privește prelucrarea datelor cu caracter personal.
• CyberArk, The Seven Types of Non-Human Identities to Secure. Sursa raportului de aproximativ 82 la 1, citat prin documentul Cloud Security Alliance. 
• Palo Alto Networks, 2026 Identity Security Landscape. Sursa valorilor de peste 100 la 1, citate prin documentul Cloud Security Alliance.