Czym jest dostęp warunkowy i jakie reguły warto ustawić?

Co dostęp warunkowy robi w praktyce

Dostęp warunkowy to warstwa typu „jeśli to, to tamto", która stoi przed twoimi aplikacjami. Każde logowanie generuje zestaw sygnałów. Silnik polityk odczytuje te sygnały i stosuje twoje reguły.

Najczęstsze sygnały to:

• Użytkownik lub grupa. Kto się loguje i do jakich grup należy. Regułę możesz zawęzić do wszystkich, tylko do adminów albo tylko do wrażliwego działu.
• Aplikacja. Do jakiej aplikacji lub zasobu ktoś się dostaje. Finanse albo system HR możesz trzymać w wyższym standardzie niż intranet pracowniczy.
• Urządzenie. Czy urządzenie jest znane twojemu systemowi zarządzania, jest zaszyfrowane, spełnia minimalną wersję systemu operacyjnego albo jest oznaczone jako zgodne.
• Lokalizacja. Sieć lub kraj, z którego pochodzi żądanie, zwykle wyznaczane na podstawie adresu IP.
• Ryzyko logowania. Wynik przyznawany przez platformę na podstawie sygnałów takich jak niemożliwa podróż, zanonimizowane adresy IP czy dane uwierzytelniające widziane w znanych wyciekach.

Wynik, jaki stosuje polityka (to „tamto"), to zwykle jedna z trzech opcji: zezwól na dostęp, zablokuj dostęp albo przyznaj dostęp tylko po spełnieniu dodatkowego warunku, najczęściej monitu MFA albo zgodnego urządzenia.

Platformy nazywają to inaczej. W Microsoft 365 jest to Conditional Access, część Microsoft Entra ID. W Google Workspace odpowiednikiem jest Context-Aware Access, który buduje reguły z „poziomów dostępu" opisujących wymagane warunki. Koncepcje są ze sobą blisko spójne, więc poniższe polityki opisujemy najpierw w prostym języku, a potem mapujemy na każdą platformę.

Polityki startowe do ustawienia najpierw

Nie potrzebujesz dziesiątek reguł. Niewielki, dobrze dobrany zestaw pokrywa większość ryzyka. Poniżej polityki, które powinna wdrożyć większość firm mid-market, w przybliżonej kolejności priorytetu.

1. Wymagaj MFA dla wszystkich

To fundament. Wymagaj drugiego składnika dla wszystkich użytkowników we wszystkich aplikacjach chmurowych. Logowanie tylko hasłem to ścieżka najmniejszego oporu dla atakujących korzystających ze skradzionych lub odgadniętych danych uwierzytelniających, a drugi składnik zamyka większość tej luki.

Zastosuj regułę do wszystkich użytkowników i wszystkich aplikacji, a wyklucz tylko to, co naprawdę musisz (twoje konta break-glass oraz konta serwisowe, które uwierzytelniają się w sposób, którego MFA nie obsłuży i które chronisz innymi środkami).

• Microsoft 365: polityka Conditional Access przyznająca dostęp wyłącznie po „Require multifactor authentication". Microsoft dostarcza też zarządzane polityki bazowe wymagające MFA, które możesz wykorzystać jako punkt startowy.
• Google Workspace: wymuś 2-Step Verification i użyj Context-Aware Access, żeby wymagać jej przy dostępie do aplikacji.

2. Zablokuj przestarzałe i podstawowe uwierzytelnianie

Przestarzałe protokoły uwierzytelniania (starsze klienty poczty i Office korzystające z IMAP, POP3, SMTP AUTH i podobnych) nie potrafią wyświetlić monitu MFA. To znaczy, że atakujący łączący się jednym z tych protokołów może ominąć regułę MFA, którą właśnie ustawiłeś. Blokada przestarzałego uwierzytelniania sprawia, że polityka MFA rzeczywiście trzyma.

Ustaw regułę, która blokuje te protokoły całkowicie. Przed jej wymuszeniem sprawdź, czy jakiś realny proces wciąż od nich zależy (stary skaner wysyłający maile przez SMTP, aplikacja liniowa odpytująca skrzynkę) i przenieś je na nowoczesne uwierzytelnianie albo wąsko zakresowany wyjątek.

• Microsoft 365: polityka Conditional Access celująca w „Other clients" (klientów przestarzałego uwierzytelniania) z kontrolą dostępu ustawioną na Block. Microsoft dokumentuje to jako politykę standardową i zaleca uruchomienie jej najpierw w trybie report-only na tydzień lub dwa.
• Google Workspace: wyłącz dostęp dla mniej bezpiecznych aplikacji i wymagaj dostępu opartego na OAuth, co usuwa ścieżki protokołów działających tylko na haśle.

3. Wymagaj zarządzanego lub zgodnego urządzenia dla wrażliwych aplikacji

Dla zasobów o najwyższej wartości (systemy finansowe, HR, konsole administracyjne, kod źródłowy, dane klientów) podnieś poprzeczkę z „zna hasło i przechodzi MFA" na „jest na urządzeniu, które zarządzamy i któremu ufamy". Zgodne urządzenie to takie, które twój system zarządzania raportuje jako spełniające twoje standardy: zaszyfrowane, aktualne, z włączoną blokadą ekranu i tak dalej.

Stosuj to selektywnie. Wymaganie zarządzanego urządzenia wszędzie tworzy tarcie i psuje procesy kontraktorów oraz BYOD. Zastosowanie tego do krótkiej listy wrażliwych aplikacji daje większość korzyści przy niewielkim koszcie.

• Microsoft 365: polityka Conditional Access z kontrolą przyznawania wymagającą zgodnego urządzenia (przez Intune) lub urządzenia hybrid-joined, zawężona do wrażliwych aplikacji.
• Google Workspace: poziom dostępu Context-Aware Access wymagający urządzenia firmowego, zaszyfrowanego i spełniającego minimalną wersję systemu operacyjnego, co zależy od skonfigurowanej weryfikacji endpointów. Warto pamiętać, że wymuszenie polityki urządzeń blokuje dostęp z mobilnej przeglądarki do tych aplikacji, więc najpierw przetestuj efekt na użytkownikach mobilnych.

4. Podnoś poziom weryfikacji przy ryzykownych logowaniach

Niektóre platformy oceniają ryzyko każdego logowania na podstawie sygnałów takich jak niemożliwa podróż, połączenia z usług anonimizujących czy dane uwierzytelniające, które pojawiły się w znanych naruszeniach. Polityka oparta na ryzyku reaguje tylko, gdy wynik jest podwyższony, więc dodaje ochronę bez dodawania monitu przy każdym zwykłym logowaniu.

Typowa reakcja na średni lub wysoki wynik ryzyka to ponowne wymaganie MFA, wymaganie zmiany hasła albo blokada do czasu przeglądu przez admina. To łapie sytuację, w której atakujący ma ważne hasło, a nawet skradzioną sesję, bo nietypowy kontekst i tak uruchamia regułę.

• Microsoft 365: polityki sign-in risk i user risk w Microsoft Entra ID Protection, które można spiąć z Conditional Access, żeby przy podwyższonym ryzyku wymagać MFA albo bezpiecznej zmiany hasła.
• Google Workspace: Google stosuje własną analizę ryzyka logowania i może kwestionować lub blokować podejrzane logowania; Context-Aware Access dokłada na to warunki oparte na atrybutach.

5. Ograniczaj lub oznaczaj logowania z nieoczekiwanych lokalizacji

Większość firm mid-market działa ze znanego zestawu krajów. Reguła lokalizacji pozwala inaczej traktować logowania spoza tego zestawu: zablokować je, wymagać dodatkowego kroku weryfikacji albo po prostu wyróżnić je do przeglądu.

Podejdź do tego rozważnie. Twarda blokada kraju jest czysta, jeśli twój zespół naprawdę nigdy nie podróżuje ani nie pracuje za granicą, ale złapie handlowca na konferencji albo pracownika sprawdzającego pocztę na urlopie. Dla wielu zespołów łagodniejsze podejście (ponowne wymaganie MFA z nieoczekiwanych lokalizacji i alert na taki przypadek) to lepszy balans. Traktuj lokalizację jako jeden sygnał wśród kilku, nie jako mur.

• Microsoft 365: zdefiniuj nazwane lokalizacje lub kraje w Conditional Access, a potem zbuduj politykę, która blokuje lub wymaga dodatkowej kontroli dla logowań spoza spodziewanego zestawu.
• Google Workspace: poziom dostępu Context-Aware Access oparty na podsieci IP lub pochodzeniu geograficznym.

Jak wdrożyć to bez zablokowania samego siebie

Dwie najczęstsze porażki przy dostępie warunkowym to wymuszenie reguły, która psuje proces, o którym nikt nie zgłosił, oraz zablokowanie administratorów poza konsolą, której potrzebują, żeby to naprawić. Dwie praktyki zapobiegają obu.

Najpierw użyj trybu report-only

Obie główne platformy pozwalają uruchomić politykę w trybie, który ją ocenia i zapisuje, co by się stało, bez faktycznego wymuszania skutku. W Microsoft 365 jest to report-only mode; polityki report-only nie blokują dostępu i nie wymagają wykluczeń, więc można je włączyć od razu bez ryzyka. Google Workspace pozwala stworzyć i monitorować politykę, zanim przełączysz ją na aktywne wymuszanie.

Uruchamiaj każdą nową politykę w ten sposób przez tydzień do dwóch. Obserwuj logi logowań pod kątem tego, co polityka by zablokowała albo zakwestionowała. Niemal zawsze znajdziesz kilka nieoczekiwanych przypadków: współdzieloną skrzynkę korzystającą z przestarzałego uwierzytelniania, konto serwisowe, kontraktora na niezarządzanym urządzeniu. Rozwiąż je, a potem przełącz politykę na wymuszoną.

Utrzymuj konta break-glass

Konto break-glass (dostępu awaryjnego) to silnie chronione konto administratora, celowo wykluczone z polityk dostępu warunkowego, które w przeciwnym razie mogłyby zablokować wszystkich. Jeśli polityka zadziała błędnie, twój dostawca MFA ma awarię albo zmiana konfiguracji pójdzie źle, te konta zostają twoją drogą powrotną.

Wskazówka Microsoftu mówi, żeby utrzymywać co najmniej jedno, a najlepiej dwa konta dostępu awaryjnego, i wykluczać je z polityk dostępu warunkowego, które blokują lub ograniczają logowanie. Praktyczne podejście wygląda tak:

• Używaj kont wyłącznie chmurowych, niezależnych od infrastruktury lokalnej lub federacyjnej.
• Nadaj im długie, unikalne, bezpiecznie przechowywane dane uwierzytelniające, podzielone tak, żeby żadna pojedyncza osoba nie znała całego sekretu.
• Wyklucz je z polityk blokujących i wymagających urządzenia, ale monitoruj je uważnie i alarmuj przy każdym użyciu, bo logowanie z konta break-glass powinno być rzadkim, zauważonym zdarzeniem.
• Testuj je regularnie, żeby wiedzieć, że wciąż działają, zanim będziesz ich potrzebować.

Wdrażaj po kolei, od wąskiego do szerokiego

Zacznij od polityk MFA dla wszystkich i blokady przestarzałego uwierzytelniania, bo razem zamykają największą lukę. Następnie dodaj wymóg urządzenia dla wrażliwych aplikacji, a na końcu dołóż reguły ryzyka i lokalizacji. Każdą nową politykę zastosuj najpierw na grupie pilotażowej, zanim rozszerzysz ją na wszystkich, i trzymaj zestaw reguł na tyle mały, żebyś potrafił wyjaśnić każdą politykę i powód jej istnienia.

Źródła

• Block legacy authentication with Conditional Access, Microsoft Entra ID · https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication (przestarzałe protokoły nie potrafią spełnić MFA; polityka blokująca i wdrożenie w trybie report-only)
• Manage emergency access admin accounts, Microsoft Entra ID · https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access (wskazówki dotyczące kont break-glass i ich wykluczeń)
• Microsoft-managed Conditional Access policies, Microsoft Entra ID · https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies (bazowe polityki MFA i wykluczanie kont awaryjnych)
• Risk policies, Microsoft Entra ID Protection · https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies (polityki oparte na ryzyku logowania i ryzyku użytkownika)
• Protect your business with Context-Aware Access, Google Workspace Admin Help · https://support.google.com/a/answer/9275380 (sygnały: tożsamość, lokalizacja, stan urządzenia, IP)
• Create Context-Aware access levels, Google Workspace Admin Help · https://support.google.com/a/answer/9262032 (podstawowe i zaawansowane poziomy dostępu, warunki urządzenia i IP)
• About Context-Aware Access, Google Workspace · https://knowledge.workspace.google.com/admin/security/about-context-aware-access (polityka urządzenia wymaga weryfikacji endpointów; wpływ na dostęp z mobilnej przeglądarki)
• Deploy Context-Aware Access, Google Workspace Admin Help · https://support.google.com/a/answer/12643733 (wdrożenie, monitorowanie przed wymuszeniem)