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

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

  1. 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.
Facebooktwittergoogle_pluslinkedin
Facebooklinkedin

Skomentuj