Do chmur(y). Zarządzanie ryzykiem modeli chmury obliczeniowej wg SCCO. Wstęp

Dzisiaj chyba mało kto wątpi, że przetwarzanie danych w chmurze obliczeniowej da się zatrzymać. Wyporność "własnej" infrastruktury jest ograniczona, a dostępność części usług czy platform jest możliwa za pośrednictwem chmury właśnie. Wiele przykładów z przeszłości pokazuje, że dobrze zarządzana i zabezpieczona chmura może uratować z kryzysowej sytuacji, choć z drugiej strony może też być źródłem wielu trosk, jeżeli nieumiejętnie podejdziemy do zagrożeń, które jednak i tutaj występują.

Można się kłócić co do tego "co jest bezpieczniejsze" - zewnętrzny dostawca ze swoją infrastrukturą, czy nasze rozwiązania on-premise (pod dachem), ale nie zmieni to faktu, że adopcja chmury będzie postępowała. W niektórych sektorach szybciej, w innych wolniej, ale pewnego trendu (jakkolwiek zmiennego) nie da się zatrzymać. Zakładam, że większość instytucji będzie korzystała z modeli hybrydowych, łączących "zewnętrzną" infrastrukturę i

W ostatnim czasie sektor finansowy " utracił " swój standard przetwarzania w chmurze obliczeniowej, który przez jednych był przeklinany, a przez innych wychwalany za "standaryzację" podejścia do chmury i zarządzania ryzykiem z nim związanym. Ja zaliczam się do tej drugiej grupy i trochę żałuję, że musiał zostać uchylony. No, ale nie ma co płakać nad rozlanym mlekiem i trzeba iść dalej. Tym dalej jest nowy Standard Cyberbezpieczeństwa Chmury Obliczeniowej, który choć jest kierowany do sektora publicznego i dostawców dla tego sektora, to jednak w wielu (wszystkich?) miejscach ma charakter uniwersalny i z powodzeniem może być stosowany przez podmioty komercyjne, szczególnie te które przetwarzają "wrażliwe" informacje.

Do napisania felietonu natchnęła mnie lektura książki Jacka Woźniaka i Wioletta Wereda "Mapa ryzyka w zarządzaniu organizacją. W kierunku organizacji opartej na innowacjach i kulturze ryzyka", która o ryzyku "mówi" jako nie tylko o ograniczeniu, ale jako szansie. Wręcz pojawia się tam stwierdzenie, że:

bez ryzyka nie ma rozwoju organizacji

I to coś z czym się całkowicie zgadzam. Wykorzystanie chmury obliczeniowej może być właśnie taką szansą. Pod warunkiem, że wiemy jak podejść do zarządzania ryzykiem związanym z tym modelem przetwarzania danych. Od tego zaczniemy.

Chciałbym jednocześnie zwrócić Waszą uwagę na to, że dobrze rozpisany i zoperacjonalizowany proces obsługi projektów chmurowych znacznie ogranicza nam koszty związane z transformacją. Chodzi tutaj przede wszystkim o czas, który wymagany jest na zebranie niezbędnych informacji i podjęcie decyzji "go/no go". Czasem może okazać się, że nasze potrzeby biznesowe nie będą mogły zostać zrealizowane w oparciu o konkretny model chmury obliczeniowej, więc przechodzenie kolejnych kroków jest zwyczajnie bez sensu. Stąd nasz proces musi być naprawdę dobrze opisany i zoperacjonalizowany.

W standardzie znajdziemy ważne stwierdzenie:

Technologie chmur obliczeniowych wprowadzają nowe modele przetwarzania danych, niezależne od miejsca ich przechowywania – dlatego chmura obliczeniowa to nie miejsce tylko model przetwarzania.

Zacznijmy od tego, że determinującym czynnikiem przesądzającym o tym jaki model chmury obliczeniowej powinniśmy wybrać, to 💾 klasa lub klasy informacji, które będziemy chcieli przetwarzać z użyciem tej technologii. Wynika to z faktu, że poziom zabezpieczeń i ogólne zasady dotyczące przetwarzania powinny być proporcjonalne do skali zagrożeń. Patrząc przez pryzmat Standardów, w zależności od tego czy mówimy np. o informacjach prawnie chronionych, informacjach niejawnych czy czymś "więcej". Akurat w SCCO mowa o specyficznej sytuacji, ale w naszej organizacji możemy przyjąć inną klasyfikację, np. ze względu na wartość biznesową informacji, np. tajemnica przedsiębiorstwa, handlowa etc.

SCCO

Stworzenie analogicznej tabeli w naszej organizacji powinno być dla nas priorytetem, bo:

🎯 jasno określimy sobie klasy informacji (jeżeli ich jeszcze nie mamy), które będą podlegały szczególnej lub mniejszej ochronie

🎯 zapewnimy, że dla przetwarzania poszczególnych klas informacji będziemy wymagali (wewnętrznie i zewnętrznie) określonych zabezpieczeń

🎯 damy jasną informację dla zespołu zakupowego (w ramach procesów zakupowych) czego oczekujemy od dostawcy określonych rozwiązań.

Oczywiście, jeżeli mamy w naszej organizacji system zarządzania ryzykiem i system zarządzania bezpieczeństwem informacji, to nie możemy zapomnieć o specyfice, która może wynikać z funkcjonowania tych systemów. W samych standardach zwrócono uwagę na konieczność zrealizowania 6 kroków, jeżeli jesteśmy odbiorcą rozwiązań chmurowych. To podejście zasadniczo zgodne z NIST RMF, który określa najbardziej efektywne podejście do zarządzania ryzykiem w obszarze cyberbezpieczeństwa.

SCCO

Jak spojrzymy na ten proces, to wyglądać może on - na pierwszy rzut oka - nieco inaczej niż w przypadku uchylonego k omunikatu chmurowego, ale w praktyce podejście jest tożsame.

W SCCO rekomendowane są następujące działania:

🛠️ [ ocena ryzyka ] obejmująca klasyfikację systemów oraz informacji (tutaj istotne znaczenie ma architektura naszych systemów oraz samych danych -> informacji) oraz de facto wybór określonego modelu przetwarzania i niezbędnego poziomu zabezpieczeń, np. zgodnych z załącznikami do SCCO [listę znajdziecie tutaj ]; jest to też etap, w którym powinniśmy przeprowadzić due diligence dostawcy (można tutaj korzystać z "doświadczeń" DORA - zajrzyjcie do felietonu o politykach zakupowych)

🔐 [ postępowanie z ryzykiem ] obejmujące implementację zabezpieczeń przez odbiorcę rozwiązań; ocena wdrożenia zabezpieczeń przez dostawcę chmury, weryfikacja naszego "łańcucha" ⛓️ zależności oraz akredyacja (tutaj to akurat specyficzny wymóg dla sektora publicznego, ale możemy tutaj przyjąć też wewnętrzne zasady approvali)

Tutaj ważna informacja - stworzenie "mapy" zabezpieczeń pod kątem konkretnych zastosowań, np. ze względu na klasę przetwarzanych informacji znacznie ułatwi nam pracę, a dostawcy da pewność co do tego czy jest w stanie pokryć nasze oczekiwania

🕹️ [ kontrola ryzyka ] etap, w którym przeprowadzamy ciągłe monitorowanie tego co zostało wdrożone, przede wszystkim poprzez stosowanie zasad określonych w naszym systemie zarządzania ryzykiem, ale także procesów związanych z rejestracją zdarzeń czy incydentów; etap ten będzie realizowany prawdopodobnie zarówno w formie "białkowej", jak i automatycznej.

Każdy z tych kroków ma swoją specyfikę i musi być zgrany z naszymi procesami wewnętrznymi. Przykładowo, jeżeli jesteśmy podmiotem regulowanym podlegającym szczególnym zasadom w zakresie outsourcingu ☁️, to prawdopodobnie będziemy musieli przejść przez "ankietę", zanim w ogóle przejdziemy do etapów związanych z wyborem dostawcy i negocjacją warunków SLA. Połączenie tych procesów powinno więc stanowić dla nas absolutny priorytet, a na kolejnym etapie powinniśmy zapewnić, że procesy te są odpowiednio komunikowane i zrozumiałe dla naszych interesariuszy.

❗️❗️❗️W tym miejscu chciałbym zwrócić uwagę na jedną istotną kwestię, czyli odpowiedzialność za to co przetwarzamy w chmurze. Możemy w zasadziue przyjąć, że jest to współodpowiedzialność, bo na różnych etapach i w różnych miejscach całego stosu technologicznego i architektury rozwiązania zarówno odbiorca, jak i dostawca chmury obliczeniowej będą mieli swoje obowiązki. Sytuacja komplikuje się nam jeszcze bardziej, gdy zaczynamy korzystać z bardziej złożonych modeli przetwarzania w chmurze. ❗️❗️❗️

SCCO

Tyle na dzisiaj, choć do tematu będę jeszcze z pewnością wracał, bo zakładam, że jeżeli poziom adopcji chmury w sektorze publicznym wzrośnie, to i w innych - dotąd podchodzących z rezerwą - sektorach również zauważymy wzrosty. Standard w nowej odsłonie nie jest czymś "nadzwyczajnym", ale porządkuje wiele kwestii i zachęcam do korzystania z niego, jako puntku wyjścia dla własnych rozwiązań. Warto!