Jak bezpiecznie przenieść się do chmury – Security as a Service (SecaaS)

Wielu dostawców rozwiązań z obszaru bezpieczeństwa oferuje je w modelu Security as a Service (SecaaS). Usługi te wykorzystują potencjał chmury (m.in. ekonomię skali, elastyczność i skalowalność, szeroki dostęp), ale dziedziczą związane z nią zagrożenia.

Żeby lepiej zrozumieć, czy samo korzystanie z usług w chmurze, które mają zapewnić nam ochronę, jest bezpieczne, należy poznać związane z nimi ryzyka. Kilka z nich przedstawię w dzisiejszym artykule w oparciu o materiały opracowane przez Cloud Security Alliance.

Cykl artykułów

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. Powoli zbliżamy się do końca, a do tej pory udało nam się omówić już sporo tematów:

• • architektura modelu cloud computingu wg NIST SP 800-145,
  • ryzyka natury organizacyjno-prawnej i zarządzania zgodnością na przykładzie pojęcia GRC – Governance, Risk management and Compliance,
  • wymagania prawne,
  • standardy bezpieczeństwa, jakie powinna spełniać usługa chmurowa i jak możemy sprawdzić, czy te standardy faktycznie spełnia,
  • RODO w chmurze,
  • zarządzanie tożsamością w chmurze i standardy SAML, OpenID, OAuth,
  • wdrożenie i zarządzanie uprawnieniami w chmurze,
  • przygotowania do wielkiej awarii,
  • bezpieczeństwo centrum danych,
  • bezpieczeństwo środowiska wirtualnego,
  • szyfrowanie w chmurze,
  • zarządzanie incydentami w chmurze,
  • interoperacyjność i przenaszalność – jak uniezależnić się od dostawcy,
  • zarządzanie cyklem życia bezpieczeństwa danych (datasecurity lifecycle),
  • Secure Software Development Cycle,
  • zarządzanie relacjami z dostawcą.

Ważnym elementem naszego cyklu są także webinary, podczas których można nie tylko posłuchać o chmurze, ale także zadać swoje pytania i otrzymać na nie odpowiedzi. Najbliższe, będące podsumowaniem całego cyklu, już 12 grudnia o godzinie 20:00 oraz 13 grudnia o godzinie 12:00. Temat: Bezpieczna migracja do chmury. Kupujemy zatem bank za złotówkę i migrujemy go do chmury. Niemożliwe? Sprawdźmy.

Kategorie SecaaS

W celu uspójnienia pojęć przytoczę kilka powszechnie znanych definicji kategorii usług.

• Bezpieczeństwo sieci (Network Security) – obejmuje usługi związane z przyznawaniem dostępu sieciowego, dystrybucją, monitorowaniem i ochroną usług sieciowych.
• Skanowanie podatności (Vulnerability Scanning) – polega na skanowaniu systemów w poszukiwaniu luk.
• Bezpieczeństwo aplikacji webowych (Web Security) – oferuje ochronę publicznie dostępnych usług w czasie rzeczywistym, przekierowując ruch sieciowy przez pośredniczącą usługę chmurową.
• Bezpieczeństwo poczty (Email Security) – dostarcza ochronę poczty przed phishingiem, złośliwymi załącznikami itp.
• Zarządzanie tożsamością i dostępem (Identity and Access Management, IAM) – umożliwia zarządzanie tożsamością i kontrolę dostępu.
• Szyfrowanie (Encryption) – proces przekształcenia danych w postać nieczytelną.
• Intrusion Management – proces wykrywania anomalii w celu zidentyfikowania lub zapobiegania incydentom lub próbom ataków.
• Data Loss Prevention (DLP) – monitorowanie, ochrona i weryfikowanie wrażliwych danych w spoczynku, przesyle i w użyciu.
• Security Information and Event Management (SIEM) – gromadzi, koreluje i analizuje informacje z różnych systemów w celu wykrywania i zapobiegania incydentom.

Kategorii usług dotyczących bezpieczeństwa jest więcej, ale na potrzeby artykułu omówię kilka przykładów oraz dobrych praktyk w odniesieniu do specyfiki chmury.

Zagrożenia wspólne

Większość wymienionych usług jest świadczona w modelu Software as a Service i współdzieli te same ryzyka.

Utrata widoczności i kontroli – brak wiedzy dostawcy na temat środowiska odbiorcy może skutkować innym poziomem szczegółowości w przypadku monitorowania i gromadzenia informacji. Dostawca dostarcza nam usługę, więc im wyżej stosu SPI się ona znajduje, tym mniejszy mamy nad nią nadzór i wpływ na jej zabezpieczenie.

Zapewnienie zgodności i różnice w regulacjach (jurysdykcja) – przy globalnym świadczeniu usług należy wziąć pod uwagę różne regulacje prawne, które musimy spełnić przy prowadzeniu działalności oraz jurysdykcję, pod jaką podlega dostawca przypadku, gdy świadczy usługi w wielu lokalizacjach, np. monitorowanie użytkowników w UE jest bardziej restrykcyjne niż w USA, przepisy dotyczące ochrony danych osobowych itp. Dane z systemów bezpieczeństwa często są bardzo istotne w śledztwie. W zależności od tego, w jakiej jurysdykcji są zlokalizowane dane, mogą one być zabezpieczone (skonfiskowane) na czas prowadzenia dochodzenia lub sporu.

Wyciek danych wrażliwych – to zagrożenie jest wpisane w specyfikę chmury. Ekonomia skali powoduje, że dane przechowywane, analizowane i monitorowane przez usługi dostawcy mogą znajdować się we współdzielonych środowiskach. Istotne jest zabezpieczenie danych również podczas przesyłania do/z usług dostawcy. Pomocne mogą okazać się mechanizmy kryptograficzne i  zrozumienie, jakie rozwiązania najbardziej nam pasują, kiedy następuje szyfrowanie, gdzie znajdują się klucze i kto nimi zarządza.

Lock-in – właściwa konfiguracja i dostrajanie systemów bezpieczeństwa do specyfiki naszego środowiska jest procesem czasochłonnym. Aby uzyskać pełny obraz poziomu bezpieczeństwa, w organizacji są one ze sobą zintegrowane. W przypadku wycofania się dostawcy lub usługi z rynku, warto zadbać o kwestie interoperacyjności i przenaszalności tej usługi wraz z danymi.

Service Level Agreement – w modelu chmury publicznej, przy środowiskach współdzielonych, dostawcy mogą nie być elastyczni i niechętnie negocjować warunki umowy. W przypadku usług bezpieczeństwa współpraca z dostawcą jest kluczowa do osiągnięcia zamierzonych celów, np. w procesie zarządzania incydentami.

Zagrożenia specyficzne dla kategorii SecaaS

Zarządzanie tożsamością i dostępem (IAM)

Relacja pomiędzy aplikacjami biznesowymi a IAM SecaaS może być rozpatrywana na dwa sposoby:

1. IAM jako usługa w chmurze,
2. IAM do usług chmurowych.

Oba rozwiązania mogą się uzupełniać, integrować z systemami on-premise i być oferowane w różnych modelach architektury.

• Jako szereg funkcjonalności znanych z tradycyjnych systemów IAM, podzielonych na logiczne warstwy:
  • polityki i zarządzanie dostępem – mechanizmy uwierzytelniania i autoryzacji,
  • zarządzanie użytkownikami – tworzenie kont, udzielanie i odbieranie dostępu, reset hasła, administracja użytkownikami,
  • zarządzanie tożsamością – synchronizacja źródła tożsamości i danych użytkowników, polityka haseł,
  • zarządzanie zgodnością – polityki zgodności, audyt i monitoring,
  • zarządzanie danymi – repozytoria danych.

IAM jako usługa w chmurze – dostęp do zasobów wewnątrz organizacji
(Cloud Security Alliance)

• IAM SecaaS może też być oferowany jako niezależne usługi, które mogą się uzupełniać.

Niezależne usługi IAM – Cloud Security Alliance

• Jako zestaw skonsolidowanych i zintegrowanych usług w postaci pojedynczego systemu IAM.

Skonsolidowany IAM SecaaS – Cloud Security Alliance

Dobre praktyki dla IAM SecaaS:

• Wszystkie dobre praktyki odnoszące się do tradycyjnego IAM (np. zasada need to know, silne hasła itd.).
• W przypadku gdy IAM SecaaS będzie wykorzystywany także do zarządzania dostępem do usług chmurowych, trzeba uwzględnić ich rozproszoną specyfikę w procesie tworzenia, modyfikacji, blokowania i usuwania kont.
• Rozdział pomiędzy dostępem i interfejsem administracyjnym (dostawca) i użytkownika końcowego (odbiorcy).
• Nadzór i monitoring kont uprzywilejowanych. Uwzględnienie również kont wykorzystywanych przez dostawcę.
• Używanie wieloskładnikowego uwierzytelnienia (MFA).
• Odpowiednie zapisy umowne SLA, w szczególności dotyczące poufności i retencji danych. zapewniające zgodność z przepisami prawnymi.
• Zapewnienie interoperacyjności i przenaszalności aplikacji oraz danych.
• Wykorzystanie modelu Federated Identity dla organizacji działających w rozproszonych środowiskach i współpracujących z wieloma podmiotami (partnerzy, klienci, dostawcy itd.):
  • Outbound SSO – dla użytkowników, aby uzyskać dostęp do usług SaaS I BPO (business process outsourcing) lub dla połączeń z systemami partnerów.
  • Inbound SSO – dla dostawców usług do dostępu do zasobów organizacji.
  • Wewnętrzne SSO – dostęp dla jednostek organizacyjnych działających w ramach grupy wspólnych interesów (grupa kapitałowa, oddziały, sieć sprzedaży itp.)

Dostawca tożsamości (IdP) na przykładzie SAML – Cloud Secuirty Alliance

DLP (Data Loss Prevention, Data Leakage Protection)

Dwoma głównymi celami DLP jest ochrona i zapobieganie wyciekowi danych podczas całego ich cyklu życia, przesyłania i tzw. spoczynku. Cel ten jest realizowany za pomocą wielu funkcji i różnych akcji.

• Wyszukiwanie plików zawierających dane podlegające ochronie na dyskach komputerów oraz udostępnionych zasobach.
• Umożliwienie transferu danych przy jednoczesnym rejestrowaniu i zbieraniu dowodów ze zdarzeń świadczących o naruszeniu polityki bezpieczeństwa.
• Blokowanie nieuprawnionego transferu danych.
• Powiadamianie administratorów i użytkowników o incydentach naruszenia bezpieczeństwa.
• Zatrzymywanie danych w oczekiwaniu na autoryzację przed wysłaniem.

Dobre praktyki dla DLP SecaaS

• Ochrona danych podczas przesyłania ich do/z usługi oraz przechowywania w DLP z wykorzystaniem adekwatnych metod szyfrowania. Dane wychodzące z silnika DLP po analizie również muszą być zabezpieczone metodami akceptowanymi przez odbiorców informacji.
• Wdrożenie mechanizmów uwierzytelnienia i kontroli dostępu (patrz IAM SecaaS).
• Uwzględnienie odpowiednich zapisów umownych regulujących kwestie jurysdykcji i mechanizmów ochrony danych w przypadku prowadzenia działań śledczych. Szczególne znaczenie ma to w przypadku środowisk współdzielonych.
• Weryfikacja możliwości integracji z wewnętrznymi politykami organizacji i ustalenie priorytetów dla stosowanych polityk.

SIEM (Security Information and Event management)

Systemy SIEM są zaprojektowane, by gromadzić logi i przepływy sieciowe z wielu systemów (operacyjnych, aplikacji, bezpieczeństwa itd.) w celu ich analizy, koleracji, monitorowania i alarmowania o incydentach i zdarzeniach mogących mieć wpływ na bezpieczeństwo. SIEM SecaaS może być zaimplementowany na kilka sposobów. Ja podam przykłady dwóch najczęściej wykorzystywanych.

1. Zewnętrzny SIEM do analizowania wewnętrznych i chmurowych zasobów organizacji.

Źródło: Cloud Security Alliance

2. Hybrydowy SIEM – wewnętrzny SIEM monitorujący wewnętrzne zasoby organizacji i chmurę prywatną zintegrowany z zewnętrznym SIEM monitorującym zewnętrzne i chmurowe zasoby organizacji.

 

Źródło: Cloud Security Alliance

W SIEM SecaaS najważniejszym aspektem jest współpraca i podział obowiązków pomiędzy personel dostawcy i odbiorcy. Poniższe pytania będą podobne jak w przypadku korzystania z usługi zewnętrznego SOC-a (Security Operations Center) lub CERT-u (Computer Emergency Response Team).

• Kto jest odpowiedzialny za monitorowanie i obsługę alarmów lokalnie i po stronie dostawcy?
• Czy dostawca jest odpowiedzialny tylko za monitorowanie i obsługę alarmów, czy ma inne obowiązki związane z postępowaniem ze zdarzeniami lub incydentami?
• Jeśli dostawca jest zaangażowany także w postępowanie ze zdarzeniami, to jaki powinien uzyskać dostęp do zarządzanych przez organizację systemów?
• Kto jest odpowiedzialny za definiowanie i implementację reguł?

Kolejnym istotnym aspektem jest integracja różnych źródeł oraz zapewnienie odpowiedniej przepustowości do przesłania tak dużej ilości logów z różnych lokalizacji, w szczególności gdy wykorzystujemy SIEM również do monitorowania usług chmurowych rozproszonych geograficznie. W takim przypadku konieczna będzie także współpraca dostawców tych usług.

Dobre praktyki dla SIEM Secaas

• Zdefiniowany, szczegółowy i jasno opisany podział obowiązków i sposób komunikacji pomiędzy dostawcą i odbiorcą w procesie obsługi alarmów i incydentów oraz definiowania i implementacji reguł i polityk.
• Alternatywny ruch do SIEM na wypadek ataku i braku możliwości wykorzystania podstawowego łącza.
• Synchronizacja czasu i uwzględnienie opóźnień wynikających z przesyłania danych do/z usługi, w szczególności przy wykorzystaniu mechanizmów kryptograficznych.
• Zapewnienie interoperacyjności i przenaszalności danych pomiędzy systemami i usługami chmurowymi zarządzanymi przez organizację a usługą SIEM.

Podsumowanie

Poniżej zamieszczam listę rekomendacji, które musimy uwzględnić jako niezbędne minimum przy korzystaniu z usług w modelu SecaaS:

• Zrozumienie i zdefiniowanie podziału obowiązków i sposobów komunikacji pomiędzy personelem dostawcy i odbiorcy usługi.
• W przypadku gdy usługa jest realizowana w rozproszonym geograficznie i współdzielonym środowisku, zapewnienie zgodności z obowiązującymi przepisami prawa i standardami. Uwzględnienie różnej jurysdykcji i wynikających z tego konsekwencji, np. zabezpieczenie danych w przypadku prowadzonego dochodzenia.
• Informacje z systemów bezpieczeństwa są bardzo istotne w przypadku zewnętrznego lub wewnętrznego śledztwa. Przepisy prawne lub wewnętrzne regulacje mogą nakładać obowiązek zachowania określonego okresu retencji danych. Należy upewnić się, że dane przetwarzane i gromadzone w usługach SecaaS będą mogły być wykorzystane przez nas lub udostępnione instytucjom zewnętrznym w akceptowany przez nie sposób.
• Zapewnienie alternatywnych łączy do usługi w przypadku ataku lub braku możliwości skorzystania z podstawowego łącza.
• Wdrożenie silnych metod uwierzytelnienia (np. MFA) i kontroli dostępu.
• Rozdział pomiędzy dostępem i interfejsem administracyjnym (dostawca) i użytkownika końcowego (odbiorcy).
• Nadzór i monitoring kont uprzywilejowanych. Uwzględnienie również kont wykorzystywanych przez dostawcę.
• Ochrona danych w całym cyklu życia danych (od wytworzenia do zniszczenia) oraz w trakcie ich przesyłania i przechowywania. Należy stosować adekwatne mechanizmy segregacji w środowiskach współdzielonych oraz szyfrowania, kiedy dane są przesyłane do/z usługi dostawcy i kiedy są tam przechowywane. Należy uwzględnić opóźnienia wynikające z zastosowania dodatkowych zabezpieczeń.
• Zapewnienie interoperacyjności i przenaszalności aplikacji i danych. Dzięki temu będziemy mogli integrować ze sobą wewnętrzne systemy i różne usługi SecaaS oraz uniknąć uzależnienia się od dostawcy.

Usługi w modelu SecaaS są narażone na te same zagrożenia i wyzwania co wszystkie usługi chmurowe, ale korzystanie z nich niesie wiele korzyści:

• OPEX, płatność za wykorzystanie, zwinność, redundancja, wysoka dostępność i odporność, możliwość zastosowania rozwiązań hybrydowych, koncentracja na core biznesie.
• Doświadczenie i kompetencje – wdrożenie wielu rozwiązań w obszarze bezpieczeństwa wymaga wysokiej wiedzy i poziomu kompetencji, wykwalifikowanego personelu i doświadczenia. Dostawcy, którzy już długo działają na rynku, nie borykają się w z problemami wieku niemowlęcego i wciąż rozwijają swoje usługi.
• Wymiana informacji o zagrożeniach („threat intelligence”). Dostawcy obsługują klientów w wielu sektorach oraz lokalizacjach i mogą dzielić się tą wiedzą wewnętrznie i szybciej reagować.
• Elastyczność we wdrożeniu w rozległych środowiskach dzięki szerokiemu dostępowi sieciowemu.

Przypominam także o możliwości zapisania się na webinary – najbliższe, będące podsumowaniem całego cyklu, już 12 grudnia o godzinie 20:00 oraz 13 grudnia o godzinie 12:00. Temat: Bezpieczna migracja do chmury.

Program:

1. Podsumowanie zagadnień poruszanych w poprzednich artykułach
2. Proces migracji krok po kroku z punktu widzenia bezpieczeństwa
3. Podsumowanie
4. Sesja pytań od uczestników

Możecie zapisywać się już teraz.

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