Uwierzytelnianie wieloskładnikowe i dostęp warunkowy

Skradzione dane uwierzytelniające są główną przyczyną naruszeń bezpieczeństwa w chmurze. Samo hasło można wyłudzić za pomocą phishingu, odgadnąć metodą brute force lub ujawnić w wyniku wycieku danych od zewnętrznego dostawcy. Uwierzytelnianie wieloskładnikowe (MFA) wymaga drugiego składnika weryfikacji, którego atakujący prawdopodobnie nie będzie posiadać nawet po uzyskaniu hasła — znacząco ogranicza to ryzyko nieautoryzowanego dostępu do środowiska Azure.

Entra ID obsługuje wiele składników weryfikacji MFA. Najbezpieczniejszą i zalecaną opcją jest aplikacja Microsoft Authenticator, która zapewnia dopasowywanie numerów i powiadomienia push. Inne opcje to klucz zabezpieczeń FIDO2 (token sprzętowy), programowy token OATH, wiadomość tekstowa SMS lub połączenie głosowe. SMS-y i połączenia głosowe zapewniają niższy poziom bezpieczeństwa i powinny być używane wyłącznie jako metody awaryjne.

MFA w usłudze Entra ID można wymuszać za pomocą trzech mechanizmów. Ustawienia zabezpieczeń domyślnych to bezpłatna opcja uruchamiana jednym kliknięciem, która wymusza MFA dla wszystkich użytkowników, ale nie pozwala na dostosowanie konfiguracji. MFA dla poszczególnych użytkowników (starsze rozwiązanie) włącza MFA dla określonych kont użytkowników. Zalecanym nowoczesnym podejściem są zasady dostępu warunkowego (Entra ID P1/P2), które wymuszają MFA tylko wtedy, gdy zostaną spełnione określone warunki ryzyka, ograniczając niedogodności dla użytkowników podczas logowań niskiego ryzyka.

Dostęp warunkowy (Entra ID P1) to mechanizm zasad typu jeśli–to: jeśli użytkownik (lub grupa) próbuje uzyskać dostęp do zasobu w określonych warunkach, to należy przyznać dostęp, zablokować go lub wymagać dodatkowych mechanizmów kontroli, takich jak MFA albo zgodne urządzenie. Warunki mogą obejmować tożsamość użytkownika, zgodność urządzenia, lokalizację adresu IP, używaną aplikację oraz wynik oceny ryzyka w usłudze Entra ID Identity Protection.

Zasada dostępu warunkowego składa się z dwóch części: Przypisania (kogo i czego dotyczy zasada) oraz Mechanizmy kontroli dostępu (co dzieje się po uruchomieniu zasady). Przypisania określają Użytkowników/grupy, używane Aplikacje w chmurze oraz Warunki (lokalizację, platformę urządzenia i ryzyko logowania). Mechanizmy kontroli dostępu określają, czy należy Przyznać dostęp (opcjonalnie wymagając MFA, zgodnego urządzenia lub zatwierdzonej aplikacji), czy całkowicie go Zablokować.

Nazwane lokalizacje w dostępie warunkowym pozwalają definiować zaufane zakresy adresów IP (na przykład sieć firmowego biura) lub kraje. Często stosowany wzorzec zasady to: wymaganie MFA, gdy użytkownik loguje się spoza zaufanej nazwanej lokalizacji, oraz zezwalanie na dostęp bez dodatkowych kontroli podczas logowania ze znanego biurowego adresu IP. Ogranicza to niedogodności dla pracowników na miejscu, jednocześnie zwiększając bezpieczeństwo użytkowników zdalnych lub podróżujących.

Dostęp warunkowy może wymagać, aby urządzenie uzyskujące dostęp było zgodne (spełniało zasady zgodności urządzeń w usłudze Intune) lub było firmowym urządzeniem hybrid Azure AD joined. Dzięki temu nawet przy prawidłowych danych uwierzytelniających logowania z urządzeń osobistych lub niezarządzanych są blokowane albo wymagają spełnienia dodatkowych warunków. Mechanizmy kontroli oparte na urządzeniach są jednym z filarów modelu bezpieczeństwa Zero Trust.

Entra ID Identity Protection (P2) wykorzystuje uczenie maszynowe do oceny każdego logowania i przypisuje mu ocenę ryzyka: niską, średnią lub wysoką. Czynniki ryzyka obejmują niemożliwą podróż (logowanie z dwóch krajów w ciągu kilku minut), anonimowy adres IP, wyciek danych uwierzytelniających oraz wykrycie ataku typu password spray. Zasady dostępu warunkowego mogą być uruchamiane na podstawie poziomu ryzyka — na przykład mogą wymagać MFA przy średnim ryzyku i automatycznie blokować dostęp przy wysokim ryzyku.

Przed wymuszeniem zasady dostępu warunkowego można ustawić ją w trybie Report-Only. W tym trybie zasada jest sprawdzana dla wszystkich logowań i rejestrowane jest to, co by się wydarzyło (dostęp zostałby przyznany, zablokowany lub wymagane byłoby MFA), ale mechanizmy kontroli nie są faktycznie egzekwowane. Pozwala to sprawdzić wpływ zasady na użytkowników przed jej włączeniem i zapobiec nieoczekiwanym blokadom dostępu wynikającym z nieprawidłowo określonych warunków.

Narzędzie What If w obszarze dostępu warunkowego pozwala symulować scenariusz logowania — określając użytkownika, aplikację, adres IP, platformę urządzenia i poziom ryzyka — oraz sprawdzić, które zasady miałyby zastosowanie i jaki byłby łączny wynik ich działania. Jest to niezwykle przydatne podczas rozwiązywania problemów z dostępem i sprawdzania, czy zestaw zasad daje oczekiwany rezultat dla określonych użytkowników i warunków.

Każda organizacja powinna utrzymywać co najmniej dwa awaryjne konta dostępu break-glass, wykluczone ze wszystkich zasad dostępu warunkowego, w tym z wymagań MFA. Konta te są używane wyłącznie w przypadku awarii infrastruktury MFA lub zablokowania dostępu wszystkim administratorom. Dane uwierzytelniające kont break-glass należy przechowywać w fizycznym sejfie, używać długich losowych haseł, nie rejestrować dla nich MFA oraz dokładnie kontrolować każde użycie.

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznali Państwo następujące zagadnienia: MFA wymaga drugiego składnika poza hasłem, znacznie ograniczając ryzyko kradzieży danych uwierzytelniających, zasady dostępu warunkowego stosują mechanizmy przyznawania lub blokowania dostępu na podstawie użytkownika, aplikacji, lokalizacji i warunków ryzyka, a Identity Protection wykorzystuje ocenę ryzyka opartą na ML do uruchamiania automatycznych mechanizmów kontroli dostępu. W następnej części omówimy funkcję Single Sign-On i tożsamości zewnętrzne w usłudze Entra ID.