Dane oryginału

Authorized Polish translation of the English edition of Practical Cloud Security, ISBN 9781492037514

© 2019 Chris Dotson

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Przekład Piotr Fabijańczyk na zlecenie WITKOM Witold Sikorski

Projekt okładki polskiego wydania INT-MEDIA Dawid Mazur na podstawie oryginału

Wydawca Edyta Kawala

Redaktor prowadzący Jolanta Kowalczuk

Redaktor Anna Bogdanienko

Koordynator produkcji Anna Bączkowska

Skład wersji elektronicznej na zlecenie Wydawnictwa Naukowego PWN: Katarzyna Błaszczyk/Woblink

Konsultacja merytoryczna

Kamil Frankowicz

Zastrzeżonych nazw firm i produktów użyto w książce wyłącznie w celu identyfikacji.

Copyright © for the Polish edition by Wydawnictwo Naukowe PWN SA

Warszawa 2020

ISBN 978-83-01-21121-9

eBook został przygotowany na podstawie wydania papierowego z 2020 r., (wyd. I)
Warszawa 2020

Wydawnictwo Naukowe PWN SA

02-460 Warszawa, ul. Gottlieba Daimlera 2

tel. 22 69 54 321, faks 22 69 54 288

infolinia 801 33 33 88

e-mail: pwn@pwn.com.pl, reklama@pwn.pl

www.pwn.pl

Spis treści

Przedmowa

Rozdział 1. Zasady i pojęcia

Najmniejsze uprzywilejowanie

Bezpieczeństwo od podstaw

Potencjalni atakujący, diagramy i granice zaufania

Model świadczenia usługi w chmurze

Model współodpowiedzialności w chmurze

Zarządzanie ryzykiem

Rozdział 2. Zarządzanie zasobami danych i ich ochrona

Identyfikacja i klasyfikacja danych

Przykładowe poziomy klasyfikacji danych

Istotniejsze wymagania branżowe i prawne

Zarządzanie zasobami danych w chmurze

Oznaczanie zasobów w chmurze

Ochrona danych w chmurze

Tokenizacja

Szyfrowanie

Podsumowanie

Rozdział 3. Zarządzanie zasobami danych i ich ochrona

Różnice w stosunku do tradycyjnego IT

Rodzaje zasobów w środowisku w chmurze

Zasoby obliczeniowe

Zasoby pamięci

Zasoby sieciowe

Pipeline zarządzania zasobami

Wycieki podczas wyboru usługi

Wycieki wynikające z przetwarzania

Wycieki wynikające z wykorzystania narzędzi

Wycieki wynikające z zaniedbania ryzyka

Oznaczanie zasobów w chmurze

Podsumowanie

Rozdział 4. Zarządzanie tożsamością i dostępem

Różnice w stosunku do tradycyjnego IT

Cykl życia dla tożsamości i dostępu

Żądanie

Zatwierdzanie

Utwórz, usuń, udziel lub odwołaj

Uwierzytelnianie

Tożsamości IAM w chmurze

Relacje firma-klient i firma-pracownik

Uwierzytelnianie wielopoziomowe

Hasła i klucze API

Współdzielone tożsamości

Tożsamość federacyjna

Pojedyncze logowanie

Metadane instancji i dokumenty tożsamości

Zarządzanie sekretami

Autoryzacja

Scentralizowana autoryzacja

Role

Przedłużanie ważności

Połączenie wszystkiego w przykładowej aplikacji

Podsumowanie

Rozdział 5. Zarządzanie podatnościami

Różnice w stosunku do tradycyjnego IT

Zagrożone obszary

Dostęp do danych

Aplikacje

Oprogramowanie pośredniczące

System operacyjny

Sieć

Infrastruktura wirtualna

Infrastruktura fizyczna

Znajdowanie i naprawianie podatności

Skanery podatności na zagrożenia sieciowe

Skanery bezagentowe i zarządzanie konfiguracją

Skanery agentowe i zarządzanie konfiguracją

Narzędzia zarządzania bezpieczeństwem od dostawcy chmury

Skanery kontenerów

Dynamiczne skanery aplikacji (DAST)

Statyczne skanery aplikacji (SAST)

Skanery analizy składu oprogramowania (SCA)

Interaktywne skanery aplikacji (IAST)

Runtime Application Self-Protection Scanners (RASP)

Ręczne sprawdzenie kodu

Testy penetracyjne

Raporty użytkowników

Przykładowe narzędzia do zarządzania podatnościami i konfiguracją

Procesy zarządzania ryzykiem

Mierniki zarządzania podatnościami

Zakres narzędzi

Średni czas naprawy

Systemy/aplikacje z niezałatanymi podatnościami

Odsetek wyników fałszywie pozytywnych

Odsetek wyników fałszywie negatywnych

Mierniki powtarzalności podatności

Zarządzanie zmianami

Połączenie wszystkiego w przykładowej aplikacji

Podsumowanie

Rozdział 6. Bezpieczeństwo sieci

Różnice w stosunku do tradycyjnego IT

Pojęcia i definicje

Białe i czarne listy

Strefy DMZ

Proxy

Sieci definiowane programowo

Wirtualizacja funkcji sieciowych

Sieci nakładkowe i enkapsulacja

Prywatne chmury wirtualne

Network Address Translation

IPv6

Połączenie wszystkiego w przykładowej aplikacji

Szyfrowanie w trakcie przesyłania

Zapory i segmentacja sieci

Zezwalanie na dostęp administracyjny

Zapora sieciowa aplikacji internetowych i RASP

Anty-DDoS

Systemy wykrywania i zapobiegania włamaniom

Filtrowanie ruchu wychodzącego z sieci

Zapobieganie utracie danych

Podsumowanie

Rozdział 7. Wykrywanie, reagowanie i odzyskiwanie po incydentach bezpieczeństwa

Różnice w stosunku do tradycyjnego IT

Co monitorować

Dostęp użytkownika uprzywilejowanego

Dzienniki narzędzi defensywnych

Dzienniki i mierniki usług w chmurze

Dzienniki i mierniki systemu operacyjnego

Dzienniki oprogramowania pośredniczącego

Serwer sekretów

Twoja aplikacja

Jak monitorować?

Agregacja i zatrzymywanie

Parsowanie

Wyszukiwanie i korelacja

Alarmowanie i automatyczna reakcja

Informacje o bezpieczeństwie i menedżerowie zdarzeń

Threat Hunting

Przygotowanie do incydentu

Zespół

Plany

Narzędzia

Reagowanie na zdarzenie

Cyber Kill Chains

Pętla OODA (Obserwacja-Orientacja-Decyzja-Akcja)

Forensic w chmurze

Blokada nieautoryzowanego dostępu

Zatrzymywanie ekstrakcji danych oraz komunikacji z serwerami C&C

Odzyskiwanie

Ponowne instalowanie systemów informatycznych

Powiadomienia

Zdobyta wiedza

Przykładowe mierniki

Przykładowe narzędzia do wykrywania, reagowania i odzyskiwania

Połączenie wszystkiego w przykładowej aplikacji

Monitorowanie systemów ochronnych

Monitorowanie aplikacji

Monitorowanie administratorów

Zrozumienie infrastruktury audytu

Podsumowanie

O autorze

O ilustracji na okładce

Przypisy

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.

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

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.

Rozdział 1
Zasady i pojęcia

Tak, ta książka została napisana jako praktyczny przewodnik, jednakże w pierwszej kolejności konieczne jest omówienie kilku istotnych dla chmury zasad wysokiego poziomu bezpieczeństwa przed skupieniem się na praktycznych elementach. W przypadku gdy czytelnik uzna, że jest doświadczonym specjalistą do spraw bezpieczeństwa, ale początkującym w środowisku w chmurze, możliwe jest przejście od razu do podrozdziału „Model współodpowiedzialności w chmurze”.

Najmniejsze uprzywilejowanie

Zasada najmniejszego uprzywilejowania stanowi po prostu, że użytkownicy bądź też zautomatyzowane narzędzia powinny mieć dostęp ograniczony tylko i wyłącznie do tego, co jest im potrzebne do wykonywania pracy. Bardzo łatwo jest jednak pominąć prawa dostępu narzędzi zautomatyzowanych. Na przykład komponent uzyskujący dostęp do bazy danych nie powinien używać danych uwierzytelniających umożliwiających zapis do bazy danych, jeśli dostęp do zapisu nie jest mu potrzebny.

Praktyczne zastosowanie zasady najmniejszego uprzywilejowania często oznacza, że z zasady dostęp jest domyślnie zabroniony. Oznacza to, że użytkownicy nie mają domyślnie żadnych lub niewiele uprawnień i muszą przejść proces żądania i następnie zatwierdzenia wymaganych uprawnień.

W środowisku chmury niektórzy administratorzy muszą mieć dostęp do konsoli chmury, czyli strony internetowej, która umożliwia tworzenie, modyfikowanie i kasowanie zasobów w chmurze, takich jak na przykład maszyny wirtualne. W przypadku środowisk w chmurze różnych dostawców, każdy posiadacz dostępu do konsoli chmury ma jednocześnie także domyślne „boskie” uprawnienia do wszystkiego, czym zarządza ten dostawca chmury. Może to obejmować możliwość odczytywania, modyfikowania lub kasowania danych w dowolnej części środowiska w chmurze, niezależnie od tego, jakie mechanizmy kontrolne obowiązują w udostępnianych systemach operacyjnych. Z tego powodu konieczne jest zapewnienie ścisłej kontroli dostępu i uprawnień do konsoli w chmurze, podobnie jak ściśle kontrolowany jest dostęp do fizycznego centrum danych w środowiskach lokalnych oraz rejestrowane jest to, co robią użytkownicy.

Bezpieczeństwo od podstaw

W sytuacji gdy wiele z przedstawionych w tej książce elementów kontrolnych zostało idealnie zaimplementowanych, nie istniałaby potrzeba stosowania innych elementów tego typu. Bezpieczeństwo od podstaw jest założeniem, że prawie każda kontrola bezpieczeństwa może zawieść, ponieważ osoba atakująca może być wystarczająco zdeterminowana lub też istnieje problem ze sposobem, w jaki kontrola bezpieczeństwa jest realizowana. W przypadku bezpieczeństwa od podstaw tworzonych jest wiele nakładających się na siebie warstw mechanizmów kontroli bezpieczeństwa, tak aby w razie niepowodzenia jednej, kolejna z nich mogła wychwycić atakujących.

W przypadku bezpieczeństwa od podstaw istnieje pewna możliwość popadnięcia w nierozsądne skrajności, dlatego ważne jest zrozumienie zagrożenia, z jakimi prawdopodobnie będzie trzeba się zmierzyć, a które zostały opisane w dalszej części tej książki. Zasadniczo jednak powinno się być w stanie wskazać dowolną kontrolę bezpieczeństwa i powiedzieć: „A co, jeśli to się nie powiedzie?” Jeśli odpowiedź to kompletne niepowodzenie, najprawdopodobniej bezpieczeństwo od podstaw nie zostało zapewnione w wystarczającym stopniu.

Potencjalni atakujący, diagramy i granice zaufania

Istnieją różne sposoby myślenia o ryzyku, ale zazwyczaj preferowane jest podejście zorientowane na zasoby. Oznacza to, że najpierw należy się skoncentrować na tym, co musi być chronione, właśnie dlatego też w rozdziale 2 poruszono najpierw zagadnienia związane z zasobami danych.

Warto również pamiętać, kim najprawdopodobniej może być osoba powodująca problemy. W mowie cyberbezpieczeństwa są to „potencjalni atakujący”. Na przykład osoba odpowiedzialna za bezpieczeństwo niekoniecznie może zostać zmuszona do obrony przed dobrze finansowanym podmiotem państwowym, a jedynie przed przestępcą, który jest nastawiony na czerpanie zysków z kradzieży danych lub też jest „haktywistą” mającym na celu zniszczenie strony internetowej. Należy pamiętać o tych osobach podczas projektowania wszystkich zabezpieczeń.

Mimo że dostępnych jest wiele informacji oraz dyskusji na temat potencjalnych atakujących, ich motywacji oraz metod, jakie są przez nich wykorzystywane[1], to w książce rozważono cztery główne typy potencjalnych atakujących, które warte są uwzględnienia:

- Przestępczość zorganizowana lub niezależni przestępcy, zainteresowani przede wszystkim zarabianiem pieniędzy.

- „Haktywiści”, zainteresowani przede wszystkim dyskredytowaniem przez rozpowszechnianie skradzionych danych, popełnianiem aktów wandalizmu lub zakłócaniem działalności firmy.

- Wewnętrzni napastnicy, zwykle zainteresowani dyskredytowaniem lub zarabianiem pieniędzy.

- Podmioty państwowe, które mogą być zainteresowane kradzieżą tajemnic lub zakłóceniem działalności firmy.

W celu zapożyczenia metod z realnych doświadczeń użytkowników korzystne jest wyobrażenie sobie członka każdej z wymienionych grup, nadanie mu nazwy, zanotowanie wybranych „cech osobowości” na kartach, które później mogą zostać wykorzystane podczas projektowania sposobów obrony.

Drugą czynnością, jaką należy zrobić, jest zrozumienie sposobów i kierunków komunikacji w projektowanej aplikacji, a najłatwiejszą metodą do wykonania tego jest narysowanie całości i przeanalizowanie, gdzie mogą być zlokalizowane podatności na zagrożenia. Dostępne są całe książki o tym, jak to zrobić[2], ale nie trzeba być ekspertem, aby narysować coś na tyle przydatnego, aby było to pomocne w podejmowaniu decyzji. W przypadku gdy sprawa dotyczy środowiska narażonego na wysokie ryzyko, należy jednak stworzyć formalne diagramy za pomocą odpowiednich narzędzi, a nie bazować na prostych schematach.

Mimo że istnieje wiele różnych możliwych architektur oprogramowania omówionej aplikacji, poniżej zaprezentowano prosty trójpoziomowy sposób projektowania:

1. W pierwszym kroku należy narysować ikonkę i oznaczyć ją jako „użytkownik”. Następnie kolejną figurkę i oznaczyć ją jako „administrator” (rysunek 1.1). Jak opisano później, może występować wiele typów użytkownika, administratora i innych ról, jest to jednak dobry punkt wyjściowy.

Rysunek 1.1. Role użytkownika i administratora

2. Następnie należy dodać pole dla pierwszego komponentu, z którym komunikuje się użytkownik (na przykład serwery sieciowe). Kolejnym krokiem jest narysowanie linii od użytkownika do tego pierwszego komponentu i opisanie jej, w jaki sposób użytkownik komunikuje się z tym komponentem (rysunek 1.2). Należy zauważyć, że komponent ten może być usługą serverless, kontenerem, maszyną wirtualną lub czymś innym. Połączenie takie umożliwia każdemu komunikację z tym komponentem, tak więc najprawdopodobniej jest to pierwsza rzecz do zrobienia. Naprawdę nie jest konieczne, aby inne komponenty zaufały temu komponentowi bardziej, niż jest to konieczne.

Rysunek 1.2. Pierwszy komponent

3. Za polami pierwszych komponentów należy narysować dodatkowe pola dla wszystkich innych komponentów, z którymi musi komunikować się pierwszy komponent. Należy połączyć je liniami (rysunek 1.3). Ilekroć zostanie osiągnięta granica systemu, który faktycznie przechowuje dane, należy oznaczyć go małym symbolem (na przykład cylindrem) i dodać opis jakiego typu dane są tam przechowywane. Należy kontynuować tworzenie schematu, dopóki nie jest już możliwe określenie dodatkowych komponentów w projektowanej aplikacji.

Rysunek 1.3. Dodatkowe komponenty

4. W kolejnym kroku należy narysować, w jaki sposób administrator oraz wszelkie inne zdefiniowane role uzyskują dostęp do aplikacji. Należy pamiętać, że administrator może mieć kilka różnych sposobów komunikowania się z tą aplikacją: na przykład za pośrednictwem portalu dostawcy usługi chmury, interfejsów API, dostępu do systemu operacyjnego lub przez komunikowanie się z aplikacją w sposób podobny do tego, w jaki robi to użytkownik (rysunek 1.4).

Rysunek 1.4. Dostęp administratora

5. Następnie należy zaznaczyć wybrane granice zaufania kreskowanymi liniami (rysunek 1.5). Granica zaufania oznacza, że wszystko w tej granicy może być przynajmniej w pewnym stopniu pewne motywów działania czegokolwiek mieszczącego się w tej granicy, aczkolwiek wymagana jest weryfikacja przed zaufaniem czemukolwiek spoza granicy zaufania. Należy założyć, że jeśli osoba atakująca dostanie się w obręb pewnej granicy zaufania, ostatecznie uzyska pełną kontrolę nad wszystkim, co się w niej znajduje, tak więc przejście przez każdą kolejną granicę zaufania powinno wymagać wysiłku. Należy zauważyć, że na rysunku umieszczonych jest wiele serwerów internetowych w tej samej granicy zaufania. Oznacza to, że te serwery sieciowe mogą sobie całkowicie ufać, a jeśli ktoś ma dostęp do jednego, tak naprawdę ma dostęp do pozostałych. Innymi słowy, jeśli ktoś zdobędzie dostęp do jednego z tych serwerów sieciowych, nie zostaną wyrządzone dalsze szkody, jeśli zdobędzie dostęp do pozostałych.

Rysunek 1.5. Granice zaufania dla komponentów

6. Do pewnego stopnia skomponowany system jest obdarzony większym zaufaniem niż wszystko, co znajduje się poza tym systemem. Należy więc narysować kreskowaną linię wokół wszystkich komponentów, w tym administratora, ale pomijając użytkownika (rysunek 1.6). Trzeba pamiętać, że jeśli jest wielu administratorów, takich jak administrator serwera www i administrator bazy danych, mogą się oni znajdować w różnych granicach zaufania. Fakt, że istnieją granice zaufania wewnątrz innych granic zaufania, obrazuje różne poziomy zaufania. Na przykład serwery mogą akceptować połączenia sieciowe z serwerów znajdujących się w innych granicach zaufania aplikacji, ale nadal weryfikować ich tożsamość. Mogą nawet nie przyjmować połączeń z systemów znajdujących się poza całą granicą zaufania aplikacji.

Rysunek 1.6. Granice zaufania dla przykładowej aplikacji

Stworzony schemat przykładowej aplikacji jest wykorzystywany w całej książce do omawiania modelu współodpowiedzialności, spisu zasobów, kontroli i monitorowania. W tej chwili na schemacie nie ma żadnych elementów sterujących specyficznych dla chmury, zostały one jednak dodane w kolejnych rozdziałach. Należy zwrócić szczególną uwagę na dowolne miejsca, w których linia oznaczająca komunikację przekracza granicę zaufania. Są to miejsca, na których należy się skoncentrować w pierwszej kolejności!

Model świadczenia usługi w chmurze

Istnieje niepisane prawo, że żadna książka na temat przetwarzania w chmurze nie jest kompletna bez omówienia modeli świadczenia usług, takich jak Infrastruktura jako usługa (IaaS), Platforma jako usługa (PaaS) i Oprogramowanie jako usługa (SaaS). Zamiast standardowego przeglądu zwrócono uwagę no to, że modele tych usług są użyteczne tylko do ogólnego zrozumienia pojęć. W szczególności różnica między IaaS i PaaS jest coraz mniej wyraźna. Czy usługa systemu dostarczania treści (CDN, ang. Content Delivery Network) buforująca informacje w Internecie tak, aby były blisko użytkownika, jest usługą PaaS lub IaaS? To naprawdę nie ma znaczenia. Ważne jest, aby zrozumieć, co oferuje (i czego nie oferuje!) ta usługa, a nie czy pasuje do konkretnej kategorii.

Model współodpowiedzialności w chmurze

Najbardziej podstawowe pytanie z zakresu bezpieczeństwa, na które trzeba odpowiedzieć, brzmi: „Za jakie aspekty bezpieczeństwa jesteśmy odpowiedzialni?”. W środowiskach lokalnych odpowiedź jest często udzielana pośrednio. Dział programistyczny jest odpowiedzialny za błędy w kodzie, natomiast dział operacyjny IT jest odpowiedzialny za pozostałe komponenty. Wiele organizacji stosuje obecnie model DevOps, w którym obowiązki są dzielone, a granice dzielące zespoły programistyczne i operacyjne są rozmyte lub nie istnieją. Niezależnie jednak od sposobu organizacji praktycznie cała odpowiedzialność za bezpieczeństwo zlokalizowana jest w obrębie firmy.

Być może jedną z najbardziej niepokojących zmian podczas przechodzenia ze środowiska lokalnego do środowiska w chmurze jest bardziej skomplikowany model współodpowiedzialności za bezpieczeństwo. W środowisku lokalnym może to być wewnętrzny dokument porozumienia, umowy z działem IT lub innym działem, który zajmuje się utrzymaniem serwerów. Jednak w wielu przypadkach biznesowi użytkownicy IT są przyzwyczajeni do przekazywania wymagań lub kodu wewnętrznemu dostawcy, który jest odpowiedzialny za wdrożenie wszystkiego, szczególnie w dziedzinie bezpieczeństwa.

Nawet osoby działające od dłuższego czasu w środowisku chmury, mogą się zastanawiać, gdzie kończy się odpowiedzialność dostawcy chmury, a gdzie zaczyna się odpowiedzialność klienta. Ta linia rozgraniczająca różni się w zależności od rodzaju usługi w chmurze. Prawie wszyscy dostawcy usług w chmurze omawiają to w jakiś sposób w dokumentacji i materiałach szkoleniowych, ale najlepszym sposobem wyjaśnienie tego jest analogia do jedzenia pizzy.

Usługa Pizza-as-a-Service[3] odnosi się do chęci zjedzenia pizzy. Istnieje jednak wiele możliwości wyboru! Można po prostu zrobić pizzę w domu, chociaż potrzebne są wtedy różne składniki oraz trochę czasu. Można podbiec do sklepu spożywczego i kupić mrożoną pizzę – wymaga to wtedy tylko posiadania piekarnika i miejsca, w którym można ją zjeść. Można także zadzwonić do ulubionego dostawcy pizzy. Ewentualnie można po prostu usiąść w restauracji i zamówić pizzę. Wszystkie wymienione możliwości zostały umieszczone na schemacie składającym się z komponentów i osób za nie odpowiedzialnych, na rysunku 1.7.

Przypisy

1 Verizon Data Breach Investigations Report (https://vz.to/2LoBfyq) jest doskonałym darmowym zasobem do zrozumienia różnych rodzajów udanych ataków, posortowanych ze względu na rodzaj przemysłu i użyte metody, a jego streszczenie jest bardzo czytelne.

2 Autor poleca: Adam Shostack Threat Modeling: Designing for Security (Wiley).

3 Oryginalny pomysł z artykułu Alberta Barrona.