Zero Trust z Microsoft 365 - praktyczny przewodnik wdrożenia

W naszym przewodniku po architekturze Zero Trust opisaliśmy siedem zasad NIST SP 800-207, model dojrzałości CISA ZTMM v2.0 i pięć filarów: tożsamość, urządzenia, sieci, aplikacje, dane. Pytanie, które CISO zadaje następne: “Jak to zrobić z tym, co już mam?”

Dla większości organizacji odpowiedź brzmi: Microsoft 365. Nie dlatego, że jest jedynym rozwiązaniem - ale dlatego, że ekosystem M365 pokrywa wszystkie pięć filarów ZTA natywnie, bez konieczności zakupu dziesięciu osobnych narzędzi od różnych dostawców. Policy Engine (Entra ID Conditional Access), Policy Administrator (Entra ID + Intune), Policy Enforcement Points (Defender for Endpoint, Global Secure Access, Purview DLP) - wszystkie trzy logiczne komponenty NIST są wbudowane w platformę.

Ten artykuł to praktyczny przewodnik: co skonfigurować, w jakiej kolejności i na jakim poziomie licencji. Nie jest to dokumentacja Microsoft - to mapa decyzyjna dla CISO i architekta bezpieczeństwa planującego wdrożenie.

M365 jako platforma Zero Trust - mapowanie na NIST 800-207

Architektura NIST 800-207 opiera się na trzech komponentach: Policy Engine (PE), Policy Administrator (PA) i Policy Enforcement Point (PEP). W ekosystemie M365 mapują się one następująco:

Komponent NIST	Implementacja M365	Funkcja
Policy Engine	Entra ID Conditional Access + Identity Protection	Ocena ryzyka sesji, trust algorithm, decyzja grant/deny/step-up
Policy Administrator	Entra ID + Intune + Defender for Cloud Apps	Konfiguracja polityk, dystrybucja do PEP, zarządzanie sesjami
PEP - tożsamość	Entra ID MFA + Passwordless	Egzekwowanie uwierzytelniania
PEP - urządzenia	Intune Compliance + Defender for Endpoint	Sprawdzanie postawy urządzenia, izolacja zagrożonych
PEP - sieć	Global Secure Access (Entra Private Access + Internet Access)	ZTNA zastępujące VPN, SWG, filtrowanie ruchu
PEP - aplikacje	Defender for Cloud Apps (CASB)	Kontrola dostępu do SaaS, shadow IT discovery
PEP - dane	Purview Information Protection + DLP	Klasyfikacja, szyfrowanie, blokada eksfiltracji
Telemetria	Defender XDR + Sentinel	Zbieranie sygnałów zasilających trust algorithm

Co dostaniesz na jakim poziomie licencji

Nie każda organizacja potrzebuje M365 E5. Poniższe zestawienie pokazuje, jakie możliwości ZTA uzyskasz na każdym poziomie:

Filar ZTA	Business Standard	Business Premium	M365 E3	M365 E5
Tożsamość	Entra ID Free: MFA (security defaults), brak Conditional Access	Entra ID P1: Conditional Access, MFA, SSO	Jak BP	Entra ID P2: risk-based CA, Identity Protection, PIM, access reviews
Urządzenia	Brak MDM, brak EDR	Intune MDM/MAM, Defender for Endpoint P1	Intune, brak Defender for Endpoint	Intune + Defender for Endpoint P2 (pełne EDR, AIR)
Sieć	Brak	Brak ZTNA natywnie	Brak ZTNA natywnie	Global Secure Access (ZTNA, SSE) - add-on
Aplikacje	Brak	Brak CASB	Brak CASB	Defender for Cloud Apps (CASB)
Dane	Brak sensitivity labels, brak DLP	Podstawowe sensitivity labels, DLP	Sensitivity labels, DLP	Auto-labeling, trainable classifiers, zaawansowane DLP
Detekcja	Exchange Online Protection (basic)	Defender for Office 365 P1	Brak Defender for Office 365	Defender XDR (Endpoint + Office + Identity + Cloud Apps)
SIEM	Brak	Brak	Brak	Microsoft Sentinel (add-on, consumption-based)
ZTA readiness	Brak fundamentów	Solidna baza	Luki w EDR i email	Pełny stack

Rekomendacja SEQRED

Profil organizacji	Rekomendowana licencja	Uzasadnienie
Startup / mikrofirma	Business Standard + Entra ID P1 add-on	Minimum do Conditional Access i MFA. Brak EDR - akceptowalne przy <10 użytkownikach z niskim ryzykiem
MŚP (<300 użytkowników)	Business Premium	Najlepszy stosunek bezpieczeństwa do ceny - Defender for Endpoint P1, Intune, Conditional Access P1
Średnia firma (300-2000)	E3 + E5 Security add-on	E3 dla produktywności, E5 Security dla pełnego stacku bezpieczeństwa na kluczowych kontach
Duża organizacja / regulowana	E5	Pełny stack: Defender XDR, CASB, Identity Protection P2, PIM, auto-labeling
Konta uprzywilejowane (IT, admin)	E5 niezależnie od reszty	Konta o najwyższym ryzyku wymagają pełnej ochrony - mixed licensing

Wdrożenie krok po kroku - mapowanie na filary CISA ZTMM

Filar 1: Tożsamość - fundament

Tożsamość to punkt wyjścia Zero Trust. Bez centralnego zarządzania tożsamością żadna inna kontrola nie ma sensu.

Krok 1.1: Włącz MFA dla wszystkich

Od 2025 roku Microsoft wymaga MFA dla wszystkich kont administracyjnych w Entra ID. Ale to minimum - MFA powinno obejmować każdego użytkownika.

Konfiguracja w Entra ID → Conditional Access → New policy:

• Assignment: All users (z wykluczeniem kont break-glass)
• Cloud apps: All cloud apps
• Conditions: Any location (bez wykluczeń)
• Grant: Require multifactor authentication
• Session: Sign-in frequency = 12 hours

Krok 1.2: Skonfiguruj Conditional Access policies

Zestaw bazowych polityk (starter set):

Polityka	Cel	Konfiguracja
Require MFA for admins	Konta Global Admin, Security Admin, Exchange Admin	Grant: Require MFA + Require compliant device
Block legacy authentication	Wyłączenie POP, IMAP, SMTP Basic Auth	Conditions: Client apps = Other clients → Block
Require compliant device	Dostęp z SharePoint/OneDrive/Teams tylko z zarządzanych urządzeń	Grant: Require device to be marked as compliant
Risk-based sign-in (E5)	Step-up MFA przy podwyższonym ryzyku sesji	Conditions: Sign-in risk = Medium/High → Grant: Require MFA
Risk-based user (E5)	Wymuszenie resetu hasła przy skompromitowanym koncie	Conditions: User risk = High → Grant: Require password change + MFA
Block by country	Blokada logowań z krajów, z których organizacja nie operuje	Conditions: Location = All except named locations → Block

Krok 1.3: Wdróż phishing-resistant MFA

Dla kont uprzywilejowanych i danych wrażliwych - FIDO2 security keys lub passkeys:

• Entra ID → Authentication methods → FIDO2 security key → Enable
• Conditional Access policy: konta w roli Global Admin/Security Admin → Grant: Require authentication strength = Phishing-resistant MFA

Krok 1.4: Privileged Identity Management (E5)

PIM eliminuje stale aktywne konta administracyjne:

• Rola Global Admin → Eligible (nie Active). Administrator aktywuje rolę na 1-8 godzin z uzasadnieniem
• Wymagaj zatwierdzenia przez drugą osobę dla ról Tier 0
• Access reviews co 90 dni - automatyczna dezaktywacja niepotwierdzonych ról

Filar 2: Urządzenia - endpoint jako perimeter

Krok 2.1: Enrollment w Intune

Wszystkie urządzenia z dostępem do danych firmowych muszą być zarządzane:

• Windows Autopilot dla nowych urządzeń (zero-touch deployment)
• Ręczna rejestracja dla istniejących (Settings → Accounts → Access work or school)
• BYOD: Intune App Protection Policies (MAM) bez pełnej rejestracji urządzenia

Krok 2.2: Compliance policies

Polityki zgodności definiują minimum, które urządzenie musi spełnić, aby uzyskać dostęp:

Kontrola	Windows	macOS	iOS/Android
Szyfrowanie dysku	BitLocker wymagany	FileVault wymagany	Szyfrowanie natywne
Firewall	Windows Firewall włączony	macOS Firewall	N/A
Antywirus	Defender aktualny	Defender/XProtect	N/A
Wersja OS	Min. Windows 11 23H2	Min. macOS 14	Min. iOS 17 / Android 14
Jailbreak/root	N/A	N/A	Blokada
PIN/biometria	Windows Hello	Touch/Face ID	Wymagane

Conditional Access policy: Grant → Require device to be marked as compliant. Urządzenie niespełniające wymagań → brak dostępu do M365.

Krok 2.3: Defender for Endpoint

EDR na każdym endpoincie - to fundament widoczności:

• Automated Investigation and Remediation (AIR) - automatyczna analiza i reakcja na alerty
• Attack Surface Reduction (ASR) rules - blokowanie makr Office, credential dumping, lateral movement
• Device isolation - zdalna izolacja skompromitowanego urządzenia jednym klikiem
• Threat and Vulnerability Management (TVM) - priorytetyzacja łatania na podstawie exploitability

Filar 3: Sieć - od VPN do ZTNA

Krok 3.1: Global Secure Access (ZTNA)

Microsoft Entra Private Access to natywne ZTNA zastępujące VPN:

• Brak wystawiania sieci - użytkownik uzyskuje dostęp do konkretnej aplikacji, nie do całej sieci
• Per-app Conditional Access - każda aplikacja wewnętrzna ma swoją politykę dostępu
• Private DNS - rozwiązywanie nazw prywatnych bez VPN
• Connector agent - lekki agent na serwerze w sieci firmowej, ustanawiający tunel wychodzący

Różnica vs VPN: VPN daje dostęp do sieci (Layer 3). ZTNA daje dostęp do aplikacji (Layer 7) - atakujący, który kompromituje konto, nie widzi reszty sieci.

Krok 3.2: Entra Internet Access (SWG)

Secure Web Gateway filtrujący ruch internetowy:

• Web content filtering - blokowanie kategorii (malware, phishing, adult)
• Tenant restrictions v2 - blokowanie logowania do niezatwierdzonych tenantów M365 (zapobiega eksfiltracji na prywatne konta)
• Source IP restoration - logi zachowują oryginalny IP użytkownika (nie IP proxy)

Filar 4: Aplikacje - widoczność i kontrola

Krok 4.1: Defender for Cloud Apps (CASB)

Shadow IT discovery - podłącz logi proxy/firewalla do Defender for Cloud Apps:

• Automatyczne wykrywanie SaaS aplikacji używanych w organizacji (typowo 500-3000 unikalnych aplikacji)
• Risk scoring każdej aplikacji (bezpieczeństwo, compliance, industry benchmarks)
• Sanction/unsanction - zatwierdzenie lub blokada aplikacji
• Session control - Conditional Access App Control dla real-time inspekcji sesji (np. blokada pobierania z SharePoint na niezarządzanym urządzeniu)

Krok 4.2: OAuth app governance

Kontrola aplikacji z uprawnieniami OAuth do M365:

• Przegląd aplikacji z uprawnieniami Mail.Read, Files.ReadWrite.All
• Alert na aplikacje z wysokimi uprawnieniami od niezweryfikowanych wydawców
• Blokada consent dla aplikacji wymagających uprawnień administratora

Filar 5: Dane - klasyfikacja i ochrona

Krok 5.1: Sensitivity labels (Purview)

Bez klasyfikacji DLP nie wie co chronić. Rekomendowana taksonomia:

Etykieta	Ochrona	Auto-labeling trigger
Public	Brak ograniczeń	Brak
Internal	Blokada udostępniania na zewnątrz	Brak (domyślna etykieta)
Confidential	Szyfrowanie + DLP + watermark	PESEL, NIP, numery kart, dane osobowe
Highly Confidential	Szyfrowanie + brak druku + brak forward + tracking	Umowy, M&A, własność intelektualna

Wdrożenie etapowe:

1. Tydzień 1-2: Stwórz etykiety, opublikuj jako opcjonalne (użytkownicy wybierają ręcznie)
2. Tydzień 3-4: Włącz default label = “Internal” (każdy nowy dokument automatycznie oznaczony)
3. Miesiąc 2: Włącz auto-labeling w simulation mode dla “Confidential” (trainable classifiers + sensitive info types)
4. Miesiąc 3: Aktywuj auto-labeling po weryfikacji wyników symulacji

Krok 5.2: DLP policies

DLP egzekwuje polityki na podstawie etykiet:

• Blokada wysyłki plików “Confidential” na zewnętrzne adresy e-mail
• Alert przy uploadzie “Highly Confidential” do niezatwierdzonego SaaS
• Blokada kopiowania danych firmowych z Teams do aplikacji prywatnych (Intune App Protection)
• Policy tip - ostrzeżenie użytkownika zanim zablokowany zostanie dokument (edukacja > blokada)

Monitoring i detekcja - zamykanie pętli

Zero Trust wymaga ciągłego monitoringu - trust algorithm musi być zasilany telemetrią w czasie rzeczywistym.

Defender XDR - korelacja sygnałów

Defender XDR integruje sygnały z pięciu źródeł:

Źródło	Produkt Defender	Sygnały
Tożsamość	Defender for Identity	Lateral movement, Kerberoasting, DCSync
Endpoint	Defender for Endpoint	Malware, suspicious processes, ASR alerts
Email	Defender for Office 365	Phishing, BEC, malicious attachments
Cloud apps	Defender for Cloud Apps	Shadow IT, anomalous behavior, OAuth abuse
Data	Purview DLP	Data exfiltration attempts, policy violations

Automatyczna korelacja: atak phishingowy (email) → credential theft (identity) → lateral movement (endpoint) → data exfiltration (DLP) - Defender XDR łączy te zdarzenia w jeden incident zamiast 4 osobnych alertów.

Microsoft Sentinel (SIEM/SOAR)

Dla organizacji wymagających zaawansowanej analityki i retencji logów:

• Ingestion: logi z Defender XDR + Entra ID + Intune + firewalli + OT NDR
• KQL analytics rules: detekcja impossible travel, token theft, MFA fatigue
• SOAR playbooks: automatyczna izolacja urządzenia, rewokacja tokenów, notyfikacja SOC
• Workbooki: dashboardy zero trust maturity per filar

Najczęstsze błędy wdrożeniowe

Błąd	Konsekwencja	Rozwiązanie
Brak kont break-glass	Lockout administratorów po błędnej polityce CA	2 konta emergency z wyłączonym CA, monitorowane alertem
Conditional Access w “Report-only” na zawsze	Polityki raportują ale nie blokują - fałszywe poczucie bezpieczeństwa	Wyznacz deadline na przejście z Report-only na Enforce (max 30 dni)
MFA tylko dla adminów	90%+ ataków celuje w konta zwykłych użytkowników	MFA dla WSZYSTKICH, bez wyjątków
Brak default sensitivity label	Nowe dokumenty są nieoznaczone, DLP ich nie widzi	Default label = “Internal” na całej organizacji
Intune compliance bez CA enforcement	Urządzenia oceniane ale niezgodne wciąż mają dostęp	Conditional Access: Require compliant device
Brak tenant restrictions	Użytkownicy logują się do prywatnych tenantów M365, eksfiltrując dane	Entra Internet Access: tenant restrictions v2

Checklist wdrożenia Zero Trust w M365

Tydzień 1-2: Fundament

• Konta break-glass (2 szt.) z monitoringiem logowań
• MFA dla wszystkich użytkowników (Conditional Access policy)
• Blokada legacy authentication (POP, IMAP, Basic Auth)
• Blokada logowań z krajów spoza listy dozwolonych

Miesiąc 1: Urządzenia

• Enrollment urządzeń w Intune (Autopilot lub ręczny)
• Compliance policies (szyfrowanie, firewall, wersja OS)
• Conditional Access: Require compliant device
• Defender for Endpoint deployment (Windows, macOS)

Miesiąc 2: Dane i aplikacje

• Sensitivity labels (4 poziomy) z default label “Internal”
• Auto-labeling w simulation mode (2-4 tygodnie)
• DLP policies z policy tips (ostrzeżenia, nie blokady)
• Defender for Cloud Apps - shadow IT discovery

Miesiąc 3: Zaawansowane

• PIM dla kont uprzywilejowanych (E5)
• Risk-based Conditional Access (Sign-in risk + User risk) (E5)
• FIDO2 / passkeys dla kont admin
• Global Secure Access pilot (ZTNA zamiast VPN)
• Auto-labeling enforcement (po weryfikacji symulacji)

Ciągle

• Access reviews co 90 dni
• Przegląd Conditional Access policies co kwartał
• Symulacje phishingowe co 2 miesiące
• Red team / testy penetracyjne co rok
• Przegląd OAuth app permissions co kwartał

Od czego zacząć

Zero Trust w M365 nie wymaga zakupu całego E5 od pierwszego dnia. Business Premium daje Conditional Access, MFA, Intune, Defender for Endpoint P1 i podstawowe sensitivity labels - wystarczająco, żeby przejść z poziomu Traditional na Initial w CISA ZTMM.

Kluczowe to zacząć od tożsamości (MFA + Conditional Access) i urządzeń (Intune compliance) - te dwie zmiany eliminują większość wektorów ataku, które odpowiadają za 80%+ naruszeń (Verizon DBIR 2025: 22% credential theft + 8x wzrost ataków na VPN).

SEQRED pomaga organizacjom we wdrażaniu Zero Trust w ekosystemie Microsoft 365 - od oceny obecnej konfiguracji, przez projektowanie polityk Conditional Access, po testy penetracyjne weryfikujące skuteczność wdrożenia. Jeśli chcesz ocenić swój obecny poziom dojrzałości ZTA - umów bezpłatną rozmowę.

Powiązane artykuły:

• Zero Trust Architecture - od koncepcji do wdrożenia - teoria i filary NIST/CISA
• Bezpieczeństwo pracy zdalnej i hybrydowej - szerszy kontekst zabezpieczeń remote work
• Bezpieczeństwo haseł - dlaczego MFA i passkeys są konieczne

Źródła

• Microsoft - Zero Trust deployment plan with M365
• Microsoft - Zero Trust deployment for technology pillars
• Microsoft - Conditional Access overview
• Microsoft - Zero Trust Workshop and Assessment
• Microsoft - Replace your VPN with Global Secure Access
• Microsoft - Create and configure sensitivity labels
• Microsoft - Intune Zero Trust deployment approach
• NIST SP 800-207 - Zero Trust Architecture
• CISA Zero Trust Maturity Model v2.0