Jak zadbać o bezpieczeństwo w dobie masowych ataków? – Artur Kuliński

Pewnie znacie powiedzenie: "bezpieczeństwo przede wszystkim", ale czy nie zapominamy o nim w cyberprzestrzeni? Dzisiaj przyjrzymy się tematowi Security, rozwiązań Google Cloud.

Subskrybuj, by być na bieżąco z kolejnymi odcinkami, a dzisiaj witamy już naszego eksperta.

Cześć, cześć.

Gościmy dzisiaj Artura Kulińskiego, Security Specialist Google Cloud. Bardzo gorąco witam Cię po drugiej stronie.

Cześć, dzięki za zaproszenie.

20 lat w IT, tak mega krótko, podsumowując Twój wielki dorobek w roli architekta, dewelopera, menadżera. Od 2 lat. Jesteś w Google, w kwietniu stuknie Ci trzeci rok. Pytanie, jak wspominasz ten okres i dlaczego minęło to wszystko tak szybko?

Okres był przedziwny, dlatego że jak rozpocząłem pracę w Google, zamiast w biurowcu przy Emilii Plater, znalazłem się na swojej działce w środku lasu, z grubsza odcięty od świata, z łańcuchami dostaw, które się załamały, gdzie przesłanie czegokolwiek, laptopa, klucza security, wszystko było wielkim wyzwaniem, a swoich nowych kolegów i koleżanki z pracy zobaczyłem chyba mniej więcej po roku, więc było to na pewno najbardziej bombowe rozpoczęcie pracy, jakie chyba pamiętam w swojej karierze.

Grubo! Rozumiem, że cieszyłeś się na ten moment, kiedy mogłeś już zdecydować, czy czasem zdalnie, czy raczej z biura, ale czy to dla ciebie też jest pewien element, powiedzmy, bezpieczeństwa? No bo jak pracuje się z działki i mówi się o security dużego ekosystemu, to trzeba sobie chyba w głowie poukładać.

To było dość niesamowite, właśnie z perspektywy bezpieczeństwa. Właściwie nie zauważyłem żadnej różnicy w kwestii onboard'owania w kwestii pracy przy takiej pracy w modelu zupełnie zdalnym, czy później powrotu do biura, wszystko po prostu działało. Nie wykonywałem żadnych specjalnych kroków związanych z przystosowaniem się do pracy zdalnej. Później dotarło do mnie, że tak naprawdę właśnie Google i jego podejście do wdrożenia Zero Trust'a, który teraz jest chyba najpopularniejszym buzzword'em w security zaraz obok XDR'a, ale właśnie wdrożenie Zero Trust'a, takie pełne wdrożenie podparte bardzo dobrymi narzędziami spowodowało, że właściwie można było wyjść z biura, przenieść się gdziekolwiek i rozpocząć normalną pracę i tak samo działa to właściwie, gdy podróżuję do innych biur, do innych lokalizacji, czy gdy wchodzę do kafejki internetowej. Ja po prostu zaczynam pracę, nie muszę się szczególnie mocno zastanawiać, czy odpalę VPN'a, czy nie odpalę VPN'a, czy jestem w sieci zaufanej, czy w sieci niezaufanej, po prostu nie ma już sieci zaufanych.

O!

Zero Trust, nie ufamy, ponieważ nie ma czegoś takiego jak sieć zaufana, bo czy sieć w domu na moim routerze Wi-Fi jest bardziej zaufana niż sieć popularnej sieci kawiarni? No może mi się tak wydawać, ale będzie to naiwne myślenie. Więc po prostu siadam, uruchamiam Zero Trust'a, Chrome przede wszystkim dba o to, żeby każdy mój request był uwierzytelniony, a następnie zautoryzowany bazując na całym zestawie atrybutów: skąd się łączę, w jakich godzinach, z jakiego urządzenia i do jakich zasobów. Dopiero wtedy jest stosowany odpowiednio dopasowany mechanizm uwierzytelnienia, dodatkowe sprawdzenia, drugi, twardy składnik. Jak wiecie, znaczy jak wiesz i jak wiedzą pewnie słuchający podcast, w Google 100% pracowników posiada klucze sprzętowe FIDO2, nasze tytany, po prostu bez tego nie pracujesz w Google'u.

Dojdziemy sobie do cyfr, jak to wpłynęło na poprawę bezpieczeństwa i jakie są dobre praktyki, co...

Cyfra jest bardzo prosta, od momentu wdrożenia tytanów 0 przypadków kradzieży tożsamości w Google'u i miejmy nadzieję, że tak pozostanie.

Zanim to wszystko, najpierw wjedzie data. Data: pierwszy dzień czerwca 2022, Dzień Dziecka, przynajmniej w Polsce, zanotowano największy atak DDoS w historii, jak na razie historii świata, który po pierwsze został odparty, w szczytowym momencie generował 46 000 000 zapytań na sekundę, poprzedni chyba był nawet o 76% mniejszy, więc jakby skala naprawdę niesamowita. Czy mógłbyś opowiedzieć trochę więcej, czy było ci dane śledzić to wszystko i analizować? Bo rozumiem, że ta sytuacja prawdopodobnie będzie miała miejsce i czy możemy skupić się i zmierzać w stronę tego, czemu zawdzięczamy odparty atak, czyli Cloud Armor?

Tak, oczywiście.

Puszka Pandory, czuję, że puszka Pandory to była.

Oczywiście, oczywiście muszę się zastanowić, bo tak, oczywiście śledziliśmy to można powiedzieć, że na bieżąco. Mieliśmy też okazję zobaczyć trochę więcej, nazwijmy to, niż ci, którzy są na zewnątrz. Nie wiem, jak dużo tutaj mogę powiedzieć, natomiast czemu zawdzięczamy? Przede wszystkim trzeba zachować pokorę. 46 000 000 w czerwcu, nie wiemy, ile będzie jutro, obroniliśmy się, super, natomiast to jest ciągły wyścig, to jest ciągły wyścig. Super, kiedy jesteśmy na czele tego wyścigu i oby tak pozostało, oczywiście nie mówię tutaj o konkurencji, czy o innych dostawcach podobnych usług, myślę tutaj o wyścigu z tymi, którzy chcą nam zaszkodzić i można powiedzieć chcą nam wszystkim zaszkodzić. Cloud Armor ustał, oczywiście jest to związane z naszym podejściem do budowania i skalowalności usług. Jest to związane z tym, że zarówno Google Cloud, jak i inne usługi Google'a, które znają konsumenci, są chronione przez warstwę, która nazywa się Google Front End. Ta warstwa jest odpowiedzialna między nimi za rozpraszanie ataków wolumetrycznych i oczywiście pod spodem stoi ogromna, automatycznie skalowalna infrastruktura, no i niesamowite zespoły zarówno rozwijające te usługi, jak i zespoły SRE, czyli naszych site reliability inżynierów, które to utrzymują i dbają o to, żeby to działało dokładnie tak, jak tego się spodziewamy. W tym tkwi tak naprawdę tajemnica. Oczywiście też przepustowość naszego networkingu, jak pewnie wiesz, operujemy jedną z największych sieci światłowodowych globalnych, pewne rzeczy po prostu dzięki temu możemy, że tak powiem, opędzić, na pewno pomaga nam tutaj efekt w skali. Kluczowe jest to, żeby mieć świadomość, że takie ataki są. Takie ataki nie są też związane z tym, że ktoś się po prostu brzydko bawi, te ataki mają swój cel. Jest to cel albo motywowany finansowo, albo niestety bardzo często jest to cel motywowany też politycznie, bo ataki DDoS są wykorzystywane w celu cenzurowania, w celu odcinania, są częścią po prostu cyberwojen, tak więc warto o tym pamiętać, warto się zabezpieczać, warto pamiętać o takich programach jak np. nasz Project Shield i zastanowić się, czy nie jesteśmy organizacją, która jest narażona po prostu tego typu atak. Szczęśliwie, jak obserwuję nasz rynek, to świadomość, zwłaszcza wśród tych dużych, kluczowych dla naszej gospodarki firm, jest bardzo duża i każdy posiada właściwie jakiś mechanizm zabezpieczania przed atakami wolumetrycznymi... I super!

Chodzi po prostu o wolumen zapytań, w tym przypadku DDoS to były zaszyfrowane zapytania https, jeśli mówiąc językiem zwykłego śmiertelnika, czy można to po prostu sprowadzić do tego, że te 46 000 000 request'ów, zapytań na sekundę sprowadza się do ilości zapytań, które musielibyśmy jako globalna marka obsłużyć w przeciągu całego dnia, a to dzieje się na przestrzeni sekund i to zabija infrastrukturę także fizyczną?

Po prostu taka symulacja wielkiego sukcesu biznesowego nagle na naszą stronę, którą do tej pory odwiedzało, powiedzmy, kilkanaście, kilkadziesiąt, kilkaset osób w ciągu sekundy, nagle próbuje wejść 46 000 000 ludzi na sekundę. Każdy pojedyncze żądanie obsługi pochłania jakieś zasoby, prawda? Gdzieś są jakieś serwery, które muszą tam tą stronkę wygenerować, jeszcze teraz bardzo często są to strony dynamiczne, za takim żądaniem jest żądanie do backend'ów, czyli do bazy danych, do aplikacji, które mają wygenerować, do licznych API, mikro serwisów. Każde z takich wywołań potrafi pociągnąć za sobą konsumpcję jakichś zasobów w postaci w szczególności procesora, więc jeżeli teraz jesteśmy przygotowani na obsługę, powiedzmy, 100 zapytań na sekundę, a dostaniemy 46 000 000, możemy zakładać, że raczej nasza infrastruktura tego nie udźwignie i raczej musimy spodziewać się tego, że się złożymy lub będziemy musieli się złożyć, żeby np. zabezpieczyć się przed rosnącymi kosztami obsługi takiego ataku.

Czy te ataki ze względu na to, że teoretycznie jest to zwykłe zapytanie do infrastruktury, którą stworzyliśmy, czy one dlatego są trudne do wykrycia w początkowej fazie i dlatego to jest przewaga Cloud Armor, że sobie z tym radzi? Bo to teoretycznie nie odbiega od peak'u grudniowego, tylko zwielokrotnionego. Możemy tak to przyrównać, czy...?

Tak, tak, możemy to tak przyrównać. Ten ruch, co do jego jakości, nazwijmy to, jest właściwie nie do odróżnienia od ruchu normalnego, ruchu klienckiego, dlatego też np. w Cloud Armorze mamy dostępne mechanizmy takiej ochrony adaptacyjnej, która po prostu patrzy sobie, jak wygląda taki normalny, nazwijmy to, tzw. baseline, czyli normalny ruch, który przychodzi do chronionego zasobu, czyli np. do chronionej strony internetowej. Znamy taki baseline, znamy też jakieś wzorce, no bo oczywiście my obserwujemy, akurat w przypadku Google Cloud mamy dosyć szerokie, że tak powiem, spojrzenie na to, co się dzieje w szeroko rozumianym internecie. Widzimy, jak wyglądają wzorce takich ataków, widzimy jak wygląda np. narastanie tego ruchu, widzimy jak wyglądają typowe źródła takich ataków. Składając to wszystko do kupy jesteśmy w stanie powiedzieć, że ok, mamy prawdopodobnie do czynienia z atakiem DDOS i rozpocząć działania remedy, zareagować na takie zdarzenie. Najczęściej, niestety, jeżeli będziemy czekać na to, aż zorientujemy się i zastosujemy ręcznie jakieś reguły, no bo oczywiście, odfiltrowanie takiego złego ruchu jest też możliwe po prostu przez modyfikację konfiguracji urządzeń sieciowych i zadziałanie w taki sposób manualny. Niestety, jak się domyślasz, przy poziomie typu 46 000 000 request'ów na sekundę, jeżeli będziemy próbowali coś robić ręcznie, to raczej nie zdążymy, tak? Umówmy się, raczej nie zdążymy, nasza architektura, nasza infrastruktura klęknie. Natomiast mając do dyspozycji tego typu narzędzia jak Cloud Armor możemy bazować na regułach adaptacyjnych, możemy jej automatycznie zastosować i obronić się przed takim atakiem.

Czy Cloud Armor jest domyślnym rozwiązaniem i taką dobrą praktyką zalecaną przez Google, czy to jest raczej coś, co użytkownik powinien wdrożyć we własnym zakresie, ponieść tego jakiś dodatkowy koszt, z czym wiąże się w ogóle zabezpieczenie tą usługą?

Jeżeli tutaj mówimy, nie chciałbym bardzo głęboko wnikać w specyfikę usług. Tak jak wspominałem, przed naszymi usługami zarówno tymi konsumenckimi, jak i usługami Google Cloud znajduje się ta warstwa Google Front End. Ta warstwa, jak gdyby sama w sobie potrafi rozpraszać, pochłaniać, jak byśmy tego nie nazwali, pewne typy ataków wolumetrycznych dając już pierwszy element ochrony. Oczywiście, warunkiem jest to, że do naszych zasobów np. wystawianych z Clouda wchodzimy przez global load balancing. Nie jest np. tak, że mamy zostawione dedykowane łącze, cały ruch internetowy przechodzi przez naszą premise, a my sobie to puszczamy później do zasobów na Google Cloudzie, no bo tą drogą niekoniecznie jesteśmy w stanie już zobaczyć po prostu, że taki atak ma miejsce. Natomiast jedna, pierwsza, jak gdyby warstwa, to jest właściwie Google Front End, następnie istnieje możliwość włączenia usługi Cloud Armor, która jest usługą płatną. Jeżeli udostępniamy zasoby właśnie przez Google'owy load balancing możemy włączyć Cloud Armor, którego jedną z funkcjonalności będzie ochrona przed atakami typu DDoS, ale nie tylko. Tam w tej chwili jest także integracja, możliwość tworzenia własnych reguł, filtrowanie list adresowych z adresów, które są podejrzane, nazwijmy to, możliwość integracji z ochroną przed botami, znaną zresztą wszystkim reCAPTCHA, więc wiele, wiele, wiele innych funkcjonalności, nie jest to tylko ochrona DDoS. Pojawia się po prostu dodatkowy element ochrony DDOS przed dodatkowymi typami ataku wolumetrycznych.

Kiedy mówimy o tego typu atakach, to zazwyczaj co za nimi stoi? To znaczy czy to stoi wspomniany bot, a w zasadzie botnet, sieć rozproszona komputerów zainfekowanych tworzących sieć zdolną do wspólnego działania, wspólnego ataku, skąd płynie ten ruch?

Jedna rzecz to są to są botnety, druga rzecz jest taka, że oczywiście wszelkie aktywności, nazwijmy to, cyberprzestępcze, to będą się koncentrowały tam, gdzie jest po prostu bardzo niskie prawdopodobieństwo penalizacji za tego typu aktywność. Przeprowadzania ataków DDoS w tej chwili to nie jest tak, że to grupa aktywistów, tak jak czasami są przedstawiani na filmach, w czarnych bluzach z kapturami, siada gdzieś po prostu w jakimś kontenerze...

Na pustyni.

Albo na pustyni. I zaczyna takie zabawy. Niestety, cyberprzestępstwo jest potężnym biznesem w tej chwili. Tego typu ataki DDoS są po prostu produktem, który można kupić na czarnym rynku cyberprzestępczym. I tak, są po prostu operatorzy sieci botnetowych, są to różnego typu zasoby, zdajesz sobie sprawy, ile jest zasobów typu kamerki, różnego typu urządzenia, urządzenia sieciowe, routery w domach. Te wszystkie urządzenia mają procesory, te wszystkie urządzenia są de facto komputerami. Bardzo często gdzieś tam siedzi jakieś osadzony linux, do którego tak naprawdę w ten czy inny sposób można się dostać. Niestety, wraz z rosnącą liczb tych urządzenia budowanie takich sieci botnetowych jest łatwe. Do tego trzeba dodać umiejętności, niestety, czasami bardzo wyrafinowane umiejętności, np. tak jak my budujemy mechanizmy ochrony adaptacyjnej po stronie Claud Armore, tak po drugiej stronie wiedza na temat maszyny learningowei AI jest wykorzystywana do tego, żeby budować po prostu procedury ataku, które są tak wyrafinowane, że po prostu oszukiwać tego typu mechanizmy obronne, jakie są budowane po stronie tych, którzy przed atakami DDoS bronią, tak, żeby unikać wzorców, tak, żeby mylić te algorytmy, które mają ataki wykrywać. W tym momencie jest to duży problem, tak jak mówię, ciągły wyścig, tak, postęp obydwu stronach.

To skoro to nie jest taki obrazek jak z filmu akcji, jeśli chodzi o zaplecze, powiedzmy, organizacji takich ataków, to czy filmem akcji jest praca w security po tej dobrej stronie, czy czasem sprowadza się to do dramatycznych wyścigów szukania ludzi po piętrach, czy raczej jest to żmudne przeglądanie logów, incydentów, które już miały miejsce?

Wyrywanie kabli i..?

[śmiech] Na przykład. Słuchaj, jak to się może zmieniło, jak to wygląda obecnie?

Wiesz, ja ogólnie...

Wyglądasz na zrelaksowanego człowieka bardzo, więc...

W swojej karierze nie zaliczyłem epizodu pracy takiej w socku, prawda, na pierwszej linii. Zakładam, że w wielu momentach to jest praca, w której adrenalina bardzo skacze i zaczyna to przypominać trochę film akcji. To jest trochę praca taka, jak w każdym innym centrum monitorowania, gdzie po prostu mogą się wydarzyć sytuacje odbiegające od normy, które wymagają po prostu reakcji. Niestety, w dużej mierze jest to żmudna praca polegająca na analizowaniu logów i nie jest bardzo częstym przypadek łapania tzw., prawda, włamywacza z rękami na klawiaturze, jest to niestety bardzo dużo false positive'ów, czyli sytuacji, w których pojawiają się. To jest jeden z elementów, w których właśnie bardzo, bardzo dużo energii poświęca się na to, żeby wyeliminować te false positivy, one są bardzo niebezpieczne, nie tylko ze względu na to, że pochłaniają czas i odrywają, jak gdyby tych, którzy się powinni zająć prawdziwymi problemami, ale też powodują duży poziom zmęczenia, frustracji, są bardzo negatywnym generalnie zjawiskiem, prawda, ale nadal jest tego dużo. No, ale kiedy pojawi się taki rzeczywisty przypadek, kiedy mamy do czynienia z sytuacją ataku, to jest to pewnie trochę kino akcji. To, co my widzimy po naszej stronie, co zresztą też mamy zaimplementowane u siebie, bo bo jak domyślasz się, przy globalnej skali firmy, takiej jak Google, trudno sobie wyobrazić ogarnięcie kwestii związanej z wykrywaniem i reakcją do czynnika ludzkiego. Tutaj jest potężna automatyka, potężne nakłady na automatyzację wszystkiego, co da się zautomatyzować. To, co widzimy także poza Googlem, to jest bardzo duża konieczność, żeby jak najwięcej tych elementów związanych z sockiem automatyzować, dlatego że przy tak wzrastającej liczbie ataków, przy tak wzrastającym rozmiarze infrastruktury i komplikacji systemów, po prostu człowiek naprawdę powinien dotykać tylko tego, co wymaga rzeczywiście ludzkich cech i ludzkich umiejętności, jak najwięcej powinno podlegać automatyzacji.

To może wiąże się z moim kolejnym pytaniem/ co uważasz za większe wyzwanie, tak globalnie, rosnąca skala zagrożeń ataków, która potencjalnie może się wydarzyć, czy bardziej to, że brakuje rąk do pracy i brakuje specjalistów IT?

Nie wiem, czy można to rozpatrywać w kategorii, co jest większym ryzykiem. Na pewno jedno i drugie jest całkowicie ze sobą połączone. Na pewno dużym problemem jest to, że próg wejścia do obszaru hakowania, tak, czy zajmowania się szeroko rozumianą aktywnością hakerską, jest coraz niższy, tak. Coraz więcej gotowych narzędzi, coraz łatwiejszy dostęp do sieci, coraz łatwiejsze techniki ukrywania się, ogromne, komercyjne i open source'owe zestawy narzędzi, które mogą być użyte, tak jak każde narzędzie, prawda, w dobrym i złym celu. Z drugiej strony, dosyć wysoki próg wejścia, z drugiej strony, prawda, w obszar detekcji, w obszar reakcji, w obszary w obszary socka, trzeba jednak tutaj intuicji, doświadczenia, wiedzy, wszystkiego. Więc z jednej strony możemy mieć kogoś, kto nawet w ramach po prostu zabawy weźmie narzędzie i zacznie go używać, a z drugiej strony generuje to całkowicie poważną sytuację zagrożenia, więc to na pewno jest trochę niepokojące. Z drugiej strony, jest to jakiś chyba naturalny element rozwoju cywilizacji. Znaleźliśmy się w momencie, w którym musimy sobie zdać sprawę, że jest taki obszar, nad którego automatyzacją potrzebujemy się skupić, znaleźć nowe metody działania i nowe rozwiązania, bo to, co robiliśmy do tej pory, po prostu przestało wystarczać, tak.

Arturze, wybacz za taką dziennikarską pułapkę często obserwowaną w mediach, często po prostu formułuje się w ten sposób pytania: wybierz z dwóch powiązanych ze sobą rzeczy albo podziel świat na "my i oni", niestety mózg lubi takie porównania i cały świat mediów tworzy tego typu przekaz, który niestety najczęściej jest mylny, bo statystyka i liczby mówią co innego. Mam tylko jeszcze jedno pytanie, uprzedzam właśnie, że z puli takich mainstreamowych, bo z perspektywy klienta, takiego zwykłego użytkownika wszystko działa, sam też nie padłem jak dotąd ofiarą oszustwa na polu, o którym rozmawiamy, odpukać, oczywiście, w obudowę komputera, ale przecież mówi się teraz, że frontem także konfliktu w Ukrainie jest cyberprzestrzeń, dlaczego to jest prawdziwe stwierdzenie?

Dlatego, że obserwowaliśmy, np. jeżeli popatrzysz sobie na informacje zespołów zajmujących się analizą zagrożeń, np. takim zespołem jest nasz Tag, bardzo zresztą znanym zespołem monitorującym aktywność tych state sponsors, prawda, grup hakerskich, to widzieliśmy po prostu bardzo dużo przykładów, kiedy ataki w cyberprzestrzeni szły równocześnie z atakami konwencjonalnymi, były to ataki na infrastrukturę, były to ataki np. na organizacje niosące pomoc, były to ataki mając na celu wyłączenie funkcjonowania instytucji rządowych. Pole do popisu jest niestety bardzo szerokie. Wyobraź sobie np. sytuację, w której wystawiony jest formularz, gdzie osoby potrzebujące pomocy, uciekające z terenów objętych wojną mają się rejestrować w jakimś celu, wszystko jedno, ćwiczenie czysto teoretyczne. Zaatakowanie niezabezpieczonego, źle napisanego formularza jest niezwykle łatwe, technologicznie pociągnie być może duże koszty, zapchanie bazy danych, wyłączenie tego formularza w świecie fizycznym spowoduje to, że te osoby, które potrzebują pomocy, tej pomocy nie dostaną, a więc jest to efekt bardzo fizyczny, wymierny efekt w świecie rzeczywistym spowodowany działalnością w cyberprzestrzeni. Absolutnie jest to kolejny front. Bardzo ci gratuluję, że nie padłeś ofiarą i bardzo się cieszę, że nie padłeś ofiarą tego typu działalności, natomiast nie można tego lekceważyć. Ja niestety znam przypadki wśród rodziny, znajomych, gdzie miały miejsce przejęcia tożsamości, odcięcia dostępu do maila, gdzie w mailu bardzo często są informacje, takie jak różnego typu oświadczenia wykorzystywane czy w bankowości elektronicznej, czy w innych site'ach, które stanowią punkt wyjścia do dalszej eksploracji dla cyberprzestępcy. W wielu przypadkach, tak jak np. ataki phishingowe, które prowadzą do penetracji sieci korporacyjnych, czy do deck'ów ransomewarowych, bardzo często ofiara tego ataku nie ma świadomości, że tak naprawdę wpuściła do sieci korporacyjnej jakieś złośliwe oprogramowanie, nawet nie wie, że jest ofiarą takiego ataku i o to tak naprawdę przestępcy chodzi. Jeżeli popatrzymy sobie na takie targetowane ataki, poza tutaj ransomwarem, to taki średni czas w Europie, taki średni czas życia atakującego w sieci, zaatakowanej, skompromitowanej sieci do momentu wykrycia to jest nawet powyżej 40 dni, tak więc o to chodzi, trzeba po cichu wejść i zacząć się rozglądać, tak wygląda atak. Jeżeli on jest targetowany, jeżeli on szuka np. możliwości wykradzenia danych czy namierzenia szczególnie cennych assetów w sieci, w atakowanej sieci, to zależy nam, żeby jak najdłużej w tej sieci pozostać bez wykrycia, więc ten punkt wejścia on będzie cichy i celem jest to, żeby ofiara nie zauważyła, że taki atak miał miejsce, dlatego tak ważne jest ta czujność, nieklikanie tych linków, nieotwieranie podejrzanych załączników, zabezpieczenie stacji, posiadanie drugiego składnika. Silnego drugiego składnika na swoich kontach prywatnych.

Dużą przewagą już jest filtrowanie wiadomości w Gmailu, to już jest takie duże sito wstępne, no ale wiemy też, że metody są bardziej wysublimowane.

Nie każdy też używa Gmaila, rzeczywiście, muszę przyznać tutaj z nieukrywaną satysfakcją, że jeżeli ktoś używa Gmaila, to mogę powiedzieć, że troszeczkę spokojniejszy jestem w temacie samej zawartości tego, co przychodzi, bo tu rzeczywiście niesamowite nakłady, niesamowicie duża praca i innowacja w ochronę użytkowników jest wkładana. Nadal my możemy zrobić bardzo dużo, ale jeżeli użytkownik ma słabe credentiale, nie ma drugiego składnika, to w tej chwili już praktycznie to jest niemożliwe, ale nadal, jeżeli jest to po prostu słabe zabezpieczenie swojej tożsamości cyfrowej, to tutaj naprawdę momentami niewiele można zrobić.

Spotkałem się z nowym standardem FIDO, paski nowym rozwiązaniem, które może pozbawić nas haseł niejako?

Passwordless jest trendem, który jest obecny od bardzo dawno, więc ja z zainteresowaniem obserwuję i czekam z niecierpliwością na rozpowszechnienie i na wsparcie implementacyjne.

I w tym pojęciu zawierają się wszystkie fizyczne urządzenia służące do autentykacji, jak np. YubiKey'e?

Oczywiście tak, i też mam nadzieję, że jednak świadomość potrzeby chronienia tej swojej tożsamości cyfrowej spowoduje, że jednak przełamiemy się troszeczkę, jest troszeczkę niechęć do posiadania tego dodatkowego urządzenia, najczęściej dwóch, bo też konieczne jest posiadanie, nieutracenie dostępu do swojej zawartości przez utracenie po prostu klucza i te standardy się rozpowszechnią, jednak nikt nie ma takich zapędów, żeby pozbywać się kluczy do domu, prawda, to oczywiście wiadomo, że niektórzy mają zamki już na linie, ale jednak powszechnie staramy się mieć atestowane zamki o wysokiej skuteczności, więc mam nadzieję, że takiego podejścia nabierzemy też do zabezpieczania naszej tożsamości cyfrowej. Kluczowe jest tylko to, co zawsze powtarzam, że jak już mamy ten super zamek, mamy silne hasło, mamy klucz FIDO, to, żebyśmy nie zapomnieli zamknąć okna, prawda, czyli nie dali się sphishingować, albo nie nie wpuścili sobie malware'u, albo nie zostawili gdzieś np. w infrastrukturze cloudowej publicznie udostępnionych zasobów, czy po prostu niekontrolowanej konfiguracji.

To już jest standard w Chromie od wersji stabilnej chyba 108, polecamy sprawdzić paski. Natomiast teraz, czy możemy przejść trochę do już konkretnych rozwiązań? Nie wiem, to jest trochę pytanie, które pojawi się w dalszym toku, czy tutaj bezserwerowe technologie i usługi mogą być punktem wyjścia dla osób, które wymagają może wysokiego poziomu bezpieczeństwa, ale mniejszego progu wejścia? Natomiast, czy możemy w ogóle zacząć od komponentów bezpieczeństwa Google Cloud? Bo mamy tutaj Cloud Armor jako osobną usługę, mamy tutaj szyfrowanie praktycznie na każdym poziomie. Czy możesz na chwilę jakby wejść też w te niższe i niewidoczne warstwy i powiedzieć nam, jak wygląda w ogóle kwestia szyfrowania chmury? Wiem, że temat jest szalenie rozległy, natomiast czy możesz pokrótce opowiedzieć o tym, czego nie widać, ale czego możemy potencjalnie się spodziewać, jak nasze dane są chronione?

Właściwie tak, większość rzeczy, których nie widać, a których możemy się spodziewać, są opisane w dokumentacji, są dostępne dla użytkowników Clouda. Chyba podejście, standardowe podejście Google i właściwie każdej dojrzałej pod kątem security firmy to nie jest security by obscurity, tylko wręcz przeciwnie, prawda. Każdy powinien wiedzieć, czego i z jakich rozwiązań korzysta, staramy się jak najwięcej informacji udostępniać, ale wiadomo, że nie każdy wnika wystarczająco głęboko, żeby znać szczegóły tych implementacji. To, co jest kluczowe, i co właściwie też już jest standardem takiego dojrzałego designu, jest secure by design, defense in debt i tego typu pojęcia związane z samym podejściem do projektowania i realizacji usług, czyli nie robimy tak, że po prostu budujemy usługę, budujemy jej funkcjonalność biznesową, a potem zaczynamy myśleć: "a, to może by trzeba ją było jakoś zabezpieczyć", nie, czegoś takiego nie ma, to jest jedna rzecz. Druga rzecz jest taka, że z założenia nie wierzymy, że jakakolwiek pojedyncza warstwa ochrony jest w stanie zabezpieczyć nasze rozwiązania, prawda, to znane podejście w architekturze security, prawda, czyli fosa i mury vs. defense in debt, czyli przełamujemy mury i plądrujemy, prawda, plądrujemy zamczysko, zabieramy wszystko vs. fosa, mury, druga warstwa murów, barbakan...

Wilcze doły, zasieki.

Wilcze doły.

Soła.

Zasieki. Nie lubię tych militarnych porównań, ale są dosyć trafne, tak. To znaczy, że od najniższego poziomu, czy najwyższego, wszystko jedno, jak tutaj sobie to narysujemy, czyli zaczynamy od bezpiecznego designu data center. Tutaj polecam, jest na YouTubie taki filmik, nazywa się "Six layers deep", o ile dobrze pamiętam, i on pokazuje po prostu, jakie mechanizmy bezpieczeństwa stosujemy w fizycznej budowie naszych serwerowni, od bardzo, prawda, prostych zabezpieczeń przed wjazdem rozpędzonym samochodem, po jak gdyby monitorowanie poruszania się personelu po data center i wyszukiwaniu odstępów od, nazwijmy to, utartych ścieżek, czy pojawienia się ludzi w miejscach, w których nie powinni oni być, co automatycznie, prawda, wywoła jakąś tam reakcję. Są to bardzo zaawansowane też mechanizmy, wykorzystujemy dużo sztucznej inteligencji, dużo algorytmów zaawansowanych do tego, żeby to bezpieczeństwo fizyczne wzmacniać. Idąc wyżej, networking, w naszym wykonaniu networking to jest jest rozwiązanie całkowicie customowe, pierwsze takie, powiedzmy, komercyjne urządzenie, jakie można spotkać w naszym data center jest tam, gdzie dochodzi conectivity od strony, od klienta, tak. Po naszej stronie są to nasze rozwiązania, są to projektowane przez nas serwery. Już chyba, mam nadzieję, prawie każdy, kto się z bezpieczeństwem Google spotkał, wie, że na naszych płytach głównych jest chip Titan, że on zabezpiecza przed tym, żeby ktoś nie podmienił firmware'u, żeby od momentu włączenia serwera do prądu wszystko było pod pełną kontrolą, tak. Sprawdzamy firmware, sprawdzamy cyfrowy podpis tego firmware'u, jeżeli cokolwiek jest nie tak, serwer zostaje zawieszony, on się nie uruchomi, jeżeli podejrzewamy, że to może nie być nasz firmware, chociaż naprawdę przy takim procesie zabezpieczenia supply chainu, czyli, czyli łańcucha dostaw, jaki mamy, trudno mi sobie aż to wyobrazić, ale oczywiście ktoś zdecydował, że takie ryzyko jest realne, więc ono zostało zaadresowane. Idąc dalej, karty sieciowe, dwie karty sieciowe nie będą ze sobą rozmawiać w serwerowni Googla, jeżeli nie przedstawią się wzajemnie swoją tożsamością cyfrową, także realizowaną przez chipy Titan. Zresztą Titan został przez nas też opensourcowany, jest projekt open source Titan. W tej chwili można z niego korzystać. Ostatnio na konferencji, jednej z naszych tutaj konferencji, przedstawiciele Intela, o ile pamiętam, pokazywali rozwiązania, które na open Titanie są też używane do zabezpieczenia właśnie niższych warstw sprzętowych. Też mówiłem, networking, następnie proces wytwórczy, ataki na supply chain software'owy są w tej chwili bardzo gorącym tematem. U nas, można powiedzieć, od zawsze ten proces wytwarzania oprogramowania miał bardzo wysoki poziom bezpieczeństwa, od przeglądów kodu, po autoryzację binarną, która w tej chwili, jak wiesz, jest też dostępna dla klientów, to znaczy, że możemy, po pierwsze, nie tylko, że podpisać jak gdyby artefakty, które trafiają na serwery i są na serwerach uruchamiane, my możemy w całej ścieżce wytwórczej, prawda, ona ma wiele kroków, w każdym z tych kroków możemy przybić tzw. atestację, możemy przybić pieczątkę, że dany kawałek oprogramowania, który ma być uruchomiony, przeszedł dany kawałek tej ścieżki i na samym końcu, zanim to oprogramowanie zostanie uruchomione, to jest element, który potrafi skontrolować, czy to, co ma zostać uruchomione, przeszło całą ścieżkę, w szczególności, nie wiem, sprawdzanie podatności, testy security, testy funkcjonalne i dopiero, kiedy stwierdzimy, że pochodzenie tego oprogramowania, plus proces przez jaki przeszło nam odpowiada, dopiero wtedy mówimy okej, to może zostać uruchomione. To właściwie u Google działa tak od bardzo, bardzo dawna, żeby nie powiedzieć od zawsze. Nie wiem, co jeszcze. Tych elementów jest naprawdę bardzo dużo, tak. Mówiłeś o szyfrowaniu, wszystkie dane w GPS są szyfrowane, nie trzeba nic robić, nie trzeba nic włączać, nie trzeba nic konfigurować. Natomiast ze względu na to, że klienci mają różne wymagania, czasami związane z reżimem regulacyjnym, w którym żyją, compliancem, z tartanami wewnętrznymi, mogą mieć specyficzne potrzeby dotyczące np. sposobu zarządzania kluczem, no to dajemy też taką możliwość, żeby z tej pełnej automatyki szyfrowania przejść do tzw. customer managed encryption key, czy external managed encryption key, całkowitej eksternalizacji klucza, i to jest jak najbardziej możliwe. Szyfrujemy ruch sieciowy, ruch sieciowy pomiędzy naszymi data center szyfrujemy co najmniej w jednej warstwie, gdy tylko ten ruch opuszcza ściśle kontrolowany przez nas obszar fizyczny w ramach naszych regionów, w ramach naszych data center, także cały ruch jest szyfrowany i uwierzytelniany. Także tutaj nie ma jak gdyby miejsca na kompromis. Wiadomo, w Cloudzie działamy w modelu współdzielonej odpowiedzialności, no i my ten obszar naszej odpowiedzialności w obszarze security traktujemy bardzo, bardzo poważnie.

Myślę, że na przestrzeni lat firmie udało się zbudować tak duże globalne zaufanie, że teraz możemy na nim polegać. I teraz pytanie, po które usługi, i czy istnieją takie usługi, czy coś ci się klaruje, możemy sięgać jako mniej zaznajomieni z security użytkownicy chmury, Google Cloud, po to, by ten ciężar odpowiedzialności myślenia jakby przenieść na Was, bo ta praca, jak powiedziałeś, została już wykonana?

Myślę, że na przestrzeni lat firmie udało się zbudować tak duże globalne zaufanie, że teraz możemy na nim polegać. I teraz pytanie, po które usługi, i czy istnieją takie usługi, czy coś ci się klaruje, możemy sięgać jako mniej zaznajomieni z security użytkownicy chmury, Google Cloud, po to, by ten ciężar odpowiedzialności myślenia jakby przenieść na Was, bo ta praca, jak powiedziałeś, została już wykonana?

Nie.

Natomiast nie myślmy w naiwny sposób, że ja tu użyję jakiejś usługi chmurowej i będę miał spokój z security. To jest myślenie dosyć naiwne i niebezpieczne. Wykorzystywanie usług chmurowych nie jest metodą transferu ryzyka.

Kompletnie odpowiedziałeś na to pytanie. Chciałem je tylko rozszerzyć, czy w czasach, wiesz, globalizacji, świetnego dostępu do Internetu z niemal każdego miejsca świata, obecnie zwłaszcza, to już przestało mieć znaczenie, czy buduję biznes, buduję aplikację tylko i wyłącznie przeznaczoną na rynek Polski, czy to jest aplikacja globalna, czy te ryzyka przy modelowaniu będą różne, czy to w ogóle już przestało mieć znaczenie w zglobalizowanym świecie? Brałbyś to pod uwagę, że nie, buduję tylko polski startup, nie, buduję startup na cały świat?

Wchodzimy tutaj w obszar biznesowy, nie czuję się ekspertem biznesowym w obszarze startupów. Intuicja mi podpowiada, że gdybym budował w tej chwili rozwiązanie w tym świecie digital native, czyli w świecie startupów, technologie chmurowe są absolutnie oczywiste, można sobie powiedzieć. Na pewno nie ograniczałbym się do jednego rynku, nie pozwoliłbym przynajmniej, żeby założenie, że będę działał tylko na jednym rynku w istotny sposób wpłynęło na architekturę mojego rozwiązania, bo po co, prawda? Natomiast oczywiście są rzeczy, które trzeba wziąć pod uwagę, bo jeżeli buduję rozwiązanie, które z założenia ma być globalne, to wtedy będzie wymagało ono innego podejścia do architektury samego rozwiązania, do kwestii tego, co ma być rozproszone, prawda, gdzie mają być dane, w ilu lokalizacjach, kwestie wysokiej dostępności, czyli tzw. wymagania niefunkcjonalne. One oczywiście po trochę przełożą się też na kwestie modelowania zagrożeń, natomiast w obecnej chwili nie skomplikują one na tyle zagadnienia, żebym z założenia wprowadzał sobie ograniczenie: "a, moja aplikacja będzie działać tylko z regionu Google Cloud Europe Central 2", czyli Warszawa i nigdzie indziej, tak. Mogę tego chcieć, mogę wykorzystać mechanizmy kontrolne chmury, żeby wymusić to, żeby moje dane, moje rozwiązanie było tylko w tym regionie, ale to jest moja wola, moja konfiguracja, ale nie jest to ograniczenie technologiczne, w żaden sposób.

Wspomniałeś o regionie, bo to jest pytanie znowu bardzo otwarte i wiem, że może tricky, czy z otwarcia nowego regionu Google Cloud Warszawa płyną jakieś korzyści na polu security?

To jest ciekawa kwestia. Nie wiem, trudno mi powiedzieć, czy na polu, czy security. Nasze regiony są budowane w taki sam sposób. Z punktu widzenia klienta, który wykorzystuje bigwary czy Cloud Storage to czy skorzysta z niego w Warszawie, czy skorzysta z niego w Iowa, czy gdziekolwiek indziej, nie ma to różnice z perspektywy tego, jak ta usługa jest skonstruowana, zbudowana i zabezpieczona. Tak jak mówię, jego wymagania regulacyjne mogą dla niego nakładać konieczność ograniczenia lokalizacji danych do danego regionu, ale z perspektywy security nie ma to jakichś takich bardzo konkretnych..., wymiernego znaczenia. Natomiast tutaj wspomnę, że często, zanim region Google Clouda pojawił się w Polsce, bardzo często takie rozmowy, które zamykały trochę drogę do rozwiązań cloudowych, było pytanie: "a, czy moje dane mogą pozostać na terenie Polski?", albo: "czy moje rozwiązanie może pozostać na terenie Polski?", nie, nie ma jeszcze tutaj regionu, "a, to przykro mi", nie wchodząc w szczegóły, skąd nagle tego typu wymagania mogą się pojawiać, bo naprawdę nie ma zbyt wiele sytuacji, w których są tego typu twarde wymagania. Pojawienie się regionu w Warszawie nie spowodowało, że te rozwiązania i te dane pojawiły się w Warszawie, ale spowodowało, że nagle inne regiony europejskie stały się równie dostępne pod te rozwiązania, jak region w Warszawie, po prostu, ten argument z dyskusji zniknął, okazało się, że po prostu jednak chmura w Europie, chmura sprostająca europejskim regulacjom, compliance'owi jest równie dobra w Warszawie, jak i Finlandii, czy we Frankfurcie.

I właśnie z cyfrowego portu, czyli regionu Google Cloud Warszawa rozmawiał z nami dzisiaj Artur Kuliński, Security Specialist z Google Cloud. Bardzo dziękuję Ci za rozmowę i spotkanie.

Dzięki.

A my słyszymy się w kolejnym odcinku FlyTalks. Dzięki, że byliście z nami do samego końca.