
Un client al unui serviciu cloud vrea să știe ce măsuri de protecție operează furnizorul și care rămân în responsabilitatea sa. Oficiul Federal German pentru Securitatea Informației (BSI) publică Cloud Computing Compliance Criteria Catalogue, C5, ca bază structurată pentru examinarea acestei asigurări. Pentru un CTO, pregătirea înseamnă ca limita serviciului, implementarea controalelor și înregistrările operaționale să poată fi inspectate, nu doar strângerea unor politici.
C5 este un catalog de criterii folosit pentru atestarea independentă, nu o certificare de tip ISO. Documentația BSI privind C5 este referința principală. Începeți prin a conveni cu auditorul independent asupra ediției aplicabile, a obiectivului de asigurare și a perimetrului examinării.
Descrieți serviciul cloud, locațiile de operare, limitele organizaționale și dependențele. Un raport care acoperă un serviciu nu acoperă automat fiecare produs aflat sub aceeași marcă. Identificați componentele de producție, interfețele de administrare, operațiunile de suport și serviciile externe care pot afecta afirmațiile de asigurare.
Descrierea sistemului ar trebui să îi permită unei persoane din exterior să înțeleagă cum intră datele clienților în serviciu, cum circulă prin el și cum îl părăsesc. Includeți căile de administrare, procesele de implementare, monitorizarea securității, copiile de rezervă și împărțirea responsabilităților între echipe. Explicați caracteristicile relevante ale serviciului și condițiile de operare, în loc să înlocuiți textul narativ cu diagrame de arhitectură.
Rezolvați aceste întrebări de perimetru înainte de a colecta dovezi:
Oferiți excluderilor o justificare explicită. Dacă o implementare veche este exclusă, asigurați-vă că declarațiile adresate clienților nu sugerează că aceasta este acoperită. Livrabilul este o descriere versionată a sistemului, susținută de înregistrări privind arhitectura, dependențele și responsabilitățile.
Asigurarea C5 este exprimată, în general, printr-un raport de atestare al auditorului. Tipul 1 se referă la proiectarea și implementarea controalelor la un anumit moment. Tipul 2 examinează în plus eficacitatea funcționării pe parcursul unei perioade specificate.
| Decizie | Tipul 1 | Tipul 2 |
|---|---|---|
| Limită temporală | O dată specificată | O perioadă de examinare specificată |
| Accentul dovezilor | Proiectare și implementare adecvate | Proiectare, implementare și funcționare în timp |
| Implicație pentru planificare | Stabilirea stării controalelor la data de referință | Păstrarea înregistrărilor operaționale pe toată durata perioadei |
Tipul 1 poate fi o etapă utilă la construirea unui mediu de control, dar nu răspunde la aceeași întrebare ca tipul 2. Confirmați ce solicită efectiv clienții înainte de a alege un raport intermediar.
Conveniți asupra perioadei și a așteptărilor privind dovezile cu auditorul. Nu presupuneți o durată universală de observare. O procedură scrisă spre sfârșitul unei perioade nu poate stabili că un control a funcționat mai devreme. La fel, un test actual reușit nu șterge un eșec din trecut.
Ca metodă practică de pregătire, construiți un registru al dovezilor care leagă fiecare criteriu aplicabil de controlul implementat, de proprietar, de limita serviciului, de sursa dovezilor, de frecvența revizuirii și de lacunele nerezolvate. Înregistrați deciziile privind aplicabilitatea și justificarea lor; evitați să marcați un criteriu drept irelevant doar pentru că implementarea ar fi dificilă.
Separați trei întrebări: ce ar trebui să se întâmple, ce este implementat și ce s-a întâmplat efectiv. O politică răspunde la prima. Înregistrările de configurare pot susține a doua. Tichetele, jurnalele, aprobările și rezultatele testelor o susțin pe a treia.
| Domeniu de control | Dovezi de implementare | Dovezi operaționale |
|---|---|---|
| Administrarea identităților | Definiții ale rolurilor, configurarea accesului privilegiat | Înregistrări privind sosirile și plecările, revizuiri ale accesului, revocări |
| Gestionarea modificărilor | Cale de implementare protejată, reguli de aprobare | Modificări, aprobări, rezultate ale testelor, revizuiri ale modificărilor de urgență |
| Gestionarea incidentelor | Procedură de răspuns, responsabilități de escaladare | Înregistrări ale incidentelor, exerciții, acțiuni corective |
| Reziliență | Configurarea copiilor de rezervă, obiective de recuperare | Teste de restaurare, rezultate ale recuperării, acțiuni ulterioare |
| Gestionarea furnizorilor | Inventarul dependențelor, procedura de evaluare | Revizuiri ale rapoartelor furnizorilor, evaluări ale excepțiilor |
Acestea sunt exemple practice, nu o listă completă de verificare C5. Folosiți catalogul și perimetrul convenite pentru a stabili acoperirea necesară, inclusiv pentru controalele organizaționale, de personal, fizice și tehnice.
Pentru fiecare export sau captură de ecran, păstrați sistemul sursă, data colectării, perioada relevantă, filtrele și persoana care a realizat colectarea. Explicați dacă reprezintă întreaga populație sau un element selectat. Auditorii trebuie să înțeleagă populația din care selectează eșantioanele; un dosar care conține doar exemple reușite nu este suficient.
Preferați înregistrările care păstrează actorul, marcajul temporal, acțiunea și rezultatul. Protejați dovezile împotriva modificărilor neautorizate și evitați expunerea inutilă a datelor clienților. Acolo unde este necesară anonimizarea parțială, păstrați suficient context pentru ca evaluatorul să înțeleagă ce dovedește înregistrarea.
Asigurarea oferită de un furnizor de infrastructură poate susține securitatea fizică sau controalele platformei de bază. Ea nu stabilește că autorizarea la nivel de tenant a aplicației dumneavoastră funcționează. Documentați dependența, perimetrul raportului relevant, perioada, excepțiile și responsabilitățile pe care echipa dumneavoastră trebuie să le îndeplinească în continuare.
Controalele complementare ale clienților au nevoie, de asemenea, de o formulare practică. „Clientul este responsabil pentru securitate” este prea larg. Specificați sarcini precum administrarea utilizatorilor tenantului, configurarea federării identităților sau revizuirea politicilor de acces controlate de client. Mențineți aceste responsabilități consecvente în descrierea sistemului, în documentația serviciului și în aranjamentele contractuale.
Începeți cu o evaluare a lacunelor în raport cu criteriile convenite. Distingeți implementarea lipsă de dovezile lipsă: acestea necesită remedii diferite. O revizuire nedocumentată poate necesita înregistrări mai bune; o revizuire a accesului care nu a avut loc niciodată necesită un control operațional.
Atribuiți fiecărei lacune un proprietar, o acțiune de remediere, dependențele și un termen-țintă. Prioritizați problemele care afectează separarea tenanților, accesul privilegiat, modificările în producție, răspunsul la incidente și capacitatea de recuperare, în funcție de riscurile serviciului, nu doar cele mai ușoare sarcini de documentare.
Înainte de perioada de tip 2, verificați dacă controalele recurente au calendare realizabile și înregistrări durabile. Confirmați cine le realizează în caz de absență sau de fluctuație a personalului. Pentru controalele declanșate de evenimente, cum ar fi încetarea conturilor, asigurați-vă că populația care declanșează evenimentul poate fi identificată.
Realizați o parcurgere de pregătire cu dovezi reprezentative. Urmăriți o modificare de la solicitare până la implementare, un administrator care pleacă până la revocare și un exercițiu de recuperare până la acțiunea corectivă. Acest lucru scoate la iveală predări de responsabilitate defectuoase pe care o revizuire a politicilor le poate rata.
În timpul examinării, întrețineți un registru al solicitărilor, cu proprietari și stadiul răspunsurilor. Păstrați înregistrările originale disponibile, explicați deschis discrepanțele și urmăriți remedierea separat de dovezile istorice. Nu rescrieți înregistrările vechi pentru a le face să pară conforme. Auditorul stabilește modul în care constatările afectează testarea și opinia.
Să presupunem, cu titlu ilustrativ, că un furnizor operează o aplicație multi-tenant într-o singură regiune, folosește un furnizor extern de infrastructură și urmărește o asigurare de tip 2. Echipa sa controlează lansările aplicației, permisiunile tenanților, administrarea producției și procedurile de recuperare.
Descrierea perimetrului identifică aplicația, baza de date, planul de management, instrumentele de suport și dependența de infrastructură. Ea explică ce controale de bază sunt moștenite și care rămân în responsabilitatea furnizorului aplicației.
Pentru izolarea tenanților, echipa înregistrează designul autorizării, testele negative automate, constatările testelor de securitate și aprobările lansărilor. Ea păstrează, de asemenea, înregistrări ale modificărilor care arată când s-a schimbat logica de autorizare. Raportul furnizorului de infrastructură este o dovadă de susținere privind dependența, nu o dovadă a izolării aplicației.
Pentru accesul privilegiat, echipa păstrează populația de administratori, aprobările acordărilor, deciziile de revizuire și înregistrările eliminărilor. Să presupunem că o revizuire descoperă un cont de suport nefolosit. Echipa înregistrează descoperirea, revocarea, evaluarea expunerii și acțiunea preventivă. Acest lucru este mai credibil decât transmiterea doar a listei curățate de conturi.
Pentru recuperare, ea păstrează rezultatul unui test de restaurare care arată ce a fost recuperat, timpul scurs, verificările de integritate a datelor și limitările nerezolvate. Un job de backup configurat nu demonstrează, singur, capacitatea de recuperare. Fiecare set de dovezi are un proprietar și o perioadă definită, astfel încât auditorul să poată lega înregistrările de controlul examinat.
ISO/IEC 27001 se referă la un sistem de management al securității informației cu perimetru definit. SOC 2 este un raport de atestare care folosește propriile criterii și propriul context de raportare. C5 se concentrează pe asigurarea serviciilor cloud în baza catalogului BSI.
Evaluările de risc, controalele de acces, procedurile privind incidentele și înregistrările operaționale existente pot susține mai multe programe. Reutilizați-le prin corespondențe specifice versiunii și perimetrului, apoi verificați diferențele de cerințe sau de raportare. Un control comun nu înseamnă echivalență automată între cadre.
Alegeți portofoliul de asigurare în funcție de cerințele reale ale clienților și de riscurile serviciului. C5 nu este obligatoriu în mod universal pentru fiecare furnizor de cloud; cerințele din licitații, contracte sau din normele sectoriale aplicabile necesită o analiză separată. Nici un raport C5, nici un alt document de asigurare nu stabilește, în mod independent, conformitatea cu RGPD sau NIS2.
Clienții au nevoie de descrierea sistemului, de data sau perioada acoperită, de opinia efectivă, de excepții și de limitele responsabilităților, nu doar de eticheta raportului. Atunci când partajați rapoartele, respectați confidențialitatea contractuală și oferiți context pentru evaluarea clientului.
Explicați stadiul remedierii fără a sugera că remedierile ulterioare schimbă opinia istorică. Dacă perioada raportului precedă o modificare majoră de arhitectură, identificați această limitare. Conveniți asupra examinărilor recurente în funcție de așteptările clienților și de modificările operaționale, în loc să tratați atestarea ca pe o acreditare atemporală.
Secani ajută echipele să lege implementarea controalelor și dovezile de cerințe revizuite. Modelați serviciul și dependențele, atribuiți proprietari și evaluatori, atașați înregistrările justificative și transformați lacunele de dovezi în sarcini. Păstrați explicită aprobarea umană pentru corespondențe și concluzii. Modelul de pregătire pentru audit ajută la păstrarea perimetrului și a responsabilității din spatele fiecărei afirmații.
BSI publică catalogul. Un auditor independent realizează examinarea și emite raportul de atestare; confirmați cu acel auditor cadrul de asigurare aplicabil și condițiile angajamentului.
Nu inventați o înregistrare de incident. Păstrați dovezi că procesul a fost implementat și, acolo unde este cazul, exersat. Conveniți cu auditorul asupra modului în care absența evenimentelor afectează testarea.
Luați un serviciu de producție reprezentativ și pregătiți-i descrierea perimetrului, matricea responsabilităților și registrul dovezilor. Revizuiți aceste trei livrabile împreună cu viitorul auditor înainte de a asambla un pachet amplu de dovezi.
Secani conectează domeniile de aplicare, dovezile, sarcinile și agenții IA într-un spațiu de lucru comun.
Puneți întrebări practice despre calificare, experiența în sector, așteptările privind dovezile, planificare, independență și costul total al evaluării.
Citiți certificatele ISO și rapoartele SOC 2 în context: perimetru, perioadă, excepții, responsabilitățile clientului și dovezile de remediere.
Planificați un audit intern independent, bazat pe dovezi, și duceți constatările prin acțiuni corective până la verificarea eficacității.