Esaminare la funzionalità di sicurezza della comunicazione remota di Windows PowerShell
Per impostazione predefinita, gli endpoint creati da Windows PowerShell consentono le connessioni solo da parte dei membri di un gruppo specifico. A partire da Windows Server 2016 e Windows 10, questi gruppi includono il gruppo Utenti gestione remota e il gruppo Administrators locale. In un dominio Active Directory Domain Services quest'ultimo include anche i membri del gruppo globale di dominio Domain Admins, poiché tale gruppo è membro del gruppo Administrators locale in ogni computer aggiunto al dominio. Prima di Windows Server 2016 e Windows 10, per impostazione predefinita solo i membri del gruppo Administrators locale erano autorizzati a usare la comunicazione remota di PowerShell. È tuttavia possibile modificare le impostazioni predefinite. Ogni endpoint dispone di un elenco di controllo di accesso di sistema (SACL) che è possibile modificare per controllare esattamente chi può connettersi.
La comunicazione remota di PowerShell e WinRM sono in ascolto sulle porte seguenti:
- HTTP: 5985
- HTTPS: 5986
Il comportamento di comunicazione remota predefinito consiste nel delegare le credenziali di accesso al computer remoto, ma è anche possibile specificare credenziali alternative quando si stabilisce una connessione. Il computer remoto a cui ci si connette usa queste credenziali per rappresentare l'utente ed eseguire le attività specificate usando tali credenziali. Se è stato abilitato il controllo, oltre alle attività eseguite dall'utente verranno controllate anche le attività eseguite dalla comunicazione remota di PowerShell per conto dell'utente. La comunicazione remota è trasparente per la sicurezza e non modifica la sicurezza esistente dell'ambiente. Con la comunicazione remota è possibile eseguire tutte le stesse attività che si eseguono trovandosi fisicamente davanti al computer locale.
Nota
Nelle reti private la regola di Windows Firewall predefinita per la comunicazione remota di PowerShell accetta tutte le connessioni. Sulle reti pubbliche la regola Firewall di Windows predefinita consente le connessioni della comunicazione remota di PowerShell solo dall'interno della stessa subnet. È necessario modificare in modo esplicito tale regola per aprire la comunicazione remota di PowerShell per tutte le connessioni in una rete pubblica.
Rischi di sicurezza e autenticazione reciproca
Delegare le credenziali a un computer remoto comporta alcuni rischi di sicurezza. Se, ad esempio, un utente malintenzionato rappresenta correttamente un computer remoto noto, si potrebbero trasmettere credenziali con privilegi elevati a tale utente malintenzionato, che le potrà quindi usare a scopo dannoso. A causa di questo rischio, la comunicazione remota richiede per impostazione predefinita l'autenticazione reciproca, il che significa che l'utente deve eseguire l'autenticazione nel computer remoto e il computer remoto deve autenticarsi con l'utente. Questa autenticazione reciproca fa in modo che la connessione avvenga solo al computer previsto.
L'autenticazione reciproca è una funzionalità nativa del protocollo di autenticazione Kerberos di Active Directory. Quando ci si connette tra computer di dominio attendibili, l'autenticazione reciproca avviene automaticamente. Quando ci si connette a computer non aggiunti a un dominio, è necessario fornire un'altra forma di autenticazione reciproca attraverso un certificato SSL e il protocollo HTTPS che deve essere configurato in anticipo. Un'altra opzione consiste nel disattivare il requisito per l'autenticazione reciproca aggiungendo il computer remoto all'elenco TrustedHosts locale. Si noti, tuttavia, che l'elenco TrustedHosts usa l'autenticazione NTLM (NT LAN Manager), che non garantisce l'identità del server. Come con qualsiasi protocollo che usa NTLM per l'autenticazione, gli utenti malintenzionati che hanno accesso a un account attendibile di un computer aggiunto al dominio possono fare in modo che il controller di dominio crei una chiave di sessione NTLM e quindi possono rappresentare il server.
Nota
Il protocollo di autenticazione NTLM non può assicurare l'identità del server di destinazione, ma può solo verificare che conosca già la password. È quindi necessario configurare i server di destinazione per usare SSL per la comunicazione remota di PowerShell. Ottenendo un certificato SSL rilasciato da un'autorità di certificazione attendibile che il client considera affidabile e assegnandolo al server di destinazione, è possibile migliorare la sicurezza dell'autenticazione basata su NTLM, grazie alla possibilità di convalidare sia l'identità utente che l'identità del server.
Considerazioni sul nome computer
Per il funzionamento dell'autenticazione basata su Active Directory Domain Services, la comunicazione remota di PowerShell deve essere in grado di cercare e recuperare gli oggetti computer Active Directory Domain Services. Ciò significa che è necessario fare riferimento ai computer di destinazione usando i relativi nomi di dominio completi (FQDN). Gli indirizzi IP o gli alias DNS (Domain Name System), ad esempio, non funzionano perché non forniscono la comunicazione remota con l'autenticazione reciproca necessaria. Se è necessario fare riferimento a un computer tramite un indirizzo IP o un alias DNS, è necessario stabilire la connessione usando HTTPS, il che significa che il computer remoto deve essere configurato per accettare tale protocollo. In alternativa, è necessario aggiungere l'indirizzo IP o l'alias DNS all'elenco TrustedHosts locale.
Nota
È prevista un'eccezione speciale per il nome computer localhost, che consente di usare tale nome per la connessione al computer locale senza altre modifiche alla configurazione. Se il computer locale usa un sistema operativo basato su client, è necessario configurare WinRM.
Elenco TrustedHosts
L'elenco TrustedHosts è un'impostazione configurata localmente che è anche possibile configurare usando un oggetto Criteri di gruppo. L'elenco TrustedHosts enumera i computer per i quali l'autenticazione reciproca non è possibile. I computer devono essere elencati con lo stesso nome che si userà per connettersi a essi, indipendentemente dal fatto che si tratti del nome computer effettivo, di un alias DNS o di un indirizzo IP. È possibile usare caratteri jolly per specificare SRV*, che consente la connessione di qualsiasi computer il cui nome o alias DNS inizia con SRV. Prestare tuttavia attenzione quando si usa questo elenco. Mentre l'elenco TrustedHosts semplifica la connessione ai computer non di dominio senza che sia necessario configurare HTTPS, ignora una misura di sicurezza importante. Consente di inviare le credenziali a un computer remoto senza determinare se il computer è effettivamente quello a cui ci si vuole connettere. È consigliabile usare l'elenco TrustedHosts solo per designare i computer che si è certi che non siano compromessi, ad esempio i server ospitati in un data center protetto. È anche possibile usare l'elenco TrustedHosts per abilitare temporaneamente le connessioni a computer non di dominio in una subnet di rete controllata, ad esempio i nuovi computer sottoposti a un processo di provisioning.
Nota
Come procedura consigliata, evitare di usare l'elenco TrustedHosts a meno che non sia assolutamente necessario. La configurazione di un computer non di dominio per l'uso di HTTPS è una soluzione a lungo termine più sicura.
Riservatezza
Per impostazione predefinita, la comunicazione remota usa HTTP, che non offre privacy o crittografia del contenuto delle comunicazioni. Windows PowerShell, tuttavia, consente di applicare la crittografia a livello di applicazione per impostazione predefinita. Ciò significa che le comunicazioni ricevono un livello di privacy e protezione. Nelle reti interne questa crittografia a livello di applicazione è in genere sufficiente per soddisfare i requisiti di sicurezza dell'organizzazione.
In un ambiente di dominio che usa il protocollo di autenticazione Kerberos predefinito, le credenziali vengono inviate sotto forma di ticket Kerberos crittografati che non includono le password.
Quando ci si connette tramite HTTPS, l'intero canale viene crittografato usando le chiavi di crittografia del certificato SSL del computer remoto. Di conseguenza, anche se si usa l'autenticazione di base, le password non vengono trasmesse in testo non crittografato. Tuttavia, quando ci si connette usando HTTP e l'autenticazione di base a un computer che non è configurato per HTTPS, le credenziali (incluse le password) vengono trasmesse in testo non crittografato. Ciò può verificarsi, ad esempio, quando ci si connette a un computer non di dominio aggiunto all'elenco TrustedHosts locale. Ciò può accadere anche quando si usa un computer aggiunto a un dominio specificando il relativo indirizzo IP invece del nome host.
Poiché in tale scenario le credenziali vengono trasmesse in testo non crittografato, è necessario assicurarsi di connettersi a un computer non di dominio solo in una subnet di rete controllata e protetta, ad esempio una designata appositamente per il provisioning di nuovi computer. Se è necessario connettersi regolarmente a un computer non di dominio, configurarlo per supportare HTTPS.