Distribuzione di Microsoft Cloud PKI per Microsoft Intune

Questo articolo descrive i modelli di distribuzione supportati da Microsoft Intune e dal servizio Microsoft Cloud PKI.

Sono disponibili due opzioni di distribuzione:

• CA radice di Microsoft Cloud PKI: distribuire Microsoft Cloud PKI usando la radice e le CA di emissione nel cloud.

• Bring Your Own Certification Authority (BYOCA): distribuire Microsoft Cloud PKI usando la propria CA privata.

Con l'approccio CA radice PKI di Microsoft Cloud, è possibile creare una o più PKI all'interno di un singolo tenant di Intune. La distribuzione di Cloud PKI in questo modo crea una gerarchia a due livelli, in modo da poter disporre di più CA emittenti subordinate alla CA radice. Queste CA non sono pubbliche. È invece necessario creare sia la CA radice che le CA emittenti nel cloud, private per il tenant di Intune. La CA emittente rilascia certificati ai dispositivi gestiti da Intune usando il profilo di certificato SCEP di configurazione del dispositivo.

In alternativa, è possibile portare la propria autorità di certificazione (BYOCA). Con questo approccio, è possibile distribuire Microsoft Cloud PKI usando la propria CA privata. Questa opzione richiede di creare una CA emittente nel cloud privata per il tenant di Intune. La CA emittente è ancorata a una CA privata, ad esempio Servizi certificati Active Directory (ADCS). Quando si crea una CA emittente BYOCA Cloud PKI, viene creata anche una richiesta di firma del certificato (CSR) in Intune. Per firmare il CSR è necessario l'autorità di certificazione privata.

Prima di iniziare

È importante esaminare e comprendere le catene di certificati attendibili prima di iniziare la distribuzione. Per ulteriori concetti e nozioni fondamentali sull'infrastruttura PKI, vedere Nozioni fondamentali sull'infrastruttura PKI di Microsoft Cloud.

Identificare le relying party

Identificare le relying party. La relying party è un utente o un sistema che utilizza i certificati generati da un'infrastruttura PKI. Di seguito sono riportati alcuni esempi di relying party:

• Un punto di accesso Wi-Fi che usa l'autenticazione basata su certificati RADIUS.
• Un server VPN che autentica un utente remoto.
• Utente che visita un sito Web protetto con TLS/SSL in un Web browser.

Determinare il percorso per l'ancoraggio di attendibilità

Determinare la posizione del trust anchor radice. Un trust anchor è un certificato di firma o la chiave pubblica di un'autorità di certificazione usato da una relying party come punto di partenza per la convalida del percorso o dell'attendibilità del certificato. Una relying party potrebbe avere uno o più trust anchor derivati da più origini. Un trust anchor può essere la chiave pubblica della CA radice oppure la chiave pubblica della CA che rilascia un certificato di entità finale alla relying party.

Garantire la catena di fiducia

Quando si usano i certificati per eseguire l'autenticazione basata su certificati, assicurarsi che entrambe le relying party dispongano della catena di attendibilità dei certificati della CA (che include le chiavi pubbliche e la CA radice) di tutti i certificati coinvolti in una conversazione basata su TLS/SSL. In tale contesto, le parti facenti affidamento sulla certificazione sono:

• I dispositivi gestiti da Intune.
• Servizi di autenticazione usati da servizi Wi-Fi, VPN o Web.

Se manca il certificato di firma emittente, una relying party può richiederlo tramite la proprietà AIA (Authority Information Access) nel certificato utilizzando il motore di concatenamento certificati della piattaforma del sistema operativo nativo.

Nota

Quando ci si connette a una relying party, ad esempio un punto di accesso Wi-Fi o un server VPN, il dispositivo Intune gestito stabilisce innanzitutto una connessione TLS/SSL quando tenta di connettersi. Microsoft Cloud PKI non fornisce questi certificati TLS/SSL. È necessario ottenere questi certificati tramite un altro servizio PKI o CA. Di conseguenza, quando si crea un profilo Wi-Fi o VPN, è necessario creare anche un profilo di certificato attendibile e assegnarlo ai dispositivi gestiti affinché considerino attendibile la connessione TLS/SSL. Il profilo del certificato attendibile deve contenere le chiavi pubbliche delle CA radice e di emissione responsabili dell'emissione del certificato TLS/SSL.

Opzioni di distribuzione

Questa sezione descrive le opzioni di distribuzione supportate da Microsoft Intune per Microsoft Cloud PKI.

Esistono metodi per distribuire certificati CA a relying party non gestiti da Intune. Parti relying party, ad esempio server radius, punti di accesso Wi-Fi, server VPN e server di app Web che supportano l'autenticazione basata su certificati.

Se la relying party è membro di un dominio di Active Directory, utilizzare i Criteri di gruppo per distribuire i certificati CA. Per altre informazioni, vedere:

• Distribuire i certificati ai computer client usando i criteri di gruppo
• Registrare un dispositivo Windows automaticamente con i criteri di gruppo

Se la relying party non è membro del dominio di Active Directory, verificare che la catena di attendibilità del certificato di firma per la radice PKI di Microsoft Cloud e la CA emittente sia installata nell'archivio sicurezza della relying party. L'archivio di sicurezza appropriato varia a seconda della piattaforma del sistema operativo e dell'applicazione host che fornisce il servizio.

Considerare anche la configurazione del software relying party necessaria per supportare altre autorità di certificazione.

Opzione 1: CA radice PKI di Microsoft Cloud

Durante una distribuzione della CA radice Cloud PKI, il certificato radice Cloud PKI deve essere distribuito a tutte le relying party. Se un certificato di firma emittente non è presente in una relying party, quest'ultima può recuperarlo e installarlo automaticamente avviando l'individuazione dei certificati. Questo processo, noto come motore di concatenamento dei certificati (CCE), è specifico della piattaforma e usato per recuperare il certificato padre mancante. L'URL del certificato CA emittente si trova nella proprietà AIA di un certificato foglia (il certificato rilasciato al dispositivo tramite una CA emittente Cloud PKI). Una relying party può utilizzare la proprietà AIA per recuperare i certificati CA padre. Il processo è simile al download dei CRL.

Nota

Il sistema operativo Android richiede ai server di restituire un'intera catena di certificati e non esegue l'individuazione dei certificati seguendo i percorsi AIA. Per altre informazioni sui requisiti della catena di certificati in Android, vedere la documentazione sulla sicurezza di SSL per Android. Assicurarsi di distribuire l'intera catena di certificati ai dispositivi gestiti Android e alle relying party.

I dispositivi gestiti da Intune, indipendentemente dalla piattaforma del sistema operativo, richiedono la catena di certificati attendibili CA seguente.

Tipo di certificato CA	Catena di attendibilità dei certificati CA	Metodo di distribuzione
Certificato CA PKI cloud	Necessario il certificato CA radice, l'autorità di certificazione emittente è facoltativa ma consigliata	Profilo di configurazione del certificato attendibile di Intune
Certificato CA privato	È necessario il certificato CA radice, l'emissione del certificato CA è facoltativa ma consigliata	Profilo di configurazione del certificato attendibile di Intune

Le relying party richiedono la catena di attendibilità dei certificati di firma seguente.

Tipo di certificato CA	Catena di attendibilità dei certificati CA	Metodo di distribuzione
Certificato CA PKI cloud	Necessario il certificato CA radice, l'autorità di certificazione emittente è facoltativa ma consigliata	Se il server o il servizio della relying party è un server membro nel dominio di Active Directory (AD), utilizzare i Criteri di gruppo per distribuire i certificati CA. Se non si trova nel dominio AD, potrebbe essere necessario un metodo di installazione manuale.
Certificato CA privato	Necessario il certificato CA radice, certificato CA emittente facoltativo ma consigliato	Se il server o il servizio della relying party è un server membro nel dominio di Active Directory (AD), utilizzare i Criteri di gruppo per distribuire i certificati CA. Se non si trova nel dominio AD, potrebbe essere necessario un metodo di installazione manuale.

Il diagramma seguente mostra i certificati in azione sia per il client che per le relying party.

Il diagramma seguente mostra le rispettive catene di certificati di firma attendibili che devono essere distribuite sia ai dispositivi gestiti che alle relying party. Le catene di trust CA garantiscono che i certificati PKI cloud emessi per i dispositivi gestiti da Intune siano attendibili e possano essere usati per l'autenticazione alle relying party.

Opzione 2: Bring Your Own CA (BYOCA)

Durante una distribuzione BRING-Your-Own-CA, il dispositivo gestito da Intune necessita dei certificati CA seguenti:

• La catena di trust della CA privata, inclusi i certificati radice e di emissione della CA, della CA responsabile della firma della CSR BYOC.
• Certificato di firma che rilascia BYOCA.

Tutte le relying party devono avere già la catena di certificati della CA privata.

I dispositivi gestiti da Intune, indipendentemente dalla piattaforma del sistema operativo, richiedono la catena di certificati attendibili CA seguente.

Tipo di certificato CA	Catena di attendibilità dei certificati CA	Metodo di distribuzione
Certificato CA PKI cloud	CA di emissione facoltativa ma consigliata	Profilo di configurazione del certificato attendibile di Intune
Certificato CA privato	Necessario il certificato CA radice, l'autorità di certificazione emittente è facoltativa ma consigliata	Profilo di configurazione del certificato attendibile di Intune

La relying party deve già avere la catena di certificati di firma privata. Tuttavia, il certificato CA emittente BYOCA deve essere distribuito anche alle relying party. Se la relying party è un server membro nel dominio di Active Directory, utilizzare l'oggetto Criteri di gruppo come metodo di distribuzione.

Nota

Se il certificato CA emittente Cloud PKI BYOCA non viene distribuito nella piattaforma relying party, la proprietà AIA (URL) del certificato SCEP emesso da Cloud PKI (certificato end-entity/leaf) può essere usata dal CCE della relying party per richiedere e installare il certificato CA emittente Cloud PKI BYOCA (chiave pubblica) nel suo archivio attendibilità. Tuttavia, questo comportamento non è garantito e dipende da ogni implementazione del sistema operativo/piattaforma di CCE. È consigliabile distribuire il certificato CA emittente BYOCA al dispositivo gestito e alla relying party.

Le relying party considerano attendibile il certificato SCEP emesso da BYOCA Cloud PKI per il dispositivo gestito, in quanto è concatenato alla catena di trust CA privata già presente nella relying party.

Il diagramma seguente illustra il modo in cui le rispettive catene di certificati di firma vengono distribuite ai dispositivi gestiti da Intune.

* In questo diagramma, privato si riferisce al Servizio certificati Active Directory o a un servizio non Microsoft.

Riepilogo

La radice PKI cloud e le CA emittenti e le CA emittenti BYOCA ancorate a una CA privata possono esistere nello stesso tenant perché Cloud PKI può supportare entrambi i modelli di distribuzione contemporaneamente.

Prima di avviare una distribuzione e rilasciare certificati, determinare la posizione del trust anchor radice. Può trovarsi nella CA radice PKI cloud o nella CA radice privata. La posizione determina la catena di certificati attendibili necessaria sia per i dispositivi gestiti da Intune che per le relying party.

• CA radice PKI cloud: è necessario distribuire la catena di attendibilità del certificato PKI cloud, costituita dalla & radice che emette chiavi pubbliche CA, a tutte le relying party.
• CA emittente BYOCA PKI cloud utilizzando una CA radice privata: la catena attendibile di certificati di CA privata, costituita dalla CA radice e dalla CA emittente, deve già essere distribuita nelle relying party in tutta l'infrastruttura. Sebbene non sia obbligatorio, è consigliabile creare un certificato CA di emissione BYOCA Cloud PKI.