Planowanie bezpieczeństwa w programie Configuration Manager

 

Dotyczy: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1

Poniższe informacje pomogą w planowaniu zabezpieczeń w programie Microsoft System Center 2012 Configuration Manager.

  • Planowanie certyfikatów (z podpisem własnym i PKI)

    • Planowanie odwoływania certyfikatów PKI

    • Planowanie zaufanych certyfikatów głównych PKI i listy wystawców certyfikatów

    • Planowanie wyboru certyfikatu klienta PKI

    • Planowanie strategii przejścia dla certyfikatów PKI i internetowego zarządzania klientami

  • Planowanie zaufanego klucza głównego

  • Planowanie podpisywania i szyfrowania

  • Planowanie administracji opartej na rolach

Oprócz powyższych sekcji warto także zapoznać się z tematem Bezpieczeństwo i ochrona prywatności dotyczące administrowania lokacją w programie Configuration Manager.

Dodatkowe informacje o tym, w jaki sposób program Menedżer konfiguracji korzysta z certyfikatów i funkcji kryptograficznych, znajdują się w temacie Informacje techniczne dotyczące formantów kryptograficznych używanych w programie Configuration Manager.

Planowanie certyfikatów (z podpisem własnym i PKI)

Program Menedżer konfiguracji korzysta z kombinacji certyfikatów z podpisem własnym i certyfikatów infrastruktury kluczy publicznych (PKI).

W ramach najlepszych praktyk w dziedzinie zabezpieczeń doradzamy korzystanie z certyfikatów PKI zawsze, o ile to tylko możliwe. Więcej informacji o wymaganiach dotyczących certyfikatów PKI znajduje się w temacie Wymagania dotyczące certyfikatu PKI dla programu Configuration Manager. Kiedy program Menedżer konfiguracji żąda certyfikatów PKI, na przykład podczas rejestracji urządzeń przenośnych i udostępniania AMT, należy użyć usług domenowych Active Directory i urzędu certyfikacji przedsiębiorstwa. W przypadku wszelkich innych certyfikatów PKI należy wdrażać je i zarządzać nimi niezależnie od programu Menedżer konfiguracji.

Certyfikaty PKI są także wymagane do łączenia się komputerów klienckich z internetowymi systemami lokacji i zaleca się ich używanie, kiedy klienci łączą się z systemami lokacji, w których działają usługi Internet Information Services (IIS). Więcej informacji o komunikacji z klientami znajduje się w temacie Planowanie komunikacji z klientem w programie Configuration Manager.

Korzystając z certyfikatów PKI, można korzystać także z protokołu IPsec, aby pomóc w zabezpieczaniu komunikacji między serwerami w ramach tej samej lokacji i między lokacjami, a także w każdej innej sytuacji wiążącej się z transferem danych między komputerami. Protokół IPsec należy skonfigurować i zainstalować niezależnie od programu Menedżer konfiguracji.

Kiedy certyfikaty PKI są niedostępne, program Menedżer konfiguracji może automatycznie generować certyfikaty z podpisem własnym, a niektóre certyfikaty w programie Menedżer konfiguracji są zawsze z podpisem własnym. W większości wypadków program Menedżer konfiguracji automatycznie zarządza certyfikatami z podpisem własnym, co nie wymaga podejmowania żadnych dodatkowych działań. Jeden z dopuszczalnych wyjątków stanowi certyfikat podpisywania serwera lokacji. Certyfikat podpisywania serwera lokacji jest zawsze z podpisem własnym; gwarantuje on, że zasady klienta pobierane przez klientów z punktu zarządzania zostały faktycznie wysłane z serwera lokacji i nie zostały przez nikogo naruszone.

Planowanie certyfikatu podpisywania serwera lokacji (z podpisem własnym)

Klienci mogą w bezpieczny sposób uzyskać kopię certyfikatu podpisywania serwera lokacji z usług domenowych Active Directory i z instalacji wypychanej klienta. Jeśli klienci nie mogą uzyskać kopii certyfikatu podpisywania serwera lokacji za pomocą jednego z tych mechanizmów, to w ramach najlepszych praktyk w dziedzinie bezpieczeństwa zaleca się instalowanie kopii certyfikatu podpisywania serwera lokacji podczas instalowania klienta. Jest to szczególnie istotne, jeśli klient nawiązuje komunikację z daną lokacją po raz pierwszy przez Internet, ponieważ punkt zarządzania jest wtedy połączony z siecią niezaufaną i w związku z tym narażony na atak. W przypadku niepodjęcia tego dodatkowego kroku klienci automatycznie pobierają kopię certyfikatu podpisywania serwera lokacji z punktu zarządzania.

Scenariusze, w których klienci nie mogą w sposób bezpieczny uzyskać kopii certyfikatu serwera lokacji, obejmują następujące sytuacje:

  • Klient nie jest instalowany metodą wypychania klienta i jest spełniony dowolny z następujących warunków:

    • Schemat usługi Active Directory nie jest rozszerzony do programu Menedżer konfiguracji.

    • Lokacja klienta nie jest publikowana w usługach domenowych Active Directory.

    • Klient pochodzi z niezaufanego lasu lub grupy roboczej.

  • Klient jest instalowany w trakcie połączenia z Internetem.

Poniższa procedura służy do instalowania klientów wraz z kopią certyfikatu podpisywania serwera lokacji.

Aby zainstalować klientów wraz z kopią certyfikatu podpisywania serwera lokacji

  1. Znajdź certyfikat podpisywania serwera lokacji na serwerze lokacji głównej klienta. Certyfikat jest przechowywany w magazynie certyfikatów SMS i ma przypisaną nazwę podmiotu Serwer lokacji oraz przyjazną nazwę Certyfikat podpisywania serwera lokacji.

  2. Wyeksportuj certyfikat bez klucza prywatnego, składując plik w sposób bezpieczny i uzyskując do niego dostęp tylko z kanału zabezpieczonego (na przykład korzystając z podpisywania protokołu SMB lub z protokołu IPsec).

  3. Zainstaluj klienta, używając z programem CCMSetup.exe właściwości pakietu Client.msi SMSSIGNCERT=<pełna ścieżka i nazwa pliku>.

Planowanie odwoływania certyfikatów PKI

W przypadku korzystania z certyfikatów PKI w programie Menedżer konfiguracji należy zaplanować, czy i w jaki sposób klienci i serwery będą korzystać z listy odwołania certyfikatów (listy CRL, od ang. Certificate Revocation List) w celu weryfikowania certyfikatu na łączącym się z nimi komputerze. Lista odwołania certyfikatów (lista CRL) to plik utworzony i podpisany przez urząd certyfikacji; plik ten zawiera listę certyfikatów wystawionych przez urząd certyfikacji, ale odwołanych. Certyfikaty mogą być odwoływane przez administratora urzędu certyfikacji, na przykład jeśli o wystawionym certyfikacie wiadomo lub podejrzewa się, że został naruszony.

System_CAPS_importantWażne

Ponieważ lokalizacja listy CRL jest dodawana do certyfikatu w momencie wystawienia go przez urząd certyfikacji, należy pamiętać o zaplanowaniu listy CRL jeszcze przed wdrożeniem jakichkolwiek certyfikatów PKI, które będą używane w programie Menedżer konfiguracji.

Domyślnie usługi IIS zawsze sprawdzają listę CRL pod kątem certyfikatów klienta i jest to konfiguracja, której nie można zmienić w programie Menedżer konfiguracji. Domyślnie klienci programu Menedżer konfiguracji zawsze sprawdzają listę CRL pod kątem systemów lokacji; to ustawienie można jednak wyłączyć, określając właściwość lokacji i właściwość programu CCMSetup. W przypadku zarządzania poza pasmem komputerami opartymi na technologii AMT firmy Intel można także włączyć sprawdzanie listy CRL pod kątem punktu obsługi poza pasmem i komputerów z uruchomioną konsolą zarządzania poza pasmem.

Jeśli komputery korzystają ze sprawdzania odwołań certyfikatów, ale nie mogą zlokalizować listy CRL, to zachowują się tak, jakby wszystkie certyfikaty w łańcuchu certyfikacji były odwołane, bo ich braku na liście CRL nie da się zweryfikować. W tej sytuacji wszystkie połączenia wymagające certyfikatów i korzystające z listy CRL kończą się niepowodzeniem.

Sprawdzanie listy CRL przy każdorazowym użyciu certyfikatu zapewnia lepszą ochronę przed potencjalnym użyciem odwołanego certyfikatu, jednak wprowadza opóźnienie komunikacji i konieczność dodatkowego przetwarzania danych na kliencie. To dodatkowe wymaganie sprawdzania zabezpieczeń wydaje się bardziej pożądane, kiedy klienci znajdują się w Internecie lub w sieci niezaufanej.

Przed podjęciem decyzji o tym, czy klienci programu Menedżer konfiguracji mają sprawdzać listę CRL, skonsultuj się z administratorami infrastruktury PKI, po czym pomyśl o pozostawieniu tej opcji włączonej w programie Menedżer konfiguracji, kiedy spełnione są obydwa poniższe warunki:

  • Infrastruktura PKI obsługuje listę CRL, a ta jest publikowana w miejscu, w którym mogą ją odnaleźć wszyscy klienci programu Menedżer konfiguracji. Pamiętaj, że mogą być wśród nich także klienci z Internetu, jeśli korzystasz z internetowego zarządzania klientami, oraz klienci z lasów niezaufanych.

  • Wymaganie sprawdzania listy CRL w przypadku każdego połączenia z systemem lokacji skonfigurowanego do korzystania z certyfikatu PKI ma większe znaczenie niż wymaganie szybszych połączeń i wydajnego przetwarzania na kliencie czy ryzyko nienawiązywania połączeń z serwerami przez klientów niemogących odnaleźć listy CRL.

Planowanie zaufanych certyfikatów głównych PKI i listy wystawców certyfikatów

Jeśli w danych systemach lokacji z usługami IIS wykorzystuje się certyfikaty PKI klienta do uwierzytelniania klientów w połączeniach HTTP lub uwierzytelniania klientów i szyfrowania w połączeniach HTTPS, może zajść potrzeba zaimportowania certyfikatów głównego urzędu certyfikacji jako właściwości lokacji. Może tak być w jednej z dwu sytuacji:

  • Podczas wdrażania systemów operacyjnych za pomocą programu Menedżer konfiguracji punkty zarządzania akceptują tylko połączenia klienckie HTTPS.

  • Używane są certyfikaty PKI klienta, które nie łączą się w łańcuch zaufania z certyfikatem głównego urzędu certyfikacji zaufanym z perspektywy punktów zarządzania.

    Uwaga

    W przypadku wystawiania certyfikatów PKI klienta z tej samej hierarchii urzędu certyfikacji, która wystawia certyfikaty serwera wykorzystywane przez punkty zarządzania, nie ma potrzeby określania tego certyfikatu głównego urzędu certyfikacji. Jeśli jednak korzysta się z wielu hierarchii urzędów certyfikacji i nie ma się pewności, czy ufają one sobie wzajemnie, należy zaimportować główny urząd certyfikacji do hierarchii urzędu certyfikacji klientów.

Jeśli zachodzi konieczność importu certyfikatów głównego urzędu certyfikacji do programu Menedżer konfiguracji, należy je wyeksportować z wystawiającego je urzędu certyfikacji lub z komputera klienta. W przypadku eksportowania certyfikatu z wystawiającego go urzędu certyfikacji, który jest przy tym głównym urzędem certyfikacji, należy zwrócić uwagę, żeby nie został wyeksportowany klucz prywatny. Aby zabezpieczyć plik wyeksportowanego certyfikatu przed naruszeniem, należy zadbać o składowanie go w bezpiecznym miejscu. Do pliku należy mieć dostęp podczas konfigurowania lokacji, jeśli więc jest to dostęp za pośrednictwem sieci, należy zadbać o ochronę komunikacji przed naruszeniami poprzez zastosowanie podpisywania protokołu SMB lub użycie protokołu IPsec.

Jeśli którekolwiek z zaimportowanych certyfikatów głównego urzędu certyfikacji zostaną odnowione, należy je zaimportować.

Te zaimportowane certyfikaty głównego urzędu certyfikacji wraz z głównym urzędem certyfikacji każdego punktu zarządzania tworzą listę wystawców certyfikatów, której komputery w programie Menedżer konfiguracji używają w następujący sposób:

  • Kiedy klienci łączą się z punktami zarządzania, punkt zarządzania weryfikuje, że certyfikat klienta tworzy łańcuch z zaufanym certyfikatem głównym z listy wystawców certyfikatów danej lokacji. Jeśli tak nie jest, certyfikat zostaje odrzucony, a połączenie PKI nie zostaje nawiązane.

  • Kiedy klienci wybierają certyfikat PKI, to jeśli dysponują listą wystawców certyfikatów, wybierają certyfikat, który tworzy łańcuch z zaufanym certyfikatem głównym z listy wystawców certyfikatów. Jeśli nie ma dopasowania, klient nie wybiera certyfikatu PKI. Aby uzyskać więcej informacji o procesie certyfikatu klienta, zapoznaj się z sekcją Planowanie wyboru certyfikatu klienta PKI w tym temacie.

Niezależnie od konfiguracji lokacji może zajść konieczność zaimportowania certyfikatu głównego urzędu certyfikacji podczas rejestrowania urządzeń przenośnych lub komputerów Mac, a także udostępniania komputerów opartych na technologii AMT firmy Intel pod kątem sieci bezprzewodowych.

Planowanie wyboru certyfikatu klienta PKI

Jeśli w danych systemach lokacji z usługami IIS wykorzystuje się certyfikaty PKI klienta do uwierzytelniania klientów w połączeniach HTTP lub uwierzytelniania klientów i szyfrowania w połączeniach HTTPS, należy zaplanować, jak klienci z systemem Windows będą wybierali certyfikat na użytek programu Menedżer konfiguracji.

Uwaga

Nie wszystkie urządzenia obsługują metodę wyboru certyfikatu i zamiast z niej korzystać, automatycznie wybierają pierwszy certyfikat spełniający wymagania certyfikatu. Metody wyboru certyfikatu nie obsługują na przykład klienci na komputerach Mac i na urządzeniach przenośnych.

W wielu przypadkach domyślna konfiguracja i domyślne zachowanie okażą się wystarczające. Klient programu Menedżer konfiguracji na komputerach z systemem Windows filtruje większą liczbę certyfikatów, posługując się następującymi kryteriami:

  1. Lista wystawców certyfikatów: certyfikat tworzy łańcuch z głównym urzędem certyfikacji, który jest zaufany z perspektywy punktu zarządzania.

  2. Certyfikat znajduje się w domyślnym magazynie certyfikatów o nazwie Osobisty.

  3. Certyfikat jest ważny, nieodwołany i niewygasły. Sprawdzanie ważności polega m.in. na weryfikacji, że klucz prywatny jest dostępny i że certyfikatu nie utworzono za pomocą wersji 3 szablonu certyfikatu, niezgodnej z programem Menedżer konfiguracji.

  4. Certyfikat ma zdolność uwierzytelniania klienta lub jest wystawiony dla komputera o określonej nazwie.

  5. Certyfikat ma najdłuższy okres ważności.

Klientów można skonfigurować do korzystania z listy wystawców certyfikatów następującymi metodami:

  • Lista jest publikowana jako informacje o lokacji programu Menedżer konfiguracji w usługach domenowych Active Directory.

  • Klienci są instalowani przy użyciu instalacji wypychanej klienta.

  • Po pomyślnym przypisaniu do swojej lokacji klienci pobierają listę z punktu zarządzania.

  • Lista jest określana podczas instalacji klienta, jako właściwość CCMCERTISSUERS pakietu client.msi w programie CCMSetup.

Jeśli klienci nie dysponują listą wystawców certyfikatów podczas swojej pierwszej instalacji, a nie są jeszcze przypisani do lokacji, pomijają tę procedurę sprawdzania. Jeśli dysponują listą wystawców certyfikatów, ale nie mają certyfikatu PKI, który tworzyłby łańcuch z zaufanym certyfikatem głównym z listy wystawców certyfikatów, to wybór certyfikatu kończy się niepowodzeniem, a klienci nie kontynuują wybierania certyfikatu na podstawie innych kryteriów wyboru.

W większości wypadków klient programu Menedżer konfiguracji prawidłowo identyfikuje unikatowy i właściwy certyfikat PKI przeznaczony do użycia. Jeśli jednak dzieje się inaczej, to zamiast wybierać certyfikat na podstawie zdolności klienta do uwierzytelnienia, można skonfigurować dwie alternatywne metody wyboru:

  • Częściowe dopasowanie ciągu do nazwy podmiotu certyfikatu klienta. To dopasowanie, które nie uwzględnia wielkości liter, jest odpowiednie w przypadku użycia w polu podmiotu nazwy komputera wyrażonej jako w pełni kwalifikowana nazwa domeny (nazwa FQDN), gdy chce się wybrać certyfikat na podstawie sufiksu domeny, na przykład contoso.com. Można jednak wykorzystać tę metodę wyboru do identyfikacji w nazwie podmiotu certyfikatu dowolnego ciągu znaków wyróżniającego dany certyfikat spośród innych składowanych w magazynie certyfikatów klienta.

    Uwaga

    W ramach ustawienia lokacji nie można określić częściowego dopasowania ciągu w alternatywnej nazwie podmiotu (SAN). Częściowe dopasowanie ciągu można określić dla nazwy SAN przy użyciu programu CCMSetup, lecz zostanie on zastąpiony przez właściwości lokacji w następujących scenariuszach:

    • Klienci pobierają informacje o lokacji publikowane w usługach domenowych Active Directory.

    • Klienci zostali zainstalowani przy użyciu instalacji wypychanej klienta.

    Częściowo dopasowany ciąg można określić w nazwie SAN tylko w przypadku ręcznego instalowania klientów, którzy nie pobierają informacji o lokacji z usług domenowych Active Directory. Te warunki dotyczą na przykład tylko klientów internetowych.

  • Dopasowanie w wartościach atrybutów nazwy podmiotu lub alternatywnej nazwy podmiotu (SAN) certyfikatu klienta. To jest dopasowanie uwzględniające wielkość liter odpowiednie w przypadku używania nazwy wyróżniającej X500 lub odpowiednich identyfikatorów OID (identyfikatory obiektów) zgodnych ze standardem RFC 3280, gdy użytkownik chce wybrać certyfikat na podstawie wartości atrybutów. Istnieje możliwość określenia tylko atrybutów i ich wartości wymaganych do jednoznacznej identyfikacji lub weryfikacji certyfikatu i odróżnienia go od innych certyfikatów w magazynie.

Poniższa tabela zawiera wartości atrybutów obsługiwane przez program Menedżer konfiguracji w ramach kryteriów wyboru certyfikatu klienta.

Atrybut identyfikatora OID

Atrybut nazwy wyróżniającej

Definicja atrybutu

0.9.2342.19200300.100.1.25

DC

Składnik domeny

1.2.840.113549.1.9.1

E lub E-mail

Adres e-mail

2.5.4.3

CN

Nazwa pospolita

2.5.4.4

SN

Nazwa podmiotu

2.5.4.5

SERIALNUMBER

Numer seryjny

2.5.4.6

C

Kod kraju

2.5.4.7

L

Miejscowość

2.5.4.8

S lub ST

Nazwa województwa

2.5.4.9

STREET

Ulica

2.5.4.10

O

Nazwa organizacji

2.5.4.11

OU

Jednostka organizacyjna

2.5.4.12

T lub Title

Tytuł

2.5.4.42

G lub GN lub GivenName

Imię

2.5.4.43

I lub Initials

Inicjały

2.5.29.17

(brak wartości)

Alternatywna nazwa podmiotu

Jeżeli po zastosowaniu kryteriów wyboru zostanie zlokalizowany więcej niż jeden odpowiedni certyfikatów, można zastąpić domyślną konfigurację, aby wybrać certyfikat o najdłuższym okresie ważności, i określić brak wybranego certyfikatu. W tym scenariuszu klient nie będzie mógł się komunikować z systemami lokacji usług IIS przy użyciu certyfikatu PKI. Klient wysyła do przypisanego mu rezerwowego punktu stanu komunikat o błędzie, aby ostrzec użytkownika o nieprawidłowym wyborze certyfikatu. Dzięki temu można zmodyfikować lub uściślić kryteria wyboru certyfikatu. W takim przypadku zachowanie klienta zależy od tego, czy nie powiodło się połączenie za pośrednictwem protokołu HTTPS czy HTTP:

  • Jeżeli nie powiodło się połączenie za pośrednictwem protokołu HTTPS: klient próbuje nawiązać połączenie za pośrednictwem protokołu HTTP i używa certyfikatu klienta z podpisem własnym.

  • Jeżeli nie powiodło się połączenie za pośrednictwem protokołu HTTP: klient próbuje nawiązać kolejne połączenie za pośrednictwem protokołu HTTP przy użyciu certyfikatu klienta z podpisem własnym.

Aby ułatwić identyfikację unikatowego certyfikatu klienta PKI, można również określić magazyn niestandardowy, inny niż domyślny Osobisty w magazynie Komputer. Jednak należy utworzyć ten magazyn niezależnie od programu Menedżer konfiguracji, aby umożliwić wdrażanie certyfikatów do tego magazynu niestandardowego i odnawianie ich przed upływem okresu ważności.

Informacje na temat konfigurowania ustawień dla certyfikatów klienta zawiera sekcja Konfigurowanie ustawień certyfikatów PKI klienta w temacie Konfigurowanie zabezpieczeń w programie Configuration Manager.

Planowanie strategii przejścia dla certyfikatów PKI i internetowego zarządzania klientami

Elastyczne opcje konfiguracji w programie Menedżer konfiguracji umożliwiają stopniowe przejście klientów oraz lokacji do używania certyfikatów PKI, aby ułatwić zabezpieczenie punktów końcowych klienta. Certyfikaty PKI zapewniają większy poziom zabezpieczeń i umożliwiają zarządzanie klientami połączonymi z Internetem.

Ze względu na liczbę opcji konfiguracji i dostępnych wyborów w programie Menedżer konfiguracji nie istnieje jeden sposób na przejście lokacji, aby wszyscy klienci używali połączeń HTTPS. W razie potrzeby postępuj zgodnie z następującymi wskazówkami:

  1. Zainstaluj lokację programu Menedżer konfiguracji i skonfiguruj ją tak, aby systemy lokacji akceptowały połączenia klienta za pośrednictwem protokołów HTTPS i HTTP.

  2. Skonfiguruj ustawienia na karcie Komunikacja komputera klienckiego we właściwościach lokacji, wybierając w obszarze Ustawienia systemu lokacji opcję HTTP lub HTTPS, a następnie zaznacz pole wyboru Użyj certyfikatu klienta PKI (możliwość uwierzytelniania klienta), jeśli jest dostępny. Skonfiguruj na tej karcie inne wymagane ustawienia. Więcej informacji znajduje się w sekcji Konfigurowanie ustawień certyfikatów PKI klienta w temacie Konfigurowanie zabezpieczeń w programie Configuration Manager.

  3. Przeprowadź wdrożenie certyfikatów PKI klienta. Przykład wdrożenia zawiera sekcja Wdrażanie certyfikatu klienta na komputerach z systemem Windows w temacie Przykład krok po kroku wdrożenia certyfikatów PKI dla programu Configuration Manager: Urząd certyfikacji systemu Windows Server 2008.

  4. Zainstaluj klientów przy użyciu metody instalacji wypychanej klienta. Więcej informacji znajduje się w sekcji Jak instalować klientów programu Configuration Manager za pomocą instalacji wypychanej klienta w temacie Jak zainstalować klientów na komputerach z systemem Windows w programie Configuration Manager.

  5. Monitoruj wdrożenie klienta i stan za pomocą raportów i informacji w konsoli programu Menedżer konfiguracji.

  6. Sprawdź liczbę klientów używających certyfikatu PKI klienta, wyświetlając w obszarze roboczym Zasoby i zgodność w węźle Urządzenia kolumnę Certyfikat klienta.

    Na komputerach można również wdrożyć narzędzie oceny gotowości protokołu HTTPS programu Menedżer konfiguracji (cmHttpsReadiness.exe) i sprawdzić za pomocą raportów liczbę komputerów, które mogą używać certyfikatu PKI klienta w programie Menedżer konfiguracji.

    Uwaga

    Podczas instalacji klienta programu Menedżer konfiguracji na komputerach klienckich narzędzie cmHttpsReadiness.exe jest instalowane w folderze %windir%\CCM. Po uruchomieniu tego narzędzia w klientach można określić następujące opcje:

    • /Store:<nazwa>

    • /Issuers:<lista>

    • /Criteria:<kryteria>

    • /SelectFirstCert

    Te opcje mapują odpowiednio do właściwości pliku Client.msi CCMCERTSTORE, CCMCERTISSUERS, CCMCERTSEL i CCMFIRSTCERT. Więcej informacji o tych opcjach znajduje się w temacie Informacje o właściwościach instalacji klientów w programie Configuration Manager.

  7. Po upewnieniu się, że odpowiednia liczba klientów pomyślnie używa certyfikatu PKI klienta do uwierzytelniania za pośrednictwem protokołu HTTP, wykonaj następujące czynności:

    1. Wdróż certyfikat serwera sieci Web PKI do serwera członkowskiego, który będzie obsługiwał dodatkowy punkt zarządzania dla lokacji, a następnie skonfiguruj ten certyfikat w usługach IIS. Więcej informacji znajduje się w sekcji Wdrażanie certyfikatu serwera sieci Web dla systemów lokacji z usługami IIS w temacie Przykład krok po kroku wdrożenia certyfikatów PKI dla programu Configuration Manager: Urząd certyfikacji systemu Windows Server 2008.

    2. Zainstaluj na tym serwerze rolę punktu zarządzania i skonfiguruj opcję Połączenia klientów we właściwościach punktu zarządzania w ramach protokołu HTTPS.

  8. Przeprowadź monitorowanie i sprawdź, czy klienci z certyfikatem PKI używają nowego punktu zarządzania za pośrednictwem protokołu HTTPS. W tym celu można użyć liczników wydajności lub rejestrowania usług IIS.

  9. Zmień konfigurację innych ról systemu lokacji, aby używały połączeń klientów za pośrednictwem protokołu HTTPS. Aby zarządzać klientami przez Internet, upewnij się, że systemy lokacji mają przypisane w pełni kwalifikowane nazwy domen internetowych i skonfiguruj indywidualne punkty zarządzania oraz punktu dystrybucji, aby akceptowały połączenia z Internetu.

    System_CAPS_importantWażne

    Przed skonfigurowaniem ról systemu lokacji w celu akceptowania połączeń z Internetu sprawdź informacje o planowaniu i wymagania wstępne dotyczące internetowego zarządzania klientami. Więcej informacji znajduje się w sekcji Planowanie internetowego zarządzania klientami w temacie Planowanie komunikacji w programie Configuration Manager.

  10. Rozszerz wdrożenie certyfikatu PKI dla klientów i systemu lokacji z uruchomionymi usługami IIS, a następnie w razie potrzeby skonfiguruj role systemu lokacji do połączeń klientów za pośrednictwem protokołu HTTPS i połączeń internetowych.

  11. Aby zapewnić optymalny poziom zabezpieczeń: po uprawnieniu się, że wszyscy klienci używają certyfikatu PKI do uwierzytelniania i szyfrowania, zmień właściwości lokacji, aby używać tylko protokołu HTTPS.

Wykonanie tego planu w celu stopniowego wprowadzenia certyfikatów PKI, najpierw do uwierzytelniania tylko za pośrednictwem protokołu HTTP, a następnie do uwierzytelniania i szyfrowania za pośrednictwem protokołu HTTPS, ogranicza ryzyko przerwania zarządzania klientami. Ponadto umożliwi to zastosowanie optymalnych zabezpieczeń obsługiwanych przez program Menedżer konfiguracji.

Planowanie zaufanego klucza głównego

Zaufany klucz główny programu Menedżer konfiguracji zapewnia klientom programu Menedżer konfiguracji mechanizm umożliwiający sprawdzenie, czy systemy lokacji należą do ich hierarchii. Każdy serwer lokacji generuje klucz wymiany lokacji do komunikowania się z innymi lokacjami. Klucz wymiany lokacji z lokacji najwyższego poziomu w hierarchii jest nazywany zaufanym kluczem głównym.

Zaufany klucz główny w programie Menedżer konfiguracji pełni podobną funkcję do certyfikatu głównego w infrastrukturze kluczy publicznych, tzn. wszystkie elementy podpisane przez klucz prywatny zaufanego klucza głównego są objęte zaufaniem na wszystkich poziomach hierarchii. Na przykład dzięki podpisaniu certyfikatu punktu zarządzania za pomocą klucza prywatnego pary zaufanych kluczy głównych i udostępnieniu kopii tej pary kluczy klientom mogą oni odróżnić punkty zarządzania należące do ich hierarchii od punktów, które do niej nie należą. Klienci przechowują kopię zaufanego klucza głównego w obszarze nazw root\ccm\locationservices za pomocą usługi WMI.

Klienci mogą automatycznie pobierać publiczną kopię zaufanego klucza głównego przy użyciu dwóch następujących mechanizmów:

  • Schemat usługi Active Directory zostaje rozszerzony dla programu Menedżer konfiguracji, lokacja jest publikowana w usługach domenowych Active Directory i klienci mogą pobierać informacje o tej lokacji z serwera wykazu globalnego.

  • Klienci są instalowani przy użyciu instalacji wypychanej klienta.

Jeżeli klienci nie mogą pobrać zaufanego klucza głównego przy użyciu jednego z tych mechanizmów, ufają kluczowi dostarczonemu przez pierwszy punkt zarządzania, z którym nawiążą połączenie. W tym scenariuszu klient może zostać nieprawidłowo skierowany do punktu zarządzania osoby atakującej, z którego może pobrać zasady z nieautoryzowanego punktu zarządzania. To może być działanie doświadczonej osoby atakującej i może zdarzyć się tylko w ograniczonym czasie zanim klient pobierze zaufany klucz główny z prawidłowego punktu zarządzania. Jednak w celu ograniczenia tego ryzyka nieprawidłowego skierowania klientów do nieautoryzowanego punktu zarządzania można wstępnie udostępnić klientom zaufany klucz główny.

Zastosuj poniższe procedury, aby wstępnie udostępnić i sprawdzić zaufany klucz główny dla klienta programu Menedżer konfiguracji:

  • Wstępnie udostępnij klientowi zaufany klucz główny przy użyciu pliku.

  • Wstępnie udostępnij klientowi zaufany klucz główny bez użycia pliku.

  • Sprawdź zaufany klucz główny w kliencie.

Uwaga

Nie trzeba wstępnie udostępniać klientom zaufanego klucza głównego, gdy mogą go uzyskać z usług domenowych Active Directory lub zostali zainstalowani za pomocą instalacji wypychanej klienta. Ponadto nie ma konieczności przeprowadzania wstępnego udostępniania, gdy klienci komunikują się z punktami zarządzania za pośrednictwem protokołu HTTPS, ponieważ w tym przypadku zaufanie jest ustanawiane przy użyciu certyfikatów PKI.

Zaufany klucz główny można usunąć z klienta przy użyciu właściwości RESETKEYINFORMATION = TRUE pliku Client.msi za pomocą programu CCMSetup.exe. Aby zastąpić zaufany klucz główny, zainstaluj ponownie klienta wraz z nowym zaufanym kluczem głównym, na przykład używając instalacji wypychanej klienta lub określając właściwość SMSPublicRootKey pliku Client.msi za pomocą programu CCMSetup.exe.

Aby wstępnie udostępnić klientowi zaufany klucz główny przy użyciu pliku

  1. W edytorze tekstu otwórz plik <katalog programu Configuration Manager>\bin\mobileclient.tcf.

  2. Znajdź wpis SMSPublicRootKey=, skopiuj klucz z tego wiersza i zamknij plik bez wprowadzania żadnych zmian.

  3. Utwórz nowy plik tekstowy i wklej do niego informacje o kluczu skopiowane z pliku mobileclient.tcf.

  4. Zapisz plik i umieść go w lokalizacji dostępnej dla wszystkich komputerów, w której plik będzie zabezpieczony przed manipulacjami.

  5. Zainstaluj klienta przy użyciu metody odpowiedniej dla właściwości pliku Client.msi, a następnie określ właściwość pliku Client.msi SMSROOTKEYPATH=<pełna ścieżka i nazwa pliku>.

    System_CAPS_importantWażne

    W przypadku określenia podczas instalacji klienta zaufanego klucza głównego w celu zapewnienia dodatkowych zabezpieczeń należy również określić kod lokacji, używając właściwości pliku Client.msi SMSSITECODE=<kod lokacji>.

Aby wstępnie udostępnić klientowi zaufany klucz główny bez użycia pliku

  1. W edytorze tekstu otwórz plik <katalog programu Configuration Manager>\bin\mobileclient.tcf.

  2. Znajdź wpis SMSPublicRootKey=, zanotuj klucz z tego wiersza lub skopiuj go do schowka, a następnie zamknij plik bez wprowadzania żadnych zmian.

  3. Zainstaluj klienta przy użyciu metody odpowiedniej dla właściwości pliku Client.msi, a następnie określ właściwość pliku Client.msi SMSPublicRootKey=<klucz>, gdzie <klucz> to ciąg skopiowany z pliku mobileclient.tcf.

    System_CAPS_importantWażne

    W przypadku określenia podczas instalacji klienta zaufanego klucza głównego w celu zapewnienia dodatkowych zabezpieczeń należy również określić kod lokacji, używając właściwości pliku Client.msi SMSSITECODE=<kod lokacji>.

Aby sprawdzić zaufany klucz główny w kliencie

  1. W menu Start kliknij pozycję Uruchom, a następnie wpisz Wbemtest.

  2. W oknie dialogowym Tester oprzyrządowania Instrumentacji zarządzania Windows kliknij przycisk Połącz.

  3. W oknie dialogowym Łączenie w polu Obszar nazw wpisz ścieżkę root\ccm\locationservices, a następnie kliknij przycisk Połącz.

  4. W oknie dialogowym Tester oprzyrządowania Instrumentacji zarządzania Windows w sekcji IWbemServices kliknij przycisk Wylicz klasy.

  5. W oknie dialogowym Informacje o superklasie wybierz opcję Cykliczne, a następnie kliknij przycisk OK.

  6. W oknie Wynik kwerendy przewiń listę do końca, a następnie kliknij dwukrotnie pozycję TrustedRootKey ().

  7. W oknie dialogowym Edytor obiektów dla TrustedRootKey kliknij pozycję Wystąpienia.

  8. W nowym oknie Wynik kwerendy zawierającym wystąpienia obiektu TrustedRootKey kliknij dwukrotnie pozycję TrustedRootKey=@.

  9. W oknie dialogowym Edytor obiektów dla TrustedRootKey=@ w sekcji Właściwości przewiń ekran w dół do pozycji TrustedRootKey CIM_STRING. Ciąg w prawej kolumnie to zaufany klucz główny. Sprawdź, czy jest on zgodny z wartością SMSPublicRootKey w pliku <katalog programu Configuration Manager>\bin\mobileclient.tcf.

Planowanie podpisywania i szyfrowania

Gdy certyfikat PKI jest używany do całej komunikacji z klientem, nie trzeba planować podpisywania i szyfrowania korespondencji w celu zabezpieczenia danych klienta. Jednak przy konfiguracji systemów lokacji, w których serwer IIS zezwala na połączenia klienckie z użyciem protokołu HTTP, musisz zdecydować, jak zabezpieczyć komunikację z klientem w danej lokacji.

Aby ułatwić ochronę danych wysyłanych przez klientów do punktów zarządzania, można wymóc ich podpisywanie. Dodatkowo można wymóc, aby wszystkie podpisane dane z klientów używających protokołu HTTP zostały podpisane algorytmem SHA-256. Choć to bezpieczniejsze ustawienie, to nie należy go włączać, jeśli wszyscy klienci nie obsługują tego protokołu. Wiele systemów operacyjnych obsługuje go natywnie, lecz w starszych konieczna może być aktualizacja lub instalacja odpowiedniej poprawki. Przykładowo w komputerach z systemem Windows Server 2003 SP2 trzeba zainstalować poprawkę hotfix, do której podano odwołanie w artykule KB 938397.

Podpisywanie chroni dane przed naruszeniem, a szyfrowanie utrudnia ujawnienie informacji. Istnieje możliwość włączenia szyfrowania algorytmem 3DES dla danych spisu oraz komunikatów o stanie wysyłanych przez klientów do punktów zarządzania w lokacji. Do obsługi tej opcji nie jest konieczna instalacja żadnych aktualizacji u klienta. Warto jednak wziąć pod uwagę wyższe obciążenie procesora na klientach i punktach zarządzania związane z realizacją szyfrowania i odszyfrowywania.

Informacje dotyczące konfigurowania ustawień podpisywania i szyfrowania zawiera sekcja Konfigurowanie podpisywania i szyfrowania w temacie Konfigurowanie zabezpieczeń w programie Configuration Manager.

Planowanie administracji opartej na rolach

Administracja oparta na rolach pozwala zaprojektować i wdrożyć zabezpieczenia hierarchii programu System Center 2012 Configuration Manager na dowolne z następujących sposobów:

  • Role zabezpieczeń

  • Kolekcje

  • Zakresy zabezpieczeń

Połączenie tych ustawień pozwala zdefiniować zakres administracyjny u użytkownika administracyjnego. Zakres administracyjny kontroluje obiekty, które użytkownik administracyjny może wyświetlić w konsoli programu Menedżer konfiguracji, oraz uprawnienia, które użytkownik ma dla tych obiektów. Konfiguracje administracji opartej na rolach są replikowane do wszystkich lokacji w hierarchii jako dane globalne, a następnie stosowane do wszystkich połączeń administracyjnych.

System_CAPS_importantWażne

Opóźnienia w replikacji między lokacjami mogą utrudnić odebranie zmian przez lokację w zakresie administracji opartej na rolach. Informacje dotyczące monitorowania replikacji bazy danych między lokacjami zawiera sekcja Jak monitorować łącza replikacji bazy danych i stan replikacji w temacie Monitorowanie lokacji i hierarchii w programie Configuration Manager.

Planowanie ról zabezpieczeń

Używanie ról zabezpieczeń do przydzielania uprawnień bezpieczeństwa użytkownikom administracyjnym. Role zabezpieczeń to grupy uprawnień zabezpieczeń przypisywane do użytkowników administracyjnych i umożliwiające wykonywanie im zadań administracyjnych. Te uprawnienia zabezpieczeń definiują działania administracyjne, które użytkownik administracyjny może wykonywać oraz uprawnienia przydzielane określonym typom obiektów. Najlepsze rozwiązanie w zakresie zabezpieczeń to przypisanie ról zabezpieczeń nadających jak najmniejsze uprawnienia.

Program System Center 2012 Configuration Manager ma dostępne wbudowane role zabezpieczeń obsługujące typowe grupowania zadań administracyjnych. Można także tworzyć własne, niestandardowe role zabezpieczeń stosownie do konkretnych potrzeb biznesowych. Przykłady wbudowanych ról zabezpieczeń:

  • Administrator o pełnych uprawnieniach: Ta rola zabezpieczeń przyznaje wszystkie uprawnienia dostępne w programie Menedżer konfiguracji.

  • Analityk zasobów: Ta rola zabezpieczeń zezwala użytkownikom administracyjnym na wyświetlanie danych zebranych przez funkcję Analiza zasobów, zapasów oprogramowania, zapasów sprzętowych oraz pomiarów użytkowania oprogramowania. Użytkownicy administracyjni mogą utworzyć reguły pomiarów i kategorie, rodziny oraz etykiety funkcji Analiza zasobów.

  • Menedżer aktualizacji oprogramowania: Rola zabezpieczeń przydziela uprawnienia do definiowania i wdrażania aktualizacji oprogramowania. Użytkownicy administracyjni skojarzeni z tą rolą mogą tworzyć kolekcje, grupy aktualizacji oprogramowania, wdrożenia i szablony oraz włączać aktualizacje oprogramowania w funkcji Ochrona dostępu do sieci (NAP).

System_CAPS_tipPorada

W konsoli programu Menedżer konfiguracji istnieje możliwość wyświetlenia listy wbudowanych oraz utworzonych niestandardowych ról zabezpieczeń wraz z opisami. Aby to zrobić, w obszarze roboczym Administracja rozwiń opcję Zabezpieczenia i wybierz polecenie Role zabezpieczeń.

Każda rola zabezpieczeń ma specyficzne uprawnienia do różnych typów obiektów. Przykładowo rola zabezpieczeń Administrator aplikacji ma następujące uprawnienia do aplikacji: Zatwierdź, Utwórz, Usuń, Modyfikuj, Modyfikuj folder, Przenieś obiekty, Odczytaj/wdróż, Ustaw zakres zabezpieczeń. Nie jest możliwa zmiana uprawnień dla wbudowanych ról zabezpieczeń. Można jednak skopiować rolę, wprowadzić zmiany, a następnie zapisać je jako nową, niestandardową rolę zabezpieczeń. Istnieje także możliwość importu ról zabezpieczeń wyeksportowanych z innej hierarchii (np. z sieci testowej). Przejrzyj role zabezpieczeń i odpowiednie uprawnienia i określ, czy chcesz użyć wbudowanych ról zabezpieczeń, czy zastosować utworzone niestandardowe role zabezpieczeń.

Aby zaplanować role zabezpieczeń, wykonaj następujące czynności:

  1. Zidentyfikuj zadania, które użytkownicy administracyjni mogą wykonywać w programie System Center 2012 Configuration Manager. Zadania te mogą być powiązane z przynajmniej jedną grupą zadań zarządzania, taką jak wdrażanie aplikacji i pakietów, wdrażanie systemów operacyjnych i ustawień zgodności, konfiguracja lokacji i zabezpieczeń, inspekcje, zdalne kontrolowanie komputerów oraz zbieranie danych spisu.

  2. Zamapuj te zadania administracyjne do przynajmniej jednej wbudowanej roli zabezpieczeń.

  3. Jeśli niektórzy użytkownicy administracyjni wykonują zadania przydzielone do wielu ról zabezpieczeń, przypisz te role do użytkowników, a nie twórz nowych ról łączących te zadania.

  4. Jeśli zidentyfikowane zadania nie mapują na wbudowane role zabezpieczeń, utwórz i przetestuj nowe role zabezpieczeń.

Informacje dotyczące tworzenia i konfigurowania ról zabezpieczeń na potrzeby administrowania opartego na rolach zawierają sekcje Tworzenie niestandardowych ról zabezpieczeń i Konfigurowanie ról zabezpieczeń w temacie Konfigurowanie zabezpieczeń w programie Configuration Manager.

Planowanie kolekcji

Kolekcje określają zasoby u użytkownika i komputera, które użytkownik administracyjny może wyświetlać lub którymi może zarządzać. Przykładowo aby użytkownicy administracyjni mogli wdrażać aplikacje lub realizować zdalne sterowanie, należy do nich przypisać rolę zabezpieczeń przydzielającą dostęp do kolekcji zawierającej dane zasoby. Istnieje możliwość wybrania kolekcji użytkowników lub urządzeń.

Więcej informacji o kolekcjach znajduje się w temacie Wprowadzenie do kolekcji w programie Configuration Manager.

Przed skonfigurowaniem administracji oparta na rolach sprawdź, czy konieczne jest utworzenie nowej kolekcji z któregokolwiek z następujących powodów:

  • Podział funkcjonalny. Przykładowo oddzielne kolekcje dla serwerów i stacji roboczych.

  • Podział geograficzny. Przykładowo oddzielne kolekcje dla Ameryki Północnej i Europy.

  • Wymagania dotyczące zabezpieczeń i procesów biznesowych. Przykładowo oddzielne kolekcje dla komputerów produkcyjnych i testowych.

  • Podział organizacyjny. Przykładowo oddzielne kolekcje dla poszczególnych jednostek biznesowych.

Informacje o sposobie konfigurowania kolekcji na potrzeby administrowania opartego na rolach zawiera sekcja Konfigurowanie kolekcji w celu zarządzania zabezpieczeniami w temacie Konfigurowanie zabezpieczeń w programie Configuration Manager.

Planowanie zakresów zabezpieczeń

Zakresy zabezpieczeń umożliwiają zapewnienie użytkownikom administracyjnym dostępu do zabezpieczanych obiektów. Zakresy zabezpieczeń to nazwane zestawy zabezpieczanych obiektów przypisywanych do użytkownika administracyjnego jako grupa. Wszystkie zabezpieczane obiekty muszą być przypisane do przynajmniej jednego zakresu zabezpieczeń. Program Menedżer konfiguracji ma dwa wbudowane zakresy zabezpieczeń:

  • Wszystko: Ten wbudowany zakres zabezpieczeń nadaje dostęp do wszystkich zakresów. Nie można przypisywać obiektów do tego zakresu zabezpieczeń.

  • Domyślny: Ten wbudowany zakres zabezpieczeń jest używany domyślnie do wszystkich obiektów. Po pierwszej instalacji programu System Center 2012 Configuration Manager do tego zakresu zabezpieczeń przypisywane są wszystkie obiekty.

Jeśli chcesz ograniczyć obiekty wyświetlane i zarządzane przez użytkowników administracyjnych musisz utworzyć własne, niestandardowe zakresy zabezpieczeń i używać ich. Zakresy zabezpieczeń nie obsługują struktury hierarchicznej i nie mogą być zagnieżdżone. Zakresy zabezpieczeń mogą zawierać przynajmniej jeden typ obiektu, w tym:

  • Subskrypcje alertów

  • Aplikacje

  • Obrazy rozruchowe

  • Grupy granic

  • Elementy konfiguracji

  • Niestandardowe ustawienia klienta

  • Punkty dystrybucji i grupy punktów dystrybucji

  • Pakiety sterowników

  • Warunki globalne

  • Zadania migracji

  • Obrazy systemu operacyjnego

  • Pakiety instalacyjne systemu operacyjnego

  • Pakiety

  • Kwerendy

  • Lokacje

  • Zasady pomiaru użytkowania oprogramowania

  • Grupy aktualizacji oprogramowania

  • Pakiety aktualizacji oprogramowania

  • Pakiety sekwencji zadań

  • Pakiety i pozycje ustawień urządzeń z systemem Windows CE

Niektórych obiektów nie można uwzględnić w zakresach zabezpieczeń, ponieważ są zabezpieczone wyłącznie rolami zabezpieczeń. Dostęp administracyjny do tych obiektów nie może być ograniczony do podzbioru dostępnych obiektów. Przykładowo może istnieć użytkownik administracyjny, który tworzy grupy granic używane w określonej lokacji. Ponieważ obiekt granicy nie obsługuje zakresów zabezpieczeń, to nie można przypisać do tego użytkownika zakresu zabezpieczeń nadającego dostęp wyłącznie do tych granic, które mogą być skojarzone z tą lokacją. Brak możliwości skojarzenia obiektu granicy z zakresem zabezpieczeń oznacza, że przypisanie użytkownikowi roli zabezpieczeń z dostępem do obiektów granicy przyzna danemu użytkownikowi dostęp do każdej granicy w hierarchii.

Obiekty, które nie są ograniczone przez zakresy zabezpieczeń, to:

  • Lasy usługi Active Directory

  • Użytkownicy administracyjni

  • Alerty

  • Zasady ochrony przed złośliwym kodem

  • Granice

  • Skojarzenia komputerów

  • Ustawienia domyślne klienta

  • Szablony wdrażania

  • Sterowniki urządzeń

  • Łącznik serwera Exchange

  • Mapowanie lokacji przy migracji

  • Profile rejestracji urządzeń przenośnych

  • Role zabezpieczeń

  • Zakresy zabezpieczeń

  • Adresy lokacji

  • Role systemu lokacji

  • Tytuły oprogramowania

  • Aktualizacje oprogramowania

  • Komunikaty o stanie

  • Koligacje urządzeń użytkownika

Zakresy zabezpieczeń należy tworzyć, gdy konieczne jest ograniczenie dostępu do oddzielnych wystąpień obiektów. Na przykład:

  • Grupa użytkowników administracyjnych musi mieć możliwość wyświetlenia aplikacji produkcyjnych, lecz nie powinna mieć dostępu do aplikacji testowych. Utwórz dwa zakresy zabezpieczeń — dla aplikacji produkcyjnych i aplikacji testowych.

  • Różni użytkownicy administracyjni muszą mieć zróżnicowany dostęp do niektórych wystąpień obiektów określonego typu. Przykładowo jedna grupa użytkowników administracyjnych wymaga uprawnienia do odczytu do określonych grup aktualizacji oprogramowania, a inna — modyfikacji i usuwania innych grup aktualizacji oprogramowania. Utwórz różne zakresy zabezpieczeń dla tych grup aktualizacji oprogramowania.

Aby uzyskać informacje o sposobie konfigurowania zakresów zabezpieczeń na potrzeby administrowania opartego na rolach, zapoznaj się z sekcją Konfigurowanie zakresów zabezpieczeń dla obiektu w temacie Konfigurowanie zabezpieczeń w programie Configuration Manager.