Schützen des Netzwerkcontrollers

Gilt für: Azure Stack HCI, Versionen 23H2 und 22H2; Windows Server 2022, Windows Server 2019, Windows Server 2016

In diesem Artikel wird beschrieben, wie Sie die Sicherheit für die gesamte Kommunikation zwischen dem Netzwerkcontroller und anderen Software- und Geräten konfigurieren.

Zu den Kommunikationspfaden, die Sie schützen können, zählen die Northbound-Kommunikation auf der Verwaltungsebene, die Clusterkommunikation zwischen virtuellen Netzwerkcontrollercomputern (virtual machines, VMs) in einem Cluster und die Southbound-Kommunikation auf der Datenebene.

1. Northbound-Kommunikation:. Der Netzwerkcontroller kommuniziert auf der Verwaltungsebene mit SDN-fähiger Verwaltungssoftware wie Windows PowerShell und System Center Virtual Machine Manager (SCVMM). Diese Verwaltungstools ermöglichen das Definieren einer Netzwerkrichtlinie sowie das Erstellen eines Zielzustands für das Netzwerk, mit dem Sie die tatsächliche Netzwerkkonfiguration vergleichen können, um Parität zwischen der tatsächlichen Konfiguration und dem Zielzustand zu erreichen.

2. Clusterkommunikation des Netzwerkcontrollers:. Wenn Sie drei oder mehr virtuelle Computer als Netzwerkcontroller-Clusterknoten konfigurieren, kommunizieren diese Knoten miteinander. Diese Kommunikation kann mit der knotenübergreifenden Synchronisierung und Replikation von Daten oder mit einer bestimmten Kommunikation zwischen Netzwerkcontrollerdiensten zusammenhängen.

3. Southbound-Kommunikation. Der Netzwerkcontroller kommuniziert auf der Datenebene mit SDN-Infrastruktur und anderen Geräten wie softwarebasierten Lastenausgleichsmodulen, Gateways und Hostcomputern. Sie können den Netzwerkcontroller verwenden, um diese Southbound-Geräte so zu konfigurieren und zu verwalten, dass sie den Zielzustand aufrechterhalten, den Sie für das Netzwerk konfiguriert haben.

Northbound-Kommunikation

Der Netzwerkcontroller unterstützt Authentifizierung, Autorisierung und Verschlüsselung für die Northbound-Kommunikation. In den folgenden Abschnitten finden Sie Informationen zum Konfigurieren dieser Sicherheitseinstellungen.

Authentifizierung

Wenn Sie die Authentifizierung für die Northbound-Kommunikation des Netzwerkcontrollers konfigurieren, erlauben Sie Netzwerkcontrollerclusterknoten und Verwaltungsclients, die Identität des Geräts zu überprüfen, mit dem sie kommunizieren.

Der Netzwerkcontroller unterstützt die drei folgenden Authentifizierungsmodi zwischen Verwaltungsclients und Netzwerkcontrollerknoten.

1. Kerberos. Verwenden Sie die Kerberos-Authentifizierung, wenn Sie sowohl den Verwaltungsclient als auch alle Netzwerkcontroller-Clusterknoten in eine Active Directory-Domäne einbinden. Die Active Directory-Domäne muss über Domänenkonten verfügen, die für die Authentifizierung verwendet werden.

2. X.509. Verwenden Sie X.509 für die zertifikatbasierte Authentifizierung für Verwaltungsclients, die nicht in eine Active Directory-Domäne eingebunden sind. Sie müssen Zertifikate bei allen Netzwerkcontroller-Clusterknoten und Verwaltungsclients registrieren. Außerdem müssen alle Knoten und Verwaltungsclients den Zertifikaten der jeweils anderen Verwaltungsclients bzw. Knoten vertrauen.

3. Keine. Die Option „Keine“ ist zum Testen in einer Testumgebung vorgesehen und sollte daher nicht in einer Produktionsumgebung verwendet werden. Wenn Sie diesen Modus auswählen, wird keine Authentifizierung zwischen Knoten und Verwaltungsclients durchgeführt.

Der Authentifizierungsmodus für die Northbound-Kommunikation kann mithilfe des Windows PowerShell-Befehls Install-NetworkController mit dem Parameter ClientAuthentication konfiguriert werden.

Authorization

Wenn Sie die Autorisierung für die Northbound-Kommunikation des Netzwerkcontrollers konfigurieren, erlauben Sie Netzwerkcontrollerclusterknoten und Verwaltungsclients, zu überprüfen, ob das Gerät, mit dem sie kommunizieren, vertrauenswürdig ist und über die Berechtigung verfügt, an der Kommunikation teilzunehmen.

Verwenden Sie die folgenden Autorisierungsmethoden für jeden der vom Azure Netzwerkcontroller unterstützten Authentifizierungsmodi.

1. Kerberos. Wenn Sie die Kerberos-Authentifizierungsmethode verwenden, definieren Sie die Benutzer und Computer, die für die Kommunikation mit dem Netzwerkcontroller autorisiert sind, indem Sie eine Sicherheitsgruppe in Active Directory erstellen und dann die autorisierten Benutzer und Computer zur Gruppe hinzufügen. Sie können den Parameter ClientSecurityGroup des Windows PowerShell-Befehls Install-NetworkController verwenden, um den Netzwerkcontroller so zu konfigurieren, dass die Sicherheitsgruppe für die Autorisierung verwendet wird. Nach der Installation des Netzwerkcontrollers kann die Sicherheitsgruppe mithilfe des Befehls Set-NetworkController mit dem Parameter -ClientSecurityGroup geändert werden. Bei Verwendung von SCVMM muss die Sicherheitsgruppe im Rahmen der Bereitstellung als Parameter angegeben werden.

2. X.509. Wenn Sie die X509-Authentifizierungsmethode verwenden, akzeptiert der Netzwerkcontroller nur Anforderungen von Verwaltungsclients, deren Zertifikatfingerabdrücke dem Netzwerkcontroller bekannt sind. Diese Fingerabdrücke können mithilfe des Parameters ClientCertificateThumbprint des Windows PowerShell-Befehls Install-NetworkController konfiguriert werden. Mithilfe des Befehls Set-NetworkController können jederzeit weitere Clientfingerabdrücke hinzugefügt werden.

3. Keine. Wenn Sie diesen Modus auswählen, wird keine Authentifizierung zwischen Knoten und Verwaltungsclients durchgeführt. Die Option „Keine“ ist zum Testen in einer Testumgebung vorgesehen und sollte daher nicht in einer Produktionsumgebung verwendet werden.

Verschlüsselung

Die Northbound-Kommunikation verwendet Secure Sockets Layer (SSL), um einen verschlüsselten Kanal zwischen Verwaltungsclients und Netzwerkcontrollerknoten bereitzustellen. Für die SSL-Verschlüsselung der Northbound-Kommunikation ist Folgendes erforderlich:

• Alle Netzwerkcontrollerknoten müssen über ein identisches Zertifikat verfügen, das die Zwecke „Serverauthentifizierung“ und „Clientauthentifizierung“ in EKU-Erweiterungen (Enhanced Key Usage, erweiterte Schlüsselverwendung) enthält.

• Der URI, der von Verwaltungsclients für die Kommunikation mit dem Netzwerkcontroller verwendet wird, muss der Name des Zertifikatantragstellers sein. Der Antragstellername des Zertifikats muss entweder den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) oder die IP-Adresse des REST-Endpunkts des Netzwerkcontrollers enthalten.

• Wenn sich Netzwerkcontrollerknoten in verschiedenen Subnetzen befinden, muss der Antragstellername ihrer Zertifikate dem Wert entsprechen, der im Windows PowerShell-Befehl Install-NetworkController für den Parameter RestName verwendet wurde.

• Dem SSL-Zertifikat muss von allen Verwaltungsclients vertraut werden.

Registrierung und Konfiguration des SSL-Zertifikats

Das SSL-Zertifikat muss manuell auf Netzwerkcontrollerknoten registriert werden.

Nachdem das Zertifikat registriert wurde, können Sie den Netzwerkcontroller mithilfe des Parameters -ServerCertificate des Windows PowerShell-Befehls Install-NetworkController so konfigurieren, dass der Netzwerkcontroller das Zertifikat verwendet. Wenn Sie den Netzwerkcontroller bereits installiert haben, können Sie die Konfiguration jederzeit mithilfe des Befehls Set-NetworkController aktualisieren.

Clusterkommunikation des Netzwerkcontrollers

Der Netzwerkcontroller unterstützt die Authentifizierung, Autorisierung und Verschlüsselung der Kommunikation zwischen Netzwerkcontrollerknoten. Die Kommunikation erfolgt über Windows Communication Foundation (WCF) und TCP.

Dieser Modus kann mithilfe des Parameters ClusterAuthentication des Windows PowerShell-Befehls Install-NetworkControllerCluster konfiguriert werden.

Weitere Informationen finden Sie unter Install-NetworkControllerCluster.

Authentifizierung

Wenn Sie die Authentifizierung für die Netzwerkcontrollerclusterkommunikation konfigurieren, erlauben Sie Netzwerkcontrollerclusterknoten, die Identität der anderen Knoten zu überprüfen, mit denen sie kommunizieren.

Der Netzwerkcontroller unterstützt die drei folgenden Authentifizierungsmodi zwischen Netzwerkcontrollerknoten.

1. Kerberos. Die Kerberos-Authentifizierung kann verwendet werden, wenn alle Netzwerkcontroller-Clusterknoten in eine Active Directory-Domäne eingebunden sind und Domänenkonten für die Authentifizierung verwendet werden.

2. X.509. X.509 ist eine zertifikatbasierte Authentifizierung. Die X.509-Authentifizierung kann verwendet werden, wenn Netzwerkcontroller-Clusterknoten nicht in eine Active Directory-Domäne eingebunden sind. Wenn Sie X.509 verwenden möchten, müssen Sie Zertifikate bei allen Netzwerkcontroller-Clusterknoten registrieren, und den Zertifikaten muss von allen Knoten vertraut werden. Darüber hinaus muss der Antragstellername des Zertifikats, das bei dem jeweiligen Knoten registriert ist, mit dem DNS-Namen des Knotens identisch sein.

3. Keine. Wenn Sie diesen Modus auswählen, wird keine Authentifizierung zwischen Netzwerkcontrollerknoten durchgeführt. Dieser Modus wird nur zu Testzwecken bereitgestellt und wird nicht für die Verwendung in einer Produktionsumgebung empfohlen.

Authorization

Wenn Sie die Autorisierung für die Netzwerkcontrollerclusterkommunikation konfigurieren, erlauben Sie Netzwerkcontrollerclusterknoten, zu überprüfen, ob die Knoten, mit denen sie kommunizieren, vertrauenswürdig sind und über die Berechtigung verfügen, an der Kommunikation teilzunehmen.

Für jeden der vom Netzwerkcontroller unterstützten Authentifizierungsmodi werden die folgenden Autorisierungsmethoden verwendet.

1. Kerberos. Netzwerkcontrollerknoten akzeptieren nur Kommunikationsanforderungen von anderen Netzwerkcontroller-Computerkonten. Diese Konten können beim Bereitstellen des Netzwerkcontrollers mithilfe des Parameters Name des Windows PowerShell-Befehls New-NetworkControllerNodeObject konfiguriert werden.

2. X.509. Netzwerkcontrollerknoten akzeptieren nur Kommunikationsanforderungen von anderen Netzwerkcontroller-Computerkonten. Diese Konten können beim Bereitstellen des Netzwerkcontrollers mithilfe des Parameters Name des Windows PowerShell-Befehls New-NetworkControllerNodeObject konfiguriert werden.

3. Keine. Wenn Sie diesen Modus auswählen, wird keine Autorisierung zwischen Netzwerkcontrollerknoten durchgeführt. Dieser Modus wird nur zu Testzwecken bereitgestellt und wird nicht für die Verwendung in einer Produktionsumgebung empfohlen.

Verschlüsselung

Die Kommunikation zwischen Netzwerkcontrollerknoten wird mithilfe der WCF-Verschlüsselung auf Transportebene verschlüsselt. Diese Art der Verschlüsselung wird verwendet, wenn die Authentifizierungs- und die Autorisierungsmethode entweder auf Kerberos oder auf X.509-Zertifikate festgelegt sind. Weitere Informationen finden Sie in den nachfolgenden Themen.

• Vorgehensweise: Sichern eines Diensts mit Windows-Anmeldeinformationen
• Vorgehensweise: Sichern eines Diensts mit einem X.509-Zertifikat.

Southbound-Kommunikation

Der Netzwerkcontroller interagiert für die Southbound-Kommunikation mit verschiedenen Arten von Geräten. Bei diesen Interaktionen kommen unterschiedliche Protokolle zum Einsatz. Aus diesem Grund gibt es abhängig von der Art des Geräts und des Protokolls, das vom Netzwerkcontroller für die Kommunikation mit dem Gerät verwendet wird, unterschiedliche Anforderungen für die Authentifizierung, Autorisierung und Verschlüsselung.

Die folgende Tabelle enthält Informationen zur Interaktion des Netzwerkcontrollers mit verschiedenen Southbound-Geräten.

Im folgenden Abschnitt wird der Kommunikationsmechanismus für jedes dieser Protokolle beschrieben.

Authentifizierung

Bei der Southbound-Kommunikation werden folgende Protokolle und Authentifizierungsmethoden verwendet.

1. WCF/TCP/OVSDB. Bei diesen Protokollen wird die Authentifizierung mithilfe von X.509-Zertifikaten durchgeführt. Sowohl der Netzwerkcontroller als auch der Peer-SLB-MUX (Software Load Balancing Multiplexer) bzw. die Hostcomputer präsentieren untereinander ihre Zertifikate für die gegenseitige Authentifizierung. Jedem Zertifikat muss jeweils vom Remotepeer vertraut werden.

   Bei der Southbound-Authentifizierung kann das gleiche SSL-Zertifikat verwendet werden, das auch für die Verschlüsselung der Kommunikation mit den Northbound-Clients konfiguriert ist. Sie müssen auch ein Zertifikat für den SLB-MUX und die Hostgeräte konfigurieren. Der Name des Zertifikatantragstellers muss dem DNS-Namen des Geräts entsprechen.

2. WinRM. Bei diesem Protokoll wird die Authentifizierung mithilfe von Kerberos (für Computer mit Domänenzugehörigkeit) und mithilfe von Zertifikaten (für Computer ohne Domänenzugehörigkeit) durchgeführt.

Authorization

Bei der Southbound-Kommunikation werden folgende Protokolle und Autorisierungsmethoden verwendet.

1. WCF/TCP. Bei diesen Protokollen basiert die Autorisierung auf dem Antragstellernamen der Peerentität. Der Netzwerkcontroller speichert den DNS-Namen des Peergeräts und verwendet ihn für die Autorisierung. Dieser DNS-Name muss dem Antragstellernamen des Geräts im Zertifikat entsprechen. Ebenso muss das Netzwerkcontrollerzertifikat dem auf dem Peergerät gespeicherten DNS-Namen des Netzwerkcontrollers entsprechen.

2. WinRM. Bei Verwendung von Kerberos muss das WinRM-Clientkonto in einer vordefinierten Gruppe in Active Directory oder in der Gruppe „Lokale Administratoren“ auf dem Server vorhanden sein. Bei Verwendung von Zertifikaten legt der Client dem Server ein Zertifikat vor, das der Server anhand des Antragstellernamens/Ausstellers autorisiert, und der Server verwendet ein zugeordnetes Benutzerkonto, um die Authentifizierung durchzuführen.

3. OVSDB. Die Autorisierung basiert auf dem Antragstellernamen der Peerentität. Der Netzwerkcontroller speichert den DNS-Namen des Peergeräts und verwendet ihn für die Autorisierung. Dieser DNS-Name muss dem Antragstellernamen des Geräts im Zertifikat entsprechen.

Verschlüsselung

Bei der Southbound-Kommunikation werden folgende Verschlüsselungsmethoden für Protokolle verwendet.

1. WCF/TCP/OVSDB. Bei diesen Protokollen wird die Verschlüsselung mithilfe des Zertifikats durchgeführt, das auf dem Client oder Server registriert ist.

2. WinRM. Für die Verschlüsselung von WinRM-Datenverkehr wird standardmäßig der Kerberos Security Support Provider (SSP) verwendet. Sie können eine zusätzliche Verschlüsselung in Form von SSL auf dem WinRM-Server konfigurieren.