Sécuriser le contrôleur de réseau
S’applique à : Azure Stack HCI, versions 22H2 et 21H2, Windows Server 2022, Windows Server 2019, Windows Server 2016
Dans cette rubrique, vous découvrirez comment configurer la sécurité pour toutes les communications entre le contrôleur de réseau et d’autres logiciels et appareils.
Les chemins de communication que vous pouvez sécuriser incluent la communication vers les composants de niveau supérieur sur le plan de gestion, la communication de cluster entre les machines virtuelles du contrôleur de réseau dans un cluster et la communication vers les composants de niveau inférieur sur le plan de données.
Communication vers les composants de niveau supérieur. Le contrôleur de réseau communique sur le plan d’administration avec un logiciel de gestion compatible SDN comme Windows PowerShell et System Center Virtual Machine Manager (SCVMM). Ces outils de gestion vous permettent de définir la stratégie réseau et de créer un état d’objectif pour le réseau, par rapport auquel vous pouvez comparer la configuration réseau réelle pour mettre la configuration en parité avec l’état d’objectif.
Communication du cluster du contrôleur de réseau. Lorsque vous configurez trois machines virtuelles ou plus en tant que nœuds de cluster de contrôleur de réseau, ces nœuds communiquent entre eux. Cette communication peut être liée à la synchronisation et à la réplication des données entre les nœuds ou une communication spécifique entre les services de contrôleur de réseau.
Communication vers les composants de niveau inférieur. Le contrôleur de réseau communique sur le plan de données avec l’infrastructure SDN et d’autres appareils tels que les équilibreurs de charge logicielles, les passerelles et les machines hôtes. Vous pouvez utiliser le contrôleur de réseau pour configurer et gérer ces appareils de trafic vers les composants de niveau inférieur afin qu’ils conservent l’état d’objectif que vous avez configuré pour le réseau.
Communication vers les composants de niveau supérieur
Le contrôleur de réseau prend en charge l’authentification, l’autorisation et le chiffrement pour la communication vers les composants de niveau supérieur. Les sections suivantes fournissent des informations sur la configuration de ces paramètres de sécurité.
Authentification
Lorsque vous configurez l’authentification pour la communication en direction nord du contrôleur de réseau, vous autorisez les nœuds de cluster du contrôleur de réseau et les clients de gestion à vérifier l’identité de l’appareil avec lequel ils communiquent.
Le contrôleur de réseau prend en charge les trois modes d’authentification suivants entre les clients de gestion et les nœuds de contrôleur de réseau.
Notes
Si vous déployez un contrôleur de réseau avec System Center Virtual Machine Manager, seul le mode Kerberos est pris en charge.
Kerberos. Utilisez l’authentification Kerberos lors de la liaison du client de gestion et de tous les nœuds de cluster du contrôleur réseau à un domaine Active Directory. Le domaine Active Directory doit avoir des comptes de domaine utilisés pour l’authentification.
X509. Utilisez X509 pour l’authentification basée sur des certificats pour les clients de gestion non joints à un domaine Active Directory. Vous devez inscrire des certificats à tous les nœuds de cluster de contrôleur de réseau et clients de gestion. En outre, tous les nœuds et clients de gestion doivent approuver les certificats des autres.
Aucun. Utilisez Aucun à des fins de test dans un environnement de test. Par conséquent ce mode n’est pas recommandé pour une utilisation dans un environnement de production. Lorsque vous choisissez ce mode, aucune authentification n’est effectuée entre les nœuds et les clients de gestion.
Vous pouvez configurer le mode d’authentification pour la communication vers des composants de niveau inférieur à l’aide de la commande Install-NetworkController Windows PowerShell avec le paramètre ClientAuthentication.
Autorisation
Lorsque vous configurez l’autorisation pour la communication northbound du contrôleur de réseau, vous autorisez les nœuds de cluster et les clients de gestion du contrôleur de réseau à vérifier que l’appareil avec lequel ils communiquent est approuvé et a l’autorisation de participer à la communication.
Utilisez les méthodes d’autorisation suivantes pour chacun des modes d’authentification pris en charge par le contrôleur de réseau.
Kerberos. Lorsque vous utilisez la méthode d’authentification Kerberos, vous définissez les utilisateurs et ordinateurs autorisés à communiquer avec le contrôleur de réseau en créant un groupe de sécurité dans Active Directory, puis en ajoutant les utilisateurs et ordinateurs autorisés au groupe. Vous pouvez configurer le contrôleur de réseau pour utiliser le groupe de sécurité pour l’autorisation à l’aide du paramètre ClientSecurityGroup de la commande Install-NetworkController Windows PowerShell. Après avoir installé le contrôleur de réseau, vous pouvez modifier le groupe de sécurité à l’aide de la commande Set-NetworkController avec le paramètre -ClientSecurityGroup. Si vous utilisez SCVMM, vous devez fournir le groupe de sécurité en tant que paramètre pendant le déploiement.
X509. Lorsque vous utilisez la méthode d’authentification X509, le contrôleur de réseau accepte uniquement les demandes des clients de gestion dont les empreintes de certificat sont connues du contrôleur de réseau. Vous pouvez configurer ces empreintes à l’aide du paramètre ClientCertificateThumbprint de la commande Install-NetworkController Windows PowerShell. Vous pouvez ajouter d’autres empreintes clientes à tout moment à l’aide de la commande Set-NetworkController.
Aucun. Lorsque vous choisissez ce mode, aucune authentification n’est effectuée entre les nœuds et les clients de gestion. Utilisez Aucun à des fins de test dans un environnement de test. Par conséquent ce mode n’est pas recommandé pour une utilisation dans un environnement de production.
Chiffrement
La communication vers des composants de niveau inférieur utilise SSL (Secure Sockets Layer) pour créer un canal chiffré entre les clients de gestion et les nœuds de contrôleur de réseau. Le chiffrement SSL pour la communication vers des composants de niveau inférieur inclut les exigences suivantes :
Tous les nœuds du contrôleur de réseau doivent avoir un certificat identique qui inclut les objectifs d’authentification serveur et d’authentification client dans les extensions EKU (utilisation améliorée de la clé).
L’URI utilisé par les clients de gestion pour communiquer avec le contrôleur de réseau doit être le nom de l’objet du certificat. Le nom de l’objet du certificat doit contenir le nom de domaine complet (FQDN) ou l’adresse IP du point de terminaison REST du contrôleur de réseau.
Si les nœuds du contrôleur de réseau se trouvent sur différents sous-réseaux, le nom de l’objet de leurs certificats doit être identique à la valeur utilisée pour le paramètre RestName dans la commande Install-NetworkController Windows PowerShell.
Tous les clients de gestion doivent approuver le certificat SSL.
Inscription et configuration du certificat SSL
Vous devez inscrire manuellement le certificat SSL sur les nœuds du contrôleur de réseau.
Une fois le certificat inscrit, vous pouvez configurer le contrôleur de réseau pour utiliser le certificat avec le paramètre -ServerCertificate de la commande Install-NetworkController Windows PowerShell. Si vous avez déjà installé le contrôleur de réseau, vous pouvez mettre à jour la configuration à tout moment à l’aide de la commande Set-NetworkController.
Notes
Si vous utilisez SCVMM, vous devez ajouter le certificat en tant que ressource de bibliothèque. Pour plus d’informations, consultez Configurer un contrôleur de réseau SDN dans l’infrastructure VMM.
Communication du cluster du contrôleur de réseau
Le contrôleur de réseau prend en charge l’authentification, l’autorisation et le chiffrement pour la communication entre les nœuds du contrôleur de réseau. La communication est sur Windows Communication Foundation (WCF) et TCP.
Vous pouvez configurer ce mode avec le paramètre ClusterAuthentication de la commande Install-NetworkControllerCluster Windows PowerShell.
Pour plus d’informations, consultez Install-NetworkControllerCluster.
Authentification
Lorsque vous configurez l’authentification pour la communication du cluster du contrôleur de réseau, vous autorisez les nœuds de cluster du contrôleur de réseau à vérifier l’identité des autres nœuds avec lesquels ils communiquent.
Le contrôleur de réseau prend en charge les trois modes d’authentification suivants entre les nœuds du contrôleur de réseau.
Notes
Si vous déployez le contrôleur de réseau à l’aide de SCVMM, seul le mode Kerberos est pris en charge.
Kerberos. Vous pouvez utiliser l’authentification Kerberos lorsque tous les nœuds de cluster de contrôleur de réseau sont joints à un domaine Active Directory, avec des comptes de domaine utilisés pour l’authentification.
X509. X509 est une authentification basée sur des certificats. Vous pouvez utiliser l’authentification X509 lorsque les nœuds de cluster du contrôleur de réseau ne sont pas liés à un domaine Active Directory. Pour utiliser X509, vous devez inscrire des certificats à tous les nœuds de cluster du contrôleur de réseau, et tous les nœuds doivent approuver les certificats. En outre, le nom de l’objet du certificat inscrit sur chaque nœud doit être identique au nom DNS du nœud.
Aucun. Lorsque vous choisissez ce mode, aucune authentification n’est effectuée entre les nœuds du contrôleur de réseau. Ce mode est fourni uniquement à des fins de test et n’est pas recommandé pour une utilisation dans un environnement de production.
Autorisation
Lorsque vous configurez l’autorisation pour la communication de cluster du contrôleur de réseau, vous autorisez les nœuds de cluster du contrôleur de réseau à vérifier que les nœuds avec lesquels ils communiquent sont approuvés et ont l’autorisation de participer à la communication.
Pour chacun des modes d’authentification pris en charge par le contrôleur de réseau, les méthodes d’autorisation suivantes sont utilisées.
Kerberos. Les nœuds du contrôleur de réseau acceptent uniquement les demandes de communication à partir d’autres comptes de machine de contrôleur de réseau. Vous pouvez configurer ces comptes lorsque vous déployez le contrôleur de réseau à l’aide du paramètre Name de la commande New-NetworkControllerNodeObject Windows PowerShell.
X509. Les nœuds du contrôleur de réseau acceptent uniquement les demandes de communication à partir d’autres comptes de machine de contrôleur de réseau. Vous pouvez configurer ces comptes lorsque vous déployez le contrôleur de réseau à l’aide du paramètre Name de la commande New-NetworkControllerNodeObject Windows PowerShell.
Aucun. Lorsque vous choisissez ce mode, aucune autorisation n’est effectuée entre les nœuds du contrôleur de réseau. Ce mode est fourni uniquement à des fins de test et n’est pas recommandé pour une utilisation dans un environnement de production.
Chiffrement
La communication entre les nœuds du contrôleur de réseau est chiffrée à l’aide du chiffrement au niveau du transport WCF. Cette forme de chiffrement est utilisée lorsque les méthodes d’authentification et d’autorisation sont des certificats Kerberos ou X509. Pour plus d'informations, consultez les rubriques ci-dessous.
- Procédure : sécuriser un service avec des informations d’identification Windows
- Procédure : sécuriser un service avec un certificat X.509.
Communication vers les composants de niveau inférieur
Le contrôleur de réseau interagit avec différents types d’appareils pour la communication vers les composants de niveau inférieur. Ces interactions utilisent différents protocoles. En raison de cela, il existe différentes exigences pour l’authentification, l’autorisation et le chiffrement en fonction du type d’appareil et de protocole utilisé par le contrôleur de réseau pour communiquer avec l’appareil.
Le tableau suivant fournit des informations sur l’interaction du contrôleur de réseau avec différents appareils de trafic vers les composants de niveau inférieur.
| Appareil/service de trafic vers les composants de niveau inférieur | Protocol | Authentification utilisée |
|---|---|---|
| Équilibrage de la charge logicielle | WCF (MUX), TCP (hôte) | Certificats |
| Pare-feu | OVSDB | Certificats |
| Passerelle | WinRM | Kerberos, Certificats |
| Réseau virtuel | OVSDB, WCF | Certificats |
| Itinéraire défini par l’utilisateur | OVSDB | Certificats |
Pour chacun de ces protocoles, le mécanisme de communication est décrit dans la section suivante.
Authentification
Pour la communication vers les composants de niveau inférieur, les protocoles et méthodes d’authentification suivants sont utilisés.
WCF/TCP/OVSDB. Pour ces protocoles, l’authentification est effectuée à l’aide de certificats X509. Le contrôleur réseau et les machines homologues du multiplexeur (MUX)/hôte de l’équilibrage de charge logicielle (SLB) se présentent mutuellement leurs certificats pour une authentification mutuelle. Chaque certificat doit être approuvé par l’homologue distant.
Pour l’authentification vers les composants de niveau inférieur, vous pouvez utiliser le même certificat SSL configuré pour chiffrer la communication avec les clients vers les composants de niveau supérieur. Vous devez également configurer un certificat sur les appareils SLB MUX et hôtes. Le nom d’objet du certificat doit être le même que le nom DNS de l’appareil.
WinRM. Pour ce protocole, l’authentification est effectuée à l’aide de Kerberos (pour les machines liées à un domaine) et à l’aide de certificats (pour les machines liées à un domaine).
Autorisation
Pour la communication vers les composants de niveau inférieur, les protocoles et méthodes d’autorisation suivants sont utilisés.
WCF/TCP. Pour ces protocoles, l’autorisation est basée sur le nom de l’objet de l’entité homologue. Le contrôleur de réseau stocke le nom DNS de l’appareil homologue et l’utilise pour l’autorisation. Ce nom DNS doit correspondre au nom de l’objet de l’appareil dans le certificat. De même, le certificat du contrôleur de réseau doit correspondre au nom DNS du contrôleur de réseau stocké sur l’appareil homologue.
WinRM. Si Kerberos est utilisé, le compte client WinRM doit être présent dans un groupe prédéfini dans Active Directory ou dans le groupe Administrateurs locaux sur le serveur. Si des certificats sont utilisés, le client présente un certificat au serveur que le serveur autorise à l’aide du nom/émetteur de l’objet, et le serveur utilise un compte d’utilisateur mappé pour effectuer l’authentification.
OVSDB. L’autorisation est basée sur le nom d’objet de l’entité homologue. Le contrôleur de réseau stocke le nom DNS de l’appareil homologue et l’utilise pour l’autorisation. Ce nom DNS doit correspondre au nom de l’objet de l’appareil dans le certificat.
Chiffrement
Pour la communication vers les composants de niveau inférieur, les méthodes de chiffrement suivantes sont utilisées pour les protocoles.
WCF/TCP/OVSDB. Pour ces protocoles, le chiffrement est effectué à l’aide du certificat inscrit sur le client ou le serveur.
WinRM. Le trafic WinRM est chiffré par défaut à l’aide du fournisseur de support de sécurité Kerberos (SSP). Vous pouvez configurer un chiffrement supplémentaire, sous la forme de SSL, sur le serveur WinRM.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour