Conformitatea NIS2 dincolo de propria rețea: cum evaluezi riscul venit de la furnizori

Un atac reușit asupra firmei care îți ține contabilitatea sau asupra furnizorului de Cloud poate bloca facturarea la fel de sigur ca un incident în propriul…

Un atac reușit asupra firmei care îți ține contabilitatea sau asupra furnizorului de Cloud poate bloca facturarea la fel de sigur ca un incident în propriul server. Multe companii au aflat asta abia după ce un partener compromis le-a deschis ușa către date și aplicații critice. Directiva NIS2 transformă această realitate într-o obligație concretă.

Ce cere NIS2 despre furnizori

Directiva (UE) 2022/2555, cunoscută drept NIS2, a fost transpusă în România prin OUG nr. 155/2024, iar Directoratul Național de Securitate Cibernetică (DNSC) este autoritatea care supraveghează aplicarea ei. Printre măsurile minime de gestionare a riscurilor, articolul 21 include explicit securitatea lanțului de aprovizionare, adică relația cu furnizorii direcți și prestatorii de servicii.

Textul nu se oprește la o mențiune generală. Entitățile esențiale și importante trebuie să ia în calcul vulnerabilitățile specifice fiecărui furnizor, calitatea produselor livrate și practicile lui de securitate, inclusiv modul în care își dezvoltă software-ul. Cu alte cuvinte, nu este suficient să știi cine sunt partenerii, ci și cât de bine își protejează propriile sisteme.

Responsabilitatea rămâne la companie, chiar dacă o parte din infrastructură este externalizată. Dacă un furnizor de servicii administrate suferă o breșă și atacatorii ajung în rețeaua clientului, autoritatea va analiza ce măsuri a luat clientul pentru a preveni scenariul. Mai mult, organele de conducere răspund direct pentru aprobarea și supravegherea măsurilor de securitate, inclusiv a celor legate de terți.

Pentru companiile care pregătesc conformarea la NIS2, primul pas practic este inventarul complet al furnizorilor. În multe organizații, lista oficială de contracte nu acoperă tot: apar abonamente SaaS cumpărate direct de departamente, integratori angajați pe proiect sau aplicații conectate prin API la ERP fără o evidență centrală.

Inventarul ar trebui să răspundă la câteva întrebări simple: ce serviciu oferă fiecare furnizor, ce date procesează, ce acces tehnic are în sistemele companiei și ce s-ar întâmpla dacă ar deveni indisponibil peste noapte. Răspunsurile separă partenerii critici de cei cu impact redus și arată unde trebuie concentrat efortul de evaluare.

Un furnizor de papetărie și un furnizor care găzduiește baza de date a clienților nu pot fi tratați la fel. Clasificarea pe niveluri de risc evită două greșeli frecvente: birocrația excesivă aplicată tuturor partenerilor, indiferent de rol, și superficialitatea față de cei care au chei de acces la infrastructură. O clasificare utilă ține cont de sensibilitatea datelor, de gradul de dependență operațională și de posibilitatea de a înlocui rapid furnizorul.

Pentru furnizorii din nivelul cel mai înalt, evaluarea trebuie făcută înainte de semnarea contractului și reluată periodic, nu doar o dată la începutul colaborării.

Criterii pentru un furnizor critic

Evaluarea unui furnizor nu înseamnă doar un chestionar trimis pe email și arhivat. Răspunsurile trebuie comparate cu dovezi: certificări valabile, rapoarte de audit, politici documentate și rezultate ale testelor de securitate. Un furnizor serios poate explica fără ezitare cum își protejează infrastructura și cine are acces la datele clienților.

Pentru partenerii care găzduiesc aplicații sau au acces administrativ la sisteme, merită verificate cel puțin următoarele aspecte:

  • certificările de securitate relevante, precum ISO/IEC 27001, și perimetrul exact pe care îl acoperă;
  • modul de gestionare a accesului, inclusiv autentificarea multifactor pentru conturile privilegiate;
  • termenul în care furnizorul anunță clientul despre un incident care îi afectează datele;
  • locația centrelor de date și jurisdicția aplicabilă datelor stocate;
  • politica de backup, frecvența testelor de restaurare și planul de continuitate;
  • subcontractorii implicați în livrarea serviciului și controlul exercitat asupra lor.

Ultimul punct este adesea ignorat. Un furnizor de servicii IT poate folosi la rândul său un alt Cloud, un centru de date al unei terțe părți sau o firmă externă pentru suportul de noapte. Riscul se transmite pe tot acest lanț, iar contractul trebuie să oblige furnizorul să aplice aceleași standarde și partenerilor lui.

Locația infrastructurii contează din mai multe motive. Datele găzduite în România sau în Uniunea Europeană rămân sub incidența acelorași reguli de protecție, iar auditul fizic este mai ușor de organizat. De exemplu, GTS Romania operează centre de date proprii în București și Cluj-Napoca, un detaliu util atunci când compania trebuie să documenteze exact unde se află sistemele critice.

Evaluarea nu se termină la semnarea contractului. Clauzele trebuie să includă dreptul de audit, obligația de notificare a incidentelor, cerințe privind ștergerea datelor la încetarea colaborării și un plan de ieșire realist. Fără un plan de ieșire, mutarea aplicației ERP sau a magazinului online la alt furnizor devine dificilă exact în momentul în care relația nu mai funcționează.

Un alt criteriu practic este transparența în situații neplăcute. Întreabă furnizorul cum a gestionat ultimul incident semnificativ, cât a durat restabilirea serviciului și ce a schimbat ulterior. Un răspuns concret, chiar dacă descrie o problemă reală, spune mai mult despre maturitatea lui decât o prezentare comercială fără cusur.

Cloud și co-sourcing: cine răspunde de ce

Mutarea aplicațiilor într-un mediu Cloud sau externalizarea operațiunilor IT nu transferă automat obligațiile NIS2 către furnizor. Se împarte însă responsabilitatea tehnică, iar această împărțire trebuie scrisă clar. Furnizorul răspunde, de regulă, de infrastructura fizică, rețea și virtualizare, în timp ce clientul rămâne responsabil pentru conturi, configurări, date și aplicații, dacă nu s-a convenit altfel.

Confuziile apar frecvent la backup și la actualizări. Mulți clienți presupun că furnizorul de Cloud salvează automat datele sau aplică patch-urile sistemelor de operare. În realitate, aceste activități depind de serviciul contractat. Backupul, protecția împotriva atacurilor DDoS sau disaster recovery sunt adesea servicii distincte, care trebuie solicitate și configurate separat.

Un mediu virtual de găzduire, cum este GTS Virtual Hosting Environment (VHE), pune la dispoziția companiei resurse virtuale de calcul, stocare și rețea într-un centru de date administrat de furnizor. Pentru evaluarea NIS2, contează că infrastructura fizică, securitatea accesului în clădire și alimentarea sunt gestionate de un operator specializat, iar clientul poate documenta aceste aspecte în propriul dosar de conformitate.

Totuși, chiar și într-un astfel de mediu, cineva trebuie să administreze mașinile virtuale, să monitorizeze jurnalele și să reacționeze la alerte. Dacă echipa internă este mică, aceste sarcini rămân adesea neacoperite în afara programului de lucru, exact atunci când multe atacuri sunt lansate.

Aici intervine modelul de co-sourcing, în care o parte din operațiunile IT este preluată de o echipă externă, iar controlul strategic rămâne în companie. GTS Managed IT Operations Services (MIOS) este serviciul prin care GTS Romania preia astfel de activități operaționale, în funcție de perimetrul stabilit prin contract. Și un asemenea partener intră, la rândul lui, în lista furnizorilor critici care trebuie evaluați.

Pentru magazinele online, împărțirea responsabilităților are o miză aparte. Platforma de e-commerce depinde de găzduire, de procesatorul de plăți, de firma de curierat și, adesea, de module dezvoltate de terți. Un plugin vulnerabil poate expune datele clienților chiar dacă infrastructura Cloud este bine protejată.

Matricea de responsabilități ar trebui să includă fiecare dintre aceste componente și să indice cine actualizează, cine monitorizează și cine anunță incidentele. Documentul devine util abia când este verificat în practică, de exemplu printr-un exercițiu de simulare a unui incident la care participă și furnizorii principali.

Monitorizarea după semnătură

Riscul unui furnizor se schimbă în timp. O firmă care trecea fără probleme evaluarea de acum doi ani poate fi preluată de alt grup, își poate muta serverele în altă țară sau poate renunța la o parte din echipa de securitate. De aceea, evaluarea inițială trebuie urmată de o monitorizare proporțională cu importanța fiecărui partener.

Un program de monitorizare eficient include, de obicei, următoarele activități:

  • reevaluarea anuală a furnizorilor critici, pe baza unor dovezi actualizate;
  • revizuirea periodică a conturilor de acces acordate terților și dezactivarea celor nefolosite;
  • urmărirea vulnerabilităților publicate pentru produsele folosite în companie;
  • analiza schimbărilor de subcontractori sau de locație a datelor;
  • verificarea respectării nivelurilor de serviciu stabilite prin contract;
  • actualizarea registrului de furnizori după fiecare contract nou sau încetat.

Conturile de acces ale terților merită o atenție aparte. În multe incidente analizate în ultimii ani, atacatorii au intrat prin conexiuni de administrare la distanță lăsate active după încheierea unui proiect sau prin credențiale furate de la un integrator. O politică simplă, cu acces temporar și autentificare multifactor, reduce considerabil această expunere.

Pregătirea pentru incidente trebuie să țină cont și de termenele de raportare. NIS2 cere o avertizare timpurie către autoritate în 24 de ore de la constatarea unui incident semnificativ și o notificare mai detaliată în 72 de ore. Dacă incidentul pornește de la un furnizor, compania poate respecta aceste termene doar dacă află rapid ce s-a întâmplat.

Din acest motiv, contractele cu partenerii critici ar trebui să prevadă un termen scurt de notificare, persoane de contact disponibile permanent și obligația de a furniza informațiile tehnice necesare investigației. Un furnizor care raportează un incident după o săptămână lasă clientul fără nicio șansă de a se încadra în cerințele legale.

Gestionarea riscului din lanțul de aprovizionare nu cere un departament nou, ci disciplină. Un registru actualizat, criterii clare de clasificare și contracte care spun exact cine ce face acoperă o mare parte din ce va verifica DNSC.

Restul ține de o rutină menținută constant: întrebări puse la timp, accese revizuite și parteneri aleși pentru felul în care răspund când ceva nu merge, nu doar pentru prețul trecut în oferta comercială.

Scris de

Ma numesc Octavian Cernat, am 35 de ani si sunt specialist in tehnologie. Am absolvit Facultatea de Automatica si Calculatoare din Bucuresti, iar ulterior mi-am continuat dezvoltarea profesionala prin cursuri si certificari in domeniul securitatii informatice si al inteligentei artificiale. Sunt pasionat de inovatie si de modul in care tehnologia poate transforma viata oamenilor, de la solutii digitale care simplifica munca de zi cu zi pana la proiecte complexe cu impact pe termen lung.

In timpul liber, imi place sa testez gadgeturi si aplicatii noi, sa citesc despre ultimele tendinte in IT si sa particip la hackathoane sau conferinte de profil. De asemenea, ma relaxez prin fotografie urbana si prin calatorii, unde imbin pasiunea pentru descoperirea locurilor noi cu interesul pentru arhitectura moderna si tehnologia oraselor inteligente.

Comentarii

Scrie un comentariu

Niciun comentariu încă. Ai o întrebare sau o experiență de împărtășit? Scrie primul!

Lasă un comentariu

Adresa de email nu va fi publicată. Câmpurile marcate cu * sunt obligatorii.

Parteneri România 174