Planen der Sicherheit in Configuration Manager

  • Artikel

Gilt für: Configuration Manager (Current Branch)

In diesem Artikel werden die folgenden Konzepte beschrieben, die Sie bei der Planung der Sicherheit mit Ihrer Configuration Manager Implementierung berücksichtigen sollten:

  • Zertifikate (selbstsigniert und PKI)

  • Der vertrauenswürdige Stammschlüssel

  • Signieren und Verschlüsseln

  • Rollenbasierte Administration

  • Microsoft Entra-ID

  • SMS-Anbieterauthentifizierung

Bevor Sie beginnen, stellen Sie sicher, dass Sie mit den Grundlagen der Sicherheit in Configuration Manager vertraut sind.

Zertifikate

Configuration Manager verwendet eine Kombination aus selbstsignierten und digitalen PKI-Zertifikaten (Public Key Infrastructure). Verwenden Sie nach Möglichkeit PKI-Zertifikate. Einige Szenarien erfordern PKI-Zertifikate. Wenn PKI-Zertifikate nicht verfügbar sind, generiert der Standort automatisch selbstsignierte Zertifikate. In einigen Szenarien werden immer selbstsignierte Zertifikate verwendet.

Weitere Informationen finden Sie unter Planen von Zertifikaten.

Der vertrauenswürdige Stammschlüssel

Der Configuration Manager vertrauenswürdigen Stammschlüssels bietet einen Mechanismus für Configuration Manager Clients, um zu überprüfen, ob Standortsysteme zu ihrer Hierarchie gehören. Jeder Standortserver generiert einen Standortaustauschschlüssel für die Kommunikation mit anderen Standorten. Der Standortaustauschschlüssel vom Standort der obersten Ebene in der Hierarchie wird als vertrauenswürdiger Stammschlüssel bezeichnet.

Die Funktion des vertrauenswürdigen Stammschlüssels in Configuration Manager ähnelt einem Stammzertifikat in einer Public Key-Infrastruktur. Alles, was vom privaten Schlüssel des vertrauenswürdigen Stammschlüssels signiert wird, wird weiter unten in der Hierarchie als vertrauenswürdig eingestuft. Clients speichern eine Kopie des vertrauenswürdigen Stammschlüssels des Standorts im root\ccm\locationservices WMI-Namespace.

Beispielsweise stellt die Website ein Zertifikat an den Verwaltungspunkt aus, das mit dem privaten Schlüssel des vertrauenswürdigen Stammschlüssels signiert wird. Der Standort teilt den öffentlichen Schlüssel des vertrauenswürdigen Stammschlüssels mit Clients. Clients können dann zwischen Verwaltungspunkten in ihrer Hierarchie und Verwaltungspunkten unterscheiden, die sich nicht in ihrer Hierarchie befinden.

Clients erhalten automatisch die öffentliche Kopie des vertrauenswürdigen Stammschlüssels mithilfe von zwei Mechanismen:

  • Sie erweitern das Active Directory-Schema für Configuration Manager und veröffentlichen den Standort in Active Directory Domain Services. Anschließend rufen Clients diese Standortinformationen von einem globalen Katalogserver ab. Weitere Informationen finden Sie unter Vorbereiten von Active Directory für die Websiteveröffentlichung.

  • Wenn Sie Clients mithilfe der Clientpushinstallationsmethode installieren. Weitere Informationen finden Sie unter Clientpushinstallation.

Wenn Clients den vertrauenswürdigen Stammschlüssel mithilfe eines dieser Mechanismen nicht abrufen können, vertrauen sie dem vertrauenswürdigen Stammschlüssel, der vom ersten Verwaltungspunkt bereitgestellt wird, mit dem sie kommunizieren. In diesem Szenario wird ein Client möglicherweise falsch an den Verwaltungspunkt eines Angreifers umgeleitet, wo er eine Richtlinie vom nicht autorisierten Verwaltungspunkt erhält. Diese Aktion erfordert einen anspruchsvollen Angreifer. Dieser Angriff ist auf die kurze Zeit beschränkt, bevor der Client den vertrauenswürdigen Stammschlüssel von einem gültigen Verwaltungspunkt abruft. Um dieses Risiko zu verringern, dass ein Angreifer Clients falsch zu einem nicht autorisierten Verwaltungspunkt weiterleitt, stellen Sie den Clients den vertrauenswürdigen Stammschlüssel vorab bereit.

Weitere Informationen und Verfahren zum Verwalten des vertrauenswürdigen Stammschlüssels finden Sie unter Konfigurieren der Sicherheit.

Signieren und Verschlüsseln

Wenn Sie PKI-Zertifikate für die gesamte Clientkommunikation verwenden, müssen Sie keine Signierung und Verschlüsselung planen, um die Kommunikation mit Clientdaten zu schützen. Wenn Sie Standortsysteme einrichten, auf denen IIS ausgeführt wird, um HTTP-Clientverbindungen zuzulassen, entscheiden Sie, wie die Clientkommunikation für den Standort gesichert werden soll.

Wichtig

Ab Configuration Manager Version 2103 sind Websites, die die HTTP-Clientkommunikation zulassen, veraltet. Konfigurieren Sie die Website für HTTPS oder erweitertes HTTP. Weitere Informationen finden Sie unter Aktivieren der Website für nur HTTPS oder erweitertes HTTP.

Um die Daten zu schützen, die Clients an Verwaltungspunkte senden, können Sie von Clients verlangen, die Daten zu signieren. Sie können auch den SHA-256-Algorithmus zum Signieren anfordern. Diese Konfiguration ist sicherer, erfordert jedoch keinen SHA-256, es sei denn, alle Clients unterstützen sie. Viele Betriebssysteme unterstützen diesen Algorithmus nativ, aber ältere Betriebssysteme erfordern möglicherweise ein Update oder Hotfix.

Während das Signieren dazu beiträgt, die Daten vor Manipulationen zu schützen, trägt die Verschlüsselung dazu bei, die Daten vor der Offenlegung von Informationen zu schützen. Sie können die Verschlüsselung für die Bestandsdaten und Zustandsmeldungen aktivieren, die Clients an Verwaltungspunkte am Standort senden. Sie müssen keine Updates auf Clients installieren, um diese Option zu unterstützen. Clients und Verwaltungspunkte erfordern eine größere CPU-Auslastung für die Ver- und Entschlüsselung.

Hinweis

Zum Verschlüsseln der Daten verwendet der Client den öffentlichen Schlüssel des Verschlüsselungszertifikats des Verwaltungspunkts. Nur der Verwaltungspunkt verfügt über den entsprechenden privaten Schlüssel, sodass nur er die Daten entschlüsseln kann.

Der Client bootstrapst dieses Zertifikat mit dem Signaturzertifikat des Verwaltungspunkts, das er mit dem vertrauenswürdigen Stammschlüssel des Standorts bootstrapst. Stellen Sie sicher, dass Sie den vertrauenswürdigen Stammschlüssel auf Clients sicher bereitstellen. Weitere Informationen finden Sie unter Der vertrauenswürdige Stammschlüssel.

Weitere Informationen zum Konfigurieren der Einstellungen für signieren und verschlüsseln finden Sie unter Konfigurieren von Signierung und Verschlüsselung.

Weitere Informationen zu den kryptografischen Algorithmen, die zum Signieren und Verschlüsseln verwendet werden, finden Sie unter Technische Referenz zu Kryptografiesteuerelementen.

Rollenbasierte Administration

Mit Configuration Manager verwenden Sie die rollenbasierte Verwaltung, um den Zugriff zu sichern, den Administratoren benötigen, um Configuration Manager zu verwenden. Sie sichern auch den Zugriff auf die Objekte, die Sie verwalten, z. B. Sammlungen, Bereitstellungen und Websites.

Mit der Kombination aus Sicherheitsrollen, Sicherheitsbereichen und Sammlungen trennen Sie die administrativen Zuweisungen, die die Anforderungen Ihrer organization erfüllen. Zusammen wird der Verwaltungsbereich eines Benutzers definiert. Dieser Verwaltungsbereich steuert die Objekte, die ein Administrator in der Configuration Manager-Konsole anzeigt, und steuert die Berechtigungen, die ein Benutzer für diese Objekte hat.

Weitere Informationen finden Sie unter Grundlagen der rollenbasierten Verwaltung.

Microsoft Entra-ID

Configuration Manager ist in Microsoft Entra-ID integriert, damit der Standort und die Clients die moderne Authentifizierung verwenden können.

Weitere Informationen zur Microsoft Entra-ID finden Sie in Microsoft Entra Dokumentation.

Das Onboarding Ihrer Website mit Microsoft Entra ID unterstützt die folgenden Configuration Manager Szenarien:

Clientszenarien

Serverszenarien

SMS-Anbieterauthentifizierung

Sie können die mindeste Authentifizierungsebene für Administratoren für den Zugriff auf Configuration Manager Websites angeben. Dieses Feature erzwingt, dass sich Administratoren mit der erforderlichen Ebene bei Windows anmelden, bevor sie auf Configuration Manager zugreifen können. Sie gilt für alle Komponenten, die auf den SMS-Anbieter zugreifen. Beispielsweise die Configuration Manager-Konsole, SDK-Methoden und Windows PowerShell Cmdlets.

Configuration Manager unterstützt die folgenden Authentifizierungsstufen:

  • Windows-Authentifizierung: Authentifizierung mit Active Directory-Domänenanmeldeinformationen erforderlich. Diese Einstellung ist das vorherige Verhalten und die aktuelle Standardeinstellung.

  • Zertifikatauthentifizierung: Erfordert die Authentifizierung mit einem gültigen Zertifikat, das von einer vertrauenswürdigen PKI-Zertifizierungsstelle ausgestellt wurde. Sie konfigurieren dieses Zertifikat nicht in Configuration Manager. Configuration Manager erfordert, dass der Administrator mithilfe der PKI bei Windows angemeldet ist.

  • Windows Hello for Business-Authentifizierung: Erfordert die Authentifizierung mit einer starken zweistufigen Authentifizierung, die an ein Gerät gebunden ist und biometrische Daten oder eine PIN verwendet. Weitere Informationen finden Sie unter Windows Hello for Business.

    Wichtig

    Wenn Sie diese Einstellung auswählen, erfordert der SMS-Anbieter und der Verwaltungsdienst, dass das Authentifizierungstoken des Benutzers einen MFA-Anspruch (Multi-Factor Authentication) von Windows Hello for Business enthält. Anders ausgedrückt: Ein Benutzer der Konsole, des SDK, von PowerShell oder des Verwaltungsdiensts muss sich mit seiner Windows Hello for Business PIN oder biometrisch bei Windows authentifizieren. Andernfalls lehnt die Website die Aktion des Benutzers ab.

    Dieses Verhalten gilt für Windows Hello for Business, nicht für Windows Hello.

Weitere Informationen zum Konfigurieren dieser Einstellung finden Sie unter Konfigurieren der SMS-Anbieterauthentifizierung.

Nächste Schritte