Proteggere Controller di rete

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versioni 21H2 e 20H2

In questo argomento si apprenderà come configurare la sicurezza per tutte le comunicazioni tra Controller di rete e altri software e dispositivi.

I percorsi di comunicazione che è possibile proteggere includono la comunicazione northbound sul piano di gestione, la comunicazione del cluster tra macchine virtuali del controller di rete (VM) in un cluster e la comunicazione Southbound sul piano dati.

  1. Comunicazione northbound. Il controller di rete comunica sul piano di gestione con software di gestione con supporto SDN, ad esempio Windows PowerShell e System Center Virtual Machine Manager (SCVMM). Questi strumenti di gestione consentono di definire i criteri di rete e di creare uno stato obiettivo per la rete, rispetto al quale è possibile confrontare la configurazione di rete effettiva per ottenere la parità della configurazione effettiva con lo stato obiettivo.

  2. Comunicazione del cluster del controller di rete. Quando si configurano tre o più macchine virtuali come nodi del cluster controller di rete, questi nodi comunicano tra loro. Questa comunicazione potrebbe essere correlata alla sincronizzazione e alla replica dei dati tra nodi o alla comunicazione specifica tra i servizi di Controller di rete.

  3. Comunicazione verso sud. Il controller di rete comunica sul piano dati con l'infrastruttura SDN e altri dispositivi, ad esempio servizi di bilanciamento del carico software, gateway e computer host. È possibile usare Controller di rete per configurare e gestire questi dispositivi in ingresso meridionale in modo che mantengano lo stato obiettivo configurato per la rete.

Comunicazione in direzione nord

Controller di rete supporta l'autenticazione, l'autorizzazione e la crittografia per le comunicazioni northbound. Le sezioni seguenti forniscono informazioni su come configurare queste impostazioni di sicurezza.

Authentication

Quando si configura l'autenticazione per la comunicazione northbound del controller di rete, si consente ai nodi del cluster di Controller di rete e ai client di gestione di verificare l'identità del dispositivo con cui comunicano.

Controller di rete supporta le tre modalità di autenticazione seguenti tra i client di gestione e i nodi del controller di rete.

Nota

Se si distribuisce Controller di rete con System Center Virtual Machine Manager, è supportata solo la modalità Kerberos.

  1. Kerberos. Usare l'autenticazione Kerberos quando si uniscono sia il client di gestione che tutti i nodi del cluster di Controller di rete a un dominio di Active Directory. Il dominio di Active Directory deve avere account di dominio usati per l'autenticazione.

  2. X509. Usare X509 per l'autenticazione basata su certificati per i client di gestione non aggiunti a un dominio di Active Directory. È necessario registrare i certificati in tutti i nodi del cluster e i client di gestione di Controller di rete. Inoltre, tutti i nodi e i client di gestione devono considerare attendibili i certificati reciproci.

  3. Nessuno. Usare Nessuno a scopo di test in un ambiente di test e, pertanto, non è consigliabile usarlo in un ambiente di produzione. Quando si sceglie questa modalità, non viene eseguita alcuna autenticazione tra i nodi e i client di gestione.

È possibile configurare la modalità di autenticazione per la comunicazione northbound usando il Windows PowerShell install-NetworkController con il parametro ClientAuthentication.

Autorizzazione

Quando si configura l'autorizzazione per la comunicazione northbound del controller di rete, si consente ai nodi del cluster di Controller di rete e ai client di gestione di verificare che il dispositivo con cui comunicano sia attendibile e abbia l'autorizzazione a partecipare alla comunicazione.

Usare i metodi di autorizzazione seguenti per ognuna delle modalità di autenticazione supportate da Controller di rete.

  1. Kerberos. Quando si usa il metodo di autenticazione Kerberos, si definiscono gli utenti e i computer autorizzati a comunicare con Controller di rete creando un gruppo di sicurezza in Active Directory e quindi aggiungendo gli utenti e i computer autorizzati al gruppo. È possibile configurare Controller di rete per l'uso del gruppo di sicurezza per l'autorizzazione usando il parametro ClientSecurityGroup del comando Install-NetworkController Windows PowerShell. Dopo aver installato il controller di rete, è possibile modificare il gruppo di sicurezza usando il comando Set-NetworkController con il parametro -ClientSecurityGroup. Se si usa SCVMM, è necessario specificare il gruppo di sicurezza come parametro durante la distribuzione.

  2. X509. Quando si usa il metodo di autenticazione X509, Controller di rete accetta solo le richieste dai client di gestione le cui identificazioni personale del certificato sono note a Controller di rete. È possibile configurare queste identificazioni personale usando il parametro ClientCertificateThumbprint del comando Install-NetworkController Windows PowerShell. È possibile aggiungere altre identificazioni personale client in qualsiasi momento usando il comando Set-NetworkController.

  3. Nessuno. Quando si sceglie questa modalità, non viene eseguita alcuna autenticazione tra i nodi e i client di gestione. Usare Nessuno a scopo di test in un ambiente di test e, pertanto, non è consigliabile usarlo in un ambiente di produzione.

Crittografia

La comunicazione northbound usa Secure Sockets Layer (SSL) per creare un canale crittografato tra i client di gestione e i nodi del controller di rete. La crittografia SSL per la comunicazione northbound include i requisiti seguenti:

  • Tutti i nodi del controller di rete devono avere un certificato identico che includa gli scopi autenticazione server e autenticazione client nelle estensioni EKU (Enhanced Key Usage).

  • L'URI usato dai client di gestione per comunicare con Controller di rete deve essere il nome soggetto del certificato. Il nome soggetto del certificato deve contenere il nome di dominio completo (FQDN) o l'indirizzo IP dell'endpoint REST del controller di rete.

  • Se i nodi del controller di rete sono in subnet diverse, il nome del soggetto dei certificati deve corrispondere al valore usato per il parametro RestName nel comando Install-NetworkController Windows PowerShell.

  • Tutti i client di gestione devono considerare attendibile il certificato SSL.

Registrazione e configurazione del certificato SSL

È necessario registrare manualmente il certificato SSL nei nodi del controller di rete.

Dopo aver registrato il certificato, è possibile configurare Controller di rete per l'uso del certificato con il parametro -ServerCertificate del comando Install-NetworkController Windows PowerShell. Se è già stato installato Controller di rete, è possibile aggiornare la configurazione in qualsiasi momento usando il comando Set-NetworkController.

Nota

Se si usa SCVMM, è necessario aggiungere il certificato come risorsa di libreria. Per altre informazioni, vedere Configurare un controller di rete SDN nell'infrastruttura VMM.

Comunicazione del cluster del controller di rete

Controller di rete supporta l'autenticazione, l'autorizzazione e la crittografia per la comunicazione tra i nodi del controller di rete. La comunicazione viene Windows Communication Foundation (WCF) e TCP.

È possibile configurare questa modalità con il parametro ClusterAuthentication del comando Install-NetworkControllerCluster Windows PowerShell.

Per altre informazioni, vedere Install-NetworkControllerCluster.

Authentication

Quando si configura l'autenticazione per la comunicazione del cluster del controller di rete, si consente ai nodi del cluster di Controller di rete di verificare l'identità degli altri nodi con cui comunicano.

Controller di rete supporta le tre modalità di autenticazione seguenti tra i nodi del controller di rete.

Nota

Se si distribuisce Controller di rete usando SCVMM, è supportata solo la modalità Kerberos.

  1. Kerberos. È possibile usare l'autenticazione Kerberos quando tutti i nodi del cluster di Controller di rete vengono aggiunti a un dominio di Active Directory, con gli account di dominio usati per l'autenticazione.

  2. X509. X509 è l'autenticazione basata su certificati. È possibile usare l'autenticazione X509 quando i nodi del cluster controller di rete non sono aggiunti a un dominio di Active Directory. Per usare X509, è necessario registrare i certificati in tutti i nodi del cluster di Controller di rete e tutti i nodi devono considerare attendibili i certificati. Inoltre, il nome soggetto del certificato registrato in ogni nodo deve corrispondere al nome DNS del nodo.

  3. Nessuno. Quando si sceglie questa modalità, non viene eseguita alcuna autenticazione tra i nodi del controller di rete. Questa modalità viene fornita solo a scopo di test e non è consigliata per l'uso in un ambiente di produzione.

Autorizzazione

Quando si configura l'autorizzazione per la comunicazione del cluster controller di rete, si consente ai nodi del cluster di Controller di rete di verificare che i nodi con cui comunicano siano attendibili e che siano autorizzati a partecipare alla comunicazione.

Per ognuna delle modalità di autenticazione supportate dal controller di rete, vengono usati i metodi di autorizzazione seguenti.

  1. Kerberos. I nodi del controller di rete accettano richieste di comunicazione solo da altri account computer del controller di rete. È possibile configurare questi account quando si distribuisce Controller di rete usando il parametro Name del comando New-NetworkControllerNodeObject Windows PowerShell.

  2. X509. I nodi del controller di rete accettano richieste di comunicazione solo da altri account computer del controller di rete. È possibile configurare questi account quando si distribuisce Controller di rete usando il parametro Name del comando New-NetworkControllerNodeObject Windows PowerShell.

  3. Nessuno. Quando si sceglie questa modalità, non viene eseguita alcuna autorizzazione tra i nodi del controller di rete. Questa modalità viene fornita solo a scopo di test e non è consigliata per l'uso in un ambiente di produzione.

Crittografia

La comunicazione tra i nodi del controller di rete viene crittografata tramite la crittografia a livello di trasporto WCF. Questa forma di crittografia viene usata quando i metodi di autenticazione e autorizzazione sono certificati Kerberos o X509. Per ulteriori informazioni, vedere gli argomenti seguenti.

Comunicazione verso sud

Controller di rete interagisce con diversi tipi di dispositivi per la comunicazione Southbound. Queste interazioni usano protocolli diversi. Per questo scopo, esistono requisiti diversi per l'autenticazione, l'autorizzazione e la crittografia a seconda del tipo di dispositivo e protocollo usato dal controller di rete per comunicare con il dispositivo.

Nella tabella seguente vengono fornite informazioni sull'interazione del controller di rete con dispositivi southbound diversi.

Dispositivo/servizio southbound Protocollo Autenticazione usata
Bilanciamento del carico software WCF (MUX), TCP (host) Certificati
Firewall OVSDB Certificati
Gateway WinRM Kerberos, certificati
Reti virtuali OVSDB, WCF Certificati
Routing definito dall'utente OVSDB Certificati

Per ognuno di questi protocolli, il meccanismo di comunicazione è descritto nella sezione seguente.

Authentication

Per le comunicazioni southbound vengono usati i protocolli e i metodi di autenticazione seguenti.

  1. WCF/TCP/OVSDB. Per questi protocolli, l'autenticazione viene eseguita tramite certificati X509. I computer host/controller di rete e peer Software Load Balancing (SLB) Multiplexer (MUX) presentano i certificati reciprocamente per l'autenticazione reciproca. Ogni certificato deve essere considerato attendibile dal peer remoto.

    Per l'autenticazione southbound, è possibile usare lo stesso certificato SSL configurato per crittografare la comunicazione con i client Northbound. È anche necessario configurare un certificato nei dispositivi MUX e host SLB. Il nome soggetto del certificato deve corrispondere al nome DNS del dispositivo.

  2. WinRM. Per questo protocollo, l'autenticazione viene eseguita tramite Kerberos (per i computer aggiunti a un dominio) e tramite certificati (per computer non aggiunti a un dominio).

Autorizzazione

Per le comunicazioni southbound vengono usati i protocolli e i metodi di autorizzazione seguenti.

  1. WCF/TCP. Per questi protocolli, l'autorizzazione è basata sul nome soggetto dell'entità peer. Controller di rete archivia il nome DNS del dispositivo peer e lo usa per l'autorizzazione. Questo nome DNS deve corrispondere al nome soggetto del dispositivo nel certificato. Analogamente, il certificato del controller di rete deve corrispondere al nome DNS del controller di rete archiviato nel dispositivo peer.

  2. WinRM. Se si usa Kerberos, l'account client WinRM deve essere presente in un gruppo predefinito in Active Directory o nel gruppo Amministratori locali nel server. Se vengono usati certificati, il client presenta un certificato al server autorizzato dal server usando il nome soggetto/autorità emittente e il server usa un account utente mappato per eseguire l'autenticazione.

  3. OVSDB. Non è disponibile alcuna autorizzazione per questo protocollo.

Crittografia

Per le comunicazioni southbound, per i protocolli vengono usati i metodi di crittografia seguenti.

  1. WCF/TCP/OVSDB. Per questi protocolli, la crittografia viene eseguita usando il certificato registrato nel client o nel server.

  2. WinRM. Il traffico WinRM viene crittografato per impostazione predefinita usando il provider di supporto per la sicurezza (SSP) Kerberos. È possibile configurare La crittografia aggiuntiva, sotto forma di SSL, nel server Gestione remota Windows.