W artykule o Device Code Phishingu pokazaliśmy, jak atakujący nadużywa przepływu OAuth2 Device Code Flow, by przejąć token i działać w imieniu ofiary — bez znajomości hasła i z obejściem MFA. Ten poradnik to druga połowa tematu: co konkretnie zrobić, żeby zamknąć tę powierzchnię ataku w Microsoft Entra ID przy pomocy Conditional Access.
Punkt wyjścia: dwie strategie
Microsoft pozwala — poprzez opcje i polityki Conditional Access — wyłączyć lub ograniczyć użycie Device Code Flow albo zawęzić je do kontrolowanych scenariuszy. Masz zasadniczo dwie drogi:
- Opcja A — całkowite wyłączenie. Jeśli organizacja nie używa Device Code Flow, zablokuj go w całości. To najprostsze i najskuteczniejsze rozwiązanie: znika cała powierzchnia ataku.
- Opcja B — ograniczenie zasięgu. Jeśli część scenariuszy faktycznie wymaga przepływu (np. wybrane narzędzia CLI lub urządzenia IoT), zablokuj go dla wszystkich, ale wyklucz wąską grupę kont lub aplikacji, które go potrzebują — ewentualnie powiąż dozwolony przepływ z urządzeniami zarządzanymi/zgodnymi.
W obu przypadkach mechanizmem egzekwowania jest polityka Conditional Access z warunkiem Authentication flows (Przepływy uwierzytelniania) i kontrolą Block access.
Wymóg licencyjny: polityki Conditional Access wymagają licencji Entra ID P1 dla obejmowanych użytkowników. Bez niej warunek Authentication flows nie będzie dostępny do egzekwowania.
Zanim klikniesz: przygotowanie
- Zinwentaryzuj realne użycie. Przejrzyj dzienniki logowania Entra ID i odfiltruj zdarzenia po typie przepływu uwierzytelniania (device code). Sprawdź, które aplikacje i konta faktycznie korzystają z przepływu — to podstawa decyzji między opcją A a B.
- Zabezpiecz konta awaryjne (break-glass). Microsoft rekomenduje, by z polityk Conditional Access zawsze wykluczać co najmniej dwa konta awaryjne, na wypadek błędnej konfiguracji odcinającej dostęp.
- Zaplanuj walidację w trybie Report-only. Nie włączaj polityki od razu w trybie egzekwowania — najpierw obserwuj jej wpływ.
Opcja A — całkowite wyłączenie Device Code Flow (krok po kroku)
- Zaloguj się do Microsoft Entra admin center z uprawnieniami co najmniej Conditional Access Administrator.
- Przejdź do Protection → Conditional Access → Policies i wybierz New policy.
- Nadaj politykę czytelną nazwę, np.
Block Device Code Flow. - Users → wybierz All users, a w zakładce Exclude dodaj konta awaryjne (break-glass) oraz ewentualne grupy, które przepływu potrzebują (patrz opcja B).
- Target resources → ustaw na All resources (dawniej „All cloud apps”), aby objąć politykę pełnym zakresem.
- Conditions → Authentication flows → przełącz na Configured: Yes i zaznacz Device code flow.
- Access controls → Grant → wybierz Block access i zatwierdź.
- Enable policy → ustaw najpierw Report-only.
- Kliknij Create.
Politykę utrzymaj w trybie Report-only przez czas wystarczający, by zebrać reprezentatywne logowania (np. cykl tygodniowy), a następnie — po walidacji — przełącz Enable policy na On.
Opcja B — ograniczenie zasięgu
Jeśli inwentaryzacja wykazała legalne użycie Device Code Flow, nie rezygnuj z blokady — zawęź ją:
- Utwórz tę samą politykę blokującą co w opcji A, ale w sekcji Users → Exclude dodaj wąską, nazwaną grupę kont lub aplikacji, które faktycznie potrzebują przepływu (np. dedykowane konto serwisowe dla narzędzia CLI lub urządzenia IoT).
- Dzięki temu Device Code Flow pozostaje dostępny wyłącznie dla tej grupy, a dla całej reszty organizacji jest zablokowany.
- Dla wykluczonej grupy rozważ dodatkową, oddzielną politykę wzmacniającą kontekst zaufania — np. wymóg urządzenia zgodnego (compliant) lub dołączonego do Entra (hybrid/Entra joined) — aby legalne użycie odbywało się wyłącznie z urządzeń zarządzanych.
Zasada jest prosta: domyślnie blokuj, a dostęp przyznawaj punktowo i świadomie. To zgodne z podejściem Zero Trust i zarządzaniem tożsamością (IAM).
Pułapki, których warto uniknąć
- Brak wykluczenia kont break-glass. Najczęstszy błąd przy każdej polityce Conditional Access. Zawsze wyklucz konta awaryjne, zanim przełączysz politykę na egzekwowanie.
- Włączenie od razu w trybie On. Pominięcie Report-only grozi nieprzewidzianym odcięciem legalnych scenariuszy. Najpierw obserwuj, potem egzekwuj.
- Zbyt szerokie wykluczenia. W opcji B wyklucz najwęższą możliwą grupę. Każde konto z wyjątkiem to potencjalnie otwarta furtka dla Device Code Phishingu.
- Pomylenie blokady przepływu z blokadą aplikacji. Warunek Authentication flows celuje w sam przepływ device code, nie w aplikację jako taką — aplikacje korzystające z innych przepływów (np. przeglądarkowych) działają dalej.
- Założenie, że MFA wystarczy. MFA nie chroni przed Device Code Phishingiem, bo to ofiara wykonuje MFA. Blokada przepływu działa na innej warstwie i jest tu właściwym środkiem.
Walidacja po wdrożeniu
- Raporty Report-only. W szczegółach polityki i w raportach Conditional Access sprawdź, ile logowań zostałoby zablokowanych i czy nie obejmują one scenariuszy biznesowych, których nie chcesz odcinać.
- Dzienniki logowania Entra ID. Po przełączeniu na On filtruj zdarzenia po typie przepływu uwierzytelniania (device code) i potwierdź, że objęte konta są blokowane, a wykluczenia działają.
- Test kontrolowany. Spróbuj zainicjować logowanie device code (np. dla narzędzia CLI) na koncie objętym polityką i potwierdź, że dostęp jest zablokowany; powtórz dla konta wykluczonego i potwierdź, że działa zgodnie z założeniem.
Checklist
- Zinwentaryzowano realne użycie Device Code Flow (dzienniki logowania).
- Wybrano strategię: A (pełna blokada) lub B (blokada z wąskim wykluczeniem).
- Polityka Conditional Access: warunek Authentication flows → Device code flow → Block access.
- Wykluczono konta awaryjne (break-glass) i — w opcji B — wąską grupę legalnych kont/aplikacji.
- Uruchomiono w trybie Report-only i zwalidowano wpływ.
- Przełączono na On i potwierdzono działanie testem kontrolowanym.
- Udokumentowano wyjątki i ustalono cykl ich przeglądu.
Powyższa konfiguracja to przykład edukacyjny. Nazwy i układ ekranów w Microsoft Entra admin center mogą się zmieniać, a wpływ polityki zależy od specyfiki Twojego tenanta. Przed wdrożeniem produkcyjnym przetestuj zmiany w trybie Report-only. Jeśli potrzebujesz wsparcia w projektowaniu i wdrożeniu polityk Conditional Access oraz strategii tożsamościowej, zespół nFlo pomoże przeprowadzić to bezpiecznie.
Źródła i materiały referencyjne
- Microsoft Learn — Conditional Access: authentication flows
- Microsoft Learn — Block authentication flows with Conditional Access policy
- Microsoft Learn — OAuth 2.0 device authorization grant flow
