9:53
2/3/2011

Tydzień temu miałem problem z Google Calendar. Dwa dni temu, 0.08% użytkowników GMaila na świecie (ok. 150 000 skrzynek pocztowych), w wyniku błędu po stronie Google, straciło całą swoją pocztę. Oto czarne oblicze Cloud Computingu i usług w modelu SaaS.

Chmura potrafi wyparować! Od tego jest ona.

Kalendarze, które przez przypadek wyczyściło mi Google w zeszłym tygodniu wróciły po ok. 24 godzinach. Na szczęście miałem kopie na telefonie, który synchronizuję z Google Calendar… E-maile, które 150 000 osób przez przypadek usunięto, wróciły po 12 godzinach. Jak myślicie, ilu z użytkowników “skasowanych” skrzynek miało kopie zapasowe?

Zagrożenia Cloud Computingu

Zagrożenia Cloud Computingu

Bezpieczeństwo przechowywania danych w chmurze

W konteście tych awarii warto zastanowić się nad bezpieczeństwem przechowywania danych w tzw. chmurze (cóż za ironiczna nazwa, chmury wszakże potrafią wyparować — i jak widać dane też ;) 2 lata temu boleśnie przekonał się o tym także Microsoft.

Za chmurą

…przemawia wygoda, i teoretycznie lepsza ochrona danych przed zniszczeniem — dostawcy usług SaaS mają kilka datacenters, rozlokowanych w geograficznie różnych lokalizacjach i synchronizujących (czyt. “duplikujących”) między sobą dane. Mało którego Zwykłego Użytkownika stać na domowy serwer NAS lub zabawy w RAID i zakup kilku dysków.

Przeciw chmurze

…postawić można utratę kontroli nad swoimi danymi (gdzie dokładnie są przechowywane? w ilu kopiach?) i brak prywatności/poufności, jeśli danych nie zabezpieczymy przed umieszczeniem “w chmurze”. Dodatkowo, na przykładzie powyższych awarii pięknie można pokazać, że to co wrzucamy do chmury może niespodziewanie stać się niedostępne (krótko lub długoterminowo) — pamiętajcie, kiedy hosting daje dupy, dobrze wiedzieć, że mam backupy!

Wskazówka dla tych, którym brakuje miejsca na lokalne backupy: W przypadku usług typu GMail warto rozważyć otwarcie drugiego konta i automatyczne dodawanie go w BCC przy wysyłaniu wiadomości, oraz ustawienie filtra automatycznie forwardującego tam każdy otrzymany e-mail. W przypadku kolejnej awarii należy trzymać kciuki, żeby nie objęła ona obu kont ;)

Przypominamy, że w przypadku jakichkolwiek problemów związanych z usługami Google, warto odwiedzić tę stronę. Ciekawe, czy inżynier odpowiedzialny za błąd (ponoć bug w oznaczaniu kont jako nowe/już istniejące) dostał po premii ;)


Przeczytaj także:

36 komentarzy

Dodaj komentarz
  1. Ale utrata kontroli nad danymi moim zdaniem jest pozorna. Bo tak samo od lat tracimy kontrolę nad dużo chyba ważniejszymi danymi – jak dane osobowe, dane o zarobkach, dane o zdrowiu, itp. Dane te przechowywane są w podejrzewam dużo mniej bezpiecznych warunkach na serwerach różnych instytucji, itp.

    I owszem zgadzam się, że chmura nie jest “lekiem na całe zło”, ale moim zdaniem nie warto demonizować (choć owszem w newsie tego nie robicie! i chwała Wam za to) usług w chmurze. Bo generalnie tak jak piszecie – pewnie wielu użytkowników ma dużo mniejszą kontrolę nad swoimi danymi na swoim laptopie niż nad takimi danymi w chmurze.

    O ile wpadki jak widać mogą się zdarzyć, to niejako dużym plusem sytuacji jest to, że pewnie w 99,99% takie wpadki są naprawianie (w sensie technicznym, że dane są odzyskiwane).

    Aczkolwiek zgadzam się, że problemem może być ta czasowa niedostępność. Ale przed nią nie uchronią nas nawet nasze własne serwery, gdzie teoretycznie też może się zdarzyć brak takiej dostępności.

    • Mariuszu, czasowa niedostępność po “naszej”, czyli użytkownika stronie ma jedną zaletę — od razu wiemy, że mamy backupy i oddychamy z ulgą. W przypadku awarii w chmurze zawsze jest ten “dreszczyk” emocji — czy oni to zbackupowali, a jeśli tak, to kiedy? ;-)

      Co do utraty kontroli na d dostępnością, to nie zgodzę się, że jest pozorna. Niech ktoś (zakładam, że masz na myśli firmy/urzędy) trzyma moje dane osobowe, historie chorób, zdjęcie paszportowe, wyciągi z banku. Nie trzyma jednak moich myśli, uczuć, haseł do mojej “online’owej” tożsamości — a GMail (czy inne chmurzaste skrzynki pocztowe) tak…

      Dodatkowo, z mojego punktu widzenia awarie chmury są jak wypadki samolotów. Zdarzają się rzadko, ale dotykają taką liczbę osób, że jest o nich głośno. Zastanówmy się, ile dysków twardych padło Polakom w ciągu poprzedniego tygodnia — i ilu z nich miało te dane zbackupowane… Obstawiam, że statystyka wyjdzie inplus dla chmury.

    • I dlaczego już nie mogę na Twój komentarz Piotrze odpowiedzieć? :)

      Fakt oddech ulgi jak masz backupy jest bezcenny :) W wypadku chmury (jak czytasz umowy) to też masz opisaną sytuację backupu. Aczkolwiek może w wypadku usług konsumenckich nie jest to takie kolorowe.

      Nie przemawia do mnie argument wyższości “myśli, uczuć, haseł” nad (jednak istotnymi) danymi osobowymi. Myślę, że należy zawsze myśleć w kontekście tego, czy bardziej dla Ciebie problematyczne byłoby zobaczyć na pierwszej stronie gazety X historię Twojego konta bankowego/choroby czy list do dziewczyny lub inną wymianę korespondencji z zaprzyjaźnionym gejem. Dla każdego co innego może być gorsze, ale jakoś obstawiam jednak, że bardziej krytyczne są dane, które i tak od lat przechowywane są za nas, bez naszej kontroli, na serwerach urzędów i instytucji, które nie zawsze mają pojęcie (albo chociaż procedury) o bezpieczeństwie. Tu nadal będę się upierał, że (mimo ewentualnych wpadek) lepiej to zrobią firmy typu Google, Amazon czy Microsoft.

      Bardzo dobre porównanie z awariami chmury i awariami samolotów. Jeśli nie masz nic przeciwko – z chęcią dorzucę ten punkt do mojej prezentacji o bezpieczeństwie chmury (których ostatnio sporo robię).

    • Mamy tylko 2-poziomowe komentowanie ;)

      Wracając do meritum — może z artykułu to nie wynika, ale ja również jestem zdania, że Google/Amazon/MS są w stanie lepiej przechowywać dane, gdzie lepszość dostrzegam jako: “gdy coś padnie, oni się tym zajmą, nie ja” za cenę “poczekam na naprawę dłużej niż gdybym sobie sam odtwarzał dane z backupu”, no ale czekam nic-nie-robiąc ;-) Przy czym warto wziąć poprawkę na to, że ja i tak backupuje to co pcham do chmury (tak na wszelki wypadek) i ja potrafię i często korzystam z szyfrowania danych które do chmury wrzucam, w końcu to “niezaufane” środowisko. Chińczy^WAdvanced Persistent Threaterzy ;) przecież pokazali, że sieci komputerowe dużych korporacji z milionowymi budżetami na ochronę sieci nie są odporne na ataki. Ba! robione przez nas testy penetarcyjne dla różnych dużych i ciekawych instytucji ;) też to potwierdzają…

    • A to chyba jest kluczowe: “no ale czekam nic-nie-robiąc” :D Wspominam o tym podczas prezentacji, bo właśnie to chyba często pada jako potwierdzenie “że nie mam kontroli”. Ale mam to samo – jak mam czekać aż mi ktoś odzyska backup to sobie za każdym razem myślę “ile razy ja bym to szybciej zrobił… i w tym czasie nie musiałbym myśleć o tym czy ktoś dla mnie to już robi, czy może to 5 kolejność odśnieżania” ;)

      No i nawiązując do “Advanced Persistent Threaterów” + znając życie… też nie wieszczę, że duże korporacje mają 100% zabezpieczenia :) Ale pewnie statystycznie 4-5 dziewiątek można dać :)

  2. Najciekawsze w całej historii jest to, że przy okazji okazało się, google trzyma backupy na taśmach.

    • Co w tym takiego dziwnego? Sposób uświęcony tradycją, tani, pewny i bezpieczny.

    • Mnie to osobiście dziwi, RPO i RTO, które ma jak widać Google jest chyna trudne do osiągnięcia na kilkuset tysiącach taśm.

    • Taśmy są lepsze. Mieści się na nich znacznie więcej danych ponieważ są wielorazowego użytku. Trudniej te dane uszkodzić, a co za tym idzie odtworzenie backupu jest łatwiejsze. Poza tym są tańsze w magazynowaniu.

    • A czy nie jest tak, że dyski są co najmniej tak samo tanie jak taśmy, dane można łatwiej deduplikować i replikować?. Są też wielorazowe :).

    • @Draj, no niekoniecznie… taśmy nawet po zalaniu można osuszyć i odzyskać dane. Z dyskiem tego nie zrobisz. To jest trochę na zasadzie “stare było lepsze bo mocniejsze”.

    • Ale geograficznie oddalony backup nie musi być odporny na uszkodzenia fizyczne w takim stopniu o jakim piszesz. W momencie utraty danych produkcyjnych backup jest z backupu a w momencie utraty backupu backupem są dane produkcyjne, z których od razu robi się backup, który staje się backupem :D

    • @Draj, ale tu mylimy dwa pojęcia. Backup i redundancję danych. Jeżeli weźmiesz np. bazę Oracle to masz możliwość synchronizacji dwóch baz w ten sposób, że pierwsza chodzi jako “produkcja”, a druga dociąga sobie dane i w razie fail over przejmuje pracę “od ręki”.
      Backup to sytuacja w której np. jakaś funkcjonalność padła, pad się rozpropagował na wszystkie instancje i musisz przywrócić stan konkretnej maszyny. Względnie gdy musisz wykonać rollback stanu do konkretnej daty by usunąć np. błąd. Jak grasz w Ogame to im się czasami zdarza “przywracanie stanu gry z przed X”.

  3. Faktycznie – super mądra rada – zakładanie drugiego konta na tym samym serwerze/usługodawcy. Autor pewnie backup partycji 1 trzyma na partycji 2 tego samego dysku.

    • RTFA, grep po “geograficznie różnych” oraz “obu kont” (nie mówiąc już o tym, że nigdzie nie napisano, że chodzi o drugie konto GMaila).

  4. z tym backupem to różnie bywa, zwykły użytkownik go nie robi a ‘profi user’ postanawiaja go robić jak już się coś spierdzieli ;)

    • Są też tacy, którzy robią regularnie, ale nigdy nie testują odtwarzania (które nie działa, bo …) :>

    • @Piotr, bo ludzi dzielimy na tych co robią backupy, tych co będą robić backupy i tych co potrafią przywrócić dane z backupu. Najgorzej wypada pierwsza grupa, bo myślą na zasadzie “mam zapięte pasy mogę docisnąć do 180”.

  5. jeżeli chodzi o zagrożenia `chmurowe`, to osobiście bardziej martwiłbym się tym, że to co wrzucamy do chmury może niespodziewanie stać się dostępne, DLA WSZYSTKICH (krótko lub długoterminowo) ;D

  6. Nie wyobrażam sobie, aby np. GUS czy Urzędy Skarbowe trzymały swoje/nasze dane w chmurze należącej do zagranicznych koncernów mająych zobowiązania wobec władz swoich państw… Już były akcje ABW i prokuratury, które rządały ujawnienia od GUS-u tych danych, ale dyrektorzy powoływali się na tajemnice statystyczną…. Każda instytucja/firma musia sama podjąć decyzję czy chce, czy też nie oraz jakie dane chce tam przetrzymywać. Im większa firma/korporacja tym więcej poufnych/tajnych danych posiada i choć w przypadku dużych firm zyski z chumry potrafią być znaczące, o tyle nigdy wszystkich danych nie powinny tam przekazywać (ufam, że tak jest).
    A co do backup-u to prawdopodobnie dla wielu właścicieli firm/instytucji/osób prywatnych takei słowo wogóle nie istnieje, lepiej mówić “kopie zapasowe” to przynajmniej coś to niektórym mówi…;)

    • USy czy GUS trzymają dane na własnych serwerach, ale zapewne obsługiwanych przez firmy z zewnątrz w dodatku jako instytucje publiczne podlegają kontroli. Ja bardziej martwiłbym się o firmy prywatne, bo te są tylko kontrolowane przez GIODO, ale tylko w podstawowym zakresie (zgody, dostęp, zabezpieczenia). Jeżeli ktoś by chciał wyjść z Polski z danymi to może to zrobić tak, że nawet GIODO nie będzie tego wstanie odkryć.

  7. Nie ma tego złego. Gdybyś sam miał serwer pocztowy, lub aplikację, w której masz tylko kalendarz straciłbyś bezpowrotnie… Lub bawił się tygodniami na odzyskaniem danych.
    A Google lub inny wielki provider? 12-24h i masz.

    • Wiesz, w ich przypadku procedura tworzenia i przywracania backupu musi być w jakiś sposób opracowana i przetestowana. To w końcu nie jest firma pana Mietka, żeby mogli sobie pozwolić na utratę wizerunku i danych klientów.

  8. Od zawsze wiadomo ,że każdy produkt ma swoje wady i zalety – pytanie tylko czy nie wystarczy zmienić polityki bezpieczeństwa danych w danej przestrzeni i tyle.
    Nie można też zapomnieć iż dla odbiorcy usługi i tak chmura zewnętrzna publiczna jest najtańszym rozwiązaniem bo w sumie darmowym więc nie można wymagać bezpieczeństwa utrzymywanego w stopniu wyższym niż ten standardowy który zazwyczaj się oferuje dla darmowych rozwiązań klienta indywidualnego.
    Po za tym zawsze przed oddaniem swoich danych w ręcę usługodawcy SaaS można poczytać trochę o tym jak postępuje z backupami aby wiedzieć jak stoi z bezpieczeństwem, a jeśli tego nie robi to przecież można poszukać innego dostawcy usługi.

    Johnny, istnieje jeszcze coś takiego jak chmura prywatna zamknięta – w takich miejscach mógłby trzymać dane GUS.

  9. Josué zrobił o tym komiks: http://nerfnow.com/comic/475

  10. Ja mam w dni nieparzyste oprócz weekendów odpalany rdiff-backup najważniejszych danych na drugi dysk. Dane przyrostowe są usuwane te, które są starsze niż 3 miesiące. Raz na miesiąc synchronizuję drugi dysk na backupy z zewnętrznym dyskiem. Oprócz tego najważniejsze z najważniejszych danych mam na 32GB pendraku w portfelu. Wszystko co łatwe do wyniesienia lub zgubienia i zawierające coś cennego (dla mnie) potraktowane TrueCrypt. Chyba jestem paranoikiem :|

    • U mnie szyfrowana kopia przyrostowa idzie 2x dziennie na dysk sieciowy, oraz na 2 serwery za granicą :)
      Drugie zadanie kopii SVN wykonywane jest po każdym commicie w takiej samej ilości jak wcześniej.

      Dziennie wysyłane jest trochę danych :)
      A to tylko kopia PC’ta :) O maszynach produkcyjnych nie wspominam ;p

  11. @Artykuł: Moje zdanie jest takie, że chmury są ok, ale tylko jeśli masz zaufanie do providera takowej usługi. Do Google raczej zaufanie można mieć, gdyż takie firmy dbają o wizerunek, a wpadka związana z wyciekiem prywatnych (nawet nie osobowych) danych mogłaby taką firmę pogrążyć. Przypadkowe rm -rf /* to przy tym mały pikuś, bo są backupy. Gorzej jak by ktoś niepowołany uzyskał dostęp.

    Jako bonus dodam sposób na tani “lokalny dropbox”, pozwalający mieć zawsze jakiś backup. Większość osób chyba wie czym jest dropbox, prawda? Do stworzenia takiego rozwiązania będzie potrzebny ruter i jakiś starszy komputer(y, bo może być kilka, co nawet jest lepsze). Celeron 800 spokojnie wystarczy, tutaj ważniejsza jest pojemność dysku. Nawet RAM-u nie musi być, jeśli wszystko po SSH będziemy robić. Na takim komputerze po wmontowaniu jakiegoś większego dysku instalujemy jakiegoś serwerowego linuksa bez żadnych bajerów typu iksy. Następnie instalujemy na nim klienta i serwer SSH i odpowiednio konfigurujemy. Potem wystarczy wykorzystać transfery plików po SSH + odpowiedni skrypt np. w Pythonie który będzie aktualizował dane w folderach na komputerze lokalnym bądź serwerze w zależności od tego który będzie nowszy i będzie działał przez cały czas w pętli. Jeśli chcemy aby było kilka serwerów (chodź w jednym można zamontować kilka dysków, bo to awaria twardziela jest największym ryzykiem), skrypt powinien synchronizować dane między serwerami. Aby nie było problemów z komunikacją najlepiej ustawić w sieci lokalnej statyczne IP dla komputerów w LAN i w skrypcie podać listę IP serwerów pomiędzy którymi ma następować synchronizacja, taką samą w skrypcie “klienckim”, choć tutaj czas oczekiwania na serwer powinien być mniejszy i jeśli się nie uda z nim skontaktować powinien przejść do następnego serwera z listy.

  12. Testował ktoś to mailstore? Ponoć dobre i za free.

    http://www.mailstore.com/en/mailstore-home.aspx

  13. @Darek
    To nie łatwiej po prostu postawić na tym starszym komputerze XP (może być nawet jakieś odchudzone dziwactwo typu Windows MX aby komputer chodził w miarę szybko) z połączeniem jedynie w sieci lokalnej i jednym jedynym programem którym będzie Dropbox lub Windows Mesh który będzie synchronizował dane z główną maszyną?

  14. AVE…

    Backup poczty mam lokalny. Dużo mniej zabawy i nerwów. Backup backupu na karcie SDHC w komórce. A co do dropboxa, to kupić HP T5500, wsadzić mu jakikolwiek system (nawet FreeDOS) i używać w charakterze serwera http://FTP...

  15. Mnie ciekawi jak zareagował dowolny klient posługujący się protokołem IMAP po zalogowaniu na taką pustą skrzynkę. Zsynchronizował się z pustą, czy zostawił kopię lokalną wiadomości.

  16. […] milionów pakietów na sekundę przesyłanych danych. Warto w takiej sytuacji zastanowić się nad kolejną wadą rozwiązania umieszczenia swojego serwisu w chmurze wielkiego operatora posiadającego miliony […]

  17. Kolejna wada rozwiązania w chmurze:

    http://bothunters.pl/2011/03/04/strona-wordpress-com-pod-solidnym-obstrzalem/

    • Jaka tam wada? Przecież DDoS może przytafić każdemu serwerowi wpiętemu do Sieci. A im większe zagęszczenie klientów, tym bardziej prawdopodobne.

Twój komentarz

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

RSS dla komentarzy: