Planowanie zabezpieczeń w Configuration Manager

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

W tym artykule opisano następujące pojęcia, które należy wziąć pod uwagę podczas planowania zabezpieczeń przy użyciu implementacji Configuration Manager:

  • Certyfikaty (z podpisem własnym i infrastrukturą PKI)

  • Zaufany klucz główny

  • Podpisywanie i szyfrowanie

  • Administracja oparta na rolach

  • Microsoft Entra ID

  • Uwierzytelnianie dostawcy programu SMS

Przed rozpoczęciem upewnij się, że znasz podstawy zabezpieczeń w Configuration Manager.

Certyfikaty

Configuration Manager używa kombinacji certyfikatów cyfrowych z podpisem własnym i infrastruktury kluczy publicznych (PKI). W miarę możliwości używaj certyfikatów infrastruktury kluczy publicznych. Niektóre scenariusze wymagają certyfikatów infrastruktury kluczy publicznych. Gdy certyfikaty PKI nie są dostępne, witryna automatycznie generuje certyfikaty z podpisem własnym. W niektórych scenariuszach zawsze są używane certyfikaty z podpisem własnym.

Aby uzyskać więcej informacji, zobacz Planowanie certyfikatów.

Zaufany klucz główny

Zaufany klucz główny Configuration Manager zapewnia mechanizm Configuration Manager klientom w celu sprawdzenia, czy systemy lokacji należą do ich hierarchii. Każdy serwer lokacji generuje klucz wymiany lokacji w celu komunikowania się z innymi lokacjami. Klucz wymiany lokacji z lokacji najwyższego poziomu w hierarchii jest nazywany zaufanym kluczem głównym.

Funkcja zaufanego klucza głównego w Configuration Manager przypomina certyfikat główny w infrastrukturze klucza publicznego. Wszystkie elementy podpisane przez klucz prywatny zaufanego klucza głównego są zaufane w dalszej części hierarchii. Klienci przechowują kopię zaufanego klucza głównego lokacji w root\ccm\locationservices przestrzeni nazw usługi WMI.

Na przykład lokacja wystawia certyfikat do punktu zarządzania, który podpisuje kluczem prywatnym zaufanego klucza głównego. Lokacja udostępnia klientom klucz publiczny zaufanego klucza głównego. Następnie klienci mogą rozróżniać punkty zarządzania znajdujące się w hierarchii i punkty zarządzania, które nie znajdują się w hierarchii.

Klienci automatycznie pobierają publiczną kopię zaufanego klucza głównego przy użyciu dwóch mechanizmów:

  • Rozszerzasz schemat usługi Active Directory dla Configuration Manager i publikujesz witrynę do Active Directory Domain Services. Następnie klienci pobierają informacje o tej lokacji z serwera wykazu globalnego. Aby uzyskać więcej informacji, zobacz Przygotowywanie usługi Active Directory do publikowania witryn.

  • Podczas instalowania klientów przy użyciu metody instalacji wypychanej klienta. Aby uzyskać więcej informacji, zobacz Instalacja wypychana klienta.

Jeśli klienci nie mogą uzyskać zaufanego klucza głównego przy użyciu jednego z tych mechanizmów, ufają zaufanemu kluczowi głównemu udostępnianemu przez pierwszy punkt zarządzania, z którym komunikują się. W tym scenariuszu klient może zostać błędnie skierowany do punktu zarządzania osoby atakującej, w którym otrzyma zasady z nieautoryzowanego punktu zarządzania. Ta akcja wymaga zaawansowanego atakującego. Ten atak jest ograniczony do krótkiego czasu, zanim klient pobierze zaufany klucz główny z prawidłowego punktu zarządzania. Aby zmniejszyć ryzyko błędnego skierowania klientów przez osobę atakującą do nieautoryzowanego punktu zarządzania, wstępnie aprowizuj klientów przy użyciu zaufanego klucza głównego.

Aby uzyskać więcej informacji i procedur zarządzania zaufanym kluczem głównym, zobacz Konfigurowanie zabezpieczeń.

Podpisywanie i szyfrowanie

W przypadku używania certyfikatów infrastruktury kluczy publicznych dla całej komunikacji z klientem nie trzeba planować podpisywania i szyfrowania w celu zabezpieczenia komunikacji danych klienta. Jeśli skonfigurowano jakiekolwiek systemy lokacji z uruchomionymi usługami IIS w celu zezwalania na połączenia klienta HTTP, zdecyduj, jak pomóc w zabezpieczeniu komunikacji klienta dla lokacji.

Ważna

Począwszy od Configuration Manager wersji 2103, witryny, które zezwalają na komunikację klienta HTTP, są przestarzałe. Skonfiguruj witrynę pod kątem protokołu HTTPS lub rozszerzonego protokołu HTTP. Aby uzyskać więcej informacji, zobacz Włączanie witryny dla protokołu HTTPS lub rozszerzonego protokołu HTTP.

Aby chronić dane wysyłane przez klientów do punktów zarządzania, możesz wymagać od klientów podpisania danych. Możesz również wymagać algorytmu SHA-256 do podpisywania. Ta konfiguracja jest bezpieczniejsza, ale nie wymaga algorytmu SHA-256, chyba że wszyscy klienci ją obsługują. Wiele systemów operacyjnych natywnie obsługuje ten algorytm, ale starsze systemy operacyjne mogą wymagać aktualizacji lub poprawki.

Podczas podpisywania pomaga chronić dane przed naruszeniami, szyfrowanie pomaga chronić dane przed ujawnieniem informacji. Możesz włączyć szyfrowanie danych spisu i komunikatów o stanie wysyłanych przez klientów do punktów zarządzania w lokacji. Nie trzeba instalować żadnych aktualizacji na klientach, aby obsługiwać tę opcję. Klienci i punkty zarządzania wymagają większego użycia procesora CPU na potrzeby szyfrowania i odszyfrowywania.

Uwaga

Aby zaszyfrować dane, klient używa klucza publicznego certyfikatu szyfrowania punktu zarządzania. Tylko punkt zarządzania ma odpowiedni klucz prywatny, więc tylko on może odszyfrować dane.

Klient uruchamia ten certyfikat przy użyciu certyfikatu podpisywania punktu zarządzania, który uruchamia się przy użyciu zaufanego klucza głównego lokacji. Pamiętaj, aby bezpiecznie aprowizować zaufany klucz główny na klientach. Aby uzyskać więcej informacji, zobacz Zaufany klucz główny.

Aby uzyskać więcej informacji na temat konfigurowania ustawień podpisywania i szyfrowania, zobacz Konfigurowanie podpisywania i szyfrowania.

Aby uzyskać więcej informacji na temat algorytmów kryptograficznych używanych do podpisywania i szyfrowania, zobacz Dokumentacja techniczna kontrolek kryptograficznych.

Administracja oparta na rolach

W przypadku Configuration Manager należy użyć administracji opartej na rolach, aby zabezpieczyć dostęp, którego użytkownicy administracyjni muszą używać Configuration Manager. Można również zabezpieczyć dostęp do zarządzanych obiektów, takich jak kolekcje, wdrożenia i lokacje.

Dzięki połączeniu ról zabezpieczeń, zakresów zabezpieczeń i kolekcji należy segregować przypisania administracyjne spełniające wymagania organizacji. Używane razem definiują zakres administracyjny użytkownika. Ten zakres administracyjny steruje obiektami, które użytkownik administracyjny wyświetla w konsoli Configuration Manager, i kontroluje uprawnienia, które użytkownik ma do tych obiektów.

Aby uzyskać więcej informacji, zobacz Podstawy administracji opartej na rolach.

Microsoft Entra ID

Configuration Manager integruje się z identyfikatorem Microsoft Entra, aby umożliwić lokacji i klientom korzystanie z nowoczesnego uwierzytelniania.

Aby uzyskać więcej informacji na temat identyfikatora Microsoft Entra, zobacz dokumentację Microsoft Entra.

Dołączanie witryny przy użyciu identyfikatora Microsoft Entra obsługuje następujące scenariusze Configuration Manager:

Scenariusze klienta

Scenariusze serwera

Uwierzytelnianie dostawcy programu SMS

Możesz określić minimalny poziom uwierzytelniania dla administratorów, aby uzyskać dostęp do Configuration Manager witryn. Ta funkcja wymusza, aby administratorzy logowali się do systemu Windows z wymaganym poziomem, zanim będą mogli uzyskać dostęp do Configuration Manager. Dotyczy ona wszystkich składników uzyskujących dostęp do dostawcy programu SMS. Na przykład konsola Configuration Manager, metody zestawu SDK i polecenia cmdlet Windows PowerShell.

Configuration Manager obsługuje następujące poziomy uwierzytelniania:

  • Uwierzytelnianie systemu Windows: wymagaj uwierzytelniania przy użyciu poświadczeń domeny usługi Active Directory. To ustawienie jest poprzednim zachowaniem i bieżącym ustawieniem domyślnym.

  • Uwierzytelnianie certyfikatu: wymagaj uwierzytelniania z prawidłowym certyfikatem wystawionym przez zaufany urząd certyfikacji PKI. Nie konfigurujesz tego certyfikatu w Configuration Manager. Configuration Manager wymaga zalogowania administratora do systemu Windows przy użyciu infrastruktury kluczy publicznych.

  • uwierzytelnianie Windows Hello dla firm: wymagaj uwierzytelniania przy użyciu silnego uwierzytelniania dwuskładnikowego powiązanego z urządzeniem i używającego danych biometrycznych lub numeru PIN. Aby uzyskać więcej informacji, zobacz Windows Hello dla firm.

    Ważna

    Po wybraniu tego ustawienia dostawca programu SMS i usługa administracyjna wymagają, aby token uwierzytelniania użytkownika zawierał oświadczenie uwierzytelniania wieloskładnikowego (MFA) z Windows Hello dla firm. Innymi słowy, użytkownik konsoli, zestawu SDK, programu PowerShell lub usługi administracyjnej musi uwierzytelnić się w systemie Windows przy użyciu Windows Hello dla firm numeru PIN lub danych biometrycznych. W przeciwnym razie witryna odrzuca akcję użytkownika.

    To zachowanie dotyczy Windows Hello dla firm, a nie Windows Hello.

Aby uzyskać więcej informacji na temat konfigurowania tego ustawienia, zobacz Konfigurowanie uwierzytelniania dostawcy programu SMS.

Następne kroki