Managementul posturii de securitate SaaS pentru auditurile din 2026

Constatarea de audit SaaS pe care nu și-a asumat-o nimeni

La 08:15, într-o zi de marți, CISO-ul unei companii fintech cu creștere rapidă primește un mesaj de la responsabilul cu protecția datelor: „De ce poate fi partajat public un export cu date despre clienți dintr-un instrument de colaborare și cine a aprobat aplicația OAuth care îl poate citi?”

Până la 09:00, departamentul financiar confirmă că instrumentul este plătit cu un card de departament, nu prin achiziții centralizate. Până la 10:30, IT descoperă că utilizatorul care a creat linkul public a plecat din companie în urmă cu trei luni. La prânz, departamentul juridic întreabă dacă situația reprezintă o încălcare a securității datelor cu caracter personal în sensul GDPR. La 14:00, Comitetul de risc întreabă dacă problema afectează igiena cibernetică NIS2 și riscul asociat terților TIC conform DORA. La 16:00, auditorul intern solicită configurații de referință, revizuiri ale accesului administratorilor, proprietatea serviciului cloud, jurnale și verificarea prealabilă a furnizorilor.

Adevărul dificil este că organizația nu a suferit o indisponibilitate SaaS clasică sau un eșec al furnizorului. A suferit un eșec de guvernanță.

Acest scenariu nu mai este excepțional. O echipă de marketing conectează o platformă de IA la un CRM cu permisiuni OAuth largi. HR cumpără un instrument de analiză de nișă în afara procesului de achiziții. O echipă de suport clienți activează exporturi publice ale tichetelor pentru comoditate. Echipa de inginerie integrează o extensie de browser într-un flux de dezvoltare. Fiecare decizie poate părea minoră, însă împreună creează o suprafață de control distribuită, plină cu date reglementate, fluxuri privilegiate și dependențe operaționale.

Managementul posturii de securitate SaaS, sau SSPM, este disciplina care transformă această realitate SaaS dispersată într-un control guvernat, testat și verificabil. Implementat corect, oferă CISO-ilor, managerilor de conformitate, auditorilor și proprietarilor de procese un set unic de dovezi trasabile pentru ISO/IEC 27001:2022, igiena cibernetică NIS2, riscul TIC DORA și responsabilitatea de securitate conform GDPR.

Poziția Clarysec este directă: SSPM nu trebuie tratat ca încă un tablou de bord. Trebuie integrat în SMSI, conectat la responsabilitatea pentru risc, mapat la obligațiile legale, susținut prin politici și testat prin dovezi recurente.

Aici devin practice Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls și modelele de politici Clarysec. Acestea ajută la transformarea proliferării SaaS într-un model de control pe care un auditor îl poate înțelege și pe care un organism de conducere îl poate supraveghea.

De ce managementul posturii de securitate SaaS a devenit o problemă de conformitate

SaaS era tratat anterior ca „software rulat de altcineva”. Această încadrare nu mai poate fi susținută.

În cadrul NIS2, mulți furnizori cloud, SaaS, de infrastructură digitală, de servicii administrate și de securitate administrată pot intra sub incidența așteptărilor reglementate de securitate cibernetică, în funcție de sector, dimensiune, rol și criticitate. Mai important, organizațiile care se bazează pe SaaS trebuie să îl guverneze ca parte a propriilor măsuri de management al riscurilor. NIS2 Article 20 face organismele de conducere responsabile pentru aprobarea măsurilor de management al riscurilor de securitate cibernetică, supravegherea implementării și participarea la instruire. Article 21 impune măsuri tehnice, operaționale și organizaționale practice, inclusiv analiza riscurilor, politici, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziții și mentenanță securizate, testarea eficacității, igienă cibernetică, criptografie, securitate HR, controlul accesului, managementul activelor și autentificare multifactor acolo unde este cazul.

DORA ridică și mai mult standardul pentru entitățile financiare. Începând cu 17 ianuarie 2025, DORA se aplică multor organizații din sectorul financiar ca regim de reziliență operațională pentru entitățile aflate în domeniul de aplicare. DORA impune guvernanță TIC, identificarea și clasificarea activelor TIC și a funcțiilor susținute, controale de protecție și prevenire, gestionarea incidentelor, continuitate, testare și managementul riscurilor asociate terților TIC. Furnizorii SaaS care susțin funcții critice sau importante devin parte din perimetrul de dovezi DORA, în timp ce entitatea financiară reglementată rămâne responsabilă.

GDPR adaugă un strat de dovezi privind protecția datelor cu caracter personal. Article 5 impune integritate, confidențialitate și responsabilitate. Article 32 impune securitatea adecvată a prelucrării. În practică, o organizație trebuie să știe ce date cu caracter personal există, unde sunt prelucrate, cine le poate accesa, ce furnizori le prelucrează și ce măsuri de protecție le apără. O configurare greșită SaaS transformă aceste întrebări în întrebări urgente de evaluare a încălcării securității datelor.

ISO/IEC 27001:2022 este puntea. Clauzele 4.1 până la 4.4 cer organizației să definească contextul, cerințele părților interesate, domeniul de aplicare, interfețele și dependențele. Clauza 5 impune leadership, politică, roluri și responsabilități. Clauzele 6.1.1 până la 6.1.3 impun evaluarea riscurilor, tratarea riscurilor, Declarația de aplicabilitate și decizii privind riscul rezidual. Clauzele 8.1, 8.2 și 8.3 impun planificare operațională, evaluarea riscurilor și tratarea riscurilor. Clauzele 9 și 10 impun monitorizare, audit intern, revizuire de management și îmbunătățire.

Dacă nu puteți răspunde ce instrumente SaaS prelucrează date reglementate, cine le deține, cum sunt configurate, cine are acces de administrator, ce integrări sunt active și ce dovezi demonstrează că respectivul control funcționează, poziția dumneavoastră de conformitate este fragilă.

Modelul SSPM Clarysec: inventar, proprietate, configurație de referință, dovezi

Clarysec tratează managementul posturii de securitate SaaS ca pe o buclă de control repetabilă, nu ca pe un proiect unic de remediere.

1. Identificați fiecare serviciu SaaS, inclusiv SaaS neautorizat sau nedeclarat.
2. Desemnați un proprietar operațional și un proprietar tehnic.
3. Clasificați datele, utilizatorii, integrările și criticitatea operațională.
4. Aplicați configurații de referință securizate.
5. Revizuiți utilizatorii, administratorii, oaspeții, conturile de serviciu și domeniile de acces OAuth.
6. Activați jurnalizarea, alertarea și păstrarea jurnalelor.
7. Monitorizați partajarea publică și expunerea datelor.
8. Conectați furnizorii, contractele, acordurile de prelucrare a datelor și planificarea ieșirii.
9. Colectați dovezi pe baza unei cadențe definite.
10. Introduceți constatările în tratarea riscurilor, revizuirea de management și îmbunătățire.

Acest model se aliniază strâns cu controalele ISO/IEC 27002:2022 ISO/IEC 27002:2022, în special 5.9 inventarul informațiilor și al altor active asociate, 5.15 controlul accesului, 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, 8.2 drepturi de acces privilegiat, 8.3 restricționarea accesului la informații, 8.9 managementul configurației, 8.15 jurnalizare, 8.16 activități de monitorizare și 8.32 managementul schimbărilor.

Zenith Blueprint, în faza Controls in Action, Pasul 23 pentru controalele organizaționale, precizează:

Cloudul nu mai este o destinație, ci opțiunea implicită. De la stocare la colaborare, de la infrastructură la machine learning, organizațiile sunt construite tot mai mult pe straturi de medii terțe, abstractizate și administrate la distanță. Controlul 5.23 recunoaște această realitate și impune ca securitatea informației să fie abordată explicit în selecția, utilizarea și managementul serviciilor cloud, nu ca o idee ulterioară, ci ca principiu de proiectare încă de la început.

Acesta este nucleul SSPM. Nu este doar detectarea configurărilor greșite după producerea lor. Înseamnă includerea selecției, înrolării, operării, monitorizării și ieșirii din SaaS în sistemul de management.

Aceeași secțiune Zenith Blueprint explică realitatea responsabilității partajate într-un limbaj pe care fiecare membru al consiliului de administrație ar trebui să îl audă:

Furnizorii cloud securizează infrastructura, dar dumneavoastră rămâneți responsabili pentru datele, configurațiile, politicile de acces și pregătirea pentru răspuns la incidente. Un bucket de stocare configurat greșit, un tablou de bord expus public sau permisiuni excesive într-o configurație IAM cloud nu sunt eșecuri ale cloudului. Sunt eșecuri de guvernanță.

Furnizorul poate opera platforma, dar organizația rămâne responsabilă pentru configurația tenantului, identități, aprobări de acces, date expuse, integrări, fluxuri de răspuns la incidente și dovezi de conformitate.

Controlul 5.23 este ancora, dar SSPM are nevoie de o familie de controale

În Zenith Controls, controlul ISO/IEC 27002:2022 5.23, securitatea informației pentru utilizarea serviciilor cloud, este încadrat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea. Conceptul său de securitate cibernetică este Protect, cu capabilitate operațională în securitatea relațiilor cu furnizorii și domenii care acoperă guvernanța, ecosistemul și protecția.

Acest lucru contează deoarece SSPM nu este un singur control. Este o disciplină transversală de control.

Zenith Controls conectează 5.23 la relațiile cu furnizorii din 5.19 deoarece furnizorii SaaS sunt furnizori critici, însă 5.23 adaugă preocupări specifice SaaS, precum multi-tenancy, transparența locației datelor și responsabilitatea partajată. Conectează 5.23 la transferul de informații deoarece API-urile, integrările și fluxurile inter-SaaS mută datele în mod continuu. Conectează 5.23 la inventarul activelor deoarece organizațiile au nevoie de vizibilitate actuală asupra datelor stocate în cloud și a resurselor SaaS. De asemenea, conectează guvernanța cloud la monitorizare, restricționarea accesului, managementul configurației și supravegherea furnizorilor.

Pentru drepturi de acces, Zenith Controls mapează 5.18 la 5.15 controlul accesului, 5.16 managementul identității, 5.3 separarea atribuțiilor, 5.36 conformitatea cu politicile, regulile și standardele pentru securitatea informației și 8.2 drepturi de acces privilegiat. Pentru SSPM, aceasta înseamnă că revizuirea accesului nu este doar un exercițiu în foi de calcul. Este o dovadă operațională că ciclul de viață al identității, principiul privilegiului minim, separarea atribuțiilor și guvernanța accesului privilegiat funcționează în aplicațiile SaaS.

Fundamentul de politică: definiți ce înseamnă corect înainte de a cumpăra instrumente

Multe eșecuri SaaS încep deoarece limbajul politicilor este vag. „Utilizați instrumentele aprobate în mod securizat” nu este suficient. Politicile Clarysec definesc așteptări specifice privind registrele, accesul, jurnalizarea, configurația și revizuirea furnizorilor.

Pentru IMM-uri, Politica de utilizare a serviciilor cloud pentru IMM-uri Politica de utilizare a serviciilor cloud - IMM oferă un punct de plecare practic. Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3:

Un Registru al serviciilor cloud trebuie menținut de furnizorul IT sau de directorul general. Acesta trebuie să înregistreze: 5.3.1 Denumirea și scopul fiecărui serviciu cloud aprobat 5.3.2 Persoana sau echipa responsabilă (Proprietar de aplicație) 5.3.3 Tipurile de date stocate sau prelucrate 5.3.4 Țara sau regiunea în care sunt stocate datele 5.3.5 Permisiunile de acces ale utilizatorilor și conturile administrative 5.3.6 Detaliile contractuale, datele de reînnoire și contactele de suport

Această clauză este nucleul operațional al SSPM. Oferă auditorilor primul obiect de dovadă: un registru care conectează utilizarea SaaS la proprietari, date, geografie, acces și contracte.

Aceeași Politică de utilizare a serviciilor cloud pentru IMM-uri, din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.2, definește setările de referință:

Cerințe privind configurația de securitate 6.2.1 Următoarele trebuie activate pe toate platformele cloud: 6.2.2 Autentificare multifactor (MFA) pentru conturile administrative și de utilizator 6.2.3 Setări privind complexitatea parolei (minimum 10 caractere, fără reutilizare) 6.2.4 Jurnalizarea activităților pentru tentativele de autentificare și accesul la date 6.2.5 Restricții de acces (de exemplu, liste de permitere IP, acolo unde sunt acceptate) 6.2.6 Accesul administrativ trebuie limitat la persoane nominale sau furnizori de suport autorizați. 6.2.7 Conținutul partajat public trebuie monitorizat periodic pentru a preveni scurgerea de date. 6.2.8 Când conturile de utilizator nu mai sunt necesare, accesul trebuie revocat imediat, iar orice date reziduale trebuie revizuite și arhivate sau șterse.

Pentru mediile enterprise, Politica de utilizare a serviciilor cloud Politica de utilizare a serviciilor cloud atribuie o guvernanță centralizată mai puternică. Din secțiunea „Cerințe de guvernanță”, clauza de politică 5.3:

Fiecare serviciu cloud trebuie să aibă un proprietar de serviciu desemnat, responsabil pentru managementul ciclului de viață al activului informațional, guvernanța utilizării, urmărirea bugetului și monitorizarea continuă a conformității.

Această propoziție închide o lacună de audit comună. Dacă nimeni nu deține un serviciu SaaS, nimeni nu deține abaterile de la configurația de referință, recertificarea accesului, expunerea datelor, deciziile de reînnoire, contactul pentru incidente sau planificarea ieșirii.

Guvernanța privilegiilor trebuie să fie, de asemenea, explicită. Politica privind gestionarea conturilor de utilizator și a privilegiilor pentru IMM-uri Politica privind gestionarea conturilor de utilizator și a privilegiilor - IMM, din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.4, prevede:

Revizuirea drepturilor de acces și jurnalizare 6.4.1 O revizuire a tuturor conturilor de utilizator și privilegiilor trebuie efectuată la fiecare șase luni. 6.4.2 În timpul revizuirilor, responsabilul IT trebuie să valideze dacă fiecare cont rămâne activ, necesar și alocat cu permisiunile corecte. 6.4.3 Jurnalele privind crearea conturilor, dezactivarea accesului și modificările de privilegii trebuie păstrate în siguranță timp de cel puțin 12 luni.

Pentru SaaS, fiecare platformă critică are nevoie de un ciclu definit de revizuire a accesului, chiar dacă platforma este administrată de o echipă operațională și nu de IT central.

Jurnalizarea trebuie să fie și ea explicită. Politica de jurnalizare și monitorizare pentru IMM-uri Politica de jurnalizare și monitorizare - IMM, din secțiunea „Cerințe de guvernanță”, clauza de politică 5.5, prevede:

Servicii cloud și jurnalizarea terților 5.5.1 Pentru platformele unde jurnalizarea nu se află sub control direct IT (de exemplu, e-mail SaaS), se aplică următoarele cerințe: 5.5.1.1 Jurnalizarea trebuie activată și configurată acolo unde este disponibilă 5.5.1.2 Alertele trebuie direcționate către furnizorul de suport IT 5.5.1.3 Contractele trebuie să oblige furnizorii să păstreze jurnalele timp de cel puțin 12 luni și să ofere acces la cerere

În final, guvernanța furnizorilor SaaS trebuie documentată. Politica de securitate privind terții și furnizorii pentru IMM-uri Politica de securitate privind terții și furnizorii - IMM, din secțiunea „Cerințe de implementare a politicii”, clauza de politică 6.3, prevede:

Monitorizarea continuă a securității furnizorilor 6.3.1 Furnizorii critici sau cu risc ridicat trebuie revizuiți cel puțin anual. Revizuirea trebuie să verifice: 6.3.1.1 Utilizarea continuă a metodelor de acces securizate 6.3.1.2 Certificări de securitate valide sau dovezi de control actualizate 6.3.1.3 Istoricul incidentelor sau problemele raportate 6.3.1.4 Conformitatea contractuală cu clauzele de securitate 6.3.2 Aceste revizuiri trebuie documentate și păstrate împreună cu înregistrarea furnizorului. Acțiunile ulterioare trebuie urmărite clar. 6.3.3 Acolo unde furnizorii administrează infrastructură IT sau aplicații, monitorizarea poate include: 6.3.3.1 Solicitarea jurnalelor de audit 6.3.3.2 Revizuirea activității conturilor 6.3.3.3 Confirmarea faptului că nu a avut loc acces neautorizat

Împreună, aceste politici transformă SSPM dintr-o aspirație de securitate într-un model operațional aplicabil.

Un sprint de 30 de zile pentru dovezi SSPM

Un CISO sau un manager de conformitate poate începe practic cu un sprint de 30 de zile pentru dovezi. Selectați cele cinci platforme SaaS cele mai importante pentru datele reglementate sau activitățile critice. Candidații tipici includ Microsoft 365 sau Google Workspace, CRM, ticketing, HRIS, automatizare financiară, suport clienți și analytics.

Săptămâna 1: Creați registrul SaaS

Utilizați câmpurile din clauza 5.3 a Politicii de utilizare a serviciilor cloud pentru IMM-uri ca registru minim. Pentru fiecare serviciu SaaS, înregistrați:

• Denumirea serviciului și scopul operațional
• Proprietarul aplicației și proprietarul tehnic
• Tipurile de date, inclusiv date cu caracter personal și categorii speciale de date, acolo unde este cazul
• Țara sau regiunea de stocare a datelor
• Grupurile de utilizatori și conturile de administrator
• Aplicațiile OAuth și integrările cu terți
• Proprietarul contractului, data de reînnoire și contactul de suport
• Criticitatea pentru activități
• Obligațiile aplicabile, cum ar fi NIS2, DORA, GDPR sau contractele cu clienții

Aceasta susține clauzele ISO/IEC 27001:2022 4.2 și 4.3 deoarece dependențele de reglementare, contractuale și de terți trebuie să modeleze domeniul de aplicare al SMSI. Susține, de asemenea, identificarea și clasificarea în stil DORA Article 8 a funcțiilor operaționale susținute TIC, a activelor informaționale, a activelor TIC și a dependențelor.

Săptămâna 2: Definiți configurații de referință securizate

Pentru fiecare platformă SaaS selectată, definiți 10 până la 15 controale de referință.

• MFA impusă pentru toți utilizatorii, cu MFA rezistentă la phishing pentru administratori, acolo unde este posibil
• Partajarea externă dezactivată implicit sau limitată la domenii aprobate
• Linkuri publice dezactivate sau limitate în timp
• Conturi de oaspeți revizuite lunar
• Roluri administrative atribuite persoanelor nominale
• Autentificare moștenită dezactivată
• Flux de aprobare pentru aplicații OAuth activat
• Domenii de acces OAuth cu risc ridicat blocate sau supuse aprobării de securitate
• Jurnalizare de audit activată
• Permisiuni de export al datelor restricționate
• Setări de păstrare aliniate la cerințele legale și operaționale
• Token-uri API revizuite și rotite
• Alerte de securitate direcționate către IT sau SOC
• Setări de prevenire a pierderii datelor activate acolo unde sunt acceptate
• Conturi de urgență („break-glass”) documentate și monitorizate

Zenith Blueprint, faza Controls in Action, Pasul 19, controlul 8.9 managementul configurației, explică de ce contează acest lucru:

Multe încălcări nu rezultă din defecte software, ci din alegeri slabe de configurare. Parole implicite lăsate neschimbate, servicii nesigure activate, porturi inutile deschise sau sisteme expuse la internet fără justificare. Controlul 8.9 asigură că fiecare sistem este construit pe o configurație de referință securizată și revizuit periodic pentru a preveni abaterile în timp.

Pentru SaaS, abaterile de la configurația de referință includ activarea partajării publice de către un proprietar operațional, aprobarea de către un administrator a unui acces larg pentru terți sau modificarea setărilor implicite de către un furnizor după lansarea unei funcționalități.

Săptămâna 3: Revizuiți accesul și integrările

Exportați utilizatorii, grupurile, administratorii și aplicațiile conectate. Pentru fiecare cont de administrator, confirmați persoana nominală, justificarea operațională, starea MFA, ultima autentificare, nivelul de privilegii, acoperirea de rezervă, preocupările privind separarea atribuțiilor și dovezile aprobării.

Pentru aplicațiile OAuth și integrări, confirmați proprietarul aplicației, datele accesate, permisiunile solicitate, statutul riscului asociat furnizorului, data ultimei utilizări, necesitatea continuării și dacă acordul a fost acordat de utilizator sau aprobat de administrator.

Zenith Blueprint, faza Controls in Action, Pasul 19, controlul 8.3 restricționarea accesului la informații, oferă principiul operațional:

Accesul la informații trebuie să fie atât de deschis cât este necesar, dar atât de restricționat cât este posibil.

Acest principiu se aplică nu doar persoanelor, ci și aplicațiilor, serviciilor și API-urilor. O integrare OAuth inactivă poate păstra accesul mult timp după ce angajatul sau proiectul care a creat-o a dispărut.

Săptămâna 4: Produceți dovezi pregătite pentru audit și tratarea riscurilor

Pentru fiecare platformă SaaS, stocați înregistrarea din registru, configurația de referință, capturi de ecran sau exporturi care dovedesc setările-cheie, aprobarea rezultată din revizuirea accesului, dovezile revizuirii administratorilor, dovezile revizuirii OAuth, dovezile de jurnalizare și alertare, înregistrarea revizuirii securității furnizorului, constatările deschise și acțiunile de tratare a riscurilor.

Apoi creați un rezumat de management de o pagină care prezintă constatările critice, proprietarii acțiunilor restante, lacunele de configurare cu risc ridicat nerezolvate, integrările neaprobate, lacunele de jurnalizare, excepțiile și deciziile necesare. Acest lucru susține clauza ISO/IEC 27001:2022 9.1 monitorizare, clauza 9.2 audit intern și clauza 9.3 revizuire de management. Creează, de asemenea, o punte practică spre responsabilitatea managementului conform NIS2 Article 20 și supravegherea de către organul de conducere conform DORA.

Mapare cross-compliance: un pachet de dovezi SSPM, mai multe obligații

Valoarea operațională a SSPM nu este doar o securitate mai bună. Este reducerea duplicării activităților de conformitate.

NIS2 Article 21 impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale. Inventarul SaaS susține managementul activelor. Configurațiile de referință susțin igiena cibernetică. MFA și revizuirea drepturilor de acces susțin controlul accesului. Jurnalizarea susține gestionarea incidentelor. Revizuirea furnizorilor susține securitatea lanțului de aprovizionare. Cadența dovezilor susține politicile și procedurile de evaluare a eficacității.

DORA impune entităților financiare să identifice și să clasifice funcțiile susținute TIC, activele informaționale, activele TIC și dependențele de terți. De asemenea, impune măsuri de protecție și prevenire, controale de acces, autentificare puternică, criptare, continuitate, testare, gestionarea incidentelor și guvernanța riscurilor asociate terților TIC. Un pachet de dovezi SSPM pentru SaaS poate susține registrele DORA, cartografierea dependențelor, supravegherea contractelor, drepturile de audit și planificarea ieșirii.

GDPR impune operatorilor să demonstreze conformitatea cu integritatea, confidențialitatea și responsabilitatea. Registrele SaaS identifică unde sunt prelucrate datele cu caracter personal. Configurațiile de referință reduc divulgarea neautorizată. Revizuirea drepturilor de acces susține principiul privilegiului minim. Jurnalizarea susține investigarea încălcărilor. Înregistrările despre furnizori susțin guvernanța persoanelor împuternicite și responsabilitatea.

NIST CSF 2.0 adaugă un strat util de comunicare. Funcția GOVERN impune ca cerințele de securitate cibernetică legale, de reglementare și contractuale să fie înțelese și gestionate. Rezultatele privind lanțul de aprovizionare impun roluri ale furnizorilor, contracte, verificare prealabilă, monitorizare și activități post-relație. Funcțiile IDENTIFY, PROTECT, DETECT, RESPOND și RECOVER se mapează natural la inventarul SaaS, controlul accesului, protecția datelor, jurnalizare, răspuns la incidente și recuperare.

Auditorii orientați spre COBIT 2019 și ISACA vor aborda de regulă SSPM prin guvernanță, obiective de management, responsabilitate pentru risc, operarea controalelor și asigurare. Ei vor întreba dacă deciziile SaaS sunt aliniate cu obiectivele organizației, dacă răspunsurile la risc sunt documentate, dacă responsabilitățile sunt atribuite și dacă activitățile de asigurare dovedesc funcționarea controalelor.

Lentila de audit: cum testează auditorii diferiți postura SaaS

Un program SSPM solid rezistă diferitelor stiluri de audit deoarece produce dovezi la nivelul potrivit.

Un auditor ISO/IEC 27001:2022 va începe cu domeniul de aplicare, părțile interesate, evaluarea riscurilor, Declarația de aplicabilitate și dovezile operaționale. Dacă este inclus controlul 5.23, va aștepta dovezi pentru selecția, utilizarea, managementul și ieșirea din serviciile cloud. Dacă sunt incluse controalele privind drepturile de acces, va eșantiona utilizatori și va întreba dacă schimbările de tip intrări, transferuri și plecări sunt reflectate în permisiunile SaaS.

Un evaluator DORA se va concentra pe funcții critice sau importante, dependența de terți TIC, completitudinea registrului, contracte, clasificarea incidentelor, testare și planificarea ieșirii. Dacă o platformă SaaS susține operațiuni de plată, integrarea clienților, tranzacționare, analiză de risc sau comunicări cu clienții, standardul de dovezi crește.

Un auditor GDPR sau un revizor de confidențialitate va întreba unde sunt stocate datele cu caracter personal, cine le poate accesa, ce exporturi și setări de partajare există, dacă persoanele împuternicite sunt guvernate, dacă jurnalele susțin evaluarea încălcărilor și dacă controalele sunt proporționale cu riscul.

Riscul asociat furnizorilor, responsabilitatea partajată și pregătirea pentru incidente

SSPM începe adesea cu configurația, dar nu se poate opri acolo. SaaS este și o problemă de risc asociat furnizorilor și de pregătire pentru incidente.

DORA impune entităților financiare să mențină registre ale contractelor de servicii TIC, să distingă aranjamentele care susțin funcții critice sau importante, să evalueze riscul de concentrare, să evalueze adecvarea furnizorului și să mențină strategii de ieșire. Contractele trebuie să trateze descrierile serviciilor, locația datelor, protecția disponibilității, autenticității, integrității și confidențialității, accesul la date, recuperarea și returnarea, asistența în caz de incident, cooperarea cu autoritățile, drepturile de reziliere, cerințele de securitate, drepturile de audit și suportul pentru tranziție.

NIS2 Article 21 include și securitatea lanțului de aprovizionare și impune entităților să ia în considerare vulnerabilitățile specifice furnizorilor direcți și furnizorilor de servicii, calitatea produselor și practicile de securitate cibernetică ale furnizorilor.

În practică, o revizuire SaaS critică trebuie să combine dovezi din chestionare de securitate, revizuirea contractului, statutul acordului de prelucrare a datelor, istoricul incidentelor, angajamentele privind nivelul serviciilor, accesul la jurnale, rapoarte de audit, dovezi de configurare și fezabilitatea ieșirii.

Lacuna de responsabilitate partajată apare când echipele presupun că certificarea furnizorului acoperă configurația tenantului. Nu o acoperă. Un furnizor poate opera o platformă securizată în timp ce clientul activează partajarea publică, lasă active conturi administrative inactive sau acordă domenii API excesive. SSPM închide această lacună.

Pregătirea pentru incidente este la fel de importantă. Raportarea incidentelor semnificative NIS2 include o avertizare timpurie în 24 de ore, o notificare în 72 de ore și un raport final nu mai târziu de o lună după notificarea de 72 de ore. DORA impune gestionarea incidentelor legate de TIC cu detectare, înregistrare, clasificare, escaladare, comunicare și notificare. Evaluarea unei încălcări a securității datelor cu caracter personal conform GDPR depinde, de asemenea, de înțelegerea la timp a ceea ce s-a întâmplat, a datelor afectate și a persoanelor impactate.

Dacă o aplicație OAuth suspectă a accesat fișiere ale clienților, trebuie să știți când a fost autorizată aplicația, ce utilizator a autorizat-o, ce domenii de acces au fost acordate, ce date au fost accesate, dacă datele au fost descărcate sau partajate, ce utilizatori sau clienți au fost afectați, dacă accesul rămâne activ și ce acțiuni de izolare au fost luate.

Fără jurnalizare și păstrarea jurnalelor, organizația poate fi forțată să facă presupuneri de tip worst-case. Aceasta crește expunerea juridică, presiunea comunicării cu clienții și incertitudinea de reglementare. Acolo unde un furnizor SaaS percepe costuri suplimentare pentru jurnale de audit, proprietarul riscului trebuie să accepte explicit riscul rezidual sau să aprobe nivelul de licențiere necesar. Această decizie trebuie inclusă în înregistrarea tratării riscurilor și în revizuirea de management.

Tipare comune de eșec SSPM

Aceleași tipare de eșec apar în toate sectoarele.

În primul rând, SaaS neautorizat sau nedeclarat este descoperit prin facturi, istoricul browserului sau jurnale SSO, nu prin procesul de achiziții. Remedierea nu înseamnă doar blocarea instrumentelor. Înseamnă un proces de solicitare ușor, pe care echipele operaționale îl pot utiliza.

În al doilea rând, proprietatea SaaS este neclară. CRM-ul este „deținut de Vânzări”, dar nimeni din Vânzări nu poate explica rolurile de administrator, token-urile API, exporturile de date sau setările de păstrare. Desemnați separat proprietari de aplicații și proprietari tehnici.

În al treilea rând, revizuirea drepturilor de acces este prea generică. Un revizor semnează „toți utilizatorii aprobați” fără a verifica rolurile cu risc ridicat, utilizatorii inactivi, oaspeții, colaboratorii externi sau conturile de serviciu. Revizuirea accesului SSPM trebuie prioritizată pe bază de risc.

În al patrulea rând, aplicațiile OAuth sunt ignorate. Multe organizații revizuiesc utilizatorii umani, dar nu permisiunile aplicație-la-aplicație. În SaaS modern, integrările pot fi mai puternice decât utilizatorii.

În al cincilea rând, configurațiile de referință există doar ca capturi de ecran din proiectul de certificare. Ele nu sunt monitorizate pentru abateri. Aliniați SSPM cu managementul configurației astfel încât verificările de referință să devină dovezi recurente.

În al șaselea rând, revizuirea furnizorilor și revizuirea posturii SaaS sunt separate. Achizițiile au contractul, IT are consola de administrare, Privacy are acordul de prelucrare a datelor, iar Securitatea are Registrul de riscuri. Auditorul vede fragmente. SSPM le aduce împreună.

Raportarea către management: faceți riscul SaaS vizibil pentru consiliu

NIS2 și DORA transformă guvernanța TIC și a securității cibernetice într-o problemă de management. ISO/IEC 27001:2022 impune, de asemenea, leadership, resurse, atribuirea rolurilor, monitorizare și revizuire de management.

Un raport SSPM eficace pentru management trebuie să răspundă la următoarele întrebări:

• Ce servicii SaaS critice sunt în domeniul de aplicare?
• Ce procese reglementate depind de ele?
• Care conțin date cu caracter personal sau date sensibile ale organizației?
• Care au revizuiri ale accesului restante?
• Care au lacune de configurare cu risc ridicat nerezolvate?
• Care au aplicații OAuth sau integrări neaprobate?
• Cărui furnizor îi lipsesc dovezi de securitate actuale?
• Ce lacune de jurnalizare afectează raportarea incidentelor?
• Ce excepții necesită acceptarea riscului?
• Ce investiții sau decizii sunt necesare?

Acest lucru transformă SSPM dintr-un proiect tehnic de remediere într-o contribuție de guvernanță. De asemenea, îl face pe CISO mai eficace, deoarece acceptarea riscului se mută la nivelul potrivit.

Transformați postura SaaS în dovezi pregătite pentru audit

Dacă organizația dumneavoastră se bazează pe SaaS pentru date reglementate, operațiuni financiare, suport clienți, HR, colaborare, inginerie sau analytics, SSPM nu mai este opțional. Face parte din igiena cibernetică, managementul riscurilor TIC, responsabilitatea privind protecția datelor cu caracter personal și pregătirea pentru audit.

Clarysec vă poate ajuta să treceți de la constatări SaaS dispersate la un program structurat, bazat pe dovezi, utilizând:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pentru structurarea implementării la nivelul utilizării cloud, restricționării accesului și managementului configurației.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pentru maparea controalelor ISO/IEC 27002:2022 la NIS2, DORA, GDPR, NIST CSF 2.0 și așteptările de audit.
• Modele de politici Clarysec, precum Politica de utilizare a serviciilor cloud Politica de utilizare a serviciilor cloud, Politica de utilizare a serviciilor cloud pentru IMM-uri Politica de utilizare a serviciilor cloud - IMM, Politica privind gestionarea conturilor de utilizator și a privilegiilor pentru IMM-uri Politica privind gestionarea conturilor de utilizator și a privilegiilor - IMM, Politica de jurnalizare și monitorizare pentru IMM-uri Politica de jurnalizare și monitorizare - IMM și Politica de securitate privind terții și furnizorii pentru IMM-uri Politica de securitate privind terții și furnizorii - IMM, pentru a crea reguli operaționale aplicabile.

Începeți cu cele cinci platforme SaaS cu cel mai ridicat risc. Desemnați proprietari. Colectați date, acces, configurație, integrări, jurnale și dovezi privind furnizorii. Transformați constatările în acțiuni de tratare a riscurilor și decizii de management.

Așa devine managementul posturii de securitate SaaS mai mult decât o categorie de instrumente. Devine o disciplină de conformitate defensabilă pentru 2026.

Descărcați modelele de politici Clarysec, utilizați Zenith Blueprint pentru a planifica sprintul de 30 de zile pentru dovezi SSPM și mapați controalele SaaS cu Zenith Controls înainte ca următorul audit să găsească lacunele în locul dumneavoastră.