Za nami czwarta sesja strategiczna programu Cloud Excellence, całorocznego projektu realizowanego przez CIONET Polska we współpracy z partnerami: Dell Technologies, VMware, PwC, AWS, HPE i Red Hatem. Tym razem tematyka spotkania dotyczyła szeroko pojętego bezpieczeństwa chmury.

CIONET Cloud Excellence to program służący szerzeniu wiedzy i dobrych praktyk w zakresie stosowania technologii chmurowych. W drodze cyklicznie organizowanych spotkań – sesji strategicznych oraz warsztatów online – z udziałem zaproszonych prelegentów i przedstawicieli społeczności CIONET chcemy budować w organizacjach świadomość szans i wyzwań, jakie wiążą się z wdrażaniem rozwiązań cloud.

Program został zainaugurowany w czerwcu 2022 r. sesją “Road2Cloud”, po której nastąpiły jeszcze trzy podobne spotkania. Ostatnie z nich odbyło się na początku marca br. Plan na rok 2023 przewiduje jeszcze trzy sesje strategiczne: na temat środowisk wielochmurowych, ESG i sustainability oraz architektury aplikacji natywnych.

Z prezentacjami wystąpili Michał Karski, dyrektor programowy Cloud Excellence; Jakub Teska, dyrektor ds. architektury i usług cyberbezpieczeństwa oraz Tomasz Krupnik, manager ds. architektury cyberbezpieczeństwa, reprezentujący PKO Bank Polski; Paweł Westfalewicz, dyrektor Departamentu Architektury w PGE Systemy oraz Marcin Safranow, IT & Security Director, Huuuge Games. Grono prelegentów uzupełnili Paweł Kosmólski, Software Delivery Director i Kryspin Sławek, dyrektor ds. utrzymania systemów IT – obaj z PZU (nieprzypadkowo: spotkanie zostało zorganizowane w nowej siedzibie PZU, niedawno otwartym biurowcu Generation Park Y, który należy do najbardziej ekologicznych w Warszawie).

Wspólnym mianownikiem wszystkich wystąpień było zaś bezpieczeństwo chmury.

W poszukiwaniu odpowiedzialności

Pytanie, czym właściwie jest bezpieczeństwo chmurowe? Odpowiedzi na nie starał się udzielić Michał Karski, dyrektor programowy Cloud Excellence. Bo nawet jeżeli sama definicja wydaje się klarowna – chodzi o zestaw procedur, narzędzi i technologii zaprojektowany tak, by zaadresować zewnętrzne i wewnętrzne zagrożenia dla bezpieczeństwa biznesu – to gdy przychodzi do praktycznej implementacji, mogą pojawiać się mniejsze lub większe wątpliwości.

Należy do nich m.in. podział odpowiedzialności. Czym się różni cloud security od data center security? Na poziomie polityk bezpieczeństwa czy roadmap – niczym. Diabeł tkwi w praktyce implementacji. Dostawca, rzecz jasna, bierze na siebie jej część związaną z bezpieczeństwem dostarczanej infrastruktury ale klient nie może zapominać, że to na nim ciąży obowiązek poprawnej konfiguracji i użytkowania dostarczonych mu rozwiązań.

Za dużym, hiperskalowym usługodawcą, stoją duże budżety, wieloosobowe zespoły specjalistów i reputacja poważnej marki o globalnym zasięgu. „Okazuje się, że to złudzenie bezpieczeństwa bardzo często powoduje obniżenie naszej uwagi, co kończy się bolesną lekcją” – przestrzegał Karski. Wszystkim trzem dużym dostawcom chmury, czyli Microsoftowi, Amazon Web Services i Google’owi – przytrafiły się bowiem głośne ataki czy incydenty bezpieczeństwa.

Dla zobrazowania problemu Karski użył celnej analogii motoryzacyjnej. Kierowca w samochodzie autonomicznym nie może polegać wyłącznie na technologii pokładowej, jakkolwiek zaawansowane te systemy by nie były. To on jest w pierwszej kolejności jest odpowiedzialny za bezpieczeństwo, a technologia może zaalarmować lub w inny sposób pomóc, np. w trakcie wykonywania potencjalnie niebezpiecznego manewru.

Podobnie z chmurą – za jej bezpieczeństwo odpowiedzialny jest klient. I to nie tylko dział bezpieczeństwa – jego rolą jest opracowanie i egzekwowanie procedur stosowania narzędzi chmurowych tak by były bezpieczne, zgodne z polityką bezpieczeństwa czy regulacjami. „Nasz łańcuch będzie tak silny jak najsłabsze ogniwo, czyli każdy pojedynczy pracownik” – podkreślał Michał Karski.

Zdaniem dyrektora programowego Cloud Excellence z bezpieczeństwem chmurowym jest trochę tak jak z budowaniem efektywności kosztowej. Każdy użytkownik rozwiązania musi mieć świadomość, które elementy i w jaki sposób generują koszty. Bez tej wiedzy żadna optymalizacja nie będzie całkowicie skuteczna.

Budując jakiekolwiek rozwiązanie chmurowe każdy pracownik musi być świadom wszelkich kwestii z nim związanych i wynikających z tego implikacji. Dostawca zarzuci nas całą masą fantastycznych rozwiązań, które będą monitorowały, testowały, skanowały, wskazywały miejsca potencjalnych podatności czy błędów konfiguracyjnych. Ale czy to rozwiąże każdy problem? Nie – ocenił prelegent.

Droga do chmury

Ze słów Michała Karskiego wynika, że najgorsze, co możemy zrobić będąc świadczeniobiorcą chmury, to wygodnie rozsiąść się w fotelu klienta i popaść w iluzję bezpieczeństwa zapewnianego przez firmę zewnętrzną. W końcu jednak musi nastąpić swego rodzaju „odcięcie” – uznanie, że nie ma się kontroli nad całym środowiskiem IT. W tym kontekście usługa chmurowa to relacja zaufania między klientem a dostawcą – przekonywali Jakub Teska i Tomasz Krupnik z PKO Banku Polskiego.

Firmom takim, jak PKO czy PZU, a więc działającym w sektorze regulowanym, decyzję o wejściu na drogę do chmury z pewnością ułatwił komunikat Urzędu Komisji Nadzoru Finansowego z 2019 r., który zliberalizował wymogi związane ze stosowaniem rozwiązań cloud w podmiotach nadzorowanych, a przy tym uszczegóławiał je. Gdy rok później wiele organizacji z powodu pandemii COVID-19 stanęło w obliczu konieczności zachowania ciągłości działania i przestawienia się na nowy model operacyjny, transformacja chmurowa stała się trendem powszechnym.

Przykładowo, w PZU już na etapie implementacji oprogramowania do pracy biurowej Office 365 trzeba było zmierzyć się z takimi kwestiami, jak zakres danych, które mogą być przetwarzane w chmurze. „Oczywiste było też wdrożenie mechanizmów bezpieczeństwa, które pozwoliłyby na bieżące analizowanie ruchu i danych przekazywanych na zewnątrz” – wspominał Kryspin Sławek.

„Dla każdego ‘bezpiecznika’ jeszcze kilka lat temu chmura była trudnym tematem, bo mam wrażenie, że nasza świadomość, jakie mechanizmy w chmurze można zaimplementować, nie była pełna” – mówił Jakub Teska. Aż nadszedł rok 2020, w którym bank PKO uruchomił formalnie program transformacji chmurowej „Road-to-cloud”. „Od startu programu w 2020 r. mam przekonanie, że nasza perspektywa do tego, jak zabezpieczać chmurę i w jaki sposób do tego podchodzić i na co zwracać uwagę, całkowicie się zmieniła” – dodał.

Przede wszystkim, organizacja – nastawiając się na użycie więcej niż jednego środowiska chmurowego – postanowiła zmaksymalizować możliwości inspekcji i kontroli ruchu (to kluczowe z perspektywy bezpieczeństwa danych klientów). Zbudowano mechanizmy bezpieczeństwa wspólne dla wszystkich połączonych elementów chmurowych. Utworzona została specjalna strefa sieciowa, która pozwoliła na wdrożenie mechanizmów niezależnych od dostawcy chmurowego, zawierająca też bezpieczne, dedykowane połączenia do środowisk dostawców chmurowych PKO.

Dobre praktyki

Przygotowując się do transformacji chmurowej warto opracować zestaw reguł i polityk, mających ułatwić zarządzanie zmodernizowaną infrastrukturą oraz przechowywanymi w niej danymi klientów.

„Idąc do chmury należy uważać, by w nowym środowisku nie odtwarzać starych problemów” – przestrzegał Tomasz Krupnik PKO. Szczególnie starannie trzeba podchodzić do konfiguracji usług chmurowych, bo największym zagrożeniem dla chmury nie jest atak, ale błąd w konfiguracji. Nie są to przestrogi bez pokrycia. Jak wynika z szacunków firmy analitycznej Gartner (na które w swojej prezentacji powoływał się później Marcin Safranow) do końca 2025 r. przyczyną ponad 99 proc. wszystkich incydentów bezpieczeństwa w chmurze będzie błąd lub niewłaściwa konfiguracja.

Elastyczny dostęp do aplikacji i możliwość dynamicznego powoływania nowych aplikacji usług to jedno, ale z drugiej strony nawet najprostszy błąd w tym zakresie może spowodować poważny incydent. Z drugiej strony, aplikacje i usługi należy projektować z założeniem, że kiedyś w końcu dojdzie do niechcianego zdarzenia. Dlatego też należy jak najczęściej i jak najwięcej testować.

Uczestnicy Cloud Excellence #4 rekomendowali też utworzenie katalogu ustandaryzowanych usług (modułów), stosowanych do tworzenia aplikacji. Jeżeli, przykładowo, w wyniku zamówienia biznesowego na nową aplikację zawiera ona elementy spoza tego katalogu, muszą one przejść całą ścieżkę przeglądu i dopuszczenia do wdrożenia. W PKO Banku Polskim wszystko jest powoływane kodem:

Mamy automatyczne środowiska, strumienie CI/CD, jedno środowisko testowe (w którym nie mogą znaleźć się dane bankowe). Zanim powołamy nowe środowisko, sprawdzimy, czy zostało zbudowane we właściwy sposób. Gdy w strumieniu CI/CD pojawia się informacja o błędzie, powoływanie jest przerywane. Dzięki temu unikamy błędów w konfiguracji przed powołaniem infrastruktury. Powołujemy zawsze środowiska z gotowych dopuszczonych modułów i nikt nie może napisać własnego kodu – od tego są architekci cloudowi – podkreślił Tomasz Krupnik.

Walory infrastruktury jako kodu podkreślił też w trakcie swojego wystąpienia Paweł Westfalewicz. Developerzy, aby móc w pełni wykorzystywać korzyści oferowane przez chmurę, powinni mieć przecież możliwość dynamicznego wprowadzania zmian w tym środowisku. Dlatego, z punktu widzenia zespołów programistycznych, IaaC zapewnia działowi bezpieczeństwa odpowiedni poziom komfortu: nikt i nic nie miesza w konfiguracjach; można też uzyskać większą pewność, że powoływane środowiska są zgodne z tym, co zostało zaplanowane.

Przedstawiciele PKO przypomnieli też, że przy migracji do chmury niezwykle ważne jest rozbicie monolitycznych aplikacji i przejście na model mikroserwisowy. Aplikacje muszą być transparentne, łatwo rozliczalne i „monitorowalne”. „W chmurze musi być lepiej niż było. Kiedy budujemy aplikacje w chmurze, która musi skomunikować się z on-premise, a tam jest dług technologiczny, to jednym z wymagań security jest likwidacja tego długu – powiedział Krupnik.

Automatyzuj i buduj świadomość

O skali wyzwań związanych z konfiguracją środowisk chmurowych świadczą liczby. Wszyscy wiemy, że dobrze zrobiony Identity and Access Management to fundament bezpieczeństwa. Natomiast tylko w jednej z usług udostępnianych przez Amazon Web Services, Elastic Compute Cloud (EC2), istnieje ok. 600 konfigurowalnych parametrów uprawnień. A wszystkich usług w portfolio AWS jest ponad 200. Na tym prostym przykładzie widać wyraźnie, jak dużą złożonością charakteryzuje się chmura i jak wielką wagę ma odpowiednie zarządzanie tym obszarem. 

Jeśli dodatkowo nałożymy na to filtr nowoczesnych metod wytwarzania oprogramowania – w podejściu DevOps nowych wersji aplikacji może powstać nawet kilka dziennie – okazuje się, nie da się tego wszystkiego spiąć ręcznym sterowaniem: automatyzacja i delegowanie świadomości security to konieczność. Dlatego też programistów należy włączyć w procesy projektowania bezpieczeństwa. Określa się to mianem „shift left” – to praktyka, w której testowanie jakości, wydajności i bezpieczeństwa odbywa się na bardzo wczesnym etapie rozwojowym – nic nowego, ale dopiero teraz staje się to oczywiste również dla programistów. Tym samym podejście DevOps przekształca się de facto w DevSecOps.

Więcej informacji o programie: 

LINKEDIN: https://www.linkedin.com/showcase/cloudexcellencepl/