8:30
11/10/2021

Chmura zdobywa popularność w Polsce. Co prawda nadal znajdujemy się w europejskim ogonku jeśli chodzi o poziom adopcji chmury. Według danych Eurostatu, w 2020 roku z clouda korzystało 24% polskich przedsiębiorstw, kiedy średnia UE wynosiła 36%. Ale zmiany są dostrzegalne. Widać to chociażby po natężeniu atrakcyjnych ofert pracy dla inżynierów chmurowych, liczbie nowych projektów uruchamianych w chmurze czy wysypie darmowych i płatnych kursów. Jako partner Google Cloud notujemy coraz większe zainteresowanie usługami chmury publicznej wśród firm, startupów, jak indywidualnych developerów i administratorów. Niestety, często (na pewno częściej niż byśmy chcieli) jesteśmy też świadkami spektakularnych potknięć. Na przykład takich:

 

Autorem niniejszego artykułu jest Ida Ożarowska, Content Manager w FOTC.

Ponieważ najlepsza jest nauka na cudzych błędach, postanowiliśmy przyjrzeć się pięciu niepotrzebnie wysokim rachunkom w chmurze. Prześledzimy, co poszło nie tak, wskażemy, jak należało zareagować oraz pokażemy, jak można było tym sytuacjom zapobiec. 

Zapraszamy Was też na webinar o podstawach bezpieczeństwa w chmurze dla osób pracujących lub planujących pracę z Google Cloud Platform. Więcej informacji o wydarzeniu znajdziesz na końcu artykułu.

Analiza 5 niepotrzebnie wysokich rachunków za chmurę

Dostawcy usług chmurowych piszą o sukcesach swoich klientów. Na stronie AWS przeczytamy o Netfliksie, u Google o PayPalu czy Twitterze. Ale obok pomyślnych, głośnych projektów zdarzają się też ciche potknięcia wynikające z pośpiechu, niewłaściwej konfiguracji usług czy niedopilnowania kwestii bezpieczeństwa.

Poniżej opisaliśmy pięć popularnych błędów i ich konsekwencje. Kilka uwag do tego, co za chwilę przeczytasz:

  • Te historie wydarzyły się naprawdę.
  • Ale nie są normą. To raczej chmurowe anomalie.
  • Podajemy przybliżoną kwotę, jaką nabili użytkownicy chmury GCP. To wyrażony w dolarach moment ich reakcji, a nie górny limit na usługi cloudowe.
  • Właściwie każdej z tych sytuacji można było zapobiec. Wiele organizacji stawia na samodzielność, przez co nie konsultują architektury czy sposobu konfiguracji usług z firmą partnerską. I tak, niektóre z tych sytuacji przytrafiły się naszym klientom, ale dołożyliśmy wszelkich starań, żeby szybko zażegnać kryzys i zminimalizować jego skutki.

1. Udostępnienie klucza service account w publicznym repozytorium – 70 000 USD w dobę

Nikt nie wie, ile Bitcoinów zostało wykopanych cudzym kosztem.

Za każdym razem, gdy rozbudowujemy infrastrukturę GCP o kolejną usługę, tworzone jest konto serwisowe, dzięki któremu usługa uwierzytelnia się wśród innych aktywnych komponentów. Przykładowo: uruchamiamy VM w usłudze Compute Engine, która ma współpracować z bazą danych Cloud SQL; z pomocą klucza usługi (service account key) maszyna uwierzytelnia się w usłudze bazy danych i otrzymuje dostęp. W Google Cloud Platform każde nowo utworzone konto serwisowe ma określony zakres dostępu do danych i edycji, by zachować płynność działania infrastruktury, a w gestii właściciela projektu jest przyznanie minimalnego wymaganego poziomu uprawnień usługi.

Przypadkowe udostępnienie klucza usługi to najpopularniejszy sposób na pozostawienie w chmurze dużej ilości pieniędzy. Nieuwagę użytkowników chętnie wykorzystują hakerzy, którzy scrapują publiczne repozytoria w poszukiwaniu kluczy, z pomocą których uzyskują dostęp (najczęściej) do mocy obliczeniowej maszyn wirtualnych.

Niedawno pomagaliśmy rozwiązać taką właśnie sytuację. Organizacja posiadała projekt w chmurze GCP z maszynami o wysokiej specyfikacji. Jeden z pracowników firmy udostępnił na GitHubie folder zawierający klucz dostępu usługi. A ta… no cóż, miała duże uprawnienia. Wystarczyła doba, żeby haker nabił rachunek na ponad 70 000 USD. A ten byłby z pewnością wyższy, gdyby administrator nie usunął w czas service account key. Natychmiast skontaktowaliśmy się z supportem Google w imieniu klienta i opisaliśmy całe zdarzenie. Na szczęście jedyną stratą w wyniku tej sytuacji była strata nerwów, ponieważ zespół GCP, po rozpatrzeniu sytuacji, postanowił anulować rachunek wygenerowany przez hakera.

Jak można było zapobiec tej sytuacji?

Zabrakło wdrożenia dobrych praktyk bezpieczeństwa, w szczególności przyznawania dostępu według zasady principle of least privilege, również wśród kont usług. Gdyby service account miało mniejsze uprawnienia, haker nie zasiałby tak dużego zniszczenia.

Druga, niezwykle ważna kwestia: udostępniając kod na GitHubie należy wykluczyć w pliku .gitignore wszystkie foldery zawierające dane dostępu, hasła czy klucze.

 

Klucze usług znajdują się w folderze keys. Dobrze jest wykluczyć cały folder z dodawania do repozytorium.

Polecamy też ustawić alerty o osiągnięciu określonego pułapu wydatków w zakładce Billing lub własne alerty w usłudze Cloud Monitoring, które poinformują o anomaliach zachodzących na koncie GCP – na przykład o większym obciążeniu czy zużyciu zasobów.

Jeśli bardziej niż dostępność aplikacji cenisz sobie niewygórowane rachunki za chmurę, możesz zaimplementować wyłącznik awaryjny – skrypt, który z pomocą usług Google Cloud Platform nasłuchuje eventów i po osiągnięciu konkretnego pułapu automatycznie wyłącza wskazaną usługę (odnośnik do dokumentacji kill switcha znajdziesz w dalszej części artykułu).

Jak reagować, jeśli haker przechwyci klucz usługi?

Jest kilka drastycznych sposobów i kilka mniej drastycznych, które zatrzymają rachunek galopujący w wyniku udostępnienia service account key.

Najbardziej drastycznym jest wyłączenie całej infrastruktury. Jeśli możesz pozwolić sobie na przerwę w działaniu aplikacji, to będzie wyjście, które pozwoli najszybciej zatamować przeciek. Wyłącz, przeanalizuj logi, zlokalizuj lukę, załataj i ponownie uruchom system.

Jeśli nie chcesz przerywać działania aplikacji, możesz szukać przyczyny “na żywo”. Z pomocą partnera Google Cloud lub w panelach Billing i Cloud Monitoring namierz, który projekt lub usługa generuje koszty i wyłącz ją lub odepnij od konta rozliczeniowego. To odbierze hakerowi dostęp do zasobów, ale najpewniej zaskutkuje też wyłączeniem części systemu.

Drążąc dalej, możesz odszukać i usunąć feralny klucz konta usługi. To wyrządzi najmniejsze szkody w działaniu aplikacji; licz się jednak z zerwaniem połączenia między powiązanymi usługami.

2. Atak DDoS przy braku limitu skalowania górnego – 12 000 USD w godzinę

Usługi chmurowe skalują się w dół oraz w górę. Z jednej strony taka rozciągliwość jest dobra, bo pozwala przyjąć bez czkawki każdego użytkownika serwisu. Z drugiej, za wysoki górny limit skalowania może doprowadzić do niepotrzebnie wysokich kosztów. Zwłaszcza, jeśli ruch nie będzie wygenerowany organicznie przez użytkowników serwisu, a przez hakera.

DDoS (distributed denial of service) to cyberatak, którego celem jest zajęcie dostępnych zasobów aplikacji, by uniemożliwić jej funkcjonowanie. Ruch jest generowany sztucznie z wielu urządzeń, najczęściej zainfekowanych trojanami czy botami. Do każdego zapytania zostaje przypisany pewien zasób – pamięć, moc procesora, przepustowość sieci, co przy wielu wejściach na serwis prowadzi do wyczerpania zasobów i jego wyłączenia.

Ale wyłączenie serwisu może trochę zająć, jeśli korzystamy z chmury i nie zabezpieczyliśmy się przed atakiem ani nie ustawiliśmy bezpiecznego górnego limitu skalowania. Aplikacja w pewnym momencie nie będzie w stanie obsłużyć wszystkich zapytań, ale zanim to się wydarzy, zostanie nabity dość pokaźny rachunek za moc obliczeniową. Na przykład 12 000 USD w przeciągu godziny.

Jak uchronić się przed atakiem DDoS w chmurze?

Czołowi dostawcy usług chmurowych posiadają w portfolio swoich usług produkty zabezpieczające przed cyberatakami. W przypadku Google Cloud Platform jest to Cloud Armor – usługa tarczy i firewalla z wbudowaną ochroną przed atakami L3 i L4 DDoS oraz predefiniowanymi regułami, które pozwalają też blokować ruch przychodzący na podstawie danych geolokalizacyjnych i typu źródła, CIDR czy protokołów IPv4 i IPv6.

Jeśli nie chcesz korzystać z gotowych usług zabezpieczających przed atakami, minimum to ustawienie bezpiecznego górnego limitu skalowania usług compute lub serverless. Możesz (a raczej powinieneś) przygotować też awaryjne centrum danych i opracować automatyczny lub manualny sposób przełączania aplikacji albo zadbać chociaż o cykliczne wykonywanie i bezpieczne przechowywanie kopii zapasowej. W sytuacji ataku serwis się wyłączy – haker osiągnie swój cel, ale Ty będziesz miał relatywnie dużą łatwość przywrócenia działania aplikacji w innym projekcie czy lokalizacji. I relatywnie niski rachunek za zużytą moc obliczeniową.

A jak reagować na atak, jeśli nie byliśmy na niego przygotowani?

Jeśli nie zadbałeś wcześniej o odpowiednią ochronę infrastruktury i bimbasz z wysokim limitem skalowania, w sytuacji ataku jedyne, co możesz zrobić to przyspieszyć blokadę serwisu – wyłączyć usługę maszyn wirtualnych, odpiąć projekt od konta rozliczeniowego lub całkowicie zamknąć konto billingowe i przywrócić aplikację do działania po odpowiednim jej zabezpieczeniu.

3. Rekurencja w chmurze – 70 000 USD w ciągu dwóch godzin

To historia, w której jedną z głównych ról ponownie odgrywa za wysoki górny limit skalowania. Biorąc pod uwagę fakt, że zasoby cloudowe są niemal nieograniczone, chcemy, żebyście zapamiętali:

Nie powinno się robić nieskończonej pętli w chmurze albo przypadkowej rekurencji.

Znaczy, można, fizycznie jest to wykonalne. Ale zanim zdecydujesz się na uruchomienie rekurencyjnie wykonującego się kodu, przeczytaj o sytuacji, z jaką mierzył się startup z Doliny Krzemowej – Milkie Way.

Po miesiącach prac nad aplikacją Announce, trzy dni przed planowaną publikacją wersji MVP, zespół postanowił przetestować możliwości Cloud Run – bezserwerowej platformy do wdrożeń aplikacji w kontenerach. O której nie mieli za dużego pojęcia i która jest jedną z najdroższych usług GCP z wachlarza produktów compute & serverless.

Zespół chciał stworzyć algorytm, który pozwoli obejść ograniczenia czasowe w używanych przez nich usługach chmurowych. Przy dwunastym kubku kawy jeden z członków napisał na tablicy suchościeralnej skrypt, który następnie przenieśli do Cloud Run. Ustawili alert o zużyciu na poziomie 7 USD, uruchomili usługę i wrócili do tworzenia kodu aplikacji.

Nie zauważyli od razu, że określony pułap zużycia został osiągnięty dość szybko, a rachunek rósł w tempie ok. 600 USD na minutę. Kiedy weszli do konsoli, ciężko było im namierzyć przyczynę tak dużego zużycia. Nie chcąc marnować czasu, wyłączyli wszystkie projekty w GCP – nie tylko Announce, ale też inne, już funkcjonujące produkty. Kwota zatrzymała się na poziomie 71 393,86 USD.

Co było przyczyną tak wysokiego rachunku? Założyciel Milkie Way wskazał kilka błędów, które popełnili, m.in.:

  • startupowe podejście “fail fast, learn fast”, które w chmurze może generować sporo problemów,
  • zamieszczenie w usłudze nieprzetestowanego algorytmu, który, jak się okazało dość szybko, zapętlił się w nieskończoność,
  • niewystarczającą znajomość usługi, z której korzystali,
  • uruchomienie Cloud Run z domyślnym górnym limitem skalowania na poziomie 1000 instancji.

W efekcie wszystkie 1000 instancji pracowało nieprzerwanie i wysyłało do bazy danych Firebase miliard zapytań w ciągu minuty. A to dużo więcej niż było potrzebne do sprawnego działania aplikacji.

Po nitce do kłębka, czyli co zrobić z pętlą w chmurze

Jeśli zdarzyłoby ci się, że coś generuje zbyt duże koszty, przypomnij sobie, jakie niekonwencjonalne ruchy wykonywałeś ostatnio w chmurze. Może zamieściłeś nowy skrypt lub uruchomiłeś kolejną usługę? Jeśli masz czas i środki, prześledź w usłudze Cloud Monitoring, które projekty lub usługi generują największe zużycie i wyłącz je. W sytuacji, gdy nie możesz namierzyć przyczyny, a nie chcesz wyłączać całej aplikacji, skontaktuj się z partnerem Google Cloud, który przeprowadzi wywiad i pomoże zlokalizować źródło problemu.

Natomiast gdy rachunek rośnie w zastraszającym tempie, a tobie raczej nie uśmiecha się zbankrutować, możesz całkowicie wyłączyć konto billingowe lub odpiąć od niego wszystkie projekty, jak zrobił zespół Milkie Way.

A jak nie wpaść w błędne koło?

Najlepszym sposobem na uniknięcie wysokiego rachunku za nieświadome uruchomienie rekurencji w chmurze jest nieuruchamianie rekurencji w chmurze lub uruchamianie jej intencjonalnie i po przeprowadzeniu testów. Zanim wrzucisz kod do usługi chmurowej, przetestuj go w lokalnym środowisku lub w pipeline zbudowanym w usłudze Cloud Build.

Koniecznie zwracaj uwagę na konfigurację usług, zwłaszcza zarządzanych i skalujących się automatycznie – m.in. Managed Instance Groups w Compute Engine, Google Kubernetes Engine, App Engine czy wspomnianego Cloud Run. Gdyby Milkie Way zmieniło limit skalowania z domyślnego 1000 instancji na 2, usłiuga wygenerowałaby koszt 144 USD zamiast ponad 70 000 USD.

Obok alertów z konta rozliczeniowego ustaw też alerty w usłudze Cloud Monitoring. Możesz skomponować własne, szczegółowe warunki wysyłania powiadomień, które pozwolą szybciej namierzyć przyczynę i wskażą, który element aplikacji należy zablokować.

4. Puszczenie wadliwego zapytania w BigQuery – 40 000 USD przez weekend

BigQuery to jedna z ulubionych usług użytkowników Google Cloud Platform. To wysoce wydajna bezserwerowa hurtownia, która jest w stanie w czasie rzeczywistym analizować petabajty danych. Koszt to 5 USD za terabajt analizowanych informacji. Co nie wydaje się wysoką ceną, o ile masz pewność, że puszczasz prawidłowo skonstruowane query.

Piątek po południu, deploy zrobiony, pracownicy dość sporej firmy technologicznej byli już myślami na wieczornym grillu. Pozostało jeszcze tylko przesłać zapytanie do BigQuery i można zaczynać weekend.

W poniedziałek okazało się, że query, które miało skonsumować 5 dolarów, wygenerowało rachunek na 40 000 USD.

Zapytanie było nieprawidłowo skonstruowane, czego nikt nie sprawdził przed przesłaniem do usługi. Po uruchomieniu wykonywało się w kółko i trwałoby dalej, gdyby proces nie został przerwany. Finalnie, wspólnymi siłami, udało się nam anulować rachunek, a autor zamieszania został niekwestionowanym specjalistą od konstruowania zapytań SQL.

Jak można było temu zapobiec?

Do weryfikowania poprawności konstrukcji zapytań w BigQuery służy flaga dry_run. Wskazuje ile, w przybliżeniu, bajtów zostanie przetworzonych do obsługi danego query. Załóżmy, że baza danych, którą chcemy odpytać, waży 5 TB. Jeśli test dry_run zwróci wynik 0 bajtów lub 10 petabajtów to powinniśmy się spodziewać, że zapytanie nie zostało prawidłowo napisane. Jeśli wskaże wartość zbliżoną do 5 TB, możemy założyć, że wszystko jest w porządku i puścić query jako właściwe zapytanie.

5. Kiedy chcesz zaoszczędzić, a tracisz – 9 000 USD miesięcznie przez 3 lata

Jeśli korzystasz lub planujesz korzystać z GCP przed dłuższy czas, możesz obniżyć ceny niektórych usług chmurowych nawet o 70% dzięki Committed Use Discounts (w skrócie CUDs). To zniżka za zobowiązanie do stałego wykorzystania określonej puli zasobów – procesora, pamięci, przestrzeni dyskowej – w danym regionie Google Cloud Platform. Zniżkę możesz wziąć na okres roku lub trzech lat, przez który co miesiąc będziesz płacić stałą, niższą kwotę za “zarezerwowane” zasoby – niezależnie od tego, czy wykorzystasz całą pulę, czy tylko jej część.

Proste, prawda? Chyba nie da się niczego zepsuć.

Otóż da się. Można na przykład:

  • wskazać przez przypadek zniżkę na maszyny w innym regionie Google Cloud Platform,
  • wykupić zasoby na okres trzech lat, myśląc o trzech miesiącach,
  • wziąć za dużą zniżkę “na zapas” i opłacać ją pomimo mniejszego zużycia.

Załóżmy, że mamy miesięczne stałe zużycie mocy obliczeniowej na poziomie 20 000 USD. Biorąc zniżkę na okres 3 lat, moglibyśmy oszczędzić 45% kosztów. Ale jeśli się pomylimy i, przykładowo, jako region danych wskażemy nie asia-southeast1 a australia-southeast1 i nie zgłosimy pomyłki do supportu Google, będziemy zobowiązani przez trzy lata, obok 20 000 USD stałych kosztów, płacić też “pozniżkowe” 9 000 USD.

Źle kliknąłem, wskazując zniżkę. Co z tym zrobić?

O ile odpowiednio wcześnie (najlepiej w przeciągu 24 godzin) zorientujesz się o błędzie i zgłosisz go, Google najpewniej anuluje CUDa. Co do zasady nie ma możliwości przedterminowej rezygancji z Committed Use Discount, jednak wato próbować – nawet jeśli od momentu wykupienia zobowiązania minęło więcej niż doba.

Jak uniknąć panicznego pisania na support, czyli co jeszcze powinieneś wiedzieć przed uruchomieniem projektu w chmurze

Zakładając konto na GCP, musisz podać dane karty płatniczej, ponieważ Google potrzebuje zweryfikować Twoją tożsamość. Na start otrzymasz bezpłatne kredyty – 300 USD ważne przez 90 dni do wykorzystania na wybrane usługi. Dopóki nie wykorzystasz tych środków (i uważnie będziesz czytać, co akceptujesz podczas aktywowania konta), Twoja karta nie zostanie obciążona. Po zużyciu kredytów działające dotychczas usługi zostaną zablokowane, a Ty zapytany o chęć przejścia z wersji trialowej na pełną, płatną.

Inaczej jest w sytuacji, gdy nawiązujesz współpracę z partnerem Google Cloud i korzystasz z przekazanych od niego środków. Przykładowo, po wykorzystaniu vouchera 300 USD od Google możesz skorzystać z kredytów 500 USD od FOTC ważnych przez rok. Po zużyciu tych środków usługi ani projekt nie zostaną zablokowane – będą działały, dopóki ich nie wyłączysz ręcznie, a co miesiąc na Twojej skrzynce będzie pojawiała się faktura za użycie chmury.

Ustawianie alertów i kontrola zużycia

W konsoli GCP, w zakładce Billing / Budget & alerts, możesz bezpłatnie ustawić powiadomienia o prognozach zużycia lub osiągnięciu danego pułapu.

W Billing warto zwrócić też uwagę na panele Reports i Cost table. Pierwszy pokazuje wykres z wykorzystaniem środków w czasie, drugi szczegółowy spis, która usługa, w którym projekcie i jakim okresie czasu pobrała daną sumę z konta rozliczeniowego.

Polecamy też korzystać z narzędzia Cloud Monitoring (o którym już wspominaliśmy nie raz), w którym ustawisz własne reguły wysyłania powiadomień, dotyczące niemal każdego aspektu – poziomu użycia usług, wykorzystania procesora, pamięci, przestrzeni dyskowej, obciążenia sieci czy innych. Powiadomienia możesz otrzymywać na maila, SMS-em, na Slacka, PagerDuty czy przez inny zintegrowany kanał.

Implementacja awaryjnego wyłącznika

Niestety, dotychczas jeszcze żaden dostawca usług chmurowych nie zaoferował funkcjonalności automatycznego wyłączania usługi po osiągnięcia określonego pułapu kosztów. Jednak w Google Cloud Platform można stworzyć i zaimplementować taki skrypt (który jest nawet opisany w oficjalnej dokumentacji).

Mechanizm wykorzystuje usługi GCP, z których większość jest darmowa lub dostępna bezpłatnie w ramach odnawialnych miesięcznych limitów. 

Tutaj znajduje się instrukcja, jak stworzyć i zaimplementować mechanizm kill switch.

Bezpłatne limity

Obok vouchera na start (300 USD od Google lub 500 USD od partnera), możesz korzystać też bezpłatnie z najpopularniejszych usług Google Cloud Platform dzięki Free Tier – bezterminowemu programowi miesięcznych limitów użytkowania. Na Free Tier składają się między innymi:

  • instancja f1-micro (0,2 vCPU i 0,6 GB pamięci) w usłudze maszyn wirtualnych Compute Engine,
  • 28 godzin instancji klasy “F” (frontend instance) oraz 9 godzin instancji klasy “B” (backend instance) dziennie na platformie developerskiej App Engine,
  • jeden klaster w usłudze Google Kubernetes Engine,
  • 2 miliony żądań miesięcznie w Cloud Run,
  • 5 GB przestrzeni dyskowej w usłudze Cloud Storage,
  • 1 GB w usłudze bazy danych NoSQL Firestore,
  • 1 TB zapytań oraz 10 GB przestrzeni dyskowej w BigQuery,
  • 60 minut transkrypcji mowy na tekst w Speech-to-Text,
  • limity usług wykorzystujących uczenie maszynowe, m.in. rozpoznające obrazy i wideo AutoML Vision oraz AutoML Video czy rozumiejąca treść pisaną usługa AutoML Natural Language.

Z limitów Free Tier można korzystać również mając aktywne bezpłatne środki z vouchera. Dopiero po przekroczeniu określonego dla każdej usługi pułapu środki zaczną być pobierane z konta. Jeśli chcesz kontrolować, kiedy nastąpi ten moment, ustaw alerty na limity Free Tier dla poszczególnych usług.

Wsparcie partnera Google Cloud

Dokumentacja Google Cloud jest obszerna i raczej… nudna. Kto chciałby przekopywać się przez setki podstron i poznawać od kuchni daną usługę chmurową, kiedy w tym czasie można pisać kod? To zadanie można oddelegować do firmy partnerskiej, która ma w swoich szeregach certyfikowanych inżynierów i architektów chmury. Dobra rada nic nie kosztuje, a może przełożyć się na uniknięcie wielu nieprzyjemności czy niepotrzebnie wysokich rachunków, a także postawić organizację w lepszej pozycji w obliczu fakapu.

Webinar o podstawach bezpieczeństwa w chmurze Google

Chyba wypadałoby to wreszcie napisać: chmura nie jest straszna, ale trzeba wiedzieć, jak z niej korzystać. 

Dlatego zapraszamy na bezpłatny webinar o podstawach bezpieczeństwa w chmurze, który poprowadzą Mateusz Chmielewski – Head of GCP, Cloud Architect w FOTC oraz Bart Madajewski – Customer Engineer w Google Cloud. Podczas wydarzenia dowiesz się więcej, na co zwracać uwagę przy początkowej konfiguracji konta i usług, jak zabezpieczyć infrastrukturę przed popularnymi i bardziej wyszukanymi metodami ataków hakerskich oraz w jaki sposób zapobiegać lub minimalizować skutki potknięć swoich lub innych osób z zespołu.

Webinar jest organizowany przez polskiego partnera Google Cloud – firmę FOTC – i odbędzie się 9 listopada 2021. Zapraszamy do zapisów przez formularz kontaktowy  

Niniejszy artykuł jest artykułem sponsorowanym. Autorką jest Ida Ożarowska, Content Manager w FOTC.

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

38 komentarzy

Dodaj komentarz
  1. Jeden z linków (Tutaj znajduje się instrukcja, jak stworzyć i zaimplementować mechanizm kill switch.) ma chyba double-escaping ostatniego slasha albo hasha.

  2. Mi kiedyś GCP naliczyło 1000zl kosztem transferu z USA za ddosa. Anulowali , ale kazali obiecac ze zabezpieczę i to się nie powtórzy. Był weekend i dzwoniły do mnie jakieś numery zagraniczne, ale kto by to odbierał w sobotę wieczorem.

  3. Dobry artykuł. Doczepiłbym się tylko do opisania Cloud Run jako “jednej z najdroższych” usług compute na GCP. Prawidłowo użyte Cloud Run jest tanie i stosunkowo niezawodne — używam go produkcyjnie w wielu projektach od paru lat. Kluczowe jest wykorzystywanie frameworków “asynchronicznych”, gdzie nie marnuje się zasobów na oczekiwanie na I/O. Odkąd da się również zdefiniować min_instances, to jest to świetne narzędzie do backendów usług, które zazwyczaj mają jakiś znany poziom trafficu, ale od święta dostają dużym spike’m.

    Co do GCP to dodałbym że należy pilnować developerów, żeby NIE generowali kluczy i innych sekretów — i zamiast tego wykorzystywali do wszystkiego system-managed keys udostępniane przez serwery metadanych dostępne na każdym compute resource. Tak do autentykacji z innymi usługami GCP jak i zewnętrznymi serwisami. W normalnej praktyce developerskiej na GCP nie ma żadnego uzasadnienia tworzenia lokalnych kluczy czy innych sekretów. Do wszystkiego obecnie jest usługa, która u podstaw ma autentykację za pomocą system-managed keys, i autoryzację za pomocą IAM. Czy to będzie REDIS podpięty do Cloud Run przez Serverless NEG, czy klaseter z Elasticiem, nie ma powodów hardkodować jakichkolwiek sekretów, a za wygenerowanie klucza SA i wrzucenie go do repo powinni odbierać legitymację programisty na 3 miesiące.

    • Za pisanie “autentykacja” zamiast uwierzytelnienie powinni odbierać autorowi klawiaturę na 3 miesiące.

    • @Michal

      Jak zapłacisz @Lukasz’owi przez te 3 miesiące pensję cloud engineera z dodatkiem managerskim, to se zabieraj tę klawiaturę. A jak Cię nie stać, to się nie wtrącaj.

  4. A co to za farmazon ? “…Dobra rada nic nie kosztuje…”.Nie pierwszy i nie ostatni kotry nacial sie an “doskonale dzialajaca chmure i obnizenie kosztow etc.”Przeciez uslugi chmurowe z punktu decyzji politycznych i technoilogicznych roziazan to zlo.Zlo wciskane firma jako super dobre rozwiazanie.A w zyciu.Korporacje sobie moga korzystac jak maja kadre monitorojaca i umowy itp itd.Zwykle mniejsze firmy i osoby prywatne beda obgryzac paznokcie.I zadne podpianie kart na ktorych sa pieniadze wspolne czy glowne srodki.I zadnych umow typu faktura za “robura”.

  5. 6. Podpięcie karty od głównego rachunku bieżącego.

    Jak ktoś chce kontrolować wydatki, zakłada oddzielne subkonto pomocnicze z kartą debetową – tylko do opłacania chmury. W razie potrzeby subkonto zasila się ręcznie przelewem z innego konta.

    • I co z tego, że podepniesz inną kartę? Przecież Google nie ściąga z niej pieniędzy na bieżąco, za dzień/tydzień/miesiąc wystawi fakturkę na 70k USD i musisz ją opłacić. Czy z karty, którą podpiąłeś, czy innej to już nieistotne.

    • GCP już drugi rok wprowadza pre-paid na chmurę (przynajmniej oni jako jedyni ogłosili, że wprowadzą) :P

    • @Dominik

      Rzecz w tym, że jednak w innej pozycji jesteś gdy już Ci ściągnęli z karty. Wystawiona faktura daje jednak czas na reakcję.

    • @Kie, w Azure od bardzo dawna jest prepaid PayAsYouGo

  6. f1-micro już nie jest Free Tier, od września przenieśli tę usługę na e2-micro (2 vCPUs, 1 GB memory)

  7. Ja polecam kolejną metodę zabezpieczenia, polecaną przez praktyków: założyć spółkę zoo z małym kapitałem i wszelkie wdrożenia i testy chmurowe prowadzić na taką spółkę, a nie na siebie czy pracodawcę i w razie czego ogłaszać bankructwo tej spółki zoo… :D

    • Prawdziwie polskie rozwiązanie. :)

    • Spółka z.o.o może odpowiadać. Lepiej LLC w UK z kapitałem 100 Funtów jako właściciel spółki z.o.o. Jeżeli w Polsce koniecznie to Sp. z o.o. sp.k.

    • @zibi34 – Nie! To rozwiązanie nauczone od Brytyjczyków! :)

  8. Przyjdzie jeden z drugim bez wiedzy, wejdzie w chmurę na ślepo i o taki efekt, a potem chmura ble, bo 100 koła na minusie. Nie wiem czy to jest lenistwo, czy co, że ludzie nie chcą najpierw poczytać, dowiedzieć się, zapytać, doszkolić? Qwiklabs puchnie od kursów, Google czy Partnerzy jak i inni dostawcy usług chmurowych robią co chwila webinary czy jakieś szkolenia, wystarczy chcieć się uczyć.

    • @Andrzej Kruszewski

      Wg mnie najbardziej jest to pośpiech. Pod presją klienta, rynku, szefa, rodziny, kumpli (niepotrzebne skreślić). Szybko mieć efekt, ch* z tym za jaką cenę. No i jest efekt, wprawdzie nieco inny niż zamierzony, ale na pewno zauważalny ;-)

    • @stukot No i finalnie ludzie zrażają się do chmury. Wszystko jest dla ludzi, tak jak on-premise nie jest dla wszystkich tak i chmura ma plusy i minusy. Nie dzieliłbym włosa na czworo. Lepiej “stracić czas i trochę pieniędzy na naukę niż później stresować się fakturą na 100 koła xd

  9. Protip: Nie używając chmury nie dostaniesz rachunku na 100k USD po weekendzie.

  10. Wszystko pięknie, ale problem jest taki, że chmury powinny ustawiać na start twardy limit budżetu np. 500zł oraz dawać super łatwą możliwość ustawienia górnego capa na całe konto i nie byłoby takich cyrków. Trzeba się już trochę znać, żeby taki limit skutecznie uatawić.

    • Podręcznik do GCP mówi na jednej z pierwszych stron, że IAM i Cloud Billing et consortes to podstawa (i powtarza to przez całą książkę). Można mieć setki lat doświadczeń, ale czasem warto wrócić do książek.

  11. Ludzie mysla, ze chmura to przyszlosc – ja natomiast osobiscie uwazam ze nigdy w pelni nie zastapi ona bardziej tradycyjnych form oddawania czci diabłu… :p

    • @WkurzonyBialyMis90210

      :D

  12. Miałem kiedyś 2 maszyny w AWS które wymieniały między sobą spory ruch. Przez niewiedzę puściliśmy ruch przez internet gateway (tak że wychodził z AWS i zaraz do niego wracał) zamiast wewnętrznie w ramach VPC (co gwarantowałoby darmowy ruch). Nabiło nam niecałe $5k zanim się zorientowaliśmy :P

  13. Te historie mogą skutecznie odstraszyć wiele osób. Z drugiej strony chociażby Google podchodzi do tematu uczciwie i potrafi anulować rachunki nabite na wskutek działania hakera, wiec dopóki ktoś tam ma trochę empatii to nie trzeba aż tak się obawiać.

  14. Pytanie nowicjusza – czemu przy zapisach na webinary wymagane są maile służbowe? Jak są później wykorzystywane?

  15. To już chyba lepiej w ramach inwestycji postawić swój serwer o takich parametrach jakich się potrzebuje, samodzielnie go skonfigurować w zależności od potrzeb, nadzorować, aktualizować, zapewnić mu źródło awaryjnego zasilania i niech pracuje na siebie

    • Dokladnie, ze swojej strony dodam ze duzo racjonalnych przeslanek za przejsciem do chmury w miedzyczasie (lata jak nie dekady wdrazania) zostalo rendered obsolete (uczynione przestarzalymi? przestarzone?) przez ewolucje samych systemow/serwerow i ich komponentow. Karty graficzne to praktycznie dawne superkomputery, zarzadanie energia i zasobami poszlo na przod cale poziomy, systemy ktore da sie rozbudowywac praktycznie “na zywca” sa dostepne nawet dla klientow retail (w sensie zwyklego kowalskiego).

      Wylicz sobie zalety chmury, a potem porownaj z usprawnieniami technologicznymi na nowych serwerach – wiele zalet jest obecnie redundant (redundancjowane? powtarzalnych w sobie?) a wady sa gdzie byly…

  16. Najlepsze sa projekty typu. Testowki postawimy w chmurze bo taniej i szybciej. A potem jak to idzie on-prem na prod to macierze i serwery staja :-). Bo wlasnie na dev sie rozskalowalo i nikt nie zobaczyl ile IO potrzeba……

  17. Chmura = dajcie nam frajerzy swoje dane. Nikt tego nie uzywa do powaznych rozwiazan poza miedzynarodowymi korpami, ktore i tak pracuja dla tych samych wlascicieli. Inni trzymaja sie od tego inwigilacyjnego syfu tak daleko, jak sie tylko da.

    • @p0k3m0n
      Nick równie poważny jak ten komentarz.. jeszcze powiedz nam o tym spisku który rządzi światem, o jaszczurach i nanorobotach w szczepionkach :D

    • Mnie bardziej zastanawia ten płacz nad “słabą adopcją” rozwiązań chmurowych. Gdyby ludzie wiedzieli ile się da wycisnąć z VPS’a za 20 zł miesięcznie, to by ta adopcja jeszcze spadła. Niestety niski poziom edukacji, a raczej zabijanie wyobraźni wśród przyszłych programistów to niepowetowana strata. 8c/16 GB RAM nie dawał rady prostej aplikacji. 10 minut oglądania bazy bez kluczy wystarczyło. Po założeniu kluczy – downgrade do 2 rdzeni i 6 GB, a serwer się nadal nudził. O czym wy tu opowiadacie? O 1% firm, które na tym wyjdą na swoje? Absurd na podobnym poziomie jak naganianie małym firmom aplikacji SPA. Technik stworzonych przez firmy które na nie stać.

  18. Świetny artykuł!

  19. Chyba ktoś nie ogarnął.
    Po tym arcie nikt normalny nie kupi usługi w chmurze…

  20. Dawniej w telefonach ludzie też nabijali wysokie rachunki bo monopolista ich nie zabezpieczył.

    Google to taki właśnie monopolista.

    Obecnie w telefonie mam limit wydatków 700zl i potem blokada.

    Pewnie Google też kiedyś będzie robił że limit jest domyślny, a dopiero na specjalny wniosek można go zwiększyć.

    Tylko ktoś musi Google do tego zmusić tak samo jak telekomy…

  21. Zastanawiam się nad dwiema rzeczami. Po pierwsze – czemu dostawcy usług chmurowych nie mają opcji prepaid ? Doładowuję konto określoną kwotą i powiedzmy gdy zostaje 30,20,10% środków dostaję alerty, a gdy jest 0 – wszystkie usługi są zatrzymywane. Na produkcję się to oczywiście nie nadaje,ale na dev/qc/qa jak najbardziej tak i pozwala bez stresu o rachunek testować ? Po drugie – czy taki niebotyczny rachunek wskutek błędu przy braku możliwości ustawienia „twardego” zabezpieczenia/limitu wydanych pieniędzy nie podpada pod artykuł kk o doprowadzeniu do niekorzystnego rozporządzania mieniem (wiem ze z „grubej rury”, ale pytam jak najbardziej poważnie) ?

Odpowiadasz na komentarz Mike

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: