Problemy uwierzytelniania związane są z dużą liczbą różnych klientów. W modelu tradycyjnym każdy uwierzytelniany użytkownik ma swoje konto zlokalizowane w aplikacyjnej bazie danych uwierzytelniania (lub usługach katalogowych). Jednak współużytkowanie komplikuje ten proces, ponieważ konwencjonalne usługi uwierzytelniania zazwyczaj domyślnie oferują dostęp do współdzielonych zasobów. 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" Najnowsza propozycja - "Web Identity 2.0" lub inaczej "sfederowana tożsamość" zakłada istnienie wielu usług tożsamości. W tym modelu dostawca cloud może wybrać, z która 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 (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).

W tradycyjnej pracy sieciowej użytkownik najczęściej jest świadomy, gdzie znajdują się aplikacje i dane. Dokładna lokalizacja zasobów komputerowych dla danej chmury może nie być bezpośrednio identyfikowalna zarówno przez klienta jak i dostawcę chmury. To stawia nowe wyzwania: jak chronić dane nie wiedząc gdzie się fizycznie znajdują? Jak dostawca cloud ma identyfikować dane klienta (dla potrzeb prawnych i innych) oraz jak je usuwać, kiedy klient przestanie korzystać z usługi?

Zobacz również:

• 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT
• Cyfrowa transformacja z AI - co nowego na Google Cloud Next 24
• Dzięki tej umowie polska policja zyska wiedzę i narzędzia zapobiegające cyfrowym zagrożeniom

Duża rolę w usługach cloud odgrywa wirtualizacja, bądź jako wsparcie usługi lub - w przypadku IaaS - jako element oferty cloud service. Wnosi jednak te same ryzyka bezpieczeństwa jak fizyczne środowisko komputerowe, a dodatkowo luki na styku "gość-host" i "gość-gość".

Dobre praktyki w ochronie chmury

Od chwili pojawienia się, chmury stały się celem wszystkich konwencjonalnych ataków: fizycznych, przepełnienia bufora, ataków na hasła, wykorzystania luk w aplikacjach, zatruwania sesji, ataków sieciowych, "man in the middle", socjotechniki itp. Ale unikatowy charakter cloud computing stwarza też nowe wyzwania. Ponieważ napastnicy to zalogowani, uwierzytelnieni użytkownicy, wiele konwencjonalnych metod ochrony (takich ja wydzielone strefy bezpieczeństwa, zapory sieciowe itp.) traci na znaczeniu.

Bezpieczeństwo IT jest dyscypliną rozległą i każdy z jej rozlicznych aspektów musi być zweryfikowany w modelu cloud. W tradycyjnym systemie komputerowym, kiedy pracownik opuszcza firmę, są usuwane jego uprawnienia dostępu do aplikacji i danych. Kiedy jednak taki pracownik - w imieniu firmy - jest subskrybentem cloud service, to bez wdrożonej techniki śledzenia subskrypcji, odchodząc z pracy będzie miał możliwość zachowania dostępu do danych firmy. Implikacje tego typu zachodzą w całym zakresie problemów bezpieczeństwa.

Brak ścisłej lokalizacji sprawia, że właściwa wydaje się klasyfikacja i oznaczanie właścicielstwa danych. Dostawcy cloud powinni mieć możliwość oznaczania (metkowania) danych cechą właścicielstwa i klasyfikacji pod względem bezpieczeństwa, a także zapewniać ochronę opartą na tych atrybutach.

Dostawca cloud powinien również fizycznie zabezpieczyć serwery i dane. Jeżeli serwer nie ma potrzeby komunikowania się z większością innych serwerów, to powinien mieć zablokowaną taką możliwość. Jeżeli komputer kliencki nie powinien komunikować się z innym komputerem klienckim, to należy mu taka możliwość zablokować.