Distribuzione PKI di Microsoft Cloud per Microsoft Intune

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

Sono disponibili due opzioni di distribuzione:

  • CA radice PKI di Microsoft Cloud: distribuire l'infrastruttura a chiave pubblica di Microsoft Cloud usando le CA radice ed emettendole nel cloud.

  • Bring your own certification authority (BYOCA): distribuire Microsoft Cloud PKI usando la propria CA privata.

Con l'approccio della CA radice PKI di Microsoft Cloud, è possibile creare una o più chiavi chiave chiave all'interno di un singolo tenant Intune. La distribuzione dell'infrastruttura a chiave pubblica cloud in questo modo crea una gerarchia a due livelli, in modo da poter avere più CA emittenti subordinate alla CA radice. Queste CA non sono pubbliche. Al contrario, si creano sia la CA radice che le AUTORITÀ di certificazione emittenti nel cloud, private per il tenant Intune. La CA emittente rilascia certificati ai dispositivi gestiti da Intune usando il profilo certificato SCEP di configurazione del dispositivo.

In alternativa, è possibile portare la propria autorità di certificazione (BYOCA). Con questo approccio, si distribuisce l'infrastruttura a chiave pubblica di Microsoft Cloud usando la propria CA privata. Questa opzione richiede la creazione di una CA emittente nel cloud privata per il tenant Intune. La CA emittente è ancorata a una CA privata, ad esempio Active Directory Certificate Services (ADCS). Quando si crea un'autorità di certificazione BYOCA per l'infrastruttura a chiave pubblica cloud, viene creata anche una richiesta di firma del certificato in Intune. L'autorità di certificazione privata deve firmare la richiesta csr.

Prima di iniziare

È importante esaminare e comprendere le catene di attendibilità dei certificati prima di iniziare la distribuzione. Per altri concetti e concetti fondamentali dell'infrastruttura a chiave pubblica, vedere Concetti fondamentali dell'infrastruttura a chiave pubblica cloud Microsoft.

Identificare le relying party

Identificare le relying party. La relying party è un utente o un sistema che utilizza i certificati generati da un'infrastruttura a chiave pubblica. Esempi di relying party includono:

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

Determinare la posizione per l'ancoraggio di attendibilità

Determinare la posizione dell'ancoraggio di trust radice. Un ancoraggio di trust è un certificato ca, o la chiave pubblica di una CA, usata 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ù ancoraggi di attendibilità derivati da più origini. Un ancoraggio di trust può essere la chiave pubblica della CA radice o la chiave pubblica della CA che emette un certificato dell'entità finale alla relying party.

Garantire la catena di attendibilità

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 ca (che include le chiavi pubbliche e la CA radice) di tutti i certificati coinvolti in una conversazione basata su TLS/SSL. In questo contesto, le relying party sono:

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

Se il certificato ca emittente non è presente, una relying party può richiederlo tramite la proprietà Authority Information Access (AIA) nel certificato usando il motore di concatenamento dei 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, viene prima stabilita una connessione TLS/SSL dal dispositivo Intune gestito durante il tentativo di connessione. 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, è anche necessario creare un profilo certificato attendibile e assegnarlo ai dispositivi gestiti per considerare attendibile la connessione TLS/SSL. Il profilo certificato attendibile deve contenere le chiavi pubbliche per le CA radice ed emittenti responsabili del rilascio del certificato TLS/SSL.

Opzioni di distribuzione

Questa sezione descrive le opzioni di distribuzione supportate da Microsoft Intune per L'infrastruttura a chiave pubblica cloud Microsoft.

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

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

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

Si consideri anche la configurazione software della relying party necessaria per supportare altre autorità di certificazione.

Opzione 1: CA radice PKI di Microsoft Cloud

Durante una distribuzione della CA radice dell'infrastruttura a chiave pubblica cloud, il certificato radice PKI cloud deve essere distribuito a tutte le relying party. Se un certificato CA emittente non è presente in una relying party, la relying party può recuperarlo e installarlo automaticamente avviando l'individuazione del certificato. Questo processo, noto come motore di concatenamento dei certificati (CCE), è specifico della piattaforma e viene 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 un'autorità di certificazione PKI cloud). Una relying party può utilizzare la proprietà AIA per recuperare i certificati CA padre. Il processo è simile al download 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 SSL Android. Assicurarsi di distribuire la catena di certificati completa in dispositivi e relying party gestiti android.

Intune dispositivi gestiti, indipendentemente dalla piattaforma del sistema operativo, richiedono la catena di attendibilità del certificato ca seguente.

Tipo di certificato CA Catena di attendibilità dei certificati ca Metodo di distribuzione
Certificato CA PKI cloud Certificato CA radice obbligatorio, rilascio della CA facoltativo ma consigliato Intune profilo di configurazione del certificato attendibile
Certificato CA privato Certificato CA radice obbligatorio, il rilascio del certificato CA è facoltativo ma consigliato Intune profilo di configurazione del certificato attendibile

Le relying party richiedono la catena di attendibilità del certificato ca seguente.

Tipo di certificato CA Catena di attendibilità dei certificati ca Metodo di distribuzione
Certificato CA PKI cloud Certificato CA radice obbligatorio, rilascio della CA facoltativo ma consigliato Se il server o il servizio della relying party è un server membro nel dominio di Active Directory (AD), usare Criteri di gruppo per distribuire i certificati CA. Se non è nel dominio di Active Directory, potrebbe essere necessario un metodo di installazione manuale.
Certificato CA privato Certificato CA radice obbligatorio, rilascio del certificato CA facoltativo ma consigliato Se il server o il servizio della relying party è un server membro nel dominio di Active Directory (AD), usare Criteri di gruppo per distribuire i certificati CA. Se non è nel dominio di Active Directory, 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.

Diagramma di flusso che mostra il rilascio di certificati dall'infrastruttura a chiave pubblica cloud ai dispositivi client e la convalida dei certificati da parte delle relying party.

Il diagramma seguente mostra le rispettive catene di attendibilità dei certificati ca che devono essere distribuite sia ai dispositivi gestiti che alle relying party. Le catene di trust ca assicurano che i certificati PKI cloud rilasciati ai dispositivi gestiti da Intune siano attendibili e possano essere usati per l'autenticazione alle relying party.

Diagramma di flusso che mostra la distribuzione della catena di attendibilità dei certificati ca dall'infrastruttura a chiave pubblica cloud a Intune ai dispositivi gestiti.

Opzione 2: Bring your own CA (BYOCA)

Durante una distribuzione bring-your-own-CA, il dispositivo gestito Intune necessita dei certificati CA seguenti:

  • Catena di attendibilità della CA privata, inclusi i certificati CA radice e emittente, della CA responsabile della firma della CSR BYOCA.
  • Certificato ca emittente BYOCA.

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

Intune dispositivi gestiti, indipendentemente dalla piattaforma del sistema operativo, richiedono la catena di attendibilità del certificato ca seguente.

Tipo di certificato CA Catena di attendibilità dei certificati ca Metodo di distribuzione
Certificato CA PKI cloud Autorità di certificazione emittente facoltativa ma consigliata Intune profilo di configurazione del certificato attendibile
Certificato CA privato Certificato CA radice obbligatorio, rilascio della CA facoltativo ma consigliato Intune profilo di configurazione del certificato attendibile

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

Nota

Se il certificato CA emittente dell'infrastruttura a chiave pubblica cloud BYOCA non viene distribuito nella piattaforma della relying party, la proprietà AIA (URL) del certificato SCEP emesso da PKI cloud (certificato end-entity/foglia) può essere usata dall'CCE della relying party per richiedere e installare il certificato della CA emittente (chiave pubblica) byoca PKI cloud nel relativo archivio di attendibilità. Tuttavia, questo comportamento non è garantito e dipende da ogni implementazione del sistema operativo/piattaforma del CCE. È consigliabile distribuire il certificato ca emittente BYOCA nel dispositivo gestito e nella relying party.

Le relying party considerano attendibile il certificato SCEP rilasciato da CLOUD PKI BYOCA al dispositivo gestito, perché viene concatenato fino alla catena di attendibilità della CA privata già presente nella relying party.

Il diagramma seguente illustra come vengono distribuite le rispettive catene di attendibilità dei certificati ca nei dispositivi gestiti Intune.

Diagramma delle catene di attendibilità dei certificati ca che devono essere distribuite in dispositivi gestiti Intune. * In questo diagramma private fa riferimento al servizio certificati Active Directory o a un servizio non Microsoft.

Riepilogo

La radice dell'infrastruttura a chiave pubblica cloud e le CA emittenti e le CA emittenti BYOCA ancorate a una CA privata possono esistere nello stesso tenant perché l'infrastruttura a chiave pubblica cloud può supportare entrambi i modelli di distribuzione contemporaneamente.

Prima di avviare una distribuzione e rilasciare certificati, determinare la posizione dell'ancoraggio di attendibilità radice. Può trovarsi nella radice PKI cloud o nella CA radice privata. Il percorso determina la catena di attendibilità del certificato richiesta sia dai dispositivi gestiti Intune che dalle relying party.

  • CA radice PKI cloud: è necessario distribuire la catena di attendibilità del certificato PKI cloud, costituita dalla radice & le chiavi pubbliche della CA emittente, a tutte le relying party.
  • CLOUD PKI BYOCA che emette ca usando una CA radice privata: la catena di certificati ca privata attendibile, costituita dalla CA radice e dalla CA emittente, deve essere già distribuita nelle relying party in tutta l'infrastruttura. Anche se non è obbligatorio, è consigliabile creare un certificato CA emittente BYOCA PKI cloud.
  • Last updated on