Technische Referenz für kryptografische Steuerelemente

Gilt für: Configuration Manager (Current Branch)

Configuration Manager verwendet die Signierung und Verschlüsselung zum Schutz der Geräteverwaltung in der Configuration Manager-Hierarchie. Wenn Daten bei der Übertragung verändert wurden, werden sie mit der Signierung verworfen. Bei der Verschlüsselung wird mithilfe einer Netzwerkprotokollanalyse verhindert, dass ein Angreifer die Daten lesen kann.

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

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

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

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

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

Hinweis

Wenn Sie die HTTPS-Kommunikation konfigurieren, werden diese Nachrichten doppelt verschlüsselt. Die Nachricht wird mit AES verschlüsselt. Anschließend wird der HTTPS-Transport ebenfalls mit AES verschlüsselt.

Wenn Sie Client-Kommunikation über HTTPS verwenden, konfigurieren Sie Ihre Public-Key-Infrastruktur (PKI) um Zertifikate mit den maximalen Hash-Algorithmen und Schlüssellängen zu verwenden. Bei der Verwendung von CNG v3-Zertifikaten unterstützen die Configuration Manager-Clients nur Zertifikate, die den kryptografischen RSA-Algorithmus verwenden. Weitere Informationen finden Sie unter PKI-Zertifikatanforderungen und eine Übersicht über CNG v3-Zertifikate.

Aus Gründen der Transportsicherheit unterstützt alles, was TLS verwendet, AES. Diese Unterstützung ist inklusive, wenn Sie die Website für erweitertes HTTP oder HTTPS konfigurieren. Für lokale Standortsysteme können Sie die TLS-Cipher Suites steuern. Bei Cloud-basierten Rollen wie dem Cloud Management Gateway (CMG) konfiguriert der Configuration Manager die Cipher Suites, wenn Sie TLS 1.2 aktivieren.

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

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

Standortvorgänge

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

Signieren und Verschlüsseln von Richtlinien

Die Site signiert Client-Richtlinienzuweisungen mit ihrem selbstsignierten Zertifikat. Dieses Verhalten verhindert, dass das Sicherheitsrisiko eines kompromittierten Verwaltungspunkts manipulierte Richtlinien sendet. Wenn Sie die internetbasierte Clientverwaltungverwenden, ist dieses Verhalten wichtig, da es einen Verwaltungspunkt mit Internetzugriff erfordert.

Wenn die Richtlinie ab Version 2107 vertrauliche Daten enthält, verschlüsselt der Verwaltungspunkt diese mit AES-256. In Version 2103 und früher wird 3DES verwendet. Eine Richtlinie, die sensible Daten enthält, wird ausschließlich an autorisierte Clients gesendet. Die Site verschlüsselt keine Richtlinie, die keine vertraulichen Daten enthält.

Wenn ein Client eine Richtlinie speichert, verschlüsselt er die Richtlinie anhand der Windows-Datenschutzanwendungsprogrammierschnittstelle (Data Protection Application Programming Interface, DPAPI).

Hashwert von Richtlinien

Wenn ein Client eine Richtlinie anfordert, erhält er zuerst eine Richtlinienzuweisung. Anschließend weiß er, welche Richtlinien auf ihn angewendet werden, und er kann nur diese Richtlinienstellen anfordern. Jede Richtlinienzuordnung enthält den errechneten Hashwert für den entsprechenden Richtlinientext. Der Client lädt die zutreffenden Richtlinientext herunter und berechnet dann den Hash-Wert für jeden Richtlinientext. Stimmt der Hashwert des heruntergeladenen Richtlinientexts nicht mit dem Hashwert der Richtlinienzuordnung überein, wird der Richtlinientext vom Client verworfen.

Der Hashalgorithmus für Richtlinien ist SHA-256.

Inhaltshashing

Der Verteilungs-Manager-Dienst des Standortservers erstellt einen Hashwert für die Inhaltsdateien aller Pakete. Der Richtlinienanbieter bindet den Hashwert in die Softwareverteilungsrichtlinie ein. Wenn der Inhalt vom Configuration Manager-Client heruntergeladen wird, wird der Hashwert vom Client lokal erneut generiert und mit dem Hashwert der Richtlinie verglichen. Wenn die Hashes übereinstimmen, wird der Inhalt nicht verändert, und der Client installiert ihn. Wenn ein einziges Byte des Inhalts verändert wird, stimmen die Hashes nicht überein, und der Client installiert die Software nicht. Diese Prüfung hilft sicherzustellen, dass die richtige Software installiert wird, da der tatsächliche Inhalt mit der Richtlinie verglichen wird.

Der Standard-Hashing-Algorithmus für Inhalte ist SHA-256.

Die Verwendung von Inhaltshashs wird nicht von allen Geräten unterstützt. Ausnahmen sind:

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

  • Windows Mobile-Clients, obwohl diese Clients die Signatur einer Anwendung überprüfen, die von einer vertrauenswürdigen Quelle signiert ist.

Signieren und Verschlüsseln der Inventur

Wenn ein Client Hardware- oder Software-Inventar an eine Verwaltungsstelle sendet, signiert er das Inventar immer. Es spielt keine Rolle, ob der Client über HTTP oder HTTPS mit dem Verwaltungspunkt kommuniziert. Wenn sie HTTP verwenden, können Sie auch wählen, diese Daten zu verschlüsseln, was empfohlen wird.

Zustandsmigrationsverschlüsselung

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 mit dem Verschlüsselungsalgorithmus AES-256 aus. In Version 2010 und früher wird 3DES verwendet.

Verschlüsselung für Multicastpakete

Für jedes Betriebssystem-Bereitstellungspaket 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 zusätzliche Konfiguration für das Zertifikat erforderlich. Der multicastfähige Verteilungspunkt erstellt automatisch symmetrische Schlüssel zur Paketverschlüsselung. Jedes Paket erhält einen anderen Verschlüsselungsschlüssel. Der Schlüssel wird mithilfe von Windows-Standard-APIs auf dem multicastfähigen Verteilungspunkt gespeichert.

Wenn sich der Client mit der Multicast-Session verbindet, 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 HTTP verwendet, verwendet er das selbstsignierte Zertifikat. Der Client speichert den Schlüssel zur Verschlüsselung nur während der Multicast-Session im Arbeitsspeicher.

Verschlüsselung für Betriebssystembereitstellungsmedien

Wenn Sie Medien zur Bereitstellung von Betriebssystemen verwenden, sollten Sie immer ein Passwort zum Schutz der Medien angeben. Mit einem Passwort werden die Umgebungsvariablen der Tasksequenz mit AES-128 verschlüsselt. Andere Daten auf den Medien, wie beispielsweise Pakete und Inhalte für Anwendungen, werden nicht verschlüsselt.

Verschlüsselung für cloudbasierte Inhalte

Wenn Sie eine Cloud Management Gateway-Instanz (CMG) so konfigurieren, dass Inhalte gespeichert werden können, wird der Inhalt mit AES-256 verschlüsselt. Der Inhalt wird verschlüsselt, wenn Sie ihn aktualisieren. Wenn der Inhalt von Clients heruntergeladen wird, wird er verschlüsselt und ist per HTTPS-Verbindung geschützt.

Signieren von Softwareupdates

Alle Softwareupdates müssen zum Schutz vor Manipulation von einem vertrauenswürdigen Herausgeber signiert werden. Auf Client-Computern sucht der Windows Update Agent (WUA) nach den Aktualisierungen aus dem Katalog. Die Aktualisierung wird nicht installiert, wenn das digitale Zertifikat nicht im Speicher der vertrauenswürdigen Herausgeber auf dem lokalen Computer gefunden werden kann.

Wenn Sie Softwareaktualisierungen mit System Center Updates Publisher veröffentlichen, signiert ein digitales Zertifikat die Softwareaktualisierungen. Sie können entweder ein PKI-Zertifikat angeben oder festlegen, dass Updates Publisher ein selbstsigniertes Zertifikat zum Signieren des Softwareupdates generieren soll. Wenn Sie für die Veröffentlichung des Aktualisierungskatalogs ein selbstsigniertes Zertifikat verwenden, wie z. B. WSUS Publishers Self-signed, muss sich das Zertifikat auch im Zertifikatspeicher der Trusted Root Certification Authorities auf dem lokalen Computer befinden. Die WUA prüft auch, ob die Gruppenrichtlinieneinstellung Signierte Inhalte vom Intranet-Speicherort des Microsoft-Update-Dienstes zulassen auf dem lokalen Computer aktiviert ist. Diese Richtlinieneinstellung muss für WUA aktiviert sein, damit Aktualisierungen überprüft werden können, die anhand vom System Center Update Publisher erstellt und veröffentlicht wurden.

Signierte Konfigurationsdaten für Kompatibilitätseinstellungen

Beim Importieren von Konfigurationsdaten ü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, den Import nicht fortzusetzen. Sie sollten mit dem Import der Konfigurationsdaten nur fortfahren, wenn Sie dem Herausgeber und der Integrität der Daten wirklich vertrauen.

Verschlüsselung und Hashing für die Clientbenachrichtigung

Wenn Sie die Client-Benachrichtigung verwenden, verwendet die gesamte Kommunikation TLS sowie die höchsten Algorithmen, die der Server und der Client aushandeln können. Beispielsweise können alle unterstützten Windows-Betriebssystemversionen mindestens die AES-128-Verschlüsselung verwenden. Das gleiche Aushandeln erfolgt für das Hashing der Pakete, die bei der Clientbenachrichtigung übertragen werden, die SHA-2 verwendet.

Zertifikate

Eine Liste der PKI-Zertifikate, die von Configuration Manager verwendet werden können, eine Übersicht über spezielle Anforderungen oder Einschränkungen sowie Informationen zur 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 eine SHA-256 und 2048-Bit-Schlüssellänge.

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

Hinweis

Alle von Configuration Manager verwendeten Zertifikate dürfen im Antragstellernamen oder alternativen Antragstellernamen nur Einzelbyte-Zeichen enthalten.

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

  • Wenn Sie den Configuration Manager-Clients über das Internet verwalten

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

  • Wenn Sie macOS-Computer verwalten

  • Wenn Sie ein Cloudverwaltungsgateway verwenden

Für die meisten anderen Kommunikationsvorgänge, die Zertifikate zur Authentifizierung, Signierung oder Verschlüsselung erfordern, verwendet Configuration Manager automatisch PKI-Zertifikate, sofern diese verfügbar sind. Wenn sie nicht verfügbar sind, erstellt der Configuration Manager selbstsignierte Zertifikate.

Bei der Verwaltung mobiler Geräte über den Exchange Server-Connector verwendet Configuration Manager keine PKI-Zertifikate.

Verwaltung mobiler Geräte und PKI-Zertifikate

Wenn das mobile Gerät nicht durch den mobilen Betreiber gesperrt wurde, können Sie den Configuration Manager verwenden um ein Clientzertifikat anzufordern und zu installieren. Dieses Zertifikat sorgt für die gegenseitige Authentifizierung zwischen dem Client auf dem mobilen Gerät und den Configuration Manager-Site-Systemen. Wenn Ihr mobiles Gerät gesperrt ist, können Sie den Configuration Manager nicht zur Bereitstellung von Zertifikaten verwenden.

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

Betriebssystembereitstellung und PKI-Zertifikate

Wenn Sie den 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, wenn sich der Client in einer Übergangsphase befindet, z. B. beim Hochfahren von Tasksequenzmedien oder einem PXE-fähigen Verteilungspunkt. Um dieses Szenario zu unterstützen, erstellen Sie ein PKI-Client-Authentifizierungszertifikat und exportieren es mit dem privaten Schlüssel. Importieren Sie es dann in die Eigenschaften des Site-Servers, und fügen Sie auch das Trusted Root CA-Zertifikat des Verwaltungspunkts hinzu.

Wenn Sie startbare Medien erstellen, importieren Sie das Clientauthentifizierungszertifikat bei der Erstellung des startbaren Mediums. Konfigurieren Sie zum Schutz des privaten Schlüssels und anderer sensibler Daten, die in der Tasksequenz konfiguriert werden, ein Passwort für das startbare Medium. Jeder Computer, der vom startfähigen Medium hochfährt, verwendet dasselbe Zertifikat mit dem Verwaltungspunkt, das für Client-Funktionen wie das Anfordern von Client-Richtlinien erforderlich ist.

Wenn Sie PXE verwenden, importieren Sie das Client-Authentifizierungszertifikat in den PXE-fähigen Verteilungspunkt. Das gleiche Zertifikat wird für jeden Client verwendet, der von diesem PXE-fähigen Verteilungspunkt hochfährt. Um den privaten Schlüssel und andere sensible Daten in den Tasksequenzen zu schützen, benötigen Sie ein Passwort für PXE.

Sollte eines dieser Clientauthentifizierungszertifikate gefährdet sein, sperren Sie die Zertifikate im Arbeitsbereich Verwaltung über die Knoten Zertifikate und Sicherheit . Sie benötigen die Berechtigung zur Verwaltung des Zertifikats zur Betriebssystembereitstellung, um diese Zertifikate verwalten zu können.

Nachdem der Configuration-Manager bereitgestellt ist, installiert das Betriebssystem den Client, 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 zum Erweitern von Configuration Manager erstellen. Ein ISV kann beispielsweise Erweiterungen erstellen, um Nicht-Windows-Plattformen (z. B. macOS) zu unterstützen. Wenn für die Standortsysteme jedoch HTTPS-Clientverbindungen erforderlich sind, müssen von diesen Clients ebenfalls PKI-Zertifikate für die Kommunikation mit dem Standort verwendet werden. Configuration Manager bietet die Möglichkeit, dem ISV-Proxy ein Zertifikat zuzuweisen, über das die Kommunikation zwischen den ISV-Proxyclients und dem Verwaltungspunkt ermöglicht wird. Wenn Sie Erweiterungen verwenden, die ISV-Proxyzertifikate erfordern, sollten Sie die Dokumentation des Produkts zu Hilfe nehmen.

Sollte das ISV-Zertifikat gefährdet sein, sperren Sie das Zertifikat im Arbeitsbereich Verwaltung über die Knoten Zertifikate und Sicherheit .

Asset Intelligence und Zertifikate

Configuration Manager wird mit einem X.509-Zertifikat installiert, über das vom Asset Intelligence-Synchronisierungspunkt eine Verbindung mit Microsoft hergestellt wird. Configuration Manager verwendet dieses Zertifikat, um ein Clientauthentifizierungszertifikat vom Microsoft-Zertifikatdienst anzufordern. Das Client-Authentifizierungszertifikat ist auf dem Asset Intelligence-Synchronisierungspunkt installiert und wird zur Authentifizierung des Servers gegenüber der Microsoft verwendet. In Configuration Manager dient das Clientauthentifizierungszertifikat zum Herunterladen des Asset Intelligence-Katalogs und zum Hochladen von Softwaretiteln.

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

Azure-Dienste und -Zertifikate

Cloud Management Gateway-Instanzen erfordern Serverauthentifizierungszertifikate. Anhand dieser Zertifikate kann der Dienst die HTTPS-Kommunikation für Clients über das Internet bereitstellen. 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 Azure Active Directory, ein PKI-Zertifikat oder ein Site-Token verwenden. Weitere Informationen finden Sie unter Konfigurieren der Client-Authentifizierung für das Cloud-Management-Gateway.

Clients benötigen kein Client-PKI-Zertifikat, um cloudbasierten Speicher zu verwenden. Nachdem sie sich beim Verwaltungspunkt authentifiziert haben, stellt der Verwaltungspunkt ein Configuration Manager-Zugriffstoken an den Client aus. Der Client präsentiert dieses Token der CMG-Instanz, um auf die Inhalte zuzugreifen. Das Token ist acht Stunden lang gültig.

Überprüfen der Zertifikatsperrlisten für PKI-Zertifikate

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

IIS aktiviert standardmäßig die Überprüfung der Zertifikatsperrlisten. Wenn Sie eine Zertifikatsperrliste mit Ihrer PKI-Bereitstellung verwenden, müssen Sie die meisten Standortsysteme, auf denen IIS ausgeführt wird, nicht konfigurieren. Eine Ausnahme sind Softwareupdates, die einen manuellen Schritt zum Aktivieren der CRL-Prüfung erfordern, damit die Signaturen in Softwareupdatedateien überprüft werden können.

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

Die folgenden Verbindungen unterstützen keine Überprüfung der Zertifikatsperrliste im Configuration Manager:

  • Server-zu-Server-Verbindungen

  • Von Configuration Manager registrierte mobile Geräte.

Serverkommunikation

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

Serverkommunikation innerhalb eines Standorts

Jeder Standortsystemserver verwendet ein Zertifikat zur Datenübertragung auf andere Standortsysteme innerhalb des gleichen Configuration Manager-Standorts. Von einigen Standortsystemrollen werden auch Zertifikate für die Authentifizierung verwendet. Wenn Sie beispielsweise den Anmeldungsproxypunkt auf einem Server und den Anmeldungspunkt auf einem anderen Server installieren, erfolgt die gegenseitige Authentifizierung über dieses Identitätszertifikat.

Wenn der Configuration Manager ein Zertifikat für diese Kommunikation verwendet, und wenn ein PKI-Zertifikat mit der Serverauthentifizierungsfunktion verfügbar ist, verwendet es der Configuration Manager automatisch. Andernfalls erstellt der Configuration Manager ein selbstsigniertes Zertifikat. Von diesem selbstsignierten Zertifikat, das Serverauthentifizierungsfunktionen hat, wird SHA-256 verwendet und eine Schlüssellänge von 2048 Bit unterstützt. Configuration Manager kopiert das Zertifikat in den Speicher für vertrauenswürdige Personen auf anderen Standortsystemservern, von denen das Standortsystem möglicherweise als vertrauenswürdig eingestuft werden muss. Mithilfe dieser Zertifikate und PeerTrust wird eine bidirektionale Vertrauensstellung zwischen Standortsystemen ermöglicht.

Zusätzlich zu diesem Zertifikat für jeden Standortsystemserver generiert Configuration Manager für die meisten Standortsystemrollen ein selbstsigniertes Zertifikat. Wenn es von einer Standortsystemrolle mehrere Instanzen am gleichen Standort gibt, gilt für alle Instanzen das gleiche Zertifikat. Beispielsweise können sich an einem Standort mehrere Verwaltungspunkte befinden. Dieses selbstsignierte Zertifikat verwendet SHA-256 und hat eine Schlüssellänge von 2048 Bit. Es wird ebenfalls in den Trusted People Store auf den Site-Systemservern kopiert, von denen es möglicherweise als vertrauenswürdig eingestuft werden muss. Dieses Zertifikat wird von den folgenden Standortsystemrollen generiert:

  • Asset Intelligence-Synchronisierungspunkt

  • Zertifikatregistrierungspunkt

  • Endpoint Protection-Punkt

  • Anmeldungspunkt

  • Fallbackstatuspunkt

  • Verwaltungspunkt

  • Multicast-fähiger Verteilungspunkt

  • Reporting Services-Punkt

  • Softwareupdatepunkt

  • Zustandsmigrationspunkt

Der Configuration Manager erstellt und verwaltet diese Zertifikate automatisch.

Um Statusmeldungen vom Verteilungspunkt zum Verwaltungspunkt zu senden, verwendet der Configuration Manager ein Client-Authentifizierungszertifikat. 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. Er kann auch ein selbstsigniertes Zertifikat mit Client-Authentifizierungsfunktion verwenden, es verwendet SHA-256 und hat eine Schlüssellänge von 2048 Bit.

Serverkommunikation zwischen Standorten

Configuration Manager überträgt Daten zwischen den Standorten mithilfe von Datenbankreplikation und dateibasierter Replikation. Weitere Informationen finden Sie unter Datenübertragungen zwischen Sites und Kommunikation zwischen Endpunkten.

Der Configuration-Manager konfiguriert automatisch die Datenbankreplikation zwischen den Sites. Falls verfügbar, verwendet er PKI-Zertifikate mit Serverauthentifizierungsfähigkeit. Falls nicht verfügbar, erstellt der Configuration-Manager selbstsignierte Zertifikate für die Serverauthentifizierung. In beiden Fällen erfolgt die Authentifizierung zwischen Site anhand von Zertifikaten im Trusted People Store, der den PeerTrust verwendet. Dieser Zertifikatspeicher wird verwendet, um sicherzustellen, dass nur die Configuration Manager-Hierarchie SQL Server an der Site-To-Site-Replikation beteiligt sind.

Die Kommunikation zwischen Standorten wird von Standortservern mithilfe eines sicheren, automatisch ablaufenden Schlüsselaustausches eingerichtet. Vom sendenden Standortserver wird ein Hashwert generiert und mit seinem privaten Schlüssel signiert. Der empfangende Standortserver prüft die Signatur mithilfe des öffentlichen Schlüssels und vergleicht den Hashwert mit einem lokal erstellten Wert. Stimmen die Werte überein, werden die replizierten Daten vom empfangenden Standort akzeptiert. Wenn die Werte nicht übereinstimmen, weist der Configuration Manager die Replikationsdaten ab.

Die Datenbankreplikation in Configuration Manager verwendet den SQL Server Service Broker, um Daten zwischen Sites zu übertragen. Es verwendet die folgende Mechanismen:

  • SQL Server zu SQL Server: Diese Verbindung verwendet Windows-Anmeldeinformationen für die Server-Authentifizierung und selbstsignierte Zertifikate mit 1024 Bit zum Signieren und Verschlüsseln der Daten mit dem AES-Algorithmus.dards (Advanced Encryption Standard, AES) verwendet. Falls verfügbar, verwendet er PKI-Zertifikate mit Serverauthentifizierungsfähigkeit. Es werden nur Zertifikate im persönlichen Zertifikatspeicher 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 verwendet nur Zertifikate in der SQL Server Masterdatenbank.

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 vom Configuration Manager implementieren.

Clients, die HTTPS verwenden

Wenn von Standortsystemrollen Clientverbindungen akzeptiert werden, können Sie sie für Verbindungen über HTTPS und HTTPS bzw. nur über HTTPS konfigurieren. Site-Systemrollen, die Verbindungen aus dem Internet annehmen, akzeptieren nur Client-Verbindungen über HTTPS.

Bei Clientverbindungen über HTTPS ist ein höheres Maß an Sicherheit gegeben, da sie in eine Public Key-Infrastruktur (PKI) integriert werden, um die Kommunikation zwischen Clients und Servern zu schützen. Wenn Sie HTTPS-Clientverbindungen konfigurieren, ohne sich zuvor umfassend mit der PKI-Planung, -Bereitstellung und den PKI-Operationen vertraut gemacht zu haben, können jedoch immer noch Sicherheitslücken bestehen. Wenn Sie z. B. Ihre Root Certificate Authority (CA), nicht absichern, können Angreifer das Vertrauen in Ihre gesamte PKI-Infrastruktur gefährden. Werden die PKI-Zertifikate nicht mit kontrollierten und sicheren Prozessen bereitgestellt und verwaltet, kann dies dazu führen, dass nicht-verwaltete Clients keine kritischen Software-Aktualisierungen oder -Pakete erhalten können.

Wichtig

Die PKI-Zertifikate, die der Configuration Manager für die Client-Kommunikation verwendet, schützen die Kommunikation nur zwischen dem Client und einigen Site-Systemen. Sie schützen nicht den Kommunikationskanal zwischen dem Site-Server und Site-Systemen oder zwischen Site-Servern.

Unverschlüsselte Kommunikation, wenn Clients HTTPS verwenden

Wenn Clients über HTTPS mit Site-Systemen kommunizieren, wird der größte Teil des Datenverkehrs verschlüsselt. In den folgenden Situationen findet die Kommunikation der Clients mit Site-Systemen jedoch ohne Verschlüsselung statt:

  • Der Client kann keine HTTPS-Verbindung im Intranet herstellen und fällt auf die Verwendung von HTTP zurück, wenn die Site-Systeme diese Konfiguration zulassen.

  • Kommunikation mit den folgenden Standortsystemrollen:

    • Der Client sendet Zustandsmeldungen an den Fallback-Statuspunkt.

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

    • Der Client sendet Benachrichtigungsdaten an einen Verwaltungspunkt.

Sie konfigurieren die Meldedienstpunkte für die Verwendung von HTTP oder HTTPS, unabhängig vom Kommunikationsmodus des Clients.

Clients, die HTTPS verwenden

Wenn die Kommunikation zwischen Client und Standortsystemrollen über HTTP erfolgt, können für die Clientauthentifizierung PKI-Zertifikate oder von Configuration Manager generierte, selbstsignierte Zertifikate verwendet werden. Wenn der Configuration Manager selbstsignierte Zertifikate erstellt, haben sie 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 Bits.

Betriebssystembereitstellung und selbstsignierte Zertifikate

Wenn Sie den Configuration Manager für die Bereitstellung von Betriebssystemen mit selbstsignierten Zertifikaten verwenden, muss auch der Client über ein Zertifikat verfügen, um mit dem Verwaltungspunkt zu kommunizieren. Diese Anforderung gilt auch, wenn sich der Computer in einer Übergangsphase befindet, z. B. beim Hochfahren von Tasksequenz-Medien oder einem PXE-fähigen Verteilungspunkt. Um dieses Szenario für HTTP-Client-Verbindungen zu unterstützen, erstellt der 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 Bits. Wenn diese selbstsignierten Zertifikate kompromittiert sind, verhindern Sie, dass Angreifer sie verwenden, um sich als vertrauenswürdige Clients auszugeben. Sperren Sie die Zertifikate im Zertifikate-Knoten im Arbeitsbereich Verwaltung, Sicherheitsknoten.

Client- und Severauthentifizierung

Bei HTTP-Clientverbindungen werden Verwaltungspunkte entweder mithilfe der Active Directory Domain Services oder mithilfe des vertrauenswürdigen Configuration Manager-Stammschlüssels authentifiziert. Die Clients authentifizieren keine anderen Site-Systemrollen, wie z. B. Statusmigrationspunkte oder Softwareaktualisierungspunkte.

Bei der ersten Authentifizierung eines Clients von einem Verwaltungspunkt mithilfe des selbstsignierten Clientzertifikats bietet dieses Verfahren nur minimale Sicherheit, da selbstsignierte Zertifikate von jedem beliebigen Computer generiert werden können. Verwenden Sie die Clientgenehmigung, um diesen Vorgang zu optimieren. Genehmigen Sie nur vertrauenswürdige Computer, entweder automatisch durch den Configuration Manager oder manuell, durch einen administrativen Benutzer. Weitere Informationen finden Sie unter Verwalten von Clients.

Über SSL-Sicherheitsrisiken

Um die Sicherheit Ihrer Configuration Manager-Clients und -Server zu verbessern, führen Sie die folgenden Maßnahmen durch:

Weitere Informationen findest du in den folgenden Artikeln:

Diese Verfahren haben keine Auswirkungen auf die Configuration Manager-Funktionalität.

Hinweis

Der Configuration Manager-Download aus dem Azure Content Delivery Network (CDN), das Anforderungen an die Verschlüsselungssuite hat, wurde aktualisiert. Weitere Informationen finden Sie unter Azure Front Door: Häufig gestellte Fragen zur TLS-Konfiguration.