WMI può essere protetto per essere sicuro per le reti interne seguendo alcuni passaggi di configurazione:
link
Riservatezza
Il problema più immediato (per me) è richiedere la crittografia in transito per mitigare lo snooping (estratto di sopra):
An administrator or a MOF file can configure a WMI namespace so that no data is returned unless you use packet privacy (RPC_C_AUTHN_LEVEL_PKT_PRIVACY or PktPrivacy as a moniker in a script) in a connection to that namespace. This ensures that data is encrypted as it crosses the network. If you try to set a lower authentication level, you will get an access denied message. For more information, see Requiring an Encrypted Connection to a Namespace.
Minimo privilegio
La prossima cosa più importante è il minimo privilegio tramite RBAC. È necessario limitare l'account del prodotto di gestione delle risorse alle operazioni WMI di sola lettura e, se possibile, limitare ciò che può leggere a ciò che è necessario. Questo è ottenuto tramite Namespace Security ed è descritto più avanti qui:
link
Potrebbe essere necessario consentire determinati privilegi di scrittura se il software di gestione degli asset esegue anche azioni sugli endpoint anziché solo su audit. Premi il fornitore per una configurazione con privilegi minimi.
Strong Authentication
Una volta ottenuto ciò, dovresti generare valori random ad alta entropia (usando tutti i caratteri e la lunghezza massima con cui lo strumento di gestione delle risorse funzionerà) sia per il nome utente che per la password. Queste credenziali devono essere archiviate in un sistema di gestione delle password sicuro come Thycotic Secret Server o un gestore di password sicuro locale come KeePass per il quale si gestiscono i backup. Probabilmente puoi usare un nome utente non casuale, ma questo aumenta un po 'il rischio se è facilmente indovinato e usa un nome utente casuale dato che raramente hai bisogno di gestirlo ti dà un aumento di sicurezza gratuito.
Sicurezza di rete
Dopo tutto, è necessario impostare Windows Firewall con Advanced Security per consentire le connessioni DCOM necessarie per WMI solo sulla porta su cui è in esecuzione e solo dall'host (o dagli host se si sta facendo HA) che esegue il software di gestione delle risorse. Questo è l'ultimo livello della difesa in profondità qui e rende più difficile per gli attaccanti sfruttare anche se hanno le credenziali.
Single-purpose Single Server / VM
Il software di gestione degli asset dovrebbe essere eseguito da solo su un server o VM dedicato. La whitelist del firewall è molto meno utile se si trova su un app di app misc con tutte le altre cose di cui una rete ha bisogno. Eseguirlo con altri software o servizi espone anche questo e le credenziali a rischi di attacchi locali non necessari.
Potresti riuscire a inserire questi passaggi in un oggetto Criteri di gruppo.
Soluzione alternativa: PowerShell
Un'alternativa (sebbene incompatibile con il tuo prodotto di gestione delle risorse) è PowerShell Remoting. Utilizza l'autenticazione TLS e GSSAPI integrata con AD, quindi mi sento molto a mio agio. Lo usiamo in produzione.
Una volta attivato il servizio remoto di PowerShell, è possibile accedere in remoto a un sistema con Enter-PSSession% MachineName% . Puoi anche utilizzare Invoke-Command con -ScriptBlock per eseguire un comando in remoto e ottenere risultati centralmente per il coordinamento. I tuoi comandi WMI potrebbero essere eseguiti in questo modo.
Ecco una guida per abilitare il servizio remoto di PowerShell:
link
Conclusione
La sfida con entrambi questi è la fiducia transitiva e il movimento laterale. Fai attenzione che gli account autorizzati a fare questo salto tra le macchine abbiano password molto forti. Per questo utilizziamo password ASCII casuali complete di 100 caratteri per persona, che ruotiamo ogni 90 giorni. Usiamo KeePass per autotiparli poiché non sono pratici da digitare a mano.