Planen der Sicherheit im Konfigurations-Manager

Gilt für: Konfigurations-Manager (Current Branch)

In diesem Artikel werden die folgenden Konzepte beschrieben, die Sie bei der Sicherheitsplanung für Ihre Konfigurations-Manager-Implementierung berücksichtigen sollten:

  • Zertifikate (selbstsigniert und PKI)

  • Der vertrauenswürdige Stammschlüssel

  • Signieren und Verschlüsseln

  • Rollenbasierte Administration

  • Microsoft Entra-ID

  • Authentifizierung des SMS-Anbieters

Bevor Sie beginnen, stellen Sie sicher, dass Sie mit den Grundlagen der Sicherheit im Konfigurations-Manager vertraut sind.

Zertifikate

Konfigurations-Manager verwendet eine Kombination aus selbstsignierten und digitalen PKI-Zertifikaten (Public Key Infrastructure). Verwenden Sie nach Möglichkeit PKI-Zertifikate. Für einige Szenarien sind PKI-Zertifikate erforderlich. Wenn keine PKI-Zertifikate verfügbar sind, generiert die Site automatisch selbstsignierte Zertifikate. Einige Szenarien verwenden immer selbstsignierte Zertifikate.

Weitere Informationen finden Sie unter Planen von Zertifikaten.

Der vertrauenswürdige Stammschlüssel

Der vertrauenswürdige Stammschlüssel von Konfigurations-Manager stellt einen Mechanismus für Konfigurations-Manager-Clients bereit, um zu überprüfen, ob Standortsysteme zu ihrer Hierarchie gehören. Jeder Standortserver generiert einen Standorttauschschlüssel, um mit anderen Standorten zu kommunizieren. 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 im Konfigurations-Manager ähnelt einem Stammzertifikat in einer Public Key-Infrastruktur. Alles, was mit dem privaten Schlüssel des vertrauenswürdigen Stammschlüssels signiert ist, wird weiter unten in der Hierarchie als vertrauenswürdig eingestuft. Clients speichern eine Kopie des vertrauenswürdigen Stammschlüssels der Website im root\ccm\locationservices WMI-Namespace.

So stellt die Website beispielsweise ein Zertifikat für den Verwaltungspunkt aus, das sie mit dem privaten Schlüssel des vertrauenswürdigen Stammschlüssels signiert. Die Website teilt mit Clients den öffentlichen Schlüssel ihres vertrauenswürdigen Stammschlüssels. Dann können Clients zwischen Verwaltungspunkten unterscheiden, die sich in ihrer Hierarchie befinden, und Verwaltungspunkten, die sich nicht in ihrer Hierarchie befinden.

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

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

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

Wenn Clients den vertrauenswürdigen Stammschlüssel nicht mithilfe eines dieser Mechanismen erhalten 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 an den Verwaltungspunkt eines Angreifers umgeleitet, wo er Richtlinien vom nicht autorisierten Verwaltungspunkt empfängt. Diese Aktion erfordert einen raffinierten 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 das Risiko zu verringern, dass ein Angreifer Clients an einen nicht autorisierten Verwaltungspunkt umleitet, stellen Sie den Clients vorab mit dem vertrauenswürdigen Stammschlüssel 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 Clientdatenkommunikation zu sichern. Wenn Sie Standortsysteme einrichten, auf denen IIS ausgeführt wird, um HTTP-Clientverbindungen zuzulassen, entscheiden Sie, wie Sie die Clientkommunikation für den Standort sichern können.

Wichtig

Ab Konfigurations-Manager Version 2103 sind Standorte, 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 reines HTTPS oder erweitertes HTTP.

Zum Schutz der Daten, die Clients an Verwaltungspunkte senden, können Sie verlangen, dass Clients die Daten signieren. Sie können auch den SHA-256-Algorithmus zum Signieren anfordern. Diese Konfiguration ist sicherer, erfordert jedoch SHA-256 nur, wenn alle Clients dies unterstützen. Dieser Algorithmus wird in vielen Betriebssystemen nativ unterstützt, für ältere Betriebssysteme ist jedoch möglicherweise ein Update oder Hotfix erforderlich.

Während die Signierung dazu beiträgt, die Daten vor Manipulationen zu schützen, hilft die Verschlüsselung, die Daten vor der Offenlegung von Informationen zu schützen. Sie können die Verschlüsselung für die Bestandsdaten und Statusmeldungen 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 benötigen mehr 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 startet dieses Zertifikat mit dem Signaturzertifikat des Verwaltungspunkts, das er mit dem vertrauenswürdigen Stammschlüssel der Website erstellt. Stellen Sie sicher, dass der vertrauenswürdige Stammschlüssel auf Clients sicher bereitgestellt wird. 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 kryptografischen Steuerelementen.

Rollenbasierte Administration

Mit Konfigurations-Manager verwenden Sie die rollenbasierte Verwaltung, um den Zugriff zu sichern, den administrative Benutzer für die Verwendung von Konfigurations-Manager benötigen. Sie sichern auch den Zugriff auf die von Ihnen verwalteten Objekte, z. B. Sammlungen, Bereitstellungen und Websites.

Mit der Kombination aus Sicherheitsrollen, Sicherheitsbereichen und Sammlungen trennen Sie die administrativen Aufgaben, die den Anforderungen Ihrer Organization entsprechen. Zusammen definierten, definieren sie den administrativen Bereich eines Benutzers. Dieser administrative Bereich steuert die Objekte, die ein Administrator in der Konfigurations-Manager-Konsole anzeigt, und er steuert die Berechtigungen, die ein Benutzer für diese Objekte hat.

Weitere Informationen finden Sie unter Grundlagen der rollenbasierten Verwaltung.

Microsoft Entra-ID

Konfigurations-Manager wird in Microsoft Entra ID integriert, um dem Standort und den Clients die Verwendung moderner Authentifizierung zu ermöglichen.

Weitere Informationen zu Microsoft Entra ID finden Sie in der Dokumentation zu Microsoft Entra.

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

Clientszenarien

Serverszenarien

Authentifizierung des SMS-Anbieters

Sie können die Mindestauthentifizierungsebene für Administratoren für den Zugriff auf Konfigurations-Manager-Websites festlegen. Diese Funktion erzwingt, dass sich Administratoren mit der erforderlichen Stufe bei Windows anmelden müssen, bevor sie auf den Konfigurations-Manager zugreifen können. Sie gilt für alle Komponenten, die auf den SMS-Anbieter zugreifen. Beispielsweise die Konfigurations-Manager-Konsole, SDK-Methoden und Windows PowerShell-Cmdlets.

Konfigurations-Manager unterstützt die folgenden Authentifizierungsebenen:

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

  • Zertifikatauthentifizierung: Verlangen Sie die Authentifizierung mit einem gültigen Zertifikat, das von einer vertrauenswürdigen PKI-Zertifizierungsstelle ausgestellt wurde. Sie konfigurieren dieses Zertifikat nicht im Konfigurations-Manager. Für den Konfigurations-Manager muss der Administrator über PKI bei Windows angemeldet sein.

  • Windows Hello for Business-Authentifizierung: Fordern Sie die Authentifizierung mit sicherer Zwei-Faktor-Authentifizierung an, 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, benötigen der SMS-Anbieter und der Verwaltungsdienst, dass das Authentifizierungstoken des Benutzers einen MFA-Anspruch (Multi-Factor Authentication) von Windows Hello for Business enthält. Mit anderen Worten: Ein Benutzer der Konsole, des SDK, der PowerShell oder des Verwaltungsdiensts muss sich bei Windows mit seiner Windows Hello for Business-PIN oder biometrischen Daten 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