Przedmowa
Jak sugeruje tytuł, książka ta jest praktycznym przewodnikiem dotyczącym bezpieczeństwa w środowisku chmury. Praktycznie w większości organizacji sprawy związane z kwestiami bezpieczeństwa muszą zderzać się z problemami dotyczącymi zarówno finansowania, jak i uwzględnienia w ramach czasowych funkcjonowania organizacji i często zajmują drugorzędne miejsce w procesie wdrażania. Istotne jest zatem, aby z punktu widzenia bezpieczeństwa skupiać się na „najlepszym stosunku ceny do efektu”.
Książka ta ma na celu pomóc szybko zdobyć najistotniejsze umiejętności dotyczące kontroli bezpieczeństwa najważniejszych zasobów, niezależnie od tego, czy osoba za to odpowiedzialna jest specjalistą od spraw bezpieczeństwa, początkująca w środowisku w chmurze, czy jest projektantem lub programistą odpowiedzialnym za bezpieczeństwo. Zdobycie zaprezentowanej, fundamentalnej wiedzy umożliwi dalsze kontynuowanie, zdobywanie i szlifowanie umiejętności.
Podczas gdy wiele zasad bezpieczeństwa jest podobnych w środowisku w chmurze i w warunkach lokalnych, istnieją pewne ważne różnice praktyczne. Z tego powodu niektóre zalecenia dotyczące bezpieczeństwa w chmurze mogą być zaskakujące dla osób mających doświadczenie związane z bezpieczeństwem środowisk lokalnych. Mimo że z pewnością istnieją uzasadnione różnice zdań między specjalistami do spraw bezpieczeństwa w prawie każdym obszarze bezpieczeństwa informacji, zalecenia w tej książce wynikają z wieloletniego doświadczenia w zabezpieczaniu środowiska w chmurze i zostały oparte na najnowszych osiągnięciach w zakresie przetwarzania w tym środowisku.
Kilka pierwszych rozdziałów zostało poświęconych na zrozumienie odpowiedzialności za bezpieczeństwo w środowisku chmury oraz tego, jak różnią się one od tych w środowiskach lokalnych, a także na zrozumienie posiadanych zasobów, najbardziej prawdopodobnych zagrożeń dla tych zasobów i niektórych ich zabezpieczeń.
W kolejnych rozdziałach książki zostały zawarte praktyczne, uszeregowane według stopnia istotności, wskazówki najważniejszych umiejętności związanych z bezpieczeństwem, które należy wziąć pod uwagę w pierwszej kolejności:
• Zarządzanie tożsamością i dostępem.
• Zarządzanie podatnościami na zagrożenia.
• Kontrola sieci.
Ostatni rozdział został poświęcony wykrywaniu nieprawidłowości i radzeniu sobie z nimi. Warto przeczytać ten rozdział, zanim coś pójdzie nie tak!
Jeżeli celem czytelnika jest uzyskanie certyfikatów lub zaświadczeń dla danego środowiska, takich jak certyfikat PCI lub raport SOC 2, należy zwrócić uwagę na kilka konkretnych pułapek, które zostały opisane w niniejszej książce. Konieczna jest także znajomość wszelkich obowiązujących aktualnie przepisów, na przykład tych dotyczących danych PHI (ang. Protected Health Information) w Stanach Zjednoczonych lub przetwarzania danych osobowych obywateli UE, niezależnie od tego, gdzie tworzona aplikacja ma być hostowana.
Konwencje stosowane w tej książce
W tej książce zastosowano następujące konwencje typograficzne:
Kursywa
Wykorzystana do oznaczenia nowych definicji, adresów URL, adresów e-mail, nazw i rozszerzeń plików.
Czcionka o stałej szerokości
Wykorzystana do oznaczenia listy programów, a także w akapitach do oznaczenia elementów programu, takich jak nazwy zmiennych lub funkcji, bazy danych, typy danych, zmienne środowiskowe, instrukcje i słowa kluczowe.
Czcionka pogrubiona o stałej szerokości
Wykorzystana do oznaczenia polecenia lub innego tekstu, który użytkownik powinien wpisać dosłownie.
Kursywa o stałej szerokości
Wykorzystana do oznaczenia tekstu, który powinien zostać zastąpiony wartościami podanymi przez użytkownika lub wartościami określonymi przez kontekst.
xii | Przedmowa
Tym elementem oznaczono wskazówkę lub sugestię.
Tym elementem oznaczono uwagę ogólną.
Tym elementem oznaczono ostrzeżenie lub przestrogę.
Internetowa platforma edukacyjna O’Reilly
Od prawie 40 lat O’Reilly Media dostarcza technologię oraz szkolenia biznesowe, wiedzę, aby pomóc firmom osiągnąć sukces.
Nasza wyjątkowa sieć ekspertów i innowatorów dzieli się swoją wiedzą i doświadczeniem przez książki, artykuły, konferencje i naszą internetową platformę edukacyjną. Internetowa platforma edukacyjna O’Reilly zapewnia dostęp na żądanie do kursów szkoleniowych na żywo, niezależnych ścieżek edukacyjnych, interaktywnych środowisk programowania oraz ogromnej kolekcji tekstów i filmów od O’Reilly oraz ponad 200 innych wydawców. Więcej informacji zamieszczono na stronie http://oreilly.com
Jak się z nami skontaktować
Komentarze i pytania dotyczące tej książki prosimy kierować do wydawcy:
O’Reilly Media, Inc.
1005 Gravenstein Highway North Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)
Ta książka ma własną stronę internetową, na której zamieszczono erratę, przykłady i wszelkie dodatkowe informacje. Dostęp do tej strony można uzyskać pod adresem: http://bit.ly/practical-cloud-security
W celu skomentowania lub zadania pytania technicznego dotyczącego tej książki, wyślij e-mail’a na adres: bookquestions@oreilly.com
W celu uzyskania bardziej szczegółowych informacji o naszych książkach, kursach, konferencjach i nowościach, odwiedź naszą stronę internetową: http://www.oreilly.com
Znajdź nas na Facebooku: http://facebook.com/oreilly
Śledź nas na Twitterze: http://twitter.com/oreillymedia
Obejrzyj nas na YouTube: http://www.youtube.com/oreillymedia
Jak się z nami skontaktować | xiii
Podziękowanie
Książka ta nie istniałaby bez zachęty i wsparcia mojej cudownej żony, Tabithy Dotson, która uświadomiła mi, że nie mogę przepuścić tej okazji i nie opublikuję tej książki, jeśli przez ponad rok będę zaniedbywać harmonogram i obowiązki. Chciałbym również podziękować moim dzieciom, Samantha’cie (za jej rozległą wiedzę na temat mitologii greckiej) i Molly (za nieustanne podważanie założeń i myślenie nieszablonowe).
Oprócz autora, wiele innych osób przyczyniło się do publikacji tej książki, czego nie doceniłem w pełni przed jej napisaniem. Chciałbym podziękować moim redaktorom, Andy’emu Oramowi i Courtneyowi Allenowi. Moim recenzentom, Hansowi Donkerowi, Darrenowi Dayowi i Edgarowi Ter Danielyanowi oraz reszcie wspaniałego zespołu O’Reilly, który poprowadził mnie i wsparł w procesie publikacji. Na koniec chciałbym podziękować wszystkim moim znajomym, rodzinie, kolegom i mentorom, którzy przez lata odpowiadali na pytania, dyskutowali o pomysłach, słuchali kiepskiej gry słów, śmiali się z moich błędów i faktycznie nauczyli mnie większości treści z tej książki.
xiv | Przedmowa
Zarządzanie zmianami
Wiele organizacji ma pewnego rodzaju funkcjonalność zarządzania zmianami. W najprostszej formie zarządzanie zmianami powinno gwarantować, że zmiany zostaną wprowadzone dopiero po ich zatwierdzeniu, a ocena ryzyka ich wprowadzenia została poddana ocenie.
Zarządzanie zmianami może być przydatne w zarządzaniu podatnościami, pozwalając upewnić się, że proponowane zmiany nie przyczynią się do wprowadzenia nowych podatności na zagrożenia do systemu. Jednocześnie, w przypadku nieprawidłowego wykonania, zarządzanie zmianami może również utrudniać zarządzanie podatnościami i przyczyniać się do zwiększania ogólnego r yzyka przez spowolnienie zmian niezbędnych do usunięcia tych podatności.
Jak zostało to omówione w tym rozdziale, niektóre nowe technologie środowisk w chmurze mogą przyczyniać się do zmniejszenia ryzyka całkowitego wyłączenia tak, że przy mniejszym udziale ręcznego zarządzania zmianami możliwe jest osiągnięcie tego samego poziomu ryzyka operacyjnego. Część ogólnego programu zarządzania podatnościami na zagrożenia w chmurze może wpływać na modyfikację procesów zarządzania zmianami.
Na przykład przekazywanie nowego kodu wraz z poprawkami zabezpieczeń do produkcji może być normalnym działaniem, automatycznie zatwierdzanym przez zespół kontroli zmian, pod warunkiem istnienia zademonstrowanego procesu szybkiego powrotu do prawidłowego stanu. Może to zostać osiągnięte przez kolejną aktualizację, doprowadzającą do przywrócenia poprzedniej wersji lub przez wyłączenie ruchu do nowej wersji aplikacji, aż do momentu rozwiązania problemu. Jednakże większe zmiany, takie jak zmiany w projekcie aplikacji, mogą nadal wymagać przejścia do ręcznego procesu zarządzania zmianami.
W idealnym przypadku w procesie kontroli zmian powinien brać udział co najmniej jeden specjalista do spraw bezpieczeństwa, zaangażowany jako członek zespołu kontroli zmian, ewentualnie jako doradca.
Udokumentowany proces zarządzania zmianami jest wymagany w przypadku szeregu certyfikatów przemysłowych i regulacyjnych, w tym SOC 2, ISO 27001 i PCI DSS.
Połączenie wszystkiego w przykładowej aplikacji
Na rysunku 5.3 przedstawiono przykładową, naprawdę prostą, trójwarstwową aplikację z rozdziału 1.
W przypadku zorganizowanego środowiska mikrousług opartych na kontenerach z testowymi i produkcyjnymi klastrami Kubernetes, przykładowa aplikacja może wyglądać nieco inaczej. Jednakże nadal możliwe jest wyodrębnienie tych samych, trzech głównych poziomów na środku schematu (rysunek 5.4).
Połączenie wszystkiego w przykładowej aplikacji | 105
Granica zaufania DMZ
Granica zaufania aplikacji
Granica zaufania bazy danych
Użytkownik
HTTPS
Serwery webowe
HTTPS
SSH SSH
Serwery aplikacji
db
Serwery baz danych
Dane klienta
SSH, DB
Administrator
Rysunek 5.3. Schemat przykładowej aplikacji
Przeglądający kod
Hmm, czy to wygląda dobrze?
Repozytorium kodu źródłowego
Granica zaufania całej aplikacji
Administrator/ programista Użytkownik Pentester
Aktualizacja modułu/ pracownika
1) Kod zatwierdzenia
Triggered on commit
t Automatyzacja pipeline wdrażania
2) Jakieś błędy lub podatne zależności?
Statyczny skaner kodu i parsowanie oprogramowania 4 d te w
Dynamiczne testowanie aplikacji w stosunku do: / dashboard / widget1 / widget2
3) Przesłanie kopii, aby przetestować klaster i uruchomić test funkcjonalny/ integracyjny
4) Uruchomienie dynamicznego testowania aplikacji względem klastra
5) Wdrożenie w klastrze produkcyjnym
HTTPS Złamię to!
Kontrolery Kubernetes Ingress (serwery WWW)
| Rozdział 5: Zarządzanie podatnościami
HTTPS
Skaner podatności na zagrożenia sieciowe
/widget1 (agenci IAST and RAST)
/dashboard (agenci IAST and RAST) Mik
DB / TLS
/widget2 (agenci IAST and RAST)
Codziennie – zbieranie adresów sieciowych z zapasów i testowanie wszystkich portów
Kontener bazy danych Mikroserwery aplikacji
Persistent Volume Claim
likji
Podatny?
Skaner kontenerów y dkjKbt Skaner agentowy (na każdym węźle roboczym)
Klastry testowe i produkcyjne Kubernetes, złożone z maszyn wirtualnych węzłów roboczych (nie pokazano)
Konsola skanera agentowego
Znalezienie podatności na zagrożenia – powiadomienie!
Rysunek 5.4. Schemat przykładowej aplikacji w architekturze mikrousług
Jeśli kontenery zawierają pełną kopię systemu operacyjnego i pozwalają administratorom na logowanie, to stanowią w zasadzie miniaturowe maszyny wirtualne. Mimo że kontenerów można używać w trybie „minimaszyny wirtualnej”, nie jest to najlepszy sposób ich wykorzystania. Strategia zarządzania zasobami dla kontenerów zależy częściowo od tego, w jaki sposób są wykorzystywane. Poniżej omówiono dwa modele: „natywny” model kontenera oraz model „minimaszyny wirtualnej”.
Natywny model kontenera. W natywnym modelu kontenera:
• Kontenery powinny zawierać absolutnie minimalne elementy systemu operacyjnego niezbędne do wykonywania ich funkcji.
• Każdy kontener powinien spełniać tylko jedną funkcję (lub „sprawy” w pewnej dokumentacji).
• Kontenery powinny być niezmienne, co oznacza, że nie powinny zmieniać się z czasem. Kontenery mogą wprowadzać zmiany w niektórych innych komponentach, takich jak zapis danych do usługi magazynowania, ale pamięć ta powinna być utrzymywana niezależnie od samego kontenera.
• Niezmienne kontenery powinny pozostawać doskonałą kopią kodu zawartego w obrazie przez cały okres ich życia. Kod nie powinien być aktualizowany przez samego siebie ani żadną inną logującą się do niego osobę. Zamiast aktualizacji kontenerów, stare kontenery powinny być kasowane, a na ich miejsce tworzone nowe kontenery ze zaktualizowanym kodem.
W przypadku natywnych, niezmiennych kontenerów nie powinien istnieć żaden wymóg rutynowej konserwacji wykonywanej przez administratorów logujących się do kontenerów, aczkolwiek należy zapewnić pewne, awaryjne możliwości uzyskania dostępu. Jeśli logowanie do kontenerów nie jest ogólnie dozwolone, zarządzanie dostępem do kontenerów staje się mniej ryzykowne niż w przypadku serwerów. Zarządzanie podatnościami i konfiguracją pozostają nadal istotnymi zagrożeniami, aczkolwiek zakres dla danego kontenera jest znacznie węższy niż zakres dla serwera, który na ogół może wykonywać wiele różnych funkcji.
Natywne kontenery są generalnie tworzone i kasowane znacznie częściej niż maszyny wirtualne. Oznacza to, że bardziej sensowne jest inwentaryzowanie obrazów kontenerów niż samych kontenerów i następnie śledzenie, z którego obrazu kopiowany jest kontener. Obraz kontenera musi zostać zinwentaryzowany przede wszystkim w celu śledzenia oprogramowania i konfiguracji obrazu, tak aby obraz mógł zostać zaktualizowany o poprawki bezpieczeństwa oraz nowe konfiguracje w miarę wykrycia podatności na zagrożenia.
Rodzaje zasobów w środowisku w chmurze | 35 mogą być też dodatkowe kontrole przeprowadzane przez jądro. Możliwe jest także wykorzystanie hybrydowych rozwiązań, łączących większą izolację maszyn wirtualnych lub oddzielne systemy fizyczne z łatwością wdrażania kontenerów.
Model kontenera „Minimaszyna wirtualna”. W modelu, w którym kontenery są traktowane jak miniaturowe maszyny wirtualne:
• Kontenery zwykle uruchamiają pełną kopię komponentów trybu użytkownika systemu operacyjnego.
• Kontenery pełnią wiele funkcji, takich jak uruchamianie dwóch różnych rodzajów usług w tym samym kontenerze.
• Kontenery umożliwiają logowanie administracyjne i zmieniają się z czasem.
Jeśli kontenery są wykorzystywane jako minimaszyny wirtualne, powinny być inwentaryzowane i chronione w taki sam sposób jak maszyny wirtualne. Oznacza to instalowanie agentów do inwentaryzacji oraz śledzenie użytkowników, oprogramowania i wszystkich innych elementów wymienionych w poprzedniej części dotyczącej maszyn wirtualnych.
W obu modelach obrazy powinny być inwentaryzowane i aktualizowane tak, aby nowo tworzone kontenery były pozbawione podatności na zagrożenia.
Systemy orkiestracji kontenerów. Kontenery są świetne, ale jeszcze lepiej jest mieć coś, co może być wykorzystane do: łączenia kontenerów w pakiety w celu wykonywania funkcji wyższego poziomu, uruchamiania wielu kopii tych pakietów, równoważania obciążenia tych kopii i udostępniania innych funkcjonalności, takich jak łatwe sposoby komunikowania się komponentów między sobą. Taki typ systemu nazywany jest systemem orkiestracji kontenerów.
Najpopularniejszą implementacją orkiestracji kontenerów jest Kubernetes z kontenerami Docker. We wdrożeniu Kubernetes podstawowymi zasobami są klastry, w których przechowywane są pods (zasobniki), w których z kolei przechowywane są kontenery Docker kopiowane z obrazów. W środowisku Kubernetes należy rozważyć inwentaryzację następujących komponentów:
• Klastry Kubernetes, dzięki czemu można kontrolować dostęp do nich, a oprogramowanie Kubernetes może być aktualizowane. Podatności na zagrożenia w oprogramowaniu Kubernetes mogą stanowić zagrożenia dla wszystkich działających w nich zasobnikach.
• Kubernetes pods, które mogą zawierać jeden lub więcej kontenerów Docker. Za pomocą wiersza poleceń Kubernetes lub interfejsu API można śledzić istniejące pods oraz kontenery, które tworzą te pods.
• Obrazy kontenerów Docker.
aplikacja Platforma jako usługa
Oferty aplikacji działających na zasadzie Platforma jako usługa (aPaaS), takie jak Cloud
Foundry lub AWS Elastic Beanstalk, umożliwiają wdrożenie kodu bez samodzielnego przydzielania maszyn wirtualnych. Oferty te obejmują również wiele innych zasobów,
Rozdział 3: Zarządzanie zasobami danych i ich ochrona
Reagowanie na zdarzenie
W sytuacji, gdy nie został jeszcze powołany zespół reagowania na incydent, nie zostały opracowane plany, brak jest narzędzi i list kontrolnych, priorytetem powinno być powstrzymanie incydentu bez niszczenia dowodów. Zazwyczaj jest to wykonywane przez kombinację zamykania lub poddania kwarantannie systemów, zmiany haseł, odwoływanie dostępu i blokowanie połączeń sieciowych. Jednocześnie zalecane jest skontaktowanie się z firmami zajmującymi się reagowaniem na incydenty i uzyskanie od nich informacji potrzebnych do lepszego przygotowania się na incydenty w przyszłości.
Co należy zrobić w przypadku odkrycia czegoś, co wygląda jak prawdziwy atak? Odpowiedź na takie pytanie w dużej mierze zależy od działań podjętych przez osobę atakującą oraz od tego, jak wygląda przyjęty model zagrożenia, aczkolwiek istnieje kilka wskazówek, które mogą być pomocne.
W pierwszym etapie należy zmobilizować przynajmniej część zespołu tak, aby dokonać oceny stanu zaatakowanego systemu. Nie ma sensu angażowanie 30 osób z powodu infekcji złośliwym oprogramowaniem, która po kilku minutach dochodzenia wydaje się całkowicie opanowana. Tak jak łatwo jest o przesadną reakcję, tak samo łatwo o reakcję zbyt słabą. W takim przypadku mogą być pomocne pewne wstępnie zdefiniowane poziomy istotności i wytyczne dotyczące reakcji dla każdego z tych poziomów.
Następnie należy rozpocząć realizację opracowanych planów, starając się przewidzieć najbardziej prawdopodobne cele osoby atakującej, opierając się na kill chains lub attack chains.
Cyber Kill Chains
Jak wspomniano już na początku tego rozdziału, jednym z najpopularniejszych obecnie łańcuchów jest Lockheed-Martin Cyber Kill Chain. Zgodnie z tym modelem można wyróżnić następujące fazy zagrożenia:
Rozpoznanie
Przez osobę atakującą przeprowadzane są badania, mające na celu określenie, gdzie można się włamać i jakie podatności mogą być w tym pomocne. Działania takie mogą obejmować wszystko, od wyszukiwania w Google, grzebania w śmieciach, inżynierię społeczną, po skanowanie portów sieciowych.
Uzbrajanie
W tym etapie tworzone jest złośliwe oprogramowanie w celu wykorzystania znalezionych luk. Bardziej zaawansowani atakujący mogą napisać coś niestandardowego, aczkolwiek w przypadku mniej zaawansowanych ataków może być użyte standardowe oprogramowanie znalezione w internecie.
Dostarczanie złośliwego kodu
Ofiara jest zmuszana przez osobę atakującą do wykonania złośliwego oprogramowania, najczęściej przez atak sieciowy, wysłanie e-maila lub w inny sposób.
Eksploitacja
Szkodliwe oprogramowanie zaczyna działać i następnie uzyskiwany jest nieautoryzowany dostęp.
Instalacja
Złośliwe oprogramowanie jest umacniane przez instalację utrudniającą znalezienie i usunięcie tego oprogramowania, co jest zgodne z intencjami osoby atakującej. Często pierwszy kawałek złośliwego oprogramowania jest wykorzystywany do pobrania i instalacji drugiego elementu złośliwego oprogramowania. W niektórych przypadkach to trwałe złośliwe oprogramowanie jest lepiej obsługiwane i aktualizowane niż legalne programy użytkownika!
Command and control
W wyniku działania złośliwego oprogramowania tworzony jest pewnego rodzaju kanał komunikacyjny, który umożliwia osobie atakującej zdalną kontrolę nad nim: zdalna powłoka, wychodzące połączenie internetowe, a nawet odczyt poleceń z usługi przechowywania plików w chmurze. W tym momencie dostęp do systemów może być sprzedany na czarnym rynku w dobrej cenie komuś, kto takiego dostępu potrzebuje.
Działania na „przejętym” celu
Osoba atakująca, która może nawet nie jest pierwotną osobą atakującą, jest w stanie zrobić wszystko, co chce: ukraść dane, zniszczyć witryny, zaatakować klientów, wyłudzać pieniądze itp.
Inne popularne łańcuchy, takie jak MITER ATT&CK zawierają nieco inne etapy. Niezależnie od tego, który z łańcuchów jest wykorzystywany, dobrym pomysłem jest zapoznanie się z co najmniej jednym z nich, tak aby mieć pojęcie o tym, co napastnik mógł już zrobić i co może zrobić dalej.
Pętla OOda (Obserwacja-Orientacja-d
ecyzja-akcja)
Kolejnym etapem po sporządzeniu planu, określeniu postępów i planów osoby atakującej jest reakcja. Popularną koncepcją reagowania na incydenty jest pętla OODA: obserwuj, orientuj, decyduj i działaj:
1. W fazie obserwacji należy zebrać informacje z systemów, takie jak dzienniki dostawcy usług w chmurze, zapór sieciowych, systemu operacyjnego oraz mierniki i inne lokalizacje pomocne w znalezieniu nietypowych zachowań, które mogą wskazywać na aktywność osoby atakującej.
2. W fazie orientacji należy zrozumieć, co się dzieje i co może się stać dalej. Może to obejmować zarówno wewnętrzną wiedzę o tym, gdzie znajdują się najważniejsze zasoby, jak i zewnętrzne informacje o zagrożeniach dotyczące tego, kto może być odpowiedzialny za atak i dlaczego. Nie wszystkie informacje o zagrożeniach są płatne. Na przykład US-CERT (https://www.us-cert.gov/) regularnie publikuje
168 | Rozdział 7: Wykrywanie, reagowanie i odzyskiwanie po incydentach bezpieczeństwa
