Entra ID: ryzyka i kompromisy przed połączeniem

PhishSpot umie połączyć się z Microsoft Entra ID (dawniej Azure AD) i pobierać użytkowników oraz grupy bezpośrednio z Twojego katalogu — opisuje to Rozdział 25 Synchronizacja katalogu. Wspieramy tę integrację, klienci używają jej na produkcji, działa zgodnie z dokumentacją.

Ten rozdział istnieje dlatego, że w przypadku większości organizacji nie uważamy, że powinieneś jej włączać. Nadanie scope’ów odczytu katalogu zewnętrznemu dostawcy SaaS to nie drobiazg, a korzyść w wygodzie jest mniejsza niż się wydaje, gdy policzysz pracę operacyjną, bezpieczeństwa i compliance, którą to faktycznie generuje. Prostsza alternatywa — kwartalny import z CSV — spełnia każdą realistyczną potrzebę programu symulacji phishingowych, przy ułamku ryzyka.

Przeczytaj zanim klikniesz Połącz z Microsoft. Jeśli już połączyłeś, przeczytaj przed kolejnym przeglądem nadanych zgód OAuth.

28.1 Krótko — co polecamy

Rekomendacja domyślna: nie podłączaj Entra ID. Użyj importu z CSV ze swojego systemu HR — patrz Rozdział 5 Kontakty i operacje masowe w §5.6.
Trzy powody w jednym tchu: (1) zgoda OAuth rozszerza Twoją powierzchnię ataku, dając PhishSpot dostęp do odczytu całego katalogu; (2) integracja sprzęga Twój program phishingowy z dostępnością Microsoft i decyzjami polityki Twojego tenanta; (3) platforma do symulacji phishingu, która uczy pracowników podejrzliwości wobec promptów MS, sama nie powinna być promptem MS.
Jeśli mimo to podłączasz: review scope’ów z security team, wpis do rejestru przetwarzania u DPO, time-boxed zgoda OAuth i ponowny audyt co sześć miesięcy. Patrz §28.9.

28.2 Co właściwie przyznajesz łącząc Entra

Połączenie Entra w PhishSpot żąda trzech scope’ów Microsoft Graph podczas zgody administracyjnej:

User.Read.All — odczyt pełnego obiektu użytkownika dla każdego konta w tenancie.
Group.Read.All — odczyt każdej definicji grupy security i Microsoft 365.
Directory.Read.All — odczyt członkostwa w grupach i danych katalogowych organizacji.

PhishSpot używa małego wycinka tego — email, imię/nazwisko, stanowisko, dział, lokalizacja, telefon, flaga accountEnabled i członkostwo w grupach. Reszty nie tyka. Ale scope to odczyt wszystkiego: telefonu komórkowego, łańcucha menedżerów, przypisanych licencji, ustawień skrzynki, metadanych logowań i kilkudziesięciu innych atrybutów, które Entra wystawia per użytkownik. Token OAuth, który PhishSpot zapisuje po zgodzie admina, może pobrać dowolne z tych pól, w dowolnym momencie, dopóki go nie cofniesz.

Import CSV odwraca tę logikę. To Ty wybierasz, które kolumny wyeksportować ze swojego systemu HR (first_name, last_name, email, department, title). Nic poza tym nie trafia do PhishSpot — nie dlatego, że odmówilibyśmy, ale dlatego, że tego nie wysłałeś.

To jest zasada minimalizacji danych z art. 5 ust. 1 lit. c RODO: dane osobowe muszą być „adekwatne, stosowne oraz ograniczone do tego, co niezbędne do celów, w których są przetwarzane”. Nadanie Directory.Read.All w celu „prowadzenie symulacji phishingu” jest na pierwszy rzut oka trudne do obrony.

28.3 Bezpieczeństwo — rozszerzenie powierzchni ataku

Tutaj nakładają się trzy sub-argumenty.

Token OAuth rozszerza Twoją powierzchnię ataku. PhishSpot przechowuje w swojej bazie tenant-scoped token Microsoft Graph. Jeśli PhishSpot zostanie skompromitowany — luka w naszym kodzie, źle skonfigurowany zasób chmurowy, błąd uprzywilejowanego użytkownika po naszej stronie — atakujący odchodzi z dostępem read-only do Twojego katalogu. Zanim się połączyłeś, Twój katalog był chroniony przez Twój własny perimeter bezpieczeństwa. Po — jest chroniony też przez nasz. Podwoiłeś liczbę organizacji, które muszą pozostać bezpieczne, żeby Twój katalog pozostał prywatny.

Ironia symulacji phishingowych. Cały sens PhishSpot to uczenie pracowników podejrzliwości wobec nieoczekiwanych promptów Microsoft: maila „Twoje hasło wygasa dziś”, linku „Kliknij aby zobaczyć udostępniony dokument w OneDrive”, niespodziewanego ekranu logowania. Prosząc użytkowników o SSO przez Microsoft, by mieli dostęp do naszej platformy, trenujemy ich w przeciwnym kierunku — że MS-brandowany prompt logowania, w kontekście phishspot.com, jest normalny i oczekiwany. Zbudowaliśmy konia trojańskiego, przed którym ostrzega nasze własne szkolenie. (Ta ironia dotyczy mocniej Rozdziału 24 Logowanie przez Microsoft 365; ta sama zasada jest istotna tutaj, bo integracja Entra i SSO dzielą tę samą powierzchnię OAuth.)

Ślad audytowy przeżywa integrację. Gdy nadasz zgodę administracyjną PhishSpot, zgoda OAuth zostaje zapisana w logu audytowym Entra na zawsze. Późniejsze odłączenie tego rekordu nie usuwa. Za pięć lat nowy audytor compliance pyta „dlaczego ta organizacja nadała Directory.Read.All zewnętrznemu dostawcy phishingu?” — i Ty, albo Twój następca, musisz to wyjaśnić.

28.4 Sprzężenie operacyjne

Gdy polegasz na pliku CSV, polegasz na pliku CSV. Gdy polegasz na synchronizacji Entra, polegasz na:

Dostępności Microsoft Graph. Awaria Grafu — nawet częściowa — degraduje albo zatrzymuje synchronizację. PhishSpot retryje, ale jeśli awaria trwa kilka dni, lista kontaktów odpływa od rzeczywistości.
Politykach Conditional Access. Polityki CA Twojego tenanta mogą po cichu blokować flow daemon PhishSpot. Następna zaplanowana synchronizacja kończy się niejasnym błędem — ale Ty tego nie widzisz, dopóki nie otworzysz strony integracji, co dla większości adminów oznacza „gdy coś wygląda na zepsute”.
Zmianach schematu Microsoft Graph. Microsoft aktualizuje API Graph swoim rytmem. Zmiana nazwy pola, deprecation, przemapowanie uprawnień — i nasza logika synchronizacji musi się dostosować. Robimy to, ale luka między „Microsoft wypuszcza zmianę” a „PhishSpot wypuszcza poprawkę” może wynosić dni.
Czasie życia tokena i odświeżaniu. Tokeny aplikacji wygasają. Odświeżamy je. Przeważnie. Gdy odświeżenie się nie uda — admin zmienił hasło, conditional access się zacieśnił, aplikacja została oznaczona jako ryzykowna w MDM — synchronizacja gaśnie.

CSV nie ma żadnego z tych trybów awarii. Wgrywasz, dane się ładują, i jedyne co kiedykolwiek się zmienia, to gdy wgrasz nowy plik.

28.5 RODO — minimalizacja danych

W §28.2 wspomnieliśmy już o art. 5 ust. 1 lit. c RODO. Jest więcej.

Podstawa prawna. Art. 6 wymaga, byś miał podstawę prawną przetwarzania danych osobowych. „Prawnie uzasadniony interes” to typowa podstawa dla symulacji phishingu — ale wymaga testu balansującego, a „pobraliśmy cały katalog, bo to było wygodne” nie przechodzi tego testu, gdy „pobraliśmy pięć potrzebnych pól z CSV” było dostępne.
Rejestr czynności przetwarzania (art. 30). Połączenie Entra z PhishSpot to nowa czynność przetwarzania, z nowym przepływem danych, nowym subprocesorem, nowym pytaniem o retencję. Należy do RCP. Importy CSV zwykle mieszczą się w istniejącym wpisie „symulacje phishingu”; Entra dodaje świeży.
Review DPO. W większości organizacji EU/UK nadanie Directory.Read.All dostawcy SaaS uruchamia ocenę skutków dla ochrony danych (DPIA) wg art. 35. To tygodnie procesu, często miesiące. Import CSV, z tymi samymi podmiotami danych, często nie uruchamia DPIA w ogóle — zakres danych jest węższy, a relacja z subprocesorem prostsza.

28.6 Ukryty koszt po stronie admina

Pitch dla synchronizacji Entra to „ustaw raz, zapomnij”. Rzeczywistość to więcej pracy.

Global Administrator musi nadać zgodę. W większości org to jedna albo dwie osoby — a ich kalendarze są pełne.
Review DPO i prawników, wpis RCP, DPIA (czasem).
Wyjątki w Conditional Access, jeśli Twoje domyślne polityki blokują flow app-only.
Kwartalny audyt nadanych zgód OAuth w tenancie (dobra higiena bezpieczeństwa).
Ponowna zgoda, gdy Microsoft przemianowuje scope’y albo wymaga zaktualizowanej rejestracji aplikacji.
Reakcja na incydent, gdy synchronizacja po cichu pada przez tydzień, a następna kampania trafia do byłych pracowników.

Przeciw alternatywie CSV: dowolny admin eksportuje pięciokolumnowy CSV z systemu HR raz na kwartał, wgrywa, gotowe. Bez zaangażowania global admina, bez telefonu do DPO, bez follow-upu audytowego. „Oszczędność czasu” automatyki Entra to w większości iluzja, gdy policzysz pracę, którą sama generuje.

28.7 Ironia programu uświadamiającego, w szczegółach

Ten argument zasługuje na własną sekcję, bo jest jedynym powodem specyficznym dla PhishSpot, który nie dotyczy innych integracji SaaS.

Udany program uświadamiający uczy pracowników kilku odruchów:

Nieoczekiwany MS-brandowany prompt logowania zasługuje na drugie spojrzenie.
Ekran „nadaj tej aplikacji dostęp do swojego konta” to coś, co się czyta przed kliknięciem.
Prompt, który przychodzi mailem i prosi o dane logowania, jest domyślnie wrogi, dopóki się go nie zweryfikuje.

Integracja Entra w PhishSpot i SSO Microsoft 365 zaprzeczają każdemu z tych odruchów w naszym własnym UX:

Wysyłamy użytkownikom prompt logowania Microsoft pod platform.phishspot.com/users/sign_in. Klikają, robią MFA i odruch „ufać promptowi Microsoft w tym kontekście” się wzmacnia.
Prosimy Global Administratora, by przeklikał ekran zgody Microsoft nadający naszej aplikacji Directory.Read.All. Odruch, którego chcemy — „przeczytaj ten ekran, zapytaj o ten scope” — jest w sprzeczności z integracją, którą sami prosimy go ukończyć.

Wynik: populacja pracowników lepiej wytrenowana wobec symulacji, które wysyłamy, ale nieco gorzej wytrenowana wobec prawdziwych ataków, przed którymi ma być chroniona. Trening gorzej się przenosi na „nieznany MS-brandowany prompt poza PhishSpot”, bo zrobiliśmy jeden w środku PhishSpot znanym.

To nie jest wada śmiertelna — większość programów uświadamiających akceptuje pewną niedoskonałość — ale jest powodem, by domyślnie wybierać prostszą ścieżkę integracji, która tej sprzeczności nie produkuje.

28.8 Co polecamy

W niemal każdej organizacji, z którą pracujemy, właściwa ścieżka to:

Import CSV przez Rozdział 5 Kontakty. Wybierz kolumny, których faktycznie potrzebujesz (first_name, last_name, email, department, title, groups). Wyeksportuj z systemu HR albo Active Directory przez PowerShell. Wgraj przez UI PhishSpot.
Kwartalne odświeżenie. Re-eksport i re-import raz na kwartał, albo po większych zmianach w org (duże fale rekrutacji, reorganizacje, M&A). Operacje masowe w §5.6 obsłużą usuwanie.
Członkostwo w grupach w CSV. PhishSpot akceptuje rozdzieloną przecinkami kolumnę groups — ten sam efekt co odzwierciedlanie grup z Entra, bez synchronizacji.
Risk score nadal działa. Risk score jest liczony przez PhishSpot na podstawie wyników kampanii, nie z Entra. Wyłączenie synchronizacji Entra nic nie zmienia w zachowaniu risk score.

Ta ścieżka pokrywa 95% potrzeb programu symulacji phishingowych. Tej ścieżki używają nasi długo-letni klienci nawet wtedy, gdy ich tenanty są całkowicie zdolne wesprzeć synchronizację Entra.

28.9 Jeśli mimo to się łączysz

Wspieramy synchronizację Entra. Klienci ją podłączają. Czasem są realne powody: organizacja 5 000+ pracowników, gdzie kwartalny CSV nie nadąża za zmianami org; środowisko regulowane, gdzie IT wymaga onboardingu opartego o katalog dla wszystkich SaaS; fazowane wdrożenie, gdzie program symulacji to jedno z wielu narzędzi w tym samym pipeline Entra.

Jeśli zdecydujesz się podłączyć Entra ID, zrób to świadomie:

Review scope’ów z security. Niech Twój zespół security potwierdzi, że User.Read.All / Group.Read.All / Directory.Read.All są akceptowalne w Twoim frameworku vendor risk.
Time-box zgody OAuth. Ustaw przypomnienie w kalendarzu na review zgody co sześć miesięcy. Jeśli przestałeś używać synchronizacji, cofnij.
Zarejestruj przetwarzanie. Dodaj wpis do RCP. Jeśli działasz w EU/UK i DPO wymaga DPIA — przeprowadź ją.
Monitoruj zdrowie synchronizacji. Log aktywności w §25.6 to jedyny sygnał degradacji. Skonfiguruj swój zespół operacji, by sprawdzał po każdym zaplanowanym przebiegu — albo postaw webhook na limicie contact.updated.
Trzymaj CSV w pogotowiu. Miej aktualny eksport CSV na dzień, w którym zechcesz się odłączyć — onboarding nowych kontaktów z CSV po odejściu Entra jest łatwiejszy, gdy plik został pod ręką.

Następnie idź do Rozdziału 25 Synchronizacja katalogu po instrukcje techniczne.

28.10 Odnośniki

Rozdział 5 Kontakty — ścieżka importu CSV, którą polecamy zamiast.
Rozdział 25 Synchronizacja katalogu — techniczne instrukcje dla integracji Entra, przeciw której argumentuje ten rozdział.
Rozdział 24 Logowanie przez Microsoft 365 — osobna decyzja od synchronizacji katalogu; argument o ironii symulacji z §28.7 dotyczy też SSO.
Art. 5 RODO — zasada minimalizacji danych w prawie EU.

Te same argumenty dotyczą każdej przyszłej synchronizacji katalogu Google Workspace, którą mogłybyśmy zaoferować. To nie są argumenty przeciwko Microsoft jako dostawcy — to są argumenty przeciwko OAuth-owej synchronizacji katalogu między dwoma niepowiązanymi produktami SaaS w ogóle, i przeciwko specyficznemu niedopasowaniu między treningiem antyphishingowym a ciasną integracją z Microsoft w szczególności.