Bezpieczeństwo chmury z perspektywy etycznego hakera

Słuchasz Fly Talks, podcastu o chmurze w biznesie. Dzisiaj będzie o tym, jak zabezpieczyć swój biznes, jak zadbać o chmurę, po jakie usługi sięgnąć, by minimalizować zagrożenia z zewnątrz, nie dopuszczać do incydentów wewnątrz organizacji? Nakreślimy, czym w ogóle zajmuje się szeroko rozumiana gałąź IT Security. Jak zadbać o bezpieczeństwo na etapie projektowania aplikacji? Czego oczekiwać od dostawcy chmury? Przyjrzymy się rozwiązaniom aplikacji bankowych i też jak zadbać o chmury bezpieczeństwa to też bardzo ważny court naszej rozmowy. To wszystko przed nami w rozmowie ze specjalistą IT Security Consultant firmy Securing. Łukasz Bobrek z nami. Cześć, powiedz, jak opowiadasz na starcie komuś o swojej pracy?

Cześć Konrad, cześć bardzo miło być mi tutaj na pokładzie i porozmawiać z Tobą o bezpieczeństwie, bo jest to sprawa ważna moim zdaniem. I wracając do twojego pytania to wiesz co? Zależy z kim rozmawiam. Jeżeli rozmawiam z takim zupełnym laikiem, to gdzieś na początku zazwyczaj zahaczam go o te tematy, które są dla niego bliskie, jak zarządzanie swoimi hasłami, dbanie o swoje bezpieczeństwo cyfrowe, o swoją tożsamość cyfrową. To są tematy na pewno, które w dzisiejszym świecie, każdy już gdzieś się z nimi styka i na pewno tutaj taki punkt zaczepienia można złapać. Oczywiście rozmawiając z osobami bardziej technicznymi, z deweloperami, ta rozmowa już ma zupełnie inny charakter. Wtedy bardziej rozmawiamy o rzeczach technicznych, które dotyczą ich pracy, jak to bezpieczeństwo można zwiększyć o to, żeby finalnie produkt, który, który tworzą, czy usługa, którą występują małe miała lepszą jakość.

Jak mówimy o bezpieczeństwie, to możemy trochę to rozróżnić na projektowanie tychże usług z uwzględnieniem dobrych praktyk bezpieczeństwa albo potem zarządzanie tymi usługami, tak by nadal były prowadzone bezpiecznie. Czym bardziej się zajmujesz od strony technicznej? Twoja profesja często ma taką wizję scenariusza filmu akcji, włamy, jakieś testy penetracyjne. Czy to też jest na twoim koncie? Możesz trochę poopowiadać jaka była droga do zostania seniorem w tej branży.

Właściwie to jest główna moja działalność. To jest to o czym mówiłeś, testy penetracyjne. Tutaj może przybliżę słuchaczom, jeżeli ktoś nie wie czym to jest. To są testy aplikacji, która została uruchomiona, czyli po tym całym procesie pisania kodu, aplikacja trafia finalnie do klientów, jest udostępniona, czy to jest aplikacja mobilna, webowa, czy jakakolwiek inna. W tym momencie przechodzimy my, czyli firma, która zajmuje się bezpieczeństwem i robi testy penetracyjne, czyli wciela się w rolę powiedzmy hakera czy kogoś, kto ma złe intencje i próbuje jakoś na warstwie technicznej wykonać coś w aplikacji, co nie powinno być możliwe. Oczywiście wynikiem tej akcji, którą chcemy zrobić, jest albo podniesienie jakiejś korzyści finansowej, albo uzyskania dostępu do danych innych klientów, czy też w ogóle zrobienie tak, żeby aplikacja nie działała dla nikogo. Te scenariusze ataków i cele, które chcemy uzyskać, są różne i oczywiście zależą od aplikacji, na której się skupiamy. Oczywiście też w świecie bezpieczeństwa od jakiegoś czasu jest taki mocny ruch, który nazywa się shift left, czyli ta cała nasza praca konsultacyjna, czy to wsparcie, jeżeli chodzi o bezpieczeństwo dla naszych klientów, staramy się przesunąć w tym całym procesie produkcji oprogramowania troszkę bardziej w lewo, czyli bliżej jego początku. Bo jesteśmy też teraz bardziej obecni na etapie planowania samego rozwiązania na etapie wyznaczenia architektury, na etapie jakichś wstępnych rozmów w ogóle, czym ta aplikacja ma się zajmować i jak to bezpieczeństwo w niej uwzględnić. Jeszcze tutaj zahaczając do chmury, która też jest tutaj ważnym teraz tematem. Oczywiście coraz więcej klientów, coraz więcej firm z niej korzysta, więc my oczywiście też staramy się pomóc, poprawić tak, żeby ta chmura była bezpieczna i to też się wpasowuje, w ten ruch shift left. Bo tutaj staramy się pomóc, w bezpiecznej konfiguracji chmury.

I to będzie ważne zagadnienie dzisiaj w odcinku Fly Talks podcastu o chmurze w biznesie. Zajmijmy się zatem początkiem firmy, początkiem biznesu. Wczesny etap projektowania startupu. Na co zwrócić uwagę, dobierając środowisko chmurowe korzystając z chmury publicznej ? Czy Google Cloud Platform ma jakąś przewagę na wczesnym etapie? Czy możesz przybliżyć właśnie to pod swoim kątem? To znaczy, jaki jest próg wejścia, na ile możemy zaufać, dajmy na to usługom bezpieczeństwa zawartym W GCP?

Dobra, odpowiem tak. Jeżeli chodzi o pierwsze Twoje pytanie, czyli od czego powinien taki startup zacząć, to powiedziałbym, że powinien bardzo precyzyjnie wyznaczyć sobie co on na tej chmurze chce robić i w jaki sposób to chce robić. Bo tutaj jakby największym problemem z chmurą tak naprawdę nie są takie problemy związane z bezpieczeństwem tych mechanizmów, które chmura oferuje. Oczywiście tam też się zdarzają problemy, ale są one jednak bardzo, bardzo rzadkie. Tutaj też możemy sobie porozmawiać o programie Google i to jest program, gdzie można taki problem zgłosić to do Google'a, on te problemy potem naprawia i też płaci całkiem fajne pieniądze za takie znaleziska, ale to już taka dygresja, do której może wrócimy.

Koniecznie.

Bo to nie jest tak, a niestety czasem takie myślenie też się zdarza, że jak korzystamy z chmury, to wszystko jest bezpieczne, bo chmura jest bezpieczna, więc generalnie nie musimy ciągle się martwić, będzie dobrze. Niestety tak nie jest. Korzystając z chmury musimy mieć świadomość, że jest tam coś takiego jak model, czyli pewne aspekty bezpieczeństwa są zapewniane przez dostawcę usługi chmurowej, ale część rzeczy jest tak naprawdę na naszych barkach i to my musimy zadbać o to na przykład, żeby pliki, które trzymamy na chmurze, nie były publiczne. Oczywiście część z nich może być publiczna. Taki może być nasz zamysł, ale też część plików może być prywatna, ale zdarzają się sytuacje, kiedy do jakichś ważnych biznesowych informacji czy do informacji osobowych klientów ten dostęp jest ustawiony albo przypadkiem, albo omyłkowo publicznie, ale oczywiście wtedy każdy może do takich danych uzyskać dostęp i oczywiście mamy problem. Takie sytuacje zdarzały się dla dużych firm, na przykład Fedex tak kiedyś udostępnił. Też Pfizer, jeżeli dobrze pamiętam, około pół roku temu udostępnił jakieś dane medyczne swoich prób klinicznych. Niestety takie, takie błędy zdarzają się one wynikają tylko i wyłącznie z błędów konfiguracyjnych. Tutaj jakby ciężko oczekiwać od dostawcy chmurowego, żeby on wiedział, które dane powinny być publiczne, a które nie. On gwarantuje, że jeżeli już mu powiemy, że te dane mają być prywatne, to on faktycznie dobrze zadba o ich bezpieczeństwo. Ale jeżeli to jest nasza decyzja jako firmy, że coś jest publiczne, to publiczne będzie, tak?

To tak jakby zabezpieczyć swój dom w fantastyczne drzwi, ale jednak zapomnieć o dajmy na to podwójnym regulowaniu, czy w ogóle zamknięciu ich na noc.

Dokładnie, to dosyć świetna analogia i to tutaj w tym przypadku, który tu podałem jest jednym z wielu. To oczywiście jest dużo takich elementów, o których musimy pomyśleć.

Naszym rozmówcą jest Łukasz Bobrek, specjalista do spraw bezpieczeństwa z firmy SecuRing. Czyli te przypadki stricte włamania do chmury kontra to, że to my jako użytkownicy chmury źle zabezpieczyliśmy swój biznes są marginalne, to znaczy odpowiedzialność za tego typu błędy czy afery z wyciekiem danych leżą raczej po stronie użytkowników?

Tutaj nawet mogę się posłużyć statystyką Ipartnera, bo taka mi wpadła kilka dni temu w ręce. 95% błędów bezpieczeństwa w chmurze jest związana właśnie z jakimś błędem konfiguracji, którą popełnił użytkownik, a nie samymi podatnościami w mechanizmach bezpieczeństwa chmury. Więc jest to tak zdecydowana większość.

95% incydentów po stronie użytkownika daje do myślenia albo powinno. Zatem o co zadbać Łukaszu?

To jest kluczowe, żeby bardzo dobrze zidentyfikować, co w tej chmurze się tak naprawdę ma, co się w niej robi. Wyznaczyć sobie jakieś strefy zaufania, do czego klienci powinni mieć dostęp, do czego nie powinni mieć dostępu. Jak jakieś dane powinny być przetwarzane i to też nie jest kwestia tylko udostępnienia czegoś publicznie wszystkim, ale też kwestia odpowiedniego zarządzania rolami wewnątrz swojej organizacji. Tutaj też ktoś powinien przemyśleć, że jakiś stażysta na jakiejś nietechnicznej roli w organizacji nie powinien mieć dostępu administracyjnego do maszyn wirtualnych, które są uruchomione gdzieś w obszarze chmury. Więc też niezwykle ważnym obszarem też niezwykle złożonym niestety, ale to troszkę wynika ze specyfiki chmury, jest ta kwestia nadawania uprawnień właśnie wewnątrz usług, które są w niej dostępne.

Jak to zrealizować?

Znaczy jest kilka takich dobrych praktyk, według których zawsze powinno się postępować. Pierwszą z nich to jest taka świetna praktyka, która w każdym obszarze bezpieczeństwa ma swoje zastosowanie. Jest jedną z głównych i chyba najważniejszą. To jest zasada najmniejszych przywilejów, czyli jeżeli ktoś powinien w organizacji wykonywać jakąś pracę - mówię tutaj o wewnątrz chmury, to powinien mieć uprawnienia, żeby tą pracę wykonać, ale nic, poza tym. Bo taką zasadą, o której warto pamiętać w chmurze jest korzystanie z grup, czyli tutaj nie nadawać poszczególnym osobom uprawnień, bo w organizacjach, które mają kilkaset, nawet kilka tysięcy użytkowników, to po prostu robi się już zbyt skomplikowane, żeby pamiętać o każdej osobie, żeby nadać odpowiednie uprawnienia, co gorsza, potem, być może trzeba je gdzieś odjąć, jeżeli nagle przestają być potrzebne. Więc tutaj rozwiązaniem jest tworzenie grup. Czyli tworzymy sobie grupę w której są administratorzy, deweloperzy, użytkownicy nietechniczni, konsultanci. Oczywiście tych grup w zależności od potrzeb biznesowych może być wiele i mogą być różne, aczkolwiek wtedy bardzo łatwo zdefiniować poszczególnym grupom odpowiednie dostępy.

I zautomatyzować ten proces, ułatwić administratorom życie. A jeśli chodzi o samą czynność logowania do ekosystemu Google, wykorzystanie Google Cloud Identity, czy miałeś okazję się temu przyjrzeć?

Tak jak powiedziałeś tutaj, dostęp do samej chmury jest oparty na Google Identity, czyli tutaj możemy tak naprawdę każdy użytkownik Google, to może być konto prywatne na przykład Gmail czy to może być konto firmowe podpięte pod konkretną domenę, im można nadać uprawnienie do działań wewnątrz GCP. Pewnie zaraz powiem szerzej, ale w skrócie to GCP jest po prostu młodsze i troszeczkę nauczyło się na błędach w AWS i parę rzeczy zrobiło po prostu lepiej.

Google udostępnia ciekawe rozwiązania, dzięki którym możemy zapewnić bezpieczeństwo i ochronę dla organizacji przed atakami z zewnątrz, ale też incydentami wewnątrz. Czy możemy zacząć od DDoS , czym jest DDoS i jak się bronić?

DDoS to jest distributed denial of service i to jest atak polegający na tym, że bardzo wiele tutaj mówimy o skali rzędu setki tysięcy, czasami to nawet miliony urządzeń, które są tak zwanym botnetem jednocześnie łączą się ze z daną usługą. I jeżeli to jest usługa, którą tworzymy, sami utrzymujemy we własnej infrastrukturze, to bardzo ciężko przed takim, atakiem jest się obronić. Ale korzystając z Clouda mamy to w zasadzie wbudowane od razu domyślnie w naszą już infrastrukturę. W przypadku GCP jest taki serwis o nazwie Cloud Armor i on działa na poziomie load balancera, czyli takiego punktu styku między naszą infrastrukturą a siecią publiczną, siecią zewnętrzną, z której łączą się do nas klienci albo też atakujący. I teraz ten Cloud Armor w domyślnej konfiguracji broni nas korzystając tutaj z wszelkich dobrodziejstw technologicznych Googla przed atakami typu DDoS. Więcej jakby tutaj ten tak mamy załatwiony nick, tak naprawdę korzystając z nich zupełnie nie musimy się przejmować. Cloud Armor może być też rozszerzony i to już nie działa domyślnie, ale jeżeli chcemy, to możemy skorzystać z troszeczkę lepszej wersji, gdzie możemy napisać sobie różne regułki, które wtedy działają. Wtedy on analizuje, czy w ruchu, który do nas dociera są specyficzne frazy, które sugerują, że ktoś chce zrobić coś złego w naszej infrastrukturze. Jeżeli nakryje taką sytuację, to też ten druk jest obcinany i idąc finalnie nie trafia.

Takie ataki są atakami na zlecenie? Bo to rozumiem, że wymaga zaangażowania sporej infrastruktury, też takiej hardwarowej. Czy masz coś do powiedzenia na tym polu i zastanawiam się po prostu co jest efektem? Rozumiem, że zblokowanie usługi, ale czy efektem może być dajmy na to w przypadku usługi chmurowej, gdybyśmy nie zabezpieczyli się, czy wtedy moglibyśmy mówić o wielkim zużyciu chmury, a więc wielkich kosztach?

Wiesz co, jest nawet taki tartak specyficzny dla chmury, który ma bardzo piękną nazwę i nazywa się denied of violet i on właśnie polega na tym, o czym mówisz, czyli że ktoś, kto zupełnie publicznie albo ktoś z małymi uprawnieniami, ktoś w każdym razie, kto nie powinien, w jakiś sposób generuje ogromne koszty na naszej chmurze. Naszą stratą jest to, że za to musimy zapłacić, ale też w praktyce to raczej nie jest tak, że ktoś robi taki atak, tylko po to, żeby zrobić nam na złość, ale na przykład takie ataki też już były w Tesli. Więc Tesla w swojej strukturze wykryła taką sytuację, że jakiś atakujący uruchomił bardzo dużą ilość koparek kryptowalut po prostu, bo znalazł jakąś możliwość techniczną właśnie, żeby uruchamiać...

I przez chwilę kopał na konto, znaczy na swoje konto, ale jednak za prąd płaciła Tesla?

Tesla płaciła, ktoś wykopywał sobie kryptowaluty i jakby tak to się kręciło przez chwilę, póki to by oczywiście nie zostało znalezione. To oczywiście bardzo prosto jest wykryć, tutaj każda chmura generuje bardzo fajny i przejrzysty raport budżetowy, gdzie możemy na żywo tak naprawdę oglądać, ile nam się spala pieniędzy. Też możemy sobie zdefiniować, alerty typu, że jeżeli przekroczymy kwoty x, którą zakładamy, że powinna być zużyte w ciągu miesiąca, to oczywiście dostajemy powiadomienie. Więc jeżeli dostaniemy wiesz drugiego powiadomienie, że kwota, która została zużyta za cały ostatni miesiąc, została przekroczona, to już lampka się powinna zapalić.

Trochę jak z roamingiem, zwłaszcza poza terenem Unii, to bardzo przydatne, bo wiele osób popłynęło. Było naprawdę sporo spraw w naszym kraju, że ktoś zbankrutował.

Tam nie dało się tego alertować, ale tak podobna sytuacja.

Dobrze, to raczej jak rozumiem, są ataki z zewnątrz naszej organizacji. A jak można zabezpieczyć się jak chodzi o niebezpieczeństwa w wewnątrz?

Tutaj rozmawialiśmy sobie o tej, poprawnym nadawaniu uprawnień i to jest niezwykle ważne. Też trzeba mieć na uwadze, że jeżeli mówimy ogólnie o uprawnieniach w chmurze to możemy sobie podzielić na takie uprawnienia nadawane per użytkownikom, czy też per grupie użytkowników i to jest jakby jedna grupa, ale drugą grupą zupełnie osobną są tak zwane konta serwisowe. To są konta, które identyfikują nasze wewnętrzne komponenty, też usługi wewnątrz naszej infrastruktury, czyli jeżeli tworzymy sobie tą przysłowiową maszynę wirtualną i teraz ona chce sobie zagadać do na przykład bazy danych, którą mamy gdzieś w tej infrastrukturze to tutaj jakoś musi się uwierzytelnić. Musi przekazać tej bazie danych informacje, że to jest zaufana usługa. Więc tu oczywiście możemy to kontrolować na dwa sposoby. Po pierwsze możemy sobie zdefiniować regułki firewall'owe, które po prostu na warstwie takiej komunikacyjnej mogą dopuścić, albo nie dopuścić taki ruch, ale oprócz tego też każda usługa uwierzytelnia się poprzez konto serwisowe i te konta serwisowe niestety w GCP mają dosyć szerokie uprawnienia. W sensie, jeżeli sobie zakładamy taką tą wirtualną maszynę, ona korzysta z domyślnego konta serwisowego, która domyślnie ma rolę edytora na całym projekcie i może bardzo dużo. Sam Google w swojej dokumentacji mówi, że to nie jest dobrze i żeby kontrolować, nie korzystać z domyślnych kont serwisowych, tylko definiować własne uprawnienia zgodne z faktycznymi potrzebami, czyli zgodnie z tą zasadą najmniejszych uprawnień, o której sobie mówiliśmy. Niemniej jednak tutaj wygrała taka trochę wygoda i taki UX nad bezpieczeństwem. Od zawsze jest taki dylemat i taka walka właśnie między wygodą a bezpieczeństwem. Tutaj Google uznał, że bardzo ciężko by się korzystało z chmury, gdyby dla każdego zasobu trzeba było definiować samemu konto serwisowe i dać mu uprawnienia zgodnie z jego przeznaczeniem, to byłoby trudne i faktycznie z punktu widzenia przeciętnego użytkownika. Tak jak jest teraz jest zdecydowanie wygodniej. Aczkolwiek sama dokumentacja Google mówi, że nie jest to normalne i żeby też to tego pilnować.

Prowadzisz audyty rozumiem różnych biznesów, w tym jak słyszę, prowadzisz niejako audyty także biznesów chmurowych i jakie procedury kontrolne oferuje tutaj GCP? Bo pewnie mamy jakieś rodzaje szyfrowania. Mamy kontrolę dostępów. Mamy różne pewne poziomy zaawansowanej autoryzacji. Mamy też dostęp do logów. Co jest bardzo przydatne, gdy podchodzisz do kwestii badania bezpieczeństwa danego przedsiębiorstwa?

Jasne. Jeżeli robię przegląd bezpieczeństwa usług chmurowych w jakimś przedsiębiorstwie to muszę mieć do niego dostęp. I tutaj w przypadku GCP jest to o tyle ułatwione, że jest taka definiowana rola o nazwie the security i ona z grubsza ma takie uprawnienia, jakie są mi potrzebne do wykonania takiego audytu. Mówię z grubsza, bo ona zakłada taki dosyć płytki audyt. Tymczasem chcemy wejść trochę głębiej i prosimy naszych klientów o jakieś rozszerzenie tej woli, ale to jest taki pierwszy krok, który trzeba wykonać żebyśmy w ogóle mogli zobaczyć na czyimś chmura. I jak już ten dostęp mamy, pierwszym krokiem, który zawsze robimy jest rozmowa i bez tego tutaj byłoby ciężko cokolwiek zrobić, bo rozmawiamy o produkcie, który ma naprawdę setki, jeśli nie tysiące różnych usług. Więc musimy poznać tak naprawdę co to są za usługi. Więc umawiamy się na kilkugodzinną, czasem dłuższą rozmowę z klientem, w ciągu której robimy coś, co nazywamy modelowaniem zagrożeń. Czyli z jednej strony klient opowiada co w tej chmurze ma i jak z tego korzysta. My sobie budujemy taki obraz właśnie tych zasobów ze stopnia złożoności tej infrastruktury, też wyznaczamy sobie takie kluczowe zasoby, które klient powinien bronić, czyli jakieś dane osobowe powiedzmy i wyznaczamy sobie jakie to są dane i gdzie one są. Budujemy sobie taki obraz, co ktoś mógłby chcieć zaatakować i oczywiście potem myślimy, jak to zrobić i patrzymy czy zabezpieczenia przed takimi atakami są poprawnie zaimplementowane?

Jak wypadamy na tle świata? Czy Łukaszu możesz podać jakieś przykłady wyników audytów, także chmurowych audytów u swoich klientów?

Tutaj nie powiem, żeby była jakakolwiek różnica. W sensie to nie jest tak, że polscy klienci robią coś lepiej albo gorzej. Uważam, że ten poziom jest wyrównany z resztą świata. Jeżeli chodzi o takie rzeczy, które najczęściej się trafiają to oczywiście jest udostępnienie tych bucketów, czyli w przypadku GCP cloud storage, tej przestrzeni dyskowej, gdzie można zatrzymać dowolne pliki i tutaj udostępnienie tego zbyt szeroko. Tutaj też taka ciekawa rzecz, która mnie zawsze tak na prawdę boli, jak ją widzę i jeżeli nam się zdarzy ją znaleźć. Otóż i w GCP i AWS jest taka rola, która jest strasznie myląca i nawet ciężko mi się dziwić, że ktoś faktycznie ją ustawia, jeżeli chodzi o poziom dostępu do danych plików, czyli ktoś tworzy sobie jakiś zasób, chce, żeby do niego dostęp miała tylko część organizacji, więc widzi rolę, czy po prostu grupy użytkowników i stwierdza, że OK brzmi dobrze, tak, ustawię, że będą mieli dostęp do tych plików. Ale okazuje się, że w nomenklaturze GCP są to wszyscy uwierzytelnieni użytkownicy w Google. Czyli ktokolwiek kto ma Gmail'a może się dostać do tych zasobów. Takie rzeczy się zdarzają. Teraz w AWS nazwy takiej roli już dokładnie nie pamiętam, ale jest analogiczne, więc niestety na to trzeba uważać.

A to niezła ciekawostka. Takich luk też pewnie rozumiem można szukać po godzinach będąc freelancerem. Hackujesz sobie po godzinach?

Jeżeli chodzi o moje życie zawodowe to codziennie, ale jeżeli chodzi o jakąś taką pracę po godzinach to też, aczkolwiek tutaj już w formie oczywiście kontrolowanej i legalnej, ponieważ w programach typu takie, które oferuje Google, ale i tak te programy polegają na tym, że ktoś po godzinach przecież ktoś to musi traktować jako ogólno wymiarową pracę, bada bezpieczeństwo danych aplikacji czy to usług, czy innych rozwiązań. Jeżeli znajdzie jakąś podatność, to zgłasza ją do dostawcy. Tam można zgłosić taką podatność, Google ją przetwarza, analizuje i jeżeli faktycznie przychyli się, że jest to jakiś błąd bezpieczeństwa, to po prostu wypłaca nagrodę dla tego kto to znalazł i tę podatność oczywiście naprawia. Tam też oczywiście jest to kontrolowane, ponieważ oficjalne ogłoszenie jaka to jest płatność następuje wtedy, kiedy ona już zostanie poprawiona. Więc tutaj nie ma takiego ryzyka, że ktoś coś znajdzie, klikuje i zanim ktoś to naprawi, to jeszcze tam zdąży...

Jasne, a powiedz, czy kwoty, które są oferowane za znalezienie pewnej dziury, luki są jawne i jakiego rodzaju ewentualnie są?

Są jawne. Znaczy to też zależy od programu, od tego, kto to płaci firmom, gdy znajdziemy podatności.

A Google?

Mniejsze firmy często nawet nie wypłacają żadnych nagród, tylko na przykład umieszczają jakieś podziękowania na swoich stronach. Google płaci dosyć dobrze. Płaci z tego co pamiętam, 31 tysięcy za takie największe podatności, na przykład związane z wykonaniem zdalnym kodu.

Jaka waluta? 31 tysięcy..?

Dolarów.

Dolarów, to też wiele zmienia.

Przy czym jeszcze jest coś takiego jak TOP 10 takich znalezionych podatności. Jeżeli jakaś podatność w ciągu całego roku zostanie uznana za najfajniejszą z tych wszystkich zgłoszonych, to jeszcze dopłaca 100 tysięcy, więc no to już się...

Dolarów?

Wtedy... Dolarów. 130 tysięcy za jedną płatność.

Czy masz na koncie podatność?

W Google nie.

Ale pracujesz nad tym jak słyszę?

Tak. No ale to też jest tak, że pracując z klientami to oni nam w ciągu naszego czasu pracy nie płacą za to, żeby atakować bezpośrednio mechanizmy bezpieczeństwa Google, tak?

To praca po godzinach.

Zresztą to nie jest ich biznes. To się robi po godzinach. Troszkę to jest mało czasu, więc osoby, które z tego żyją, zapewne tutaj mają lepsze wyniki.

Dobrze. Czy możemy powoli domykać ten wątek i przechodzić trochę do aplikacji mobilnych i bankowości, chociaż trochę ją naruszyć, bo to też jest bardzo chodliwy temat i gorący, zwłaszcza w obliczu raportu, który ostatnio przygotowałeś.

Jasne, to jest badanie, które robimy we współpracy z Pulsem Biznesu i w ramach konkursu Złoty Bankier i ocenia banki polskie w bardzo dużej ilości kategorii. My jesteśmy partnerem merytorycznym kategorii bezpieczeństwo i my w ramach tego wykonujemy takie sprawdzenie bezpieczeństwa polskich banków, aczkolwiek tutaj my tylko oceniamy, czy istnieją różne mechanizmy, ale nie badamy tego, jakie one są, czy na warstwie technicznej one są zrobione poprawnie. To robimy oczywiście komercyjnie dla naszych klientów. W ramach konkursu tylko i wyłącznie stwierdzamy obecność mechanizmów typu, na przykład wieloskładnikowe uwierzytelnienie jest jednym z takich wielu rzeczy.

Nie wykonujecie stricte testów, a tak naprawdę przyglądacie się aplikacjom bardziej?

Dokładnie.

Jakie są wyniki?

Jeżeli chodzi ogólnie o polską scenę bankowości to jest bardzo fajnie rozwinięta i tutaj porównując z bankami zagranicznymi, jeśli chodzi o liczbę mechanizmów i tego jaka jest jakość implementacji, to naprawdę mogę powiedzieć, że jesteśmy z przodu stawki, jeżeli chodzi o rozwiązania bankowe.

Bo rozumiem, że tutaj w pewnie w przypadku tak jak i chmury największe ryzyko leży po stronie nas, czyli stricte użytkowników. Co banki stosują obecnie z nowości, co będą mogły stosować? Jakie ewentualnie możliwości mogą pojawiać się na horyzoncie? Jak chodzi zwłaszcza o weryfikację użytkownika, co tutaj widzisz na tym polu?

Jeśli chodzi o weryfikację użytkownika to jest taki ruch, który powoli już widać. To jest uwierzytelnienie się naszą taką tożsamością związaną z elektronicznym dowodem na przykład. Tego jeszcze nie ma, to działa raczej w drugą stronę, że jeżeli chcemy uwierzytelnić na przykład w ZUS-ie z Profilu Zaufanym możemy to zrobić przez bank, ale jakby nie ma technicznych przeszkód i nawet to już powoli, myślę, że banki o tym myślą, żeby się uwierzytelniać w nich przy użyciu elektronicznego dowodu. Więc w skrócie mielibyśmy aplikację mobilną, którą byśmy skanowali poprzez NFC nasz dowód osobisty i w efekcie moglibyśmy w ten sposób uwierzytelnić do banku. Być może kiedyś coś takiego będzie wprowadzonego.

A jak możemy zabezpieczyć obecnie? Czy wydrukować sobie tradycyjną kartę kodów do autoryzacji przelewów? Czy może bardziej ufać naszym telefonom?

No nie jestem fanem takich kodów szczerze mówiąc. I takim najbezpieczniejszym obecnie rozwiązaniem jest aplikacja mobilna. To co pewnie wiele osób zna z polskiej bankowości, bo to jest dosyć powszechne. Czyli wykonujemy sobie płatność, przychodzi do nas na telefon powiadomienie, w którym musimy kliknąć, że się zgadzamy na daną transakcję i jeszcze, żeby to kliknąć, to musimy się wcześniej zautoryzować w aplikacji mobilnej albo podając kod. To jest na chwilę obecną najbezpieczniejsze rozwiązanie.

Mówiąc o bezpieczeństwie firmy czy też biznesu, warto być odpornym także na ataki typu phishing. Na czym polegają i jak się przed nimi chronić?

W jakiś sposób ktoś Ci podsyła stronę, która wygląda identycznie albo w bardzo zbliżony sposób do strony, gdzie chce Cię okraść. Co więcej, są takie automatyczne narzędzia do phishingu, że w ogóle to tylko klikasz jaką chcesz stronę i to narzędzie, jakby automatycznie sobie zaciąga taki cały kod ten UX-owy tej strony, generalnie jest nie do odróżnienia. Wpisujesz tam login i hasło w tą aplikację i to narzędzie pod spodem co robi, to jakby bierze twój login i hasło szybko je wysyła do oryginalnej strony, Tobie podstawia tą stronę z prośbą o podanie tego tam kodu czy tokenu z sms'a, z e-maila czy skądkolwiek, Ty wpisujesz to i to oni jakby sobie pod spodem przesyłają do faktycznej strony i przed czymś takim może cię obronić tylko fizyczny token który nie jest aż tak popularny jeszcze.

Fizyczny token, czyli takich klucz, który na przykład wtyka się do USB?

Dokładnie tak i to są takie fizyczne tokeny autoryzacyjne i w momencie kiedy jesteś proszony o dodatkową autoryzację, to nie wystarczy tutaj podanie kodu SMS, co ktoś może przejąć, tylko musisz fizycznie włożyć coś do USB i wtedy dopiero zostaje autoryzowany. Więc jeżeli ktoś to robi zdalnie, nie mając fizycznego dostępu do tego tokena to po prostu nie jest w stanie nic zrobić.

Rozumiem, że polecamy takie rozwiązanie?

Jak najbardziej.

Ok Łukaszu, a zbierając to wszystko razem, czy możemy nakreślić taki zestaw dobrych praktyk, które możemy wdrożyć na przykład w startującym biznesie?

Ok. Więc na takiej warstwie osobistej już tak, by odchodząc jeszcze od biznesowych zaleceń, to na pewno warto korzystać z managerów haseł, warto mieć unikalne hasła dla każdej usługi. Fajnie, jeżeli te hasła są długie i bardzo losowe, to na pewno. Poza tym taki zdrowy rozsądek i rozwaga, jeżeli chodzi o to gdzie udostępniamy, gdzie dajemy uprawnienia, gdzie przesyłamy nasze dane. Tutaj trzeba zachować też uwagę. Jeżeli ktoś nam przesyła linka, żebyśmy gdzieś zapłacili, to już powinna wzbudzić w nas jakąś czujność. Jeżeli nawet ten link miałby być dobry, to zawsze warto zweryfikować jego strukturę. Bo jeżeli ktoś chce wyciągnąć nasze dane osobowe przy ataku phishing, to tak naprawdę my finalnie te dane nie wysyłamy na domenę banku, czy też usługi, z której chcemy korzystać, tylko na inną domenę. Te domeny czasem potrafią być bardzo podobne do tych właściwych, różnić się jednym znakiem na przykład. Ale czasem to są jakieś zupełnie losowy ciąg znaków, więc wtedy od razu powinniśmy odrzucić taki link i z niego nie korzystać. Jeżeli chodzi o takie rady dla biznesów, to również bym zalecił managery haseł jako coś, co to jest zalecane wszystkim wewnątrz organizacji i też wymuszenie dwuskładnikowego uwierzytelnienia. To w chmurze jest jak najbardziej dosyć proste do zrobienia. Wręcz możemy wymusić, że musi być to fizyczne, tak związane z tokenem fizycznym. Na przykład wewnątrz Google tak jest. Wszyscy pracownicy Google'a, którzy chcą się dostać do swoich kont czy usług, korzystają z tych fizycznych tokenów.

A to ciekawe, mówiłeś, że bardzo częstym takim koronnym grzechem firm po dokonanym dajmy na to audycie, jak chodzi o technologie chmurowe, jest sytuacja, w której na dysku publicznym albo dysku szeroko współdzielonym znajdują się jakieś cenne informacje i pytanie jest takie, czy właśnie jest to za szeroki dostęp dla danego dysku? Czy jest to sytuacja, że na publicznym dysku są dane poufne czy też wrażliwe, które znalazły się tam przez przypadek?

To powiem Ci tak, i w jedną i w drugą stronę. W sensie pracując i likwidując takie audyty, znaleźliśmy sytuacje, gdzie był ten bucket, to jest może trochę niefortunna nazwa, ale jest zupełnie nieprzetłumaczalna na polski, jeśli chodzi o tą przestrzeń dyskową, którą można udostępnić wszędzie klientom. Więc oczywiście w jednym z takich bucketów były i miały być przechowywane statyczne pliki, które generowały czy budowały stronę internetową i to jest jak najbardziej w porządku. Tutaj jakby nie ma w tym nic złego, ale w tym pakiecie też znalazł się plik, który tam być nie powinien, zdradzał jakieś tam dane biznesowe. Takie sytuacje się zdarzają. Zdarzają się też sytuacje, gdzie po prostu albo przez błędną konfigurację, albo przez jakiś błąd, albo właśnie przez złe zrozumienie nazwy grupy typu właśnie taki kontener, w którym jakby z definicji są dane wrażliwe, jest udostępniany publicznie.

Łukasz Bobrek, Senior IT Security Consultant z firmy Securing. Bardzo dziękuję ci za rozmowę. Czuję, że nasze biznesy, jak i konta prywatne są o wiele bezpieczniejsze po tym podcaście.

Również dziękuję i do usłyszenia.

A usłyszymy się w kolejnym odcinku Fly Talks podcastu o chmurze w biznesie.