Dzisiaj na warsztat bierzemy temat niezwykle istotny, szczególnie w kontekście wycieków danych, o których słyszymy coraz częściej – ochronę tożsamości. Mechanizmów do ochrony tożsamości w Microsoft 365, czy konkretnie w Azure Active Directory jest przynajmniej kilka. Możemy tu wspomnieć choćby o MFA, Dostępie warunkowym, ochronie hasłem czy właśnie o mechanizmie „ochrona tożsamości” (ang. Identity Protection). Mechanizm ten, mimo mało skomplikowanej nazwy, jest jednym z najbardziej zaawansowanych mechanizmów Microsoft, które dotyczą procesu uwierzytelniania. W jaki sposób działa, jak możemy go skonfigurować i kiedy okaże się on skuteczny? Zapraszam do lektury!
Ochrona tożsamości (Identity Protection)
Jak wspominałem, mechanizm ochrony tożsamości jest jednym z najbardziej zaawansowanych rozwiązań bezpieczeństwa związanych z procesem uwierzytelniania, które oferuje Microsoft. Jego działanie opiera się przede wszystkim na sztucznej inteligencji, która szacuje dwa rodzaje ryzyka:
- Ryzyko związane z kontem użytkownika – poziom ryzyka to poziom prawdopodobieństwa, że ktoś może/mógł uzyskać dostęp do konta użytkownika. Przykładem wysokiego poziomu ryzyka związanego z kontem użytkownika może być np. znalezienie poświadczeń w opublikowanym wycieku danych.
- Ryzyko związane z logowaniem – poziom ryzyka odzwierciedla prawdopodobieństwo, że dane logowanie nie zostało wykonane przez właściciela danego konta. Przykładem wyższego poziomu ryzyka może być np. logowanie z drugiego końca świata w odstępie kilku minut od poprzedniego logowania. Innym przykładem może być np. wykorzystanie sieci TOR czy inne formy anonimizacji adresu IP.
W zależności od zidentyfikowanego poziomu ryzyka mechanizm będzie podejmował określone przez nas na etapie konfiguracji decyzje. Na jego podstawie określone działania mogą podejmować również inne mechanizmy, np. mechanizm dostępu warunkowego.
Identity Protection doskonale integruje się również z mechanizmem MFA (uwierzytelnianie wieloskładnikowe) czy SSRP (samodzielny reset hasła przez użytkownika). Dzięki temu, w przypadku wykrycia podwyższonego poziomu ryzyka, jest on w stanie zadziałać i wymusić określone czynności na użytkowniku bez ingerencji administratora.
Jak działa mechanizm ochrony tożsamości?
Żeby zrozumieć jak dokładnie działa ten mechanizm spójrzmy na poniższy schemat:
- Użytkownik chce się zalogować do swojego konta w Azure AD
- Azure AD rozpoczyna proces obliczania ryzyka w czasie rzeczywistym, na bazie otrzymanych „parametrów” logowania. Może to być np. lokalizacja, adres IP, urządzenie. Na tej podstawie wyliczany jest Poziom ryzyka związanego z logowaniem.
- Mechanizm bierze obliczony właśnie Poziom ryzyka związanego z logowaniem oraz obliczony wcześniej Poziom ryzyka związanego z kontem użytkownika. Obydwa poziomy ryzyka zostają zagregowane tworząc poziom ryzyka dla aktualnego logowania danego użytkownika.
- Następuje weryfikacja określonego poziomu ryzyka ze skonfigurowanymi politykami. Na tej podstawie mechanizm determinuje, czy niezbędne jest podjęcie jakichś działań.
- Jeżeli poziom ryzyka spełnia wymagania którejkolwiek z polityk przypisanych do użytkownika, podejmowane są określone w polityce działania. W przeciwnym przypadku użytkownik pomyślnie przechodzi proces logowania.
Pomimo pozornie dość złożonego procesu, jest on przeprowadzany w mgnieniu oka. Użytkownik logujący się do systemu prawdopodobnie nawet nie zauważy, że w samym procesie cokolwiek się zmieniło czy wydłużyło.
Konfiguracja mechanizmu ochrony tożsamości
Aby poznać możliwości mechanizmu przejdźmy do jego konfiguracji. Znajdziemy go wchodząc do Azure Active Directory (przez portal AAD lub portal Azure), a następnie do zakładki Security (Zabezpieczenia):
W menu po lewej stronie znajdziemy mechanizm Identity Protection:
Rejestracja MFA
Będąc już w samym mechanizmie możemy przejść do konfiguracji, która mimo złożonego działania mechanizmu jest relatywnie prosta. Zacznijmy od polityki rejestracji MFA:
Nie trudno się domyśleć, że będzie ona odpowiadała za wymuszenie rejestracji MFA dla wybranych użytkowników. Oznacza to, że użytkownik przy okazji logowania zostanie poproszony o skonfigurowanie dodatkowych składników uwierzytelniania.
Na potrzeby tej demonstracji wymusimy rejestrację MFA dla jednego, wybranego użytkownika w naszej organizacji. W przypadku środowiska produkcyjnego, nawet jeżeli nie korzystamy z mechanizmu ochrony tożsamości, warto zadbać o to, aby MFA miał skonfigurowane i włączone absolutnie każdy pracownik w naszej organizacji.
Na dole mamy jeszcze możliwość określenia, czy dana polityka ma zostać włączona. W naszym przypadku przestawiamy oczywiście suwak na pozycję On:
Przy okazji kolejnego logowania wybranego użytkownika zobaczy on komunikat o konieczności podania większej ilości informacji.
Domyślnie może on pomijać ten proces przez najbliższe 14 dni. Po tym okresie pominięcie rejestracji nie będzie możliwe. Użytkownik zostanie poproszony o podanie danych typu aplikacja czy numer telefonu, za pomocą których będzie przeprowadzana dodatkowa weryfikacja.
Ryzyko związane z logowaniem
Mając już skonfigurowaną politykę wymuszającą rejestrację MFA, przejdźmy do konfiguracji polityki ryzyka związanego z logowaniem. Jej konfiguracja również nie jest przesadnie skomplikowana. Będziemy mieli tutaj do określenia trzy elementy:
- Zakres działania, tj. których użytkowników ma ona dotyczyć
- Poziom ryzyka, po osiągnięciu którego podejmowane będą jakieś działania
- Sposób działania, jeżeli dane logowanie osiągnie wskazany wcześniej poziom ryzyka:
Na potrzeby demonstracyjne skonfigurujmy przykładową politykę w następujący sposób:
- Będzie ona obejmowała działaniem użytkownika, któremu wcześniej wymuszaliśmy rejestrację MFA
- Kroki będą podejmowane po osiągnięciu przynajmniej średniego poziomu ryzyka
- System będzie blokował dostęp w przypadku osiągnięcia takiego poziomu ryzyka. Alternatywnie możemy tutaj np. wymagać MFA (podczas gdy przy braku ryzyka, nie będzie ono wymagane)
Sposób obliczania ryzyka przez mechanizm nie jest publicznie udostępniony przez Microsoft. Wiemy natomiast, że im wyższy poziom ryzyka, tym wyższa pewność, że dane logowanie nie jest przeprowadzane przez właściciela konta. Znamy również długą listę elementów, na podstawie których ryzyko jest określane. Jest to np. próba anonimizacji adresu IP (np. poprzez TOR), nietypowa podróż w krótkim odstępie czasu (mechanizm ma wbudowany element uczenia maszynowego, który pozwala odróżnić takie logowanie od wykorzystania VPN-a), a także szereg innych elementów związanych np. z nieprawidłowościami w tokenach dostępu. Szerszą listę analizowanych czynników znajdziemy w dokumentacji.
Ryzyko związane z użytkownikiem
Kolejnym typem polityki, który możemy skonfigurować jest polityka ryzyka związanego z użytkownikiem. Jego konfiguracja jest w zasadzie identyczna jak w przypadku ryzyka związanego z logowaniem. Różnicą jest natomiast sposób działania oraz elementy, które są brane pod uwagę przy ocenie ryzyka.
Ryzyko związane z użytkownikiem nie jest obliczane w czasie rzeczywistym w momencie, gdy użytkownik loguje się do systemu. Jest ono obliczane ogólnie dla konta danego użytkownika, nie dla konkretnego logowania. Elementami, branymi pod uwagę przy obliczeniach są np. analizowane przez Microsoft wycieki danych. Jeżeli w znalezionej bazie z wycieku znajdą się poświadczenia danego użytkownika – ryzyko dla tego konta jest natychmiast podnoszone. Oprócz wycieków na ryzyko wpływ ma Azure AD Threat Intelligence. Mechanizm ten pozwala na wykrycie sytuacji, gdy zachowanie danego użytkownika jest nietypowe lub zgodne ze znanymi schematami działania związanymi z konkretnymi atakami.
Jeżeli chodzi o samo działanie mechanizmu, zamiast wymuszania MFA, jak przy logowaniu, możemy wymusić zmianę hasła u danego użytkownika. Mechanizm ten powinien być połączony ze skonfigurowanym mechanizmem SSRP (Self service password reset). Pozwala on użytkownikom, po odpowiednim uwierzytelnieniu, samodzielnie zmienić hasło do swojego konta, bez ingerencji administratora czy help desk-u. Dzięki temu cały proces przebiega z punktu widzenia administratora automatycznie. Dla przykładu:
- Dane zostają znalezione w wycieku
- Mechanizm ochrony tożsamości podnosi poziom ryzyka
- Polityka wymusza zmianę hasła u użytkownika
- Mechanizm SSPR umożliwia użytkownikowi samodzielną zmianę hasła
- Użytkownik zmienia hasło, ryzyko zostaje zminimalizowane, a użytkownik może dalej korzystać ze swojego konta
Polityka dostępu warunkowego
Jak można zauważyć, możliwości konfiguracji mechanizmu ochrony tożsamości są nieco skąpe. Jeżeli chcemy skonfigurować polityki bardziej granularnie, możemy skorzystać z mechanizmu dostępu warunkowego. Sam mechanizm dokładnie omawiałem w jednym z pierwszych artykułów na Blogu, który znajdziecie tutaj.
W sekcji, w której określamy warunki dla tworzonej polityki dostępu warunkowego mamy możliwość wskazania konkretnego poziomu ryzyka:
Co więcej, w przypadku ryzyka związanego z logowaniem mamy możliwość wybrania dodatkowej opcji – No risk. Pozwala ona na jeszcze większe możliwości konfiguracji zasad w tym zakresie:
Dzięki politykom dostępu warunkowego możemy skonfigurować zasady dokładnie odpowiadające naszym potrzebom biznesowym. Możemy spowodować, że mechanizm będzie reagował na dany poziom ryzyka, ale tylko dla wybranych aplikacji. Możemy dołożyć inne warunki, poza poziomem ryzyka, które mają być spełnione. I wreszcie możemy wymagać dużo więcej elementów, aby faktycznie użytkownik mógł przy takich warunkach uzyskać dostęp do aplikacji czy danych:
Ochrona tożsamości w praktyce
Aby zaprezentować sposób działania mechanizmu spróbujmy zalogować się na konto chronionego użytkownika wykorzystując anonimowy adres IP. Przy takiej próbie użytkownik, czy raczej potencjalny atakujący zobaczy następujący komunikat:
Pomimo podania poprawnego loginu i hasła logowanie nie przebiegło pomyślnie. Ze względu na anonimizację adresu, która podniosła poziom ryzyka – polityka zadziałała i zachowała się zgodnie z konfiguracją. Alternatywnie, gdybyśmy zamiast blokady dostępu spróbowali np. wymusić MFA, użytkownik został by w tym miejscu poproszony o dodatkowe uwierzytelnienie.
Raportowanie
Zblokowana próba logowania czy wykrycie ryzyka są oczywiście widoczne dla administratora w formie raportów. Zostały one podzielone na 3 sekcje, adekwatnie do dostępnych polityk:
Bazując na zablokowanej próbie logowania przeanalizujmy widoczne raporty. Zacznijmy od raportów wykrycia ryzyka. Znajdziemy tam informacje o przedstawionej przed chwilą, nieudanej próbie logowania:
Wchodząc w szczegóły możemy zobaczyć cały szereg różnych informacji – od czasu i urządzenia, z którego nastąpiło logowanie, po informacje o poziomie ryzyka czy powodzie jego podniesienia. Jak widać próba logowania z sieci TOR została zaklasyfikowana jako wysokie ryzyko:
Z pomocą widocznych na górze przycisków możemy szybko wyfiltrować odpowiednie informacje, dotyczące danego użytkownika czy logowania:
Przejdźmy teraz do raportu z ryzykownymi logowaniami:
Możemy tutaj znaleźć listę ryzykownych logowań, dla których mamy możliwość podejrzenia wielu szczegółów, które zostały podzielone na 4 różne zakładki widoczne na górze:
Zajrzyjmy jeszcze do raportu zawierającego ryzyka związane z użytkownikami:
Logowanie z anonimowego adresu IP skutkowało określeniem wysokiego ryzyka związanego z logowaniem. Ale … ktoś przy próbie logowania podał przecież prawidłowe hasło do konta użytkownika. Niewątpliwie niesie to za sobą ryzyko tego, że takie hasło zostało przejęte przez atakującego. Stąd też skutkiem zablokowanego logowania jest również podniesienie poziomu ryzyka związanego z samym użytkownikiem. Takie ryzyko zostaje określone jako średnie:
Ponieważ poziom ryzyka dla konta użytkownika został podniesiony, samo konto pozostaje zablokowane. Do momentu podjęcia odpowiednich działań i decyzji przez administratora/dział bezpieczeństwa, konto pozostanie zablokowane. Nawet prawowity użytkownik nie będzie miał możliwości zalogowania się na nie.
Z poziomu raportu przedstawiającego ryzyko związane z użytkownikiem możemy podjąć odpowiednie decyzje. Możemy tutaj zresetować hasło danego użytkownika, potwierdzić przejęcie jego hasła, odblokować konto wskazując na false positive lub zablokować konto użytkownika. Sens wykorzystania opcji zależy od skonfigurowanego sposobu działania mechanizmu – jeżeli nie blokuje on kont w sposób automatyczny, a np. wymaga resetu hasła, możemy wymusić to ręcznie z tego miejsca:
W omawianym przypadku dopóki konto pozostaje zablokowane, dane są bezpieczne. Kolejnym krokiem może być reset hasła i przekazanie jednorazowego hasła właścicielowi konta, a przede wszystkim dokładna weryfikacja, dlaczego doszło do takiego incydentu.
Powiadomienie o wykryciu ryzyka
Elementem zdecydowanie wartym uwagi są alerty, które będą generowane i wysyłane do administratorów i/lub działu bezpieczeństwa po wykryciu odpowiedniego poziomu ryzyka. W menu po lewej stronie znajdziemy sekcję Notify, w której dostępne są dwa typy powiadomień, które będą wysyłane do wskazanych osób:
Zacznijmy od pierwszego z nich, którego zadaniem jest wysłanie powiadomienia w przypadku zidentyfikowania ryzyka na odpowiednim poziomie. W pierwszej kolejności musimy wybrać osoby, które powinny otrzymywać powiadomienia. Domyślnie na liście znajdziemy użytkowników, którzy posiadają rolę Globalnego Administratora, Administratora Zabezpieczeń lub Security Readera (czyli pełen dostęp do mechanizmów bezpieczeństwa, ale w trybie Read-Only). Nie ma również przeciwwskazań, aby maile wysyłane były do innych osób czy na skrzynki funkcyjne. Możliwość wprowadzenia takich adresów znajdziemy na dole listy:
Na samym dole znajdziemy jeszcze możliwość określenia poziomu ryzyka, po osiągnięciu którego alert będzie generowany i wysyłany:
Przykładowy alert, który pojawi się na skrzynkach wybranych osób będzie wyglądał następująco:
Drugie z powiadomień pozwala na przesyłanie cotygodniowego raportu o wykrytych użytkownikach czy logowaniach z podwyższonym ryzykiem. Jest konfiguracja jest analogiczna – wskazujemy określone osoby oraz włączamy lub wyłączamy takie powiadomienia:
Przykładowy mail będzie wyglądał następująco:
Słowo końcowe
Jak widać, mechanizm ochrony tożsamości jest niezwykle prosty w konfiguracji. Oczywiście wykorzystując dostęp warunkowy możemy nieco uszczegółowić i utrudnić cały proces, ale nawet podstawowa konfiguracji okaże się bardzo skuteczna. Pomimo prostoty konfiguracji i przejrzystości raportów czy powiadomień mechanizm ten jest niezwykle skomplikowany „pod spodem”. Dzięki temu, nie komplikując specjalnie życia administratorom, potrafi zapewnić bezpieczeństwo związane z tożsamościami, a przede wszystkim procesem uwierzytelniania na absolutnie najwyższym poziomie.
