Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy: programu Configuration Manager (bieżąca gałąź)
Program Configuration Manager używa podpisywania i szyfrowania, aby chronić zarządzanie urządzeniami w hierarchii programu Configuration Manager. W przypadku podpisywania, jeśli dane zostały zmienione podczas przesyłania, zostaną one odrzucone. Szyfrowanie uniemożliwia osobie atakującej odczytanie danych przy użyciu analizatora protokołu sieciowego.
Podstawowym algorytmem wyznaczania wartości skrótu używanym przez program Configuration Manager do podpisywania jest SHA-256. Gdy dwie lokacje programu Configuration Manager komunikują się ze sobą, podpisują swoją komunikację za pomocą algorytmu SHA-256.
Począwszy od wersji 2107, podstawowym algorytmem szyfrowania używanym przez program Configuration Manager jest AES-256. Szyfrowanie występuje głównie w następujących dwóch obszarach:
Jeśli włączysz w lokacji szyfrowanie, klient szyfruje swoje dane zapasów i komunikaty o stanie, które wysyła do punktu zarządzania.
Gdy klient pobiera tajne zasady, punkt zarządzania zawsze szyfruje te zasady. Na przykład sekwencja zadań wdrażania systemu operacyjnego zawierająca hasła.
Uwaga
W przypadku skonfigurowania komunikacji HTTPS te wiadomości są szyfrowane dwukrotnie. Wiadomość jest szyfrowana za pomocą AES, następnie transport HTTPS jest szyfrowany za pomocą AES-256.
W przypadku komunikacji z klientami 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ótu i długościami kluczy. W przypadku korzystania z certyfikatów CNG v3 klienci programu Configuration Manager obsługują tylko certyfikaty korzystające z algorytmu kryptograficznego RSA. Aby uzyskać więcej informacji, zobacz Omówienie wymagań dotyczących certyfikatów PKI i certyfikatów CNG v3.
W celu zapewnienia bezpieczeństwa transportu wszystko, co używa protokołu TLS, obsługuje standard AES-256. Ta obsługa obejmuje konfigurowanie witryny pod kątem rozszerzonego protokołu HTTP (E-HTTP) lub HTTPS. W przypadku lokalnych systemów lokacji można kontrolować mechanizmy szyfrowania TLS. W przypadku ról opartych na chmurze, takich jak brama zarządzania chmurą (CMG), po włączeniu protokołu TLS 1.2 program Configuration Manager konfiguruje zestawy szyfrowania.
W przypadku większości operacji kryptograficznych w systemach operacyjnych Windows Configuration Manager używa algorytmów z biblioteki CryptoAPI systemu Windows rsaenh.dll.
Aby uzyskać więcej informacji na temat poszczególnych funkcji, zobacz Operacje witryny.
Działanie witryny
Informacje w programie Configuration Manager mogą być podpisywane i szyfrowane. Obsługuje te operacje z certyfikatami PKI lub bez nich.
Podpisywanie zasad i szyfrowanie
Witryna podpisuje przypisania zasad klienta za pomocą certyfikatu z podpisem własnym. Takie działanie pomaga zapobiegać wysyłaniu zmodyfikowanych zasad przez zagrożenie bezpieczeństwa punktu zarządzania z naruszonymi zabezpieczeniami. W przypadku zarządzania klientami internetowymi to zachowanie jest ważne, ponieważ wymaga punktu zarządzania dostępnego w Internecie.
Gdy zasady zawierają poufne dane, począwszy od wersji 2107, punkt zarządzania szyfruje je przy użyciu algorytmu AES-256. Zasady, które zawierają poufne dane, są wysyłane tylko do autoryzowanych klientów. Witryna nie szyfruje zasad, które nie zawierają poufnych danych.
Gdy klient przechowuje zasady, szyfruje je przy użyciu interfejsu programowania aplikacji ochrony danych systemu Windows (DPAPI).
Tworzenie skrótów zasad
Gdy klient żąda zasad, najpierw otrzymuje przypisanie zasad. Wtedy wie, które zasady go dotyczą, i może żądać tylko tych organów zasad. Każde przypisanie zasad zawiera obliczeniowy 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 zasad to SHA-256.
Haszowanie zawartości
Usługa menedżera dystrybucji na serwerze lokacji tworzy skróty plików zawartości dla wszystkich pakietów. Dostawca zasad dołącza skrót do zasad dystrybucji oprogramowania. Gdy klient programu Configuration Manager pobiera zawartość, klient ponownie generuje skrót lokalnie i porównuje go z wartością podaną w zasadach. Jeśli skróty są zgodne, zawartość nie jest zmieniana i klient instaluje ją. Jeśli zmieniony zostanie pojedynczy bajt zawartości, skróty nie będą zgodne, a klient nie zainstaluje oprogramowania. Sprawdzenie to pozwala upewnić się, że zainstalowano właściwe 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. Do wyjątków należą:
- klientów systemu Windows podczas przesyłania strumieniowego zawartości App-V.
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 E-HTTP, czy HTTPS. Jeśli korzystają z protokołu E-HTTP, możesz również zaszyfrować te dane, co jest zalecane.
Szyfrowanie migracji stanów
Gdy sekwencja zadań przechwytuje dane z klienta wdrożenia systemu operacyjnego, zawsze szyfruje dane. W wersji 2103 i nowszych sekwencja zadań uruchamia narzędzie User State Migration Tool (USMT) z algorytmem szyfrowania AES-256 .
Szyfrowanie pakietów multiemisji
W przypadku każdego pakietu wdrożenia systemu operacyjnego można włączyć szyfrowanie, gdy używasz multiemisji. To szyfrowanie wykorzystuje algorytm AES-256 . W przypadku włączenia szyfrowania nie jest wymagana żadna inna konfiguracja certyfikatu. Punkt dystrybucji z włączoną multiemisji automatycznie generuje klucze symetryczne w celu zaszyfrowania pakietu. Każdy pakiet ma inny klucz szyfrowania. Klucz jest przechowywany w punkcie dystrybucji z włączoną multiemisji przy użyciu standardowych interfejsów API systemu Windows.
Gdy klient łączy się z sesją multiemisji, następuje wymiana kluczy za pośrednictwem zaszyfrowanego kanału. Jeśli klient korzysta z protokołu HTTPS, używa certyfikatu uwierzytelniania klienta wystawionego przez infrastrukturę PKI. Jeśli klient korzysta z protokołu E-HTTP, używa certyfikatu z podpisem własnym. Klient przechowuje klucz szyfrowania w pamięci tylko podczas sesji multiemisji.
Szyfrowanie nośnika wdrożenia systemu operacyjnego
Gdy wdrażasz systemy operacyjne przy użyciu nośnika, zawsze określaj hasło w celu ochrony multimediów. Za pomocą hasła zmienne środowiskowe sekwencji zadań są szyfrowane za pomocą algorytmu 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 przechowywania zawartości za pomocą bramy zarządzania chmurą (CMG) zawartość jest szyfrowana za pomocą algorytmu AES-256. Zawartość jest szyfrowana przy każdej aktualizacji. Gdy klienci pobierają zawartość, jest ona szyfrowana i chroniona za pomocą połączenia HTTPS.
Logowanie się do aktualizacji oprogramowania
Wszystkie aktualizacje oprogramowania muszą być podpisane przez zaufanego wydawcę w celu ochrony przed naruszeniami. Na komputerach klienckich program Windows Update Agent (WUA) skanuje w poszukiwaniu aktualizacji z wykazu. Nie zainstaluje aktualizacji, 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 aktualizacje oprogramowania są podpisywane certyfikatem cyfrowym. 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 używany jest certyfikat z podpisem własnym, taki jak certyfikat z podpisem własnym wydawcy programu WSUS, certyfikat musi także znajdować się w magazynie certyfikatów zaufanych głównych urzędów certyfikacji na komputerze lokalnym. WUA sprawdza także, czy na komputerze lokalnym jest włączone ustawienie zasad grupy Zezwalaj na podpisaną zawartość z intranetu Usługa aktualizacji firmy Microsoft dotyczące lokalizacji jest włączona. To ustawienie zasad musi być włączone, aby usługa WUA mogła skanowanie w poszukiwaniu aktualizacji, które zostały utworzone i opublikowane za pomocą programu System Center Aktualizacje Publisher.
Podpisane dane konfiguracyjne dla ustawień zgodności
Podczas importowania danych konfiguracji program Configuration Manager weryfikuje podpis cyfrowy pliku. Jeśli pliki nie są podpisane lub sprawdzanie podpisu nie powiedzie się, konsola wyświetli ostrzeżenie o konieczności kontynuowania importowania. Dane konfiguracyjne należy importować tylko wtedy, gdy jawnie ufasz wydawcy i integralności plików.
Szyfrowanie i haszowanie na potrzeby powiadamiania klienta
Jeśli używasz powiadamiania klienta, cała komunikacja używa protokołu TLS i algorytmów najwyższego poziomu, jakie mogą wynegocjować serwer i klient. Ta sama negocjacja występuje w przypadku tworzenia skrótów pakietów przesyłanych podczas powiadamiania klienta przy użyciu algorytmu SHA-2.
Certyfikaty
Aby uzyskać listę certyfikatów infrastruktury kluczy publicznych (PKI), które mogą być używane przez program Configuration Manager, wszelkie specjalne wymagania i ograniczenia oraz informacje o tym, jak te certyfikaty są używane, zobacz Wymagania dotyczące certyfikatów PKI. Ta lista zawiera obsługiwane algorytmy wyznaczania wartości skrótu i długości kluczy. Większość certyfikatów obsługuje klucze o długości SHA-256 i 2048 bitów.
Większość operacji programu Configuration Manager używających certyfikatów obsługuje również certyfikaty w wersji 3. Aby uzyskać więcej informacji, zobacz Omówienie certyfikatów CNG v3.
Uwaga
Wszystkie certyfikaty używane przez program Configuration Manager muszą zawierać tylko znaki jednobajtowe w nazwie podmiotu lub w nazwie alternatywnej podmiotu.
Program Configuration Manager wymaga certyfikatów PKI w następujących sytuacjach:
Podczas zarządzania klientami programu Configuration Manager w Internecie
W przypadku korzystania z bramy zarządzania chmurą (CMG)
W przypadku większości innych form komunikacji, które wymagają certyfikatów do uwierzytelniania, podpisywania lub szyfrowania, program Configuration Manager automatycznie używa certyfikatów PKI, jeśli są dostępne. Jeśli nie są one dostępne, program Configuration Manager generuje certyfikaty z podpisem własnym.
Zarządzanie urządzeniami przenośnymi i certyfikaty infrastruktury kluczy publicznych
Uwaga
Od listopada 2021 r. zrezygnowaliśmy z zarządzania urządzeniami przenośnymi i zalecamy klientom odinstalowanie tej roli.
Wdrożenie systemu operacyjnego i certyfikaty infrastruktury kluczy publicznych
Gdy wdrażasz systemy operacyjne za pomocą programu Configuration Manager, a punkt zarządzania wymaga połączeń klienckich 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 włączoną obsługą środowiska PXE. Aby obsłużyć ten scenariusz, utwórz certyfikat uwierzytelniania klienta PKI i wyeksportuj go z kluczem prywatnym. Następnie zaimportuj go do właściwości serwera lokacji, a także dodaj certyfikat zaufanego głównego urzędu certyfikacji punktu zarządzania.
W przypadku tworzenia nośnika rozruchowego certyfikat uwierzytelniania klienta jest importowany podczas tworzenia nośnika rozruchowego. Aby chronić klucz prywatny i inne poufne dane 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, który jest wymagany do funkcji klienta, takich jak żądanie zasad klienta.
Jeśli używasz środowiska PXE, zaimportuj certyfikat uwierzytelniania klienta do punktu dystrybucji obsługującego środowisko PXE. Używa tego samego certyfikatu dla każdego klienta, który uruchamia się z tego punktu dystrybucji z włączoną obsługą środowiska PXE. Aby chronić klucz prywatny i inne poufne dane w sekwencjach zadań, wymagaj hasła dla środowiska PXE.
Jeśli którykolwiek z tych certyfikatów uwierzytelniania klienta zostanie naruszony, zablokuj certyfikaty w węźle Certyfikaty w obszarze roboczym Administracja , w węźle Zabezpieczenia . Aby zarządzać tymi certyfikatami, musisz mieć uprawnienie Zarządzanie certyfikatem wdrożenia systemu operacyjnego.
Gdy program Configuration Manager wdroży system operacyjny, zainstaluje klienta, klient wymaga własnego certyfikatu uwierzytelniania klienta PKI do komunikacji z klientem HTTPS.
Rozwiązania proxy niezależnych dostawców oprogramowania i certyfikaty infrastruktury kluczy publicznych
Niezależni dostawcy oprogramowania (ISV) mogą tworzyć aplikacje, które rozszerzają program Configuration Manager. Na przykład niezależny dostawca oprogramowania może utworzyć rozszerzenia do obsługi platform klienckich innych niż Windows. Jeśli jednak systemy lokacji wymagają połączeń klienckich HTTPS, ci klienci muszą również używać certyfikatów PKI do komunikacji z lokacją. Program Configuration Manager umożliwia przypisanie certyfikatu do serwera proxy niezależnego dostawcy oprogramowania, co umożliwia komunikację między klientami serwera proxy niezależnego dostawcy zabezpieczeń a punktem zarządzania. Jeśli korzystasz z rozszerzeń, które wymagają certyfikatów serwera proxy niezależnego dostawcy oprogramowania, zapoznaj się z dokumentacją danego produktu.
Jeśli certyfikat niezależnego dostawcy oprogramowania zostanie naruszony, zablokuj certyfikat w węźle Certyfikaty w obszarze roboczym Administracja , w węźle Zabezpieczenia .
Kopiowanie identyfikatora GUID certyfikatu serwera proxy niezależnego dostawcy oprogramowania
Począwszy od wersji 2111, aby uprościć zarządzanie tymi certyfikatami serwerów proxy niezależnego dostawcy oprogramowania, można teraz skopiować jego identyfikator GUID w konsoli programu Configuration Manager.
W konsoli programu Configuration Manager przejdź do obszaru roboczego Administracja.
Rozwiń węzeł Zabezpieczenia i wybierz węzeł Certyfikaty .
Posortuj listę certyfikatów według kolumny Typ .
Wybierz certyfikat typu ISV Proxy.
Na wstążce wybierz pozycję Kopiuj identyfikator GUID certyfikatu.
Ta akcja kopiuje identyfikator GUID tego certyfikatu, na przykład: aa05bf38-5cd6-43ea-ac61-ab101f943987
Asset Intelligence i certyfikaty
Uwaga
Od listopada 2021 r. wycofaliśmy analizę zasobów i zalecamy klientom odinstalowanie tej roli.
Usługi i certyfikaty platformy Azure
Brama zarządzania chmurą (CMG) wymaga certyfikatów uwierzytelniania serwera. Te certyfikaty umożliwiają usłudze komunikację HTTPS z klientami przez Internet. Aby uzyskać więcej informacji, zobacz Certyfikat uwierzytelniania serwera CMG.
Klienci wymagają innego typu uwierzytelniania do komunikowania się z CMG i lokalnym punktem zarządzania. Mogą użyć usługi Microsoft Entra ID, certyfikatu PKI lub tokenu witryny. Aby uzyskać więcej informacji, zobacz Konfigurowanie uwierzytelniania klienta dla bramy zarządzania chmurą.
Klienci nie wymagają certyfikatu infrastruktury PKI klienta, aby korzystać z magazynu opartego na chmurze. Po uwierzytelnieniu w punkcie zarządzania punkt zarządzania wystawia klientowi token dostępu programu Configuration Manager. Klient przedstawia ten token CMG w celu uzyskania dostępu do zawartości. Token jest ważny osiem godzin.
Sprawdzanie listy CRL pod kątem certyfikatów infrastruktury kluczy publicznych
Lista odwołania certyfikatów kluczy publicznych (CRL) zwiększa ogólne zabezpieczenia, ale wiąże się z pewnym obciążeniem administracyjnym i procesowym. Jeśli zostanie włączone sprawdzanie listy CRL, ale klienci nie mogą uzyskać dostępu do listy CRL, połączenie z infrastrukturą PKI zakończy się niepowodzeniem.
Program IIS domyślnie włącza sprawdzanie listy CRL. Jeśli używasz listy CRL z wdrożeniem infrastruktury kluczy publicznych, nie musisz konfigurować większości systemów lokacji z usługami IIS. Wyjątkiem są aktualizacje oprogramowania, w przypadku których trzeba ręcznie włączyć sprawdzanie listy CRL w celu weryfikacji sygnatur plików aktualizacji oprogramowania.
Gdy klient korzysta z protokołu HTTPS, domyślnie włącza sprawdzanie listy CRL.
Następujące połączenia nie obsługują sprawdzania listy CRL w programie Configuration Manager:
- Połączenia między serwerami
Komunikacja z serwerem
Program Configuration Manager używa następujących formantów kryptograficznych do komunikacji z serwerem.
Komunikacja z serwerem w obrębie lokacji
Każdy serwer systemu lokacji używa certyfikatu do transferu danych do innych systemów lokacji w tej samej lokacji programu Configuration Manager. Niektóre role systemu lokacji używają również certyfikatów na potrzeby uwierzytelniania. Jeśli na przykład zainstalujesz punkt proxy rejestracji na jednym serwerze, a punkt rejestracji na innym serwerze, będą one mogły uwierzytelniać się nawzajem przy użyciu tego certyfikatu tożsamości.
Gdy program Configuration Manager używa certyfikatu dla tej komunikacji, jeśli jest dostępny certyfikat infrastruktury kluczy publicznych z możliwością uwierzytelniania serwera, program Configuration Manager automatycznie go używa. Jeśli nie, program Configuration Manager generuje certyfikat z podpisem własnym. Ten certyfikat z podpisem własnym obsługuje uwierzytelnianie serwera, wykorzystuje algorytm SHA-256, a jego klucz ma długość 2048 bitów. Configuration Manager kopiuje certyfikat do magazynu zaufanych People na innych serwerach systemu lokacji, które mogą wymagać zaufania systemu lokacji. Systemy lokacji mogą następnie ufać sobie nawzajem przy użyciu tych certyfikatów i zaufania równorzędnego.
Oprócz tego certyfikatu dla każdego serwera systemu lokacji program Configuration Manager generuje certyfikat z podpisem własnym dla większości ról systemu lokacji. Gdy istnieje więcej niż jedno wystąpienie roli systemu lokacji w tej samej lokacji, współużytkują one ten sam certyfikat. Na przykład w jednej witrynie może znajdować się kilka punktów zarządzania. Ten certyfikat z podpisem własnym wykorzystuje algorytm SHA-256, a jego klucz ma długość 2048 bitów. Jest kopiowany do zaufanego magazynu People na serwerach systemu lokacji, które mogą wymagać zaufania do niego. Ten certyfikat są generowany przez następujące role systemu lokacji:
Punkt synchronizacji analizy zasobów
Punkt ochrony punktu końcowego
Punkt stanu rozwiązania alternatywnego
Punkt zarządzania
Punkt dystrybucji z obsługą multiemisji
Punkt usług Reporting Services
Punkt aktualizacji oprogramowania
Punkt migracji stanów
Program Configuration Manager automatycznie generuje te certyfikaty i zarządza nimi.
Aby wysyłać komunikaty o stanie z punktu dystrybucji do punktu zarządzania, program Configuration Manager używa certyfikatu uwierzytelniania klienta. Podczas konfigurowania punktu zarządzania dla protokołu HTTPS jest wymagany certyfikat infrastruktury kluczy publicznych. Jeśli punkt zarządzania akceptuje połączenia E-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, a jego klucz ma długość 2048 bitów.
Komunikacja między lokacjami za pomocą serwera
Program Configuration Manager transferuje dane między lokacjami przy użyciu replikacji baz danych i replikacji opartej na plikach. Aby uzyskać więcej informacji, zobacz Transfery danych między lokacjami i Komunikacja między punktami końcowymi.
Program Configuration Manager automatycznie konfiguruje replikację bazy danych między lokacjami. Jeśli są dostępne, używa certyfikatów PKI z możliwością uwierzytelniania serwera. Jeśli nie są dostępne, program Configuration Manager tworzy certyfikaty z podpisem własnym na potrzeby uwierzytelniania serwera. W obu przypadkach uwierzytelnianie między witrynami odbywa się za pomocą certyfikatów w magazynie Trusted People, który korzysta z modelu PeerTrust. Używa tego magazynu certyfikatów, aby zapewnić, że tylko serwery SQL Server hierarchii programu Configuration Manager uczestniczą w replikacji lokacja-lokacja.
Serwery lokacji nawiązują komunikację między lokacjami 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ącej sprawdza podpis przy użyciu klucza publicznego i porównuje skrót z wartością wygenerowaną lokalnie. Jeśli znaki są zgodne, witryna odbierająca akceptuje zreplikowane dane. Jeśli wartości nie są zgodne, program Configuration Manager odrzuca dane replikacji.
Replikacja bazy danych w programie Configuration Manager używa brokera usług programu SQL Server do transferu danych między lokacjami. Wykorzystuje następujące mechanizmy:
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 za pomocą algorytmu AES. Jeśli są dostępne, używa certyfikatów PKI z możliwością uwierzytelniania serwera. Używane są tylko certyfikaty znajdujące się w osobistym magazynie certyfikatów komputera.
Broker usług SQL: Ta usługa używa certyfikatów z podpisem własnym i 2048 bitami do uwierzytelniania oraz do podpisywania i szyfrowania danych za pomocą algorytmu AES. Używa tylko certyfikatów z głównej bazy danych programu SQL Server.
Replikacja oparta na plikach wykorzystuje protokół bloku komunikatów serwera (SMB). Używa algorytmu SHA-256 do podpisywania danych, które nie są szyfrowane i nie zawierają żadnych danych poufnych. Aby zaszyfrować te dane, należy użyć protokołu IPsec, który jest implementowany niezależnie od programu Configuration Manager.
Klienci korzystający z protokołu HTTPS
Gdy role systemu lokacji akceptują połączenia klienckie, można skonfigurować je 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 bezpieczeństwa dzięki integracji z infrastrukturą kluczy publicznych (PKI) w celu ochrony komunikacji klient–serwer. Jednak konfigurowanie połączeń klienckich HTTPS bez dokładnej wiedzy na temat planowania, wdrażania i działania infrastruktury kluczy publicznych może narazić użytkownika na niebezpieczeństwo. Jeśli na przykład nie zabezpieczysz głównego urzędu certyfikacji, osoby atakujące mogą naruszyć zaufanie do całej infrastruktury infrastruktury infrastruktury PKI. Niepowodzenie wdrożenia certyfikatów infrastruktury kluczy publicznych i zarządzania nimi przy użyciu kontrolowanych i zabezpieczonych procesów może spowodować, że klienci niezarządzani nie będą mogli otrzymywać krytycznych aktualizacji oprogramowania ani pakietów.
Ważna
Certyfikaty infrastruktury kluczy publicznych, których program Configuration Manager używa do komunikacji z klientem, chronią komunikację tylko między klientem a niektórymi systemami lokacji. Nie chronią one kanału komunikacyjnego między serwerem lokacji a systemami lokacji ani między serwerami lokacji.
Nieszyfrowana 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 używania 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 Reporting Services konfiguruje się tak, aby używały protokołu HTTP lub HTTPS niezależnie od trybu komunikacji z klientem.
Klienci używający protokołu E-HTTP
Gdy klienci używają komunikacji E-HTTP z rolami systemu lokacji, mogą używać certyfikatów PKI do uwierzytelniania klienta lub certyfikatów z podpisem własnym generowanych przez program Configuration Manager. Gdy program Configuration Manager generuje certyfikaty z podpisem własnym, mają one niestandardowy identyfikator obiektu do podpisywania i szyfrowania. Certyfikaty te służą do unikatowej identyfikacji klienta. Te certyfikaty z podpisem własnym wykorzystują algorytm SHA-256, a ich klucz ma długość 2048 bitów.
Wdrożenie systemu operacyjnego i certyfikaty z podpisem własnym
Gdy używasz programu 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ługiwać ten scenariusz dla połączeń klienta E-HTTP, program Configuration Manager generuje certyfikaty z podpisem własnym, które mają niestandardowy identyfikator obiektu do podpisywania i szyfrowania. Certyfikaty te służą do unikatowej identyfikacji klienta. Te certyfikaty z podpisem własnym wykorzystują algorytm SHA-256, a ich klucz ma długość 2048 bitów. Jeśli te certyfikaty z podpisem własnym zostaną naruszone, uniemożliwiaj atakującym użycie ich do personifikacji zaufanych klientów. Zablokuj 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 E-HTTP, uwierzytelniają punkty zarządzania przy użyciu usług Active Directory Domain Services lub zaufanego klucza głównego programu Configuration Manager. 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, mechanizm ten zapewnia minimalne zabezpieczenia, ponieważ każdy komputer może wygenerować certyfikat z podpisem własnym. Użyj zatwierdzenia klienta, aby usprawnić ten proces. Zatwierdź tylko zaufane komputery, automatycznie przez program 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 klientów i serwerów programu Configuration Manager, wykonaj następujące czynności:
Włącz protokół TLS 1.2 na wszystkich urządzeniach i we wszystkich usługach. Aby włączyć protokół TLS 1.2 dla programu Configuration Manager, zobacz Jak włączyć protokół TLS 1.2 dla programu Configuration Manager.
Wyłącz 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:
- Ograniczanie używania niektórych algorytmów kryptograficznych i protokołów w Schannel.dll
- Określanie priorytetów zestawów szyfrowania Schannel
Te procedury nie mają wpływu na funkcje programu Configuration Manager.
Uwaga
Pobieranie aktualizacji programu Configuration Manager z sieci dostarczania zawartości (CDN) platformy Azure, która ma wymagania dotyczące pakietu szyfrowania. Aby uzyskać więcej informacji, zobacz usługę Azure Front Door: konfigurowanie protokołu TLS — często zadawane pytania .