Szyfrujesz czy oddajesz?

Microsoft: szyfrowanie bez suwerenności

BitLocker sam w sobie nie jest problemem. Problemem jest to, że domyślnie recovery key leci do chmury Microsoftu (konto Microsoft / Entra ID), a więc istnieje w przestrzeni, do której operator ma prawny i techniczny dostęp.Virtru nazwało to po imieniu: „encryption without data sovereignty” – klient ma zaszyfrowane dyski, ale nie ma wyłącznej kontroli nad kluczem, bo Microsoft w praktyce pełni rolę urzędu do wydawania przepustek do danych.Jeśli twoja stacja z BitLockerem jest powiązana z kontem organizacyjnym i nie wyłączyłeś escrowing’u kluczy do chmury, to przy odpowiednim nakazie Microsoft może ten klucz przekazać, a ty dowiesz się o tym – jeśli w ogóle – z opóźnieniem, bo NDA przy takich nakazach to standard.​

Praktyczny detal: w wielu tenantach widziałem polityki, gdzie RequireDeviceEncryption = True i brak osobnej polityki zabraniającej automatycznego backupu kluczy do Entra ID. Czyli szyfrowanie niby jest, ale suwerenność nad kluczem leży po stronie dostawcy.​

Apple: schizofreniczne iCloud + Advanced Data Protection

Apple gra w podwójną grę. Standardowy iCloud ma miks danych szyfrowanych end‑to‑end oraz takich, gdzie Apple trzyma klucze w swoich data center i może je wydać na podstawie nakazu.Advanced Data Protection (ADP) to dopiero prawdziwe E2EE: większość kategorii danych iCloud jest szyfrowana tak, że tylko twoje zaufane urządzenia mają klucze, a Apple nie może ich użyć ani do odzyskiwania, ani do odpowiedzi na nakaz.Z perspektywy organów ścigania to ruletka: jeśli ADP jest włączone, produkcja z iCloud to w dużej mierze zaszyfrowane blob-y plus metadane i plik Chunkdetails.csv z checksumami, a wartość dowodowa spada dramatycznie bez fizycznego dostępu do urządzeń i mechanizmów odzyskiwania klucza.​

The Register opisał, jak presja regulacyjna potrafi to odwrócić: dla UK Apple zdecydowało się wyłączyć ADP, bo end‑to‑end szyfrowanie kłóciło się z oczekiwaniami państwa do łatwego dostępu do danych w iCloud.​Czyli E2EE w chmurze Apple jest funkcją geopolityki, nie tylko techniki – w jednych jurysdykcjach dostajesz realną prywatność, w innych „wygodę” organów ścigania.​

Google i Meta: usługa decyduje, nie logo

Dla Google i Meta nie ma jednego modelu.Część usług ma tryby E2EE (np. komunikatory), ale backupy, przestrzenie dyskowe i archiwa danych mają różne modele zarządzania kluczem: czasem provider ma techniczny dostęp, czasem klucz jest powiązany z urządzeniami, czasem jest to hybryda.​Uproszczenie „Apple, Google i Meta robią X, Microsoft nie” jest wygodne na slajd, ale przy IR szybko zabija cię brak szczegółów: musisz wiedzieć, co dokładnie jest E2EE, a gdzie klucz jest depozytem u dostawcy i może wylądować w aktach sprawy.​

Oracle i AWS: KMS i iluzja „bring your own key”

Oracle i AWS chętnie sprzedają narrację „bring your own key” i „customer-managed keys”, ale trzeba czytać drobny druk.W AWS KMS klucz logicznie należy do ciebie, ale fizycznie działa w HSM zarządzanym przez AWS i istnieją tryby, w których operator może wykonać operację kryptograficzną na twoim materiale kluczowym na potrzeby procesów zgodnych z prawem.​Oracle idzie w podobną stronę: daje ci interfejsy do zarządzania kluczami, rotacją, politykami, ale hardware, firmware i integracja z infrastrukturą operatora pozostają w ich rękach – z punktu widzenia suwerenności danych to nadal model zaufania do chmury, nie pełna izolacja.​

„Klient zarządza kluczami” w folderze marketingowym nie znaczy, że operator nie może ich dotknąć, gdy przyjdzie papier z sądu z odpowiednią podstawą prawną.Prawdziwym złotym standardem jest tylko taki model, w którym chmura przechowuje wyłącznie ciphertext, a wszystkie operacje na kluczach – generacja, podział, składanie – dzieją się poza jej kontrolą.

Efekt Rogów: jedna dziura, cały wizerunek w piach

Virtru podsumowało sprawę BitLockera brutalnie: jeśli trzymasz klucze w chmurze Microsoftu, to de facto oddajesz kontrolę nad dostępem do danych dostawcy, który w starciu z nakazem będzie egzekwował swoje obowiązki prawne, nie twoją politykę bezpieczeństwa.The Register nazwał to „surrender as a service”: w momencie, gdy operator posiada recovery key, twoja cała narracja o „zero trust”, „data ownership” i „confidential computing” rozbija się o prostą czynność: wydrukowanie klucza z portalu i przekazanie go odpowiednim służbom.

Effekt aureoli działa, dopóki marketing trzyma narrację.Jedna dobrze nagłośniona sprawa, w której organ ścigania czy konkurencja uzyskuje dostęp do pełnych dysków przez legalny dostęp do kluczy w chmurze, i nagle twoja marka „dbająca o prywatność klientów” staje się memem na r/netsec.

Koncepcja: klucz pocięty na dwie chmury, składany on‑prem

Model:

1. Generujesz lokalnie główny klucz szyfrujący backupy, nazwijmy go K_master.
   
2. Z K_master tworzysz dwa udziały, K_A i K_B, w schemacie dzielonym (np. Shamir’s Secret Sharing, próg 2‑z‑2 w tym wariancie).
   
3. Każdy udział ląduje w innej chmurze (np. udział A w AWS, udział B w Oracle), w różnych regionach i różnych kontach, bez pełnego kontekstu metadanych.
   
4. Backupy w chmurze (np. w trzeciej chmurze lub u jednego z tych dwóch operatorów) są szyfrowane K_master, ale żaden z dostawców nie ma kompletnego klucza – widzą ciphertext i co najwyżej swój fragment udziału.
   

Do odszyfrowania potrzebujesz:– lokalnego procesu, który pobierze K_A i K_B,– węzła on‑prem, który złoży K_master w pamięci (bez logowania klucza na dysk),– mechanizmu, który po odszyfrowaniu backupu skasuje z pamięci zarówno K_master, jak i udziały.

Brutalna zaleta: pojedynczy nakaz do jednej chmury daje co najwyżej 50% tajemnicy, czyli nic.Żeby faktycznie mieć K_master, trzeba w praktyce skoordynować działania wobec dwóch różnych operatorów, potencjalnie w dwóch różnych jurysdykcjach.

Techniczny detal, który odróżnia slajd od produkcji

Jeżeli robisz to na poważnie, to:– udziały klucza (K_A, K_B) przechowujesz nie jako raw key, tylko jako zaszyfrowany blob (np. AES‑GCM) z lokalnym KEK, który nigdy nie wychodzi poza twoje HSM / TPM;– endpoint do pobierania udziału ma wymuszony mTLS z certem wydanym z twojego prywatnego CA, a po stronie chmury robisz hard enforcement na aws:PrincipalTag/kms:EncryptionContext albo odpowiednik w Oracle, żeby nawet wewnętrzny operator nie mógł sobie „kliknąć” GET‑a po udział;​– w pipeline backupowym ustawiasz twarde ograniczenie: K_master istnieje w RAM podczas operacji odtworzenia backupu maksymalnie kilkanaście sekund, a potem jest nadpisywany.

To jest różnica między „mamy E2EE” na stronie www, a realnym modelem, w którym nawet ty musisz się trochę napocić, żeby odzyskać dane.Jeżeli odtwarzanie backupu jest zbyt wygodne, to zwykle znaczy, że ktoś inny też będzie miał wygodnie – tylko z nakazem.

Plan działania

Skoro wiemy, że chmurze nie wolno ufać w kwestii kluczy, to przechodzimy do tezy roboczej: backup w chmurze, ale klucz, który istnieje tylko po złożeniu dwóch kawałków przechowywanych w różnych chmurach i składanych dopiero lokalnie.

Krok 1: audyt kluczy. Sprawdź, gdzie realnie lądują recovery keys, KMS CMK i hasła do backupów – szczególnie BitLocker recovery keys w Entra ID/MDM, iCloud bez ADP dla zarządu, KMS w AWS z nadmiernymi uprawnieniami operacyjnymi.

Krok 2: odłącz escrowing. Dla stacji z wysokim ryzykiem (zarząd, R&D, M&A) wyłącz automatyczne wysyłanie kluczy do operatora chmury, wprowadź HSM/TPM i własny system escrow on‑prem, z rotacją i twardą procedurą dostępu (4‑eyes, logi, SIEM).​

Krok 3: zaprojektuj split-key backup. Wybierz dwie chmury, wdroż Shamir’a lub inny system dzielenia tajemnicy, napisz minimalny, audytowalny kod, który składa klucz wyłącznie lokalnie, i zrób tabletop exercise: załóż, że jedna z chmur dostała nakaz i „posypała się”, a ty musisz odzyskać backup bez ich udziału.​

Kto tego nie ma, ten gra w rosyjską ruletkę z cudzym pistoletem – klucze trzyma operator, a ty tylko liczysz na to, że nikt nie pociągnie za spust.

Bibliografia

• Virtru – „Microsoft’s BitLocker Problem: Encryption Without Data Sovereignty”
  
• Virtru Blog – „Decrypted | Insights from Virtru to Unlock New Ideas” ​
  
• The Register – „Surrender as a service: Microsoft unlocks BitLocker for feds”
  
• Apple – „Advanced Data Protection Analytics & Privacy”​
  
• WarrantBuilder – „iCloud Advanced Data Protection: A challenge for law enforcement”​
  
• The Register – „Apple ends iCloud Advanced Data Protection for UK residents”​
  
• Badania nt. szyfrowania i zarządzania kluczami w chmurze (MDPI, CP‑ABE / KMS)​