Technische Referenz zu kryptografischen Steuerelementen

  • Artikel

Gilt für: Configuration Manager (Current Branch)

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

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

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

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

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

Für Clients mit Version 2103 und früher ist der primäre Verschlüsselungsalgorithmus 3DES.

Hinweis

Wenn Sie die HTTPS-Kommunikation konfigurieren, werden diese Nachrichten zweimal verschlüsselt. Die Nachricht wird mit AES verschlüsselt, dann wird der HTTPS-Transport mit AES verschlüsselt.

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

Aus Gründen der Transportsicherheit unterstützt alles, was TLS verwendet, AES. Diese Unterstützung schließt ein, wenn Sie den Standort für erweitertes 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 die Verschlüsselungssammlungen für cloudbasierte Rollen wie das Cloudverwaltungsgateway (CLOUD Management Gateway, CMG).

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 Standortvorgänge.

Standortvorgänge

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

Richtliniensignatur und -verschlüsselung

Der Standort signiert Clientrichtlinienzuweisungen mit seinem selbstsignierten Zertifikat. Dieses Verhalten verhindert, dass das Sicherheitsrisiko eines kompromittierten Verwaltungspunkts manipulierte Richtlinien sendet. Wenn Sie die internetbasierte Clientverwaltung verwenden, ist dieses Verhalten wichtig, da dafür ein Verwaltungspunkt mit Internetzugriff erforderlich ist.

Wenn die Richtlinie vertrauliche Daten enthält, verschlüsselt der Verwaltungspunkt sie ab Version 2107 mit AES-256. In Version 2103 und früher wird 3DES verwendet. Richtlinie, die vertrauliche Daten enthält, wird nur an autorisierte Clients gesendet. Die Website verschlüsselt keine Richtlinie, die keine vertraulichen Daten enthält.

Wenn ein Client eine Richtlinie speichert, verschlüsselt er die Richtlinie mithilfe der Windows-Datenschutzanwendungsprogrammierschnittstelle (DPAPI).

Richtlinienhashing

Wenn ein Client eine Richtlinie anfordert, erhält er zuerst eine Richtlinienzuweisung. Dann weiß sie, welche Richtlinien auf sie angewendet werden, und sie kann nur diese Richtlinientexte anfordern. Jede Richtlinienzuweisung enthält den berechneten Hash für den entsprechenden Richtlinientext. Der Client lädt die entsprechenden 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 die Richtlinie ist SHA-256.

Inhaltshashing

Der Verteilungs-Manager-Dienst auf dem Standortserver erstellt einen Hash für die Inhaltsdateien für alle Pakete. Der Richtlinienanbieter schließt 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 angegebenen Hash. Wenn die Hashes übereinstimmen, wird der Inhalt nicht geändert, und der Client installiert ihn. Wenn ein einzelnes Byte des Inhalts geändert wird, stimmen die Hashes nicht überein, und der Client installiert die Software nicht. Diese Überprüfung hilft sicherzustellen, dass die richtige Software installiert ist, da der tatsächliche Inhalt mit der Richtlinie verglichen wird.

Der Standardhashalgorithmus für Inhalte ist SHA-256.

Nicht alle Geräte können Das Hashing von Inhalten unterstützen. Zu den Ausnahmen gehören:

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

  • Windows Mobile-Clients überprüfen jedoch die Signatur einer Anwendung, die von einer vertrauenswürdigen Quelle signiert wurde.

Inventursignierung und -verschlüsselung

Wenn ein Client die Hardware- oder Softwareinventur an einen Verwaltungspunkt sendet, wird der Bestand immer signiert. Es spielt keine Rolle, ob der Client über HTTP oder HTTPS mit dem Verwaltungspunkt kommuniziert. Wenn sie HTTP verwenden, können Sie diese Daten auch verschlüsseln, was empfohlen wird.

Verschlüsselung der Zustandsmigration

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 User State Migration Tool (USMT) mit dem AES-256-Verschlüsselungsalgorithmus aus. In Version 2010 und früheren Versionen wird 3DES verwendet.

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-Algorithmus . Wenn Sie die Verschlüsselung aktivieren, ist keine andere Zertifikatkonfiguration erforderlich. Der Multicast-fä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 Windows-Standard-APIs auf dem Multicast-fä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, wird das von der PKI ausgestellte Clientauthentifizierungszertifikat verwendet. Wenn der Client HTTP verwendet, wird das selbstsignierte Zertifikat verwendet. 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 Umgebungsvariablen der Tasksequenz mit AES-128 verschlüsselt. Andere Daten auf den Medien, einschließlich Paketen und Inhalten für Anwendungen, werden nicht verschlüsselt.

Verschlüsselung für cloudbasierte Inhalte

Wenn Sie ein Cloudverwaltungsgateway (CMG) zum Speichern von Inhalten aktivieren, werden die Inhalte mit AES-256 verschlüsselt. Der Inhalt wird bei jeder Aktualisierung verschlüsselt. Wenn Clients den Inhalt herunterladen, wird er verschlüsselt und durch die HTTPS-Verbindung geschützt.

Anmelden bei Softwareupdates

Alle Softwareupdates müssen von einem vertrauenswürdigen Herausgeber signiert werden, um sich vor Manipulationen zu schützen. Auf Clientcomputern sucht der Windows Update-Agent (WUA) nach updates aus dem Katalog. Das Update wird nicht installiert, wenn das digitale Zertifikat nicht im Speicher für vertrauenswürdige Herausgeber auf dem lokalen Computer 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 verwenden, um den Updatekatalog zu veröffentlichen, 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 intranetfähigem Microsoft Update Service-Speicherort zulassen auf dem lokalen Computer aktiviert ist. Diese Richtlinieneinstellung muss aktiviert sein, damit WUA nach updates sucht, 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, warnt die Konsole Sie, 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 Clientbenachrichtigungen

Wenn Sie clientbenachrichtigungen verwenden, verwendet die gesamte Kommunikation TLS und die höchsten Algorithmen, die server- und clientseitig aushandeln können. Beispielsweise können alle unterstützten Windows-Betriebssystemversionen mindestens die AES-128-Verschlüsselung verwenden. Die gleiche Aushandlung erfolgt für das Hashing der Pakete, die während der Clientbenachrichtigung übertragen werden, wobei SHA-2 verwendet wird.

Zertifikate

Eine Liste der PKI-Zertifikate (Public Key-Infrastruktur), die von Configuration Manager verwendet werden können, alle besonderen Anforderungen oder Einschränkungen sowie die Verwendung der Zertifikate finden Sie unter PKI-Zertifikatanforderungen. Diese Liste enthält die unterstützten Hashalgorithmen und Schlüssellängen. Die meisten Zertifikate unterstützen die Schlüssellänge 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.

Hinweis

Alle Zertifikate, die Configuration Manager verwendet, dürfen nur Einzelbytezeichen im Antragstellernamen oder alternativen Antragstellernamen enthalten.

Configuration Manager erfordert PKI-Zertifikate für die folgenden Szenarien:

  • Wenn Sie Configuration Manager Clients im Internet verwalten

  • Wenn Sie Configuration Manager Clients auf mobilen Geräten verwalten

  • Wenn Sie macOS-Computer verwalten

  • Bei Verwendung eines Cloudverwaltungsgateways (CLOUD Management Gateway, CMG)

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

Configuration Manager verwendet keine PKI-Zertifikate, wenn mobile Geräte mithilfe des Exchange Server-Connectors verwaltet werden.

Verwaltung mobiler Geräte und PKI-Zertifikate

Wenn das mobile Gerät nicht vom Mobilfunkanbieter gesperrt ist, können Sie Configuration Manager verwenden, um ein Clientzertifikat anzufordern und zu installieren. Dieses Zertifikat ermöglicht die gegenseitige Authentifizierung zwischen dem Client auf dem mobilen Gerät und Configuration Manager Standortsystemen. Wenn das mobile Gerät gesperrt ist, können Sie Configuration Manager nicht zum Bereitstellen von Zertifikaten verwenden.

Wenn Sie die Hardwareinventur für mobile Geräte aktivieren, inventarisieren Configuration Manager auch die Zertifikate, die auf dem mobilen Gerät installiert sind.

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 ist auch dann erforderlich, 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 Standortservereigenschaften, und fügen Sie auch 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 vertrauliche Daten zu schützen, die in der Tasksequenz konfiguriert sind, konfigurieren Sie ein Kennwort auf dem startbaren Medium. Jeder Computer, der von den startbaren Medien gestartet wird, verwendet dasselbe Zertifikat mit dem Verwaltungspunkt, das für Clientfunktionen wie das Anfordern einer Clientrichtlinie erforderlich ist.

Wenn Sie PXE verwenden, importieren Sie das Clientauthentifizierungszertifikat in den PXE-fähigen Verteilungspunkt. Sie verwendet dasselbe Zertifikat für jeden Client, der von diesem PXE-fähigen Verteilungspunkt startet. 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 Configuration Manager das Betriebssystem 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 Softwarehersteller (Independent Software Vendors, ISVs) können Anwendungen erstellen, die Configuration Manager erweitern. Beispielsweise könnte ein ISV Erweiterungen erstellen, um Nicht-Windows-Clientplattformen wie macOS zu unterstützen. Wenn die Standortsysteme jedoch HTTPS-Clientverbindungen erfordern, müssen diese Clients auch PKI-Zertifikate für die Kommunikation mit dem Standort verwenden. Configuration Manager umfasst 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 zu diesem Produkt.

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

Kopieren der GUID für das ISV-Proxyzertifikat

Ab Version 2111 können Sie die GUID in der Configuration Manager-Konsole kopieren, um die Verwaltung dieser ISV-Proxyzertifikate zu vereinfachen.

  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 Zertifikat-GUID kopieren aus.

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

Asset Intelligence und Zertifikate

Configuration Manager wird mit einem X.509-Zertifikat installiert, das der Asset Intelligence-Synchronisierungspunkt verwendet, um eine Verbindung mit Microsoft herzustellen. Configuration Manager verwendet dieses Zertifikat, um ein Clientauthentifizierungszertifikat vom Microsoft-Zertifikatdienst anzufordern. Das Clientauthentifizierungszertifikat wird auf dem Asset Intelligence-Synchronisierungspunkt installiert und für die Authentifizierung des Servers bei Microsoft verwendet. Configuration Manager verwendet das Clientauthentifizierungszertifikat, um den Asset Intelligence-Katalog herunterzuladen und Softwaretitel hochzuladen.

Dieses Zertifikat hat eine Schlüssellänge von 1024 Bits.

Azure-Dienste und -Zertifikate

Das Cloudverwaltungsgateway (CMG) erfordert Serverauthentifizierungszertifikate. Diese Zertifikate ermöglichen es dem Dienst, HTTPS-Kommunikation für Clients über das Internet bereitzustellen. Weitere Informationen finden Sie unter CMG-Serverauthentifizierungszertifikat.

Clients benötigen eine andere Art der Authentifizierung, um mit einem CMG und dem lokalen Verwaltungspunkt zu kommunizieren. Sie können Microsoft Entra-ID, ein PKI-Zertifikat oder ein Standorttoken verwenden. Weitere Informationen finden Sie unter Konfigurieren der Clientauthentifizierung für das Cloudverwaltungsgateway.

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

CRL-Überprüfung auf PKI-Zertifikate

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

IIS aktiviert standardmäßig die Zertifikatsperrlistenüberprüfung. Wenn Sie eine Zertifikatsperrliste 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, die einen manuellen Schritt erfordern, um die Zertifikatsperrlistenüberprüfung zu aktivieren, um die Signaturen in Softwareupdatedateien zu überprüfen.

Wenn ein Client HTTPS verwendet, wird standardmäßig die CRL-Überprüfung aktiviert. Für macOS-Clients können Sie die CRL-Überprüfung nicht deaktivieren.

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

  • Server-zu-Server-Verbindungen

  • Mobile Geräte, die von Configuration Manager registriert werden.

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 gleichen Configuration Manager Standort zu übertragen. Einige Standortsystemrollen verwenden auch Zertifikate für die Authentifizierung. Wenn Sie z. B. den Registrierungsproxypunkt auf einem Server und den Registrierungspunkt auf einem anderen Server installieren, können sie sich mithilfe dieses Identitätszertifikats gegenseitig authentifizieren.

Wenn Configuration Manager ein Zertifikat für diese Kommunikation verwendet und ein PKI-Zertifikat mit Serverauthentifizierungsfunktion verfügbar ist, verwendet Configuration Manager es automatisch. Andernfalls generiert Configuration Manager ein selbstsigniertes Zertifikat. Dieses selbstsignierte Zertifikat verfügt über eine Serverauthentifizierungsfunktion, verwendet SHA-256 und hat eine Schlüssellänge von 2048 Bits. Configuration Manager kopiert das Zertifikat in den vertrauenswürdigen Personen speicher auf anderen Standortsystemservern, die dem Standortsystem möglicherweise vertrauen müssen. Standortsysteme können sich dann mit diesen Zertifikaten und PeerTrust gegenseitig vertrauen.

Zusätzlich zu diesem Zertifikat für jeden Standortsystemserver generiert Configuration Manager ein selbstsigniertes Zertifikat für die meisten Standortsystemrollen. Wenn mehrere instance der Standortsystemrolle am gleichen Standort vorhanden sind, verwenden diese dasselbe Zertifikat. Beispielsweise können Mehrere Verwaltungspunkte am gleichen Standort vorhanden sein. Dieses selbstsignierte Zertifikat verwendet SHA-256 und hat eine Schlüssellänge von 2048 Bits. Sie wird in den vertrauenswürdigen Personen Store auf Standortsystemservern kopiert, die ihr möglicherweise vertrauen müssen. Die folgenden Standortsystemrollen generieren dieses Zertifikat:

  • Asset Intelligence-Synchronisierungspunkt

  • Zertifikatregistrierungspunkt

  • Endpoint Protection-Punkt

  • Registrierungspunkt

  • Fallback status Punkt

  • Verwaltungspunkt

  • Multicast-fähiger Verteilungspunkt

  • Reporting Services-Punkt

  • Softwareupdatepunkt

  • Zustandsmigrationspunkt

Configuration Manager generiert und verwaltet diese Zertifikate automatisch.

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

Serverkommunikation zwischen Standorten

Configuration Manager Übertragen von 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 Configuration Manager selbstsignierte Zertifikate für die Serverauthentifizierung. In beiden Fällen wird die Authentifizierung zwischen Standorten mithilfe von Zertifikaten im Speicher für vertrauenswürdige Personen verwendet, der PeerTrust verwendet. Dieser Zertifikatspeicher wird verwendet, um sicherzustellen, dass nur die Configuration Manager Hierarchie SQL Server an der Site-to-Site-Replikation teilnehmen.

Standortserver richten die Site-to-Site-Kommunikation mithilfe eines sicheren Schlüsselaustauschs ein, der automatisch erfolgt. Der sendenden Standortserver 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 die SQL Server Service Broker, um Daten zwischen Standorten zu übertragen. 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 Zertifikate im persönlichen Zertifikatspeicher des Computers verwendet.

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

Bei der dateibasierten Replikation wird das SMB-Protokoll (Server Message Block) verwendet. Es verwendet SHA-256 zum Signieren von Daten, die nicht verschlüsselt sind und keine vertraulichen Daten enthalten. Verwenden Sie zum Verschlüsseln dieser Daten IPsec, das Sie unabhängig von 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-zu-Server-Kommunikation zu schützen. Das Konfigurieren von HTTPS-Clientverbindungen ohne umfassende Kenntnisse der PKI-Planung, -Bereitstellung und -Vorgänge kann Sie jedoch weiterhin anfällig machen. Wenn Sie z. B. Ihre Stammzertifizierungsstelle (Ca) nicht schützen, können Angreifer die Vertrauensstellung Ihrer gesamten PKI-Infrastruktur gefährden. Wenn Die PKI-Zertifikate nicht mithilfe von kontrollierten und geschützten Prozessen bereitgestellt und verwaltet werden, kann dies dazu führen, dass nicht verwaltete Clients keine kritischen Softwareupdates oder -pakete empfangen können.

Wichtig

Die PKI-Zertifikate, die Configuration Manager für die Clientkommunikation verwenden, schützen nur die Kommunikation zwischen dem Client und einigen Standortsystemen. Sie schützen nicht den Kommunikationskanal zwischen dem Standortserver und Standortsystemen oder zwischen Standortservern.

Unverschlüsselte Kommunikation, wenn Clients HTTPS verwenden

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

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

  • Kommunikation mit den folgenden Standortsystemrollen:

    • Der Client sendet Zustandsmeldungen an den Fallbackpunkt status.

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

    • Der Client sendet Benachrichtigungsdaten an einen Verwaltungspunkt.

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

Clients, die HTTP verwenden

Wenn Clients HTTP-Kommunikation mit Standortsystemrollen verwenden, können sie PKI-Zertifikate für die Clientauthentifizierung oder selbstsignierte Zertifikate verwenden, die Configuration Manager generiert. Wenn Configuration Manager selbstsignierte Zertifikate generiert, verfügen sie über einen benutzerdefinierten Objektbezeichner zum Signieren und Verschlüsseln. Diese Zertifikate werden verwendet, um den Client eindeutig zu identifizieren. Diese selbstsignierten Zertifikate verwenden SHA-256 und haben eine Schlüssellänge von 2048 Bit.

Betriebssystembereitstellung und selbstsignierte Zertifikate

Wenn Sie Configuration Manager verwenden, um Betriebssysteme mit selbstsignierten Zertifikaten bereitzustellen, muss der Client auch über ein Zertifikat verfügen, um mit dem Verwaltungspunkt kommunizieren zu können. Diese Anforderung gilt auch, 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 HTTP-Clientverbindungen generiert Configuration Manager selbstsignierte Zertifikate, die über einen benutzerdefinierten Objektbezeichner zum Signieren und Verschlüsseln verfügen. Diese Zertifikate werden verwendet, um den Client eindeutig zu identifizieren. Diese selbstsignierten Zertifikate verwenden SHA-256 und haben eine Schlüssellänge von 2048 Bit. Wenn diese selbstsignierten Zertifikate kompromittiert werden, verhindern Sie, dass Angreifer sie verwenden, um die Identität vertrauenswürdiger Clients zu annehmen. Blockieren Sie die Zertifikate im Knoten Zertifikate im Arbeitsbereich Verwaltung , Knoten Sicherheit .

Client- und Serverauthentifizierung

Wenn Clients eine Verbindung über HTTP herstellen, authentifizieren sie die Verwaltungspunkte entweder mithilfe von Active Directory Domain Services oder mithilfe des Configuration Manager vertrauenswürdigen Stammschlüssels. Clients authentifizieren keine anderen Standortsystemrollen, z. B. Zustandsmigrationspunkte oder Softwareupdatepunkte.

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

Informationen zu SSL-Sicherheitsrisiken

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

  • Aktivieren Sie TLS 1.2 für alle Geräte und Dienste. 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:

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

Hinweis

Updates sie Configuration Manager herunterladen aus dem Azure Content Delivery Network (CDN), das Verschlüsselungssammlungsanforderungen aufweist. Weitere Informationen finden Sie unter Azure Front Door: Häufig gestellte Fragen zur TLS-Konfiguration.