Bezpieczeństwo w chmurze

Filip Gontarczyk 30 listopada 2011 14:55
Środowisko cloud computing cały czas się rozwija, przekonując coraz więcej firm do tego, aby wykorzystywały to co oferuje. Jest to dla nich opłacalne, ponieważ pozwala na zaoszczędzenie czasu oraz pieniędzy. Co jednak zrobić jeśli boimy się o bezpieczeństwo naszych danych?
Najważniejszą różnicą między bezpieczeństwem tradycyjnej infrastruktury, a bezpieczeństwem w chmurze jest to, że infrastruktura chmury jest dzielona pomiędzy różnych użytkowników z innymi poziomami zabezpieczeń. To, wraz z dynamiką i ulotnością chmury nieco komplikuje problem, ponieważ stwarza więcej miejsc w których możemy popełnić błąd konfiguracyjny, tym samym ułatwiając życie złodziejom danych.

Dla większości informatyków największą więc przeszkodą stojącą na drodze do chmury jest bezpieczeństwo danych.

Środowisko obliczeń umieszczonych w chmurze może być jednak równie bezpieczne jak większość wewnętrznych infrastruktur. Większość podstawowych przeszkód można usunąć za pomocą znanych technologii takich jak szyfrowanie danych, VLAN czy nawet firewalle i filtry pakietów. Oczywiście nie są to jedyne metody zabezpieczeń.

Zapewnienie bezpieczeństwa centrom danych w chmurze zaczyna się od fizycznego zabezpieczenia sprzętu.
Operatorzy największych centrów danych, jak Google, Amazon czy Microsoft wykorzystują swoją wiedzę oraz doświadczenie przy tworzeniu infrastruktury cloud.

Najnowocześniejsze centra danych znajdują się w nieoznaczonych budynkach w dzielnicach mieszkalnych. Obszar samego obiektu, jak i teren wokół niego jest chroniony całodobowo przez strażników oraz systemy wykrywające wtargnięcia. Personel, który jest autoryzowany do wstępu musi przejść przynajmniej trzykrotny proces uwierzytelniania aby dostać się do sali z serwerami, same serwery natomiast umieszczane są w ufortyfikowanych bunkrach z jeszcze większą ilością zabezpieczeń.

Odwiedzający i podwykonawcy, aby uzyskać dostęp do obiektu muszą okazać dowód tożsamości oraz się podpisać, a podczas całej wizyty będzie im towarzyszył autoryzowany personel.

Kolejnym wymaganiem, które zostało wprowadzone w celu ochrony centrum danych przed wewnętrznymi atakami jest zapewnienie dostępu do obiektu oraz informacji o jego istnieniu wyłącznie tym pracownikom, którzy mają uzasadniony powód aby o tym wiedzieć. Dodatkowo, wszelkie formy kontaktu fizycznego i elektronicznego nawiązywane przez pracowników są rutynowo zapisywane.

Opisane praktyki są podstawą przyznania certyfikatu SAS 70.

Certyfikat Statement on Auditing Standards No. 70: Service Organizations, Type II (SAS 70 typu II) jest przyznawany organizacjom świadczącym usługi mające wpływ na sprawozdania finansowe klientów. Ten certyfikat oraz jemu podobne, przyznawane przez AICPA świadczą o tym że dostawca nie tylko wprowadził wystarczającą wewnętrzną kontrolę, ale również dba o jej utrzymanie.

Za bezpieczeństwo fizyczne odpowiada wyłącznie dostawca chmury, natomiast za kontrolę dostępu odpowiadają dostawca i użytkownicy.

Kolejnym istotnym sposobem zabezpieczenia danych, po środkach fizycznych, to kontrola osób które mają prawo dostępu do naszej części chmury. Aby lepiej zrozumieć proces weryfikacji i uwierzytelniania użytkownika, podamy krótkie przykłady sposobów używanych przez Amazon Web Services.

Pierwszym krokiem do potwierdzenia tożsamości jest weryfikacja adresu wpisywanego do faktury. Innym dobrym pomysłem jest weryfikacja poprzez inny, nie związany z chmurą interfejs. W tym przypadku jest to potwierdzenie telefoniczne. To bardzo silne zabezpieczenie, ponieważ użytkownik musi wykorzystać zasób zewnętrzny, (telefon) aby wpisać podany na stronie numer pin. W następnej kolejności dopiero podajemy dane logowania.

Mając pełną kontrolę nad danymi służącymi do potwierdzenia naszej tożsamości musimy zadbać o silne hasło. Alternatywnie można wykorzystać wieloczynnikową autentykację, np. opartą o mechanizm RSA SecurID.

Dla wielu osób jest to sposób polecany, szczególnie gdy jedynym czynnikiem autoryzacji w pierwszej metodzie jest hasło, które musimy wprowadzać z każdą próbą dostępu do usług w chmurze za pomocą przeglądarki. Wyjątkiem jest korzystanie ze specjalnej API, wtedy podajemy jedynie klucz uwierzytelniający. Do generacji takiego klucza najlepiej wykorzystać zaufany certyfikat X.509 wygenerowany w urzędzie certyfikacji.

Certyfikat ten bazuje na kryptografii klucza publicznego i składa się z pliku certyfikatu oraz odpowiadającego mu pliku z częścią prywatną klucza. Certyfikat zawiera klucz publiczny i związane z nim metadane. Jest to część publiczna, wysyłana w każdym żądaniu danej usługi. Klucz prywatny jest wykorzystywany do zatwierdzenia takich żądań, jest on tajny i nie powinno się nim dzielić.

Przedstawione metody kontroli dostępu do chmury publicznej są niemal identyczne we wszystkich infrastrukturach publicznych tego typu, mają one jednak kluczowe znaczenie dla identyfikacji, uwierzytelniania oraz autoryzacji użytkowników danej chmury.


Jeśli chcecie się dowiedzieć czym jest chmura, lub jak jest zbudowana to zapraszamy do naszych poprzednich artykułów.

Dołącz do nas!

Komentarze (8)

  • Gosć
  • 06-12-2011 14:03

Pochmurny: bo to jest specyficzna wersja tego. Serwery są udostępniane w ciągu sekund na życzenie (dyski, pamięć, procesorym przepustowość, kopie itd). Bo płacisz głównie za faktyczne wykorzystanie a nie za rezerwację. Bo dostawca daje mocny SLA (przynajmniej SAS70 jak MS. Poprostu inny model biznesowy, inne API, inne dostosowanie aplikacji i cachowania.

  • pająk wodnik
  • 06-12-2011 07:39

JEdyną siecią na kórej można polegać (i to też nie zawsze) jest sieć pajęcza albo rybacka.

  • rozpraszacz_chmur
  • 05-12-2011 18:15

Po co wymyślono chmury - po to żeby za friko mieć dostęp do cudzych danych. Odłączenie klienta od chmury jest banalnie proste, - wystarczy dokonać fizycznego ataku na sieć i nie potrzebna jest nawet znajomość informatyki. A co tu wspominać o innych metodach równie skutecznych, ale wymagających więcej finezji. Z własnej już ponad 20-to letniej praktyki wiem, że jedyną siecią, na której można polegać jest własny dobrze zabezpieczony LAN. Reszta to elektro-fikcja.

  • Jan
  • 03-12-2011 01:19

Nie wyjawiajcie swoich firmowych tajemnic Micro$oftowi, postawcie w swoim biurze prywatną chmurę ownCloud albo Eucalyptus! Wszystkie dane trzymajcie u siebie!

  • Gosć
  • 01-12-2011 04:16

@iicca10: ależ we współczesnym świecie, awarie łącz (gdy są od paru dostawców bo np. takie ważne przetwarzanie danych) są znakomicie rzadsze od jednej z krytycznych awarii własnej serwerowni. Wiele z systemów nie musi być równo 100% bezawaryjna (i nie jest bo to kosztuje majątek i paranoję a w tym czasie np. konkurenci wygrywają efektywnością środków). Aplikacje mogą korzystać z danych cachowanych w bazach lokalnych a synchronizować w tle (znane poprawne rozwiązania np. w medycynie dla szpitali, księgi wieczyste w rozproszonych sądach i ogrom innych), gdzie awaria łącza nie blokuje kontynuacji pracy a jedynie wymianę wersji zmian w danych - na co jest przygotowana logika biznesowa i użytkownicy praktycznie tego nie odczują (poza komunikatami informacyjnymi przy odpowiednich czynnościach). Dlatego, chociaż nie jest to panaceum na problemy biznesowe to w znakomitej części jest to efektywniejsze biznesowo rozwiązanie przy wielu różnych scenariuszach od polegania na tylko własnej serwerowni i własnych backupach. Zgadza się, że może być trudno refaktoryzować niektóre aplikacje pisane z pominięciem dobrych praktyk i wzorców lub pisane w technologiach nie przewidujących takich możliwości i wtedy mamy faktycznie problem - bo rozsądni konkurenci mogą mieć odpowiednią funkcjonalność taniej i szybciej co da im przewagę rynkową i naszą stratę mimo naszych poświęceń i zmagań z jakąś choćby na wstępie darmową finansowo technologią. Oczywiście są oferty namiastek, robiących "cuda" ale chyba już tylko dla naiwnych.

  • iicca10
  • 30-11-2011 22:15

Problem w tym, że już teraz można położyć na łopatki kilka firm na raz malutką awarią łącza. A propos szyfrowania. Kto zapewnia szyfrowanie danych przechowywanych w chmurze. Klienta, czy usługodawca? Bo jak ten drugi, to tak jakby szyfrowania nie było.

  • user
  • 30-11-2011 21:37

@ pohmurny fakt ale to juz nie jest serwer Twoj tylko serwer wspoldzielony z innymi zasobami a Ty jako admin wydziolenego obszeru zasobow odpowiadasz za swoje dane komu je udostepniasz ...

  • Pochmurny
  • 30-11-2011 18:22

Znowu ta chmura? Poszaleliście wszyscy? Dlaczego nie może się to po prostu dalej nazywać architekturą klient-serwer?

Galerie

Warunki obsługi - Kontakt - Regulamin
Polityka prywatności - Serwis zgodny z ASME
Serwisy IDG - Reklama -
© Copyright 2011 International Data Group Poland S.A.
04-204 Warszawa ul. Jordanowska 12
tel.(+4822)321-78-00   fax(+4822)321-78-88
Archiwum wiadomości: 2011 2010 2009 2008 2007 2006 2005 2004 2003 2002 2001