Informazioni di riferimento tecniche sui controlli crittografici

Si applica a: Configuration Manager (Current Branch)

Configuration Manager usa la firma e la crittografia per proteggere la gestione dei dispositivi nella gerarchia di Configuration Manager. Con la firma, se i dati sono stati modificati durante il trasferimento, vengono eliminati. La crittografia impedisce a un autore di un attacco di leggere i dati usando un analizzatore del protocollo di rete.

L'algoritmo hash principale usato da Configuration Manager per la firma è SHA-256. Quando due siti di Configuration Manager comunicano tra loro, firmano le rispettive comunicazioni con SHA-256.

A partire dalla versione 2107, l'algoritmo di crittografia primario usato da Configuration Manager è AES-256. La crittografia avviene principalmente nelle due aree seguenti:

• Se si abilita la crittografia del sito, il client crittografa i dati di inventario e i messaggi di stato inviati al punto di gestione.

• Quando il client scarica i criteri segreti, il punto di gestione crittografa sempre questi criteri. Ad esempio, una sequenza di attività di distribuzione del sistema operativo che include password.

Quando si usa la comunicazione client tramite HTTPS, configurare l'infrastruttura a chiave pubblica (PKI) per l'uso di certificati con algoritmi di hash e lunghezze di chiave massime. Quando si usano certificati CNG v3, i client di Configuration Manager supportano solo certificati che usano l'algoritmo di crittografia RSA. Per altre informazioni, vedere Requisiti dei certificati PKI e Panoramica dei certificati CNG v3.

Per la sicurezza del trasporto, tutto ciò che usa TLS supporta AES-256. Questo supporto include la configurazione del sito per HTTP AVANZATO (E-HTTP) o HTTPS. Per i sistemi del sito locali, puoi controllare i pacchetti di crittografia TLS. Per i ruoli basati sul cloud come Cloud Management Gateway (CMG), se si abilita TLS 1.2, Configuration Manager configura i pacchetti di crittografia.

Per la maggior parte delle operazioni di crittografia con sistemi operativi basati su Windows, Configuration Manager usa questi algoritmi dalla libreria Windows CryptoAPI rsaenh.dll.

Per altre informazioni su funzionalità specifiche, vedere Operazioni del sito.

Operazioni del sito

Le informazioni in Configuration Manager possono essere firmate e crittografate. Supporta queste operazioni con o senza certificati PKI.

Firma dei criteri e crittografia

Il sito firma le assegnazioni dei criteri client con il certificato autofirmato. Questo comportamento consente di evitare che il rischio per la sicurezza di un punto di gestione compromesso invii criteri manomessi. Se si utilizza la gestione client basata su Internet, questo comportamento è importante perché richiede un punto di gestione con connessione Internet.

Quando il criterio contiene dati sensibili, a partire dalla versione 2107, il punto di gestione li crittografa con AES-256. I criteri che contengono dati sensibili vengono inviati solo ai client autorizzati. Il sito non crittografa i criteri che non contengono dati sensibili.

Quando un client archivia i criteri, crittografa i criteri utilizzando l'interfaccia DPAPI (Data Protection Application Programming Interface) di Windows.

Hash dei criteri

Quando un client richiede un criterio, ottiene prima un'assegnazione di criterio. Quindi sa quali politiche si applicano ad esso e può richiedere solo quegli organi di politica. Ogni assegnazione di criteri contiene l'hash calcolato per il corpo dei criteri corrispondente. Il client scarica i corpi dei criteri applicabili e quindi calcola l'hash per ogni corpo dei criteri. Se l'hash nel corpo dei criteri non corrisponde all'hash nell'assegnazione dei criteri, il client elimina il corpo dei criteri.

L'algoritmo di hash per i criteri è SHA-256.

Hash dei contenuti

Il servizio di gestione della distribuzione nel server di sito esegue l'hashing dei file di contenuto per tutti i pacchetti. Il provider dei criteri include l'hash nei criteri di distribuzione software. Quando il client di Configuration Manager scarica il contenuto, il client rigenera l'hash in locale e lo confronta con quello fornito nel criterio. Se gli hash corrispondono, il contenuto non viene modificato e il client lo installa. Se un singolo byte del contenuto viene alterato, gli hash non corrispondono e il client non installa il software. Questo controllo consente di verificare che sia installato il software corretto perché il contenuto effettivo viene confrontato con i criteri.

L'algoritmo di hashing predefinito per il contenuto è SHA-256.

Non tutti i dispositivi possono supportare l'hashing dei contenuti. Le eccezioni includono:

• Client Windows quando trasmettono in streaming contenuto App-V.

Firma e crittografia dell'inventario

Quando un client invia l'inventario hardware o software a un punto di gestione, firma sempre l'inventario. Non importa se il client comunica con il punto di gestione tramite E-HTTP o HTTPS. Se utilizzano E-HTTP, puoi anche scegliere di crittografare questi dati, il che è consigliato.

Crittografia migrazione stato

Quando una sequenza di attività acquisisce dati da un client per la distribuzione del sistema operativo, crittografa sempre i dati. Nella versione 2103 e successive, la sequenza di attività esegue Utilità migrazione stato utente (USMT) con l'algoritmo di crittografia AES-256 .

Crittografia per i pacchetti multicast

Per ogni pacchetto di distribuzione del sistema operativo, è possibile abilitare la crittografia quando si usa il multicast. Questa crittografia utilizza l'algoritmo AES-256 . Se si abilita la crittografia, non è necessaria nessun'altra configurazione del certificato. Il punto di distribuzione abilitato per il multicast genera automaticamente chiavi simmetriche per crittografare il pacchetto. Ogni pacchetto ha una chiave di crittografia diversa. La chiave viene archiviata nel punto di distribuzione abilitato per il multicast usando API Windows standard.

Quando il client si connette alla sessione multicast, lo scambio di chiavi avviene su un canale crittografato. Se il client utilizza HTTPS, utilizza il certificato di autenticazione client rilasciato dall'infrastruttura PKI. Se il client utilizza E-HTTP, utilizza il certificato autofirmato. Il client archivia la chiave di crittografia in memoria solo durante la sessione multicast.

Crittografia per i supporti di distribuzione del sistema operativo

Quando si usano i supporti per distribuire i sistemi operativi, è necessario specificare sempre una password per proteggere i supporti. Con una password, le variabili di ambiente della sequenza di attività vengono crittografate con AES-128. Gli altri dati presenti sui supporti, inclusi i pacchetti e il contenuto delle applicazioni, non sono crittografati.

Crittografia per il contenuto basato sul cloud

Quando abiliti un gateway di gestione cloud (CMG) per archiviare il contenuto, il contenuto viene crittografato con AES-256. Il contenuto viene crittografato ogni volta che lo aggiorni. Quando i client scaricano il contenuto, questo viene crittografato e protetto dalla connessione HTTPS.

Accesso agli aggiornamenti software

Tutti gli aggiornamenti software devono essere firmati da un autore attendibile per la protezione da manomissioni. Nei computer client, l'agente di Windows Update (WUA) cerca gli aggiornamenti dal catalogo. L'aggiornamento non verrà installato se non è possibile individuare il certificato digitale nell'archivio Autori attendibili nel computer locale.

Quando si pubblicano aggiornamenti software con System Center Aggiornamenti Publisher, un certificato digitale firma gli aggiornamenti software. È possibile specificare un certificato PKI o configurare Aggiornamenti Publisher per generare un certificato autofirmato per firmare l'aggiornamento software. Se si usa un certificato autofirmato per pubblicare il catalogo degli aggiornamenti, ad esempio Server di pubblicazione WSUS autofirmato, il certificato deve trovarsi anche nell'archivio certificati Autorità di certificazione radice attendibili nel computer locale. WUA controlla anche se l'impostazione dei criteri di gruppo Consenti contenuto firmato dal percorso del servizio di aggiornamento Microsoft intranet è abilitata nel computer locale. Questa impostazione dei criteri deve essere abilitata per consentire a WUA di analizzare gli aggiornamenti creati e pubblicati con System Center Aggiornamenti Publisher.

Dati di configurazione firmati per le impostazioni di conformità

Quando si importano i dati di configurazione, Configuration Manager verifica la firma digitale del file. Se i file non sono firmati o se il controllo della firma non riesce, la console avvisa di continuare con l'importazione. Importare i dati di configurazione solo se si considera attendibile esplicitamente l'autore e l'integrità dei file.

Crittografia e hash per la notifica al client

Se si utilizza la notifica del client, tutte le comunicazioni utilizzano TLS e gli algoritmi più elevati che il server e il client possono negoziare. La stessa negoziazione si verifica per l'hashing dei pacchetti trasferiti durante la notifica al client, che utilizza SHA-2.

Certificati

Per un elenco dei certificati PKI (Public Key Infrastructure) che possono essere utilizzati da Configuration Manager, eventuali requisiti o limitazioni speciali e come vengono utilizzati i certificati, vedere Requisiti dei certificati PKI. Questo elenco include gli algoritmi hash supportati e le lunghezze delle chiavi. La maggior parte dei certificati supporta la lunghezza della chiave SHA-256 e 2048 bit.

La maggior parte delle operazioni di Configuration Manager che usano i certificati supporta anche i certificati v3. Per altre informazioni, vedere Panoramica dei certificati CNG v3.

Configuration Manager richiede certificati PKI per gli scenari seguenti:

• Quando si gestiscono client di Configuration Manager su Internet

• Quando si usa un gateway di gestione cloud (CMG)

Per la maggior parte delle altre comunicazioni che richiedono certificati per l'autenticazione, la firma o la crittografia, Configuration Manager usa automaticamente i certificati PKI, se disponibili. Se non sono disponibili, Configuration Manager genera certificati autofirmati.

Gestione di dispositivi mobili e certificati PKI

Distribuzione del sistema operativo e certificati PKI

Quando si usa Configuration Manager per distribuire i sistemi operativi e un punto di gestione richiede connessioni client HTTPS, il client necessita di un certificato per comunicare con il punto di gestione. Questo requisito è anche quando il client si trova in una fase di transizione, ad esempio l'avvio dal supporto della sequenza di attività o da un punto di distribuzione abilitato per PXE. Per supportare questo scenario, creare un certificato di autenticazione client PKI ed esportarlo con la chiave privata. Importarlo quindi nelle proprietà del server del sito e aggiungere anche il certificato CA radice attendibile del punto di gestione.

Se si creano supporti di avvio, il certificato di autenticazione client viene importato quando si crea il supporto di avvio. Per proteggere la chiave privata e altri dati sensibili configurati nella sequenza di attività, configurare una password nel supporto di avvio. Ogni computer che viene avviato dal supporto di avvio usa lo stesso certificato con il punto di gestione richiesto per le funzioni client, ad esempio la richiesta di criteri client.

Se usi PXE, importare il certificato di autenticazione client nel punto di distribuzione abilitato per PXE. Usa lo stesso certificato per ogni client che viene avviato da quel punto di distribuzione abilitato per PXE. Per proteggere la chiave privata e altri dati sensibili nelle sequenze di attività, richiedi una password per PXE.

Se uno di questi certificati di autenticazione client viene compromesso, bloccare i certificati nel nodo Certificati nell'area di lavoro Amministrazione , nodo Sicurezza . Per gestire questi certificati, è necessaria l'autorizzazione per Gestire il certificato di distribuzione del sistema operativo.

Dopo la distribuzione del sistema operativo di Configuration Manager, il client richiede il proprio certificato di autenticazione client PKI per la comunicazione del client HTTPS.

Soluzioni proxy ISV e certificati PKI

I fornitori di software indipendenti (ISV) possono creare applicazioni che estendono Configuration Manager. Ad esempio, un ISV potrebbe creare estensioni per supportare piattaforme client non Windows. Tuttavia, se i sistemi del sito richiedono connessioni client HTTPS, questi client devono usare anche i certificati PKI per la comunicazione con il sito. Configuration Manager include la possibilità di assegnare un certificato al proxy ISV che abilita le comunicazioni tra i client proxy ISV e il punto di gestione. Se si usano estensioni che richiedono certificati proxy ISV, consultare la documentazione del prodotto.

Se il certificato ISV è compromesso, bloccarlo nel nodo Certificati nell'area di lavoro Amministrazione , nodo Sicurezza .

Copia il GUID per il certificato proxy ISV

A partire dalla versione 2111, per semplificare la gestione di questi certificati proxy ISV, è ora possibile copiare il relativo GUID nella console di Configuration Manager.

1. Nella console di Configuration Manager passa all'area di lavoro Amministrazione.

2. Espandere Sicurezza e selezionare il nodo Certificati .

3. Ordinare l'elenco dei certificati in base alla colonna Tipo .

4. Selezionare un certificato di tipo Proxy ISV.

5. Sulla barra multifunzione selezionare Copia GUID certificato.

Questa azione copia il GUID di questo certificato, ad esempio: aa05bf38-5cd6-43ea-ac61-ab101f943987

Asset Intelligence e certificati

Da novembre 2021 Asset Intelligence è deprecato e consigliamo ai clienti di disinstallare questo ruolo.

Servizi e certificati di Azure

Il gateway di gestione cloud (CMG) richiede certificati di autenticazione del server. Questi certificati consentono al servizio di fornire la comunicazione HTTPS ai client tramite Internet. Per altre informazioni, vedere Certificato di autenticazione del server CMG.

I client richiedono un altro tipo di autenticazione per comunicare con un gateway di gestione cloud e il punto di gestione locale. Possono usare Microsoft Entra ID, un certificato PKI o un token del sito. Per altre informazioni, vedere Configurare l'autenticazione client per il gateway di gestione cloud.

I client non richiedono un certificato PKI client per usare l'archiviazione basata sul cloud. Dopo l'autenticazione al punto di gestione, il punto di gestione rilascia un token di accesso di Configuration Manager al client. Il client presenta questo token al gateway di gestione cloud per accedere al contenuto. Il token è valido per otto ore.

Controllo CRL dei certificati PKI

Un elenco di revoche di certificati PKI (CRL) migliora la sicurezza complessiva, ma richiede un sovraccarico amministrativo e di elaborazione. Se si abilita il controllo CRL, ma i client non possono accedere al CRL, la connessione PKI avrà esito negativo.

IIS abilita il controllo CRL per impostazione predefinita. Se si usa un CRL con la distribuzione PKI, non è necessario configurare la maggior parte dei sistemi del sito che eseguono IIS. L'eccezione è per gli aggiornamenti software, che richiedono un passaggio manuale per abilitare il controllo CRL per verificare le firme nei file di aggiornamento software.

Quando un client utilizza HTTPS, abilita il controllo CRL per impostazione predefinita.

Le connessioni seguenti non supportano il controllo CRL in Configuration Manager:

• Connessioni da server a server

Comunicazione server

Configuration Manager usa i controlli crittografici seguenti per la comunicazione del server.

Comunicazione server all'interno di un sito

Ogni server del sistema del sito usa un certificato per trasferire i dati ad altri sistemi del sito nello stesso sito di Configuration Manager. Alcuni ruoli del sistema del sito usano anche i certificati per l'autenticazione. Ad esempio, se si installa il punto proxy di registrazione in un server e il punto di registrazione in un altro server, è possibile autenticarsi reciprocamente utilizzando questo certificato di identità.

Quando Configuration Manager usa un certificato per questa comunicazione, se è disponibile un certificato PKI con funzionalità di autenticazione server, Configuration Manager lo usa automaticamente. In caso contrario, Configuration Manager genera un certificato autofirmato. Questo certificato autofirmato ha funzionalità di autenticazione server, usa SHA-256 e ha una lunghezza della chiave di 2048 bit. Configuration Manager copia il certificato nell'archivio Trusted People in altri server del sistema del sito che potrebbe essere necessario considerare attendibile il sistema del sito. I sistemi del sito possono quindi considerare attendibili l'uno l'altro usando questi certificati e PeerTrust.

Oltre a questo certificato per ogni server del sistema del sito, Configuration Manager genera un certificato autofirmato per la maggior parte dei ruoli del sistema del sito. Quando sono presenti più istanze del ruolo del sistema del sito nello stesso sito, condividono lo stesso certificato. Ad esempio, è possibile che nello stesso sito siano presenti più punti di gestione. Questo certificato autofirmato utilizza SHA-256 e ha una lunghezza della chiave di 2048 bit. Viene copiato nel Trusted People Store nei server del sistema del sito che potrebbero dover considerare attendibili. I ruoli del sistema del sito seguenti generano questo certificato:

• Punto di sincronizzazione di Asset Intelligence

• Punto di protezione degli endpoint

• Punto di stato di fallback

• Punto di gestione

• Punto di distribuzione abilitato per il multicast

• Punto di Reporting Services

• Punto di aggiornamento software

• Punto di migrazione stato

Configuration Manager genera e gestisce automaticamente questi certificati.

Per inviare messaggi di stato dal punto di distribuzione al punto di gestione, Configuration Manager usa un certificato di autenticazione client. Quando si configura il punto di gestione per HTTPS, è necessario un certificato PKI. Se il punto di gestione accetta connessioni E-HTTP, è possibile utilizzare un certificato PKI. Può anche usare un certificato autofirmato con funzionalità di autenticazione client, utilizza SHA-256 e ha una lunghezza della chiave di 2048 bit.

Comunicazione server tra siti

Configuration Manager trasferisce i dati tra siti usando la replica del database e la replica basata su file. Per altre informazioni, vedere Trasferimenti di dati tra siti e comunicazioni tra endpoint.

Configuration Manager configura automaticamente la replica del database tra i siti. Se disponibili, utilizza certificati PKI con funzionalità di autenticazione del server. Se non è disponibile, Configuration Manager crea certificati autofirmati per l'autenticazione del server. In entrambi i casi, esegue l'autenticazione tra siti usando i certificati nell'archivio Trusted People che usa PeerTrust. Usa questo archivio certificati per assicurarsi che solo i server SQL gerarchi di Configuration Manager partecipino alla replica da sito a sito.

I server del sito stabiliscono una comunicazione da sito a sito usando uno scambio di chiavi sicuro che avviene automaticamente. Il server del sito di invio genera un hash e lo firma con la propria chiave privata. Il server del sito ricevente controlla la firma usando la chiave pubblica e confronta l'hash con un valore generato localmente. In caso di corrispondenza, il sito ricevente accetta i dati replicati. Se i valori non corrispondono, Configuration Manager rifiuta i dati di replica.

La replica del database in Configuration Manager usa Service Broker di SQL Server per trasferire i dati tra i siti. Usa i seguenti meccanismi:

• Da SQL Server a SQL Server: questa connessione usa le credenziali di Windows per l'autenticazione del server e certificati autofirmati con 1024 bit per firmare e crittografare i dati con l'algoritmo AES. Se disponibili, utilizza certificati PKI con funzionalità di autenticazione del server. Usa solo i certificati nell'archivio certificati personali del computer.

• SQL Service Broker: questo servizio usa certificati autofirmati con 2048 bit per l'autenticazione e per firmare e crittografare i dati con l'algoritmo AES. Usa solo certificati nel database master di SQL Server.

La replica basata su file usa il protocollo SMB (Server Message Block). Usa SHA-256 per firmare i dati che non sono crittografati e non contengono dati sensibili. Per crittografare questi dati, usare IPsec, che viene implementato indipendentemente da Configuration Manager.

Client che usano HTTPS

Quando i ruoli del sistema del sito accettano connessioni client, è possibile configurarli in modo che accettino connessioni HTTPS e HTTP o solo connessioni HTTPS. I ruoli di sistema del sito che accettano connessioni da Internet accettano solo connessioni client tramite HTTPS.

Le connessioni client tramite HTTPS offrono un livello di sicurezza superiore grazie all'integrazione con un'infrastruttura a chiave pubblica (PKI) per proteggere le comunicazioni client-server. Tuttavia, la configurazione delle connessioni client HTTPS senza una conoscenza approfondita della pianificazione, della distribuzione e delle operazioni PKI potrebbe comunque lasciare vulnerabili. Ad esempio, se non si protegge l'autorità di certificazione radice (CA), gli utenti malintenzionati possono compromettere l'attendibilità dell'intera infrastruttura PKI. La mancata distribuzione e gestione dei certificati PKI tramite processi controllati e protetti potrebbe causare client non gestiti che non possono ricevere aggiornamenti o pacchetti software critici.

Comunicazione non crittografata quando i client utilizzano HTTPS

Quando i client comunicano con i sistemi del sito tramite HTTPS, la maggior parte del traffico viene crittografata. Nelle situazioni seguenti, i client comunicano con i sistemi del sito senza utilizzare la crittografia:

• Il client non riesce a stabilire una connessione HTTPS nella Intranet e torna a usare HTTP quando i sistemi del sito consentono questa configurazione.

• Comunicazione ai ruoli di sistema del sito seguenti:

  • Il client invia messaggi di stato al punto di stato di fallback.

  • Il client invia richieste PXE a un punto di distribuzione abilitato per PXE.

  • Il client invia i dati di notifica a un punto di gestione.

Configurare i punti di Reporting Services per l'utilizzo di HTTP o HTTPS indipendentemente dalla modalità di comunicazione client.

Client che utilizzano E-HTTP

Quando i client usano la comunicazione E-HTTP con i ruoli del sistema del sito, possono usare certificati PKI per l'autenticazione client o certificati autofirmati generati da Gestione configurazione. Quando Configuration Manager genera certificati autofirmati, dispone di un identificatore di oggetto personalizzato per la firma e la crittografia. Questi certificati vengono usati per identificare in modo univoco il client. Questi certificati autofirmati usano SHA-256 e hanno una lunghezza della chiave di 2048 bit.

Distribuzione del sistema operativo e certificati autofirmati

Quando si usa Configuration Manager per distribuire sistemi operativi con certificati autofirmati, anche il client deve avere un certificato per comunicare con il punto di gestione. Questo requisito si verifica anche se il computer si trova in una fase di transizione, ad esempio l'avvio da un supporto della sequenza di attività o da un punto di distribuzione abilitato per PXE. Per supportare questo scenario per le connessioni client E-HTTP, Configuration Manager genera certificati autofirmati con un identificatore di oggetto personalizzato per la firma e la crittografia. Questi certificati vengono usati per identificare in modo univoco il client. Questi certificati autofirmati usano SHA-256 e hanno una lunghezza della chiave di 2048 bit. Se questi certificati autofirmati vengono compromessi, impedire agli utenti malintenzionati di usarli per rappresentare client attendibili. Bloccare i certificati nel nodo Certificati nell'area di lavoro Amministrazione , nodo Sicurezza .

Autenticazione client e server

Quando i client si connettono tramite E-HTTP, autenticano i punti di gestione usando Active Directory Domain Services o usando la chiave radice attendibile di Configuration Manager. I client non autenticano altri ruoli del sistema del sito, ad esempio punti di migrazione stato o punti di aggiornamento software.

Quando un punto di gestione autentica per la prima volta un client usando il certificato client autofirmato, questo meccanismo offre una sicurezza minima perché qualsiasi computer può generare un certificato autofirmato. Usa l'approvazione del cliente per migliorare questo processo. Approvare solo computer attendibili, automaticamente da Configuration Manager o manualmente da un utente amministratore. Per ulteriori informazioni, vedere Gestire i client.

Informazioni sulle vulnerabilità SSL

Per migliorare la sicurezza dei client e dei server di Configuration Manager, esegui le azioni seguenti:

• Abilita TLS 1.2 in tutti i dispositivi e servizi. Per abilitare TLS 1.2 per Configuration Manager, vedi Come abilitare TLS 1.2 per Configuration Manager.

• Disabilitare SSL 3.0, TLS 1.0 e TLS 1.1.

• Riordinare i pacchetti di crittografia correlati a TLS.

Per altre informazioni, vedere gli articoli seguenti:

• Limitare l'uso di determinati algoritmi e protocolli di crittografia in Schannel.dll.
• Assegnazione di priorità ai pacchetti di crittografia Schannel

Queste procedure non influiscono sulla funzionalità di Configuration Manager.