12 grudnia 2021 na ludzi utrzymujących oprogramowanie w wielu firmach na świecie padł blady strach. Tego dnia potwierdzenie znalazła informacja (do tej pory powtarzana tylko pokątnie), że istnieje poważna luka bezpieczeństwa w najpopularniejszej bibliotece obsługującej logowanie na platformie JVM (Java Virtual Machine) o nazwie Apache Log4j.
Autorem artykułu jest Wojciech Gawroński, AWS CEE Senior Developer Advocate.
Świat ogarnęło szaleństwo i wiele firm straciło sporo czasu na powrót do normalnego stanu. A to tylko jeden z ostatnich przykładów, gdy bezpieczeństwo systemów IT pojawiło się nawet w nagłówkach popularnych serwisach mediowych. W tym przypadku głównie z powodu zasięgu oraz łatwości wykorzystania tej podatności - w końcu każdy script kiddie może dalej z tej luki skorzystać w bardzo prosty sposób.
Twórcom oprogramowania w takich sytuacjach od razu nasuwa się pytanie: co możemy zrobić żeby się przed tym ustrzec w przyszłości?
Powinniśmy zacząć od tego, żeby nie pozostawiać tematu bezpieczeństwa na sam koniec. Jak to zrobić? Najprościej jak się da: przez zajęcie się nim jak najwcześniej w procesie wytwarzania oprogramowania.
W branży IT od dłuższego czasu popularność zyskuje tzw. podejście shift-left, czyli
w bezpośrednim tłumaczeniu przesunięcie w lewo. Chodzi o przeniesienie w procesie wytwarzania oprogramowania konkretnych działań na wcześniejszy etap - czyli w lewo, biorąc pod uwagę kierunek na większości diagramów. Co nam to da? W procesie wytwarzania koszt obsługi problemu znalezionego na późniejszym etapie jest wielokrotnie wiekszy, więc im wcześniej znajdziemy potencjalną lukę bezpieczeństwa tym taniej będziemy mogli ją usunąć.
Przedtem jednak należy się pogodzić z tym, że osiągnięcie najwyższego stopnia bezpieczeństwa to bardzo kosztowny proces. Im większych gwarancji potrzebujemy, tym większe będziemy musieli ponieść nakłady finansowe oraz czasowe. Dlatego zapewnianie bezpieczeństwa to ciągły balans - gdzie po jednej stronie mamy poniesione koszty (w postaci czasu i zasobów), a po drugiej zestaw zagrożeń, które czyhają na nasze systemy i mogą wyrządzić im szkodę.
Skąd wiadomo, które z potencjalnych zagrożeń są najbardziej szkodliwe? W oznaczenie priorytetów największy wkład ma modelowanie zagrożeń.Jest to temat trudniejszy w implementacji, ma on jednak największy zwrot z inwestycji. Co ważniejsze: taki model zagrożeń przygotowuje się na różnych poziomach szczegółowości (np. dla całego rozwiązania lub tylko jego fragmentu) w zależności do potrzeb - i tutaj wracamy do wyżej wspomnianego balansu.
Jak więc przesunąć temat bezpieczeństwa na początek? Przede wszystkim powinniśmy się oprzeć się o potwierdzone i sprawdzone sposoby oraz praktyki.
Pierwszym przykładem jest automatyzacja - czyli wykorzystywanie narzędzi do wykonywania powtarzalnych procedur automatycznie, w odpowiednich punktach procesu wytwarzania oprogramowania. Robimy to po to, żeby odciążyć nasze zespoły oraz zapewnić pewien bazowy i powtarzalny poziom bezpieczeństwa. Warto wspomnieć tutaj, że nie musimy naciskać na 100% automatyzację wszystkiego od początku. Już samo skupienie automatyzacji na miejscach, które aktualnie stwarzają najwięcej problemów przyniesie wymierne korzyści.
Drugim ważnym aspektem jest proces przeglądu kodu - przede wszystkim pod kątem bezpieczeństwa. Każdy programista zdaje sobie sprawę z tego, że błądzić jest rzeczą ludzką i to właśnie przegląd kodu jest jednym z procesów, który niesie ze sobą konkretną wartość w kontekście eliminacji potencjalnych błędów. Jeżeli więc w tym procesie kładziemy nacisk na tematykę bezpieczeństwa, będziemy w stanie skorzystać z benefitów płynących z przesunięcia w lewo. Dodatkowo, jeśli dołączymy do tego wyżej wymienioną automatyzację i skorzystamy z narzędzi, wspomagających przegląd kodu, będziemy w stanie wyeliminować problemy dużo mniejszym kosztem.
Jak efektywnie skorzystać z takich narzędzi? Mamy tutaj dwie dostępne opcje: albo będziemy walczyć z wyzwaniami samodzielnie, tworząc własne rozwiązania, borykając się ze wszystkimi możliwymi problemami po drodze, dodatkowo wiedząc jak kosztowny będzie to proces, albo możemy zaufać dostawcy i skorzystać z narzędzi, które przygotował.
Dość powszechną wiedzą jest, że zdecydowana większość przedsiębiorców w Polsce i na świecie nie ma szans na zapewnienie swoim najcenniejszym zasobom sprzętowym choćby ułamka bezpieczeństwa oferowanego przez chmurę. Dostawcy zarabiają na gwarancjach dostarczanych swoim klientom, więc automatycznie inwestują nieporównywalnie większe środki w zapewnienie infrastrukturze odpowiedniego bezpieczeństwa na poziomie fizycznym i wirtualnym.
W jeden tylko kwartał zeszłego roku (2021), 20 największych dostawców chmury obliczeniowej na świecie wydało 38 miliardów dolarów na inwestycje w centra danych (informacje na co konkretnie możesz znaleźć tutaj oraz tutaj), co daje 31% wzrost rok do roku na bazie raportu Synergy Research Group.
Przez 10 lat (od roku 2011 do 2021) firma Amazon Web Services (AWS) wydała 35 miliardów dolarów na centra danych składające się na region w północnej części stanu Virginia (zwanym w żargonie us-east-1 lub N. Virginia). To daje kwotę 3.5 miliarda dolarów rocznie - wliczając w nią koszty sprzętu, płace operatorów, a także opłaty bezpośrednio i pośrednio związane z kwestiami bezpieczeństwa.
Kolejnym przykładem inwestycji w infrastrukturę i bezpieczeństwo, która byłaby ciężka do podjęcia przez firmę nie skupiającą się na dostarczaniu usług chmurowych to budowa 30 stref lokalnych w 2 lata w 21 krajach na całym świecie - w tym Europie Środkowej i Wschodniej, także w Polsce.
Jednak sprzęt i jego bezpieczeństwo fizyczne oraz wirtualne to nie wszystko: w dzisiejszym świecie liczą się dedykowane usługi, które pomagają oszczędzać czas i pieniądze - a tych w portfolio AWS nie brakuje. Dostawca cały czas poszerza swoją ofertę samodzielnie oraz wspomaga się partnerami - inwestując w budowę nowych rozwiązań i ściślejszą integrację z istniejącym ekosystemem usług.
Z punktu widzenia opłacalności to właśnie decyzja o zaufaniu dostawcy wydaje się najlepsza. Jak widać w powyższych przykładach, dostawcy inwestują w bezpieczeństwo (wliczając w to sprzęt, procedury i załogę) wielokrotnie więcej niż każdy inny biznes jest w stanie przeznaczyć samodzielnie. Można tutaj śmiało skorzystać z porównania, że wykorzystując dostawcę Twój biznes i projekt stoi na ramionach gigantów, a przez to może skorzystać z ich nakładów finansowych, wiedzy, i możliwości.
Jednak na bazie jednego konkretnego mitu pt. chmura jest niebezpieczna, część społeczności i użytkowników dała sobie wmówić, że chmura obliczeniowa jest z definicji rozwiązaniem niegodnym zaufania.
Wykorzystano przy tym mechanizm, który każe nam szybko i łatwo znajdować usprawiedliwienie dla własnych błędów, a jednocześnie być skrajnie nietolerancyjnymi dla najmniejszych przewinień innych. Dlaczego ta wybiórczość jest szkodliwa?
Głównie dlatego, że dość mocno na przestrzeni ostatnich lat zmieniły się zachowania w cyberprzestrzeni. Ostatnie ataki (np. Lapsus$) pokazują, że dzisiejsi hakerzy są oportunistycznymi drapieżnikami, którzy przeszukują internet w poszukiwaniu systemów podatnych na ataki, źle skonfigurowanych - i dopiero po wykryciu takich słabości biorą na cel konkretną firmę.
Dlatego techniczni decydenci w organizacjach powinni przestać zastanawiać się czy chmura jest bezpieczna, a ocenić, czy sami używają chmury w bezpieczny sposób.Warto wspomnieć, że dostawcy chętnie pomagają w tej ocenie - i dbają o wiele aspektów wymienionych powyżej z naciskiem na najwyższe standardy, klarowność i widoczność, oraz stawiając na automatyzację w mniejszej i większej skali - także ściśle współpracując z partnerami ciągle poszerzając portfolio usług.
Jeśli jednak należysz do grupy nieprzekonanych osób, posłużę się po raz kolejny przykładami. Zacznijmy od tego kto konkretnie korzysta z chmury AWS.
Przeszukując materiały dostępne po stronie tego konkretnego dostawcy nie ma najmniejszego problemu, żeby znaleźć firmy wymagające spełnienia najwyższych standardów jakościowych lub z branż postrzeganych jako silnie regulowane takich jak banki, branża medyczna, czy linie lotnicze. Przykładowo: Moneta to bank w chmurze AWS. Innym przykładem są Polskie Linie Lotnicze LOT, również wykorzystujące wspomnianego dostawcę w ważnych segmentach swojego systemu.
Jednak nie tylko giganci segmentu enterprise lub branż regulowanych wykorzystują chmurę - innym przykładem mogą być firmy Huuuge Games lub Brainly, czyli szybko rosnące biznesy o skali globalnej. Przy dziennej liczbie aktywnych użytkowników przekraczających milion lub dziesiątki milionów, bezpieczeństwo oraz nacisk na najwyższe standardy (w tym także wspomnianą automatyzację) musi być nadrzedną wartością w organizacji.
Tutaj w szczególności chciałbym przytoczyć cytat CTO firmy Brainly, Billa Salaka, który uzmysławia jak sporą ulgą dla organizacji jest pomoc dostawcy:
It’s not just about saving a few hours here and there — it’s about existing as a company 2−3 years from now. Using AWS, we don’t have to build large teams around infrastructure and security management.
Zaprezentowałem kilka udokumentowanych przypadków biznesowych jak chmura pomaga i aktywuje te przedsiębiorstwa, ale na pewno wszyscy zgodzimy się ze stwierdzeniem, że to bezpieczeństwo tworzy odpowiednie warunki do tej aktywacji. Nie należy jednak mylić bezpieczeństwa ze ślepym, lub wręcz paranoicznym podążaniem za sztucznymi procedurami.
Bezpieczeństwo powinno być proste i intuicyjne. W przeciwnym przypadku najsłabsze ogniwo całego łańcucha, jakim niewątpliwie jest w wielu przypadkach człowiek, zawsze pęknie. W tym konkretnym przypadku znajdzie sposób żeby uprościć sobie życie i obejść narzucone mechanizmy.
To dlatego temat bezpieczeństwa to w większości przypadków wyzwanie w aspekcie ludzkim! Dostawca powinien stawiać na to, żeby wykorzystanie dobrych praktyk było jak najmniej kłopotliwe. Dbałość o aspekty bezpieczeństwa to powinien być naturalny element codziennej pracy np. podczas budowania nowych wersji oprogramowania. Rolą dostawcy jest przygotować i zbudować warunki do kultywowania tej prostoty - a usługi dostępne w portfolio AWS takie jak AWS Security Hub, AWS Inspector, czy Amazon CodeGuru to właśnie wcielenie tej idei w życie.
Warto również zauważyć, że dzięki dostawcom i ciągłym uproszczeniom pojawia się kolejny pozytywny skutek uboczny: już nie jesteśmy sztucznie ograniczeni jeśli chodzi o szybkość wytwarzania oprogramowania. Kiedyś musieliśmy wybierać: albo będziemy bezpieczni albo będziemy eksperymentować i poruszać się szybko, pozostawiajc kwestie bezpieczeństwa z boku. Przy odpowiednim wykorzystaniu chmury nie musimy stawać przed takim dylematem.
Wspomniałem wyżej o modelowaniu zagrożeń. Niekonsekwencją i wybiórczym zachowaniem byłoby pominięcie pytania: czy dostawcy są całkowicie odporni na zagrożenia? Odpowiedzią jest stworzony na wysokim poziomie szczegółowości model zagrożeń i poniesione inwestycje finansowe oraz czasowe, w celu wyeliminowania potencjalnych problemów. To dlatego dostawcy znajdują się od początku w lepszej pozycji, bo dla pozostałych organizacji taki poziom szczegółowości jest w większości przypadków nieosiągalny. Poniesione nakłady zwracają się w takiej sytuacji z nawiązką, a dzięki działaniom prewencyjnym dostawcy dbają o ten temat w trybie ciągłym. Nawet w mało prawdopodobnym przypadku wystąpienia problemu, szybkość i proaktywność w działaniach ponownie znajdują się na poziomie nieosiągalnym dla wielu organizacji. A dodatkowo w takiej sytuacji priorytetem od strony dostawcy jest klarowna i rzetelna komunikacja na temat zastosowanych rozwiązań oraz działań zaradczych.
I na koniec tej części chciałbym ponownie nawiązać do przywołanego kryterium wybiórczości: należy pamiętać, że chmura i usługi w niej dostępne to narzędzia. Producenci narzędzi starają się jak mogą dbać o nasze bezpieczeństwo, ale jako ich użytkownicy również jesteśmy odpowiedzialni za ich bezpieczne wykorzystanie.
AWS nie pozostawia użytkowników samymi sobie i w takiej sytuacji odwołuje się do modelu współdzielonej odpowiedzialności. W tym podejściu za bezpieczeństwo chmury odpowiada dostawca - czyli AWS, o czym mówiliśmy np. w sekcji dotyczących inwestycji w kwestiach bezpieczeństwa fizycznego i wirtualnego. Warto jednak pamiętać, że za bezpieczeństwo w chmurze odpowiada klient, ale i tutaj dostawca przygotował jak najlepsze rozwiązania które tą codzienną dbałość ułatwiają.
Jeśli chodzi o edukację w tym temacie i o efektywne budowanie rozwiązań opartych o chmurę warto zwrócić uwagę na jeszcze jeden element. AWS dostarcza tzw. AWS Well-Architected Framework, czyli zestaw sprawdzonych reguł i rekomendacji podzielony na 5 filarów. Jednym z nich jest bezpieczeństwo i zawsze warto sięgnąć po ten dokument, jeśli mamy wątpliwości lub szukamy inspiracji jak efektywnie rozwiązać konkretny problem związany z kwestiami bezpieczeństwa.
To jednak nie wszystko, bo w dalszym ciągu możemy skorzystać z innych narzędzi, które zbudowali dostawcy.
Przesunięcie w lewo nie dotyczy tylko i wyłącznie wykorzystywania zarządzanych usług w chmurze, ale także polega na włączeniu specjalistycznych rozwiązań i narzędzi w procesie wytwarzania oraz utrzymywania oprogramowania. Mam na myśli tutaj usługi Amazon CodeGuru oraz Amazon DevOps Guru, które omówimy sobie w kolejnej części na konkretnym przykładzie.
Hej, jesteśmy na Google News - Obserwuj to, co ważne w techu
