Informazioni di riferimento tecniche sui controlli crittografici

  • Articolo

Si applica a: Configuration Manager (Current Branch)

Configuration Manager usa la firma e la crittografia per proteggere la gestione dei dispositivi nella gerarchia Configuration Manager. Con la firma, se i dati sono stati modificati in transito, vengono eliminati. La crittografia consente di impedire a un utente malintenzionato di leggere i dati usando un analizzatore del protocollo di rete.

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

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

  • Se si abilita il sito a Usare la crittografia, 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 le password.

Per i client della versione 2103 e precedenti, l'algoritmo di crittografia primario è 3DES.

Nota

Se si configura la comunicazione HTTPS, questi messaggi vengono crittografati due volte. Il messaggio viene crittografato con AES, quindi il trasporto HTTPS viene crittografato con AES.

Quando si usa la comunicazione client tramite HTTPS, configurare l'infrastruttura a chiave pubblica (PKI) per l'uso di certificati con gli algoritmi hash massimi e la lunghezza della chiave. Quando si usano certificati CNG v3, i client Configuration Manager supportano solo i 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, qualsiasi elemento che usa TLS supporta AES. Questo supporto include quando si configura il sito per HTTP o HTTPS avanzato. Per i sistemi del sito locali, è possibile controllare i pacchetti di crittografia TLS. Per i ruoli basati sul cloud, ad esempio 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 CryptoAPI di Windows rsaenh.dll.

Per altre informazioni sulle 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 e crittografia dei criteri

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

Quando i criteri contengono dati sensibili, a partire dalla versione 2107, il punto di gestione lo crittografa con AES-256. Nella versione 2103 e versioni precedenti usa 3DES. I criteri che contengono dati sensibili vengono inviati solo ai client autorizzati. Il sito non crittografa i criteri che non dispongono di dati sensibili.

Quando un client archivia i criteri, crittografa i criteri usando LPAPI (Data Protection Application Programming Interface) di Windows.

Hash dei criteri

Quando un client richiede criteri, ottiene prima un'assegnazione di criteri. Poi sa quali politiche si applicano a tale politica e può richiedere solo tali organismi politici. Ogni assegnazione di criteri contiene l'hash calcolato per il corpo dei criteri corrispondente. Il client scarica gli organismi dei criteri applicabili e quindi calcola l'hash per ogni corpo dei criteri. Se l'hash nel corpo del criterio non corrisponde all'hash nell'assegnazione dei criteri, il client elimina il corpo del criterio.

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

Hash del contenuto

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

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

Non tutti i dispositivi possono supportare l'hash del contenuto. Le eccezioni includono:

  • Client Windows quando trasmettono contenuto App-V.

  • Client Windows Mobile, anche se questi client verificano la firma di un'applicazione firmata da un'origine attendibile.

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 HTTP o HTTPS. Se usano HTTP, è anche possibile scegliere di crittografare questi dati, operazione consigliata.

Crittografia della migrazione dello stato

Quando una sequenza di attività acquisisce i dati da un client per la distribuzione del sistema operativo, i dati vengono sempre crittografati. Nella versione 2103 e successive, la sequenza di attività esegue lo Strumento di migrazione stato utente (USMT) con l'algoritmo di crittografia AES-256 . Nella versione 2010 e versioni precedenti usa 3DES.

Crittografia per i pacchetti multicast

Per ogni pacchetto di distribuzione del sistema operativo, è possibile abilitare la crittografia quando si usa il multicast. Questa crittografia usa l'algoritmo AES . Se si abilita la crittografia, non è necessaria alcuna 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 le API Windows standard.

Quando il client si connette alla sessione multicast, lo scambio di chiavi si verifica su un canale crittografato. Se il client usa HTTPS, usa il certificato di autenticazione client emesso da PKI. Se il client usa HTTP, usa il certificato autofirma. Il client archivia la chiave di crittografia solo in memoria durante la sessione multicast.

Crittografia per i supporti di distribuzione del sistema operativo

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

Crittografia per il contenuto basato sul cloud

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

Accesso agli aggiornamenti software

Tutti gli aggiornamenti software devono essere firmati da un autore attendibile per proteggersi dalle manomissioni. Nei computer client, l'agente Windows Update analizza gli aggiornamenti dal catalogo. Non installa l'aggiornamento se non riesce a 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 server di pubblicazione per generare un certificato autofirmato per firmare l'aggiornamento software. Se si usa un certificato autofirma per pubblicare il catalogo degli aggiornamenti, ad esempio server di pubblicazione WSUS autofirmate, 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 dalla posizione del servizio di aggiornamento Microsoft intranet è abilitata nel computer locale. Questa impostazione di criterio deve essere abilitata affinché WUA analizzi 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 esplicitamente attendibile il server di pubblicazione e l'integrità dei file.

Crittografia e hash per la notifica client

Se si usa la notifica client, tutte le comunicazioni usano TLS e gli algoritmi più elevati che il server e il client possono negoziare. Ad esempio, tutte le versioni del sistema operativo Windows supportate possono usare almeno la crittografia AES-128 . La stessa negoziazione si verifica per l'hash dei pacchetti trasferiti durante la notifica client, che usa SHA-2.

Certificati

Per un elenco dei certificati PKI (Public Key Infrastructure) che possono essere usati da Configuration Manager, eventuali requisiti o limitazioni speciali e come vengono usati 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 Configuration Manager che usano certificati supporta anche i certificati v3. Per altre informazioni, vedere Panoramica dei certificati CNG v3.

Nota

Tutti i certificati usati Configuration Manager devono contenere solo caratteri a byte singolo nel nome soggetto o nel nome alternativo del soggetto.

Configuration Manager richiede certificati PKI per gli scenari seguenti:

  • Quando si gestiscono i client Configuration Manager su Internet

  • Quando si gestiscono i client Configuration Manager nei dispositivi mobili

  • Quando si gestiscono computer macOS

  • 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.

Configuration Manager non usa i certificati PKI quando gestisce i dispositivi mobili usando il connettore Exchange Server.

Gestione dei dispositivi mobili e certificati PKI

Se il dispositivo mobile non è bloccato dall'operatore di telefonia mobile, è possibile usare Configuration Manager per richiedere e installare un certificato client. Questo certificato fornisce l'autenticazione reciproca tra il client nel dispositivo mobile e Configuration Manager sistemi del sito. Se il dispositivo mobile è bloccato, non è possibile usare Configuration Manager per distribuire i certificati.

Se si abilita l'inventario hardware per i dispositivi mobili, Configuration Manager inventaria anche i certificati installati nel dispositivo mobile.

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 ha bisogno 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 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 crea un supporto di avvio, importare il certificato di autenticazione client 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 esegue l'avvio dal supporto di avvio usa lo stesso certificato con il punto di gestione necessario per le funzioni client, ad esempio la richiesta di criteri client.

Se si usa 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à, richiedere una password per PXE.

Se uno di questi certificati di autenticazione client è 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 Configuration Manager la distribuzione del sistema operativo installa il client, il client richiede il proprio certificato di autenticazione client PKI per la comunicazione 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, ad esempio macOS. 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 consente le comunicazioni tra i client proxy ISV e il punto di gestione. Se si usano estensioni che richiedono certificati proxy ISV, consultare la documentazione relativa a tale prodotto.

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

Copiare il GUID per il certificato proxy ISV

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

  1. Nella console Configuration Manager passare 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. Nella barra multifunzione selezionare Copia GUID certificato.

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

Asset Intelligence e certificati

Configuration Manager viene installato con un certificato X.509 usato dal punto di sincronizzazione di Asset Intelligence per connettersi a Microsoft. Configuration Manager usa questo certificato per richiedere un certificato di autenticazione client al servizio certificati Microsoft. Il certificato di autenticazione client viene installato nel punto di sincronizzazione di Asset Intelligence e viene usato per autenticare il server in Microsoft. Configuration Manager usa il certificato di autenticazione client per scaricare il catalogo di Asset Intelligence e caricare i titoli software.

Questo certificato ha una lunghezza della chiave di 1024 bit.

Servizi e certificati di Azure

Il gateway di gestione cloud (CMG) richiede certificati di autenticazione server. Questi certificati consentono al servizio di fornire comunicazioni 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 cmg 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 Configuration Manager al client. Il client presenta questo token al cmg per accedere al contenuto. Il token è valido per otto ore.

Controllo CRL per i certificati PKI

Un elenco di revoche di certificati PKI aumenta la sicurezza complessiva, ma richiede un sovraccarico amministrativo ed di elaborazione. Se si abilita il controllo CRL, ma i client non possono accedere al CRL, la connessione PKI ha 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 riguarda gli aggiornamenti software, che richiede un passaggio manuale per abilitare il controllo CRL per verificare le firme nei file di aggiornamento software.

Quando un client usa HTTPS, abilita il controllo CRL per impostazione predefinita. Per i client macOS, non è possibile disabilitare il controllo CRL.

Le connessioni seguenti non supportano l'archiviazione CRL Configuration Manager:

  • Connessioni da server a server

  • Dispositivi mobili registrati da Configuration Manager.

Comunicazione server

Configuration Manager usa i controlli di crittografia seguenti per la comunicazione con il 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 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, possono autenticarsi l'un l'altro usando 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 autofirma. 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 Persone attendibile in altri server del sistema del sito che potrebbero dover considerare attendibile il sistema del sito. I sistemi del sito possono quindi considerarsi attendibili l'un l'altro usando questi certificati e PeerTrust.

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

  • Punto di sincronizzazione di Asset Intelligence

  • Punto di registrazione certificati

  • Punto di Endpoint Protection

  • Punto di registrazione

  • Punto di stato di fallback

  • Punto di gestione

  • Punto di distribuzione abilitato per 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 HTTP, è possibile usare un certificato PKI. Può anche usare un certificato autofirmato con funzionalità di autenticazione client, usa SHA-256 e ha una lunghezza della chiave di 2048 bit.

Comunicazione server tra siti

Configuration Manager trasferisce dati tra siti usando la replica di 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 siti. Se disponibile, usa certificati PKI con funzionalità di autenticazione server. Se non disponibile, Configuration Manager crea certificati autofirmati per l'autenticazione server. In entrambi i casi, esegue l'autenticazione tra siti usando i certificati nell'archivio Persone attendibile che usa PeerTrust. Usa questo archivio certificati per assicurarsi che solo la gerarchia Configuration Manager SQL Server partecipi alla replica da sito a sito.

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

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

  • SQL Server per SQL Server: questa connessione usa le credenziali di Windows per l'autenticazione del server e i certificati autofirmati con 1024 bit per firmare e crittografare i dati con l'algoritmo AES. Se disponibile, usa certificati PKI con funzionalità di autenticazione 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 i certificati nel database master SQL Server.

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

Client che usano HTTPS

Quando i ruoli del sistema del sito accettano connessioni client, è possibile configurarle per accettare connessioni HTTPS e HTTP o solo connessioni HTTPS. I ruoli del 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 da client a server. Tuttavia, la configurazione delle connessioni client HTTPS senza una conoscenza approfondita della pianificazione, della distribuzione e delle operazioni dell'infrastruttura a chiave pubblica potrebbe comunque lasciare vulnerabili. Ad esempio, se non si protegge l'autorità di certificazione radice, gli utenti malintenzionati potrebbero 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 pacchetti o aggiornamenti software critici.

Importante

I certificati PKI usati Configuration Manager per la comunicazione client proteggono la comunicazione solo tra il client e alcuni sistemi del sito. Non proteggono il canale di comunicazione tra il server del sito e i sistemi del sito o tra i server del sito.

Comunicazione non crittografata quando i client usano 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 usare la crittografia:

  • Il client non riesce a stabilire una connessione HTTPS nella intranet e torna all'uso di HTTP quando i sistemi del sito consentono questa configurazione.

  • Comunicazione con i ruoli del 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.

I punti di Reporting Services vengono configurati per l'uso di HTTP o HTTPS in modo indipendente dalla modalità di comunicazione client.

Client che usano HTTP

Quando i client usano la comunicazione HTTP con i ruoli del sistema del sito, possono usare i certificati PKI per l'autenticazione client o i certificati autofirmati generati Configuration Manager. Quando Configuration Manager genera certificati autofirmati, hanno 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, il client deve avere anche un certificato per comunicare con il punto di gestione. Questo requisito è anche se il computer si trova in una fase di transizione, ad esempio l'avvio dal supporto della sequenza di attività o un punto di distribuzione abilitato per PXE. Per supportare questo scenario per le connessioni client 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 i 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 HTTP, autenticano i punti di gestione usando Active Directory Domain Services o la chiave radice attendibile Configuration Manager. I client non autenticano altri ruoli del sistema del sito, ad esempio i punti di migrazione dello stato o i punti di aggiornamento software.

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

Informazioni sulle vulnerabilità SSL

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

  • Abilitare TLS 1.2 in tutti i dispositivi e i servizi. Per abilitare TLS 1.2 per Configuration Manager, vedere 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:

Queste procedure non influiscono sulle funzionalità Configuration Manager.

Nota

Aggiornamenti per Configuration Manager il download dalla rete per la distribuzione di contenuti (CDN) di Azure, che ha requisiti di suite di crittografia. Per altre informazioni, vedere Domande frequenti sulla configurazione di Frontdoor di Azure: TLS.