Planen der Sicherheit in Configuration Manager
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 vertrauenswürdige Stammschlüssel von Configuration Manager stellt einen Mechanismus für Configuration Manager-Clients bereit, 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 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 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 für die Verwendung von Configuration Manager benötigen. 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 den Anforderungen Ihrer Organisation entsprechen. 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 besitzt.
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 der Microsoft Entra-Dokumentation.
Das Onboarding Ihres Standorts mit Microsoft Entra ID unterstützt die folgenden Configuration Manager-Szenarien:
Clientszenarien
Serverszenarien
SMS-Anbieterauthentifizierung
Sie können die Mindestauthentifizierungsebene für Administratoren für den Zugriff auf Configuration Manager-Standorte 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. Beispiele hierfür sind die Configuration Manager-Konsole, SDK-Methoden und Windows PowerShell-Cmdlets.
Configuration Manager unterstützt die folgenden Authentifizierungsebenen:
Windows-Authentifizierung: Erfordert die Authentifizierung mit Anmeldeinformationen für die Active Directory-Domäne. 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 über die PKI bei Windows angemeldet ist.
Windows Hello for Business-Authentifizierung: Erfordert eine Authentifizierung mit starker zweistufiger 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.