21/5/2024
Chmura taka bezpieczna, bo nawet jak “dozna awarii” to — ze względu na architekturę — dane są zduplikowane w innych rejonach (centrach danych) i mogą być łatwo odtworzone. Otóż nie zawsze. Boleśnie przekonała się o tym całkiem spora organizacja, która zarządza finansami na emerytury 650 000 osób. Posłuchajcie historii jak z horroru, gdzie administratorzy tracą wszystko, co trzymali na swoich kontach Google Cloud.
Nie mamy pańskiej chmury i co nam Pan zrobi?
Bohaterem tego materiału jest UniSuper, fundusz emerytalny z Australii warty 135 miliardów (!) dolarów. To jego konto na chmurze Google Cloud zostało skasowane. Łącznie z backupami.
Do incydentu doszło 2 maja i tylko dzięki kopii danych, którą na własną rękę UniSuper wykonywał poza infrastrukturą Google, funduszowi udało się odzyskać sprawność. Po 2 tygodniach walki. Tak na marginesie, transparentność w kwestii opisu tej walki jest godna pochwały. Każdy z Was może się zapoznać z kilkunastoma oświadczeniami, które pojawiały się dzień po dniu, a czasem i kilka razy dziennie.
Niestety, w tych dokumentach na próżno szukać technicznego wyjaśnienia fuckupu Google. Co jednak ciekawe, w jednej z notatek o incydencie opublikowanej 8 maja, UniSuper cytuje też Thomasa Kuriana, CEO Google Cloud. Jeśli spojrzymy na to jak istotnym klientem jest dla Google UniSuper, to nie powinno nas dziwić, że w obsługę incydentu zaangażował się sam prezes Google Clouda:
(…)zakłócenie wynikało z bezprecedensowej sekwencji zdarzeń, w wyniku której niezamierzona błędna konfiguracja podczas dostarczania usług Private Cloud dla UniSuper ostatecznie doprowadziła do usunięcia subskrypcji Private Cloud dla UniSuper. Jest to odosobniony, „jedyny w swoim rodzaju przypadek”, który nigdy wcześniej nie wystąpił u żadnego z klientów Google Cloud na całym świecie. Nie powinno to było się wydarzyć. Google Cloud zidentyfikował zdarzenia, które doprowadziły do tego zakłócenia i podjął kroki, aby zapewnić, że nie powtórzy się to w przyszłości.
Z analizy post-mortem wynika, że UniSuper miało tzw. duplikację w dwóch regionach geograficznych jako zabezpieczenie przed awariami i utratą danych. Ale usunięcie subskrypcji spowodowało usunięcie danych w obu regionach. UniSuper miało też kopie bezpieczeństwa swoich danych składowaną w Google Cloud. Ale ta też została usunięta.
Może kiedyś dowiemy się, co konkretnie nie zostało przewidziane przez inżynierów Google — na razie są tylko żarty, że Google jest dobre w kasowanie swoich usług. Zarówno tych, których już nie potrzebuje (RIP Google Reader!), jak i aktualnie świadczonych usług ;)
Nie ufaj nikomu
Firma podniosła się tylko dzięki temu, że kopię trzymała u “innego dostawcy”. I niech to będzie nauczką, dla wszystkich, którzy po migracji do chmury dochodzą do wniosku, że sama wbudowana w chmurę “duplikacja” danych wystarczy jako backup. Nie wystarczy. Póki macie możliwość, zróbcie sobie kopie bezpieczeństwa off-cloud — to rada na dziś. I to niezależnie od tego, z jakiego dostawcy usług chmurowych korzystacie.
UniSuper przy tej wielkości podniosło się po 2 tygodniach. Ciekawe ile podnosiłby się nasz ZUS…
Ciekawi nas też, czy, a jeśli tak, to w jakiej wysokości odszkodowanie Google wypłaci UniSuper?
Aktualizacja (29.05.2024 09:58)
Google odniosło się do tego incydentu na swoim blogu. W skrócie: to pusty parametr był przyczyną skasowania środowiska klientowi:
“As a result of the blank parameter, the system assigned a then unknown default fixed 1 year term value for this parameter.
After the end of the system-assigned 1 year period, the customer’s GCVE Private Cloud was deleted. No customer notification was sent because the deletion was triggered as a result of a parameter being left blank by Google operators using the internal tool, and not due a customer deletion request.”
Co ciekawe, Google informuje też, że — wbrew temu co twierdzi UniSuper — backupy nie zostały skasowane, choć były również w infrastrukturze Google, równocześnie jednak potwierdza, że do restore UniSuper wykorzystało backupy także z innego źródła.
Weź udział z kolegami w jednym z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te krótkie szkolenia! Niektóre z nich są darmowe. Wszystkie to praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy.
To przez wielkie EGO googla bo stwierdzili, że nikt nie rezygnuje z ich usług :) więc w regulaminie zapewnie brak wzmianki, że po anulowaniu subskrypcji masz 30 dni na pobieranie swoich danych :D a tutaj zadziałała prosta reguła anuluj = delete now !
Gogl to alfabet czyli ludzie literaki pewnie jakiś pracownik nagminnie czytał sobie o maga w pracy i ich automat napisany przez “furasa” automatycznie usunął im wszystko. Przecież kazdy pamięta incydent z pewnej drukarni gdy osoba zamówiła książkę “braznową” i dostała w niej dopisek od magazyniera “A dupa cie nie boli”. Nie wspomnę o osobach które pisały że ich pedały w rowerze są zepsute na youtube i traciły całe swoje konto (dokładnie tak jak się stało w tym artykule). Wiec należy się zastanowić czy czynnik ludzi oraz preferencjie polityczne pracowników nie wpłyna na pozycje w wyszukiwarce twojej korporacji bo tak pewnie mozę jest
Adam, nie wziąłeś chyba leków
Apple przywraca usunięte dane to źle. Google usuwa ludziom dane też źle.
Nie da się ludziom dogodzić.
Microsoft z kolei chce wszystko nagrywać i też oburzenie…
@Piotr Konieczny, najgorzej, bo ludzie się tak uzależnili od Mixrosoft Windows, że dalej będą tego używać, mimo, że będą przy tym łamać RODO ONI, a nie Microsoft. Microsoft jako firma produkująca soft może wyprodukować dowolny soft robiący cokolwiek, zaś to do ADO należy obowiązek oceny zgodności przetwarzania danych. I tak, niezgodne z RODO jest użyanie MS Teams, ponieważ dane biometryczne pracownika lądują w USA bez jego zgody (pracownik-pracodawca to stosunek nierówny). Do tego teraz pomyślmy co się stanie z naszymi kartotekami medycznymi, gdy przychodnie będą pozwalali AI nagrywać to co przeglądają, czyli nasze dane medyczne.
Pora by ludzie się zaczęli o to upominać, jak również o wyniesienie wszelkich szpiegusiuów z gabinetów – ja już zaczęłam. Już udane 3 żądania wyniesienia smartfonów, smartwatchy i ipodobnego sprzętu z gabinetu. Tylko aby Google nie wiedział na co chorujemy i na co się leczymy, potrzeba też odciąć od tego Microsoft. Tu sprawa jest trudniejsza, bo wymagane jest prawnie prowadzić dokumentację w postaci elektronicznej. POTRZEBNY JEST PROTEST PRZECIWKO ELEKTRONICZNEJ DOKUMENTACJI MEDYCZNEJ.
Od siebie mogę zaoferować pomoc w przepisywaniu oprogramowania typu Płatnik oraz systemów medycznych pod Linuxa. Pora wyrzucić Windowsa i przejść na Linuxa, który nie szpieguje o ile nie używa się KDE i nie zainstaluje się szpiegowskiego oprogramowania w nim.
Aż ciśnie się na usta ożeż k… ja p…
Jak można ot tak skasować dane bez kilkutygodniowej retencji? Przecież proces kasowania danych powinien być kompletnie odrębny, jako kolejka, której nie da się przyspieszyć.
Kwestia odszkodowania też jest ciekawa, najczęściej w regulaminach usług mowa co najwyżej o zwrocie za czas nieświadczenia usługi, ale tu może być grubo na gruncie australijskiego prawa. Oby Google dostało po głowie za takie “przeoczenie”.
Usługa chmurowa, nawet jak nie działa, to kosztuje (choćby za przechowywanie). Z tego względu usunięcie subskrypcji _powinno_ kasować wszystko.
Szkoda, że nie jest dokładnie wyjaśnione, co się stało, ale stawiam na jakiś błąd w bilingu, który uznał, że ma zapłaty w terminie, i skasował usługę.
Co do odszkodowania, to pytanie, kto zawinił. Tej wielkości usługa to raczej nie opłacała się z karty kredytowej, tylko wystawiała faktury co miesiąc i czekała na przelew (być może z udziałem jakiegoś pośrednika).
Czyli to jednak nie paranoja, że używam 4 niezależnych dostawców chmury (+ backup u piątego) i 2 niezależnych dostawców DNS…
A na dodatek użyj backupa rekordów dns na pendrive albo na dyskietce
Za to wywiady medyczne i inne rozmowy podsłuchane przez Google „bo tak jest lepiej” nie zginęły i nigdy nie zginą. Google widać dba wyłącznie o własne dane, a nie o dane klientów, którzy bezpodstawinie i naiwnie mu zaufali.
Pora by ludzie zrozumieli, że oddawanie danych do chmury to jest jedynie ich publikowanie (daner te stają się de facto publiczne lub takie się staną) i powinni zacząć szyfrować wszystkie dane przed wrzuceniem ich do chmury.
Dalszego miłego używania szpiegusia (smartfona) i codziennego dzielenia się z google wszystkim co robicie, w tym swoimi danymi o chorobach i danymi biometrycznymi, które będą przydatne po wprowadzeniu CBDC.
Ludzie zaczęli uznawać chmurę jako jakieś remedium na wszystko, zupełnie zapominając o czymś takim, jak podmiotowość.
Dalej sprawdza się powiedzenie, że chmura to po prostu “dysk u kogoś innego”. I to będzie działać, jeśli “chmurę” zaczniemy traktować po prostu jako dysk – tak, on tam ma “w sobie” różne mechanizmy zabezpieczeń, ale ostatecznie chmurą kieruje jakiś podmiot X, u którego mamy usługę. Podmiot spadnie z rowerka albo go upaństwowią czy cokolwiek innego się stanie, i mamy odpowiednik trzymania danych na jednym dużym dysku…
No to ładnie. Trafiło na grubą rybę więc się nad tym pochylili – ciekawe jak by to spotkało dużo mniejszą firmę, która by się już nie podniosła.
Klasyk – dzielimy firmy na te, które robią backupy i te …., które będą robić ;)
Google ma taki burdel w tych swoich api, że wcale mnie nie dziwi taki przypadek w kontekście usług. Przekonałem się o tym jak musiałem połączyć analytics z adsami, gdzie dane były rozjechane totalnie i jeden zespół odsyłał tylko do drugiego.
Odszkodowanie pewnie nie będzie spektakularne, bo firma w końcu stanęła na nogi. Co najwyżej za przestój
Ciekawe kto ubezpiecza Google Cloud i do jakiej kwoty :D
Poprawcie stopkę :) Wszelkie prawa zastrzeżone © 2009- echo date(“Y”);
It’s a feature, not a bug.
Pokaż, że jesteś nowy na Niebezpieczniku, nie pisząc, że jesteś nowy na Niebezpieczniku. XD
Pierwszy!
Fakt, częstym gościem tu nie jestem :)
No to wygląda na profesjonalnie przetestowany scenariusz disaster na produkcji by google tylko pewnie account powymieszały się od tego randoma i trafiło na szczęśliwe konto
Miałem dokładnie taką samą sytuację jak na MacBooku zrezygnowałem z iClouda na rzecz innego dostawcy, w dniu zakończenia subskrypcji wszystkie dane z folderu Dokumenty po prostu sobie wyparowały – bez powiadomienia, bez możliwości przywrócenia z kosza.
Dobry pendrive lub dysk zewnętrzny to niewielki wydatek, zaś ostatnio Mozilla mi pokazała że jest niewiele lepsza – miałem zapisane zakładki i hasła z kontem Firefox, po zmianie hasła również sobie wyparowały, dobrze że miałem zgrany pliczek dzięki czemu przywróciłem.
Nie ufajcie chmurom, ufajcie swoim nośnikom.
Przypomne bo wciaz w sklepach jest i sprzet i nosniki – na bardzo krytyczne dane mozna sobie zrobic backup na M-Disc’ach (25GB-100GB / nosnik).
Z bardziej popularnych, zewnetrzne dyski 2.5″ “sa latwe tanie i przyjemne” bo wystarczy im zasilanie z kabla usb ktorym przesylasz dane.
I WRESZCIE :p te pendraivy: Na samsungu sie jeszcze nie przejechalem, jest tez pare innych wzglednie sensownych – ale spora czesc nosnikow ze sklepu ma taka wade ze potrafia z nich wyparowywac dane (kontroler USB tez wydaje sie miec na to jakis wplyw).
Podejrzewam ze wiele osob nie zdaje sobie sprawe ze dane +/- stracilo, bo o ile nie masz w nawyku wrzucac pliku z sumami kontrolnymi, to symptomow nie uswiadczysz dopoki nie narobia szkod poniewarz flashdrive nie zwroci kodu bledu jak tradycyjny nosnik tylko beszczelnie zapoda zle dane w miejsce brakujacych…
Np. Kiedy taki zepsuty bit trafi na dane systemu plikow: “mowisz, ze ten plik jest na pendraiwie? bo ja go nie widze” albo “niesformatowany? to gdzie jest ten na ktorym trzymalem dane?”
Ps. I wiem jak dziala USB i to nie jest buffering – na pierwszej maszynie zapisuje sie poprawnie na innej dane tez sa ok, przez pierwszy tydzien czy dwa ale poczekaj pare miesiecy i nagle zaczyna pruszyc niewlasciwymi sumami losowo ale zgodnie z rachunkiem prawdopodobienstwa (po wielkosci, bo prawdopodobienstwem jest: wielkosc / ilosc straconych bitow wystarczajaca do ubicia pliku (zazwyczaj = 1)).
Mam backup na chmurze. Szyfrowany. W zasadzie to kopię backupu, który leży u mnie w domu :P
Narzekanie na “chmurę” jest zawsze w modzie, ale przy backupach należy się zawsze trzymać starej, sprawdzonej zasady 3-2-1:
– Miej co najmniej 3 kopie danych (oryginał i przynajmniej 2 kopie)
– Na co najmniej 2 typach nośników
– Przynajmniej 1 poza siedzibą
Jak widać potrafi to uratować firmę od katastrofy.
A uczono jeszcze niedawno, że “nie należy mnożyć bytów bez potrzeby”
Zależy gdzie. “Od zawsze” dobrą zasadą budowania DNS było rozproszenie secondary po różnych lokalizacjach, najlepiej z różnymi dostawcami internetu. Taśmy z backupami też były wywożone w bezpieczne lokalizacje, z dala od siedziby firmy.
Wbrew marudzeniom malkontentów, chmura ułatwia zbudowanie dobrego systemu backupów, bo załatwia przechowywanie danych w kilku lokalizacjach i na różnych nośnikach. Tyle że zasada redundancji działa i tutaj: Traktuj jednego dostawcę przestrzeni dyskowej jako jedną kopię danych. Miej inną kopię u innego dostawcy, oraz łatwo dostępną kopie na fizycznym nośniku, na wypadek potrzeby odtworzenia danych przy totalnej awarii sieci.
Ale tego adminom chyba nie trzeba tłumaczyć.
Dokładnie. Wężykiem, wężykiem podkreślić. To mój schemat backupu. Nie wyobrażam sobie innego no chyba że jeszcze wyższego. Polegać tylko na chmurze no gratulacje. Dziś chmura jest jutro nie ma a jeszcze może spaść deszcz ;) Do dziś pamiętam jak kiedyś uratowałem studentce jej dyplom na dyskietce. Kopie zapasowe bezpieczeństwa święta rzecz.
Nigdy nie rozumialem ludzi ktorzy trzymaja w chmurze, dlatego po aferze z vultr’em po prostu zaszeregowalem ich razem z amebami:
https://www.theregister.com/2024/03/28/vultr_content_controversy/
Ps. Odnosnie:
> podniosła się tylko dzięki temu, że kopię trzymała u “innego dostawcy”
To jak to napisali, sugeruje, ze na 90% pracownik zwiazany z ekstra backupem zbierze(zbieral) bure xD
Chmury dziś są, jutro ich nie będzie. Więc trzeba je obserwować i unikać
Tu jest opisane zdarzenie dla dużej firmy. Ja opowiem swój przypadek indywidualny. W zeszłym roku na smartphonie (Samsung Galaxy S22+) na poczatku listopada zmieniłem hasło. Niestety hasło zapomniałem. Pamietałem, że Samsung oferuje usługę smart things find , którą kiedyś na jakimś Galaxy sprawdzałem i ładnie telefon mi odblokowało. Niestety przez STF samsunga S22+ nie mogłem odblokować, usługa tylko pokazywała czasami lokalizację, poziom baterii. STF generalnie dawał komunikat, że z końcem listopada 2023 roku odblokowanie będzie wygaszone (usługi się zmienią). Zażenowany podjąłem kontakt przez Chat Samsunga i dostałem wyjaśnienia, że nie da się z tym nic zrobić, szkoda bo jak pisałem działało to. Wracając do Google, przypomniałem sobie, że oni też mają podobną usługę Find My Device, pozatym pracownik Chat Samsunga mówił, że FMD przejmuje usługi Samsunga. Dobra wchodzę na FMD, urządzenie jest widoczne, piszę prośbę o odblokowanie na pomocy FMD Google. Sprawdzam co jakiś czas i nagle urządzenie znika z listy FMD Google. Kiepsko :/
Miałem taki sam problem z Samsung S23, tylko, że pamiętałem hasło. Nowy telefon, ustawienie hasła i włączyła się aktualizacja systemu. Po aktualizacji telefon uważał, że “wprowadzone hasło jest niepoprawne”. Próbowałem odblokować przy pomocy smart things find, ale nie chciało odblokować.
Pomógł fabryczny reset i zamiast hasła używam pinu, wtedy wszystko działa.
Hasło do konta Google? Hasło (kod) do odblokowania telefonu? FMD służy do lokalizowania urządzenie ewentualnie zdalnego blokowania/resetowania w przypadku kradzieży lub zgubienia.
Daniel Hasło (kod) do odblokowania telefonu. Na (jak dobrze pamiętam) Galaxy S6 usługa smart things find STF dawała możliwość zdjęcia kodu telefonu, myślałem że FMD też to umożliwia, ale dają tylko zdalną blokadę, odblokowanie, lokalizację. Po odblokowaniu FMD kod do telefonu nadal wymagany. Serwis telefonów, rozkłada ręce, mówią że gdyby było włączone Debugowanie usb to jest możliwość. Ja znalazłem Dr Phona może z niego skorzystam i równolegle próbuję przypomnieć sobie kod.
Dali bekap w 15 miejscach, ale skrypt zakładał ON DELETE CASCADE hehe
Z dziś u nas. Padł nasz wewnętrzny serwer z oprogramowaniem medycznym i wszystkimi danymi pacjentów. Poszło w nocy przepięcie i spalił się i UPS i zasilacz w serwerze i płyta główna i padły wszystkie komponenty. Jaka była szansa, że nie zadziała żadne zabezpieczenie i padną wszystkie 3 dyski twarde, również te z kopiami zapasowymi? Na szczęście została nam 1 kopia zapasowa w szufladzie, na pendrivie, sprzed miesiąca. Chmura byłaby złotym rozwiązaniem? Jak widać — nie.
Czy mam rozumieć iż dyski podstawowe i z kopiami były na tym samym serwerze? Jeśli tak to jest to żadne zabezpieczenie w tym przed przepięciami. Swego czasu analizowałem przypadek znajomej firmy – zaszyfrowane dane na serwerze przez ramsonware – kopie były… ale na tym samym serwerze… więc też zostały zaszyfrowane
nie trzymam danych na tym òwnie wole swoje dyski :p
“UniSuper przy tej wielkości podniosło się po 2 tygodniach. Ciekawe ile podnosiłby się nasz ZUS…” – trzeba bylo tego nie pisac. Moze przeniesliby sie do chmury i mielibysmy spokoj :-)
Podczas szkoleń z systemu Novell Netware w latach 1995-2002. Najważniejszą kwestią jaką poruszano, to backup’y danych. Inżynierowie Netware, którzy przeprowadzali szkolenia, dosadnie podkreślali, że jeśli chcesz mieć sprawną kopię danych, to musisz mieć 3 kopie, każdą schowaną w innym miejscu. Te dane były podawane jako minimum, które należy spełnić, aby w miarę spokojnie spać. Utrata danych nie zdarza się zbyt często, ale jeśli się zdarza, to na wierz wychodzi dużo więcej zaniedbań.
Z doświadczenia z serwerami w bankach i instytucjach, mogę dodać tylko jedno: Kopie to fragment sukcesu. Natomiast zupełnie inną kwestią jest to, czy kopie zostały zweryfikowane w stosunku do danych? (porównanie) Czy te kopie można odzyskać? Czy wszystko jest tak przygotowane, aby w rozsądnym czasie wykonać wszystko i uruchomić firmę.
Z takim kwestiami zmierzy się każdy, kto te dane chwilowo utracił. Zawału też można dostać, więc problem wcale nie jest taki banalny..
Mogę się założyć o to, że mało kto weryfikuje kopie po czasie.. Mało kto sprawdza wyrywkowo pliki, czy są nienaruszone. Sprawdza czytelność nośników kopii itd..
To, co spotkało UniSuper, to naprawdę przestroga dla nas wszystkich, bo każdy obecnie posiada dane cyfrowe które musi gdzieś przechowywać. Trzymanie danych tylko w chmurze może być ryzykowne. Zawsze warto mieć dodatkowe backupy w niezależnych lokalizacjach. Jako osoba zajmująca się stronami internetowymi, zawsze doradzam moim klientom tworzenie regularnych kopii zapasowych, swoich danych firmowych ale również prywatnych.