Proteggere Controller di rete

Si applica a: Locale di Azure, versioni 23H2 e 22H2; Windows Server 2022, Windows Server 2019, Windows Server 2016

Questo articolo descrive 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 nel piano di gestione, la comunicazione nel cluster tra macchine virtuali (VM) del controller di rete in un cluster e la comunicazione southbound nel piano dati.

1. Comunicazione northbound. Il controller di rete comunica nel piano di gestione con software di gestione compatibili con 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, con cui è possibile confrontare la configurazione di rete effettiva per portarla in parità con lo stato obiettivo.

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

3. Comunicazione southbound. Il controller di rete comunica nel piano dati con l'infrastruttura SDN e altri dispositivi, quali servizi di bilanciamento del carico software, gateway e computer host. È possibile usare Il controller di rete per configurare e gestire questi dispositivi southbound in modo che mantengano lo stato obiettivo configurato per la rete.

Comunicazione northbound

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

Autenticazione

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

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

1. Kerberos. Usare l'autenticazione Kerberos quando si aggiungono il client di gestione e tutti i nodi del cluster del controller di rete a un dominio di Active Directory. Il dominio di Active Directory deve disporre di account di dominio usati per l'autenticazione.

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

3. Nessuno. L'opzione Nessuno è per scopi di test in un ambiente di test e non è consigliabile usarla in un ambiente di produzione. Quando si sceglie questa modalità, non viene eseguita alcuna autenticazione tra nodi e client di gestione.

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

Autorizzazione

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

Usare i metodi di autorizzazione seguenti per ognuna delle modalità di autenticazione supportate dal controller di rete.

1. Kerberos. Quando si usa il metodo di autenticazione Kerberos, si definiscono gli utenti e i computer autorizzati a comunicare con il controller di rete creando un gruppo di sicurezza in Active Directory e quindi aggiungendo gli utenti e i computer autorizzati al gruppo. È possibile configurare il controller di rete affinché usi il gruppo di sicurezza per l'autorizzazione mediante il parametro ClientSecurityGroup del comando di Windows PowerShell Install-NetworkController. 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, Il controller di rete accetta solo le richieste dai client di gestione le cui identificazioni personali del certificato sono note al controller di rete. È possibile configurare queste identificazioni personali usando il parametro ClientCertificateThumbprint del comando di Windows PowerShell Install-NetworkController. È possibile aggiungere altre identificazioni personali client in qualsiasi momento usando il comando Set-NetworkController.

3. Nessuno. Quando si sceglie questa modalità, non viene eseguita alcuna autenticazione tra nodi e client di gestione. L'opzione Nessuno è per scopi di test in un ambiente di test e non è consigliabile usarla 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 include gli scopi di autenticazione server e autenticazione client nelle estensioni di utilizzo chiavi avanzato (EKU).

• L'URI usato dai client di gestione per comunicare con il 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 si trovano in subnet diverse, il nome soggetto dei certificati deve corrispondere al valore usato per il parametro RestName nel comando di Windows PowerShell Install-NetworkController.

• 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 il controller di rete affinché lo usi con il parametro -ServerCertificate del comando di Windows PowerShell Install-NetworkController. Se si è già installato il controller di rete, è possibile aggiornare la configurazione in qualsiasi momento usando il comando Set-NetworkController.

Comunicazione nel cluster del controller di rete

Il controller di rete supporta l'autenticazione, l'autorizzazione e la crittografia per la comunicazione tra i relativi nodi. La comunicazione avviene tramite Windows Communication Foundation (WCF) e TCP.

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

Per ulteriori informazioni, vedere Install-NetworkControllerCluster.

Autenticazione

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

Il controller di rete supporta le tre modalità di autenticazione seguenti tra i nodi relativi.

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

2. X509. L'autenticazione X509 si basa su certificati. È possibile usare l'autenticazione X509 quando i nodi del cluster del 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 del 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 del controller di rete, è possibile consentire ai nodi del cluster controller di rete di verificare che i nodi con cui comunicano siano attendibili e abbiano l'autorizzazione per partecipare alla comunicazione.

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

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

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

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 a livello di trasporto WCF. Questa forma di crittografia si usa quando i metodi di autenticazione e autorizzazione sono certificati Kerberos o X509. Per ulteriori informazioni, vedere gli argomenti seguenti.

• Procedura: Proteggere un servizio con credenziali di Windows
• Procedura: proteggere un servizio con certificati X.509.

Comunicazione southbound

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

La tabella seguente fornisce informazioni sull'interazione del controller di rete con diversi dispositivi southbound.

Il meccanismo di comunicazione per ognuno di questi protocolli è descritto nella sezione seguente.

Autenticazione

Per la comunicazione southbound, si usano i protocolli e i metodi di autenticazione seguenti.

1. WCF/TCP/OVSDB. Per questi protocolli, l'autenticazione è eseguita mediante certificati X509. Il controller di rete e i computer multiplexer (MUX)/host di bilanciamento del carico software (SLB) peer presentano a vicenda i propri certificati 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. È inoltre necessario configurare un certificato nei dispositivi MUX SLB e host. Il nome soggetto del certificato deve essere uguale al nome DNS del dispositivo.

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

Autorizzazione

Per la comunicazione southbound, si usano i protocolli e i metodi di autorizzazione seguenti.

1. WCF/TCP. Per questi protocolli, l'autorizzazione si basa sul nome soggetto dell'entità peer. Il 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 locale nel server. Se si usano certificati, il client presenta un certificato al server, il quale viene autorizzato dal server mediante nome soggetto/emittente e il server usa un account utente mappato per eseguire l'autenticazione.

3. OVSDB. 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.

Crittografia

Per la comunicazione southbound, per i protocolli si usano i metodi di crittografia seguenti.

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

2. WinRM. Il traffico WinRM è crittografato per impostazione predefinita mediante il provider di supporto per la sicurezza (SSP) Kerberos. È possibile configurare crittografia aggiuntiva, sotto forma di SSL, nel server WinRM.