Wstęp
W ostatnich latach wiele się mówi o zarządzaniu dostępem. Terminy „uwierzytelnianie” i „zarządzanie dostępem” często są używane zamiennie. Każdy z nich ma jednak inne znaczenie. O ile uwierzytelnianie oznacza sprawdzanie tożsamości użytkownika, zarządzanie dostępem umożliwia określenie, czy użytkownik ma zezwolenie na dostęp do danego zasobu, oraz egzekwowanie reguł dostępu obowiązujących dla tego zasobu.
Zarządzanie dostępem jest szczególnie ważne w przypadku zasobów w chmurze. Użytkownicy systemów informatycznych w przedsiębiorstwach codziennie uzyskują dostęp do wielu aplikacji chmurowych, z czym wiążą się niegodności zarówno dla nich, jak i dla administratorów. Użytkownicy muszą zapamiętać mnóstwo danych logowania, co nie zawsze im się udaje, więc administratorzy muszą ciągle resetować zapomniane hasła. Rozwiązaniem tego problemu jest funkcja jednokrotnego logowania, dzięki której użytkownicy mogą zalogować się raz, za pomocą jednego zestawu danych, do wszystkich aplikacji w chmurze, a informatycy nie muszą tracić czasu na odzyskiwanie haseł.
Ten jeden zestaw danych uwierzytelniających jest tak bezpieczny, jak metoda jego weryfikacji. Dlatego metoda weryfikacji tożsamości użytkowników jest tak ważna dla zapewnienia bezpiecznego dostępu do chmury. Rozwiązania do zarządzania dostępem i funkcje jednokrotnego logowania zapewniają szczegółową kontrolę reguł dostępu zdefiniowanych dla aplikacji, a wprowadzenie dodatkowego elementu uwierzytelniania w sytuacjach wysokiego ryzyka nie stanowi utrudnienia dla użytkowników.
Uwierzytelnianie i zarządzanie dostępem
Rozwiązania do uwierzytelnianiem i zarządzania dostępem (ang. Authentication and Access Management) są złożone z funkcji nadzoru nad tożsamością i administrowania nią (ang. Identity Governance and Administration ― IGA) oraz funkcji zarządzania dostępem (ang. Access Management ― AM). Rozwiązania do zarządzania tożsamością i dostępem (ang. Identity and Access Management ― IAM) stwarzają metodyczne ramy udzielania (i żądania) dostępu do aplikacji (IGA), stosowania mechanizmów kontroli dostępu (AM) oraz zapewniania widoczności zdarzeń związanych z dostępem (AM). Ponieważ większość organizacji wdraża komponenty IGA i AM oddzielnie, są one coraz częściej traktowane jako odrębne, samodzielne rodziny rozwiązań, a nie jako funkcje składowe pakietu zarządzania uwierzytelnianiem i dostępem.
Zarządzanie dostępem
Zarządzanie dostępem to funkcja umożliwiająca sprawdzenie, czy użytkownik ma zezwolenie na dostęp do danego zasobu, oraz egzekwowanie reguł dostępu określonych dla tego zasobu.
Zarządzanie dostępem jest oparte na regułach dostępu zdefiniowanych przez administratorów systemu informatycznego. Reguły te informują, które grupy użytkowników (np. dział sprzedaży, dział badań i rozwoju lub dział kadr) mają prawo dostępu do określonych aplikacji chmurowych (np. Salesforce, Office 365, Jira lub Taleo) oraz jakie atrybuty użytkowników są wymagane w celu uzyskania takiego dostępu (np. zaufana sieć, hasło statyczne lub hasło jednorazowe).
Reguły dostępu mogą obejmować atrybuty użytkownika, które będą oceniane (stosownie do wymagań konkretnej aplikacji w chmurze) za pomocą uwierzytelniania opartego na ryzyku lub kontekście, niezbędnego do egzekwowania różnych reguł dostępu zdefiniowanych dla poszczególnych aplikacji (więcej informacji znajduje się w części dotyczącej uwierzytelniania kontekstowego).
W zarządzaniu dostępem do aplikacji chmurowych ważne jest również jednokrotne logowanie (SSO). Dzięki tej funkcji użytkownik może zalogować się do wszystkich aplikacji jednocześnie za pomocą jednego zestawu nazwy i hasła, tj. jednej tożsamości cyfrowej (więcej informacji znajduje się w części dotyczącej jednokrotnego logowania).
Tożsamość jako usługa (IDaaS)
IDaaS to skrót od IAM-as-a-Service lub Identity-as-a-service (tożsamość jako usługa). Są to rozwiązania do zarządzania tożsamością i dostępem (IAM), które umożliwiają korzystanie z chmurowego modelu usług w zakresie zarządzania dostępem i uwierzytelniania. W ostatnich latach rozwiązania IDaaS były traktowane jako jeden odrębny segment rynku. Najnowsze trendy wskazują jednak na to, że zostaną one podzielone na dwa segmenty ― usługi zarządzania dostępem (AM) oraz usługi nadzoru nad tożsamością i administrowania nią (IGA) udostępniane w formie instalacji lokalnych, oprogramowania lub platform chmurowych.
Nadzór nad tożsamością i administrowanie nią (IGA)
Rozwiązania IGA dostarczają odpowiedzi na następujące pytania: „Kto powinien uzyskać dostęp i kto ma uprawnienia dostępu do poszczególnych aplikacji?” oraz „Kto w praktyce uzyskał dostęp do określonych aplikacji, gdzie i od kogo?” Za pomocą IGA można na przykład ustalić, że pracownicy działu badań i rozwoju będą mieć dostęp do określonych aplikacji programistycznych, takich jak GitHub, Jira i Confluence. Wówczas IGA będzie automatycznie udzielać tym użytkownikom dostępu do tych aplikacji. Gdy pracownik działu badań i rozwoju zażąda dostępu do innych aplikacji, jego wniosek zostanie skierowany do zatwierdzenia przez kierownictwo. Ten proces również jest obsługiwany przez niektóre rozwiązania IGA.
Federowanie tożsamości
Za pomocą federowania tożsamości system zwany „zaufanym dostawcą tożsamości” (ang. Identity Provider) zarządza uwierzytelnianiem użytkowników. Aplikacje chmurowe przekazują proces uwierzytelniania do dostawcy tożsamości za każdym razem, gdy użytkownik uzyskuje do nich dostęp. Sfederowana tożsamość eliminuje problemy i niedogodności związane z zarządzaniem danymi uwierzytelniającymi odrębnie dla każdej aplikacji WWW (dotyczy to zarówno aplikacji wewnętrznych, jak i zewnętrznych). Federowanie tożsamości jest oparte na protokołach federowania, takich jak SAML i Open ID Connect, oraz protokołach zastrzeżonych, takich jak WS-Federation firmy Microsoft.
Sfederowane logowanie
Sfederowane logowanie jest funkcją protokołów federowania, takich jak SAML czy Open ID Connect. Wykorzystuje ona model oparty na dostawcy tożsamości, aby uwierzytelniać użytkowników i przekazywać informacje dotyczące tego uwierzytelniania do systemu docelowego w formie tzw. asercji uwierzytelniania. Asercja ta może zawierać odpowiedź pozytywną lub negatywną, oznaczającą udzielenie lub nieudzielenie użytkownikowi dostępu do aplikacji.
Sfederowane logowanie umożliwia użytkownikom jednokrotne zalogowanie się do systemu i uzyskanie dostępu do wszystkich aplikacji w chmurze. Zamiast logować się do poszczególnych aplikacji za pomocą różnych nazw użytkownika i haseł, czyli tożsamości cyfrowych, użytkownik może uzyskać dostęp do aplikacji Office 365, Salesforce lub AWS za pomocą tych samych danych uwierzytelniających, których używa, logując się rano do sieci przedsiębiorstwa lub wieczorem do sieci VPN.
System zwany „zaufanym dostawcą tożsamości” wykorzystuje funkcję federowania tożsamości do zarządzania uwierzytelnianiem użytkowników. Aplikacje chmurowe przekazują proces uwierzytelniania do dostawcy tożsamości za każdym razem, gdy użytkownik uzyskuje do nich dostęp.
Dostawca tożsamości
SAML i inne protokoły federowania tożsamości, które umożliwiają bezpieczną wymianę danych uwierzytelniających między niepowiązanymi ze sobą serwisami WWW, są oparte na modelu dostawcy tożsamości (Identity Provider ― IdP) i dostawcy usługi (Service Provider). Gdy użytkownik uzyskuje dostęp do usługi w chmurze oferowanej przez dostawcę, jest przekierowywany do zaufanego dostawcy tożsamości w celu uwierzytelnienia i/lub autoryzacji. Dostawca tożsamości weryfikuje dane uwierzytelniające użytkownika (np. pliki cookie, dane urządzenia lub sieci bądź hasło jednorazowe) i generuje odpowiedź oznaczającą akceptację lub odrzucenie, którą przesyła do dostawcy usługi. Dane uwierzytelniające mogą obejmować pozwolenie na uzyskanie dostępu do takich informacji, jak adresy e-mail z konta poczty internetowej lub nazwiska przyjaciół z konta w sieci społecznościowej.
Przykładem działającego w ten sposób dostawcy tożsamości jest system SafeNet Trusted Access.
Usługi tokenu zabezpieczającego (STS)
Modele oparte na dostawcach tożsamości są również określane jako „modele uwierzytelniania opartego na tokenach” lub „usługi tokenu zabezpieczającego” (ang. Security Token Services ― STS). STS jest odpowiednikiem dostawcy tożsamości, strona przekazująca (ang. Relying Party ― RP) ― odpowiednikiem dostawcy usługi, natomiast asercję SAML zastąpiły tokeny zabezpieczające. Nazwy są inne, koncepcja ta sama.
Protokół SAML
SAML to skrót od Security Assertion Markup Language. Jest to otwarty standard oparty na języku XML, który umożliwia wymianę danych uwierzytelniających między niepowiązanymi ze sobą serwisami WWW. Funkcja SAML jest również określana jako „federowanie tożsamości” lub „sfederowane uwierzytelnianie”. Federowanie tożsamości oznacza możliwość rozszerzenia tożsamości cyfrowej, której użytkownik używa w systemie przedsiębiorstwa, na chmurę. Dzięki temu użytkownik może się logować za pomocą tej tożsamości do wszystkich używanych przez siebie aplikacji w chmurze. Sfederowane uwierzytelnianie w aplikacjach chmurowych z wykorzystaniem protokołu SAML sprawia, że zamiast 5 czy 25 zestawów nazw i haseł wystarczy jeden.
Jak działa SAML
Gdy użytkownik loguje się do aplikacji w chmurze, jest przekierowywany do zaufanego dostawcy tożsamości w celu weryfikacji wprowadzonych danych uwierzytelniających (np. nazwy i jednorazowego hasła). Dostawca tożsamości sprawdza te dane i przekazuje do aplikacji swoją odpowiedź w formie tzw. asercji SAML, która może zawierać akceptację lub odrzucenie. Na tej podstawie dostawca usługi (np. Salesforce, Office 365 lub DropBox) udziela lub odmawia użytkownikowi dostępu do aplikacji.
WS-Fed
Usługi WS-Federation (WS-Fed) to zastrzeżony protokół federowania tożsamości firmy Microsoft. Współdziała on z usługami Microsoft Active Directory Federation Services (AD FS) w celu rozszerzenia tożsamości przechowywanych w katalogu Active Directory na aplikacje chmurowe firmy Microsoft, takie jak Office 365 i Azure. Podobnie jak SAML, usługi WS-Fed są oparte na modelu dostawcy tożsamości. Gdy użytkownik loguje się do aplikacji chmurowej Microsoft, jest przekierowywany do usług AD FS w celu zweryfikowania wprowadzonych danych uwierzytelniających. Na podstawie przesłanej przez te usługi odpowiedzi aplikacja chmurowa udziela lub odmawia mu dostępu.
OAuth
OAuth (wymawiane jak „oh-auth”) to skrót od „Open Authorization” („otwarta autoryzacja”). Jest to otwarty standard sfederowanego lub opartego na tokenach uwierzytelniania i autoryzowania obejmującego niepowiązane ze sobą serwisy WWW. Podobnie jak w przypadku innych protokołów federowania tożsamości, takich jak SAML, Open ID Connect i WS-Fed, OAuth umożliwia logowanie do aplikacji za pomocą danych uwierzytelniających weryfikowanych przez zaufanego dostawcę tożsamości, nie ogranicza się jednak do sfederowanego uwierzytelniania. Dzięki usłudze OAuth użytkownik może zezwolić serwisom WWW strony zaufanej na uzyskanie dostępu do określonych danych klienta, takich jak nazwiska i adresy e-mail osób kontaktowych. Na przykład sieci społecznościowe wykorzystują protokół OAuth, aby uzyskać dostęp do danych kontaktowych poczty internetowej użytkownika oraz zapytać go, czy chce zaprosić te osoby do swojej sieci znajomych.
Open ID Connect
Podobnie jak SAML, OpenID Connect jest protokołem federowania tożsamości opartym na otwartych standardach, wykorzystującym model dostawcy tożsamości. W odróżnieniu od protokołu SAML, który używa plików cookie, więc współdziała tylko z aplikacjami otwierającymi się w przeglądarce (tzw. aplikacjami opartymi na przeglądarce), OpenID Connect udostępnia platformę jednokrotnego logowania obsługującą nie tylko takie aplikacje, lecz również rodzime aplikacje mobilne i komputery-klienty (np. pełne klienty i niektóre sieci VPN). Choć większość rozwiązań do jednokrotnego logowania obsługuje dziś tylko aplikacje oparte na chmurze i przeglądarce, coraz więcej dostawców tożsamości wdraża protokół OpenID Connect, dzięki któremu możemy uwierzytelniać się tylko raz, aby uzyskać dostęp do wszystkich naszych zasobów ― komputerów-klientów, aplikacji opartych na przeglądarce i rodzimych aplikacji mobilnych.
Używanie prywatnej tożsamości cyfrowej w systemie przedsiębiorstwa (Bring Your Own Identity ― BYOI)
Zarówno dostawcy usług zarządzania tożsamością, jak i przedsiębiorstwa i instytucje korzystające z ich oferty dążą do tego, aby ich pracownicy i partnerzy mogli uzyskiwać dostęp do zasobów firmy za pomocą swoich prywatnych tożsamości cyfrowych. Teoretycznie może to być każda tożsamość cyfrowa, która pozwala na wystarczający poziom weryfikacji. Przykładem są dowody tożsamości wydawane przez organy administracji państwowej, inteligentne karty udostępniane przez służbę zdrowia, a także tożsamości internetowe używane w sieciach społecznościowych i zawodowych lub udostępniane przez dostawców komercyjnych, takich jak FIDO. Prywatna i służbowa część cyfrowego świata coraz bardziej łączą się ze sobą, a specjaliści ds. cyberbezpieczeństwa w przedsiębiorstwach odczuwają coraz większą presję, aby wdrożyć podobne metody uwierzytelniania, jakie są zwykle używane w usługach dla użytkowników indywidualnych.
Jednokrotne logowanie
Dzięki funkcji jednokrotnego logowania użytkownik może potwierdzić swoją tożsamość tylko raz. Podczas uzyskiwania dostępu do innych zasobów będzie uwierzytelniany automatycznie, bez konieczności logowania się i uwierzytelniania do każdej aplikacji i każdego systemu osobno. Funkcja ta pośredniczy między użytkownikiem a aplikacjami docelowymi. W tle aplikacje i systemy docelowe nadal utrzymują swoje magazyny danych uwierzytelniających i wysyłają do systemu użytkownika instrukcje dotyczące jednokrotnego logowania. Funkcja jednokrotnego logowania odpowiada na te instrukcje i odwzorowuje dane uwierzytelniające na jedną kombinację nazwy użytkownika i hasła. (Źródło: Gartner)
Jednokrotne logowanie w formie samodzielnej funkcji lub szerszego rozwiązania do zarządzania dostępem można uzyskać, wykorzystując różne protokoły federowania tożsamości, np. protokoły open source (SAML 2.0 i Open ID Connect), protokoły zastrzeżone (WS-Federation firmy Microsoft) oraz inne technologie, takie jak repozytoria haseł i serwery odwrotnego proxy.
Repozytorium haseł
Repozytoria haseł, zwane również menedżerami haseł, umożliwiają utworzenie prostej procedury jednokrotnego logowania w sytuacji, gdy aplikacja docelowa (np. starsza lub niestandardowa) nie obsługuje protokołów federowania tożsamości. Repozytoria haseł to systemy, które przechowują i szyfrują dane z różnych serwisów WWW. Zamiast logować się do każdej aplikacji za pomocą odrębnego hasła, użytkownik może uwierzytelnić się hasłem głównym (które deszyfruje hasło z repozytorium) i uzyskać dostęp do wszystkich aplikacji.
Autoryzacja
Autoryzacja to proces zapewniający, że należycie uwierzytelnieni użytkownicy mogą uzyskać dostęp tylko do zasobów, do których mają prawo dostępu udzielone im przez właściciela lub administratora. W przypadku usług dla użytkowników indywidualnych autoryzacja może również oznaczać proces, za pośrednictwem którego użytkownik ustala, że aplikacja w chmurze (np. sieć społecznościowa) będzie mieć dostęp tylko do określonych informacji z niepowiązanych serwisów WWW (np. z konta poczty internetowej użytkownika).
Uwierzytelnianie
Uwierzytelnianie jest procesem, w którym tożsamość użytkownika jest zatwierdzana lub weryfikowana na podstawie danych uwierzytelniających wprowadzanych przez niego podczas logowania do aplikacji, usługi, komputera lub środowiska cyfrowego. Większość danych uwierzytelniających obejmuje dwa elementy: coś, co użytkownik ma (np. swoją nazwę) oraz coś, co zna (np. hasło). Jeśli wprowadzone dane uwierzytelniające są zgodne z danymi przechowywanymi przez aplikację podstawową lub dostawcę tożsamości, użytkownik zostanie uwierzytelniony i uzyska dostęp do określonego zasobu.
Uwierzytelnianie kontekstowe
Uwierzytelnianie kontekstowe umożliwia weryfikację tożsamości użytkownika w chwili jego logowania się do aplikacji na podstawie oceny wielu informacji uzupełniających. Do najczęstszych typów informacji kontekstowych należy lokalizacja użytkownika, data i godzina, adres IP, typ urządzenia, adres URL i reputacja aplikacji. Uwierzytelnianie kontekstowe, określane również jako uwierzytelnianie oparte na ryzyku lub uwierzytelnianie adaptacyjne, jest kluczowym elementem technologii jednokrotnego logowania i zarządzania dostępem, której celem jest zapewnienie maksymalnej przejrzystości i prostoty tego procesu.
Oceniając atrybuty logowania użytkownika, niezależnie od tego, czy mają one charakter kontekstowy (jak urządzenie, rola lub lokalizacja) czy behawioralny (jak szybkość uderzania w klawisze czy kolejność wyświetlania stron), rozwiązania do jednokrotnego logowania i zarządzania dostępem mogą ciągle dostosowywać poziom uwierzytelniania do reguł dostępu zdefiniowanych dla konkretnej aplikacji. Nie ma ogólnej, ujednoliconej reguły dla wszystkich zasobów przedsiębiorstwa. Uwierzytelnianie ma charakter szczegółowy, z uwzględnieniem reguł dostępu do każdej aplikacji, i przebiega w sposób tak płynny, jak jest to możliwe.
Uwierzytelnianie w trybie ciągłym
Niezależnie od tego, czy uwierzytelnianie jest oparte na tokenie zabezpieczającym, haśle czy odcisku palca, sprowadza się ono do podjęcia decyzji typu tak/nie: system potwierdza tożsamość użytkownika i zezwala mu bądź nie zezwala na dostęp do aplikacji.
Jednak dzięki nowym technologiom, takim jak uwierzytelnianie kontekstowe lub biometria behawioralna (oparta na wzorcu uderzania w klawisze lub innych cechach fizycznych użytkownika), uwierzytelnianie może się stać procesem ciągłym. Poprzez ocenę wielu atrybutów, np. adresu IP, parametrów komunikacji mobilnej, znanych urządzeń czy systemu operacyjnego, uwierzytelnianie kontekstowe lub uwierzytelnianie oparte na ryzyku może weryfikować tożsamość osoby za każdym razem, gdy loguje się ona do aplikacji, w sposób dla niej niewidoczny i nieodczuwalny.
W uwierzytelnianiu kontekstowym wykorzystywanych jest wiele bezproblemowych sposobów weryfikacji tożsamości. Pozwala to pogodzić komfort użytkownika ze stosowaniem szczegółowej kontroli dostępu w wielu aplikacjach chmurowych. Dlatego koncepcja ciągłego uwierzytelniania, oparta na uwierzytelnianiu kontekstowym, jest podstawą zarządzania dostępem w środowiskach chmurowych.
