MFA w Azure AD, a problem TOFU

Dwuskładnikowe, albo wieloskładnikowe uwierzytelnianie staje się już standardem w branży IT. Niestety samo włączenie dwuskładnikowego uwierzytelniania nie zawsze w pełni zabezpieczy nas przed atakami. Dość sporo uwagi poświęcono już atakom na SMSy, jako drugi składnik. Często wypomina się także podatność niektórych form drugiego składnika na ataki phishingowe przed czym mogą zabezpieczyć fizyczne klucze bezpieczeństwa korzystające z protokołów FIDO/U2F, np. popularne Yubikey. Jednak nawet fizyczne klucze bezpieczeństwa nie zabezpieczą nas przed lukami w konfiguracji Multi Factor Authentication.

Standardowo, gdy włączymy MFA w Azure Active Directory, użytkownikowi przy kolejnym logowaniu zostanie przedstawiony kreator, który krok po kroku przeprowadzi go przez proces rejestracji drugiego składnika. Występuje tutaj podejście do bezpieczeństwa nazywane czasem jako Trust On First Use – ufamy, że to logowanie pochodzi od prawdziwego użytkownika, a nie atakującego. 

Zależnie od modelu onboardingu nowych pracowników i wdrożenia MFA w organizacji może być to dla nas mniej, lub bardziej realny scenariusz ataku. Jednak zazwyczaj powinniśmy liczyć się z tym, że atakujący może w wyniku np. ataku password spraying, uzyskać dostęp do konta bez MFA i samodzielnie dokonać rejestracji MFA. Zwłaszcza jeśli posiadamy zapomniane konta, na które nikt nigdy się nie logował.

Możemy się przed tym zabezpieczyć korzystając z Conditional Access, modułu Azure Active Directory (wymaga on licencji Azure AD Premium P1 lub P2, ale zawarty jest też w innych licencjach Microsoft). Wystarczy stworzyć politykę warunkowego dostępu ograniczająca możliwość rejestracji MFA do listy zaufanych publicznych adresów IP należących do organizacji.

1. Pierwszym krokiem jest dodanie nowej Named Location i listy zaufanych podsieci w niej zawartych

2. Następnie tworzymy nową Conditional Access Policy, wpisujemy nazwę i wybieramy kogo będzie ona dotyczyć, tutaj: wszystkich użytkowników.

3. Kolejnym krokiem jest wybór akcji lub aplikacji, których dotyczyć będzie polityka – w tym przypadku User Actions i Register security information

4. Wybieramy warunki, których dotyczyć będzie polityka – tutaj wszystkich lokalizacji, poza wybranym przez nas wyjątkiem. Gdybyśmy wcześniej naszą lokalizację oznaczyli jako zaufaną, można byłoby też użyć opcji All trusted locations.

5. Wybieramy akcję, którą będzie objęte logowanie, jeśli spełnione zostaną wymienione wcześniej warunki. Wybranie Block zablokuje możliwość nie tylko pierwszej konfiguracji MFA, ale także zmian tej konfiguracji spoza zaufanych adresów IP. Alternatywnie można wybrać Require multi-factor authentication, wtedy zmiany konfiguracji MFA spoza zaufanych adresów IP będą dozwolone pod warunkiem zalogowania się przez użytkownika z użyciem MFA.

6. Politykę można od razu włączyć lub tylko przetestować w trybie Report-only. Przy kliknięciu Create portal sugeruje wykluczenie aktualnego użytkownika z polityki, aby przez błędna konfigurację nie odciąć sobie samemu dostępów.
7. W przypadku próby rejestracji MFA spoza zaufanej sieci użytkownik dostanie komunikat:

Alternatywą dla powyższej konfiguracji może być skorzystanie z nowej funkcjonalności Azure AD – Temporary Access Pass i wydawanie pewnego rodzaju tymczasowych przepustek użytkownikom, aby mogli sobie skonfigurować MFA. Jest to opisane w dokumentacji Azure AD. Należy pamiętać, że funkcjonalność Temporary Access Pass jest aktualnie dostępna w trybie Preview, czyli wersji beta.

W podobny sposób warto też zabezpieczyć konta techniczne, na których z oczywistych względów nie da się włączyć MFA, ale których logowania jesteśmy w stanie ograniczyć do konkretnych publicznych adresów IP lub podsieci.

Dodatkowo warto też korzystać z mechanizmu Azure AD Password Protection, aby blokować tworzenie haseł, które mimo spełniania typowej polityki złożoności (długość, duże i małe znaki, cyfry, itp.) są dość proste do złamania, np. Październik 2021!.

~Paweł Małkiewicz