Bezpieczeństwo w chmurze

Problemy uwierzytelniania

Dostęp przez internet i wielodzierżawność wyznaczają poważne wyzwania: jak uwierzytelniać dużą liczbę różnych klientów? W tradycyjnym modelu każdy uwierzytelniany użytkownik ma swoje konto zlokalizowane w aplikacyjnej bazie danych uwierzytelniania (lub usługach katalogowych). Jednak wielodzierżawność komplikuje ten proces, ponieważ konwencjonalne usługi uwierzytelniania zazwyczaj oferują domyślnie dostęp do współdzielonych, wspólnych zasobów.

Początkowo wielu dostawców cloud próbowało rozwiązać ten problem, stosując własne rozwiązania lub prywatne usługi uwierzytelniania. Ale usługi te rzadko miały pożądaną skalowalność i funkcjonalność. Pierwsza generacja chmur wymagała, aby wszyscy użytkownicy końcowi mieli oddzielne konta w ich bazach danych - podobnie jak surfując po WWW, trzeba logować się oddzielnie do każdej witryny, w której ma się konto. Ten rodzaj systemu tożsamości jest określany jako "Web Identity 1.0".

Zobacz również:

  • 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT
  • Cisco i Microsoft transmitują dane z prędkością 800 Gb/s
  • IDC CIO Summit – potencjał drzemiący w algorytmach
Cechy wyróżniające model cloud computing
Używanie jednego, dużego rozwiązania SSO (single sign-on), które współdziała z uczestniczącymi witrynami, to metoda nazywana "Web Identity 1.5". W tym modelu uwierzytelniania użytkownicy rejestrują się w niezależnym, scentralizowanym "urzędzie", gdzie otrzymują SSO ID. Użytkownik odwiedzający witrynę działającą w tym systemie może wprowadzić swoje poświadczenie SSO i uzyskać dostęp. Przykładem takiego rozwiązania jest Microsoft Passport (obecnie LiveID) oraz protokoły opracowane przez Liberty Alliance.

Najnowsza propozycja to "Web Identity 2.0", lub inaczej "sfederowana tożsamość" czy "metasystem tożsamości". W przypadku tej koncepcji zakłada się istnienie wielu usług tożsamości (zarówno centralnie zarządzanych, jak i pojedynczych, niezależnych), które mogą współdziałać z dużą liczbą witryn i usług. Popularne, indywidualne usługi tożsamości to OpenID, InfoCard czy LiveID. Wiele z usług uwierzytelniania współpracuje ze sobą i używa znanych protokołów, takich jak: XML, SOAP, SAML, Web Services, WS-Federation itp.

W modelu Web 2.0 dostawca cloud może wybrać, z którą usługą sfederowanej tożsamości ma współpracować, i którą akceptować. Witryna lub dostawca usługi może wymagać szczególnych typów ubezpieczenia tożsamości (takich jak proste hasło, karta czipowa, urządzenie biometryczne).

Z kolei użytkownicy mogą mieć możliwość podawania jedynie tych danych o tożsamości, którymi zechcą dzielić się z dostawcą usługi (tożsamość claim-based). Dobry metasystem tożsamości powinien stosować zasadę, według której użytkownicy mają udostępniać jedynie niezbędne minimum informacji o tożsamości - konieczne do uzyskania dostępu do oferowanej usługi i wykonania pożądanej transakcji.

Napastnik działający "w chmurze" z dużym prawdopodobieństwem może być użytkownikiem uwierzytelnionym w systemie cloud. W systemach "tradycyjnych" napastnik nie zaczyna od uwierzytelnionego dostępu - musi najpierw uzyskać dostęp, aby rozpocząć eksplorację systemu na wyższym poziomie.

Systemy tożsamości wciąż jeszcze znajdują się na ścieżce rozwojowej. Rozwiązania będą się zmieniać i kształtować, w miarę jak użytkownicy zaczną korzystać z chmury w szerszym zakresie. Kiedy pojawią się nowe potrzeby, konieczne będzie wprowadzanie nowych rozwiązań i protokołów. Identity 2.0 jest nowym paradygmatem, który wymaga zasadniczej zmiany myślenia o ochronie zasobów komputerowych.


TOP 200