Bezpieczeństwo systemów IT z chmurą publiczną
Rozmawiając z przedstawicielami polskich przedsiębiorstw odpowiedzialnymi za obszar IT spotykam się często z obawami przed transformacją chmurową związanymi z bezpieczeństwem systemów. Jak można być pewnym, że wdrażając rozwiązania chmurowe, czy migrując istniejące do chmury, nie wystawimy swoich systemów na nowe zagrożenia i nie zwiększymy ryzyka uzyskania dostępu do tajemnic naszego przedsiębiorstwa przez osoby nieuprawnione do danych? Poniżej spróbuję odpowiedzieć na te pytania.
Czy chmura publiczna jest publiczna?
W organizacjach rozpoczynających swoją przygodę z rozwiązaniami chmurowymi już nawet słowo „publiczna” prowadzi do skojarzenia z publicznym dostępem do danych, podczas gdy wyrażenie „public cloud” nie odnosi się do poufności danych, a do dostępności usług chmurowych. Dopóki jawnie nie udostępnimy danych lub systemów wrzuconych do chmury, nikt poza nami nie będzie miał do nich dostępu. W odróżnieniu od chmur prywatnych, w całości budowanych na użytek jednego przedsiębiorstwa czy organizacji, z usług dostawców chmur publicznych może korzystać każdy – począwszy od użytkowników indywidualnych, przez małe i średnie firmy po duże korporacje i agencje rządowe. Dla wszystkich podmiotów, należących do każdej z tych kategorii, dostępne są na ogół te same usługi chmurowe, o tych samych możliwościach, parametrach, opcjach konfiguracyjnych.
Między innymi ze względu na powszechną dostępność usług, ich bezpieczeństwo jest najwyższym priorytetem dla wiodących dostawców chmurowych, zapewne nie tylko ze względu na dbałość o reputację, kluczową w zdobywaniu szybko rosnącego rynku usług chmurowych, ale także fakt, iż poważne naruszenia bezpieczeństwa danych dla dużych klientów chmur mogą przekładać się na wysokie straty finansowe oraz skutki prawne. Uwzględniając model działania dostawców chmur oparty o self-service i spójne rozwijanie jednej, dostępnej dla każdego platformy widać, iż z wysokich standardów bezpieczeństwa korzystają wszyscy użytkownicy.
Kto odpowiada za bezpieczeństwo chmury?
Ważnym aspektem jest zrozumienie na czym polega odpowiedzialność za bezpieczeństwo danych. Należy pamiętać, że dostawca chmury odpowiada za „bezpieczeństwo chmury”, czyli bezpieczeństwo lokalizacji fizycznych, redundancję, kontrolę dostępu do serwerów, bezpieczeństwo działania samych usług (np. aktualizacje serwerów baz danych działających u podstaw usług bazodanowych), czy separację pomiędzy klientami na poziomie wirtualizacji. Za bezpieczeństwo „w chmurze” jest odpowiedzialny jej użytkownik. To hasło oznacza, że bezpieczeństwo danych jest również uzależnione od konfiguracji usług chmurowych wykonanej przez użytkownika, który wykorzystując dostępne na wyciągnięcie ręki narzędzia, wiedzę i najlepsze praktyki od dostawcy i jego partnerów, sam decyduje o poziomie bezpieczeństwa odpowiednim dla jego biznesu. W tym wypadku bardzo pomocne są też dobrze dobrane wartości domyślne dla konfiguracji, które ograniczają ryzyko pomyłek (tzw. polityka deny all by default).
Amazon Web Services, pionier i lider w dziedzinie usług Infrastructure as a Service w opracowaniu Cloud Native Policy używa pojęcia modelu współdzielonej odpowiedzialności i przedstawia go następująco:
I tutaj decydują dwa kluczowe czynniki:
- Dojrzałość chmury – jakość zabezpieczeń, możliwości konfiguracyjne, dostępne narzędzia, stopień ich zaawansowania i elastyczność.
- Znajomość tych narzędzi oraz doświadczenie w budowaniu bezpiecznych systemów IT.
Oba są tak samo ważne i wymagające zaadresowania w podejmowaniu decyzji o wejściu w rozwiązania chmurowe.
Jak porównać bezpieczeństwo danych w chmurze i on-premises?
Kiedy podczas zbierania wymagań wdrożenia nowego systemu e-commerce słyszę „system powinien być uruchomiony w naszej serwerowni, bo tak będzie bezpieczniej”, zawsze zadaję pytanie „na jakich faktach opiera się to stwierdzenie?” Proponuję weryfikować poprawność tej tezy na własnym przykładzie i zestawić możliwości, jakie daje Amazon Web Services, z tym, co jest do uzyskania własnymi siłami. Podzielmy zagadnienie bezpieczeństwa na dwie grupy problemów:
Bezpieczeństwo fizyczne
Niewątpliwie globalna infrastruktura AWS jest unikalna zarówno ze względu na skalę, jak i sam koncept budowy regionów. Region składa się typowo z trzech tzw. Availability Zones, oddalonych od siebie na tyle daleko, by ograniczyć podatność na te same katastrofy naturalne, a jednocześnie na tyle blisko, żeby dało się zapewnić między nimi szybką synchronizację dużych ilości danych. Każda AZ to co najmniej jedno niezależne centrum danych. Taka architektura umożliwia przede wszystkim dostarczenie bardzo wysokiej odporności danych na „siłę wyższą”, czego skrajnym przykładem jest usługa S3, działająca od 2006 roku i zaprojektowana do zapewnienia trwałości danych na poziomie 99.999999999%.
Fakt, nie da się osobiście zobaczyć serwera, na którym przechowywane są dane, ale przecież nie jest też tak, że dane umieszczone w chmurze są w nieokreślonej przestrzeni, która może być udostępniona w niekontrolowany sposób przypadkowym użytkownikom. Nigdy bez wiedzy użytkownika chmury dane nie opuszczą wybranego regionu, zatem zawsze wiemy, w którym państwie i w jakiej jego części się znajdują. Owszem, zdarza mi się spotkać decydentów, dla których uznane powszechnie certyfikacje nie są wystarczającym potwierdzeniem działania chmury w zgodzie z wysokimi standardami i że nie ma gdzieś pod spodem „drugiego dna”. Takie osoby najwyraźniej mają większe zaufanie do „lokalnego informatyka”, niż systemu standaryzacji i audytów. Co ciekawe, takie myślenie często idzie w parze z obawą przed vendor lock-in wobec dostawcy chmurowego, przy jednoczesnym uzależnieniu od co raz wyżej wycenianych i co raz trudniej dostępnych na rynku kompetencji specjalistów odpowiedzialnych za infrastrukturę i systemy on-premises. Jest to naturalna obawa przed czymś co odległe i nienamacalne, ale czy jest to obawa uzasadniona?
Bezpieczeństwo sieciowe
Na bazie projektów, z którymi miałem styczność, mogę powiedzieć, że z reguły działy IT albo robią wszystko, co możliwe, żeby jak najdłużej chronić swoją sieć i systemy przed kontaktem ze światem zewnętrznym, albo pod presją nowych wymagań biznesowych wystawiają na świat systemy bez odpowiedniego do ich potrzeb, czy nawet komfortu psychicznego zespołu, poziomu zabezpieczeń. I jedno, i drugie podejście jest całkowicie zrozumiałe, jeżeli wziąć pod uwagę jednorazowy koszt wdrożenia firewalla w on-premise przy braku pewności, czy nie strzelamy z armaty do wróbla. Ach, zapomniałbym o jeszcze jednym wzorcu postępowania: wdrażamy drogi firewall, ale potem nie wystarcza energii i środków na utrzymanie jego poziomu bezpieczeństwa z dnia wdrożenia.
Co w tym zakresie możemy mieć w chmurze? Po kolei:
- Konsola (Webapp) – pierwszy punkt kontaktu z chmurą, dostęp tylko po transmisji szyfrowanej, a jeśli nie pominiemy rekomendacji pojawiających się w konsoli, to także z dwuetapową autoryzacją.
- Prosty firewall – domyślnie dostajemy prywatny segment sieci, do którego nie dostanie się nikt, komu nie zezwolimy (np. na postawie adresu IP i portu).
- Połączenie VPN – jeśli potrzebujemy większej integracji wewnętrznej sieci z segmentem chmurowym (i np. mniej restrykcyjnych polityk filtrowania dla użytkowników z wewnątrz sieci firmowej)
- Ochrona przed atakami DDoS – wszyscy użytkownicy AWS-a korzystają z podstawowej ochrony DDoS, dostarczanej przez usługę AWS Shield w wersji Standard dostępną w cenie dla usług takich jak Elastic Load Balancer czy Amazon CloudFront, zatem już tylko przez uruchomienie aplikacji z wykorzystaniem loadbalancera czy podłączenie CDN-a uzyskujemy bez dodatkowych kosztów ochronę przez atakami takimi jak SynFlood (zobacz jak szybko udało nam się uruchomić CDN dla jednego znaszych klientów); dla bardziej wymagających użytkowników AWS Shield Advanced dostarcza narzędzi do ochrony innych usług
- Web Application Firewall – dodatkowa ochrona aplikacji przed exploit-ami, skanowaniem z możliwością konfigurowania własnych reguł, przy koszcie proporcjonalnym do intensywności używania
Jeżeli dodamy do tego dostępne narzędzia do szczegółowej kontroli dostępu do naszych danych i aplikacji (AWS CloudTrail), nieosiągalny na własnych zasobach koszt długoterminowego przechowywania danych (Amazon S3 Glacier to koszt poniżej dwóch groszy za gigabajt miesięcznie), to trudno oprzeć się wrażeniu, że w chmurze AWS mamy do dyspozycji pełen zestaw narzędzi do zapewnienia bezpieczeństwa naszym systemom. Pozostaje zadać sobie pytanie…
…jak zadbać o bezpieczeństwo w chmurze?
Na początku najlepiej znaleźć partnera , który pomoże w realizacji pierwszych projektów i zbudowaniu kompetencji w organizacji. Zasadniczo AWS nie realizuje projektów samodzielnie, zamiast tego wspiera sieć partnerów specjalizujących się w określonej branży, rodzaju rozwiązań czy technologii. Część narzędzi wsparcia jest dostępna także dla użytkowników końcowych, przykładowo:
- Szkolenia i certyfikacje
- AWS Well-Architected Tool, czyli zestaw najlepszych aktualnych praktyk z zakresu budowania systemów w AWS (adresujących m.in. bezpieczeństwo)
- AWS Trusted Advisor – narzędzie generujące rekomendacje zmian na podstawie porównania naszej konfiguracji chmury z zaleceniami
Podsumowanie
Osobiście nie mam wątpliwości, że obawy o bezpieczeństwo danych czy systemów w chmurze wynikają głównie z niskiej świadomości. Podchodząc do tematu „po inżyniersku”: nie ma powodów sądzić, że chmura z definicji jest mniej lub bardziej bezpieczna, a zarazem widać, że ułatwia dostęp do narzędzi i praktyk pozwalających na budowę systemów nie mniej bezpiecznych niż rozwiązania w on-premise. Dobra chmura dostarcza usługi wysoko wystandaryzowane, zbudowane na bazie wieloletnich doświadczeń dostawcy, gdzie każda usługa rozwijana jest przez grupę bardzo wąsko wyspecjalizowanych ekspertów. Taki poziom kompetencji i operational excellence jest poza zasięgiem zdecydowanej większości organizacji.
Jeżeli chcesz dowiedzieć się więcej na temat możliwości bezpiecznego wykorzystania chmury w Twoich systemach – zapraszamy do kontaktu.
