Jak bezpiecznie przenieść się do chmury – audyt i testy w chmurze

W nowym odcinku z cyklu “Jak bezpiecznie przenieść się do chmury” będziemy opowiadać o tym, jakie standardy bezpieczeństwa powinna spełniać usługa chmurowa i jak możemy sprawdzić, czy te standardy faktycznie spełnia.

Artykuł jest częścią zaplanowanego na cały rok cyklu artykułów oraz webinarów sponsorowanych przez firmę Aruba Cloud – dostawcę usług chmurowych z centrum przetwarzania w Polsce.

W poprzednich artykułach i webinarze opisałem architekturę modelu cloud computingu wg NIST SP 800-145, jakie czyhają pułapki, wyzwania i zagrożenia ze względu na rodzaj i rozmieszczeniu usługi i jakie są z tym związane ryzyka natury organizacyjno-prawnej i zarządzania zgodnością na przykładzie pojęcia GRC – Governance, Risk management and Compliance. W tym odcinku cyklu zaprezentuję kilka sposobów i technik weryfikacji czy usługa chmurowa spełnia nasze wymagania w zakresie bezpieczeństwa. W pierwszej części skupię się na audycie przedstawiając praktyki, standardy i narzędzia opracowane przez międzynarodowe organizacje m.in. CSA, ISACA, DMTF. W drugiej części opiszę co możemy zrobić w chmurze w ramach testów bezpieczeństwa, jakie są ograniczenia i możliwości oraz o jakie zapisy umowne należy zadbać.

Zapraszamy na webinar

Skoro tu zajrzeliście, to zapraszamy na nasz webinar poświęcony kwestiom RODO/GDPR w chmurze. Już teraz możecie zapisać się na termin 23 kwietnia o godzinie 20 lub 24 kwietnia o godzinie 12 – staramy się dopasować do Waszych potrzeb. W obu terminach poruszane będą te same tematy – choć Wasze pytania mogą się różnić.

W programie między innymi omówienie kwestii zapewnienia zgodności z RODO w różnych rodzajach usług w chmurze oraz problemy związane z komunikacją i współpracą z dostawcą usług chmurowych.

Audyt w modelu cloud computing

Jednym ze sposobów na ocenę w jaki sposób dostawca usługi chmurowej zapewnia odpowiednie zarządzanie ryzykiem oraz spełnia nasze wymagania dotyczące bezpieczeństwa organizacyjno-prawnego i technicznego jest wykonanie przeglądu bądź audytu. Punktem wyjścia do określenia jaki będzie jego cel, zakres i podejście do realizacji jest zrozumienie jakie są ryzyka na poszczególnych warstwach usługi (stos SPI) i kto jest odpowiedzialny za wdrożenie odpowiednich zabezpieczeń. Ryzyka mogą być związane z kwestiami organizacyjno-prawnymi (regulacje, zgodność, nadzór) oraz technicznymi. W celu ich identyfikacji oraz sposobu ich zabezpieczenia możemy się posłużyć opracowanymi i powszechnie stosowanymi standardami i narzędziami dedykowanymi dla modelu cloud computing. Zaprezentuję kilka, które są mi najbardziej znane i które miałem okazję wykorzystywać w praktyce. Większość z nich jest darmowa i publicznie dostępna.

Cloud Computing Management Audit/Assurance Program – dostępny za darmo dla członków ISACA. Prosty program składający się z dwóch głównych sekcji (Governance, Operations) i podzielonych na kilka domen. W każdej z nich są zdefiniowane cele kontrolne (czy inaczej wymagania) oraz mechanizmy (zabezpieczenia) jakie powinny być wdrożone żeby je spełnić. Do każdego mechanizmu są zaprojektowane czynności sprawdzające pozwalające uzyskać odpowiedź czy dane zabezpieczenie istnieje, jest wdrożone i skutecznie realizowane oraz istnieje odniesienie do sztandarowego standardu opracowanego przez ISACA czyli COBIT 5.

Podręcznik IT Control Objectives for cloud computing jest kolejnym produktem opracowanym przez ISACA. Zawiera on dokładny opis dla każdej domeny, określone priorytety zabezpieczeń ze względu na rodzaj i rozmieszczenie usługi chmurowej oraz znacznie bardziej rozbudowaną wersję powyższego programu audytu.

Cloud Control Matrix (CCM) i Consensus Assessment Initiative (CAI) – ściśle ze sobą powiązane narzędzia opracowane i opublikowane przez Cloud Security Alliance. Pierwszy w sposób bardzo szczegółowy opisuje jakie zabezpieczenia powinny się znaleźć w danej domenie, do jakich komponentów architektury się odnoszą (fizyczne, sieciowe, obliczeniowe, przechowywanie danych, aplikacje, dane), do jakiego rodzaju usługi (Software, Platform, Infrastructure) oraz kto jest odpowiedzialny za ich wdrożenie. Dodatkowo każde zabezpieczenie jest zmapowane do wymagań powszechnie stosowanych norm, standardów czy regulacji m.in. wspomniany COBIT 5, PCI DSS (dotyczący ochrony danych kartowych) , GDPR (znane w Polsce bardziej jako RODO – nowe rozporządzenie dotyczące ochrony danych osobowych), ISO 27001:2013 (jedna z bardziej znanych i stosowanych norm dotycząca systemów zarządzania bezpieczeństwem informacji) czy mniej znane w Polsce – AICPA, FedRAMP czy HIPAA. Takie rozwiązanie umożliwia proste zdefiniowanie programu audytu zgodności z obowiązującymi nas wymaganiami regulacji czy standardów. Do tego bardzo przydatne będzie drugie narzędzie, CAI, które jest listą kontrolną/kwestionariuszem zawierającą około 300 pytań, które pozwalają uzyskać odpowiedź czy dostawca stosuje zabezpieczenia opisane w CCM.

Powyżej przedstawione narzędzia są proste w założeniu, ale posiadają kilka ograniczeń w ich zastosowaniu ze względu na specyfikę modelu cloud computing. Do realizacji części czynności audytowych wymagany jest kontakt z dostawcą usługi lub nawet wizyta w centrum danych w celu zebrania dowodów na istnienie i stosowanie zabezpieczeń. Przy rozproszonym charakterze chmury może to być trudne i wymagające odpowiednich zasobów (czas, ludzie, pieniądze). Możemy oczywiście wysłać przygotowaną listę pytań do dostawcy usługi, ale uzyskamy jedynie deklarację, a nie realne zapewnienie bezpieczeństwa. Co możemy zrobić kiedy nie mamy zasobów na audyt w centrum danych, nie jest to dla nas opłacalne lub kontakt z dostawcą jest utrudniony. Jednym ze sposobów na potwierdzenie funkcjonowania systemów zarządzania bezpieczeństwem jest posiadanie poświadczających certyfikatów wystawionych przez zewnętrzny, akredytowany podmiot. Zgodność z wymaganiami normy jest cyklicznie oceniana przez niezależną stronę. Na ich podstawie możemy ocenić w jaki sposób dostawcy podchodzą do bezpieczeństwa świadczonych usług. Wśród nich możemy wymienić m.in.:

Normy ISO:

• ISO/IEC 27001:2013 certyfikat potwierdzający wdrożenie i funkcjonowanie Systemu Zarządzania Bezpieczeństwem Informacji,
• ISO/IEC 27017 – zgodna z ISO/IEC 27001:2013 i uzupełniająca ISO/IEC 27002:2013, która kładzie szczególny nacisk na specyficzne zagrożenia i ryzyka związane z chmurą obliczeniową,
• ISO/IEC 27018:2014 –Praktyczne zasady ochrony informacji danych osobowych w przetwarzaniu w chmurze, uzupełniająca ISO/IEC 27002:2013 o aspekty ochrony danych osobowych w chmurze.

CSA STAR

Program Security, Trust and Assurance Registry (“STAR”) jest częścią CSA Open Certification Framework („OCF”), który jest branżową inicjatywą polegającą na przyznawaniu dostawcom usług w chmurze globalnych, akredytowanych, zaufanych certyfikatów potwierdzających stosowanie najlepszych praktyk w zarządzaniu bezpieczeństwem. CSA Security, Trust & Assurance Registry (STAR) jest publicznie dostępnym rejestrem, w którym udokumentowane są systemy kontroli stosowane przez dostawców usług. Program Open Certification Framework składa się z kilku poziomów.

1. Samoocena – Polega na opublikowaniu deklarowanej przez dostawcę samooceny opartej na Consensus Assessment Initiative (CAI) Questionnaire i Cloud Control Matrix (CCM).
2. Certyfikacja / Atestacja: Polega na publikacji wyników oceny dokonanej przez niezależną stronę. Certyfikacja obejmuje ocenę zgodności z wymaganiami Cloud Control Matrix oraz standardu ISO27001. Atestacja opiera się na wynikach raportu 2 SOC – Service Operation Centre (dawny SAS 70, obecnie SSAE 16.) wykorzystującego elementy Cloud Control Matrix
3. STAR Continuous: Jest w fazie rozwoju. Polega na publikacji wyników ciągłego audytu i monitoringu opartego na Cloud Audit i Cloud Trust Protocol (CTP).

W rejestrze STAR widnieje ponad 300 dostawców usług chmurowych, a liczba ta cały czas rośnie.

Wyżej wymienione narzędzia i standardy pozwalają nam na uzyskanie statycznych deklaracji i zapewnień. A gdybyśmy chcieli uzyskać aktualną, transparentną i niezależną od dostawcy informację o bezpieczeństwie usług. Taka koncepcja w postaci otwartego standardu Cloud Auditing Data Federation (CADF) została opracowana przez DTMF (Distributed Management Task Force) i jest wykorzystywana m.in. w platformie OpenStack.

Podstawowymi komponentami modelu są zasoby pełniący role INITIATOR, TARGET, OBSERVER oraz ACTION klasyfikujący zdarzenie i OUTCOME określający wynik akcji. Głównym założeniem modelu jest to, że wykorzystując koncepcję zdarzenia (EVENT) w sposób ciągły, bez zaangażowania dostawcy i przy ustandaryzowanym formacie danych (JSON) i składni zapytań (RESTful) możemy uzyskać odpowiedzi na pytania:

• Co? (EVENT) – jaka akcja wystąpiła, jakiego rodzaju, jaki był wynik i powód zgłoszenia (event.action, event.outcome, event.type, event.reason)
• Kiedy? (EVENT) – Kiedy to nastąpiło (event.timestamp)
• Kto? (INITIATOR) – Kto (użytkownik lub usługa) zainicjował akcję (initiator.id, initiator.type)
• Na co? (TARGET)– Jaki był cel (np. zasób) akcji (target.id, target.type)
• Gdzie? (OBSERVER)– gdzie akcja był zarejestrowana, przez kogo i kiedy zgłoszona (observer.id, observer.type, reporterstep.role, reporterstep.reporterTime)
• Skąd? (INITIATOR)– Skąd była zainicjowana akcja (initiator.endpoint, initiator.connection, initiator.geolocation)
• Dokąd? (TARGET) – Dokąd była skierowana (target.endpoint, target.connection, target.geolocation)

http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

Zasobami (RESOURCES) wykorzystywanymi do dostarczania informacji o zdarzeniach w tym modelu są typowe składniki architektury chmury rozgałęziające się na szczegółowe elementy. Poniżej przykład komponentów sieciowych i odpowiedzialnych za dane.

http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

Akcje (ACTIONS) są wykorzystywane do klasyfikacji zdarzenia na podstawie czynności/operacji, które go wygenerowało.

http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

Wyniki (OUTCOMES) są określone wartościami Sukces, Niepowodzenie, Nieznany i Nierozstrzygnięty.

http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

Dzięki ujednoliceniu standard może być wykorzystywany na platformach różnych dostawców i w różnych rodzajach usługi.

http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

Testy penetracyjne w chmurze

Kolejnym sposobem na ocenę bezpieczeństwa usług w chmurze jest wykonanie testów penetracyjnych. Aby je wykonać i uniknąć wpadek też należy zrozumieć podział odpowiedzialności pomiędzy dostawcą i odbiorcą i jakie komponenty są dostarczane na różnych warstwach stosu. Specyfika poszczególnych warstw oraz lokalizacja usługi (publiczna czy prywatna) determinują podejście i zakres testów, zapisy umowne oraz komunikację z dostawcą. Poniżej kilka aspektów, które należy wziąć pod uwagę przy realizacji testów penetracyjnych z punktu widzenia odbiorcy usługi.

Komunikacja

Większość dostawców posiada własne centra bezpieczeństwa i stale monitorują swoje środowiska w celu wykrycia anomalii mogących wskazywać na atak. Bez powiadomienia ich o planowanych testach moglibyśmy spowodować alarm i zablokowanie usług. Podobnie mogłyby się zachować wewnętrzne zespoły SOC nie powiadomione o testach. Część dostawców (np. Amazon czy Microsoft) publikuje na stronach instrukcje i formularze zgłoszeniowe, Google umożliwia realizację testów pod warunkiem przestrzegania zasad korzystania z usług. W wielu przypadkach kwestie te są przedmiotem negocjacji i zapewnienia sobie odpowiednich zapisów umownych określających rodzaj, zakres i częstotliwość testów. Kolejnym aspektem jest ustalenie terminu i harmonogramu. Podobnie jak przy wewnętrznym centrum danych „wstrzelenie” się w bieżące projekty i zmiany wymaga dobrej wymiany informacji i koordynacji działań.

Rodzaj testów

Specyfika współdzierżawionego środowiska zakłada szybkie tworzenie wirtualnych maszyn na podstawie ustalonego wzorca. Naszą odpowiedzialnością jest wdrożenie odpowiednich zabezpieczeń oraz ich weryfikacja. W chmurach wykorzystujących współdzierżawione środowiska wiele testów może negatywnie wpływać na innych dzierżawców. Wielu dostawców nie zezwala na symulowanie ataków DoS (odmowa usługi), ze względu na możliwe pogorszenie jakości usług świadczonych dla innych klientów. Wiele testów zakłada scenariusz wykorzystania wykrytych podatności, użycie exploitów, eskalacje uprawnień, przejmowania kontroli nad kolejnymi wirtualnymi maszynami i usługami. Przy błędach w separacji środowisk i komunikacji sieciowej istnieje ryzyko, że symulowany atak rozszerzy się i negatywnie wpłynie na usługi innych dzierżawców. Cenną informacją byłoby przetestowanie czy jest możliwe „przeskoczenie” z wirtualnych maszyn dzierżawców na nadzorcę lub nasze środowiska przy stosowanych zabezpieczeniach na podstawie używanego wzorca. Nie jest to jednak sytuacja akceptowalna przez dostawcę i przez innych dzierżawców.

Zakres

Dla przypomnienia dołączę rysunek stosu SPI pokazujący podział obowiązku, ponieważ większość ograniczeń jest związana z rodzajem usługi chmurowej.

IaaS – Infrastructure as a service – w tym rodzaju usługi mamy najmniejsze ograniczenia, ponieważ wiele komponentów stosu jest przez nas zarządzana. Przy uwzględnieniu powyższych aspektów związanych ze wspólną dzierżawą zasobów w modelu IaaS nie możemy uwzględnić zakresie testów hypervisora oraz bezpieczeństwa komponentów sieciowych oraz odpowiedzialnych za przechowywania i składowanie danych.

PaaS – Platform as a service – w tym modelu w ramach usługi dostarczana jest platforma usług i komponentów umożliwiających m.in. rozwój i instalację aplikacji. Warstwa prezentacji (web server, front end) jest często rozdzielona od warstwy bazy danych i komponentów składowania. Wielu dostawców nie zezwala na testowanie aplikacji czy użycie niektórych technik, ponieważ może mieć to wpływ na innych dzierżawców platformy jak i samego dostawcę. Dla przykładu testy aplikacji uwzględniające ataki typu SQL Injection mogą być zabronione lub wymagać ścisłej komunikacji i koordynacji z dostawcą. Należy o tym pamiętać przy określeniu zakresu i rodzaju testów i poszukać alternatywnych podejść np. przegląd kodu.

SaaS – Software as a Service – dostarczana w formie kompletnego produktu wykorzystywanego przez wielu odbiorców. Testy penetracyjne mogą spowodować niedostępność aplikacji wykorzystywanej przez innych dzierżawców. W skrajnych przypadkach nawet wyciek danych. W zasadzie zakres testów ogranicza się do weryfikacji zabezpieczeń interfejsów, zarządzania kluczami API itp.

Podsumowanie

1. Zrozum rodzaj i umieszczenie usługi chmurowej. To wraz z obowiązującymi wymaganiami regulacji i prawa determinuje związane ryzyka i zagrożenia jako podstawę do określenia celu, zakresu i podejścia do audytu i testów penetracyjnych.
2. Zapewnij sobie w umowie prawo do audytu i testów penetracyjnych określające ich zakres i częstotliwość oraz ścieżki komunikacji i koordynacji tych działań.
3. Wykorzystuj powszechnie znane i dostępne standardy, narzędzia i techniki dedykowane dla audytu i testów usług chmurowych, udostępniane przez organizacje takie jak ISACA, CSA, DTMF, ale także przez dostawców m.in. OpenStack, SOASTA CloudTest, Core CloudInspect.
4. W przypadku braku możliwości realizacji audytów czy pentestów szukaj zapewnienia stosowania praktyk bezpieczeństwa opartych na znanych standardach i normach, najlepiej poświadczonych przez niezależną stronę.

Dla zachowania pełnej przejrzystości: za opublikowanie tego artykułu pobieramy wynagrodzenie.