Jak bezpiecznie przenieść się do chmury – początek wielkiego cyklu materiałów

O chmurze każdy słyszał, ale nie każdy wie, jak ocenić jej przydatność i bezpieczeństwo. W całorocznym cyklu artykułów i webinarów spróbujemy pomóc Wam w lepszym zdefiniowaniu i zrozumieniu problemu oraz podjęciu mądrych decyzji.

Wspólnie z Aruba Cloud rozpoczynamy dzisiaj cykl artykułów poświęconych kwestiom technologii chmurowych. W ten ciekawy i nie do końca wszystkim dobrze znany świat zabierze nas Marcin Fronczak, ekspert z bogatym doświadczeniem, prezes Cloud Security Alliance Polska. Dzisiaj możecie przeczytać wstęp, plan artykułów i webinarów oraz pierwszy wpis poświęcony architekturze cloud computing. Oddajemy głos Marcinowi.

Wprowadzenie

Pomimo znacznego rozwoju rynku cloud computing i przełamywania kolejnych barier i wątpliwości wśród konsumentów, polskie firmy i instytucje wciąż zachowują dystans wobec chmury obliczeniowej pomimo, że dostrzegają wiele korzyści, które wnosi ta technologia. W ostatnich badaniach  respondenci wskazują na te same obawy utrudniające adaptację chmury jak w 2011 roku kiedy szum medialny wokół modelu cloud computing był największy: ogólne ryzyka związane z bezpieczeństwem, integracja z istniejącymi środowiskami IT, ryzyka związane z utratą i wyciekiem danych, spełnienie wymagań regulatora i ustawodawcy, utrata kontroli, złożoność zarządzania, potencjalne komplikacje w zarządzaniu, wewnętrzny opór i inercja, vendor-lock. Z drugiej strony dostrzegają wiele korzyści z wdrożenia chmury jak elastyczność i skalowalność zasobów, poprawa dostępności i ciągłości biznesu, redukcja kosztów i złożoności, spełnienie wymogów regulacyjnych, przesunięcie wydatków na IT z modelu CAPEX (inwestycje) na rzecz OPEX (utrzymanie), przyspieszenie procesów dostarczania zasobów oraz wdrożeń, zwiększona zwinność, poprawa jakości przetwarzania danych, poprawa bezpieczeństwa. Jak widać sprzeczność leży w naszej naturze. Ja sam zachowuję dość ostrożne podejście do modelu cloud computing jednocześnie zdając sobie sprawę, że wejście w chmurę to dzisiaj już nie kwestia „czy” tylko „kiedy”. Firmy powinni w świadomy i bezpieczny sposób budować swoją strategię migracji do chmury i następnie ją realizować przy pomocy sprawdzonych praktyk i standardów. Każda taka strategia powinna być dopasowana do konkretnego przypadku i specyfiki biznesu, zaś dokładna analiza pomoże uzyskać odpowiedź na pytania: kiedy i jakimi rozwiązaniami wchodzić w chmurę, jakie są korzyści vs zagrożenia oraz jakie wydatki będzie trzeba ponieść na dostosowanie usługi do wymagań interesariuszy (m.in. kwestie prawne i bezpieczeństwa).

W planowanym cyklu artykułów i webinarów chciałbym przedstawić sposób jak bezpiecznie przenieś biznes do chmury w oparciu o podejście i praktyki wypracowane przez grupy robocze działające w ramach Cloud Security Alliance:

Sekcja nr 1 – Wprowadzenie do architektury cloud computing i zarządzania ryzykiem w chmurze

• Architektura cloud computing zgodna z definicją NIST SP 800-145 – cechy, warstwy, modele, komponenty – artykuł nr 1 – styczeń
• Zarządzanie ryzykiem – wprowadzenie do zarządzania ryzykiem, ryzyka specyficzne dla chmury, odpowiedzialność za zabezpieczanie poszczególnych komponentów i warstw w zależności od modelu i lokalizacji usługi. – webinar nr 1 – luty

Sekcja nr 2 – Zarządzanie zgodnością i audyt bezpieczeństwa w chmurze

• Zarządzanie zgodnością w modelu cloud computing – artykuł nr 2 – luty
• Audyt i testy bezpieczeństwa w chmurze – co możemy zrobić sami, a jakich informacji należy wymagać od dostawcy – artykuł nr 3 – marzec
• GDPR (RODO) w chmurze- webinar nr 2 – kwiecień

Sekcja nr 3 – Zarządzanie dostępem i tożsamością w chmurze

• Cykl zarządzanie tożsamością oraz porównanie standardów (SAML, XAMCL, SCIM, OAuth i inne) – artykuł nr 4 – kwiecień
• Kontrola dostępu w chmurze – praktyki i rozwiązania – artykuł nr 5 – maj

Sekcja nr 4 – Zarządzanie incydentami i ciągłością działania

• Proces zarządzania incydentami w modelu cloud computing – Webinar nr 3 – czerwiec
• BCP/DR – „tradycyjne” i w chmurze – artykuł nr 6 – czerwiec

Sekcja nr 5 – Bezpieczeństwo infrastruktury

• Bezpieczeństwo fizyczne i środowiskowe – Ochrona i izolacja sieci – artykuł nr 7 – lipiec
• Bezpieczeństwo środowiska wirtualnego – artykuł nr 8 – sierpień

Sekcja nr 6 – Bezpieczeństwo danych

• Zarządzanie cyklem życia bezpieczeństwa danych (Datasecurity lifecycle) – webinar nr 4 – wrzesień
• Szyfrowanie danych w locie i w spoczynku – artykuł nr 9 – wrzesień

Sekcja nr 7 – Bezpieczeństwo aplikacji

• Przenaszalność i interoperacyjność – artykuł nr 10 – październik
• Software Development Lifecycle – artykuł nr 11 – listopad

Sekcja nr 8 – Zarządzanie relacjami z dostawcą – webinar nr 5 – październik

• Jak wybrać dostawcę – na co zwracać przy wyborze partnera
• Omówienie praktyk i narzędzi do oceny dostawcy i usługi chmurowej dostarczanych przez CSA

Sekcja nr 9 – Security as a Service (Secaas) – Artykuł nr 12 – grudzień

• Przegląd usług bezpieczeństwa w modelu cloud computing
• Czy to jest bezpieczne i czy się opłaca?

Sekcja nr 10 – Podsumowanie – wchodzimy w chmury czyli proces migracji krok po kroku – webinar nr 6 – grudzień

Czasem zatem na pierwszy artykuł.

Architektura cloud computing zgodna z definicją NIST SP 800-145 – cechy, warstwy, modele, komponenty

Wirtualizacja vs. Chmura

Punktem zerowym na drodze do poznawania chmury jest zrozumienie pojęcia wirtualizacji. Używanie naprzemiennie pojęć „chmura” i „wirtualizacja” jest dość powszechne. To nie są synonimy! Wirtualizacja jest platformą dla większości chmur  i odwrotnie, chmury (IaaS) stanowią platformę dla wirtualizacji. Żeby lepiej wyjaśnić zamieszanie powstałe wokół chmury i wirtualizacji należy zrozumieć jak usługi w chmurze i wirtualizacji oddziałują na siebie wzajemnie. W szumie medialnym i marketingowym, pojęcia te są używane równoznacznie co oczywiście jest błędem. Spróbujmy zatem zdefiniować pojęcia wirtualizacji i chmury i znaleźć różnice i relacje pomiędzy nimi. Według Wikipedii „ Wirtualizacja umożliwia efektywniejsze wykorzystanie istniejących zasobów sprzętowych środowiska informatycznego poprzez dowolne (w ramach możliwości sprzętowych czy programowych oraz założeń projektowych) modyfikowanie cech wirtualizowanych zasobów, dostosowując je do wymagań użytkownika.” W kontekście chmury obliczeniowej, wirtualizacja to możliwość uruchomienia kilku różnych systemów operacyjnych, na kilku odrębnych maszynach wirtualnych, które działają na jednej lub wielu maszynach fizycznych. Oznacza to, że wirtualizacja pozwala na podział zasobów fizycznych, przydzielenie ich do maszyn wirtualnych oraz taką emulację, że system operacyjny ma wrażenie działania na fizycznym sprzęcie. Oczywiste korzyści płynące z wirtualizacji to oszczędności – zamiast pięciu różnych maszyn, możemy uruchomić jedną i tak rozdzielić jej zasoby, aby pomieściło się na niej pięć zwirtualizowanych środowisk, każde ze swoim systemem operacyjnym. Takie rozwiązanie pozwala na bardziej wydajne używanie zasobów, ale z drugiej strony wprowadza jedną z największych zalet dla całej chmury obliczeniowej: uniezależnia środowisko uruchomieniowe od konkretnej maszyny fizycznej. To wprost prowadzi do sytuacji, w której awaria sprzętowa nie musi już wpływać na awarię systemu operacyjnego czy samej maszyny wirtualnej. W razie uszkodzenia sprzętowego zasoby mogą być bardzo łatwo i nawet bez widoczności dla klienta przeniesione do innego zasobu fizycznego, zachowując ciągłość pracy. Finalnie, zwirtualizowanie środowiska uruchomieniowego pozwala na pełną elastyczność w sposobie jego definiowania oraz skalowania. Teraz, żeby dołożyć do maszyny pamięci RAM, możemy się zalogować do panelu zarządzania i zmienić klasę maszyny. Wcześniej musieliśmy udać się ze śrubokrętem do serwerowni. Wirtualizacja jest platformą dla większości chmur. Oznacza to, że model przetwarzania w chmurze nie byłby możliwy bez zdolności wirtualizacji zasobów  wykorzystywanych do świadczenia usług (sieciowych, systemów operacyjnych, przestrzeni dyskowej itd.). Chociaż dla końcowego użytkownika jest to transparentne, każdy dostawca chmury wykorzystuje do maksimum technologię wirtualizacji na każdym poziomie architektury, aby dostarczyć skalowalność i elastyczność wymaganą do osiągnięcia efektu skali. Z drugiej strony, chmura jest również wykorzystywana przez większość klientów jako platforma do wirtualizacji. Oznacza to, że najprostszym sposobem na wykorzystanie potencjału wirtualizacji jest skorzystanie z usług w modelu chmury. Użytkownik nie potrzebuje tworzyć własnego środowiska do wirtualizacji i na nim uruchamiać hypervisorów, instalować systemy operacyjne, organizować przestrzeń dyskową dostępną przez specyficzne API czy wykorzystywać moc obliczeniową dla kluczowych aplikacji. Wszystkie te możliwości mogą być udostępnione w modelu chmury. Zatem, chmura nie tylko w ogromnym stopniu wykorzystuje technologię wirtualizacji, ale także umożliwia klientom prosty sposób na pełne wykorzystanie jej potencjału bez potrzeby wirtualizacji istniejącej architektury. Brzmi to trochę jak masło maślane, ale głównym przesłaniem jest to, że pojęcia chmury i wirtualizacji są ściśle ze sobą powiązane, ale nie oznaczają tego samego.

Architektura chmury wg NIST

Jak zatem zdefiniować pojęcie cloud computing? Cloud Security Alliance posługuje się modelem chmury prezentowanym przez National Institute Standard and Technology w publikacji SP 800-145.  Jest on pewnym uproszczeniem, ale w celu uspójnienia nomenklatury i definicji będę korzystał z tego podejścia w całym cyklu.

Rys. nr 1 – model chmury wg NIST – źródło: Cloud Security Alliance

W tym modelu chmura charakteryzuje się 5 istotnymi cechami:

Oferowane są pule zasobów w postaci mocy obliczeniowej, ilości pamięci, przestrzeni składowej

Szeroki dostęp sieciowy – Usługi chmurowe mogą znajdować w różnych lokalizacjach geograficznych i powinny zapewniać dostęp do nich każdemu urządzeniu z dostępem do sieci.

Błyskawiczna elastyczność i skalowalność oznaczająca możliwość dynamicznego zwiększania i zmniejszania zasobów adekwatnie do potrzeb.  Jest to główna cecha odróżniająca model cloud o tradycyjnego hostingu. W tym drugim użytkownik nie może dodać 100 serwerów w ciągu jednej godziny lub doby, a dwa dni później ich skasować i zapłacić jedynie za te zasoby, z których faktycznie skorzystał.

Mierzalność usług – ta cecha oznacza, że wykorzystanie usług może być mierzone i naliczane zgodnie z ich wykorzystaniem. Dla przykładu jeśli korzystasz z Gmaila i przekroczysz darmową pojemność konta płacisz za ilość danych „skonsumowanych” w ramach skrzynki pocztowej. W przypadku korzystania z Microsoft Azure płacisz za ilość przestrzeni dyskowej i mocy obliczeniowej, którą wykorzystasz.  Jak ta cecha odróżnia chmurę od wirtualizacji? Przykładowo, jeśli korzystasz z VMware ESXi nie będziesz miał możliwości żeby różnym jednostkom organizacyjnym naliczyć opłaty zgodnie z wykorzystaniem przez nie mocy obliczeniowej. Aby to zrobić konieczne będzie dodanie warstwy, która nada tradycyjnemu środowisku cech chmury np. vCloud,  Citrix Cloud  lub HP Orchestrator.

Samoobsługa na żądanie oznaczająca możliwość skorzystania z usług bez potrzeby kontaktu z dostawcą. Użytkownik sam może dokonywać zmian w swoich usługach i dodawać potrzebne zasoby.

Usługi są dzielone wg rodzaju (Oprogramowanie, Platforma, infrastruktura jako usługa) oraz sposobu rozmieszczenia (Publiczna, Prywatna, Hybrydowa, Współdzielona).

Standard NIST określa model chmury ze względu na rodzaj świadczonej usługi mianem stosu SPI – Software, Platform, Infrastructure as a service. Model ten w uproszczony sposób pozwala zilustrować jakie elementy usługi są dostarczane przez dostawcę (poniżej czerwonej linii na rysunku nr 2), a jakie są instalowane przez odbiorcę. Ma to istotne znaczenie w zrozumieniu jakie ryzyka są związane z poszczególnymi modelami oraz pomaga określić kto jest odpowiedzialny za minimalizację tych ryzyk i zastosowanie odpowiednich zabezpieczeń.

Rys. nr 2 – Stos SPI

W modelu infrastruktura jako usługa (komponenty stosu w kolorze zielonym) dostawca dostarcza nam moc obliczeniową, przestrzeń do składowania danych, połączenia komunikacyjne. Najczęściej wykorzystując w tym celu technologię wirtualizacji. Jedyne czym się przejmujemy to instalacja systemu operacyjnego, usługi, aplikacji oraz korzystanie z usługi za pomocą odpowiadającego nam interfejsu. Przykładem takiej usługi jest EC2 Amazon.  W tym modelu dostawca odpowiada za zapewnienie dostępności i zabezpieczenie infrastruktury (fizyczny dostęp, kamery, czytniki) sieci, serwerów, hypervisorów (zarzadzanie dostępem, zarządzanie zmianą itd.) Wszystko to co musieliśmy robić sami , gdy centrum danych znajdowało się pod kontrolą naszej organizacji. Wszystkie elementy, które umieścimy na warstwie dostarczonej przez dostawcę czyli systemy operacyjne, aplikacje, bazy danych, usługi, interfejs oraz same dane musimy zabezpieczyć we własnym zakresie.

Dobrym przykładem PaaS czyli usługi w postaci platformy (kolor błękitny komponentów) jest Microsoft Azure. Dostawca dostarcza dodatkowo system operacyjny, bazę danych oraz narzędzia do tworzenia aplikacji. W tym modelu odbiorca usługi jest bezpośrednio odpowiedzialny za zabezpieczenie aplikacji oraz interfejsu.

Korzystając z SaaS – oprogramowania jako usługi otrzymujemy wszystkie komponenty stosu (kolor granatowy).  Jedyne co musimy zapewnić i zabezpieczyć to interfejs dzięki któremu korzystamy z usług. W zasadzie większość usług chmurowych jest dostarczana w tym modelu. Jest on powszechnie stosowany nawet bez świadomości, że jest to model SaaS. Dobrymi przykładami są Gmail, Dropbox, Salesforce, GoToMeeting.

Zrozumienie koncepcji stosu SPI pozwala lepiej zrozumieć kto jest odpowiedzialny za bezpieczeństwo poszczególnych komponentów. Im niżej stosu, tym większa odpowiedzialność za zabezpieczenie odpowiednich elementów spoczywa na dostawcy usługi. Należy pamiętać, że wobec regulatorów to my będziemy rozliczani za spełnienie wymogów dotyczących ochrony informacji. Dokładnie przedstawię to podczas kolejnych artykułów i webinarów.

Kolejnym z elementów definiującym chmurę jest rozróżnienie modelu usługi ze względu na jej rozmieszczenie. I tu zaczyna się zabawa, bo i poszczególne modele mogą być w różny sposób zorganizowane.

Rys. nr 3 – modele ze względu na rozmieszczenie usługi

Najprostsza do wyjaśnienia jest usługa dostarczona w modelu publicznym. Infrastruktura jest własnością dostawcy i to on dostarcza nam ją w formie usługi z zewnątrz. Korzystając z niej nie mamy wpływu kto jest naszym sąsiadem i korzysta z tego samego środowiska. Może to być ktoś nieszkodliwy, ale może to być również konkurencja albo przestępca. Z tego względu stronę, która ma dostęp i wykorzystuje środowisko, na którym jest świadczona usługa – nazywamy stroną niezaufaną.  Przykładami usług w modelu chmury publicznej są usługi dostarczane przez Amazon (AWS), Microsoft (Azure), Google i Aruba (Public Cloud). Zestaw LAMP Linux (Linux, Apache, MySQL I PHP) zainstalowany na Amazon’s AWS EC2 może być zaklasyfikowany jako chmura publiczna umieszczona poza organizacją (off-premise), dostępna przez niezaufaną stronę, zarządzana przez dostawcę w warstwie infrastruktury (IaaS) nawet jeśli poszczególne aplikacji i usługi w ramach zestawu LAMP będą zarządzane przez usługobiorcę.

W modelu chmury prywatnej lub współdzielonej kwestie posiadania, zarządzania, umieszczenia i dostępu do infrastruktury wyglądają zupełnie inaczej. Celem jest przede wszystkim ograniczenie dostępu do środowiska do jednego lub wielu zaufanych podmiotów zwanych zaufaną stroną. Może to być dostęp w obrębie jednej organizacji (chmura prywatna) lub wielu, które potrzebują skorzystać ze wspólnych zasobów informacyjnych (współdzielona) np. w ramach grupy kapitałowej, partnerstwa biznesowego, jednego sektora (np. administracja publiczna, placówki medyczne, uczelnie). W modelu tym infrastruktura może w być w posiadaniu i zarządzaniu przez organizację lub dostawcę i umieszczona wewnątrz i na zewnątrz organizacji. Możliwe warianty są przedstawione na rys. nr 3. Jako przykład  chmury współdzielonej (w uproszczonej formie) podam firmę AXA Technology Services. Jest to spółka w całości w posiadaniu grupy AXA, utworzona w celu świadczenia wspólnych usług informatycznych wykorzystując efekt skali (157,000 pracowników, 56 krajów, ponad 102 miliony klientów). W kilkunastu centrach danych, do których dostęp mają podmioty z grupy AXA (zaufana strona) są dostarczane usługi w formie poszczególnych komponentów stosu SPI (infrastruktura, platforma, oprogramowanie). Dodatkowo w ramach chmury współdzielonej są tworzone chmury prywatne dla poszczególnych podmiotów z grupy.  W przypadku, gdy podmioty te potrzebują jakiś specyficznych lub doraźnych rozwiązań mogą wykorzystywać usługi w modelu chmury publicznej. Kiedy są one połączone z usługami w chmurze prywatnej/współdzielonej możemy mówić o modelu hybrydowym.

Model cloud computing jest dość skomplikowanym rodzajem usługi outsourcingowej w obszarze technologii informatycznych. Tak jak w tradycyjnym outsourcingu polega na przekazywaniu pewnych funkcji i procesów do realizacji przez dostawcę zewnętrznego. Decydując się na podjęcie współpracy z wybranym usługodawcą należy bardzo starannie i dokładnie sprawdzić czy może on zapewnić działania na najwyższym poziomie. Zrozumienie rozróżnienia chmury ze względu na rodzaj usługi (stos SPI) oraz jej rozmieszczenie (publiczna, prywatna, współdzielona, hybrydowa) jest podstawą do zrozumienia kto (klient czy dostawca) i na jakiej warstwie usługi jest odpowiedzialny za zapewnienie jej funkcjonowania i wdrożenie odpowiednich zabezpieczeń.

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