MENU
Nasze ceny
Przeczytaj fragment on-line
Bezpieczeństwo w chmurze - ebook
Bezpieczeństwo w chmurze - ebook
W związku z szybko zmieniającą się architekturą automatyzacji opartej na interfejsach API, platformy w chmurze stanęły wobec niespotykanych dotychczas wyzwań i możliwości w zakresie zapewnienia bezpieczeństwa. W niniejszej książce omówiono najlepsze praktyki dotyczące bezpieczeństwa środowisk w chmurze, udostępnianych przez różnych dostawców, niezależnie od tego czy planowane jest przeniesienie dotychczasowych projektów do chmury czy też zbudowanie nowej infrastruktury od podstaw.
Omówione techniki dotyczące zabezpieczania popularnych platform środowiska w chmurze, takich jak Amazon Web Services, Microsoft Azure i IBM Cloud, mogą być szczególnie przydatne dla programistów, architektów IT oraz specjalistów do spraw bezpieczeństwa. Sposoby kierowania zarządzaniem zasobami danych, zarządzaniem tożsamością i dostępem, zarządzaniem podatnością na zagrożenia, bezpieczeństwem w sieci oraz reagowaniem na incydenty w środowisku w chmurze zostały przedstawione przez Chris Dotson’a, doświadczonego pracownika technicznego IBM.
W książce omówiono:
• Jak standardowe zasady i pojęcia, takie jak najmniejsze przywileje i obrona w głąb, znajdują zastosowanie w środowisku w chmurze.
• Sposoby zarządzania dostawcami środowiska w chmurze, przechowującymi, przetwarzającymi dane lub zapewniającymi kontrolę administracyjną.
• Kluczową rolę, jaką odgrywa tożsamość i zarządzanie zasobami IAM (ang. Identity and Access Management) w chmurze.
• Sposoby zarządzania różnego rodzaju zagrożeniami.
| Kategoria: | Informatyka |
| Zabezpieczenie: |
Watermark
|
| ISBN: | 978-83-01-21121-9 |
| Rozmiar pliku: | 2,4 MB |
FRAGMENT 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¹, 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ć², 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³ 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.
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¹, 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ć², 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³ 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.
więcej..
