Dowody audytowe dla chmury obliczeniowej w ISO 27001, NIS2 i DORA

Maria, pełniąca funkcję CISO w szybko rozwijającej się spółce zajmującej się analityką finansową, miała sześć tygodni do zbiegu trzech terminów. Audyt nadzoru ISO 27001:2022 był już zaplanowany. NIS2 przeniosła spółkę na nowy poziom odpowiedzialności kierownictwa jako podmiot ważny. DORA miała wkrótce zweryfikować, czy operacje fintech są w stanie wykazać cyfrową odporność operacyjną. Jednocześnie duży klient korporacyjny wstrzymywał podpisanie umowy do czasu, aż zespół Marii przejdzie szczegółowy przegląd zapewnienia bezpieczeństwa.

Spółka nie była niezabezpieczona. Uruchamiała obciążenia produkcyjne w AWS i Azure, korzystała z Microsoft 365 oraz kilku krytycznych platform SaaS, wymuszała MFA, wykonywała kopie zapasowe danych, skanowała podatności i zbierała logi chmurowe. Problemem były dowody.

Dowody były rozproszone między zrzutami ekranu ze Slacka, stronami wiki zespołów developerskich, eksportami z konsol chmurowych, folderami zakupowymi, umowami prawnymi i ustnymi zapewnieniami właścicieli platform. Gdy audytor pytał: „Proszę pokazać, jak kontrolujecie swoje środowisko chmurowe”, link do strony zgodności dostawcy chmury nie wystarczał. Certyfikaty dostawcy potwierdzały zabezpieczenia po stronie dostawcy. Nie potwierdzały części modelu współdzielonej odpowiedzialności należącej do Marii.

W tym miejscu zawodzi wiele programów gromadzenia dowodów audytowych bezpieczeństwa chmury. Nie dlatego, że brakuje zabezpieczeń, lecz dlatego, że organizacja nie potrafi wykazać w uporządkowany i identyfikowalny sposób, które odpowiedzialności należą do dostawcy, które do klienta, jak skonfigurowano zabezpieczenia SaaS i IaaS, jak egzekwowane są zobowiązania dostawców oraz jak dowody są przechowywane dla audytorów, regulatorów i klientów.

Zgodność chmury obliczeniowej nie jest już technicznym załącznikiem. Dla dostawcy SaaS objętego NIS2, podmiotu finansowego objętego DORA albo dowolnej organizacji ISO 27001:2022 korzystającej z IaaS, PaaS i SaaS, ład chmury obliczeniowej jest częścią zakresu SZBI, planu postępowania z ryzykiem, cyklu życia dostawcy, procesu obsługi incydentów, rozliczalności w zakresie prywatności i przeglądu zarządzania.

Cel praktyczny jest prosty: zbudować jedną architekturę dowodów chmurowych gotową na kontrolę regulatora, która odpowiada na pytania ISO 27001:2022, NIS2, DORA, GDPR, zapewnienia dla klientów i audytu wewnętrznego bez odtwarzania dowodów osobno dla każdych ram.

Chmura obliczeniowa zawsze jest w zakresie, nawet gdy infrastruktura jest outsourcowana

Pierwszą pułapką audytową jest założenie, że outsourcowana infrastruktura znajduje się poza SZBI. Nie znajduje się. Outsourcing zmienia granicę kontroli, ale nie znosi odpowiedzialności.

ISO/IEC 27001:2022 wymaga, aby organizacja zdefiniowała swój kontekst, zainteresowane strony, zakres SZBI, interfejsy, zależności i procesy. W organizacji działającej przede wszystkim w chmurze dostawca tożsamości, konto hostingu w chmurze, CRM, platforma poczty elektronicznej, hurtownia danych, potok CI/CD, narzędzie zgłoszeniowe i usługa kopii zapasowych często stanowią podstawową infrastrukturę biznesową.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint podkreśla to w fazie ISMS Foundation & Leadership, Step 2, Stakeholder Needs and ISMS Scope:

„Jeśli outsourcujesz infrastrukturę IT do dostawcy usług chmurowych, nie wyłącza jej to z zakresu; przeciwnie, obejmujesz zakresem zarządzanie tą relacją oraz aktywa chmurowe, ponieważ bezpieczeństwo Twoich danych w chmurze pozostaje Twoją odpowiedzialnością.”

To stwierdzenie stanowi punkt zaczepienia w audycie. Zakres nie powinien mówić: „AWS jest wyłączony, ponieważ zarządza nim Amazon”. Powinien wskazywać, że aktywa informacyjne i procesy związane z usługami hostowanymi w AWS są objęte zakresem, w tym zarządzanie zabezpieczeniami chmury, tożsamością, rejestrowaniem zdarzeń, szyfrowaniem, kopiami zapasowymi, zapewnieniem po stronie dostawcy i reagowaniem na incydenty.

W ISO 27001:2022 wspiera to klauzule 4.1 do 4.4 dotyczące kontekstu, zainteresowanych stron, zakresu i procesów SZBI. W NIS2 wspiera oczekiwania Article 21 dotyczące analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego pozyskiwania i utrzymania, kontroli dostępu, zarządzania aktywami, kryptografii, skuteczności zabezpieczeń i MFA tam, gdzie ma to zastosowanie. W DORA wspiera zasadę, że podmioty finansowe pozostają odpowiedzialne za ryzyko ICT także wtedy, gdy usługi ICT są outsourcowane.

Pytanie nie brzmi, czy dostawca chmury jest bezpieczny. Pytanie brzmi, czy zarządzasz sposobem korzystania z dostawcy, poprawnie konfigurujesz swoją część, monitorujesz usługę, zarządzasz zobowiązaniami dostawcy i przechowujesz dowody.

Współdzielona odpowiedzialność musi stać się współdzielonymi dowodami

Dostawcy chmury wyjaśniają współdzieloną odpowiedzialność. Audytorzy sprawdzają, czy została wdrożona operacyjnie.

W IaaS dostawca zwykle zabezpiecza obiekty fizyczne, podstawową infrastrukturę i hypervisor. Klient kontroluje tożsamość, konfigurację obciążeń, utwardzanie systemu operacyjnego, bezpieczeństwo aplikacji, klasyfikację danych, ustawienia szyfrowania, reguły sieciowe, rejestrowanie zdarzeń, kopie zapasowe, wdrażanie poprawek i reagowanie na incydenty.

W SaaS dostawca kontroluje większość operacji platformowych, ale klient nadal kontroluje konfigurację tenanta, użytkowników, role administratorów, integracje, udostępnianie danych, okres retencji, opcje rejestrowania i procedury eskalacji.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls traktuje ISO/IEC 27002:2022, zabezpieczenie 5.23, Information security for use of cloud services, jako centralne zabezpieczenie ładu chmury obliczeniowej o celu prewencyjnym w obszarach poufności, integralności i dostępności. Łączy usługi w chmurze obliczeniowej z relacjami z dostawcami, bezpiecznym transferem informacji, inwentarzem aktywów, zapobieganiem wyciekom danych, bezpieczeństwem punktów końcowych i sieci oraz praktykami bezpiecznego rozwoju oprogramowania.

Kluczowa interpretacja Zenith Controls wskazuje:

„Dostawcy usług chmurowych (CSP) działają jako dostawcy krytyczni, dlatego zastosowanie mają wszystkie środki kontroli dotyczące wyboru dostawców, kontraktowania i zarządzania ryzykiem w ramach 5.19. Jednak 5.23 idzie dalej, odnosząc się do ryzyk specyficznych dla chmury, takich jak wielodostępność, przejrzystość lokalizacji danych i modele współdzielonej odpowiedzialności.”

To rozróżnienie jest krytyczne. Same certyfikaty dostawcy nie spełniają wymagań zabezpieczenia 5.23 z Załącznika A. Potrzebne są dowody po stronie klienta potwierdzające, że usługa chmurowa jest objęta ładem, skonfigurowana, monitorowana i przeglądana.

Na tym polega różnica między posiadaniem zabezpieczeń chmury a posiadaniem zabezpieczeń chmury gotowych do audytu.

Zacznij od Rejestru usług chmurowych użytecznego dla audytorów

Najszybszym sposobem poprawy gotowości do audytu chmury jest utworzenie kompletnego Rejestru usług chmurowych. Nie powinien to być wykaz zakupowy ani eksport z finansów. Musi łączyć usługi w chmurze obliczeniowej z danymi, właścicielami, regionami, dostępem, umowami, krytycznością, znaczeniem regulacyjnym i dowodami.

Clarysec SME Cloud Usage Policy-sme Cloud Usage Policy-sme podaje zwięzłą i przyjazną audytowo konfigurację bazową w klauzuli 5.3:

„Rejestr usług chmurowych musi być utrzymywany przez dostawcę IT lub dyrektora generalnego (GM). Musi zawierać: 5.3.1 nazwę i cel każdej zatwierdzonej usługi chmurowej 5.3.2 osobę lub zespół odpowiedzialny (właściciel aplikacji) 5.3.3 typy danych przechowywanych lub przetwarzanych 5.3.4 kraj lub region, w którym dane są przechowywane 5.3.5 uprawnienia dostępu użytkowników i konta administracyjne 5.3.6 dane umowne, daty odnowienia i kontakty wsparcia”

Dla środowisk korporacyjnych Clarysec Cloud Usage Policy Cloud Usage Policy ustanawia szerszy mandat:

„Niniejsza polityka ustanawia obowiązkowe wymagania organizacji dotyczące bezpiecznego, zgodnego i odpowiedzialnego korzystania z usług chmury obliczeniowej w modelach dostarczania Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) oraz Software-as-a-Service (SaaS).”

Cloud Usage Policy wymaga scentralizowanego rejestru, którego właścicielem jest CISO, oraz zatwierdzonych konfiguracji bazowych dla środowisk chmurowych. Ten rejestr staje się fundamentem dowodowym dla kilku obowiązków jednocześnie.

W ISO 27001:2022 wspiera inwentarz aktywów, ład korzystania z chmury, relacje z dostawcami, kontrolę dostępu, wymogi prawne i umowne, postępowanie z ryzykiem oraz udokumentowane informacje. W NIS2 wspiera bezpieczeństwo łańcucha dostaw, zarządzanie aktywami, analizę ryzyka, obsługę incydentów i ciągłość. W DORA wspiera mapowanie aktywów i zależności ICT, rejestry zewnętrznych dostawców usług ICT, mapowanie funkcji krytycznych lub ważnych oraz analizę ryzyka koncentracji. W GDPR wskazuje, czy dane osobowe są przetwarzane, gdzie się znajdują, który dostawca działa jako podmiot przetwarzający oraz jakie warunki transferu lub powierzenia przetwarzania danych mają zastosowanie.

Jeżeli rejestr nie identyfikuje kategorii danych i regionów, dowody dotyczące prywatności i odporności będą niekompletne. Jeżeli nie identyfikuje właścicieli aplikacji, przeglądy dostępu będą pozbawione właścicielstwa. Jeżeli nie identyfikuje umów i dat odnowienia, nie da się przetestować klauzul bezpieczeństwa dostawców.

Uczyń ISO 27001:2022 osią dowodów chmurowych

ISO 27001:2022 jest najlepszą osią dowodów chmurowych, ponieważ łączy kontekst biznesowy, ryzyko, zabezpieczenia, dowody operacyjne, monitorowanie i doskonalenie.

Kluczowe wymagania ISO 27001:2022 istotne dla chmury obejmują:

• Klauzule 4.1 do 4.4 dotyczące kontekstu, zainteresowanych stron, zakresu SZBI, interfejsów, zależności i procesów.
• Klauzule 5.1 do 5.3 dotyczące przywództwa, polityki, ról, odpowiedzialności i rozliczalności.
• Klauzule 6.1.1 do 6.1.3 dotyczące oceny ryzyka, postępowania z ryzykiem, porównania z Załącznikiem A, Deklaracji stosowania i akceptacji ryzyka rezydualnego.
• Klauzulę 7.5 dotyczącą nadzorowanej udokumentowanej informacji.
• Klauzule 8.1 do 8.3 dotyczące planowania operacyjnego, wykonania oceny ryzyka i wykonania postępowania z ryzykiem.
• Klauzule 9.1 do 9.3 dotyczące monitorowania, pomiarów, audytu wewnętrznego i przeglądu zarządzania.
• Klauzulę 10 dotyczącą niezgodności, działań korygujących i ciągłego doskonalenia.

Zabezpieczenia z Załącznika A, które niosą największy ciężar dowodowy dla chmury, obejmują A.5.19 Information security in supplier relationships, A.5.20 Addressing information security within supplier agreements, A.5.21 Managing information security in the ICT supply chain, A.5.22 Monitoring, review and change management of supplier services, A.5.23 Information security for use of cloud services, A.5.24 do A.5.27 dotyczące zarządzania incydentami, A.5.29 Information security during disruption, A.5.30 ICT readiness for business continuity, A.5.31 Legal, statutory, regulatory and contractual requirements, A.5.34 Privacy and protection of PII, A.5.36 Compliance with policies, rules and standards for information security, A.8.8 Management of technical vulnerabilities, A.8.9 Configuration management, A.8.13 Information backup, A.8.15 Logging, A.8.16 Monitoring activities, A.8.24 Use of cryptography, A.8.25 Secure development life cycle, A.8.29 Security testing in development and acceptance oraz A.8.32 Change management.

W Zenith Blueprint, faza Controls in Action, Step 23, wyjaśnia usługi chmurowe językiem zrozumiałym dla audytorów:

„Przejście na usługi chmurowe wprowadza zasadnicze zmiany w modelu zaufania. Nie kontrolujesz już serwera, perymetru sieci ani hypervisora. Często nie wiesz nawet, gdzie fizycznie znajdują się dane. To, co kontrolujesz — i co ten środek kontroli egzekwuje — to zarządzanie tą relacją, widoczność tego, z czego korzystasz, oraz oczekiwania bezpieczeństwa stawiane dostawcom.”

Silny wpis w Deklaracji stosowania dla A.5.23 nie powinien ograniczać się do stwierdzenia: „Ma zastosowanie, dostawca chmury certyfikowany”. Powinien wyjaśniać, dlaczego zabezpieczenie ma zastosowanie, jakie ryzyka obsługuje, jak jest wdrożone i gdzie przechowywane są dowody.

Dodaj kolumnę lokalizacji dowodów do SoA lub narzędzia śledzenia zabezpieczeń. Audytorzy nie powinni musieć przeszukiwać poczty elektronicznej, systemów zgłoszeniowych i dysków współdzielonych, aby znaleźć dowód.

Stosuj jeden model dowodowy dla ISO 27001:2022, NIS2 i DORA

NIS2 i DORA wymagają udokumentowanego, opartego na ryzyku i nadzorowanego przez kierownictwo cyberbezpieczeństwa. Zakres wspólny jest znaczny, ale presja nadzorcza jest inna.

NIS2 ma zastosowanie do wielu podmiotów kluczowych i ważnych w UE, w tym dostawców infrastruktury cyfrowej, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, bankowości, infrastruktury rynków finansowych i dostawców cyfrowych. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego pozyskiwania i utrzymania, obsługi podatności, oceny skuteczności zabezpieczeń, cyberhigieny, szkoleń, kryptografii, kontroli dostępu, zarządzania aktywami oraz MFA lub bezpiecznej komunikacji tam, gdzie jest to właściwe.

W przypadku dowodów audytowych bezpieczeństwa chmury NIS2 pyta, czy ryzyka chmurowe i ryzyka dostawców są zarządzane jako część ryzyka świadczenia usług. Wprowadza także ustrukturyzowane raportowanie istotnych incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, powiadomienie o incydencie w ciągu 72 godzin i raport końcowy w ciągu jednego miesiąca.

DORA stosuje się od 17 stycznia 2025 r. do wielu podmiotów finansowych w UE i tworzy jednolite wymagania dotyczące zarządzania ryzykiem ICT, zgłaszania poważnych incydentów ICT, testowania cyfrowej odporności operacyjnej, wymiany informacji i ryzyka ICT związanego z zewnętrznymi dostawcami usług. Dla podmiotów finansowych jednocześnie zidentyfikowanych w NIS2, DORA jest traktowane jako sektorowy unijny akt prawny dla nakładających się obowiązków operacyjnych.

W przypadku chmury DORA jest bezpośrednia. Podmioty finansowe pozostają odpowiedzialne za ryzyko ICT, gdy usługi są outsourcowane. Potrzebują strategii dotyczących zewnętrznych dostawców usług ICT, rejestrów umów, ocen przedumownych, due diligence, praw audytu i dostępu, przesłanek rozwiązania umowy, analizy ryzyka koncentracji, kontroli podwykonawstwa oraz przetestowanych strategii wyjścia.

Zenith Controls mapuje ISO/IEC 27002:2022, zabezpieczenie 5.23, do EU NIS2 Article 21 oraz DORA Articles 28 to 31. Wskazuje także normy wspierające, takie jak ISO/IEC 27017 dla ról bezpieczeństwa chmury i monitorowania, ISO/IEC 27018 dla ochrony PII w chmurze publicznej, ISO/IEC 27701 dla zarządzania prywatnością w relacjach z podmiotami przetwarzającymi w chmurze, ISO/IEC 27036-4 dla monitorowania usług chmurowych i umów z dostawcami oraz ISO/IEC 27005 dla oceny ryzyka chmury.

Praktyczna konsekwencja jest prosta. Nie buduj oddzielnych pakietów dowodowych dla ISO 27001:2022, NIS2, DORA i GDPR. Zbuduj jedną architekturę dowodów chmurowych z mapowaniami właściwymi dla poszczególnych ram.

Umowy z dostawcami są dowodem działania zabezpieczenia, nie archiwum prawnym

Dowody audytowe chmury często załamują się na warstwie umownej. Bezpieczeństwo ma kwestionariusz dostawcy. Dział prawny ma MSA. Zakupy mają datę odnowienia. Inspektor ochrony danych (DPO) ma DPA. Nikt nie ma jednego widoku tego, czy umowa obejmuje klauzule bezpieczeństwa wymagane przez ISO 27001:2022, NIS2, DORA i GDPR.

Clarysec SME Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme wskazuje w klauzuli 5.3:

„Umowy muszą zawierać obowiązkowe klauzule obejmujące: 5.3.1 Poufność i nieujawnianie informacji 5.3.2 Obowiązki w zakresie bezpieczeństwa informacji 5.3.3 Terminy zgłaszania naruszeń ochrony danych (np. w ciągu 24–72 godzin) 5.3.4 Prawo do audytu lub dostępność dowodów zgodności 5.3.5 Ograniczenia dalszego podwykonawstwa bez zatwierdzenia 5.3.6 Warunki zakończenia, w tym bezpieczny zwrot lub zniszczenie danych”

Dla spójności audytowej przełóż te klauzule na macierz przeglądu umów. ISO 27001:2022, Załącznik A.5.20, oczekuje uzgodnienia wymagań bezpieczeństwa z dostawcami. GDPR Article 28 wymaga warunków dla podmiotu przetwarzającego obejmujących poufność, środki bezpieczeństwa, pomoc, podwykonawców przetwarzania, usunięcie lub zwrot danych oraz wsparcie audytu. DORA Article 30 wymaga szczegółowych postanowień umownych dla zewnętrznych dostawców usług ICT, w tym opisów usług, lokalizacji danych, bezpieczeństwa, pomocy przy incydentach, współpracy z organami, praw audytu, praw dostępu, zakończenia i ustaleń przejściowych. Bezpieczeństwo łańcucha dostaw w NIS2 również wymaga egzekwowalnej współpracy dostawców.

Zenith Controls mapuje ISO/IEC 27002:2022, zabezpieczenie 5.20, do umów z dostawcami i wskazuje powiązania z 5.19 relacje z dostawcami, 5.14 transfer informacji, 5.22 monitorowanie dostawców, 5.11 zwrot aktywów i 5.36 zgodność.

Kluczowe jest wdrożenie operacyjne. Jeżeli umowa chmurowa przyznaje dostęp do raportów SOC 2, audytorzy mogą zapytać, czy raport pozyskano, czy przejrzano wyjątki, czy śledzono działania naprawcze i czy ponownie oceniono ryzyko. Jeżeli umowa obiecuje zgłoszenie naruszenia, mogą zapytać, czy podręcznik postępowania z incydentami zawiera ścieżkę kontaktu z dostawcą i regulacyjne punkty decyzyjne. Jeżeli zmiany podwykonawców wymagają zatwierdzenia lub powiadomienia, mogą zapytać, czy powiadomienia o podwykonawcach przetwarzania są przeglądane przed akceptacją.

Umowa bez dowodów przeglądu jest archiwum. Umowa powiązana z ryzykiem dostawcy, zapisami monitorowania i procesami obsługi incydentów jest zabezpieczeniem.

Rejestrowanie i konfiguracja SaaS to częste ślepe punkty audytu

Ustalenia dotyczące chmury często pochodzą z SaaS, a nie z IaaS. Zespoły infrastrukturalne zwykle mają właścicieli inżynieryjnych, potoki rejestrowania, bazowe zabezpieczenia i zapisy zmian. Platformy SaaS są rozproszone między sprzedaż, HR, finanse, obsługę klienta, marketing i operacje. Każda z nich może przetwarzać dane wrażliwe lub regulowane.

Clarysec Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme odnosi się do tego bezpośrednio w klauzuli 5.5:

„5.5 Usługi chmurowe i rejestrowanie przez strony trzecie 5.5.1 Dla platform, na których rejestrowanie nie pozostaje pod bezpośrednią kontrolą IT (np. poczta elektroniczna SaaS), mają zastosowanie następujące wymagania: 5.5.1.1 Rejestrowanie musi być włączone i skonfigurowane tam, gdzie jest dostępne 5.5.1.2 Alerty muszą być kierowane do dostawcy wsparcia IT 5.5.1.3 Umowy muszą wymagać od dostawców przechowywania logów przez co najmniej 12 miesięcy i udostępniania ich na żądanie”

Dla przedsiębiorstw Cloud Usage Policy dodaje:

„Usługi chmurowe muszą być zintegrowane z SIEM organizacji na potrzeby ciągłego monitorowania.”

To wymaganie przenosi SaaS z kategorii „narzędzia biznesowego” do kategorii „monitorowanego systemu informatycznego”. Dowody powinny obejmować eksporty ustawień rejestrowania, potwierdzenie konektora SIEM, reguły alertów, zgłoszenia z triage, ustawienia okresu retencji i przeglądy dostępu administracyjnego.

Dla krytycznych SaaS przygotuj dowody dotyczące tworzenia kont administratorów, podejrzanych logowań, masowych pobrań, udostępniania publicznego, wyłączania MFA, tworzenia tokenów API, aktywności zewnętrznych gości i eskalacji uprawnień. Dla IaaS przygotuj CloudTrail lub równoważne rejestrowanie płaszczyzny sterowania, logi dostępu do pamięci masowej, zmiany IAM, logi przepływów tam, gdzie ma to zastosowanie, ustalenia CSPM, skany podatności, dowody poprawek, ustawienia szyfrowania, status kopii zapasowych, przeglądy grup bezpieczeństwa sieci i zgłoszenia zmian.

Metodyka audytu Zenith Controls dla zabezpieczenia 5.23 wskazuje, że audyt w stylu ISO/IEC 27007 może sprawdzać uprawnienia bucketów AWS S3, szyfrowanie, polityki IAM i rejestrowanie CloudTrail. Audytor ukierunkowany na COBIT może przeglądać konfiguracje alertów, zabezpieczenia DLP, wykorzystanie Microsoft 365 Secure Score i logi zarządzania zmianami. Perspektywa NIST SP 800-53A może testować zarządzanie kontami i monitorowanie, w tym czy obciążenia chmurowe są łatane, skanowane i monitorowane z taką samą rygorystycznością jak systemy wewnętrzne.

Różni audytorzy mówią różnymi dialektami. Dowody powinny być te same.

Zbuduj pakiet dowodowy gotowy na kontrolę regulatora dla jednej usługi SaaS i jednej usługi IaaS

Praktyczny przepływ pracy zaczyna się od jednej krytycznej platformy SaaS i jednego krytycznego środowiska IaaS. Na przykład Microsoft 365 dla współpracy oraz AWS dla hostingu produkcyjnego.

Krok 1: Zaktualizuj Rejestr usług chmurowych

Dla Microsoft 365 zapisz cel, właściciela, typy danych, region, konta administratorów, umowę, DPA, kontakt wsparcia, datę odnowienia i krytyczność. Dla AWS zapisz konto produkcyjne, regiony, kategorie danych, obciążenia, właściciela konta, status konta root, plan wsparcia, warunki umowne i powiązane usługi biznesowe.

Użyj pól z Cloud Usage Policy-sme jako minimalnego zestawu danych. Dodaj krytyczność, znaczenie regulacyjne i lokalizację dowodów.

Krok 2: Udokumentuj współdzieloną odpowiedzialność

Dla Microsoft 365 odpowiedzialności klienta obejmują cykl życia użytkownika, MFA, dostęp warunkowy, udostępnianie gościom, etykiety retencji, DLP tam, gdzie jest stosowane, rejestrowanie i eskalację incydentów. Dla AWS odpowiedzialności klienta obejmują IAM, reguły sieciowe, utwardzanie obciążeń, konfigurację szyfrowania, kopie zapasowe, rejestrowanie, wdrażanie poprawek i bezpieczeństwo aplikacji.

Dołącz dokumentację dostawcy dotyczącą współdzielonej odpowiedzialności, a następnie zmapuj każdą odpowiedzialność klienta do właściciela zabezpieczenia i źródła dowodów.

Krok 3: Zabezpiecz dowody konfiguracji

Dla Microsoft 365 wyeksportuj lub wykonaj zrzuty ekranu polityk MFA i dostępu warunkowego, ról administratorów, ustawień udostępniania zewnętrznego, rejestrowania audytowego, konfiguracji okresu retencji i działań związanych z oceną bezpieczeństwa. Dla AWS wyeksportuj politykę haseł IAM, status MFA dla uprawnień uprzywilejowanych, konfigurację CloudTrail, blokadę publicznego dostępu S3, status szyfrowania, przegląd grup bezpieczeństwa, zadania kopii zapasowych i status skanowania podatności.

Cloud Usage Policy wymaga, aby środowiska chmurowe były zgodne z udokumentowaną konfiguracją bazową zatwierdzoną przez architekta bezpieczeństwa chmury. Pakiet dowodowy powinien zawierać zarówno konfigurację bazową, jak i potwierdzenie zgodności.

Krok 4: Powiąż dowody dostawcy i prywatności

Dołącz umowę, DPA, listę podwykonawców przetwarzania, warunki zgłaszania naruszeń, raporty zapewnienia audytowego i dowody lokalizacji danych. Jeżeli przetwarzane są dane osobowe, zapisz, czy dostawca działa jako podmiot przetwarzający, jak obsługiwane jest usunięcie, jak działa wsparcie żądań osób, których dane dotyczą, oraz jakie zabezpieczenia transferu mają zastosowanie.

Dla DORA ustal, czy usługa chmurowa wspiera funkcję krytyczną lub ważną. Jeżeli tak, powiąż dowody z rejestrem zewnętrznych dostawców usług ICT, dokumentacją due diligence, prawami audytu, planem wyjścia i przeglądem ryzyka koncentracji.

Krok 5: Połącz rejestrowanie z reagowaniem na incydenty

Pokaż, że logi są włączone, przekierowane, przeglądane i wykorzystywane. Dołącz pulpity SIEM, reguły alertów i co najmniej jedno zamknięte zgłoszenie alertu. Następnie zmapuj przepływ pracy do punktów decyzyjnych raportowania NIS2 i DORA.

Dla NIS2 proces obsługi incydentów musi wspierać wczesne ostrzeżenie w ciągu 24 godzin, powiadomienie o incydencie w ciągu 72 godzin oraz raport końcowy w ciągu jednego miesiąca dla istotnych incydentów. Dla DORA proces incydentów ICT powinien klasyfikować incydenty według dotkniętych klientów, transakcji, czasu trwania, niedostępności, zasięgu geograficznego, wpływu na dane, krytyczności usługi i wpływu ekonomicznego.

Krok 6: Przechowuj dowody w sposób zdyscyplinowany

Clarysec Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme, klauzula 6.2, definiuje praktyczną dyscyplinę dowodową:

„6.2 Zbieranie i dokumentowanie dowodów 6.2.1 Wszystkie dowody muszą być przechowywane w scentralizowanym folderze audytowym. 6.2.2 Nazwy plików muszą jasno odnosić się do tematu audytu i daty. 6.2.3 Metadane (np. kto je zebrał, kiedy i z jakiego systemu) muszą być udokumentowane. 6.2.4 Dowody muszą być przechowywane przez co najmniej dwa lata lub dłużej, jeżeli wymagają tego certyfikacja albo umowy z klientami.”

Korporacyjna Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy wskazuje cel:

„Generowanie możliwych do obrony dowodów i ścieżki audytowej na potrzeby zapytań regulacyjnych, postępowań prawnych lub wniosków klientów o zapewnienie.”

Zrzut ekranu o nazwie „screenshot1.png” jest słabym dowodem. Plik o nazwie „AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png” jest silniejszy, ponieważ opisuje system, zabezpieczenie, datę i osobę zbierającą. Metadane mają znaczenie, ponieważ audytorzy muszą ufać temu, kiedy dowód został zebrany, kto go zebrał i z jakiego systemu.

Jak audytorzy testują to samo zabezpieczenie chmurowe

Najsilniejsze pakiety dowodów chmurowych są projektowane pod wiele perspektyw audytu. Audytorzy ISO 27001:2022 sprawdzają, czy zabezpieczenie znajduje się w SZBI, ocenie ryzyka, postępowaniu z ryzykiem i SoA. Asesorzy ukierunkowani na NIST testują wdrożenie techniczne. Audytorzy COBIT 2019 testują ład, wyniki dostawców i integrację procesów. Audytorzy prywatności koncentrują się na obowiązkach podmiotów przetwarzających, rezydencji danych, gotowości na naruszenia i prawach osób, których dane dotyczą. Przeglądy nadzorcze DORA koncentrują się na ryzyku ICT związanym z zewnętrznymi dostawcami usług i odporności.

Zenith Controls obejmuje te różnice metodyki audytu dla usług chmurowych, umów z dostawcami i monitorowania dostawców. Dla 5.22, Monitoring, review and change management of supplier services, podkreśla, że audytorzy mogą sprawdzać kwartalne protokoły przeglądów dostawców, raporty KPI, oceny raportów SOC, dzienniki zmian, oceny ryzyka, incydenty dostawców i śledzenie problemów. Dla 5.20, Addressing information security within supplier agreements, wskazuje próbkowanie umów pod kątem poufności, obowiązków bezpieczeństwa, zgłaszania naruszeń, praw audytu, zatwierdzania podwykonawców i warunków zakończenia.

Zabezpieczenia cross-compliance, które przenoszą główny ciężar audytu chmury

Model dowodów chmurowych gotowy na kontrolę regulatora opiera się na niewielkiej liczbie zabezpieczeń o wysokiej dźwigni. Te zabezpieczenia przenoszą znaczną część ciężaru zgodności w ISO 27001:2022, NIS2, DORA, GDPR, NIST i COBIT 2019.

NIST SP 800-53 Rev.5 dodaje głębię techniczną przez zarządzanie kontami, usługi systemów zewnętrznych, ciągłe monitorowanie, monitorowanie systemów i ochronę granic. COBIT 2019 dodaje głębię ładu przez zarządzanie relacjami z dostawcami, ryzyko dostawców, wymianę danych, bezpieczeństwo sieci i gotowość do zmian.

Normy ISO wspierające doprecyzowują model dowodowy. ISO/IEC 27017 zapewnia wytyczne specyficzne dla chmury dotyczące współdzielonych ról, konfiguracji maszyn wirtualnych i monitorowania aktywności klienta. ISO/IEC 27018 koncentruje się na ochronie PII w chmurze publicznej. ISO/IEC 27701 rozszerza obowiązki prywatności na operacje podmiotów przetwarzających i administratorów. ISO/IEC 27036-4 wspiera umowy z dostawcami chmurowymi i monitorowanie. ISO/IEC 27005 dotyczy oceny ryzyka chmury.

Przegląd zarządzania musi widzieć ryzyko chmury, nie tylko dostępność chmury

Jednym z najczęściej pomijanych artefaktów audytowych jest przegląd zarządzania. ISO 27001:2022 oczekuje, że przegląd zarządzania uwzględni zmiany, potrzeby zainteresowanych stron, trendy wyników, wyniki audytów, status postępowania z ryzykiem i możliwości doskonalenia. NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa i nadzorowały ich wdrożenie. DORA wymaga, aby organ zarządzający definiował, zatwierdzał, nadzorował i pozostawał odpowiedzialny za zarządzanie ryzykiem ICT.

Kwartalny pulpit bezpieczeństwa chmury i dostawców powinien pokazywać:

• Liczbę zatwierdzonych usług chmurowych.
• Krytyczne usługi chmurowe i ich właścicieli.
• Usługi przetwarzające dane osobowe.
• Usługi wspierające funkcje krytyczne lub ważne.
• Otwarte błędne konfiguracje chmury wysokiego ryzyka.
• Status przeglądu MFA i dostępu uprzywilejowanego.
• Pokrycie rejestrowaniem krytycznych platform SaaS i IaaS.
• Otrzymane i przejrzane raporty zapewnienia dostawców.
• Wyjątki umowne i zaakceptowane ryzyka.
• Incydenty chmurowe, sytuacje bliskie incydentowi i wnioski.
• Wyniki testów kopii zapasowych i odzyskiwania.
• Status ryzyka koncentracji i planów wyjścia.

Ten pulpit staje się dowodem przywództwa i oceny wyników w ISO 27001:2022, ładu NIS2 oraz odpowiedzialności kierownictwa w DORA.

Zenith Blueprint, w fazie Risk Management, Step 14, zaleca krzyżowe odniesienie wymagań regulacyjnych podczas wdrażania działań dotyczących postępowania z ryzykiem i polityk. Wskazuje, że mapowanie kluczowych wymagań regulacyjnych do zabezpieczeń SZBI jest użytecznym ćwiczeniem wewnętrznym i „robi również wrażenie na audytorach/asesorach, pokazując, że nie zarządzasz bezpieczeństwem w próżni, lecz znasz kontekst prawny”.

To jest poziom dojrzałości, którego oczekują regulatorzy i klienci korporacyjni.

Typowe ustalenia audytu chmury i jak ich unikać

W pracach nad gotowością do audytu chmury powtarzające się ustalenia są przewidywalne:

1. Rejestr usług chmurowych istnieje, ale brakuje w nim narzędzi SaaS.
2. Lokalizacja danych nie jest zapisana albo jest kopiowana ze stron marketingowych zamiast z dowodów umownych.
3. MFA jest wymuszone dla pracowników, ale nie dla wszystkich kont administracyjnych lub break-glass.
4. Logi chmurowe są włączone, ale nie są przeglądane, przechowywane ani połączone z reagowaniem na incydenty.
5. Raporty SOC dostawców są archiwizowane, ale nie oceniane.
6. Klauzule umowne istnieją dla nowych dostawców, ale nie dla krytycznych usług legacy.
7. Powiadomienia o podwykonawcach przetwarzania są otrzymywane pocztą elektroniczną, ale nie podlegają ocenie ryzyka.
8. Zadania kopii zapasowych kończą się powodzeniem, ale testy odtwarzania nie są udokumentowane dowodowo.
9. Współdzielona odpowiedzialność jest rozumiana przez inżynierów, ale nie jest udokumentowana dla audytorów.
10. SoA oznacza zabezpieczenia chmury jako mające zastosowanie, ale nie łączy ich z wpisami ryzyka, dowodami ani właścicielami.

To są problemy identyfikowalności. Rozwiązaniem jest połączenie polityki, ryzyka, zabezpieczenia, właściciela, dowodu i przeglądu.

Gdy Maria dotarła do dnia audytu, nie polegała już na rozproszonych zrzutach ekranu. Otworzyła centralny pulpit pokazujący Rejestr usług chmurowych, oceny ryzyka, wpisy SoA, dowody konfiguracji bazowej, pliki przeglądu dostawców, dowody rejestrowania i przegląd ryzyka koncentracji DORA. Gdy audytor zapytał, jak zarządzane są ryzyka chmurowe, pokazała SZBI. Gdy audytor zapytał, jak usługi są bezpiecznie skonfigurowane, pokazała konfigurację bazową i dowody CSPM. Gdy audytor zapytał o ryzyko ICT związane z zewnętrznymi dostawcami usług, pokazała przegląd umów, monitorowanie dostawców i planowanie wyjścia.

Wynikiem nie było idealne środowisko. Żadne środowisko chmurowe nie jest idealne. Różnica polegała na tym, że decyzje dotyczące ryzyka były udokumentowane, dowody możliwe do obrony, a odpowiedzialność widoczna.

Zbuduj pakiet dowodów chmurowych, zanim zapyta o niego audytor

Jeżeli organizacja polega na SaaS, IaaS lub PaaS, następny audyt nie zaakceptuje odpowiedzi „zajmuje się tym dostawca” jako wystarczającej. Trzeba wykazać współdzieloną odpowiedzialność, konfigurację po stronie klienta, klauzule dostawców, rejestrowanie, gotowość incydentową, odporność i nadzór kierownictwa.

Zacznij od trzech praktycznych działań w tym tygodniu:

1. Utwórz lub odśwież Rejestr usług chmurowych, korzystając z Clarysec Cloud Usage Policy Cloud Usage Policy albo Cloud Usage Policy-sme Cloud Usage Policy-sme.
2. Zmapuj pięć najważniejszych usług chmurowych do zabezpieczeń ISO 27001:2022 z Załącznika A, NIS2 Article 21, obowiązków DORA dotyczących zewnętrznych dostawców usług ICT tam, gdzie mają zastosowanie, oraz wymagań GDPR wobec podmiotów przetwarzających.
3. Zbuduj scentralizowany folder dowodowy, stosując dyscyplinę retencji i metadanych z Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy albo Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme.

Następnie użyj Zenith Blueprint Zenith Blueprint, aby umieścić te działania na 30-krokowej mapie drogowej audytu SZBI, oraz Zenith Controls Zenith Controls, aby zweryfikować mapowania cross-compliance, wspierające normy ISO i oczekiwania metodyki audytu.

Clarysec może pomóc przekształcić rozproszone zrzuty ekranu chmury, pliki dostawców i ustawienia SaaS w pakiet dowodowy gotowy na kontrolę regulatora, który wytrzyma audyty certyfikacyjne ISO 27001:2022, pytania nadzorcze NIS2, przeglądy zewnętrznych dostawców usług ICT w DORA oraz wymagania zapewnienia ze strony klientów korporacyjnych.