Technische Referenz zu kryptografischen Steuerelementen

Gilt für: Configuration Manager (Current Branch)

Configuration Manager verwendet Signatur und Verschlüsselung, um die Verwaltung der Geräte in der Configuration Manager-Hierarchie zu schützen. Wenn Daten beim Signieren während der Übertragung geändert wurden, werden sie verworfen. Die Verschlüsselung kann verhindern, dass ein Angreifer die Daten mithilfe eines Netzwerkprotokoll-Analysetools liest.

Der primäre Hashalgorithmus, den Configuration Manager zum Signieren verwendet, ist SHA-256. Wenn zwei Configuration Manager-Standorte miteinander kommunizieren, signieren sie ihre Kommunikation mit SHA-256.

Ab Version 2107 ist AES-256 der primäre Verschlüsselungsalgorithmus, den Configuration Manager verwendet. Die Verschlüsselung erfolgt hauptsächlich in den folgenden zwei Bereichen:

• Wenn Sie die Verschlüsselung für die Website aktivieren, verschlüsselt der Client seine Bestandsdaten und Statusmeldungen, die er an den Verwaltungspunkt sendet.

• Wenn der Client geheime Richtlinien herunterlädt, verschlüsselt der Verwaltungspunkt diese Richtlinien immer. Beispielsweise eine Tasksequenz für die Betriebssystembereitstellung, die Kennwörter enthält.

Wenn Sie die Clientkommunikation über HTTPS verwenden, konfigurieren Sie Ihre Public Key-Infrastruktur (PKI) so, dass Zertifikate mit den maximalen Hashalgorithmen und Schlüssellängen verwendet werden. Bei Verwendung von CNG v3-Zertifikaten unterstützen Configuration Manager-Clients nur Zertifikate, die den kryptografischen RSA-Algorithmus verwenden. Weitere Informationen finden Sie unter PKI-Zertifikatanforderungen und Übersicht über CNG v3-Zertifikate.

Für die Transportsicherheit unterstützt alles, was TLS verwendet, AES-256. Diese Unterstützung gilt, wenn Sie die Website für erweitertes HTTP (E-HTTP) oder HTTPS konfigurieren. Für lokale Standortsysteme können Sie die TLS-Verschlüsselungssammlungen steuern. Wenn Sie TLS 1.2 aktivieren, konfiguriert Configuration Manager für cloudbasierte Rollen wie das Cloud Management Gateway (CMG) die Verschlüsselungssammlungen.

Für die meisten kryptografischen Vorgänge mit Windows-basierten Betriebssystemen verwendet Configuration Manager diese Algorithmen aus der Windows-CryptoAPI-Bibliothek rsaenh.dll.

Weitere Informationen zu bestimmten Funktionen finden Sie unter Websitevorgänge.

Websitevorgänge

Informationen im Configuration Manager können signiert und verschlüsselt werden. Es unterstützt diese Vorgänge mit oder ohne PKI-Zertifikate.

Signieren und Verschlüsseln von Richtlinien

Die Website signiert Clientrichtlinienzuweisungen mit ihrem selbstsignierten Zertifikat. Durch dieses Verhalten wird verhindert, dass das Sicherheitsrisiko eines kompromittierten Verwaltungspunkts manipulierte Richtlinien sendet. Wenn Sie die internetbasierte Clientverwaltung verwenden, ist dieses Verhalten wichtig, da ein Verwaltungspunkt mit Internetzugriff erforderlich ist.

Wenn eine Richtlinie vertrauliche Daten enthält, verschlüsselt die Richtlinie ab Version 2107 diese mit AES-256. Richtlinien, die vertrauliche Daten enthalten, werden nur an autorisierte Clients gesendet. Die Website verschlüsselt keine Richtlinie, die keine vertraulichen Daten enthält.

Wenn ein Client Richtlinien speichert, verschlüsselt er sie mithilfe der Windows-Datenschutz-DPAPI (Application Programming Interface).

Richtlinienhashing

Wenn ein Client eine Richtlinie anfordert, erhält er zuerst eine Richtlinienzuweisung. Dann weiß sie, welche Richtlinien für sie gelten, und sie kann nur diese Richtlinienorgane anfordern. Jede Richtlinienzuweisung enthält den berechneten Hash für den entsprechenden Richtlinientext. Der Client lädt die anwendbaren Richtlinientexte herunter und berechnet dann den Hash für jeden Richtlinientext. Wenn der Hash im Richtlinientext nicht mit dem Hash in der Richtlinienzuweisung übereinstimmt, verwirft der Client den Richtlinientext.

Der Hashalgorithmus für Richtlinie ist SHA-256.

Inhaltshashing

Der Verteilungs-Manager-Dienst auf dem Standortserver hasht die Inhaltsdateien für alle Pakete. Der Richtlinienanbieter fügt den Hash in die Softwareverteilungsrichtlinie ein. Wenn der Configuration Manager-Client den Inhalt herunterlädt, generiert der Client den Hash lokal neu und vergleicht ihn mit dem in der Richtlinie bereitgestellten. Wenn die Hashes übereinstimmen, wird der Inhalt nicht geändert, und der Client installiert es. Wenn ein einzelnes Byte des Inhalts geändert wird, stimmen die Hashes nicht überein, und der Client installiert die Software nicht. Durch diese Überprüfung wird sichergestellt, dass die richtige Software installiert ist, da der tatsächliche Inhalt mit der Richtlinie verglichen wird.

Der Standard-Hashalgorithmus für Inhalte ist SHA-256.

Nicht alle Geräte können Inhaltshashing unterstützen. Zu den Ausnahmen gehören:

• Windows-Clients beim Streamen von App-V-Inhalten.

Signieren und Verschlüsseln von Lagerbeständen

Wenn ein Client den Hardware- oder Softwarebestand an einen Verwaltungspunkt sendet, signiert er immer den Bestand. Dabei spielt es keine Rolle, ob der Client über E-HTTP oder HTTPS mit dem Verwaltungspunkt kommuniziert. Wenn sie E-HTTP verwenden, können Sie diese Daten auch verschlüsseln. Dies wird empfohlen.

Verschlüsselung der Statusmigration

Wenn eine Tasksequenz Daten von einem Client für die Betriebssystembereitstellung erfasst, werden die Daten immer verschlüsselt. In Version 2103 und höher führt die Tasksequenz das Migrationstool für den Benutzerstatus (User State Migration Tool, USMT) mit dem AES-256-Verschlüsselungsalgorithmus aus.

Verschlüsselung für Multicastpakete

Für jedes Betriebssystembereitstellungspaket können Sie die Verschlüsselung aktivieren, wenn Sie Multicast verwenden. Diese Verschlüsselung verwendet den AES-256-Algorithmus . Wenn Sie die Verschlüsselung aktivieren, ist keine weitere Zertifikatkonfiguration erforderlich. Der multicastfähige Verteilungspunkt generiert automatisch symmetrische Schlüssel zum Verschlüsseln des Pakets. Jedes Paket verfügt über einen anderen Verschlüsselungsschlüssel. Der Schlüssel wird mithilfe von Standard-Windows-APIs auf dem multicastfähigen Verteilungspunkt gespeichert.

Wenn der Client eine Verbindung mit der Multicastsitzung herstellt, erfolgt der Schlüsselaustausch über einen verschlüsselten Kanal. Wenn der Client HTTPS verwendet, verwendet er das von der PKI ausgestellte Clientauthentifizierungszertifikat. Wenn der Client E-HTTP verwendet, verwendet er das selbstsignierte Zertifikat. Der Client speichert den Verschlüsselungsschlüssel nur während der Multicastsitzung im Arbeitsspeicher.

Verschlüsselung für Betriebssystembereitstellungsmedien

Wenn Sie Medien zum Bereitstellen von Betriebssystemen verwenden, sollten Sie immer ein Kennwort angeben, um die Medien zu schützen. Mit einem Kennwort werden die Tasksequenz-Umgebungsvariablen mit AES-128 verschlüsselt. Andere Daten auf den Medien, einschließlich Pakete und Inhalte für Anwendungen, sind nicht verschlüsselt.

Verschlüsselung für cloudbasierte Inhalte

Wenn Sie ein Cloud Management Gateway (CMG) zum Speichern von Inhalten aktivieren, wird der Inhalt mit AES-256 verschlüsselt. Der Inhalt wird bei jeder Aktualisierung verschlüsselt. Wenn Clients den Inhalt herunterladen, werden diese verschlüsselt und über die HTTPS-Verbindung geschützt.

Anmelden von Softwareupdates

Alle Softwareupdates müssen zum Schutz vor Manipulationen von einem vertrauenswürdigen Herausgeber signiert sein. Auf Clientcomputern sucht der Windows Update Agent (WUA) nach den Updates aus dem Katalog. Das Update wird nicht installiert, wenn das digitale Zertifikat im Speicher für vertrauenswürdige Herausgeber auf dem lokalen Computer nicht gefunden werden kann.

Wenn Sie Softwareupdates mit System Center Updates Publisher veröffentlichen, signiert ein digitales Zertifikat die Softwareupdates. Sie können entweder ein PKI-Zertifikat angeben oder Updates Publisher so konfigurieren, dass ein selbstsigniertes Zertifikat zum Signieren des Softwareupdates generiert wird. Wenn Sie ein selbstsigniertes Zertifikat zum Veröffentlichen des Updatekatalogs verwenden, z. B. WSUS-Herausgeber Selbstsigniert, muss sich das Zertifikat auch im Zertifikatspeicher "Vertrauenswürdige Stammzertifizierungsstellen" auf dem lokalen Computer befinden. WUA überprüft auch, ob die Gruppenrichtlinieneinstellung "Signierten Inhalt aus dem Intranet des Microsoft Updatedienst-Speicherorts zulassen " auf dem lokalen Computer aktiviert ist. Diese Richtlinieneinstellung muss aktiviert sein, damit WUA nach den Updates suchen kann, die mit System Center Updates Publisher erstellt und veröffentlicht wurden.

Signierte Konfigurationsdaten für Konformitätseinstellungen

Wenn Sie Konfigurationsdaten importieren, überprüft Configuration Manager die digitale Signatur der Datei. Wenn die Dateien nicht signiert sind oder die Signaturprüfung fehlschlägt, werden Sie von der Konsole gewarnt, mit dem Import fortzufahren. Importieren Sie die Konfigurationsdaten nur, wenn Sie dem Herausgeber und der Integrität der Dateien explizit vertrauen.

Verschlüsselung und Hashing für Clientbenachrichtigung

Wenn Sie die Clientbenachrichtigung verwenden, verwendet die gesamte Kommunikation TLS und die höchsten Algorithmen, die Server und Client aushandeln können. Die gleiche Aushandlung erfolgt für das Hashing der Pakete, die während der Clientbenachrichtigung übertragen werden, welche SHA-2 verwendet.

Zertifikate

Eine Liste der PKI-Zertifikate (Public Key Infrastructure), die von Configuration Manager verwendet werden können, besondere Anforderungen oder Einschränkungen sowie Informationen zur Verwendung der Zertifikate finden Sie unter Anforderungen an PKI-Zertifikate. Diese Liste enthält die unterstützten Hashalgorithmen und Schlüssellängen. Die meisten Zertifikate unterstützen die Schlüssellänge von SHA-256 und 2048 Bit.

Die meisten Configuration Manager-Vorgänge, die Zertifikate verwenden, unterstützen auch v3-Zertifikate. Weitere Informationen finden Sie unter Übersicht über CNG v3-Zertifikate.

Der Configuration Manager benötigt PKI-Zertifikate für die folgenden Szenarien:

• Wenn Sie Configuration Manager-Clients im Internet verwalten

• Wenn Sie ein Cloudverwaltungsgateway (Cloud Management Gateway, CMG) verwenden

Für die meisten anderen Kommunikationen, für die Zertifikate zur Authentifizierung, Signierung oder Verschlüsselung erforderlich sind, verwendet der Configuration Manager automatisch PKI-Zertifikate, sofern verfügbar. Wenn sie nicht verfügbar sind, generiert der Configuration Manager selbstsignierte Zertifikate.

Mobile Geräteverwaltung und PKI-Zertifikate

Betriebssystembereitstellung und PKI-Zertifikate

Wenn Sie Configuration Manager zum Bereitstellen von Betriebssystemen verwenden und ein Verwaltungspunkt HTTPS-Clientverbindungen erfordert, benötigt der Client ein Zertifikat für die Kommunikation mit dem Verwaltungspunkt. Diese Anforderung gilt auch dann, wenn sich der Client in einer Übergangsphase befindet, z. B. beim Starten von Tasksequenzmedien oder einem PXE-fähigen Verteilungspunkt. Erstellen Sie zur Unterstützung dieses Szenarios ein PKI-Clientauthentifizierungszertifikat, und exportieren Sie es mit dem privaten Schlüssel. Importieren Sie es dann in die Eigenschaften des Standortservers, und fügen Sie außerdem das Zertifikat der vertrauenswürdigen Stammzertifizierungsstelle des Verwaltungspunkts hinzu.

Wenn Sie startbare Medien erstellen, importieren Sie das Clientauthentifizierungszertifikat, wenn Sie die startbaren Medien erstellen. Um den privaten Schlüssel und andere in der Tasksequenz konfigurierte vertrauliche Daten zu schützen, konfigurieren Sie ein Kennwort auf dem startbaren Medium. Jeder Computer, der vom startbaren Medium gestartet wird, verwendet dasselbe Zertifikat mit dem Verwaltungspunkt, wie es für Clientfunktionen wie das Anfordern einer Clientrichtlinie erforderlich ist.

Wenn Sie PXE verwenden, importieren Sie das Clientauthentifizierungszertifikat in den PXE-fähigen Verteilungspunkt. Er verwendet dasselbe Zertifikat für jeden Client, der von diesem PXE-fähigen Verteilungspunkt gestartet wird. Um den privaten Schlüssel und andere vertrauliche Daten in den Tasksequenzen zu schützen, benötigen Sie ein Kennwort für PXE.

Wenn eines dieser Clientauthentifizierungszertifikate kompromittiert ist, blockieren Sie die Zertifikate im Knoten Zertifikate im Arbeitsbereich "Verwaltung ", Knoten "Sicherheit ". Zum Verwalten dieser Zertifikate benötigen Sie die Berechtigung zum Verwalten des Betriebssystembereitstellungszertifikats.

Nachdem der Configuration Manager das Betriebssystem bereitgestellt und den Client installiert hat, benötigt der Client ein eigenes PKI-Clientauthentifizierungszertifikat für die HTTPS-Clientkommunikation.

ISV-Proxylösungen und PKI-Zertifikate

Unabhängige Softwareanbieter (Independent Software Vendors, ISVs) können Anwendungen erstellen, die den Configuration Manager erweitern. Beispielsweise könnte ein ISV Erweiterungen zur Unterstützung von Nicht-Windows-Clientplattformen erstellen. Wenn die Standortsysteme jedoch HTTPS-Clientverbindungen erfordern, müssen diese Clients auch PKI-Zertifikate für die Kommunikation mit dem Standort verwenden. Configuration Manager bietet die Möglichkeit, dem ISV-Proxy ein Zertifikat zuzuweisen, das die Kommunikation zwischen den ISV-Proxyclients und dem Verwaltungspunkt ermöglicht. Wenn Sie Erweiterungen verwenden, die ISV-Proxyzertifikate erfordern, lesen Sie die Dokumentation für dieses Produkt.

Wenn das ISV-Zertifikat kompromittiert ist, blockieren Sie das Zertifikat im Knoten Zertifikate im Arbeitsbereich "Verwaltung ", Knoten "Sicherheit ".

Kopieren der GUID für ISV-Proxyzertifikat

Ab Version 2111 können Sie zur Vereinfachung der Verwaltung dieser ISV-Proxyzertifikate jetzt die GUID in die Configuration Manager-Konsole kopieren.

1. Wechseln Sie in der Configuration Manager-Konsole zum Arbeitsbereich Verwaltung.

2. Erweitern Sie Sicherheit, und wählen Sie den Knoten Zertifikate aus.

3. Sortieren Sie die Liste der Zertifikate nach der Spalte "Typ ".

4. Wählen Sie ein Zertifikat vom Typ "ISV-Proxy" aus.

5. Wählen Sie im Menüband die Option Zertifikat-GUID kopieren aus.

Dadurch wird die GUID dieses Zertifikats kopiert, z. B.: aa05bf38-5cd6-43ea-ac61-ab101f943987

Asset Intelligence und Zertifikate

Seit November 2021 ist Asset Intelligence veraltet, und wir empfehlen Kunden, diese Rolle zu deinstallieren.

Azure-Dienste und -Zertifikate

Für das Cloud Management Gateway (CMG) sind Serverauthentifizierungszertifikate erforderlich. Diese Zertifikate ermöglichen dem Dienst die Bereitstellung von HTTPS-Kommunikation mit Clients über das Internet. Weitere Informationen finden Sie unter CMG-Serverauthentifizierungszertifikat.

Clients benötigen für die Kommunikation mit einer CMG und dem lokalen Verwaltungspunkt eine andere Authentifizierung. Sie können Microsoft Entra ID, ein PKI-Zertifikat oder ein Standorttoken verwenden. Weitere Informationen finden Sie unter Konfigurieren der Clientauthentifizierung für Cloud Management Gateway.

Clients benötigen kein Client-PKI-Zertifikat, um cloudbasierten Speicher zu verwenden. Nach der Authentifizierung beim Verwaltungspunkt stellt der Verwaltungspunkt ein Configuration Manager-Zugriffstoken für den Client aus. Der Client legt dieses Token der CMG vor, um auf den Inhalt zuzugreifen. Der Token ist acht Stunden lang gültig.

CRL-Überprüfung auf PKI-Zertifikate

Eine PKI-Zertifikatssperrliste (Certificate Revocation List, CRL) erhöht die allgemeine Sicherheit, erfordert jedoch einen gewissen Verwaltungs- und Verarbeitungsaufwand. Wenn Sie die CRL-Überprüfung aktivieren, Clients jedoch nicht auf die CRL zugreifen können, schlägt die PKI-Verbindung fehl.

IIS aktiviert standardmäßig die CRL-Überprüfung. Wenn Sie eine CRL mit Ihrer PKI-Bereitstellung verwenden, müssen Sie die meisten Standortsysteme, auf denen IIS ausgeführt wird, nicht konfigurieren. Die Ausnahme gilt für Softwareupdates, für die ein manueller Schritt erforderlich ist, um die CRL-Überprüfung zur Überprüfung der Signaturen in Softwareupdatedateien zu aktivieren.

Wenn ein Client HTTPS verwendet, wird die CRL-Überprüfung standardmäßig aktiviert.

Die folgenden Verbindungen unterstützen keine CRL-Überprüfung im Configuration Manager:

• Server-zu-Server-Verbindungen

Serverkommunikation

Configuration Manager verwendet die folgenden kryptografischen Steuerelemente für die Serverkommunikation.

Serverkommunikation innerhalb eines Standorts

Jeder Standortsystemserver verwendet ein Zertifikat, um Daten an andere Standortsysteme am selben Configuration Manager-Standort zu übertragen. Einige Standortsystemrollen verwenden auch Zertifikate zur Authentifizierung. Wenn Sie z. B. den Registrierungsproxypunkt auf einem Server und den Registrierungspunkt auf einem anderen Server installieren, können sie sich gegenseitig mit diesem Identitätszertifikat authentifizieren.

Wenn Configuration Manager ein Zertifikat für diese Kommunikation verwendet und ein PKI-Zertifikat mit Serverauthentifizierungsfunktion verfügbar ist, verwendet Configuration Manager dieses automatisch. Andernfalls generiert Configuration Manager ein selbstsigniertes Zertifikat. Dieses selbstsignierte Zertifikat verfügt über Serverauthentifizierungsfunktionen, verwendet SHA-256 und hat eine Schlüssellänge von 2048 Bits. Configuration Manager kopiert das Zertifikat in den Trusted People-Speicher auf anderen Standortsystemservern, die dem Standortsystem möglicherweise vertrauen müssen. Standortsysteme können sich dann gegenseitig vertrauen, indem sie diese Zertifikate und PeerTrust verwenden.

Zusätzlich zu diesem Zertifikat für jeden Standortsystemserver generiert Configuration Manager für die meisten Standortsystemrollen ein selbstsigniertes Zertifikat. Wenn mehr als eine Instance der Standortsystemrolle am selben Standort vorhanden ist, verwenden sie dasselbe Zertifikat. Möglicherweise haben Sie mehrere Verwaltungspunkte am selben Standort. Dieses selbstsignierte Zertifikat verwendet SHA-256 und hat eine Schlüssellänge von 2048 Bit. Sie wird in den Trusted People Store auf Standortsystemservern kopiert, die ihr möglicherweise vertrauen müssen. Die folgenden Standortsystemrollen generieren dieses Zertifikat:

• Asset Intelligence-Synchronisationspunkt

• Endpoint Protection-Punkt

• Fallback status point

• Verwaltungspunkt

• Multicastfähiger Verteilungspunkt

• Reporting Services-Punkt

• Softwareupdatepunkt

• Zustandsmigrationspunkt

Configuration Manager generiert und verwaltet diese Zertifikate automatisch.

Zum Senden von Status vom Verteilungspunkt an den Verwaltungspunkt verwendet Configuration Manager ein Clientauthentifizierungszertifikat. Wenn Sie den Verwaltungspunkt für HTTPS konfigurieren, ist ein PKI-Zertifikat erforderlich. Wenn der Verwaltungspunkt E-HTTP-Verbindungen akzeptiert, können Sie ein PKI-Zertifikat verwenden. Sie kann auch ein selbstsigniertes Zertifikat mit Clientauthentifizierungsfunktion verwenden, verwendet SHA-256 und hat eine Schlüssellänge von 2048 Bit.

Serverkommunikation zwischen Standorten

Configuration Manager überträgt Daten zwischen Standorten mithilfe der Datenbankreplikation und der dateibasierten Replikation. Weitere Informationen finden Sie unter Datenübertragungen zwischen Standorten und Kommunikation zwischen Endpunkten.

Configuration Manager konfiguriert automatisch die Datenbankreplikation zwischen Standorten. Falls verfügbar, werden PKI-Zertifikate mit Serverauthentifizierungsfunktion verwendet. Falls nicht verfügbar, erstellt der Configuration Manager selbstsignierte Zertifikate für die Serverauthentifizierung. In beiden Fällen wird die Authentifizierung zwischen Websites mithilfe von Zertifikaten im Trusted People-Speicher durchgeführt, der PeerTrust verwendet. Er verwendet diesen Zertifikatspeicher, um sicherzustellen, dass nur die SQL Server in der Configuration Manager-Hierarchie an der Standort-zu-Standort-Replikation teilnehmen.

Standortserver stellen die Standortkommunikation mithilfe eines sicheren Schlüsselaustauschs her, der automatisch erfolgt. Der Server der sendenden Website generiert einen Hash und signiert ihn mit seinem privaten Schlüssel. Der empfangende Standortserver überprüft die Signatur mithilfe des öffentlichen Schlüssels und vergleicht den Hash mit einem lokal generierten Wert. Wenn sie übereinstimmen, akzeptiert der empfangende Standort die replizierten Daten. Wenn die Werte nicht übereinstimmen, lehnt Configuration Manager die Replikationsdaten ab.

Die Datenbankreplikation in Configuration Manager verwendet den SQL Server Service Broker zum Übertragen von Daten zwischen Standorten. Dabei werden die folgenden Mechanismen verwendet:

• SQL Server zu SQL Server: Diese Verbindung verwendet Windows-Anmeldeinformationen für die Serverauthentifizierung und selbstsignierte Zertifikate mit 1024 Bit, um die Daten mit dem AES-Algorithmus zu signieren und zu verschlüsseln. Falls verfügbar, werden PKI-Zertifikate mit Serverauthentifizierungsfunktion verwendet. Es werden nur die Zertifikate im persönlichen Zertifikatsspeicher des Computers verwendet.

• SQL Service Broker: Dieser Dienst verwendet selbstsignierte Zertifikate mit 2048 Bit zur Authentifizierung und zum Signieren und Verschlüsseln der Daten mit dem AES-Algorithmus. Es werden nur Zertifikate in der SQL Server master Datenbank verwendet.

Die dateibasierte Replikation verwendet das SMB-Protokoll (Server Message Block). Es verwendet SHA-256 , um Daten zu signieren, die nicht verschlüsselt sind und keine vertraulichen Daten enthalten. Verwenden Sie zum Verschlüsseln dieser Daten IPsec, das Sie unabhängig vom Configuration Manager implementieren.

Clients, die HTTPS verwenden

Wenn Standortsystemrollen Clientverbindungen akzeptieren, können Sie sie so konfigurieren, dass sie HTTPS- und HTTP-Verbindungen oder nur HTTPS-Verbindungen akzeptieren. Standortsystemrollen, die Verbindungen aus dem Internet akzeptieren, akzeptieren nur Clientverbindungen über HTTPS.

Clientverbindungen über HTTPS bieten ein höheres Maß an Sicherheit, indem sie in eine Public Key-Infrastruktur (PKI) integriert werden, um die Client-Server-Kommunikation zu schützen. Das Konfigurieren von HTTPS-Clientverbindungen ohne ein gründliches Verständnis der PKI-Planung, -Bereitstellung und -Vorgänge kann Sie jedoch weiterhin anfällig machen. Wenn Sie z. B. Ihre Stammzertifizierungsstelle nicht schützen, können Angreifer die Vertrauensstellung Ihrer gesamten PKI-Infrastruktur gefährden. Wenn die PKI-Zertifikate nicht mithilfe kontrollierter und gesicherter Prozesse bereitgestellt und verwaltet werden, kann dies dazu führen, dass nicht verwaltete Clients keine wichtigen Softwareupdates oder -pakete empfangen können.

Unverschlüsselte Kommunikation, wenn Clients HTTPS verwenden

Wenn Clients über HTTPS mit Standortsystemen kommunizieren, wird der meiste Datenverkehr verschlüsselt. In den folgenden Situationen kommunizieren Clients mit Standortsystemen ohne Verschlüsselung:

• Der Client kann keine HTTPS-Verbindung im Intranet herstellen und greift auf HTTP zurück, wenn die Standortsysteme diese Konfiguration zulassen.

• Kommunikation mit den folgenden Standortsystemrollen:

  • Client sendet Statusmeldungen an den Fallback-Statuspunkt.

  • Der Client sendet PXE-Anforderungen an einen PXE-fähigen Verteilungspunkt.

  • Client sendet Benachrichtigungsdaten an einen Verwaltungspunkt.

Sie konfigurieren Reporting Services-Punkte so, dass HTTP oder HTTPS unabhängig vom Clientkommunikationsmodus verwendet wird.

Clients, die E-HTTP verwenden

Wenn Clients die E-HTTP-Kommunikation mit Standortsystemrollen nutzen, können sie PKI-Zertifikate für die Clientauthentifizierung oder selbstsignierte Zertifikate verwenden, die vom Configuration Manager generiert werden. Wenn Configuration Manager selbstsignierte Zertifikate generiert, verfügen diese über einen benutzerdefinierten Objektbezeichner zum Signieren und Verschlüsseln. Diese Zertifikate werden zur eindeutigen Identifizierung des Clients verwendet. Diese selbstsignierten Zertifikate verwenden SHA-256 und haben eine Schlüssellänge von 2048 Bit.

Betriebssystembereitstellung und selbstsignierte Zertifikate

Wenn Sie mit dem Configuration Manager Betriebssysteme mit selbstsignierten Zertifikaten bereitstellen, muss der Client auch über ein Zertifikat verfügen, um mit dem Verwaltungspunkt zu kommunizieren. Diese Anforderung gilt auch dann, wenn sich der Computer in einer Übergangsphase befindet, z. B. beim Starten von Tasksequenzmedien oder einem PXE-fähigen Verteilungspunkt. Zur Unterstützung dieses Szenarios für E-HTTP-Clientverbindungen generiert Configuration Manager selbstsignierte Zertifikate mit einem benutzerdefinierten Objektbezeichner zum Signieren und Verschlüsseln. Diese Zertifikate werden zur eindeutigen Identifizierung des Clients verwendet. Diese selbstsignierten Zertifikate verwenden SHA-256 und haben eine Schlüssellänge von 2048 Bit. Wenn diese selbstsignierten Zertifikate kompromittiert sind, verhindern Sie, dass Angreifer sie verwenden, um sich als vertrauenswürdige Clients auszugeben. Blockieren Sie die Zertifikate im Knoten Zertifikate im Arbeitsbereich "Verwaltung ", Knoten "Sicherheit ".

Client- und Serverauthentifizierung

Wenn Clients eine Verbindung über E-HTTP herstellen, authentifizieren sie die Verwaltungspunkte entweder mit Active Directory Domain Services oder mit dem vertrauenswürdigen Stammschlüssel von Configuration Manager. Clients authentifizieren keine anderen Standortsystemrollen, z. B. Statusmigrationspunkte oder Softwareupdatepunkte.

Wenn ein Verwaltungspunkt einen Client zum ersten Mal mithilfe des selbstsignierten Clientzertifikats authentifiziert, bietet dieser Mechanismus ein Minimum an Sicherheit, da jeder Computer ein selbstsigniertes Zertifikat generieren kann. Verwenden Sie die Clientgenehmigung, um diesen Prozess zu verbessern. Nur vertrauenswürdige Computer genehmigen, entweder automatisch durch den Configuration Manager oder manuell durch einen Administrator Weitere Informationen finden Sie unter Verwalten von Clients.

Informationen zu SSL-Sicherheitslücken

Führen Sie die folgenden Aktionen aus, um die Sicherheit Ihrer Configuration Manager-Clients und -Server zu verbessern:

• Aktivieren Sie TLS 1.2 auf allen Geräten und Diensten. Informationen zum Aktivieren von TLS 1.2 für Configuration Manager finden Sie unter Aktivieren von TLS 1.2 für Configuration Manager.

• Deaktivieren Sie SSL 3.0, TLS 1.0 und TLS 1.1.

• Ordnen Sie die TLS-bezogenen Verschlüsselungssammlungen neu an.

Weitere Informationen finden Sie in den folgenden Artikeln:

• Einschränken der Verwendung bestimmter kryptografischer Algorithmen und Protokolle in „Schannel.dll“
• Priorisieren von Schannel-Verschlüsselungssammlungen

Diese Verfahren wirken sich nicht auf die Funktionalität des Configuration Manager aus.