Bezpieczeństwo tożsamości jest jedną z najbardziej fundamentalnych kwestii w kontekście bezpieczeństwa w zasadzie jakiegokolwiek systemu czy środowiska. Jednocześnie implementacja procesu skutecznej ochrony tożsamości, pomimo wielu wspomagających nas w tym narzędzi nie jest wcale prosta. Odpowiedzialność za ochronę tożsamości jest często „rozmyta” pomiędzy np. dostawcę usług i konsumenta czy administratorów i użytkowników.
W kontekście usług chmurowych Microsoft, a przede wszystkim usługi pozwalającej nam na przechowywanie i zarządzanie tożsamościami – Azure Active Directory, możemy mówić o wielu mechanizmach, które pomagają nam w dbaniu o ich bezpieczeństwo, zarówno o ile mówimy o procesie uwierzytelniania (np. MFA, Dostęp Warunkowy (ang. Conditional Access), Ochrona tożsamości (ang. Identity Protection) itd.), jak i procesie autoryzacji (pakiety dostępu (ang. Access packages), przeglądy uprawnień (ang. Access Reviews), PIM (Privileged Identity Management), RBAC (Role-base access control) itd.).
W tym artykule skoncentrujemy się na pierwszym z procesów – uwierzytelnianiu (jeżeli nie wiecie czym różni się uwierzytelnianie od autoryzacji – zajrzyjcie tutaj). Nie będziemy jednak omawiali tutaj oferowanych przez Microsoft mechanizmów, a skoncentrujemy się na samym wyborze metod uwierzytelniania, ponieważ odpowiedni wybór samych metod ma ogromne znaczenie dla bezpieczeństwa całego procesu. Potraktujcie go jako omawiający dostępne metody wstęp do obszernego artykułu poświęconego MFA (uwierzytelnianiu wieloskładnikowemu), który ukarze się w najbliższym czasie. Zapraszam do lektury!
PS. W tym artykule nie będziemy omawiali metod wykorzystywanych w środowiskach hybrydowych jak np. PTA (Pass Through Authentication) – to temat na zupełnie osobny artykuł.
Dostępne metody uwierzytelniania
Myśląc o metodach uwierzytelniania duża część z nas myśli od razu o hasłach, być może również o najpopularniejszych metodach wykorzystywanych w MFA – kodach jednorazowych otrzymywanych przez SMS, być może kodach jednorazowych w dedykowanych aplikacjach typu Microsoft Authenticator.
A co o ile powiedziałbym Wam, iż w Azure Active Directory mamy dostępne 9 takich metod?
- Windows Hello for Business – czyli usługa najczęściej wykorzystywana do uwierzytelniania użytkowników na urządzeniach końcowych. W zależności od posiadanego sprzętu mogą to być np. różne metody biometryczne czy kod PIN
- Microsoft Authenticator app – aplikacja Microsoft Authenticator, którą szczerze polecam również w zastosowaniu prywatnym. Może działać na różne sposoby – wymagać przepisania jednorazowego, dedykowanego dla danego konta i rotowanego co 30 sekund kodu jednorazowego, zatwierdzenia powiadomienia push w aplikacji na telefonie czy wciśnięcia przycisku z numerem, wyświetlonym na ekranie podczas logowania
- FIDO2 security key – prawdopodobnie najlepsza metoda uwierzytelniania, zarówno pod kątem bezpieczeństwa, jak i użyteczności. Klucz sprzętowy to najprościej mówiąc niewielkie urządzenie, które jest w stanie zatwierdzić nasze logowanie po włożeniu go np. w port USB czy przyłożeniu go do urządzenia wspierającego technologię NFC.
- Certificate-based authentication – użytkownik uwierzytelniany jest na podstawie certyfikatu, który jest np. zainstalowany na jego urządzeniu.
- OATH hardware tokens – metoda wykorzystująca urządzenia firm trzecich, które pozwalają na generowanie kodów jednorazowych wykorzystywanych w procesie uwierzytelniania.
- OATH software tokens – alternatywa dla powyższej opcji, gdzie kody jednorazowe są generowanie przez aplikacje, a nie fizyczne urządzenia.
- SMS – czyli kody jednorazowe otrzymywane via SMS na wskazany numer telefonu
- Voice – wydawało by się, iż archaiczna, a jednak wciąż wykorzystywana metoda uwierzytelniania. Automat nawiązuje połączenie z użytkownikiem, który musi wprowadzić swój kod pin, wcisnąć # we właściwym momencie itp.
- Password – czyli oczywiście znana wszystkim, najpopularniejsza, a przy tym najmniej bezpieczna metoda uwierzytelniania.
To, jak wygląda zależność poszczególnych metod uwierzytelniania od ich bezpieczeństwa, ale także użyteczności czy dostępności bardzo dobrze obrazuje poniższa tabelka:
Wartym odnotowania jest również to, iż niektóre z dostępnych metod uwierzytelniania mogą być wykorzystywane wyłącznie jako jeden ze składników MFA (lub SSPR), nie podstawowa metoda uwierzytelniania:
W gwoli ścisłości – w przypadku mechanizmu SSPR mamy do czynienia również z 3 dodatkowymi metodami, które nie mogą być wykorzystywane w „standardowym” procesie uwierzytelniania:
- App passwords – hasła aplikacji wykorzystywane w przypadku, gdy dana aplikacja nie wspiera tzw. Modern Authentication (o czym zaraz)
- Security questions – pytania bezpieczeństwa (niczym przy odzyskiwaniu hasła do poczty z przed 15 lat :))
- Alternatywny adres email – na który otrzymamy jednorazowy kod
W mojej ocenie – żadna z powyższych metod nie jest na tyle „silna”, aby wykorzystywać ją do procesu samodzielnego resetu hasła. o ile już musimy to zrobić – wymuśmy przynajmniej dwie metody łącząc ją z dowolną inną metodą z listy dostępnej na górze.
Modern Authentication
W kontekście utwierzytelniania w usługach Microsoft czy dokumentacji często spotykamy się z terminem Modern Authentication. w tej chwili wiele starszych aplikacji, które nie wspierają Modern Authentication nie może już łączyć się z usługami chmurowymi Microsoft. Ostatnim głośnym przykładem może być np. blokada możliwości łączenia się do Exchange Online dzięki Outlooka 2010 czy starszych wersji Outlooka 2013. Z punktu widzenia bezpieczeństwa – jest to oczywiście ruch w dobrą stronę.
Czym więc jest wspomniane Modern Authentication?
Najprościej mówiąc, będzie to termin określający bardziej nowoczesne, a przy tym bardziej bezpieczne metody czy protokoły uwierzytelniania. Terminem tym często posługujemy się w kontekście aplikacji (np. uwierzytelniania poprzez Outlook, żeby uzyskiwać dostęp do skrzynki pocztowej w Exchange Online).
Dlaczego mówiąc o Modern Authentication mówimy o bardziej bezpiecznym sposobie uwierzytelniania? Najprostszą odpowiedzią będzie fakt, iż takie metody czy protokoły muszą wspierać mechanizm MFA. Co z tego, iż mamy włączone MFA dla naszych użytkowników … o ile możemy je ominąć wykorzystując stare, niewspierające MFA protokoły (które najczęściej pozostają włączone z uwagi na funkcjonalność) i uzyskać dostęp do konta użytkownika na podstawie wyłącznie jednego składnika uwierzytelniania (najczęściej – hasła)? Trzymając się przykładu przytaczanej już poczty – dobrym przykładem braku wykorzystywania Modern Authentication mogą być aplikacje pocztowe działające w oparciu o protokół POP3 czy IMAP.
Dlatego też Microsoft, w trosce o bezpieczeństwo swoich usług oraz Klientów, od początku października 2022 zaczął wyłączać możliwość wykorzystywania tych protokołów w celu łączenia się z usługami chmurowymi – więcej info tutaj.
Wybór dopuszczalnych metod uwierzytelniania w Azure AD
Przeskoczmy teraz na moment do praktyki i zobaczmy w jaki sposób możemy zdefiniować, które metody uwierzytelniania będą dostępne dla naszych użytkowników. Znajdując się w Azure Active Directory przechodzimy do zakładki Security:
a następnie do Authentication Methods:
Znajdziemy tutaj polityki dedykowane dla poszczególnych metod uwierzytelniania:
Każda z polityk będzie zawierała nieco inne opcje, które będą możliwe do skonfigurowania. Żeby to zobrazować zajrzyjmy np. do polityki określającej możliwość wykorzystywania aplikacji Microsoft Authenticator.
W pierwszej zakładce mamy możliwość zdefiniowania czy dana metoda będzie dostępna dla użytkowników (suwak Enable) oraz dla kogo będzie ona dostępna. Możemy tutaj wskazać wszystkich użytkowników lub wyłącznie wybrane grupy. Mamy również możliwość zdefiniowania polityki w taki sposób, aby wykluczyć np. konkretną grupę użytkowników.
Dodatkowo dzięki dostępnych opcji możemy zdecydować o konieczności rejestracji danej metody przez użytkownika, a także sposobie uwierzytelniania użytkownika w ramach wskazanej metody:
W zakładce Configure (nie jest dostępna dla wszystkich metod) możemy również zdefiniować inne opcje, które są powiązane z daną metodą uwierzytelniania:
Na tym etapie rodzi się pytanie – które metody wybrać? Oczywiście odpowiedź nie będzie jednoznaczna i mocno uzależniona od naszych możliwości.
Z pewnością firmy, które posiadają chociażby klucze sprzętowe choćby dla części swoich pracowników wciąż stanowią niewielki odsetek wszystkich firm, a ta metoda byłaby z pewnością rekomendowana o ile mamy taką możliwość. Wybór metod uwierzytelniania jest również uzależniony od posiadanego sprzętu – nie każdy pracownik ma chociażby telefon służbowy, jak również nie każdy chce instalować aplikacje czy dostawać SMS-y na swoje prywatne urządzenie.
Dlatego też sam proces wyboru adekwatnych metod uwierzytelniania może być zupełnie różny dla każdej z firm. Żeby jednak nie zostawić Was z tak ogólnym opisem, bazując na swoim doświadczeniu dorzucam kilka przydatnych (mam nadzieję) wskazówek:
- Osobiście nie znam firmy, która wyposaża w klucze sprzętowe wszystkich swoich pracowników – ale być może warto porozmawiać o zakupie i wdrożeniu ich przynajmniej dla Zarządu i/lub osób z dostępem uprzywilejowanym?
- Jeżeli pracownicy posiadają telefony służbowe – aplikacja Microsoft Authenticator będzie nie tylko wygodniejsza, ale i znacznie bardziej bezpieczna niż „standardowe” kody przysyłane via SMS
- Jeżeli pracownicy nie posiadają telefonów służbowych warto rozważyć skorzystanie z Microsoft Endpoint Managera (Intune) i podpięcie urządzeń w trybie BYOD (Bring Your Own Device) – dane prywatne użytkowników nie pozostaną tknięte, a aplikację będzie można zainstalować na profilu służbowym (warto pamiętać, iż odseparowany logicznie profil służbowy będziemy w stanie stworzyć wyłącznie na telefonach z systemem Android)
- Jeżeli pracownicy nie posiadają telefonów i nie korzystamy/nie chcemy korzystać z MEM – warto zainteresować się certyfikatami jako jednym ze składników uwierzytelniania
I być może niektórzy uznają to za nieco utopijne, ale o ile mamy taką możliwość, spróbujmy powoli wdrażać Passwordless w naszych organizacjach (na moment pisania tego artykułu nie ma jeszcze możliwości całkowitego wyłączenia hasła dla kont użytkowników w Azure AD).
Wybierając metody warto również zajrzeć do zakładki Authentication Strenghts, która posiada zdefiniowane zestawy metod uwierzytelniania dla standardowego MFA, Passwordless, a także metody Phishing-resistant, czyli jak sama nazwa wskazuje, w założeniu odporne na metody phishingowe zbierające dane uwierzytelniające od użytkowników:
Czym jest Passwordless?
Passwordless w ostatnim czasie coraz bardziej zyskuje na popularności, a moja rekomendacja z poprzedniego zdania nie jest przypadkowa. Passwordless jest w tej chwili mocno promowany min. przez Microsoft jako najbezpieczniejszy z dostępnych w tej chwili sposobów uwierzytelniania (oczywiście pamiętając o kontekście wyboru odpowiednich metod uwierzytelniania).
Czym jest Passwordless? Całkowitym zrezygnowaniem z wykorzystywania hasła jako metody uwierzytelniania.
Metoda ta nie pozostało wspierana przez wiele systemów, do których logujemy się w internecie (chociażby, nad czym szczególnie ubolewam, przez wiele Banków). o ile jednak mówimy o dużych firmach technologicznych typu Microsoft czy Google, jego wykorzystanie jest jak najbardziej możliwe.
Dlaczego Passwordless jest tak skuteczny czy bezpieczny? Dlatego, iż jest odporny na wycieki haseł, które zdarzają się coraz częściej. Dziś wiele najbardziej rozpoznawalnych marek zaliczyło już mniejszy lub większy wyciek, który bardzo często zawierał również hasła użytkowników. Listę takich firm możemy podejrzeć np. tutaj – a to tylko i wyłącznie zweryfikowane i potwierdzone uzyskaniem dostępu do wykradzionej bazy wycieki.
Dlaczego wycieki są dla nas tak groźne? Praktyka pokazuje, iż hasła użytkowników wcale nie są specjalnie złożone, a już na pewno nie odporne na słownikowe metody łamania haseł. Co więcej – standardowy użytkownik w większości przypadków ma przecież to samo lub co najwyżej kilka tych samych haseł, z których korzysta. o ile wycieknie jego hasło do któregoś z portali społecznościowych czy sklepów internetowych, przestępcy z pewnością sprawdzą czy do innych portali, sklepów czy też konta służbowego użytkownik nie ustawił dokładnie takiego samego hasła. A skuteczność tego typu działań jest bardzo wysoka.
Z drugiej strony – phishing ukierunkowany na pozyskanie danych uwierzytelniających zawsze opiera się na pozyskaniu hasła, czasem również innych metod typu kod z SMS czy inny kod jednorazowy. o ile nasz użytkownik takiego hasła nie posiada – w wielu przypadkach problem znika. Szczególnie, o ile do uwierzytelniania wykorzystujemy klucz sprzętowy, który na tego typu phishing jest odporny.
Jakie metody możemy wykorzystać w przypadku Passwordless? Najlepiej te najbardziej złożone/bezpieczne, które możemy gwałtownie zobrazować dzięki przytoczonej już na samym początku artykułu grafiki:
Na moment pisania artykułu wdrożenie pełnego paswordless (tj. uwierzytelnianie hasłem nie jest w ogóle możliwe) jest możliwe wyłącznie dla kont prywatnych Microsoft. Funkcjnalność ta jest w fazie implementacji dla kont służbowych/Azure AD. Więcej info tutaj.
Logowanie bez hasła do usług Microsoft
To, iż wdrożenie pełnego Paswordless nie jest na ten moment możliwe nie oznacza, iż nasi użytkownicy czy my sami nie możemy logować się do kont służbowych dzięki chociażby aplikacji. Ze względu na to, iż ten przykład będzie chyba najłatwiejszy do zobrazowania, spróbujmy przejść przez proces konfiguracji Microsoft Authenticator jako domyślnej metody logowania dla wskazanego użytkownika.
*Na ten moment nie znalazłem żadnej metody, która pozwalała by zmienić domyślną metodę uwierzytelniania z hasła na aplikację jako administrator, dla konkretnych (lub wszystkich) użytkowników. Użytkownik musi wykonać wskazane metody „samodzielnie”, na własnym koncie.
Zacznijmy od wymagań wstępnych:
- Microsoft Authenticator musi być dostępne jako metoda uwierzytelniania dla danego użytkownika
- Użytkownik musi posiadać zarejestrowaną aplikację Authenticator (np. jako składnik MFA). o ile metoda ta nie pozostało zarejestrowana – może to zrobić np. poprzez portal mysignins.microsoft.com
Użytkownik z zarejestrowaną aplikacją Authenticator otwiera aplikację na swoim telefonie, wybiera swoje konto służbowe, a następnie opcję „Skonfiguruj logowanie telefonem”:
Urządzenie musi spełniać określone przez organizację wymagania – domyślnie posiadać blokadę ekranu oraz być zarejestrowanym w Azure AD. o ile któryś z warunków nie jest spełniony, kreator przeprowadzi nas przez cały proces. Przyjrzyjmy się kwestii rejestracji urządzenia:
Użytkownik loguje się na swoje konto, a następnie rejestruje urządzenie:
Po zarejestrowaniu użytkownik powinien otrzymać komunikat o włączeniu nowych możliwości wykorzystywania aplikacji, włącznie z opcją logowania telefonem, bez wykorzystywania hasła:
W samej aplikacji, dla danego konta widzimy, iż zostało włączone „logowanie bezhasłowe”:
Jak więc wygląda takie logowanie? Przy pierwszym logowaniu użytkownik zamiast podawać hasło musi kliknąć opcję Use an app instead:
Na ekranie wyświetlona zostaje liczba, która posłuży do zatwierdzenia logowania w aplikacji (ten etap może być różny w zależności od konfiguracji samej metody uwierzytelniania na tenancie):
Użytkownik wprowadza wyświetloną na ekranie liczbę w aplikacji:
i … tyle. Użytkownik zostaje zalogowany. Bez podawania hasła.
Przy okazji kolejnych logowań – hasło będzie dostępne wyłącznie jako metoda alternatywna. Główną metodą logowania będzie aplikacja Microsoft Authenticator. To oczywiście tylko przykład, bazujący akurat na wspomnianej aplikacji. Warto tutaj nadmienić, iż w przypadku wykorzystywania środowiska chmurowego, bardziej efektywną alternatywą może być np. logowanie dzięki biometrii poprzez Windows Hello (o ile nasze urządzenia to wspierają) i SSO do innych usług czy aplikacji. Możliwości jest wiele, a ich konfiguracja to temat na zupełnie osobny artykuł.
Rozwiązanie to ma oczywiście swoje wady – nie pozwala całkowicie zrezygnować z hasła ani wymusić aplikację jako domyślną metodę uwierzytelniania dla wszystkich użytkowników. Mimo wszystko myślę, iż stanowi ciekawą alternatywę i może być wykorzystane jako pierwszy krok w przyzwyczajaniu użytkowników do logowania bez używania hasła.
Ciekawostka: Logowanie poprzez numer telefonu
Na koniec ciekawostka – czy wiedzieliście, iż zamiast podawać adres email, w polu logowania możemy podać np. numer telefonu, który jest „przypięty” do naszego konta?
Proces logowania odbywa się tutaj w dokładnie taki sam sposób. Możemy zatwierdzić nasze logowanie np. dzięki aplikacji:
Czy też dzięki naszego hasła, bądź innej, dopuszczalnej metody uwierzytelniania:
Co w przypadku, gdy numer telefonu będzie przypięty do kilku różnych kont? Zwyczajnie wybierzemy, na które konto chcielibyśmy się zalogować.
Słowo końcowe
Metod uwierzytelniania, które są dostępne w Azure Active Directory jest bardzo wiele i tylko od nas zależy, z których będziemy chcieli korzystać w naszych organizacjach. Oby z tych bardziej bezpiecznych!
Oczywiście powyższy artykuł absolutnie nie wyczerpuje tematu uwierzytelniania, a tak jak wspominałem, koncentruje się na pokazaniu dostępnych metod, stanowiąc wstęp do bardziej obszernego artykułu poświęconemu MFA, który postaram się napisać w najbliższych tygodniach. W nim możecie spodziewać się kolejnych wątków związanych z uwierzytelnianiem. Mam jednak nadzieję, iż pomógł Wam on przede wszystkim zorientować się, jakimi metodami mogą uwierzytelniać się Wasi użytkownicy, a także pomoże Wam w świadomym wyborze tych, które zagwarantują jak najwyższy poziom bezpieczeństwa w Waszych organizacjach, zależnie od możliwości.
