Ile razy w pracy administratora czy na Help Desk-u spotykamy się z koniecznością zresetowania hasła użytkownikowi? Myślę, iż śmiało mogę zaryzykować stwierdzenie, iż nie jest to rzadka sytuacja także w Waszych organizacjach. Konieczność zresetowania użytkownikowi hasła wiąże się (a przynajmniej powinna) z dobrą weryfikacją jego tożsamości, samym zresetowaniem hasła, bezpiecznym przesłaniem zresetowanego, jednorazowego hasła użytkownikowi itd. Prawdą jest, iż nie jest to najbardziej złożony proces świata, ale mimo to zabiera nam tak istotny w codziennej pracy czas. A co, o ile moglibyśmy bezpiecznie resetować hasła użytkowników w pełni automatyzując ten proces? Z mechanizmem „Samoobsługowego resetowania hasła” znanego bardziej pod skrótem SSPR to możliwe!
Czy samodzielne resetowanie hasła przez użytkowników jest bezpieczne?
Zacznijmy od najbardziej fundamentalnej kwestii, która często pojawia się w pierwszym pytaniu o to rozwiązanie – czy SSPR jest bezpieczny? Co do zasady można by pomyśleć, iż samodzielne resetowanie hasła przez użytkownika rodzi pewne ryzyko. Skoro użytkownik może sam zresetować sobie hasło, to czy potencjalny atakujący nie jest w stanie zrobić tego samego? Obawy te są jak najbardziej słuszne, ale o ile spojrzymy trochę głębiej mogą okazać się one, akurat dla tego mechanizmu, nie do końca uzasadnione.
Korzystanie z SSPR wymaga tego, aby użytkownik miał włączone MFA, które stanowi podstawę bezpieczeństwa całego procesu. Przy procesie resetowania hasła będziemy wymagali od użytkownika uwierzytelnienia się dzięki jednej lub dwóch dodatkowych metod weryfikacji. Jak stali czytelnicy za pewne się domyślają – będę rekomendował opcję dwóch metod, która zagwarantuje nam dodatkowy poziom bezpieczeństwa. Naturalnie, dopiero po potwierdzeniu swojej tożsamości przez Microsoft Authenticator, kod z prywatnego maila, SMS itp. będzie on mógł zmienić swoje hasło.
Zastanówmy się teraz jak może wyglądać taki proces bez wykorzystania tego mechanizmu. Użytkownik dzwoni na Help Desk czy do Administratora z prośbą o zmianę hasła. Osoba z help desku, szczególnie w dużych organizacjach, nie zna głosu większości osób, więc nie jest w stanie stwierdzić czy aby na pewno dzwoni do niej właściciel konta. Z tego względu niezbędne jest przygotowanie jakiejś formy procedury weryfikacji tożsamości użytkownika. O ile pracujemy z biura – pracownik może przyjść i pokazać się fizycznie. W dobie pracy zdalnej ograniczenia co do takich możliwości są jednak dużo większe.
Rozważając, która z podanych opcji jest bezpieczniejsza trzeba by zastanowić się co jest bardziej prawdopodobne:
- To, iż ktoś podszyje się pod użytkownika dzwoniąc na nasz Help Desk i znajdzie sposób na uwierzytelnienie
- To, iż ktoś będzie miał dostęp do naszego prywatnego maila i/lub telefonu i/lub aplikacji Microsoft Authenticator (dodatkowo zabezpieczonej na telefonie)
W mojej opinii wykorzystanie SSPR jest przynajmniej tak samo bezpieczne (a stwierdziłbym nawet, iż bezpieczniejsze), a przy okazji niesie za sobą benefit w postaci automatyzacji tego procesu. Mimo wszystko, wprowadzenie takiego mechanizmu w swojej organizacji warto poprzedzić rzetelnie przeprowadzoną analizą ryzyka.
Resetowanie haseł dla kont administracyjnych
Zanim przejdziemy do kwestii konfiguracji mechanizmu oraz omawiania dostępnych możliwości należałoby jeszcze poruszyć kwestię wykorzystania tego mechanizmu dla kont administracyjnych. Z uwagi na dużo wyższe uprawnienia względem zwykłych użytkowników, a tym samym potencjalnie dużo większy wpływ przejęcia takiego konta, trzeba podejść do nich nieco inaczej.
O tych kwestiach Microsoft pomyślał za nas definiując domyślne zasady dla resetowania haseł do kont administracyjnych. o ile chodzi o SSPR dla kont administarcyjnych:
- Mechanizm jest domyślnie włączony
- Zawsze wymaga podania dwóch składników uwierzytelniania
- Nie zezwala na wykorzystanie pytań zabezpieczających (o czym w dalszej części)
- Domyślna polityka resetowania haseł dla administratorów nie może być modyfikowana
- Polityka może zostać wyłączona z poziomu PowerShell-a
Szczegóły dotyczące ról objętych działaniem tej polityki, a także min. wyjątki znajdziecie tutaj.
Jak włączyć mechanizm samodzielnego resetowania hasła?
Mechanizm Self-service password reset, jak większość mechanizmów związanych z zarządzaniem czy ochroną tożsamości, znajdziemy w Azure Active Directory. Możemy dostać się tam zarówno z portalu Azure, jak i portalu AAD. W Azure Active Directory odnajdujemy opcję Password Reset:
Tutaj możemy zacząć konfigurować omawiany mechanizm. W pierwszej kolejności określamy, czy mechanizm będzie włączony dla wszystkich użytkowników w naszej organizacji czy tylko dla wybranych grup. Naturalnie w przypadku wdrażania tego mechanizmu zalecane jest stopniowe włączanie go dla kolejnych grup użytkowników i upewnienie się, iż wszystko działa poprawnie:
Metody uwierzytelniania
Przechodząc dalej możemy zdefiniować metody, z których będzie mógł skorzystać użytkownik. Wśród nich możemy znaleźć:
- Powiadomienia w aplikacji Microsoft Authenticator – w momencie logowania użytkownik otrzyma powiadomienie na swoim telefonie. Wchodząc do aplikacji Microsoft Authenticator będzie on musiał zatwierdzić lub odrzucić daną próbę logowania. Opcja ta nie jest dostępna w przypadku korzystania tylko z jednej metody.
- Kod jednorazowy w aplikacji Microsoft Authenticator – po dodaniu konta do aplikacji użytkownikowi będą wyświetlały się jednorazowe kody, które są zmieniane co 30 sekund. W momencie logowania użytkownik zostanie poproszony o wprowadzenia aktualnego kodu widocznego w aplikacji.
- Email – użytkownik otrzyma kod jednorazowy na wskazany (np. prywatny, nie powiązany z kontem dla którego resetujemy hasło) adres email.
- Mobile Phone – Uwierzytelnienie poprzez jednorazowy kod SMS lub automatyczne połączenie telefoniczne
- Office Phone – Uwierzytelnienie przez połączenie telefoniczne
- Security Questions – pytania bezpieczeństwa znane z klasycznych systemów odzyskiwania hasła. o ile mamy możliwość skorzystania z innych opcji, będą one oferowały zdecydowanie wyższy poziom bezpieczeństwa. Wprowadzając taką możliwość warto pamiętać, aby odpowiedzi nie były łatwe do znalezienia w wyszukiwarkach czy na portalach społecznościowych. Liczba niezbędnych do skonfigurowania pytań, wymagana ilośc poprawnych odpowiedzi jak również sama treść pytań jest przez nas w pełni konfigurowalna.
Rejestracja SSPR
Poniżej znajdziemy sekcję Registration (rejestracji w kontekście dodania dozwolonych metod logowania). W tym miejscu możemy określić czy użytkownicy zostaną zmuszenia do skonfigurowania odpowiednich metod przy okazji najbliższego logowania. Sam proces, podobnie jak przy okazji rejestracji MFA, jest przyjazny dla użytkownika prowadząc go krok po kroku przez cały proces.
Podawane dane uwierzytelniające z czasem mogą się dezaktualizować. Z tego względu poniżej możemy określić liczbę dni, po której użytkownik będzie musiał zweryfikować poprawność wprowadzonych danych. Oczywiście o ile wszystkie dane będą przez cały czas aktualne, będzie on mógł potwierdzić ich poprawność bez wprowadzania dodatkowych zmian.
Powiadomienia
Przechodząc niżej znajdziemy sekcję powiadomień (Notifications). Możemy tutaj określić, czy o przeprowadzeniu procesu resetowania hasła powiadomiony zostanie użytkownik oraz administratorzy.
W przypadku użytkowników – zdecydowanie warto zostawić tą opcję włączoną. Może się to okazać szczególnie istotne, gdy atakującemu uda się pomyślnie zresetować hasło do konta użytkownika. Użytkownik mając włączone powiadomienia będzie miał szansę zauważyć podejrzaną aktywność na swoim koncie i zgłosić ją do działu bezpieczeństwa. Pozwoli to jak najszybciej podjąć odpowiednie kroki w celu ograniczenia skutków takiego ataku.
W przypadku powiadomień dla administratorów. Z jednej strony proces resetowania hasła przez administratora jest na tyle wrażliwy, iż administratorzy powinni być o tym informowani. Z drugiej strony w wielu organizacjach wykorzystujemy konta funkcyjne, więc skrzynki pocztowe globalnych administratorów mogą nie być tak często monitorowane. Wszystko zależy od scenariusza – ja jednak skłaniam się ku włączeniu powiadomień również w tym przypadku.
Dostosowywanie
Pomimo automatyzacji połączonej z względną prostotą działania całego mechanizmu mogą zdarzyć się sytuacje, gdy użytkownicy będą wymagali naszego wsparcia. Aby jak najbardziej uprościć im dotarcie do osób, które mogą pomóc im w tym zakresie, możemy wskazać nasz indywidualny adres URL lub adres mailowy, poprzez który będą oni mogli skontaktować się z naszym Help Desk-iem i uzyskać stosowną pomoc:
Mechanizm SSPR w środowiskach hybrydowych
Standardowo mechanizm samodzielnego resetowania hasła włączony jest dla użytkowników „chmurowych” (kont utworzonych w Azure Active Directory). o ile jednak synchronizujemy konta naszych użytkowników z lokalnego Active Directory i mamy włączoną opcję password writeback – możemy skorzystać z niego również w środowisku hybrydowym. O kwestii synchronizacji, w tym o password writeback pisałem tutaj.
Mając prawidłowo zestawioną synchronizację możemy włączyć integrację mechanizmu SSPR z naszym środowiskiem domenowym. Poza informacją o prawidłowym działaniu narzędzia AAD Connect możemy wybrać dwie opcje:
- Czy hasła naszych użytkowników będą synchronizowane/”przekazywane” do środowiska lokalnego. Oczywiście o ile wyłączymy tą opcję – użytkownicy nie będą w stanie zresetować czy zmienić swojego hasła z poziomu mechanizmu SSPR, ponieważ nie będzie on miał możliwości przekazania informacji o zmianie do środowiska lokalnego.
- Czy użytkownicy będą mieli możliwość odblokowania swojego konta bez konieczności resetowania hasła. Oczywiście o ile konto użytkowników zostało już zablokowane, zmiana/reset hasła do takiego konta wydaje się być zdecydowanie zalecaną opcją.
Więcej informacji na temat integracji mechanizmu SSPR z środowiskiem domenowym można znaleźć w dokumentacji.
Samodzielne resetowanie hasła w praktyce
Czas zademonstrować jak działa mechanizm samodzielnego resetowania hasła w praktyce. W pierwszej kolejności, przy okazji najbliższego logowania, użytkownik zostanie poproszony o uzupełnienie dodatkowych informacji:
Proces ten, zarówno tutaj jak i przy okazji rejestracji chociażby MFA, jest bardzo intuicyjny, więc nie będę pokazywał go w tym wpisie krok po kroku.
Po dodaniu odpowiednich metod uwierzytelniania użytkownik może bez przeszkód. Co jednak, o ile za jakiś czas użytkownik zapomni swojego hasła? Logując się do usług Microsoft użytkownik może skorzystać z widocznej na ekranie logowania opcji Forgot my password/Zapomniałem hasła:
Zostanie on przekierowany na stronę, na którą może też wejść bezpośrednio w celu zmiany swojego hasła – passwordreset.microsoftonline.com. Na stronie w pierwszej kolejności niezbędne będzie podanie konta, dla którego będziemy przeprowadzali reset hasła. o ile klikamy w zaznaczony na obrazku powyżej link – pole to zostanie wypełnione automatycznie.
Następnie przechodzimy do etapu weryfikacji tożsamości dla wskazanego przez nas konta. W pierwszym kroku wybieramy jedną z dopuszczalnych i skonfigurowanych opcji uwierzytelniania i potwierdzamy swoją tożsamość:
Co istotne, w przypadku wybrania jednej z dostępnych dla Microsoft Authenticator opcji nie mamy już możliwości wykorzystania drugiej, która jest dostępna z tej samej aplikacji. Eliminuje to prawdopodobieństwo, iż atakujący mając dostęp do naszego telefonu mógłby dzięki dwóch metod dostępnych z poziomu tego samego urządzenia potwierdzić „swoją” tożsamość:
Po potwierdzeniu swojej tożsamości przez dwie różne metody uwierzytelniania (lub jednej, w zależności od wybranej konfiguracji) możemy przejść do ustanowienia nowego hasła dla naszego konta:
Chociaż mechanizm standardowo wymusza odpowiednią długość oraz złożoność hasła (czy 8 znaków możemy nazwać „odpowiednią długością” to akurat temat dyskusyjny, o którym pisałem tutaj) warto oczywiście pamiętać o pozostałych dobrych praktykach np. o niestosowaniu wyrażeń słownikowych. Problem ten częściowo możemy rozwiązać dzięki mechanizmu Password Protection (ochrona hasłem) … ale to temat na zupełnie odrębny wpis.
Kończąc temat resetowania hasła – użytkownik, zgodnie z konfiguracją, otrzymuje maila z informacją o zmianie hasła na jego koncie. Jak łatwo zauważyć – wiadomość zostaje wysłana nie tylko na adres służbowy, ale też skonfigurowany adres prywatny użytkownika.
