Dokumentacja techniczna kontroli kryptograficznej

  • Artykuł

Dotyczy: programu Configuration Manager (bieżąca gałąź)

Configuration Manager używa podpisywania i szyfrowania, aby chronić zarządzanie urządzeniami w hierarchii Configuration Manager. Jeśli podczas podpisywania dane zostały zmienione podczas przesyłania, są odrzucane. Szyfrowanie zapobiega odczytywaniu danych przez osobę atakującą przy użyciu analizatora protokołu sieciowego.

Podstawowym algorytmem wyznaczania wartości skrótu używanym Configuration Manager do podpisywania jest SHA-256. Gdy dwie Configuration Manager lokacje komunikują się ze sobą, podpisują swoją komunikację za pomocą algorytmu SHA-256.

Począwszy od wersji 2107, podstawowym algorytmem szyfrowania używanym Configuration Manager jest AES-256. Szyfrowanie odbywa się głównie w dwóch następujących obszarach:

  • Jeśli włączysz dla lokacji opcję Użyj szyfrowania, klient szyfruje swoje dane spisu i komunikaty o stanie wysyłane do punktu zarządzania.

  • Gdy klient pobiera zasady wpisów tajnych, punkt zarządzania zawsze szyfruje te zasady. Na przykład sekwencja zadań wdrażania systemu operacyjnego, która zawiera hasła.

W przypadku klientów w wersji 2103 lub starszej podstawowym algorytmem szyfrowania jest 3DES.

Uwaga

W przypadku skonfigurowania komunikacji HTTPS te komunikaty są szyfrowane dwukrotnie. Komunikat jest szyfrowany za pomocą usługi AES, a następnie transport HTTPS jest szyfrowany za pomocą usługi AES.

Jeśli używasz komunikacji klienta za pośrednictwem protokołu HTTPS, skonfiguruj infrastrukturę kluczy publicznych (PKI) tak, aby używała certyfikatów z maksymalnymi algorytmami wyznaczania wartości skrótów i długościami kluczy. W przypadku korzystania z certyfikatów CNG w wersji 3 klienci Configuration Manager obsługują tylko certyfikaty korzystające z algorytmu kryptograficznego RSA. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące certyfikatów infrastruktury kluczy publicznych i certyfikaty CNG w wersji 3 — omówienie.

W przypadku zabezpieczeń transportu wszystko, co korzysta z protokołu TLS, obsługuje usługę AES. Ta obsługa obejmuje konfigurowanie witryny pod kątem rozszerzonego protokołu HTTP lub HTTPS. W przypadku lokalnych systemów lokacji można kontrolować zestawy szyfrowania TLS. W przypadku ról opartych na chmurze, takich jak brama zarządzania chmurą (CMG), jeśli włączysz protokół TLS 1.2, Configuration Manager konfiguruje zestawy szyfrowania.

W przypadku większości operacji kryptograficznych z systemami operacyjnymi Windows Configuration Manager używa tych algorytmów z biblioteki Windows CryptoAPI rsaenh.dll.

Aby uzyskać więcej informacji na temat określonych funkcji, zobacz Operacje lokacji.

Operacje lokacji

Informacje w Configuration Manager można podpisywać i szyfrować. Obsługuje te operacje z certyfikatami PKI lub bez nich.

Podpisywanie i szyfrowanie zasad

Lokacja podpisuje przypisania zasad klienta przy użyciu certyfikatu z podpisem własnym. To zachowanie pomaga zapobiec zagrożeniu bezpieczeństwa, że naruszony punkt zarządzania nie będzie wysyłał naruszonych zasad. Jeśli używasz internetowego zarządzania klientami, to zachowanie jest ważne, ponieważ wymaga internetowego punktu zarządzania.

Gdy zasady zawierają dane poufne, począwszy od wersji 2107, punkt zarządzania szyfruje go za pomocą protokołu AES-256. W wersji 2103 i starszej jest używana wersja 3DES. Zasady zawierające dane poufne są wysyłane tylko do autoryzowanych klientów. Witryna nie szyfruje zasad, które nie zawierają poufnych danych.

Gdy klient przechowuje zasady, szyfruje zasady przy użyciu interfejsu programowania aplikacji ochrony danych systemu Windows (DPAPI).

Wyznaczanie wartości skrótu zasad

Gdy klient żąda zasad, najpierw otrzymuje przypisanie zasad. Następnie wie, które zasady mają do niego zastosowanie, i może zażądać tylko tych organów zasad. Każde przypisanie zasad zawiera obliczony skrót dla odpowiedniej treści zasad. Klient pobiera odpowiednie treści zasad, a następnie oblicza skrót dla każdej treści zasad. Jeśli skrót w treści zasad nie jest zgodny z skrótem w przypisaniu zasad, klient odrzuca treść zasad.

Algorytm wyznaczania wartości skrótu dla zasad to SHA-256.

Skróty zawartości

Usługa menedżera dystrybucji na serwerze lokacji skróty plików zawartości dla wszystkich pakietów. Dostawca zasad zawiera skrót w zasadach dystrybucji oprogramowania. Gdy klient Configuration Manager pobierze zawartość, klient ponownie generuje skrót lokalnie i porównuje go z wartością dostarczoną w zasadach. Jeśli skróty są zgodne, zawartość nie jest zmieniana, a klient ją instaluje. Jeśli pojedynczy bajt zawartości zostanie zmieniony, skróty nie będą zgodne, a klient nie zainstaluje oprogramowania. To sprawdzenie pomaga upewnić się, że zainstalowane jest poprawne oprogramowanie, ponieważ rzeczywista zawartość jest porównywana z zasadami.

Domyślny algorytm wyznaczania wartości skrótu dla zawartości to SHA-256.

Nie wszystkie urządzenia mogą obsługiwać tworzenie skrótów zawartości. Wyjątki obejmują:

  • Klienci systemu Windows podczas przesyłania strumieniowego zawartości app-v.

  • Klienci systemu Windows Mobile, mimo że ci klienci weryfikują podpis aplikacji podpisanej przez zaufane źródło.

Podpisywanie i szyfrowanie spisu

Gdy klient wysyła spis sprzętu lub oprogramowania do punktu zarządzania, zawsze podpisuje spis. Nie ma znaczenia, czy klient komunikuje się z punktem zarządzania za pośrednictwem protokołu HTTP czy HTTPS. Jeśli używają protokołu HTTP, możesz również zaszyfrować te dane, co jest zalecane.

Szyfrowanie migracji stanu

Gdy sekwencja zadań przechwytuje dane z klienta na potrzeby wdrożenia systemu operacyjnego, zawsze szyfruje dane. W wersji 2103 i nowszej sekwencja zadań uruchamia narzędzie do migracji stanu użytkownika (USMT) z algorytmem szyfrowania AES-256 . W wersji 2010 i starszej używa 3DES.

Szyfrowanie pakietów multiemisji

Dla każdego pakietu wdrażania systemu operacyjnego można włączyć szyfrowanie podczas korzystania z multiemisji. To szyfrowanie używa algorytmu AES . W przypadku włączenia szyfrowania nie jest wymagana żadna inna konfiguracja certyfikatu. Punkt dystrybucji z obsługą multiemisji automatycznie generuje klucze symetryczne w celu zaszyfrowania pakietu. Każdy pakiet ma inny klucz szyfrowania. Klucz jest przechowywany w punkcie dystrybucji z obsługą multiemisji przy użyciu standardowych interfejsów API systemu Windows.

Gdy klient łączy się z sesją multiemisji, wymiana kluczy odbywa się za pośrednictwem zaszyfrowanego kanału. Jeśli klient używa protokołu HTTPS, używa certyfikatu uwierzytelniania klienta wystawionego przez infrastrukturę PKI. Jeśli klient używa protokołu HTTP, używa certyfikatu z podpisem własnym. Klient przechowuje klucz szyfrowania tylko w pamięci podczas sesji multiemisji.

Szyfrowanie nośnika wdrażania systemu operacyjnego

W przypadku wdrażania systemów operacyjnych przy użyciu nośnika należy zawsze określić hasło w celu ochrony nośnika. Przy użyciu hasła zmienne środowiskowe sekwencji zadań są szyfrowane za pomocą protokołu AES-128. Inne dane na nośniku, w tym pakiety i zawartość aplikacji, nie są szyfrowane.

Szyfrowanie zawartości opartej na chmurze

Po włączeniu bramy zarządzania chmurą (CMG) do przechowywania zawartości zawartość jest szyfrowana za pomocą protokołu AES-256. Zawartość jest szyfrowana za każdym razem, gdy ją aktualizujesz. Gdy klienci pobierają zawartość, jest ona szyfrowana i chroniona przez połączenie HTTPS.

Logowanie się do aktualizacji oprogramowania

Aby chronić przed naruszeniami, wszystkie aktualizacje oprogramowania muszą być podpisane przez zaufanego wydawcę. Na komputerach klienckich agent Windows Update (WUA) skanuje aktualizacje z wykazu. Aktualizacja nie zostanie zainstalowana, jeśli nie będzie mogła zlokalizować certyfikatu cyfrowego w magazynie Zaufani wydawcy na komputerze lokalnym.

Podczas publikowania aktualizacji oprogramowania za pomocą programu System Center Aktualizacje Publisher certyfikat cyfrowy podpisuje aktualizacje oprogramowania. Możesz określić certyfikat infrastruktury kluczy publicznych lub skonfigurować program Aktualizacje Publisher w celu wygenerowania certyfikatu z podpisem własnym w celu podpisania aktualizacji oprogramowania. Jeśli do publikowania wykazu aktualizacji jest używany certyfikat z podpisem własnym, taki jak program WSUS Publishers z podpisem własnym, certyfikat musi również znajdować się w magazynie certyfikatów zaufanych głównych urzędów certyfikacji na komputerze lokalnym. Usługa WUA sprawdza również, czy ustawienie zasad Zezwalaj na podpisaną zawartość z intranetu grupy lokalizacji usługi aktualizacji firmy Microsoft jest włączone na komputerze lokalnym. To ustawienie zasad musi być włączone, aby usługa WUA skanowała aktualizacje utworzone i opublikowane za pomocą programu System Center Aktualizacje Publisher.

Podpisane dane konfiguracji dla ustawień zgodności

Podczas importowania danych konfiguracji Configuration Manager weryfikuje podpis cyfrowy pliku. Jeśli pliki nie są podpisane lub sprawdzanie podpisu zakończy się niepowodzeniem, konsola wyświetli ostrzeżenie o kontynuowaniu importowania. Zaimportuj dane konfiguracji tylko wtedy, gdy jawnie ufasz wydawcy i integralności plików.

Szyfrowanie i skróty dla powiadomień klienta

Jeśli używasz powiadomień klienta, cała komunikacja używa protokołu TLS i najwyższych algorytmów, które serwer i klient mogą negocjować. Na przykład wszystkie obsługiwane wersje systemu operacyjnego Windows mogą używać szyfrowania co najmniej AES-128 . Ta sama negocjacja ma miejsce w przypadku tworzenia skrótów pakietów przesyłanych podczas powiadamiania klienta, które używa algorytmu SHA-2.

Certyfikaty

Aby uzyskać listę certyfikatów infrastruktury kluczy publicznych (PKI), które mogą być używane przez Configuration Manager, wszelkie specjalne wymagania lub ograniczenia oraz sposób użycia certyfikatów, zobacz Wymagania dotyczące certyfikatów infrastruktury kluczy publicznych. Ta lista zawiera obsługiwane algorytmy skrótów i długości kluczy. Większość certyfikatów obsługuje długość klucza SHA-256 i 2048-bitowego.

Większość operacji Configuration Manager korzystających z certyfikatów obsługuje również certyfikaty w wersji 3. Aby uzyskać więcej informacji, zobacz CNG v3 certificates overview (Omówienie certyfikatów CNG w wersji 3).

Uwaga

Wszystkie certyfikaty używane przez Configuration Manager muszą zawierać tylko znaki jedno bajtowe w nazwie podmiotu lub alternatywnej nazwie podmiotu.

Configuration Manager wymaga certyfikatów PKI w następujących scenariuszach:

  • Zarządzanie klientami Configuration Manager w Internecie

  • Zarządzanie klientami Configuration Manager na urządzeniach przenośnych

  • Zarządzanie komputerami z systemem macOS

  • W przypadku korzystania z bramy zarządzania chmurą (CMG)

W przypadku większości innych komunikacji, która wymaga certyfikatów do uwierzytelniania, podpisywania lub szyfrowania, Configuration Manager automatycznie używa certyfikatów PKI, jeśli są dostępne. Jeśli nie są one dostępne, Configuration Manager generuje certyfikaty z podpisem własnym.

Configuration Manager nie używa certyfikatów infrastruktury kluczy publicznych podczas zarządzania urządzeniami przenośnymi przy użyciu łącznika Exchange Server.

Zarządzanie urządzeniami przenośnymi i certyfikaty infrastruktury kluczy publicznych

Jeśli urządzenie przenośne nie jest zablokowane przez operatora sieci komórkowej, możesz użyć Configuration Manager, aby zażądać i zainstalować certyfikat klienta. Ten certyfikat zapewnia wzajemne uwierzytelnianie między klientem na urządzeniu przenośnym a systemami lokacji Configuration Manager. Jeśli urządzenie przenośne jest zablokowane, nie można użyć Configuration Manager do wdrażania certyfikatów.

Jeśli włączysz spis sprzętu dla urządzeń przenośnych, Configuration Manager również spis certyfikatów zainstalowanych na urządzeniu przenośnym.

Wdrażanie systemu operacyjnego i certyfikaty infrastruktury kluczy publicznych

Jeśli używasz Configuration Manager do wdrażania systemów operacyjnych, a punkt zarządzania wymaga połączeń klienta HTTPS, klient potrzebuje certyfikatu do komunikowania się z punktem zarządzania. To wymaganie jest nawet wtedy, gdy klient znajduje się w fazie przejściowej, takiej jak rozruch z nośnika sekwencji zadań lub punktu dystrybucji z obsługą środowiska PXE. Aby obsłużyć ten scenariusz, utwórz certyfikat uwierzytelniania klienta infrastruktury kluczy publicznych i wyeksportuj go przy użyciu klucza prywatnego. Następnie zaimportuj go do właściwości serwera lokacji, a także dodaj zaufany certyfikat głównego urzędu certyfikacji punktu zarządzania.

W przypadku tworzenia nośnika rozruchowego należy zaimportować certyfikat uwierzytelniania klienta podczas tworzenia nośnika rozruchowego. Aby chronić klucz prywatny i inne dane poufne skonfigurowane w sekwencji zadań, skonfiguruj hasło na nośniku rozruchowym. Każdy komputer uruchamiany z nośnika rozruchowego używa tego samego certyfikatu z punktem zarządzania wymaganym dla funkcji klienta, takich jak żądanie zasad klienta.

Jeśli używasz środowiska PXE, zaimportuj certyfikat uwierzytelniania klienta do punktu dystrybucji z obsługą środowiska PXE. Używa tego samego certyfikatu dla każdego klienta uruchamianego z tego punktu dystrybucji z obsługą środowiska PXE. Aby ułatwić ochronę klucza prywatnego i innych poufnych danych w sekwencjach zadań, należy wymagać hasła dla środowiska PXE.

Jeśli któryś z tych certyfikatów uwierzytelniania klienta zostanie naruszona, zablokuj certyfikaty w węźle Certyfikaty w obszarze roboczym Administracja , w węźle Zabezpieczenia . Do zarządzania tymi certyfikatami potrzebne jest uprawnienie do zarządzania certyfikatem wdrażania systemu operacyjnego.

Po wdrożeniu Configuration Manager systemu operacyjnego klient wymaga własnego certyfikatu uwierzytelniania klienta infrastruktury kluczy publicznych do komunikacji z klientem HTTPS.

Rozwiązania serwera proxy niezależnego dostawcy oprogramowania i certyfikaty infrastruktury kluczy publicznych

Niezależni dostawcy oprogramowania mogą tworzyć aplikacje rozszerzające Configuration Manager. Na przykład niezależny niezależny klient może tworzyć rozszerzenia do obsługi platform klienckich innych niż Windows, takich jak macOS. Jeśli jednak systemy lokacji wymagają połączeń klienckich HTTPS, klienci ci muszą również używać certyfikatów PKI do komunikacji z lokacją. Configuration Manager obejmuje możliwość przypisania certyfikatu do serwera proxy niezależnego dostawcy oprogramowania, który umożliwia komunikację między klientami serwera proxy niezależnego dostawcy oprogramowania a punktem zarządzania. Jeśli używasz rozszerzeń, które wymagają certyfikatów serwera proxy niezależnego dostawcy oprogramowania, zapoznaj się z dokumentacją tego produktu.

Jeśli certyfikat niezależnego dostawcy oprogramowania zostanie naruszona, zablokuj certyfikat w węźle Certyfikaty w obszarze roboczym Administracja , w węźle Zabezpieczenia .

Kopiowanie identyfikatora GUID dla certyfikatu serwera proxy niezależnego dostawcy usług

Począwszy od wersji 2111, aby uprościć zarządzanie tymi certyfikatami serwera proxy niezależnego dostawcy oprogramowania, możesz teraz skopiować jego identyfikator GUID w konsoli Configuration Manager.

  1. W konsoli Configuration Manager przejdź do obszaru roboczego Administracja.

  2. Rozwiń węzeł Zabezpieczenia i wybierz węzeł Certyfikaty .

  3. Posortuj listę certyfikatów według kolumny Typ .

  4. Wybierz certyfikat typu serwer proxy isv.

  5. Na wstążce wybierz pozycję Kopiuj identyfikator GUID certyfikatu.

Ta akcja kopiuje identyfikator GUID tego certyfikatu, na przykład: aa05bf38-5cd6-43ea-ac61-ab101f943987

Analiza zasobów i certyfikaty

Configuration Manager instaluje się przy użyciu certyfikatu X.509 używanego przez punkt synchronizacji analizy zasobów do nawiązywania połączenia z firmą Microsoft. Configuration Manager używa tego certyfikatu do żądania certyfikatu uwierzytelniania klienta z usługi certyfikatów firmy Microsoft. Certyfikat uwierzytelniania klienta jest instalowany w punkcie synchronizacji analizy zasobów i służy do uwierzytelniania serwera w firmie Microsoft. Configuration Manager używa certyfikatu uwierzytelniania klienta do pobierania wykazu analizy zasobów i przekazywania tytułów oprogramowania.

Ten certyfikat ma długość klucza 1024 bitów.

Usługi i certyfikaty platformy Azure

Brama zarządzania chmurą (CMG) wymaga certyfikatów uwierzytelniania serwera. Te certyfikaty umożliwiają usłudze zapewnianie komunikacji HTTPS klientom za pośrednictwem Internetu. Aby uzyskać więcej informacji, zobacz Certyfikat uwierzytelniania serwera CMG.

Klienci wymagają innego typu uwierzytelniania w celu komunikowania się z usługą CMG i lokalnym punktem zarządzania. Mogą oni używać identyfikatora Microsoft Entra, certyfikatu infrastruktury kluczy publicznych lub tokenu witryny. Aby uzyskać więcej informacji, zobacz Konfigurowanie uwierzytelniania klienta dla bramy zarządzania chmurą.

Klienci nie wymagają certyfikatu PKI klienta do korzystania z magazynu opartego na chmurze. Po uwierzytelnieniu w punkcie zarządzania punkt zarządzania wystawia Configuration Manager token dostępu do klienta. Klient przedstawia ten token grupie cmg w celu uzyskania dostępu do zawartości. Token jest ważny przez osiem godzin.

Sprawdzanie listy CRL pod kątem certyfikatów infrastruktury kluczy publicznych

Lista odwołania certyfikatów PKI (CRL) zwiększa ogólne bezpieczeństwo, ale wymaga pewnych nakładów administracyjnych i przetwarzania. Jeśli włączysz sprawdzanie listy CRL, ale klienci nie będą mogli uzyskać dostępu do listy CRL, połączenie PKI zakończy się niepowodzeniem.

Usługi IIS domyślnie umożliwiają sprawdzanie listy CRL. Jeśli używasz listy CRL z wdrożeniem infrastruktury PKI, nie musisz konfigurować większości systemów lokacji z uruchomionymi usługami IIS. Wyjątkiem są aktualizacje oprogramowania, które wymagają ręcznego kroku, aby umożliwić sprawdzanie listy CRL w celu zweryfikowania podpisów w plikach aktualizacji oprogramowania.

Gdy klient używa protokołu HTTPS, domyślnie włącza sprawdzanie listy CRL. W przypadku klientów z systemem macOS nie można wyłączyć sprawdzania listy CRL.

Następujące połączenia nie obsługują sprawdzania listy CRL w Configuration Manager:

  • Połączenia serwer-serwer

  • Urządzenia przenośne zarejestrowane przez Configuration Manager.

Komunikacja z serwerem

Configuration Manager używa następujących kontrolek kryptograficznych do komunikacji z serwerem.

Komunikacja z serwerem w lokacji

Każdy serwer systemu lokacji używa certyfikatu do przesyłania danych do innych systemów lokacji w tej samej Configuration Manager lokacji. Niektóre role systemu lokacji używają również certyfikatów do uwierzytelniania. Jeśli na przykład zainstalujesz punkt proxy rejestracji na jednym serwerze i punkt rejestracji na innym serwerze, mogą się uwierzytelniać nawzajem przy użyciu tego certyfikatu tożsamości.

Jeśli Configuration Manager używa certyfikatu do tej komunikacji, jeśli jest dostępny certyfikat PKI z możliwością uwierzytelniania serwera, Configuration Manager automatycznie z niego korzysta. Jeśli nie, Configuration Manager generuje certyfikat z podpisem własnym. Ten certyfikat z podpisem własnym ma możliwość uwierzytelniania serwera, używa algorytmu SHA-256 i ma długość klucza 2048 bitów. Configuration Manager kopiuje certyfikat do magazynu zaufanych Osoby na innych serwerach systemu lokacji, które mogą wymagać zaufania systemowi lokacji. Systemy lokacji mogą następnie ufać sobie nawzajem przy użyciu tych certyfikatów i peertrust.

Oprócz tego certyfikatu dla każdego serwera systemu lokacji Configuration Manager generuje certyfikat z podpisem własnym dla większości ról systemu lokacji. Jeśli w tej samej lokacji istnieje więcej niż jedno wystąpienie roli systemu lokacji, mają one ten sam certyfikat. Na przykład w tej samej lokacji może istnieć wiele punktów zarządzania. Ten certyfikat z podpisem własnym używa algorytmu SHA-256 i ma długość klucza 2048 bitów. Jest on kopiowany do magazynu Trusted Osoby Store na serwerach systemu lokacji, które mogą wymagać jego zaufania. Następujące role systemu lokacji generują ten certyfikat:

  • Punkt synchronizacji analizy zasobów

  • Punkt rejestracji certyfikatu

  • Punkt ochrony punktu końcowego

  • Punkt rejestracji

  • Rezerwowy punkt stanu

  • Punkt zarządzania

  • Punkt dystrybucji z obsługą multiemisji

  • Punkt usług raportowania

  • Punkt aktualizacji oprogramowania

  • Punkt migracji stanu

Configuration Manager automatycznie generuje te certyfikaty i zarządza nimi.

Aby wysyłać komunikaty o stanie z punktu dystrybucji do punktu zarządzania, Configuration Manager używa certyfikatu uwierzytelniania klienta. Podczas konfigurowania punktu zarządzania dla protokołu HTTPS wymaga on certyfikatu PKI. Jeśli punkt zarządzania akceptuje połączenia HTTP, możesz użyć certyfikatu PKI. Może również używać certyfikatu z podpisem własnym z możliwością uwierzytelniania klienta, używa algorytmu SHA-256 i ma długość klucza 2048 bitów.

Komunikacja między lokacjami

Configuration Manager przesyła dane między lokacjami przy użyciu replikacji bazy danych i replikacji opartej na plikach. Aby uzyskać więcej informacji, zobacz Transfery danych między lokacjami i Komunikacja między punktami końcowymi.

Configuration Manager automatycznie konfiguruje replikację bazy danych między lokacjami. Jeśli jest dostępna, używa certyfikatów PKI z możliwością uwierzytelniania serwera. Jeśli nie jest dostępna, Configuration Manager tworzy certyfikaty z podpisem własnym na potrzeby uwierzytelniania serwera. W obu przypadkach uwierzytelnianie między lokacjami odbywa się przy użyciu certyfikatów w magazynie zaufanych Osoby, który używa funkcji PeerTrust. Używa tego magazynu certyfikatów, aby upewnić się, że tylko Configuration Manager hierarchii serwery SQL uczestniczą w replikacji lokacja-lokacja.

Serwery lokacji ustanawiają komunikację lokacja-lokacja przy użyciu bezpiecznej wymiany kluczy, która odbywa się automatycznie. Serwer lokacji wysyłającej generuje skrót i podpisuje go kluczem prywatnym. Serwer lokacji odbierającego sprawdza podpis przy użyciu klucza publicznego i porównuje skrót z wartością wygenerowaną lokalnie. Jeśli są zgodne, lokacja odbierająca akceptuje zreplikowane dane. Jeśli wartości nie są zgodne, Configuration Manager odrzuca dane replikacji.

Replikacja bazy danych w Configuration Manager używa SQL Server Service Broker do przesyłania danych między lokacjami. Używa ona następujących mechanizmów:

  • SQL Server do SQL Server: to połączenie używa poświadczeń systemu Windows do uwierzytelniania serwera i certyfikatów z podpisem własnym z 1024 bitami do podpisywania i szyfrowania danych przy użyciu algorytmu AES. Jeśli jest dostępna, używa certyfikatów PKI z możliwością uwierzytelniania serwera. Używa tylko certyfikatów w osobistym magazynie certyfikatów komputera.

  • SQL Service Broker: ta usługa używa certyfikatów z podpisem własnym z 2048 bitami do uwierzytelniania oraz do podpisywania i szyfrowania danych przy użyciu algorytmu AES. Używa tylko certyfikatów w bazie danych SQL Server master.

Replikacja oparta na plikach używa protokołu bloku komunikatów serwera (SMB). Używa algorytmu SHA-256 do podpisywania danych, które nie są szyfrowane i nie zawierają żadnych poufnych danych. Aby zaszyfrować te dane, użyj protokołu IPsec, który jest implementowany niezależnie od Configuration Manager.

Klienci korzystający z protokołu HTTPS

Gdy role systemu lokacji akceptują połączenia klienta, można je skonfigurować tak, aby akceptowały połączenia HTTPS i HTTP lub tylko połączenia HTTPS. Role systemu lokacji, które akceptują połączenia z Internetu, akceptują tylko połączenia klienta za pośrednictwem protokołu HTTPS.

Połączenia klienckie za pośrednictwem protokołu HTTPS zapewniają wyższy poziom zabezpieczeń dzięki integracji z infrastrukturą kluczy publicznych (PKI) w celu ochrony komunikacji między klientem a serwerem. Jednak skonfigurowanie połączeń klienta HTTPS bez dokładnego zrozumienia planowania, wdrażania i operacji infrastruktury kluczy publicznych może nadal stanowić zagrożenie. Jeśli na przykład nie zabezpieczysz głównego urzędu certyfikacji, osoby atakujące mogą naruszyć zaufanie całej infrastruktury infrastruktury PKI. Nie można wdrożyć certyfikatów infrastruktury kluczy publicznych i zarządzać nimi przy użyciu kontrolowanych i zabezpieczonych procesów, co może spowodować, że klienci niezarządzani nie będą mogli odbierać krytycznych aktualizacji ani pakietów oprogramowania.

Ważna

Certyfikaty infrastruktury kluczy publicznych używane Configuration Manager do komunikacji z klientem chronią komunikację tylko między klientem a niektórymi systemami lokacji. Nie chronią kanału komunikacji między serwerem lokacji i systemami lokacji ani między serwerami lokacji.

Niezaszyfrowana komunikacja, gdy klienci używają protokołu HTTPS

Gdy klienci komunikują się z systemami lokacji za pośrednictwem protokołu HTTPS, większość ruchu jest szyfrowana. W następujących sytuacjach klienci komunikują się z systemami lokacji bez użycia szyfrowania:

  • Klient nie może nawiązać połączenia HTTPS w intranecie i wraca do korzystania z protokołu HTTP, gdy systemy lokacji zezwalają na tę konfigurację.

  • Komunikacja z następującymi rolami systemu lokacji:

    • Klient wysyła komunikaty o stanie do rezerwowego punktu stanu.

    • Klient wysyła żądania PXE do punktu dystrybucji z obsługą środowiska PXE.

    • Klient wysyła dane powiadomień do punktu zarządzania.

Punkty usług raportowania można skonfigurować tak, aby używały protokołu HTTP lub HTTPS niezależnie od trybu komunikacji klienta.

Klienci korzystający z protokołu HTTP

Gdy klienci używają komunikacji HTTP z rolami systemu lokacji, mogą używać certyfikatów infrastruktury kluczy publicznych do uwierzytelniania klienta lub certyfikatów z podpisem własnym, które Configuration Manager generuje. Gdy Configuration Manager generuje certyfikaty z podpisem własnym, mają niestandardowy identyfikator obiektu do podpisywania i szyfrowania. Te certyfikaty są używane do unikatowego identyfikowania klienta. Te certyfikaty z podpisem własnym używają algorytmu SHA-256 i mają długość klucza 2048 bitów.

Wdrażanie systemu operacyjnego i certyfikaty z podpisem własnym

Jeśli używasz Configuration Manager do wdrażania systemów operacyjnych z certyfikatami z podpisem własnym, klient musi również mieć certyfikat do komunikowania się z punktem zarządzania. To wymaganie jest nawet wtedy, gdy komputer znajduje się w fazie przejściowej, takiej jak rozruch z nośnika sekwencji zadań lub punktu dystrybucji z obsługą środowiska PXE. Aby obsłużyć ten scenariusz dla połączeń klienta HTTP, Configuration Manager generuje certyfikaty z podpisem własnym, które mają niestandardowy identyfikator obiektu do podpisywania i szyfrowania. Te certyfikaty są używane do unikatowego identyfikowania klienta. Te certyfikaty z podpisem własnym używają algorytmu SHA-256 i mają długość klucza 2048 bitów. Jeśli te certyfikaty z podpisem własnym zostaną naruszone, uniemożliwiaj osobom atakującym personifikowanie zaufanych klientów przy użyciu tych certyfikatów. Blokuj certyfikaty w węźle Certyfikaty w obszarze roboczym Administracja , w węźle Zabezpieczenia .

Uwierzytelnianie klienta i serwera

Gdy klienci łączą się za pośrednictwem protokołu HTTP, uwierzytelniają punkty zarządzania przy użyciu Active Directory Domain Services lub przy użyciu Configuration Manager zaufanego klucza głównego. Klienci nie uwierzytelniają innych ról systemu lokacji, takich jak punkty migracji stanu lub punkty aktualizacji oprogramowania.

Gdy punkt zarządzania po raz pierwszy uwierzytelnia klienta przy użyciu certyfikatu klienta z podpisem własnym, ten mechanizm zapewnia minimalne zabezpieczenia, ponieważ każdy komputer może wygenerować certyfikat z podpisem własnym. Użyj zatwierdzenia klienta, aby ulepszyć ten proces. Zatwierdzaj tylko zaufane komputery automatycznie przez Configuration Manager lub ręcznie przez użytkownika administracyjnego. Aby uzyskać więcej informacji, zobacz Zarządzanie klientami.

Informacje o lukach w zabezpieczeniach protokołu SSL

Aby zwiększyć bezpieczeństwo Configuration Manager klientów i serwerów, wykonaj następujące czynności:

  • Włącz protokół TLS 1.2 na wszystkich urządzeniach i usługach. Aby włączyć protokół TLS 1.2 dla Configuration Manager, zobacz Jak włączyć protokół TLS 1.2 dla Configuration Manager.

  • Wyłącz protokoły SSL 3.0, TLS 1.0 i TLS 1.1.

  • Zmień kolejność zestawów szyfrowania związanych z protokołem TLS.

Aby uzyskać więcej informacji, zapoznaj się z następującymi artykułami:

Te procedury nie wpływają na funkcjonalność Configuration Manager.

Uwaga

Aktualizacje do Configuration Manager pobierania z sieci dostarczania zawartości platformy Azure (CDN), która ma wymagania dotyczące zestawu szyfrowania. Aby uzyskać więcej informacji, zobacz Azure Front Door: Konfiguracja protokołu TLS — często zadawane pytania.