TRANSKRYPCJA WEBINARU

Bezpieczna chmura. Zaawansowane funkcje zabezpieczeń Google Cloud.

 

Prelegent: Gabriel Marchwant

Data: 13.02.2024

 

Wstęp i przywitanie

 

Witamy serdecznie na webinarze firmy FOTC na temat zabezpieczenia chmury obliczeniowej Google Cloud. Nazywam się Gabriel i w FOTC pełnię funkcję Cloud Security Engineera. Dzisiaj przejdziemy drogę przez zagrożenia, ich zabezpieczenia i dobre praktyki Google Cloud dla lepszego zrozumienia bezpieczeństwa opartego na zasobach chmurowych, także zaczynajmy.

Przed rozpoczęciem webinaru kilka informacji organizacyjnych. Po pierwsze: webinar jest nagrywany. Po drugie: webinar można otrzymać w ciągu trzech dni roboczych, do każdego z was zostanie to nagranie wysłane. Po trzecie: pytania można zadawać na czacie po prawej stronie. Jak chcecie, to możecie przetestować, czy widzę wasze wiadomości. Cześć! Na końcu będzie jeszcze sesja Q&A.

 

Witam wszystkich bardzo serdecznie. Warto jest podczas słuchania tego webinaru posiadać podstawową wiedzę o chmurze i umiejętność posługiwania się językiem angielskim, bo będą tutaj czasami pewne nazwy, które będą w języku angielskim, więc dobrze byłoby mieć takie pojęcie. Jeżeli mówię Cloud, to wiadomo, że chodzi o chmurę. W przypadku dodatkowych pytań zapraszamy też na stronę fotc.com oraz do pisania do mnie. Postaram się odpowiedzieć na wszystkie pytania i wątpliwości. Może ja wam zadam jakieś pytanie, okej?

Zanim jeszcze agenda, chciałem przypomnieć, że FOTC zajmuje się pomocą w migracji do chmury, supportem, zajmuje się wsparciem, jeżeli chodzi o migrację danych, jeżeli chodzi o audytowanie bezpieczeństwa, także jeżeli ktoś był zainteresowany usługami, zapraszamy do nas.

Agenda

 

No dobrze, na początku przyjrzyjmy się naszej agendzie. Jak komunikowane było na naszej stronie, rozpoczniemy od dogłębnego zrozumienia zasady dzielonej odpowiedzialności. Jednak zasada nie ogranicza się tylko i wyłącznie do tej chmury, również Azure i AWS. Gdy mówię o tym, chciałem wam zadać takie krótkie pytanie w związku z ankietą: czy korzystacie z usług Google Cloud Platform, czy po prostu z chmury googlowej? Żebyście mogli zagłosować: tak, nie, dopiero rozważam.

Okej, ci co chcieli zagłosować, już zagłosowali, to wracamy do agendy. Następnie przejdziemy do części poświęconej zarządzaniu ryzykiem i zaufaniem w naszej organizacji. Jak znaleźć złoty środek między paranoją a byciem łatwowiernym? Kolejno przejdziemy przez scenariusz niebezpiecznej organizacji, czyli stworzymy taką organizację, która albo zmigrowała do chmury, i zastanowimy się, jakie zagrożenia na nią czekają i czy są jakieś sposoby, żeby zminimalizować zagrożenia związane z bezpieczeństwem chmurowym. I przede wszystkim też zobaczymy, jak to bezpieczeństwo będzie się różniło od tego, które występowało wcześniej. Dalej przejdziemy przez zagrożenia chmurowe, jakie mogą czekać, i jak będziemy je łagodzić, wykorzystując gotowe narzędzia Google Cloud. Dalej będzie monitorowanie i wykrywanie zagrożeń. Czyli jeżeli mamy świadomość, jakie mamy zagrożenia, to przejdziemy do tego, jak je zauważyć w naszej infrastrukturze. Jak zobaczyć, że mamy jakiegoś intruza? Jak wykorzystać dane dostępne w Google Cloud, żeby móc zapobiegać problemom? Potem podsumujemy sobie narzędzia bezpieczeństwa, które spotkaliśmy wcześniej, opiszemy krótko je i w jakim przypadku je wybierać. Na końcu właśnie będzie Q&A oraz krótko o audycie bezpieczeństwa FOTC, zarówno dla Google Cloud, jak i dla Workspace.

 

Okej, zasada dzielonej odpowiedzialności. Kiedy mówimy o zasadzie dzielonej odpowiedzialności, trzeba wiedzieć o tym, że chmura upraszcza bardzo wiele kwestii związanych z bezpieczeństwem. Tak jak mamy przedstawione: ochrona fizycznego sprzętu, oprogramowania, działania sieci, magazynowanie usługowych – to wszystko nam zapewnia Google i o to nie musimy się przejmować podczas pracy w chmurze. Jednak bezpieczeństwo nie ogranicza się tylko do tego i cały czas mamy wszystkie te warstwy w chmurze, czyli zarządzanie dostępem, ochrona przed atakami, monitorowanie konfiguracji, zarządzanie ryzykiem i wybór odpowiednich zabezpieczeń.

Taki najprostszy podział to jest podział na bezpieczeństwo chmury jako takiej i bezpieczeństwo w chmurze. Bo sama chmura zaprojektowana jest bezpiecznie, tylko to, jak my dostęp do tej chmury, do tych zasobów zaprojektujemy w tej chmurze, to już jest nasza broszka. Przyjrzyjmy się właśnie, jak Google wywiązuje się ze swojej części zasady dzielonej odpowiedzialności. Przede wszystkim jest to wielopoziomowa, skalowana ochrona w tle. Google jako korporacja musi mierzyć się z bardzo dużą ilością swoich usług i ruchu sieciowego, który jest związany z nimi. Szacuje się, że przez Google przechodzi nawet 25% ruchu sieciowego, dlatego musieli stworzyć własne reguły, które dotyczą bezpieczeństwa jego własnej infrastruktury. Na szczęście podzielili się częścią tych reguł, żeby pomóc zabezpieczyć też ich usługę, jaką jest Google Cloud.

 

Pierwszą z takich ochron in-depth jest właśnie ochrona na dwóch oddzielnych, niezależnych poziomach. To znaczy, że w tle, jeszcze przed tym, jak my w ogóle dostajemy dostęp, to ochrona jest wdrożona o nieograniczonym skalowaniu i jest zawsze włączona domyślnie. Dodatkowo wszystkie dane są przetrzymywane w formie szyfrowanej i to szyfrowanie jest i w trakcie „lotu” danych, i kiedy są na miejscu. Dodatkowo Google nie ma dostępu do tych naszych danych, czyli jeżeli one są zaszyfrowane, nawet Google ich nie otrzyma. Następną regułą jest transparentność działań, usług i procesów, czyli „wiara do zera”. Chodzi o to, że jak ktoś u Google’a działa, to powinniśmy mieć wszystkie możliwości, żeby sprawdzić, jak to działa, zweryfikować czy to działa i w jaki sposób Google czy jego produkty będą przetwarzać nasze dane, żebyśmy wiedzieli, że jesteśmy bezpieczni. Ostatnim elementem reguł jest zabezpieczenie fizycznego dostępu do swoich serwerowni, ich utrzymania oraz przetrzymywanie dodatkowych kopii w wielu miejscach na świecie. Chodzi o to, że jak mamy te nasze dane, one są gdzieś przetrzymywane, to wiadomo, że to będzie bardzo bezpieczny sposób przetrzymywania, że nikt do tych serwerowni nie będzie mógł wejść. Około 1 do 2 procent wszystkich osób, które pracują w Google, w ogóle mogą wejść do tych serwerowni, także są bardzo restrykcyjne przepisy dostępu do nich.

Dużą zaletą wyboru usług chmurowych jest możliwość dostosowywania tej odpowiedzialności do naszych wymagań. Jak mamy pokazane na wykresie, mamy ten podział odpowiedzialności między klientem a Google, różny zależnie od tego, jaki rodzaj usługi wybieramy. Tutaj mamy taki podstawowy podział odpowiedzialności na przechowywanie, przetwarzanie i monitorowanie własnych potrzeb. Czyli mamy tutaj, tak jak widzimy: hardware, kernel i networking jest zawsze odpowiedzialnością Google. Oferowane usługi różnią się między innymi tym, że im więcej dajemy odpowiedzialności klientowi, tym też ma większą możliwość elastyczności w tym, co robi. To znaczy, za każdym razem, kiedy zdejmujemy z klienta jakąś odpowiedzialność, czy Google za działanie czegoś, to my dostajemy mniejszą możliwość wpływania na to, dlatego że Google wierzy, że jeżeli on już coś ustanowił, to to będzie bezpieczne tak, jak on to robi z dobrymi praktykami. Ale jeżeli klient chce, może wybrać inny rodzaj usługi, wtedy będzie miał większą możliwość elastyczności dostosowania swojego bezpieczeństwa, tylko co za tym idzie – ponosi za to większą odpowiedzialność.

 

Zarządzanie ryzykiem i zaufaniem

 

Dalej przejdziemy do zarządzania ryzykiem i zaufaniem. Stopień zaufania wymiernie wpływa na funkcjonowanie biznesu. Z raportu Krajowego Rejestru Długów i rzetelności firmy wynika, iż ponad 52% przedsiębiorców wątpi w rzetelność swoich kontrahentów. Dzięki głębszemu zrozumieniu zasady dzielonej odpowiedzialności możemy zweryfikować swój poziom zaufania do dostawcy jako kluczowego partnera rozwoju naszego biznesu, dlatego przejdźmy teraz do kolejnej części webinaru, jaką jest właśnie zaufanie i ryzyko. Temat zaufania można ugryźć na bardzo wiele sposobów. To może być zaufanie nasze do innych użytkowników, zaufanie do funkcjonowania aplikacji, do działania systemów, do procesów biznesowych, ale to również może być zaufanie jednej firmy do drugiej lub zaufanie innych ludzi do nas. Największym problemem staje się, kiedy zaufanie zawodzi, bo oczywiście zaufanie też może być rozwiązaniem, jeżeli jesteśmy leniwi i po prostu chcemy brać wszystko na zaufanie. W organizacjach chmurowych zwykle kończy się to nadwiarą, że osoba uwierzytelniona i autoryzowana, lub aplikacja uwierzytelniona i autoryzowana, jest godna zaufania i nie musi być dalej monitorowana. Jednak jest to spory błąd, który może być rozwiązany na wiele sposobów, na przykład metodą zerowego zaufania. W końcu warto wiedzieć, że właściwe określenie uprawnień i polityk może oszczędzić dużą ilość czasu na zarządzanie zaufaniem wobec użytkowników.

Głównym elementem zarządzania zaufaniem do naszych użytkowników, mantrą powtarzaną przez kluczowych specjalistów chmury Google zajmujących się identyfikacją i dostępem do zasobów, jest przypominanie o zachowaniu zasady najmniejszego przywileju. Oznacza ona przekazywanie podmiotom zabezpieczeń, czyli użytkownikom, grupom lub kontom serwisowym, najmniejszych możliwych uprawnień, które umożliwiają wykonywanie czynności, które mają zrobić. Pomyślmy o tym w ten sposób: czy pracownikowi, który ma tylko i wyłącznie przeglądać zasobniki Cloud Storage, dawać od razu uprawnienie administratora do tej usługi? Nie, wystarczy dać uprawnienia związane z jego zadaniem. Dlatego kluczowe jest właściwe zarządzanie użytkownikami za pomocą Identity and Access Management (IAM), który odpowiada na pytanie: kto, co może i na jakich zasobach. Oczywiście zarządzanie dostępem nie odbywa się tylko za pomocą IAM-a, ale też Cloud Identity lub Google Workspace, który odpowiada za uwierzytelnianie. Czyli mamy taki schemat, że mamy osobę (Cloud Identity lub konto Google Workspace) i Identity and Access Management, który sprawdza, co ta osoba może. W każdym przypadku właściwe skonfigurowanie IAM-a już samo w sobie zwiększa w bardzo dużym procencie nasze bezpieczeństwo.

Jeżeli chodzi o zarządzanie ryzykiem i zaufaniem, stopień akceptowalnego ryzyka jest wtedy, gdy praca wymagana do przełamania zabezpieczeń jest większa niż wartość chronionego zasobu oraz posiadamy wystarczające ubezpieczenie na wypadek incydentu. To jest właśnie to, o czym mówiłem na początku przy agendzie: w jaki sposób znaleźć złoty środek między łatwowiernością a paranoją? Mamy duże ryzyko, kiedy dajemy małą ilość zabezpieczeń na bardzo wartościowe zasoby, a warto nasze zabezpieczenia skalować w oparciu o kluczowość posiadanych zasobów. To znaczy, że nie musimy zabezpieczać tak mocno rzeczy, które nie są dużo warte lub na przykład kont, które nie mają bardzo dużych uprawnień, ale na przykład konto administratora warto zabezpieczyć kluczem fizycznym, bo jest dużo bardziej cenne dla naszej organizacji. Każda organizacja może mieć to troszeczkę inaczej zrobione, jednak w każdej organizacji powinna być taka świadomość, że różne stopnie akceptowalnego ryzyka dotyczą różnych zasobów. Zarządzanie ryzykiem odnosi się do kalkulacji poniesionych strat i prawdopodobieństwa wystąpienia takiego incydentu, czyli bardziej będziemy się przejmować atakami, które są aktualnie popularne w sieci, niż tymi, które dotyczą na przykład ataków kierowanych na konkretne miejsca.

W przypadku zaufania do osoby kwestia wyboru dla nas może mieć duże znaczenie. Możemy mieć duże zaufanie, jeżeli chodzi na przykład o dobranie krawatu – możemy komuś ufać, że pomoże w ubraniu się czy na przykład wybraniu smaku kawy w barze. Ale ta sama osoba, kiedy mielibyśmy jej przekazać nasze dane, jeżeli chodzi o kartę płatniczą, to możemy już nie mieć dla niej takiego zaufania, dlatego że właśnie to zaufanie jest bardzo zależne od sytuacji. Dane, które są dla nas powiedzmy neutralne, jeżeli chodzi o możliwość wycieku, no to możemy zaufać bardziej, ale jeżeli takie dane będą czymś bardzo poważnym, to lepiej zawsze pomyśleć dwa razy. Dlatego ta sama osoba w IAM-ie może mieć różne poziomy zaufania dla bardzo różnych usług i warto o tym pamiętać. To, że ktoś jest adminem w jednej usłudze, nie znaczy, że musi być adminem też w kolejnej.

Podczas projektowania infrastruktury chmurowej będziemy często zadawać pytania na temat ryzyka i zaufania. Przykładowo: czy nasza baza potrzebuje dwóch, trzech, pięciu kopii zapasowych? Jak często powinniśmy te kopie wykonywać i w jakich regionach musimy je przetrzymywać? Mądrym wyborem jest posiadanie takich kopii w różnych miejscach na wypadek jakiegoś incydentu związanego z jednym regionem. Na przykład jeden region może „upaść” na wypadek braku dostaw prądu, katastrofy naturalnej i takie serwery mogą zostać odcięte, ale jeżeli będziemy mieć taką kopię w dwóch różnych regionach, to zawsze kopia z drugiego regionu może przejąć wtedy pałeczkę do działania i dać nam poczucie bezpieczeństwa. Dodatkową opcją może być wykorzystanie firm ubezpieczeniowych w celu minimalizacji strat. Czasami wystarczy tylko bardzo dobre ubezpieczenie na wypadek incydentu. Faktycznie nasza firma może stracić, jednak jeżeli będzie ubezpieczona, może przetrwać trudny okres na przykład włamania lub katastrofy.

Ostatnią kwestią wartą poruszenia w temacie ryzyka i zaufania jest to, że powinny one wyprzedzać wiedzę na temat procesów biznesowych, struktury organizacyjnej, posiadanych zasobów, wartości oraz zależności poszczególnych danych firmowych. To znaczy, że powinniśmy mieć, jako my jako osoby zajmujące się bezpieczeństwem, bardzo dużą wiedzę na temat tego, w jaki sposób działa firma, żeby móc na przykład znaleźć „łakome kąski” dla osób, które chciałyby tam coś ukraść, i skupić na nich naszą ochronę. Z pomocą może nam przyjść takie rozwiązanie jak Menadżer Ryzyka oraz Security Command Center, który umożliwia lepsze zrozumienie bezpieczeństwa struktury naszej organizacji chmurowej i dopasowanie zabezpieczeń pod odpowiednie nasze zasoby. Na przykład taki menadżer zasobów rzuca szerokie światło na posiadane zasoby organizacyjne, ich stan i lokalizację. Przydatnymi usługami może być Identity-Aware Proxy, który wraz z modułem BeyondCorp Enterprise nadzoruje uprawnienia użytkowników i dostęp do zasobów. Tutaj na ekranie mamy taki przykład, w jaki sposób Identity-Aware Proxy wraz z BeyondCorp mogą pomóc nam w dodatkowym zabezpieczeniu zasobów, takich jak aplikacje webowe, aplikacje, infrastruktura lub API, wykorzystując dodatkowe informacje na temat połączenia, takie jak czas sesji, czas logowania, no i wszelkiego rodzaju dodatkowe opcje związane z dostępem opartym o kontekst i zerowe zaufanie, czyli informacje na temat urządzenia, z którego się osoba loguje, no i ich uprawnień, które będą cały czas dopasowane zależnie od tego, w jaki sposób zmienia się kontekst.

 

Przykładowe scenariusze ataku

 

Dalej przejdziemy do przykładowych scenariuszy ataku. Opowiedzmy sobie trochę o tej naszej organizacji, którą sobie tutaj teraz projektujemy. W swojej poprzedniej pracy miałem ogromną styczność z oprogramowaniem typu CAD/CAM i maszynami CNC. To są takie maszyny do przetwarzania metalu na różne sposoby, jak tokarki, jak lasery. Uważam, że w czasach postępującej automatyzacji, druku 3D, coraz bardziej powszechna oraz niebezpieczna jest to technologia. Wyobraźmy scenariusz przedsiębiorstwa, które specjalizuje się w produkcji. Na pewno byśmy nie chcieli, żeby projekty plików, czyli takich projektów ze wzorami, jak ma zostać wykonana jakaś część, trafiły w niepowołane ręce. Jeżeli ktoś przejął takie dane, a miałby dostatecznie dużo zasobów, żeby sobie kupić czy to wycinarkę laserową, czy tokarkę, mógłby po prostu poskładać to w broń. Byłoby to bardzo duże zagrożenie – raz ze strony tego, że nasza firma zostaje pogrążona, jeżeli chodzi o konkurencyjność, bo każdy może mieć dostęp do naszych schematów działania, a dwa, że może to mieć faktyczny szkodliwy wpływ na społeczeństwo. Załóżmy, że nasza firma wykorzystuje szereg systemów CNC, lasery, frezarki hydrauliczne, i migruje do chmury dużą część swoich zasobów, aby umożliwić lepszą komunikację między użytkownikami i maszynami, no i coraz bardziej rozrastającą się społecznością, która nie tylko teraz jest w jednym miejscu, ale na przykład ma w różnych miejscach swoje oddziały, w których produkuje części. Jakie mogą być zagrożenia związane z działaniem takiej firmy i jak można im zapobiegać? O tym za chwilę.

Scenariusz zagrożenia numer 1: Jednym z takich podstawowych zagrożeń, które mogą nam przyjść na myśl, to próba włamania się do bazy danych schematów produkcyjnych lub backupów w Cloud Storage. Oczywiście najważniejszym elementem zabezpieczania jest szyfrowanie i odizolowanie od internetu publicznego takich zasobów. Polityki powinny zakazywać tworzenia jakichkolwiek publicznych bucketów, a wgląd do SQL powinien być dostępny tylko z niepublicznych, wewnętrznych adresów IP. Dodatkowo wymiana informacji poza projektem chmurowym powinna odbywać się wyłącznie za pomocą szyfrowanego tunelu, na przykład VPN. Jeśli chcemy połączyć naszą chmurę z jakimiś zasobami on-premisowymi, zróbmy to szyfrowanym tunelem lub przez Identity-Aware Proxy Forwarding, który umożliwia łączenie się do maszyn bez zewnętrznego adresu IP. Dodatkowo na pomoc może nam przyjść usługa VPC Service Controls, która umożliwia segmentację sieci i kontrolę dostępu do tej sieci, zwiększając bezpieczeństwo dostępu do zasobów w chmurze.

Co jeżeli naszym problemem, naszym zagrożeniem nie będzie osoba, która chce się włamać z zewnątrz, ale osoba z wewnątrz? Tu mamy właśnie scenariusz numer 2. W przypadku wewnętrznego zagrożenia sprawy mają się dużo trudniej. Osoba może otworzyć furtkę do naszych poufnych danych, na przykład stworzyć jakiegoś backdoora, przez którego dalej będzie mogła się włamywać już z innego miejsca. Dlatego tak ważne jest śledzenie poczynań i wpływu użytkowników na systemy. Jeżeli mamy dobrze skonfigurowane uprawnienia IAM i IAP, monitoring, SCC, możemy czuć się w miarę przygotowani. Jednak ważne jest, by ciągle monitorować nasze systemy i zasoby. Przykładowo możemy stworzyć dodatkowe reguły w Eksploratorze Logów, żeby wykrywać alerty. Jeżeli ktoś bardzo chce zobaczyć, co mamy w naszej usłudze Cloud Storage Google i będzie próbował jakimś narzędziem – a jest mnóstwo gotowych narzędzi do skanowania bucketów Google Cloud na GitHubie – jeżeli wiemy, jak te narzędzia działają, możemy zauważyć ich aktywność. Możemy dodać alert, że jakaś osoba czy jakieś buckety wysyłają bardzo dużo informacji o błędach 403 lub 404 z zablokowanym dostępem. Możemy mieć poczucie, że ktoś chce się dostać do naszych bucketów, więc możemy takie metryki stworzyć i mieć alerty oparte na tych metrykach. Dodatkowo otrzymywanie informacji z Data Access Admin Logs o dużej operacji typu data read to dodatkowe informacje, które mogą informować nas o tym, że ktoś próbuje zobaczyć coś, czego nie powinien. Dlatego właśnie to monitorowanie i tworzenie powiadomień związanych z monitorowaniem dostępu powinno być kluczowe w naszej organizacji. Oczywiście SCC jest w stanie zautomatyzować ten proces.

Scenariusz zagrożenia numer 3 to błędna konfiguracja. W tym przypadku naszym problemem nie jest żadna konkretna osoba. Podczas tworzenia maszyny wirtualnej mającej za zadanie wymianę plików w formacie CAD z jakiegoś innego urządzenia, deweloper zapomniał wprowadzić ustawienia Confidential Computing, które umożliwia szyfrowanie danych w trakcie przetwarzania (data in use). Oznacza to, że maszyny wirtualne, które będą przetwarzać nasze dane tych schematów, nie będą miały tych danych zaszyfrowanych podczas przetwarzania. My byśmy chcieli, żeby wszystkie dane były zawsze szyfrowane. Co więcej, taka maszyna posiada publiczny adres IP z otwartym portem SSH. Wiele osób, które zajmują się bezpieczeństwem, wie, że to może być bardzo niebezpieczna sytuacja. Taka maszyna będzie dostępna i widoczna w sieci publicznej. Jak wykryć taką sytuację? Warto w takim przypadku wykorzystać kolejne narzędzie dostępne w Security Command Center, jak Virtual Machine Threat Detection, zajmujące się skanowaniem naszych maszyn wirtualnych i informowaniem nas o tym, że na przykład występuje taki problem jak otwarty port SSH czy brak Confidential Computing, kiedy wszystkie maszynki powinny mieć taką opcję włączoną. Jest bardzo wiele opcji, pokazane na ekranie, w jaki sposób dostajemy powiadomienia na temat luk w zabezpieczeniach.

Dalej zagrożenie numer 4. Nasza organizacja dodatkowo posiada bazę wiedzy firmowej, samouczków i dobrych praktyk. Bardzo dużo firm teraz posiada taką bazę wiedzy, tylko że jest to bardzo duża część wartości takiej firmy. Często taka wiedza jest zasobem umożliwiającym sprawne działanie i konkurencję na dużym rynku produkcyjnym, a taki rynek jest bardzo konkurencyjny. Zasoby takie będą oczywiście dostępne tylko za pomocą strony internetowej z internetu dla każdego pracownika, który może mieć dostęp. Jak sprawić, żeby taki dostęp miały tylko odpowiednie osoby, i jak chronić się przed ciekawską lub zazdrosną konkurencją? Jednym z częstych ataków może być atak typu DoS/DDoS, czyli serwis, który będzie próbował zablokować dostęp do takiej witryny przez bardzo dużą ilość zapytań do serwera, co zablokuje możliwość poprawnego działania i dostępu do zasobów. Możemy skorzystać z usługi Cloud Armor, która nakłada dodatkowe zasady zabezpieczeń kontrolujące dostęp do naszych zasobów chmurowych. Taka ochrona adaptacyjna w Cloud Armor zapewnia nam ochronę backendu w warstwie siódmej przed atakami właśnie typu DDoS. Wykorzystuje on wzorce ruchu do wykrywania potencjalnych ataków i wysyłania alertów. Pokazuje powiadomienia o tym, że coś się u nas dzieje. Oprócz tego Cloud Armor w połączeniu z usługą reCAPTCHA może jeszcze zablokować dostęp wszelkim botom, które chcą się dostać na naszą stronę internetową.

Scenariusz zagrożeń numer 5. Mamy ochronę przed atakami DDoS, jednak nasza strona internetowa może być jeszcze atakowana całą masą ataków webowych. Warto taką aplikację skanować pod względem znanych podatności, w końcu nie chcielibyśmy, żeby stała się ofiarą takiego ataku webowego, nawet takiego bardzo prostego, który zrobi na przykład jakiś nudzący się student. Taki atak SQL Injection może przeprowadzić każdy, kto zna się na składni SQL, i spróbować wpisać coś w jakieś miejsce dostępne do wpisywania na naszej stronie, jakiś formularz. Na szczęście możemy naszą stronę też przeskanować pod względem zagrożeń webowych. Cloud Web Security Scanner umożliwia nam stworzenie automatycznego skanu lub szeregu skanów, które będą się powtarzać w konkretnych momentach w czasie i sprawdzać, czy nasza strona internetowa jest podatna na najczęstsze podatności oparte o OWASP Top 10, czyli taki zestaw najczęstszych podatności webowych. Jest to potężne narzędzie skanujące, dlatego należy się obchodzić z takimi testami ostrożnie. Lepiej utworzyć kopię naszej aplikacji i przeskanować tę kopię, niż wrzucać to na wersję, która działa aktualnie, dlatego że zależnie od tego, jaki wybierzemy poziom takiego skanu, może naprawdę bardzo pomieszać nam na przykład w formularzach czy komentarzach na stronie. Jeżeli dobrze tego nie skonfigurujemy, na przykład nie wykluczymy konkretnych podstron, może się okazać, że taki skan doda nam 100 000 dodatkowych komentarzy, które nie będą mieć żadnego sensu, albo będzie blokował możliwość zalogowania się przez innych użytkowników, dlatego że będzie próbował wszystkimi możliwymi sposobami wykorzystać formularze do zalogowania się. Dlatego sami sobie możemy zrobić taki mini-DoS.

Tworzenie bezpiecznego procesu integracji i wdrażania (CI/CD) jest trudnym zadaniem pod względem architektury bezpieczeństwa. Konfiguracja bezpiecznej metodyki tworzenia nowych zasobów powinna odbywać się za pomocą rozwiązań dostarczonych przez Google – to jest zestawu narzędzi, szablonów, które są wprowadzane z wykorzystaniem Terraforma oraz Deployment Managera. Przykładowo, rozdzielenie ważnych kwestii bezpieczeństwa związanych z CI/CD na pojedyncze projekty, tak jak mamy przedstawione: CI i CD na dwa różne projekty, może zwiększyć nam bezpieczeństwo. Jak rozdzielimy sobie narzędzia wdrażania, jak Terraform state, Source Repository, instancje, to znacznie zmniejszy to ryzyko dostępu do całości, kiedy ktoś przejmie dostęp tylko do jednego projektu. Tak samo możemy rozdzielić wśród deweloperów i DevOpsów, kto będzie miał dostęp do czego – tak żeby jedna osoba nie miała dostępu do wszystkich możliwości w naszym pipeline. Dodatkowo silne szyfrowanie za pomocą KMS zabezpieczy ten kod przed wyciekiem. Takich rozwiązań jest oczywiście dużo więcej, dlatego polecamy infrastrukturę jako kod wraz z CFT (Cloud Foundation Toolkit) jako główną metodę projektowania i wdrażania infrastruktury. Dlaczego? Dlatego że gdy wdrażamy naszą infrastrukturę jako kod, jest dużo łatwiej śledzić zmiany, w jaki sposób nasza infrastruktura będzie przetwarzana i wdrażana. No i oczywiście łatwiej widać jakieś błędy, bo za każdym razem możemy wrócić do tego, jak to ma wyglądać, i zobaczyć, co poszło nie tak.

Kolejny scenariusz zagrożenia to scenariusz ze strony „carbon-based”, czyli naszych użytkowników końcowych. Na pewno chcemy nadzorować ich zachowanie i dostęp zależny od kontekstu. Jako zalecone rozwiązanie są polityki zerowego zaufania, z których możemy skorzystać za pomocą narzędzia BeyondCorp Enterprise oraz polityk bezpieczeństwa w zarządzaniu użytkownikami. Złagodzi to skutki słabego przygotowania naszych pracowników pod względem bezpieczeństwa, wymagając od nich konkretnych urządzeń, ich ustawień i zachowań. Możemy w ten sposób ograniczyć sytuację, gdy nasze zasoby będą podglądane przez komputery bez zainstalowanego antywirusa, bez aktualnych zabezpieczeń systemowych, bez szyfrowanych urządzeń czy bez domyślnej blokady ekranu. Wymuśmy na naszych użytkownikach wszystkie te opcje za pomocą dostępu opartego o kontekst, żeby jak ktoś chce faktycznie mieć dostęp do naszych zasobów, to musiał dostosować się do wymagań naszej firmy. Oczywiście zależnie od tego, jak nasza firma będzie wyglądała, te zasady mogą się różnić – możemy zablokować dostęp z konkretnych adresów IP czy w konkretnych godzinach. Tak jak widać na ekranie, mamy szereg ustawień dotyczących urządzeń użytkowników.

 

Monitorowanie, wykrywanie i analiza

 

Przejdźmy teraz do monitorowania, wykrywania i analizy. Monitorowanie infrastruktury chmurowej jest równie ważne jak zapobieganie zagrożeniom. Zapobieganie zagrożeniom może się wydawać prostsze, bo zaczynamy od zabezpieczeń fizycznych, ale tutaj w chmurze wszystko jest zrobione za pomocą software’u, dlatego dużo łatwiej się przemieszczać między poszczególnymi elementami ochrony. Z drugiej strony, jeżeli chodzi o monitorowanie, kiedy nie mamy takiego fizycznego dostępu i świadomości, gdzie co jest dokładnie, zrozumienie działania zagrożeń może być bardzo trudne. Dla ataków typu APT (Advanced Persistent Threat), czyli takich ataków kierowanych na konkretną organizację, przygotowanych od początku do końca na konkretny cel (a nie takich masowych jak phishing wysyłany do setek osób), nie ma czegoś takiego jak stuprocentowe przygotowanie. Takie ataki będą trwały bardzo długi czas, poprzedza je zbieranie informacji i szukanie słabych punktów, dlatego ważne jest, żeby jeżeli taki atak by nastąpił, to go wykryć. Mam taką książeczkę, w której autor pisze o atakach typu APT i bardzo często, według niego, największym problemem podczas takich ataków wcale nie jest to, że firma jest źle przygotowana pod względem zabezpieczeń, tylko że dowiaduje się o ataku rok po tym, jak ktoś siedzi w ich organizacji i zasobach. A to jest to, przed czym chcielibyśmy się zabezpieczyć – jeżeli ktoś już u nas jest, żebyśmy takiego intruza mogli zobaczyć jak najszybciej, odizolować go i usunąć z naszej organizacji.

W takich atakach występuje utworzenie punktu kontroli, który będzie pozwalał na komunikację atakującego z naszymi zasobami. Rozwiązania takie jak Cloud Firewall czy Cloud IDS pomogą nam w wykryciu szkodliwego oprogramowania. Cloud Firewall wykorzystuje mechanizm wykrywania zagrożeń oparty na podpisach do blokowania ataków sieciowych i zapobiegania im. Tworząc właściwe zasady zapór sieciowych i wykrywania prób przejęcia, możemy w łatwy sposób odnaleźć i odizolować szkodnika kryjącego się w naszej sieci. Oczywiście, póki nie przejmie dostępu do antywirusa czy programów szpiegowskich i nie przejmie kontroli. Zagrożenia sieciowe oparte są na podstawie analizy pakietów. Cloud IDS wykorzystuje pakiet mirroring traffic, który może być bardzo kosztowny, dlatego Cloud IDS nie jest tanim rozwiązaniem. Powoduje to, że podczas przechodzenia danych między konkretnymi elementami sieci, Cloud IDS będzie te dane zbierał, tworzył kopie tych danych i analizował u siebie, sprawdzając, czy czasem coś nie jest nie tak, jak powinno być. Cloud Firewall też może być czasem kłopotliwy, dlatego że zawsze trzeba pamiętać, żeby reguły były dostosowane do tego, w jaki sposób ruch ma się odbywać między konkretnymi elementami. Tutaj dalej widzimy, że dzięki sondzie IDS możemy wszystkie nasze znaleziska związane z pakiet mirroringiem od razu przesyłać do Cloud Logging, do Security Command Center, do SIEM-a, SOAR-a lub do Chronicle.

Okej, porozmawiajmy sobie trochę o monitorowaniu, jeżeli chodzi o role, które przyznajemy w naszej organizacji. Przydatnym narzędziem podczas monitorowania jest Policy Analyzer. Dzięki niemu możemy dowiedzieć się wielu informacji dotyczących naszej organizacji, na przykład: kto może przyjmować tożsamość konta usługi, kto może zmieniać reguły zapory sieciowej w moim projekcie. Za pomocą takich lub niestandardowych zapytań możemy lepiej zrozumieć i zoptymalizować ustawienia wewnątrz naszej organizacji. Jeżeli wiemy, że ktoś ma duże dostępy na poziomie powiedzmy folderu, możemy być lepiej przygotowani na to, że jeżeli nasze zaufanie zawiedzie lub ktoś przejmie klucz do konta serwisowego, to z jakimi zagrożeniami możemy się mierzyć. Dlatego właśnie tak ważna jest zasada najmniejszego przywileju.

Dalej ważne, by pamiętać o kilku ważnych zagrożeniach związanych z dostępem. Mamy role podstawowe i predefiniowane. Obie te role nie są czymś, co jest najbardziej polecane przez Google Cloud jako docelowe. Role podstawowe są wręcz zagrożeniem niż pomocą, dlatego że zawierają bardzo dużą ilość uprawnień. Takie role podstawowe to właśnie Viewer, Editor i Owner – one są niezgodne z zasadą najmniejszego uprzywilejowania. Predefiniowane to są takie role gotowe na poszczególne zasoby chmurowe, na przykład na App Engine, na zarządzanie VM-kami, na zarządzanie Kubernetesem. Jest bardzo dużo takich ról przygotowanych przez Google, żeby zajmować się konkretnymi usługami, jednak te role nie powinny być rozdawane każdemu i domyślnie, dlatego że bardzo często lepiej stworzyć grupę z przygotowanym zestawem ról niestandardowych do określonego zadania i potem takie role usunąć. Jeżeli ktoś ma mieć ciągły dostęp, można się pokusić właśnie o te role predefiniowane. Warto pamiętać, że podczas wykorzystania ról niestandardowych, jeżeli wymogi dla konkretnej usługi się zmienią, to musimy my nadążać z naszymi rolami i też je odpowiednio dopasować, jeżeli chcemy, żeby ktoś dalej mógł wykonywać działania.

Trzecie zagrożenie to zabezpieczenie kont własnych użytkowników. Warto pamiętać, że nasi użytkownicy są podatni na phishing i wyłudzenia danych logowania, a najbezpieczniejszym sposobem jest określenie czasu możliwego do logowania, czasu sesji oraz zabezpieczenie kluczem fizycznym. Tylko klucze fizyczne FIDO2 umożliwiają zabezpieczenie się w pełni przed phishingiem. Jeszcze jednym problemem może być przyznawanie dostępu publicznego za pomocą „allUsers”. „allUsers” umożliwia dostęp do naszych zasobów każdej ciekawskiej osobie z internetu lub każdej osobie, która ma prywatne konto Gmail.

 

Podsumowanie narzędzi Google

 

Dobrze, podsumujmy sobie ten zestaw narzędzi Google, który został tutaj przedstawiony. Oczywiście tych narzędzi jest jeszcze więcej, dlatego serdecznie zachęcam do poznania całego zestawu, żeby każdy mógł dopasować to, co potrzebuje, do konkretnego problemu.

• Okej, mamy pierwszy: Identity and Access Management – zwiększa bezpieczeństwo przez precyzyjną kontrolę dostępu, co minimalizuje ryzyko nieautoryzowanego dostępu i zapewnia ochronę przed naruszeniem bezpieczeństwa. Z tego będziemy korzystać wszyscy i zawsze, jest to element ochrony wykorzystywany przez inżynierów.
• Cloud Resource Manager – zapewnia centralizację zarządzania zasobami chmurowymi przez hierarchiczną strukturę projektów. Dzięki niemu możemy dobrze podzielić infrastrukturę na projekty i foldery tak, żeby przekazywać konkretne uprawnienia tylko na odpowiednim poziomie.
• Web Security Scanner – służy do wykrywania podatności i problemów związanych z atakami webowymi. Jeżeli mamy jakąś aplikację na protokole HTTPS, stronę internetową, i chcielibyśmy wiedzieć, czy jest bezpieczna, możemy to wykorzystać. Oczywiście takich narzędzi oprócz tego skanera można znaleźć dużo na GitHubie, ale z doświadczenia wiem, że ten od Google będzie bardzo dobrym wyborem na początek.
• Key Management Service (KMS) – zapewnia zarządzanie kluczami szyfrowania w sposób bezpieczny i skalowany, co umożliwia szyfrowanie danych oraz kontrolę dostępu do kluczy.
• Security Command Center (SCC) – zapewnia monitorowanie i zarządzanie dostępem w chmurze. To bardzo potężne narzędzie, ma wiele elementów i niestety nie wystarczy nam czasu na wszystkie w trakcie webinaru, dlatego zachęcam do dokumentacji. Podsumowując: SCC dla każdej sfery zasobów ma swój własny element, np. dla Kubernetesa czy polityk dostępu.
• BeyondCorp Enterprise – architektura bezpieczeństwa, która zamienia tradycyjne ustawienia sieciowe na rzecz uwierzytelnienia opartego na kontekście użytkownika. Przenosimy zabezpieczenia z parametru sieci (czy IP jest bezpieczne czy nie) do warunku, czy użytkownik spełnia określony zestaw wymagań.
• Data Loss Prevention (DLP) API – umożliwia automatyczne wykrywanie i zapobieganie wyciekom danych przez analizę i klasyfikację informacji. Jeżeli posiadacie dane poufne, personalne czy karty kredytowe, warto wykorzystać DLP do przeskanowania infrastruktury.
• Identity-Aware Proxy (IAP) – usługa pozwalająca na bezpieczny dostęp do zasobów chmurowych oparty na tożsamości i kontekście użytkownika.
• 2-Step Verification Enforcement – opcja, która wymusi na użytkownikach wykorzystanie klucza bezpieczeństwa do logowania. Jest to bardzo polecane dla kont adminów i super-adminów.
• Cloud Armor – usługa zapewniająca zabezpieczenie aplikacji przed atakami typu DoS/DDoS oraz botami.

 

Audyt bezpieczeństwa

 

Dalej kilka słów o audycie bezpieczeństwa. Czym jest audyt bezpieczeństwa Google Cloud? Metody wykorzystane przez Google i FOTC służą do lepszego sprawdzenia, dogłębnej analizy zagrożeń związanych z brakiem najlepszych praktyk. Jeżeli ktoś z was posiada chmurę, stworzymy analizę i ocenę, przekażemy rekomendacje: czy są problemy z błędną konfiguracją, jakie wskazówki wdrożyć, jak zmniejszyć ryzyko wycieku danych. Robimy to dla wszystkiego, co tylko znajdziemy. W jaki sposób znajdujemy te problemy? Najpierw tworzymy automatyczny eksport danych z Google Cloud, potem tworzymy raport oraz przegląd – czyli oprócz automatycznego zbierania danych, rozmawiamy też z klientem, żeby lepiej zrozumieć jego infrastrukturę i sposób zabezpieczania środowiska. Na koniec dajemy podsumowanie. Jakie są korzyści? Wiedza o właściwej konfiguracji, przejrzysty plan poprawy sytuacji, lepsza adopcja usług security i zdobycie wiedzy przez wasz zespół. Oprócz audytu Google Cloud mamy też audyt bezpieczeństwa Google Workspace: zbieranie danych, automatyczny eksport i warsztaty. Umożliwia on analizę ponad 150 punktów ryzyka w kluczowych obszarach Workspace. Będziemy sprawdzać instancje pod kątem wycieków, cyberataków i nieuczciwych działań pracowników.

 

Sesja Q&A

 

Okej, sesja Q&A. Jakieś pytania?

Dziękuję, Tomaszu. Ogólnie temat jest bardzo szeroki i często jest tak, że jeżeli ktoś pracuje z Googlem, to nie robi wszystkiego sam. Są ekipy od monitorowania, od zabezpieczania konkretnych usług. Bardzo ważne jest, żeby wybrać jakąś usługę, przeczytać dokumentację od deski do deski i kierować się w konkretną stronę, zależnie od potrzeb organizacji. Jak widać, usług jest bardzo dużo.

Pytanie o GTM Server-Side – czy do tych rozwiązań powinnismy dokonać zabezpieczeń? Jeśli tak, to jakich? Chodzi o poszczególne datasety czy o BigQuery jako całość? Bo jeżeli do BigQuery jako całości, może powinieneś rozważyć bardziej granulowany dostęp do datasetów. O tak, tak, o to chodzi właśnie – pracując na BigQuery lepiej nie dawać dostępu do całości, tylko do konkretnych zbiorów danych. Chyba że będziesz wykorzystywał jedynie konto serwisowe do łączenia query. Jeżeli robisz to na poziomie aplikacji, a nie użytkowników, to musisz sobie odpowiedzieć na to pytanie samemu, zależnie od tego, jakie dane będziesz przetwarzał.

Okej, to ja mam pytanie do was: czy mieliście kiedykolwiek jakiś problem związany z bezpieczeństwem w waszej organizacji? Oczywiście nie musicie mówić szczegółów, ale jakie to były problemy? Moje pytanie brzmi: czy mieliście problemy z bezpieczeństwem chmurowym, niekoniecznie googlowym? Bo rozumiem, że dużo osób dopiero zaczyna poznawanie. Może potrzebowalibyście pomocy? Jako FOTC jesteśmy gotowi pomóc, ale chciałbym się dowiedzieć, w jaki sposób wy zabezpieczacie swoje infrastruktury sieciowe.

Okej, rozumiem, nie ma więcej pytań… a, ktoś pisze. Mam pytanie, jak wykorzystać na maksa możliwości BigQuery? Przede wszystkim trzeba być ostrożnym z myślą, że można tam przetrzymywać wszystkie dane – BigQuery to nie jest Data Storage, to nie jest miejsce do przetrzymywania danych, tylko do ich analizy. To, w jaki sposób BigQuery nam odpowie, zależy od tego, jak przygotujemy zapytanie. Możemy stworzyć dużą optymalizację kosztów, jeżeli wykorzystujemy właściwe optymalizacje tabel, filtry, konkretne części tabel. Na YouTubie są nawet trzygodzinne tutoriale z BigQuery, które umożliwią lepsze zrozumienie usługi. Ktoś pisze, że w przypadku fizycznym był problem z użyciem konta współpracowników – czyli bardzo łatwo można było się nabrać. Tak, najczęściej przestępcy idą po najniższej linii oporu i hakują najbardziej podatne elementy, czyli nas – ludzi.

Okej, bardzo wszystkim dziękuję za udział. Mam nadzieję, że się podobało, minęła już prawie godzinka. Dajcie znać, jakie tematy chcielibyście usłyszeć, na przykład zgłębić wszystkie możliwości Security Command Center. Jeśli tak, z chęcią przygotuję kolejne spotkanie. Bardzo dziękuję i życzę udanego dnia. Trzymajcie się!