Punkt wyjścia: monolit pocztowy on-premises
Typowy scenariusz: kilkaset do kilku tysięcy skrzynek na Exchange Server 2013/2016/2019 (często w układzie DAG), serwer brzegowy lub urządzenie antyspamowe w DMZ, archiwizacja na taśmach oraz skrzynki współdzielone i public folders. Do tego:
- Urządzenie antyspamowe / smart host z zestawem reguł budowanych latami — reguł, których nikt nie chce stracić.
- Uwierzytelnianie z mieszanką protokołów legacy (IMAP/POP, MAPI over HTTP, uwierzytelnianie podstawowe).
- Rozproszona tożsamość — konta w lokalnym AD, brak spójnej polityki MFA.
- Backup i archiwizacja po stronie lokalnej, bez natywnej retencji zgodności.
Wymagania biznesowe i techniczne
- Migracja 1500 skrzynek do chmury bez utraty danych i przy minimalnym wpływie na pracę użytkowników.
- Spójne adresowanie i wspólna książka adresowa w okresie przejściowym (koegzystencja).
- Brak przerwy w przepływie poczty — także dla aplikacji i urządzeń wysyłających (skanery, ERP/CRM, fakturowanie).
- Przeniesienie reguł antyspamowych i polityk filtrowania na warstwę chmurową (EOP).
- Podniesienie poziomu bezpieczeństwa do standardu oczekiwanego od organizacji objętej NIS2/KSC i ISO 27001.
- Pełne wykorzystanie licencji M365 E3/E5 — bez płacenia za funkcje, które nie są skonfigurowane.
Ryzyka, które trzeba zaadresować z góry
- Legacy authentication — pozostawione stare protokoły to dziura omijająca MFA.
- Centralized mail transport — włączony wymusza przepływ całej poczty przez serwer lokalny i psuje sens przenoszenia do chmury.
- Rozjazd tożsamości — brak synchronizacji AD z Entra ID powoduje duplikaty i błędne adresy.
- Reguły filtrowania „w głowie administratora” — brak dokumentacji starej bramy antyspamowej.
- Skrzynki specjalne — współdzielone, public folders, skrzynki systemowe, urządzenia.
- Publiczne DNS — SPF, DKIM, DMARC oraz rekordy MX wymagają zaplanowanego przełączenia.
Docelowa architektura: pełna hybryda Exchange
Rekomendowany model to pełna hybryda (Full Hybrid) z nowoczesnym uwierzytelnianiem (OAuth 2.0 / modern hybrid). Hybryda pozwala:
- przenosić skrzynki partiami, bez „big bang”,
- zachować wspólną GAL i free/busy między chmurą a serwerem lokalnym,
- kierować pocztę w jednolity sposób przez EOP,
- w razie potrzeby przenosić skrzynki z powrotem (rollback).
ŹRÓDŁO (on-premises) CEL (Microsoft 365)
Exchange Server 2019 HCW / MRS Exchange Online (1500 skrzynek)
(DAG · 2-3 węzły) ─────────────▶ EOP + Defender for Office 365
AD DS + Entra Connect Mailbox Move Entra ID (MFA / Conditional Access)
certyfikat hybrydowy Endpoint
│ │
MX / SPF / DKIM / DMARC ──▶ przepływ poczty przez EOP ──▶ skrzynki
Kluczowe komponenty
- Exchange Server 2019 jako serwer hybrydowy (po migracji nie musi hostować skrzynek).
- Hybrid Configuration Wizard (HCW) — konfiguracja łączników, domen i uwierzytelniania.
- Entra Connect Sync — synchronizacja tożsamości z filtrowaniem, PHS lub federacją.
- IdFix i narzędzia walidacji — czyszczenie AD przed synchronizacją (duplikaty
proxyAddresses, błędne UPN). - Exchange Online Protection (EOP) jako warstwa filtrowania; opcjonalnie Defender for Office 365 P1/P2 (P2 w E5).
- Entra ID z MFA i Conditional Access — fundament hardeningu.
Przygotowanie katalogu i tożsamości
Przed synchronizacją wykonujemy audyt i czyszczenie AD: UPN równe adresom e-mail, brak duplikatów, uzupełnione mail i proxyAddresses, poprawne atrybuty dla skrzynek współdzielonych i zasobowych. Dopiero potem uruchamiamy synchronizację i weryfikujemy SoftMatch / HardMatch istniejących kont.
Fazy migracji skrzynek
| Faza | Zakres | Charakterystyka |
|---|---|---|
| 1 | Pilot (20–40 skrzynek) | IT + wybrani użytkownicy, walidacja procesu |
| 2 | Partie produkcyjne | 100–200 skrzynek na batch, okna poza szczytem |
| 3 | Skrzynki specjalne | współdzielone, zasobowe, systemowe |
| 4 | Public folders | migracja do public folders w Exchange Online lub do grup M365 |
| 5 | Domknięcie | wyłączenie roli pocztowej on-prem (pozostawienie hybrydy wg potrzeb) |
Migracja odbywa się przez MRS (Mailbox Replication Service) z użyciem endpointu migracji hybrydowej i proxy MRS na serwerze lokalnym. Batche planujemy tak, aby czas partii nie przekraczał okna, a po każdym batchu wykonujemy szybką walidację (liczba skrzynek, przepływ poczty, free/busy).
Zmiana przepływu poczty (cutover MX na EOP)
Docelowo cała poczta przychodząca trafia najpierw do EOP, a nie do bramy lokalnej:
- Przygotowanie łączników (inbound z EOP do on-prem dla skrzynek jeszcze lokalnych; outbound z on-prem do EOP).
- Weryfikacja SPF (
include:spf.protection.outlook.com), konfiguracja DKIM i stopniowe wdrożenie DMARC (p=none→quarantine→reject). - Przełączenie MX na
*.mail.protection.outlook.com. - Wyłączenie Centralized Mail Transport, aby poczta chmurowa nie wracała przez serwer lokalny.
- Łączniki dla aplikacji i urządzeń (skanery, ERP) — z uwzględnieniem ograniczeń SMTP AUTH (preferowany relay przez connector lub alternatywa dla aplikacji).
Migracja reguł antyspamowych do EOP
To najczęściej pomijany element projektu. Stare reguły bramy lokalnej trzeba zinwentaryzować i przełożyć na mechanizmy EOP:
| Stara funkcja (brama on-prem) | Odpowiednik w EOP / Microsoft 365 |
|---|---|
| Filtrowanie IP nadawcy (RBL, blocklist) | Connection filtering — listy dozwolonych/zablokowanych IP |
| Reguły odrzucania po nagłówkach / treści | Mail flow rules (transport rules) |
| Blacklist / whitelist nadawców i domen | Tenant Allow/Block List (TABL) |
| Filtrowanie spamu i phishingu | Anti-spam / anti-phishing policies, Spoof intelligence |
| Kwarantanna | Quarantine policies + powiadomienia i samoobsługa użytkownika |
| Filtrowanie załączników | Anti-malware, Safe Attachments (MDO) |
| Blokowanie linków | Safe Links (MDO) |
| Reguły podszywania się (BEC) | Anti-phishing + Impersonation protection |
| Stopki, disclaimery | Mail flow rules (disclaimers) |
Zasada praktyczna: najpierw przenosimy reguły dozwalające (allow), zbieramy tygodniowy raport z EOP i dopiero potem zaostrzamy blokady — podejście audit → tune → enforce. Dzięki temu nie tworzymy fałszywych blokad, które „uciszają” legalną pocztę biznesową.
Hardening zgodnie z Microsoft i CIS
Hardening realizujemy równolegle z migracją — każda faza to okazja do podniesienia poziomu bezpieczeństwa.
Tożsamość i dostęp
- wyłączenie legacy authentication (Basic Auth) na poziomie tenanta i skrzynek,
- MFA dla wszystkich + Conditional Access (urządzenie, lokalizacja, ryzyko),
- blokada dostępu dla niezgodnych urządzeń i reguły dla sesji podwyższonego ryzyka,
- dedykowane konta administracyjne (cloud-only, bez skrzynki), least privilege i PIM (E5),
- Passwordless / phishing-resistant MFA tam, gdzie to możliwe.
Poczta i filtrowanie
- DKIM, SPF i DMARC dla wszystkich domen,
- polityki EOP i Defender for Office 365 (Safe Links, Safe Attachments, anti-phishing),
- External sender tagging, ochrona przed spoofingiem i BEC,
- ograniczenie automatycznego przekazywania poczty na zewnątrz i kontrola relay.
Monitoring i logi
- Unified Audit Log i spójna retencja,
- Secure Score jako miernik postępu, alert policies,
- podłączenie logów do SIEM (np. Microsoft Sentinel lub zewnętrzny SIEM).
CIS Microsoft 365 Foundations Benchmark służy jako lista kontrolna ustawień tenanta (MFA, kontrola aplikacji chmurowych, zasady haseł, udostępnianie zewnętrzne, Teams/SharePoint).
Koegzystencja, komunikacja i szkolenie
W okresie przejściowym obowiązuje wspólny katalog adresów i spójna sygnatura. Użytkownicy dostają instrukcję dotyczącą profilu Outlook, urządzeń mobilnych i logowania MFA. Kluczowe jest okno serwisowe i punkt kontaktu dla każdej partii migracyjnej.
Wdrożenie krok po kroku
- Discovery — inwentaryzacja skrzynek, protokołów, aplikacji wysyłających, reguł antyspamowych, domen, public folders.
- Plan — harmonogram batchy, RACI, okna serwisowe, kryteria akceptacji, plan rollback.
- Przygotowanie tożsamości — czyszczenie AD, Entra Connect, walidacja atrybutów.
- Budowa hybrydy — HCW, certyfikat hybrydowy, endpoint migracji, free/busy, OAuth.
- Hardening bazowy — legacy auth off, MFA/CA, DKIM/DMARC, EOP/Defender.
- Migracja reguł — mapowanie i przeniesienie polityk antyspamowych, tryb audytu.
- Migracja skrzynek partiami — pilot → produkcja → skrzynki specjalne → public folders.
- Cutover poczty — MX na EOP, wyłączenie centralized transport, łączniki aplikacji.
- Walidacja — testy przepływu, DNS, free/busy, dostęp użytkowników, raporty filtrowania.
- Domknięcie — dekomisja roli pocztowej on-prem, dokumentacja, przekazanie do utrzymania.
Kontrolowane przejście do chmury
| Wskaźnik | Wartość docelowa |
|---|---|
| Skrzynki zmigrowane | 1500 / 1500 |
| Przestój dla użytkownika | < 15 min na skrzynkę (okno przełączenia) |
| Przerwa w przepływie poczty | 0 (planowany cutover poza godzinami pracy) |
| Reguły antyspamowe przeniesione do EOP | 100% zinwentaryzowanych |
| MFA dla skrzynek | 100% |
| Legacy authentication | 0 aktywnych klientów |
| SPF / DKIM / DMARC | wdrożone dla wszystkich domen |
| Czas migracji (całość) | 6–10 tygodni (zależnie od okien i public folders) |
Dzięki hybrydzie przejście jest stopniowe i kontrolowane — bez „wielkiego wybuchu”, z realnym planem powrotu i z mierzalnym podniesieniem bezpieczeństwa poczty.
Najczęstsze pytania
Czym różni się licencja E3 od E5 w tym projekcie?
E3 pokrywa pocztę, Teams, SharePoint i podstawowe EOP. E5 dokłada m.in. Defender for Office 365 P2 (ochrona przed phishingiem i automatyzacja), Entra ID P2 (PIM, Identity Protection) oraz zaawansowane funkcje zgodności i eDiscovery. W projektach pocztowych E5 realnie skraca czas reakcji na incydenty i upraszcza hardening.
Czy hybryda to konieczność przy migracji do Exchange Online?
Nie zawsze — przy małej skali da się wykonać migrację cutover. Ale przy 1500 skrzynkach i wymaganiu minimalnego przestoju hybryda jest najbezpieczniejsza: daje koegzystencję, wspólną GAL i łatwy rollback.
Czy mogę wyłączyć serwer lokalny po migracji?
Serwer w roli pocztowej można wyłączyć, jednak w modelu pełnej hybrydy zwykle pozostawia się serwer (lub narzędzia zarządzania Exchange), aby zachować spójne zarządzanie obiektami synchronizowanymi z lokalnego AD. Decyzja wymaga analizy.
Jak nie zgubić reguł starej bramy antyspamowej?
Najpierw inwentaryzacja i eksport reguł, potem mapowanie na EOP (connection filtering, transport rules, TABL, anti-phishing), następnie uruchomienie w trybie monitorowania i iteracyjne zaostrzanie.
Czy migracja spełnia wymagania NIS2/KSC?
Sama migracja nie „spełnia” ustawy — ale jej elementy (MFA, zarządzanie tożsamością, filtrowanie, monitoring, logi) budują część wymagań SZBI. Wymaga to formalnego wdrożenia polityk i procedur, nie tylko konfiguracji technicznej.
Checklist wdrożeniowy
- Inwentaryzacja skrzynek, protokołów, aplikacji wysyłających i reguł filtrowania
- Czyszczenie AD + przygotowanie UPN / proxyAddresses
- Entra Connect + walidacja synchronizacji
- Konfiguracja hybrydy (HCW, certyfikat, endpoint migracji, OAuth)
- Wyłączenie legacy authentication
- MFA + Conditional Access
- SPF / DKIM / DMARC na wszystkich domenach
- Mapowanie reguł antyspamowych → EOP + tryb audytu
- Migracja partiami + walidacja po każdym batchu
- Cutover MX na EOP + wyłączenie centralized transport
- Łączniki dla aplikacji i urządzeń (SMTP)
- Audit Log + alerty + integracja z SIEM
- Secure Score i przegląd CIS Microsoft 365 Benchmark
- Dekomisja roli pocztowej on-prem + dokumentacja
Słowa kluczowe
Źródła
- Microsoft Learn — Wdrożenie hybrydowe Exchange
- Microsoft Learn — Opis usługi Exchange Online Protection
- Microsoft Learn — Reguły przepływu poczty (transport rules)
- Microsoft Learn — Wyłączanie uwierzytelniania podstawowego w Exchange Online
- CIS — CIS Microsoft 365 Foundations Benchmark
- Microsoft — Microsoft Secure Score