Atestacja C5: przygotuj dowody zapewnienia dla usług chmurowych

Klient usługi chmurowej chce wiedzieć, które zabezpieczenia stosuje dostawca, a które pozostają jego własną odpowiedzialnością. Niemiecki Federalny Urząd Bezpieczeństwa Informacji (BSI) publikuje katalog kryteriów zgodności dla przetwarzania w chmurze, Cloud Computing Compliance Criteria Catalogue (C5), jako ustrukturyzowaną podstawę badania tego zapewnienia. Dla CTO przygotowanie oznacza uczynienie granicy usługi, wdrożenia kontroli i zapisów operacyjnych możliwymi do sprawdzenia, a nie jedynie zebranie polityk.

C5 to katalog kryteriów wykorzystywany w niezależnej atestacji, a nie certyfikacja w stylu ISO. Podstawowym źródłem jest dokumentacja C5 opublikowana przez BSI. Zacznij od uzgodnienia z niezależnym audytorem obowiązującego wydania, celu zapewnienia i zakresu badania.

Określ dokładnie, którą usługę obejmie raport

Opisz usługę chmurową, lokalizacje, w których działa, granice organizacyjne i zależności. Raport obejmujący jedną usługę nie obejmuje automatycznie każdego produktu pod tą samą marką. Zidentyfikuj komponenty produkcyjne, interfejsy zarządzania, działania wsparcia i usługi zewnętrzne, które mogą wpływać na twierdzenia w zakresie zapewnienia.

Opis systemu powinien pozwolić osobie z zewnątrz zrozumieć, jak dane klientów trafiają do usługi, jak się w niej przemieszczają i jak ją opuszczają. Uwzględnij ścieżki administracyjne, procesy wdrożeniowe, monitoring bezpieczeństwa, kopie zapasowe i podział obowiązków między zespoły. Wyjaśnij istotne cechy usługi i warunki jej działania, zamiast zastępować opis diagramami architektury.

Rozstrzygnij te kwestie dotyczące zakresu przed zebraniem dowodów:

• Które produkty, regiony i środowiska są uwzględnione?
• Które zespoły administrują środowiskiem produkcyjnym lub mają dostęp do informacji klientów?
• Którzy dostawcy niższego poziomu wspierają usługę i jak traktowane są ich kontrole?
• Które konfiguracje i zadania bezpieczeństwa pozostają po stronie klientów?
• Jakie istotne zmiany nastąpiły lub są planowane w okresie badania?

Każde wyłączenie powinno mieć wyraźne uzasadnienie. Jeśli starsze wdrożenie zostało wyłączone, upewnij się, że oświadczenia kierowane do klientów nie sugerują, że jest ono objęte. Produktem jest wersjonowany opis systemu, poparty zapisami dotyczącymi architektury, zależności i podziału odpowiedzialności.

Wybierz rodzaj raportu przed ustaleniem kalendarza dowodów

Zapewnienie w ramach C5 jest zazwyczaj wyrażane w raporcie atestacyjnym audytora. Typ 1 dotyczy projektu i wdrożenia kontroli na określony dzień. Typ 2 dodatkowo bada skuteczność działania w określonym okresie.

Typ 1 może być użytecznym kamieniem milowym przy budowaniu środowiska kontroli, ale nie odpowiada na to samo pytanie co Typ 2. Potwierdź, czego faktycznie wymagają klienci, zanim wybierzesz raport przejściowy.

Uzgodnij z audytorem okres i oczekiwania dotyczące dowodów. Nie zakładaj uniwersalnej długości okresu obserwacji. Procedura spisana pod koniec okresu nie może dowodzić, że kontrola działała wcześniej. Podobnie udany bieżący test nie wymazuje historycznej awarii.

Buduj dowody wokół odpowiedzialności i wykonania

Jako praktyczną metodę przygotowania zbuduj rejestr dowodów łączący każde mające zastosowanie kryterium z wdrożoną kontrolą, właścicielem, granicą usługi, źródłem dowodów, częstotliwością przeglądu i nierozwiązanymi lukami. Zapisuj decyzje o stosowaniu i ich uzasadnienie; unikaj oznaczania kryterium jako nieistotnego tylko dlatego, że jego wdrożenie byłoby trudne.

Rozdziel trzy pytania: co powinno się dziać, co jest wdrożone i co faktycznie się wydarzyło. Polityka odpowiada na pierwsze. Zapisy konfiguracji mogą wspierać drugie. Zgłoszenia, logi, zatwierdzenia i wyniki testów wspierają trzecie.

Są to praktyczne przykłady, a nie kompletna lista kontrolna C5. Wymagane pokrycie, w tym kontrole organizacyjne, kadrowe, fizyczne i techniczne, określ na podstawie uzgodnionego katalogu i zakresu.

Zapewnij odtwarzalność dowodów

Dla każdego eksportu lub zrzutu ekranu zachowaj system źródłowy, datę zebrania, odpowiedni okres, zastosowane filtry i osobę, która go zebrała. Wyjaśnij, czy przedstawia on całą populację, czy wybrany element. Audytorzy muszą rozumieć populację, z której wybierają próby; folder zawierający wyłącznie udane przykłady nie wystarczy.

Preferuj zapisy, które zachowują wykonawcę, znacznik czasu, działanie i wynik. Chroń dowody przed nieuprawnioną zmianą i unikaj zbędnego ujawniania danych klientów. Jeśli konieczne jest zaczernienie fragmentów, zachowaj wystarczający kontekst, aby recenzent zrozumiał, czego dowodzi zapis.

Oddzielaj kontrole dziedziczone od obowiązków własnych

Zapewnienie dostawcy infrastruktury może wspierać bezpieczeństwo fizyczne lub kontrole platformy bazowej. Nie dowodzi jednak, że autoryzacja dzierżawców (tenantów) w Twojej aplikacji działa. Udokumentuj zależność, zakres odpowiedniego raportu, okres, wyjątki i obowiązki, które Twój zespół musi nadal wypełniać.

Komplementarne kontrole po stronie klienta również wymagają praktycznego sformułowania. „Klient odpowiada za bezpieczeństwo” to zbyt szerokie określenie. Wskaż zadania, takie jak administrowanie użytkownikami w dzierżawie, konfigurowanie federacji tożsamości czy przegląd zasad dostępu kontrolowanych przez klienta. Utrzymuj spójność tych obowiązków w opisie systemu, dokumentacji usługi i ustaleniach umownych.

Prowadź przygotowania jak program inżynierski

Zacznij od oceny luk względem uzgodnionych kryteriów. Odróżniaj brak wdrożenia od braku dowodów: wymagają one różnych środków zaradczych. Nieudokumentowany przegląd może wymagać lepszych zapisów; przegląd uprawnień, który nigdy się nie odbył, wymaga kontroli operacyjnej.

Każdej luce przypisz właściciela, działanie naprawcze, zależności i termin docelowy. Priorytetowo traktuj kwestie dotyczące separacji dzierżawców, dostępu uprzywilejowanego, zmian w produkcji, reagowania na incydenty i możliwości odtworzenia, zgodnie z ryzykami usługi, a nie tylko najłatwiejsze zadania dokumentacyjne.

Przed rozpoczęciem okresu Typu 2 sprawdź, czy powtarzalne kontrole mają wykonalne harmonogramy i trwałe zapisy. Potwierdź, kto je wykonuje w czasie nieobecności lub przy rotacji pracowników. W przypadku kontroli wyzwalanych zdarzeniami, takich jak zakończenie dostępu do konta, upewnij się, że populację zdarzeń wyzwalających można zidentyfikować.

Przeprowadź przegląd gotowości z wykorzystaniem reprezentatywnych dowodów. Prześledź jedną zmianę od wniosku do wdrożenia, jednego odchodzącego administratora aż do cofnięcia dostępu i jedno ćwiczenie odtworzeniowe aż do działania korygującego. Ujawnia to zerwane przekazania, które przegląd polityk może przeoczyć.

W trakcie badania prowadź rejestr żądań z właścicielami i statusem odpowiedzi. Zapewnij dostępność oryginalnych zapisów, otwarcie wyjaśniaj rozbieżności i śledź działania naprawcze oddzielnie od dowodów historycznych. Nie przepisuj starych zapisów tak, by wyglądały na zgodne. To audytor decyduje, jak ustalenia wpływają na testowanie i opinię.

Przykład: aplikacja zarządzana na zewnętrznej infrastrukturze

Załóżmy dla ilustracji, że dostawca obsługuje wielodzierżawną aplikację w jednym regionie, korzysta z zewnętrznego dostawcy infrastruktury i dąży do uzyskania zapewnienia Typu 2. Jego zespół kontroluje wydania aplikacji, uprawnienia dzierżawców, administrowanie środowiskiem produkcyjnym i procedury odtwarzania.

Opis zakresu identyfikuje aplikację, bazę danych, warstwę zarządzania, narzędzia wsparcia i zależność infrastrukturalną. Wyjaśnia, które kontrole niższego poziomu są dziedziczone, a które pozostają po stronie dostawcy aplikacji.

W zakresie izolacji dzierżawców zespół dokumentuje projekt autoryzacji, zautomatyzowane testy negatywne, ustalenia z testów bezpieczeństwa i zatwierdzenia wydań. Zachowuje też zapisy zmian pokazujące, kiedy zmieniła się logika autoryzacji. Raport dostawcy infrastruktury jest dowodem pomocniczym dotyczącym zależności, a nie dowodem izolacji aplikacji.

W zakresie dostępu uprzywilejowanego zespół zachowuje populację administratorów, zatwierdzenia przyznania dostępu, decyzje z przeglądów i zapisy usunięcia uprawnień. Załóżmy, że przegląd ujawnia nieużywane konto wsparcia. Zespół dokumentuje wykrycie, cofnięcie dostępu, ocenę ekspozycji i działanie zapobiegawcze. Jest to bardziej wiarygodne niż przedstawienie wyłącznie uporządkowanej listy kont.

W zakresie odtwarzania zespół zachowuje wynik testu odtwarzania pokazujący, co zostało odtworzone, czas trwania, kontrole integralności danych i nierozwiązane ograniczenia. Samo skonfigurowane zadanie kopii zapasowej nie dowodzi możliwości odtworzenia. Każdy zestaw dowodów ma właściciela i określony okres, dzięki czemu audytor może powiązać zapisy z badaną kontrolą.

Wykorzystuj prace w zakresie zapewnienia ponownie, nie twierdząc, że są równoważne

ISO/IEC 27001 dotyczy systemu zarządzania bezpieczeństwem informacji o określonym zakresie. SOC 2 to raport atestacyjny oparty na własnych kryteriach i kontekście raportowania. C5 koncentruje się na zapewnieniu dotyczącym usług chmurowych w oparciu o katalog BSI.

Istniejące oceny ryzyka, kontrole dostępu, procedury obsługi incydentów i zapisy operacyjne mogą wspierać więcej niż jeden program. Wykorzystuj je ponownie za pomocą mapowań uwzględniających wersję i zakres, a następnie sprawdzaj różnice w wymaganiach lub raportowaniu. Wspólna kontrola nie oznacza automatycznej równoważności frameworków.

Dobieraj portfel zapewnienia na podstawie rzeczywistych wymagań klientów i ryzyk usługi. C5 nie jest powszechnie obowiązkowy dla każdego dostawcy chmury; wymagania przetargowe, umowne lub mające zastosowanie wymagania sektorowe wymagają odrębnego przeglądu. Ani raport C5, ani inny dokument zapewnienia nie dowodzi samodzielnie zgodności z RODO lub NIS2.

Przygotuj raport na potrzeby decyzji klientów

Klienci potrzebują opisu systemu, daty lub okresu, faktycznej opinii, wyjątków i granic odpowiedzialności, a nie tylko nazwy raportu. Udostępniając raporty, przestrzegaj umownej poufności i zapewnij kontekst dla oceny dokonywanej przez klienta.

Wyjaśniaj stan działań naprawczych, nie sugerując, że późniejsze poprawki zmieniają historyczną opinię. Jeśli okres objęty raportem poprzedza istotną zmianę architektury, wskaż to ograniczenie. Uzgadniaj cykliczne badania w oparciu o oczekiwania klientów i zmiany operacyjne, zamiast traktować atestację jako ponadczasowe poświadczenie.

Secani pomaga zespołom łączyć wdrożenie kontroli i dowody ze zweryfikowanymi wymaganiami. Zamodeluj usługę i zależności, przypisz właścicieli i recenzentów, dołącz zapisy pomocnicze i przekształć luki w dowodach w zadania. Utrzymuj wyraźne zatwierdzanie przez człowieka w przypadku mapowań i wniosków. Model gotowości do audytu pomaga zachować zakres i odpowiedzialność stojące za każdym twierdzeniem.

Pytania do rozstrzygnięcia przed pierwszym badaniem

Czy raport wydaje BSI?

BSI publikuje katalog. Niezależny audytor przeprowadza badanie i wydaje raport atestacyjny; potwierdź z tym audytorem właściwe ramy zapewnienia i warunki zlecenia.

Co, jeśli nie wystąpił żaden rzeczywisty incydent?

Nie wymyślaj zapisu incydentu. Zachowaj dowody, że proces został wdrożony i, w stosownych przypadkach, przećwiczony. Uzgodnij z audytorem, jak brak zdarzeń wpływa na testowanie.

Co zespół powinien zrobić w następnej kolejności?

Weź jedną reprezentatywną usługę produkcyjną i przygotuj jej opis zakresu, macierz odpowiedzialności i rejestr dowodów. Przejrzyj te trzy produkty z przyszłym audytorem, zanim zaczniesz kompletować duży pakiet dowodów.