Szyfrowanie dysków funkcją BitLocker w systemie Windows 11 dla OEM
Szyfrowanie dysków funkcją BitLocker zapewnia ochronę danych w trybie offline i systemu operacyjnego, zapewniając, że dysk nie jest naruszony, gdy system operacyjny jest w trybie offline. Szyfrowanie dysków funkcją BitLocker używa modułu TPM, dyskretnego lub wbudowanego w oprogramowanie, które obsługuje statyczny korzeń zaufania pomiaru zgodnie z definicją Trusted Computing Group.
Automatyczne szyfrowanie urządzeń za pomocą funkcji BitLocker
Automatyczne szyfrowanie urządzeń funkcją BitLocker używa technologii szyfrowania dysków funkcją BitLocker do automatycznego szyfrowania dysków wewnętrznych po zakończeniu działania funkcji Out Of Box Experience (OOBE) na urządzeniach spełniających wymagania sprzętowe.
Notatka
Automatyczne szyfrowanie urządzeń za pomocą funkcji BitLocker jest uruchamiane podczas korzystania z funkcji OOBE (Out-of-box). Ochrona jest jednak włączona (uzbrojona) tylko po zalogowaniu się użytkowników przy użyciu konta Microsoft lub konta usługi Azure Active Directory. Do tego czasu ochrona jest zawieszona, a dane nie są chronione. Automatyczne szyfrowanie urządzeń funkcją BitLocker nie jest włączone przy użyciu kont lokalnych, w tym przypadku funkcję BitLocker można włączyć ręcznie za pomocą Panelu sterowania funkcji BitLocker.
Wymagania sprzętowe dotyczące automatycznego szyfrowania urządzeń za pomocą funkcji BitLocker
Notatka
Począwszy od systemu Windows 11 w wersji 24H2, firma Microsoft zmniejszyła wymagania sprzętowe dotyczące automatycznego szyfrowania urządzeń (Auto-DE) w systemie Windows:
Funkcja Auto-DE nie zależy już od sprzętowego interfejsu testowego zabezpieczeń (HSTI) / Nowoczesnego Trybu Wstrzymania.
Funkcja Auto-DE zostanie włączona, nawet jeśli wykryte zostaną niezaufane magistrale lub interfejsy bezpośredniego dostępu do pamięci (DMA).
Oznacza to, że producenci OEM nie muszą dodawać interfejsów DMA do klucza rejestru AllowedBuses: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses
Te nowe, zredukowane wymagania są automatycznie odzwierciedlane w testach HLK i żadne dalsze działania nie są wymagane ze strony producentów OEM.
Automatyczne szyfrowanie urządzeń za pomocą funkcji BitLocker jest włączone, gdy:
- Urządzenie zawiera moduł TPM (moduł zaufanej platformy), TPM 1.2 lub TPM 2.0.
- Bezpieczny rozruch UEFI jest włączony. Aby uzyskać więcej informacji, zobacz Secure Boot.
- Bezpieczny Rozruch Platformy jest włączony
- Platforma jest nowoczesnej rezerwowej lub zgodne ze standardem HSTI (to wymaganie zostało usunięte od systemu Windows 11 24H2)
- Interfejsy bezpośredniego dostępu do pamięci (DMA) nie są dozwolone (to wymaganie zostało usunięte od systemu Windows 11 24H2)
Następujące testy muszą przejść przed włączeniem automatycznego szyfrowania urządzeń funkcją BitLocker w systemie Windows 11. Jeśli chcesz utworzyć sprzęt obsługujący tę funkcję, musisz sprawdzić, czy urządzenie przechodzi te testy.
modułu TPM: urządzenie musi zawierać moduł TPM z obsługą PCR 7. Zobacz System.Fundamentals.TPM20.TPM20.
- Jeśli obecność rozszerzalnych kart powoduje załadowanie sterowników UEFI OROM przez interfejs UEFI BIOS podczas rozruchu, funkcja BitLocker nie będzie używać powiązania PCR7.
- Jeśli korzystasz z urządzenia, które nie jest powiązane z pcR7 i funkcja BitLocker jest włączona, nie ma żadnych wad zabezpieczeń, ponieważ funkcja BitLocker jest nadal bezpieczna w przypadku korzystania z zwykłego profilu PCR UEFI (0,2,4,11).
- Wszelkie dodatkowe skróty urzędu certyfikacji (nawet Windows Prod CA) przed uruchomieniem końcowego bootmgr Windows Prod CA uniemożliwią BitLockerowi wybór korzystania z PCR7. Nie ma znaczenia, czy dodatkowe skróty pochodzą z urzędu certyfikacji UEFI (czyli Urzędu Certyfikacji Firmy Trzeciej Microsoft) lub z innego urzędu certyfikacji.
bezpieczny rozruch: bezpieczny rozruch UEFI jest włączony. Zobacz System.Fundamentals.Firmware.UEFISecureBoot.
wymagania nowoczesnego trybu wstrzymania lub walidacji HSTI. (usunięte od wersji Windows 11 24H2)
To wymaganie jest spełnione przez jedną z następujących czynności:- Nowoczesne wymagania dotyczące trybu wstrzymania zostały zaimplementowane. Obejmują one wymagania dotyczące bezpiecznego rozruchu UEFI i ochrony przed nieautoryzowanym dostępem do DMA.
- Począwszy od systemu Windows 10 w wersji 1703, to wymaganie można spełnić za pomocą testu HSTI:
- Test samoobsługowy rozruchu z bezpiecznym uruchomieniem (lub dodatkowe testy skonfigurowane w rejestrze) musi być zgłaszane przez HSTI jako przeprowadzone i zaliczone.
- Z wyłączeniem Thunderbolt, HSTI musi zgłosić brak niedozwolonych szyn DMA.
- Jeśli Thunderbolt jest obecny, HSTI musi zgłosić, że Thunderbolt został skonfigurowany bezpiecznie (poziom zabezpieczeń musi wynosić SL1 — "Autoryzacja użytkownika" lub wyższy).
Musisz mieć 250 MB wolnego miejsca dodatkowo do wszystkiego, co jest potrzebne do rozruchu (i do odzyskania systemu Windows, jeśli umieścisz WinRE na partycji systemowej). Aby uzyskać więcej informacji, zobacz System i partycje narzędzi.
Po spełnieniu wymagań wymienionych powyżej informacje o systemie wskazują, że system obsługuje automatyczne szyfrowanie urządzeń za pomocą funkcji BitLocker. Ta funkcja jest dostępna w systemie Windows 10 w wersji 1703 lub nowszej. Poniżej przedstawiono sposób sprawdzania informacji o systemie.
- Kliknij Starti wpisz Informacje systemowe
- Kliknij prawym przyciskiem myszy aplikację System Information i kliknij Otwórz jako administrator. Zezwól aplikacji na wprowadzanie zmian na urządzeniu, klikając pozycję Tak. Niektóre urządzenia mogą wymagać podwyższonych uprawnień do wyświetlania ustawień szyfrowania.
- Wpodsumowania systemu
zobacz Obsługa szyfrowania urządzeń . Wartość będzie określać, jeśli urządzenie jest zaszyfrowane lub jeśli nie, przyczyny jego wyłączenia.
Wykryto niedozwoloną magistralę/urządzenie obsługujące DMA
Ten stan informacji o systemie w obsłudze szyfrowania urządzeń oznacza, że system Windows wykrył co najmniej jedną potencjalną zewnętrzną magistralę lub urządzenie obsługujące dma, które może ujawnić zagrożenie DMA.
Aby rozwiązać ten problem, skontaktuj się z IHV, aby sprawdzić, czy to urządzenie ma zewnętrzne porty DMA. Jeśli potwierdzą to dostawcy sprzętu, że magistrala lub urządzenie ma tylko wewnętrzny DMA, to producent OEM może dodać je do listy dozwolonych.
Aby dodać magistralę lub urządzenie do listy dozwolonych, musisz dodać wartość do klucza rejestru. W tym celu musisz najpierw przejąć własność klucza rejestru AllowedBuses. Wykonaj następujące kroki:
Przejdź do klucza rejestru HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses.
Kliknij prawym przyciskiem myszy klucz rejestru i wybierz pozycję Uprawnienia....
Kliknij przycisk Zaawansowane, kliknij link Zmień w polu właściciel, wprowadź nazwę konta użytkownika, kliknij przycisk Sprawdź nazwy, a następnie kliknij przycisk OK trzy razy, aby zamknąć wszystkie okna dialogowe uprawnień.
Kliknij prawym przyciskiem myszy klucz rejestru i wybierz ponownie pozycję Uprawnienia....
Kliknij przycisk Dodaj..., dodaj konto użytkownika, kliknij przycisk Sprawdź nazwy, a następnie kliknij przycisk OK, a następnie zaznacz pole wyboru w obszarze Zezwalaj na pełną kontrolę. Następnie kliknij przycisk OK.
Następnie w obszarze klucza AllowedBuses dodaj pary nazw/wartości ciągu (REG_SZ) dla każdej oflagowanej magistrali DMA, która jest określona jako bezpieczna.
- Klucz: przyjazna nazwa urządzenia /opis
- Wartość: PCI\VEN_ID&DEV_ID.
Upewnij się, że identyfikatory są zgodne z danymi wyjściowymi testu HLK. Jeśli na przykład masz bezpieczne urządzenie o przyjaznej nazwie "Contoso PCI Express Root Port", identyfikator dostawcy 1022 i identyfikator urządzenia 157C, należy utworzyć wpis rejestru o nazwie Contoso PCI Express Root Port jako typ danych REG_SZ w: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses
Gdzie wartość = "PCI\VEN_1022&DEV_157C"
Uwaga: ten klucz rejestru jest ignorowany począwszy od systemu Windows 11 24H2.
Układ partycji szyfrowania dysków funkcją BitLocker
Szyfrowanie dysków funkcją BitLocker używa partycji systemowej niezależnie od partycji systemu Windows. Partycja systemowa systemu BitLocker musi spełniać następujące wymagania.
- Partycja systemowa BitLocker jest skonfigurowana jako aktywna partycja.
- Partycja systemowa BitLocker nie powinna być zaszyfrowana.
- Partycja systemowa funkcji BitLocker musi mieć co najmniej 250 MB wolnego miejsca, oprócz przestrzeni zajmowanej przez wymagane pliki. Ta dodatkowa partycja systemowa może służyć do hostowania środowiska odzyskiwania systemu Windows (RE) i narzędzi OEM (dostarczonych przez producenta OEM), o ile partycja nadal spełnia wymagania dotyczące 250 MB wolnego miejsca.
Aby uzyskać więcej informacji, zobacz partycje systemowe i narzędzioweoraz dyski twarde i partycje.
Wyłączanie automatycznego szyfrowania urządzeń za pomocą funkcji BitLocker
Producenci OEM mogą wyłączyć szyfrowanie urządzeń, a zamiast tego zaimplementować własną technologię szyfrowania na urządzeniu. Wyłączenie szyfrowania poza tym scenariuszem jest zabronione, ponieważ narusza wymagania licencyjne systemu Windows 11 i zasadę Windows 11 'secure by default'. Aby wyłączyć automatyczne szyfrowanie urządzenia funkcją BitLocker, możesz użyć pliku nienadzorowanego i ustawić PreventDeviceEncryption na true.
Alternatywnie można zaktualizować klucz rejestru HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker:
Wartość: PreventDeviceEncryption równe True (1).
Nie zalecamy ustawiania tego klucza rejestru na urządzeniach z funkcją odwołań.
Rozwiązywanie problemów z testami HLK dla BitLocker
Zalecane wymagania wstępne
Klasyfikacja jest znacznie prostsza, gdy znasz następujące informacje o urządzeniu testowym:
- Specyfikacja modułu TPM (np. 1.2, 2.0)
- Profil PCR funkcji BitLocker (np. 7, 11 lub 0, 2, 4, 11)
- Niezależnie od tego, czy maszyna jest nie-AOAC, czy AOAC (np. urządzenia Surface są maszynami AOAC)
Te informacje są zalecane, ale nie są wymagane do przeprowadzenia klasyfikacji.
Problemy z funkcją BitLocker HLK są zwykle związane z jedną z następujących kwestii: błędną interpretacją wyników testów lub problemami z powiązaniem PCR7.
Błędna interpretacja wyników testu
Test HLK składa się z wielu kroków testu. Niektóre kroki testu mogą zakończyć się niepowodzeniem bez wpływu na powodzenie/niepowodzenie ogólnego testu. Zobacz tutaj, aby uzyskać więcej informacji na temat interpretowania strony wyników. Jeśli niektóre kroki testu zakończyły się niepowodzeniem, ale ogólny test zakończył się pomyślnie (co wskazuje zielony symbol obok nazwy testu), zatrzymaj się tutaj. Test został pomyślnie uruchomiony i nie trzeba już podejmować żadnych działań.
Etapy priorytetyzacji:
Upewnij się, że uruchamiasz odpowiedni test względem maszyny. Kliknij prawym przyciskiem myszy na dowolny krok testu zakończonego niepowodzeniem > Infrastruktura > dzienniki zbieracza, > zajrzyj do środka RUNTIMEBLOCK.xml w poszukiwaniu elementu IsAOAC. Jeśli IsAOAC=true i korzystasz z testu, który nie jest testem AOAC, zignoruj błąd i nie uruchamiaj tego testu na maszynie. W razie potrzeby skontaktuj się z zespołem pomocy technicznej firmy Microsoft, aby uzyskać erratę dotyczącą przetwarzania listy odtwarzania.
Ustal, czy filtr jest stosowany do testu. HLK może automatycznie sugerować filtr dla niepoprawnie zamapowanego testu. Filtr jest wyświetlany jako zielony znacznik wyboru wewnątrz okręgu obok kroku testowego. (Należy pamiętać, że niektóre filtry mogą wskazywać, że kolejne kroki testu zakończyły się niepowodzeniem lub zostały anulowane). Sprawdź rozszerzone informacje o filtrze, rozwijając krok testu przy użyciu ikony specjalnej. Jeśli filtr informuje o lekceważeniu błędu testu, zatrzymaj się tutaj.
Problemy z pcR7
Typowym problemem z funkcją BitLocker, który jest specyficzny dla dwóch testów PCR7, jest niepowodzenie w powiązaniu z PCR7.
Etapy klasyfikacji:
Znajdź komunikat o błędzie w dziennikach HLK. Rozwiń krok testu, który zakończył się niepowodzeniem, i sprawdź dziennik Te.wtl. (Możesz również uzyskać dostęp do tego dziennika, klikając prawym przyciskiem myszy na krok testu , a następnie wybierając z menu: Dzienniki zadań >, Te.wtl >,.) Jeśli widzisz ten błąd, kontynuuj według kroków trieżu:
Uruchom narzędzie msinfo32 jako administrator i sprawdź konfigurację bezpiecznego rozruchu/PCR7. Test powinien zostać uruchomiony z włączonym bezpiecznym rozruchem. Jeśli powiązanie PCR7 jest nieobsługiwane, uruchom odpowiedni starszy test PCR HLK. Jeśli powiązanie PCR7 nie jest możliwe, kontynuuj postępowanie według kroków postępowania awaryjnego.
Sprawdź dzienniki błędów. Kliknij prawym przyciskiem myszy zadanie testowe > Dodatkowe pliki. Zwykle problem z powiązaniem PCR7 jest wynikiem nieprawidłowego pomiaru wartości w PCR7.
- Dzienniki zdarzeń. Dziennik MicrosoftuBitLocker-Management zawiera cenne informacje o błędach, które wyjaśniają, dlaczego nie można używać PCR7. Test HLK funkcji BitLocker powinien być uruchamiany tylko na maszynie z zainstalowaną funkcją BitLocker. Dzienniki zdarzeń są sprawdzane na maszynie generującej je.
- Mierzone logi rozruchowe. Można je również znaleźć w folderze C:\Windows\Logs\MeasuredBoot
Przeanalizuj mierzony dziennik rozruchu przy użyciu TBSLogGenerator.exe lub równoważnego. Na kontrolerze HLK, TBSLogGenerator.exe znajduje się w katalogu testów HLK, gdzie zostało zainstalowane HLK, na przykład C:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Tests\amd64\nttest\BASETEST\ngscb\TBSLogGenerator.exe.
- ścieżka TBSLogGenerator.exe -lf <do mierzonego dziennika rozruchu>> OutputLog.txt
- W OutputLog.txtwyszukaj ciąg "PCR[07]" i sprawdź miary wymienione w podanej kolejności. Pierwsza miara powinna wyglądać mniej więcej tak:
BitLocker oczekuje określonych statycznych pomiarów korzenia zaufania statycznych pomiarów korzenia zaufania w PCR7, a wszelkie różnice w tych pomiarach często uniemożliwiają powiązanie z PCR7. Następujące wartości powinny być mierzone (w kolejności i bez dodatkowych pomiarów między) do PCR7:
- Zawartość zmiennej SecureBoot
- Zawartość zmiennej PK
- Zawartość zmiennej KEK
- Zawartość zmiennej EFI_IMAGE_SECURITY_DATABASE (DB)
- Zawartość zmiennej EFI_IMAGE_SECURITY_DATABASE1 (DBX)
- (opcjonalne, ale typowe EV_SEPARATOR)
- Wpisy w EFI_IMAGE_SECURITY_DATABASE używane do weryfikowania sterowników EFI lub aplikacji rozruchowych EFI w ścieżce rozruchowej. BitLocker oczekuje tutaj tylko jednego wpisu.
Typowe problemy z mierzonym dziennikiem rozruchu:
- Tryb debugowania UEFI włączony
- Brak zmiennych PK lub KEK: pomiar PK/KEK nie zawiera danych (np. 4 bajtów 0)
- Niewiarygodny sygnatariusz urzędu certyfikacyjnego UEFI
Niektóre mierzone problemy z rozruchem, takie jak uruchamianie w trybie debugowania UEFI, mogą zostać rozwiązane przez testera. Inne problemy mogą wymagać erraty, w takim przypadku należy skontaktować się z zespołem pomocy technicznej firmy Microsoft po wskazówki.
Stosowanie aktualizacji oprogramowania układowego do urządzeń
Oprócz uruchamiania testów HLK, OEM-y muszą testować aktualizacje oprogramowania układowego z włączonym BitLockerem. Aby zapobiec niepotrzebnemu uruchamianiu odzyskiwania przez urządzenia, postępuj zgodnie z poniższymi wytycznymi, aby zastosować aktualizacje oprogramowania układowego:
- Wstrzymaj funkcję BitLocker (wymaganą dla urządzeń powiązanych z pcR[07] tylko wtedy, gdy aktualizacja oprogramowania układowego zmieni zasady bezpiecznego rozruchu)
- Stosowanie aktualizacji
- Uruchom ponownie urządzenie
- Wznawianie funkcji BitLocker
Aktualizacja oprogramowania układowego powinna wymagać od urządzenia wstrzymania funkcji BitLocker tylko przez krótki czas, a urządzenie powinno zostać ponownie uruchomione tak szybko, jak to możliwe. Funkcję BitLocker można zawiesić programowo tuż przed zamknięciem przy użyciu metody DisableKeyProtectors w instrumentacji zarządzania Windows (WMI).