Prosta, twierdząca odpowiedź na pytanie „czy dane są szyfrowane?” nie powinna zadowalać CISO i dyrektorów IT. W odpowiedzi na to pytanie ważniejsze ustalenie: kto zarządza kluczami, kto ma do nich dostęp i czy organizacja potrafi to pokazać podczas audytu.
W tym artykule opisujemy trzy modele: PMK, CMK i Microsoft Purview Customer Key. Bez straszenia i bez forsowania „najmocniejszej” opcji szyfrowania wszędzie. Chodzi o dobranie poziomu zabezpieczeń do ryzyka, regulacji i sposobu pracy organizacji.
Warto też pamiętać, że zarządzanie kluczami w Microsoft 365 i Azure to tylko jeden z elementów szerszej polityki ochrony danych. W praktyce organizacje zabezpieczają również stacje końcowe, bazy danych, aplikacje, pocztę elektroniczną, dane archiwalne, dane w transmisji. Stosują też procesy anonimizacji i pseudonimizacji, które mogą zmienić wymagania dla szyfrowania. Tutaj skupiamy się na warstwie Microsoft 365 i Azure, szczególnie na modelach PMK, CMK i Customer Key.
Szyfrowanie danych w Microsoft 365 i Azure: co działa domyślnie
Microsoft Purview Information Protection wykorzystuje AES256-CBC jako domyślny mechanizm szyfrowania dla chronionych dokumentów i wiadomości w aplikacjach Microsoft 365. Microsoft zapowiadał zmianę na AES256-CBC jako domyślny tryb szyfrowania dla aplikacji korzystających z Microsoft Purview Information Protection, a dokumentacja techniczna Microsoft wskazuje, że do października 2023 roku AES256-CBC stał się domyślny dla szyfrowania dokumentów i wiadomości w Microsoft 365 Apps.
W Azure usługi mogą korzystać z różnych modeli zarządzania kluczami: od kluczy zarządzanych przez platformę, przez klucze zarządzane przez klienta w Azure Key Vault lub Azure Managed HSM, po scenariusze z większą kontrolą po stronie organizacji. Microsoft opisuje CMK jako model, w którym klient posiada i zarządza key encryption key w Azure Key Vault lub Azure Managed HSM.
Czyli: domyślnie szyfrowanie twoich danych jest włączone. Prawdziwe pytanie brzmi, czy w Twojej organizacji wystarczy model w którym to Microsoft zarządza kluczami, czy też potrzebujesz przejąć większą kontrolę nad kluczami.
PMK, CMK i Customer Key - czym się różnią?
W szyfrowaniu chmurowym łatwo ugrzęznąć w skrótach. Najprościej myśleć o nich jako o trzech poziomach kontroli.
PMK – Platform Managed Keys
Dla zespołu IT to najprostszy wariant, bo nie wymaga osobnej architektury Azure Key Vault, procedur rotacji ani dodatkowej obsługi operacyjnej. Użytkownicy pracują normalnie, a szyfrowanie działa w tle.
Dla wielu firm PMK w zupełności wystarcza. Szczególnie wtedy, gdy organizacja nie ma specyficznych wymagań regulacyjnych dotyczących zarządzania kluczami.
Ograniczenie jest jasne: dane są szyfrowane, ale to nie Ty zarządzasz kluczami głównymi. Jeśli audyt, regulator albo wewnętrzna polityka bezpieczeństwa wymagają kontroli po stronie klienta, trzeba rozważyć CMK albo Customer Key.
CMK - Customer-Managed Keys w Azure
Microsoft opisuje CMK jako model, w którym klient posiada i zarządza key encryption key w swoim Azure Key Vault lub Managed HSM, a usługi Azure używają tego klucza do ochrony kluczy szyfrujących dane przez envelope encryption. Dla kluczy chronionych sprzętowo Microsoft wskazuje Azure Key Vault Premium albo Azure Managed HSM.
CMK daje większą kontrolę nad:
- dostępem do klucza,
- audytem operacji,
- rotacją,
- separacją obowiązków,
- wymaganiami compliance,
- procedurami wycofania usług lub danych.
Podsumowując: CMK zwiększa kontrolę, ale zwiększa też odpowiedzialność.
Microsoft Purview Customer Key
Microsoft opisuje Customer Key jako rozwiązanie, które uzupełnia BitLocker oraz server-side encryption w centrach danych Microsoft i pomaga spełniać wymagania compliance przez kontrolę nad root encryption keys na poziomie aplikacyjnym.
To rozwiązanie ma sens głównie tam, gdzie organizacja musi wykazać dodatkową kontrolę nad danymi w spoczynku – na przykład w sektorach regulowanych, przy danych szczególnie wrażliwych albo w ramach polityki suwerenności danych.
Ważne: Customer Key nie oznacza, że „całe bezpieczeństwo danych” zostaje rozwiązane jednym mechanizmem. To dodatkowa warstwa kontroli kryptograficznej. Nadal potrzebujesz dobrego modelu dostępu, klasyfikacji danych, DLP, retencji i audytu.
Kiedy wystarczy domyślne szyfrowanie Microsoft?
W wielu organizacjach większy efekt da najpierw uporządkowanie podstaw:
- MFA i Conditional Access,
- role administracyjne,
- klasyfikacja danych,
- etykiety wrażliwości,
- DLP,
- retencja,
- kontrola udostępnień,
- monitoring i audyt.
CMK i Customer Key mogą uzupełnić politykę ochrony danych, ale nie zastąpią klasyfikacji informacji, DLP, kontroli dostępu, retencji, ochrony stacji końcowych ani dobrze zaprojektowanego procesu anonimizacji lub pseudonimizacji.
Kiedy warto rozważyć CMK lub Customer Key?
CMK i Customer Key mają sens wtedy, gdy potrzeba większej kontroli wynika z konkretnego wymagania. Hasło: „własny klucz brzmi bezpieczniej” to nie jest dobry powód do wdrożenia CMK.
1. Wymagania regulacyjne
W takim przypadku pytanie nie brzmi: „czy Microsoft szyfruje dane?”, tylko: „czy organizacja potrafi udowodnić, jak kontroluje klucze i dostęp do danych?”.
2. Suwerenność danych
Nie zawsze jest to wymóg ustawowy. Czasem to element wewnętrznego modelu ryzyka.
3. Exit strategy i crypto-shredding
To mocny mechanizm, ale wymaga procedur prawnych, operacyjnych i bezpieczeństwa. Nie powinien być wdrażany „przy okazji”. Microsoft opisuje zarządzanie Customer Key, w tym tworzenie i przypisywanie Data Encryption Policy oraz zarządzanie kluczami, jako proces wymagający przygotowania, uprawnień i odpowiednich modułów administracyjnych.
4. Separacja obowiązków
Dobrze zaprojektowany model ogranicza sytuację, w której jedna osoba albo jeden zespół ma zbyt szeroką kontrolę nad całym środowiskiem.
Czego Customer Key nie rozwiązuje
To ważne, bo waga zabezpieczenia przez wdrożenie własnych kluczy bywa przeceniana.
- Customer Key nie naprawi złych uprawnień w SharePoint.
- Nie zatrzyma użytkownika, który legalnie ma dostęp do dokumentu i udostępnia go dalej.
- Nie zastąpi DLP, etykiet wrażliwości, retencji, audytu ani kontroli dostępu.
- Nie rozwiąże problemu nadmiarowych administratorów.
- Nie uporządkuje chaosu w Teams, grupach i witrynach.
- Nie zastąpi ochrony stacji końcowych, szyfrowania dysków ani polityk zabezpieczających urządzenia użytkowników.
- Nie rozwiąże problemu danych osobowych używanych w raportach, środowiskach testowych albo integracjach – tam często trzeba rozważyć także pseudonimizację lub anonimizację.
To dodatkowa warstwa kontroli kryptograficznej. Bardzo przydatna w wybranych organizacjach, ale nie jest uniwersalnym lekarstwem na bezpieczeństwo danych.
Szyfrowanie, anonimizacja i pseudonimizacja - gdzie jest granica?
Szyfrowanie chroni dane przez ich zakodowanie. Dane pozostają dostępne dla osób i systemów, które mają odpowiednie uprawnienia oraz klucze. To podstawowy mechanizm ochrony poufności.
Pseudonimizacja ogranicza możliwość przypisania danych do konkretnej osoby bez dodatkowych informacji. Te dodatkowe informacje powinny być przechowywane osobno i odpowiednio zabezpieczone.
Anonimizacja idzie dalej: po prawidłowej anonimizacji danych nie powinno dać się powiązać z konkretną osobą. W praktyce jest to trudniejsze niż samo usunięcie imienia, nazwiska czy numeru identyfikacyjnego.
Dlatego w projektach ochrony danych nie warto wybierać mechanizmu na podstawie nazwy technologii. Najpierw trzeba ustalić, co naprawdę chronimy: dostęp do danych, tożsamość osoby, transmisję, bazę danych, aplikację, endpoint, kopię archiwalną czy środowisko testowe.
Jak wygląda wdrożenie Customer Key?
Microsoft wskazuje, że Customer Key wymaga dwóch kluczy dla każdej Data Encryption Policy. W dokumentacji konfiguracji Customer Key Microsoft wymaga dwóch subskrypcji Azure i rekomenduje utworzenie nowych subskrypcji używanych specjalnie do obsługi Customer Key.
W praktyce projekt obejmuje:
- wybór danych i obciążeń objętych Customer Key,
- projekt Azure Key Vault lub Azure Managed HSM,
- model ról i odpowiedzialności,
- konfigurację Data Encryption Policy,
- testy,
- procedury rotacji i awaryjne,
- monitoring,
- dokumentację dla audytu.
Największe ryzyka CMK i Customer Key
1. Zła obsługa kluczy
Własne klucze dają większą kontrolę, ale też większą odpowiedzialność. Błąd w dostępie, rotacji, usunięciu albo procedurze awaryjnej może zablokować dostęp do danych.
Microsoft opisuje również mechanizm availability key, który wspiera odzyskiwanie w określonych scenariuszach, ale nie zastępuje odpowiedzialności organizacji za właściwe zarządzanie Customer Key.
2. Zbyt szeroki zakres wdrożenia
Lepsze podejście: zacząć od danych i obciążeń, które faktycznie mają wyższy poziom ryzyka albo konkretne wymagania compliance.
3. Brak procedur operacyjnych
Własny klucz nie jest tylko funkcją techniczną. To proces operacyjny.
4. Licencje i zależności
Customer Key nie jest funkcją, którą można włączyć w każdym planie i dla każdego użytkownika bez weryfikacji. Przed wdrożeniem trzeba sprawdzić wymagania licencyjne, obsługiwane workloady i zakres użytkowników objętych polityką. Microsoft wskazuje, że po konfiguracji Customer Key tworzy się i przypisuje Data Encryption Policies do kontroli szyfrowania danych w spoczynku w Microsoft 365.
Jak zacząć bez przeciągania projektu?
Najlepszy start to krótka ocena wymagań i danych. Zanim wybierzesz PMK, CMK albo Customer Key, odpowiedz na kilka pytań:
- Jakie dane mają najwyższy poziom klasyfikacji?
- Gdzie są przechowywane: Exchange, SharePoint, OneDrive, Teams, Azure SQL, Storage czy inne usługi?
- Czy wymagania dotyczą całego tenanta, czy wybranych obszarów?
- Czy w projekcie trzeba uwzględnić także bazy danych, aplikacje, pocztę, stacje końcowe albo dane archiwalne?
- Czy potrzebna jest integracja z PKI lub HSM?
- Czy projekt dotyczy także anonimizacji lub pseudonimizacji danych?
- Kto będzie właścicielem Azure Key Vault lub Azure Managed HSM?
- Jak wygląda rotacja kluczy?
- Jak wygląda procedura awaryjna?
- Jakie dowody trzeba pokazać audytorowi?
- Jakie licencje są dostępne?
- Które ryzyka są realne, a które tylko teoretyczne?
Dopiero po tej analizie warto zdecydować, czy wystarczy domyślne szyfrowanie Microsoft, czy potrzebujesz modelu z kluczami zarządzanymi przez klienta – a może szerszej polityki Data Encryption obejmującej również endpointy, bazy danych, aplikacje i pocztę.
Nie masz pewności, czy domyślne szyfrowanie Microsoft 365 wystarcza dla Twojej organizacji?
Sprawdzimy, gdzie przechowujesz dane wrażliwe, jakie wymagania regulacyjne musisz spełnić i czy Customer Key lub CMK rzeczywiście mają sens w Twoim środowisku.
Jak ISCG pomaga w projektach szyfrowania i zarządzania kluczami?
Pomagamy dobrać właściwy model ochrony danych – od domyślnego szyfrowania platformy, przez CMK i Customer Key, po szyfrowanie baz danych, aplikacji, poczty, stacji końcowych oraz integrację z PKI i HSM.
W praktyce wspieramy organizacje w takich obszarach jak:
- analiza środowiska Microsoft 365 i Azure,
- identyfikacja danych oraz obciążeń wymagających mocniejszej kontroli,
- dobór modelu zarządzania kluczami,
- projekt Azure Key Vault lub Azure Managed HSM,
- integracja z PKI i HSM,
- szyfrowanie baz danych, aplikacji, poczty i stacji końcowych,
- wsparcie w obszarze anonimizacji i pseudonimizacji danych,
- projekt ról i odpowiedzialności,
- konfiguracja polityk i testów,
- przygotowanie procedur rotacji i awaryjnych,
- dokumentacja dla audytu,
- wsparcie operacyjne po wdrożeniu.
FAQ - szyfrowanie danych w Microsoft 365 i Azure
Tak. Microsoft 365 stosuje szyfrowanie danych w wielu warstwach, m.in. na poziomie usług i centrów danych. Microsoft Purview Information Protection wykorzystuje AES256-CBC jako domyślny mechanizm szyfrowania dla chronionych dokumentów i wiadomości w aplikacjach Microsoft 365.
PMK oznacza, że kluczami zarządza platforma Microsoft. CMK oznacza, że organizacja zarządza kluczem używanym do ochrony kluczy szyfrujących dane, najczęściej w Azure Key Vault lub Azure Managed HSM.
Nie warto opisywać tego jako absolutnego „odcięcia Microsoftu”. Customer Key zwiększa kontrolę organizacji nad root encryption keys na poziomie aplikacyjnym i dodaje warstwę ochrony ponad standardowe szyfrowanie.
Trzeba to rozumieć w kontekście konkretnego workloadu, polityk, licencji i modelu operacyjnego. Microsoft opisuje Customer Key jako dodatkową ochronę pomagającą spełniać wymagania compliance i regulacyjne, a nie jako zamiennik całego modelu bezpieczeństwa danych.
W typowym modelu Customer Key jest częścią hierarchii ochrony kluczy, a nie mechanizmem, w którym każdy plik jest ręcznie szyfrowany kluczem klienta przy każdej operacji użytkownika.
Użytkownicy zwykle nie powinni odczuwać tego jako „spowolnienia”, ale projekt i tak warto przetestować w swoim środowisku – szczególnie przy dużych tenantach, wielu lokalizacjach i krytycznych obciążeniach.
Utrata lub błędna obsługa klucza może mieć poważne skutki dla dostępności danych. Dlatego Customer Key wymaga odpowiedniej architektury, w tym dwóch kluczy dla każdej Data Encryption Policy oraz osobnych subskrypcji Azure.
Nie zawsze. Często lepiej objąć dodatkową kontrolą wybrane dane, workloady albo grupy użytkowników.
Zakres powinien wynikać z klasyfikacji danych, regulacji i ryzyka, a nie z założenia, że „wszystko musi mieć własne klucze”.
Nie. CMK i Customer Key dotyczą kontroli kryptograficznej oraz zarządzania kluczami.
DLP, sensitivity labels, retencja, audyt i kontrola udostępnień odpowiadają na inne ryzyka: kto ma dostęp do danych, jak są klasyfikowane, jak są udostępniane i jak długo są przechowywane.
Nie. Szyfrowanie chroni dane przez ich zakodowanie, ale dane nadal mogą zostać odczytane przez uprawnione osoby lub systemy posiadające właściwy klucz. Anonimizacja ma uniemożliwić powiązanie danych z konkretną osobą. Pseudonimizacja ogranicza możliwość identyfikacji, ale przy użyciu dodatkowych informacji nadal może być odwracalna.
Nie. BitLocker chroni dane na poziomie dysków i infrastruktury. Customer Key dodaje warstwę kontroli nad kluczami głównymi na poziomie aplikacyjnym w Microsoft 365 i uzupełnia standardowe szyfrowanie usługowe. Microsoft opisuje Customer Key jako dodatkową warstwę ochrony ponad BitLocker oraz server-side encryption.
Chcesz sprawdzić, jaki model szyfrowania danych ma sens w Twojej organizacji?
Ocenimy, czy wystarczy domyślna ochrona Microsoft, czy warto wdrożyć CMK, Customer Key, HSM, PKI albo dodatkowe mechanizmy anonimizacji i pseudonimizacji – bez dokładania złożoności tam, gdzie nie daje realnej wartości.
Poznaj nasze pozostałe usługi
Aplikacje biznesowe
Usługi dla aplikacji oraz gotowe rozwiązania w obszarze cyfryzacji procesów i nowoczesnego środowiska pracy.
Nowoczesne i kompleksowe wsparcie w obszarze cyberbezpieczeństwa dla Twojej firmy.
Cyberbezpieczeństwo
Pełne wsparcie i optymalizacja infrastruktury IT, zapewniające stabilny rozwój Twojego biznesu.
Infrastruktura IT
Bezpieczeństwo wdrożenia i utrzymania usług Microsoft 365 oraz Azure, które umożliwiają elastyczne zarządzanie i optymalizację kosztów.
