Microsoft Cloud PKI – Implementare una Certification Authority in Cloud
Dal prossimo 1° marzo 2024 sarà disponibile la Microsoft Cloud PKI (Public Key Infrastructure). Microsoft Cloud PKI è una soluzione gestita da Microsoft che fornisce servizi di infrastruttura a chiave pubblica (PKI) tramite il cloud. La PKI è un insieme di ruoli, policy e procedure necessarie per creare, gestire, distribuire, utilizzare, conservare e revocare certificati digitali e gestire la crittografia a chiave pubblica. L’obiettivo principale della PKI è facilitare la sicurezza delle informazioni e delle comunicazioni digitali.
Il servizio Cloud PKI di Microsoft si propone di semplificare la gestione della PKI, riducendo la complessità e i costi associati alla gestione di una propria infrastruttura PKI in loco. Offre una piattaforma affidabile e sicura per l’emissione, la gestione e la revoca dei certificati digitali, che sono essenziali per vari scopi di sicurezza, come la crittografia SSL/TLS, la firma digitale, l’autenticazione forte e la protezione dei dati.
Microsoft Cloud PKI è particolarmente utile per le aziende che cercano di implementare o espandere le loro capacità di sicurezza digitale senza dover investire in hardware, software o personale aggiuntivo per gestire una PKI internamente. Se avete letto le nostre guide Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier, Deploy PKI in Windows Server 2016 – Parte 2 – Installazione e configurazione di una Root CA Offline e Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA sapete bene quanto può essere complesso.
Attualmente Microsoft Cloud PKI è in grado di rilasciare certificati digitali per dispositivi Windows, macOS, iOS/iPadOS e Android.
L’annuncio era stato dato già diversi mesi fa con l’articolo Microsoft Cloud PKI launches as a new addition to the Microsoft Intune Suite | Microsoft Intune Blog e finalmente la funzionalità è pronta per poter essere utilizzata.
Figura 1: Architettura di Microsoft Cloud PKI
Licenze
Per poter utilizzare la Microsoft Cloud PKI gli utenti devono possedere:
- Licenza Microsoft Intune Suite
- Licenza Intune add-ons Microsoft Cloud PKI standalone
Microsoft Intune Suite è una soluzione avanzata di gestione e sicurezza dei dispositivi mobili (MDM) e delle applicazioni mobili (MAM) di cui ho già parlato nell’articolo La Microsoft Intune Suite è disponibile (Generally Available)
Creazione di una nuova ROOT CA
Il rilascio dei certificati tramite Microsoft Cloud PKI avviene solo tramite una Issuing CA. Ma prima di poter creare una Issuing CA dobbiamo necessariamente possedere una Root CA. Possiamo utilizzare una Root CA creata nel nostro ambiente di Active Directory oppure possiamo creare una nuova Root CA direttamente nel portale di Microsoft Intune.
Collegatevi al portale di Microsoft Intune con le credenziali di un utente che sia almeno Intune Administrator e da Tenant Administration > Cloud PKI > +Create lanciate il wizard di creazione di una nuova Certification Authority.
Figura 2: Lancio del wizard di creazione di una nuova Cloud PKI
Nella scheda Basics del wizard compilate i campi relativi al nome della Certification Authority e inserite un’eventuale descrizione. Il nome scelto qui è solo descrittivo e serve a riconoscere la CA nel portale di Microsoft Intune.
Figura 3: Scheda Basics del wizard di creazione di una nuova CA in Microsoft Cloud PKI
Nella scheda Configuration settings del wizard di creazione di una nuova CA in Microsoft Cloud PKI potrete scegliere il tipo di CA, selezionando tra Root CA o Issuing CA. Io ho scelto Root CA con una durata di 10 anni.
Nella parte relativa a Extended Key Usages selezionate il tipo di certificati che saranno autorizzati all’emissione e che saranno poi rilasciati dall’Issuing CA.
NOTA: Attenzione alla compilazione perché, una volta impostati, questi parametri non saranno più modificabili.
Figura 4: Scheda Configuration settings del wizard di creazione di una nuova Root CA in Microsoft Cloud PKI
Compilate i Subject Attributes come richiesto. Inserite i dettagli sull’entità che sta creando la Root CA, inclusi il nome dell’organizzazione, il paese, la località e altre informazioni rilevanti che verranno incluse nel certificato. Completate quindi con la scelta dell’algoritmo di firma RSA (dai nomi dei suoi inventori Rivest, Shamir e Adleman) e la lunghezza della chiave (ad esempio, 2048, 3072, 4096 bit per RSA) e scegliendo la relativa famiglia di funzioni crittografiche SHA (Secure Hash Algorithm).
NOTA: Maggiore è la lunghezza della chiave, più sicuro sarà il certificato, ma ciò potrebbe aumentare il carico computazionale e potrebbe non essere supportato da tutte le versioni dei diversi sistemi operativi.
Figura 5: Scheda Configuration settings del wizard di creazione di una nuova Root CA in Microsoft Cloud PKI
Nella figura sotto sono mostrate tutte le scelte che ho fatto io per la creazione della ROOT CA.
Figura 6: Scheda Configuration settings del wizard di creazione di una nuova Root CA in Microsoft Cloud PKI
Proseguite con il wizard e selezionate i Scope tags. I role scope tag in Microsoft Intune sono utilizzati per segmentare e definire l’ambito di gestione all’interno dell’organizzazione, consentendo agli amministratori di assegnare permessi specifici a gruppi di utenti su particolari insiemi di dispositivi o risorse.
Figura 7: Scelta dei Scope Tags
Controllate le informazioni inserite e fate clic su Create per creare la nuova ROOT CA.
Figura 8: Schermata finale del wizard di creazione di una nuova Root CA in Microsoft Cloud PKI
La creazione della CA è immediata. Fantastico!
Figura 9: Creazione della Root CA avvenuta con successo
Creazione di una Issuing CA
Il processo di creazione di una Issuing CA è molto simile a quello che abbiamo già visto per la creazione della Root CA. Una Issuing Certification Authority (CA) è un’entità responsabile dell’emissione di certificati digitali. Il ruolo principale di una Issuing Certification Authority è quello di autenticare l’identità dei soggetti a cui emette i certificati, assicurando che le informazioni contenute nel certificato siano corrette e affidabili.
Le Issuing Certification Authorities sono parte di una catena di fiducia. Alla radice di questa catena vi sono le Root Certification Authorities, che sono entità altamente protette e fidate. Le Root CAs emettono certificati per le Intermediate CAs (o Subordinate CAs), che a loro volta possono emettere certificati per altre Intermediate CAs o direttamente agli enti finali, come le organizzazioni o i siti web. Questo sistema gerarchico aiuta a distribuire la fiducia e a gestire la revoca dei certificati in modo efficiente.
Oltre all’emissione di certificati, le CA sono responsabili della loro revoca (se il certificato non è più sicuro o l’entità non è più considerata affidabile) e della pubblicazione di elenchi di certificati revocati (CRLs – Certificate Revocation Lists) o dell’utilizzo del protocollo OCSP (Online Certificate Status Protocol) per fornire lo stato in tempo reale dei certificati.
Figura 10: Wizard di creazione di una Issuing CA
Dal menù a tendina scegliete come CA type la voce Issuing CA e come Root CA source scegliete Intune.
Figura 11: La Issuing CA sarà creata partendo dalla Root CA che abbiamo creato in Intune
Scegliete la Root CA presente in Intune e le Extended Key Usages disponibili tra quelle che avete scelto precedentemente per la Root CA. Noterete infatti che saranno disponibili solo le chiavi previste dalla Root CA. Completate gli altri campi richiesti e fate clic su Next per proseguire nel wizard.
Figura 12: Configurazioni della Issuing CA
Figura 13: Scelta degli Scope Tags di Intune
Controllate le informazioni inserite e fate clic su Create per lanciare la creazione della Issuing CA.
Figura 14: Schermata finale del wizard di creazione della Issuing CA
La creazione della Issuing CA è istantanea. Di nuovo fantastico!
Figura 15: Creazione della Issuing Ca completata con successo
Creazione di una Issuing CA partendo da un Root CA interna (Bring your own CA)
La creazione di una Microsoft Cloud PKI Issuing Certificate Authority (CA) che si appoggia su una Root CA interna (approccio Bring Your Own CA, BYOCA) implica l’integrazione della propria infrastruttura PKI con i servizi cloud di Microsoft. Questo processo consente alle organizzazioni di mantenere il controllo sulla root of trust attraverso la propria Root CA, mentre sfruttano la scalabilità, la flessibilità e la gestione semplificata offerte da Microsoft Cloud.
Per creare Issuing Certificate Authority che si appoggia su una Root CA interna lanciate il wizard per la creazione di una nuova Certification Authority.
Figura 16: Wizard per la creazione di una nuova Certification Authority
Nella scheda Configuration Settings scegliete come CA type Issuing CA e come Root CA source Bring your own root CA.
Scegliete gli Extended Key Usages che preferite e compilate i Subject Attributes come richiesto. Inserite i dettagli sull’entità che sta creando la Root CA, inclusi il nome dell’organizzazione, il paese, la località e altre informazioni rilevanti che verranno incluse nel certificato. Completate quindi con la scelta dell’algoritmo di firma RSA e la lunghezza della chiave, scegliendo la relativa famiglia di funzioni crittografiche SHA.
Ignorate il periodo di validità. Questa impostazione non è disponibile per la configurazione. La CA interna usata per firmare la richiesta di firma del certificato BYOCA determina il periodo di validità.
Figura 17: Configuration Settings del wizard per la creazione di una nuova Certification Authority
Figura 18: Scope tags di Microsoft Intune
Esaminate la schermata di riepilogo e fate clic su Create. Come si può vedere dalla figura sotto, sarà necessario scaricare la CSR, che sta per Certificate Signing Request (Richiesta di Firma del Certificato). Si tratta di un blocco di dati codificato da inviare a un’autorità di certificazione (CA) quando si richiede un certificato digitale SSL/TLS. La CSR contiene informazioni dettagliate che saranno incluse nel certificato, come il nome, l’organizzazione, il paese, la chiave pubblica e altre informazioni aggiuntive.
Figura 19: Schermata finale del wizard per la creazione di una nuova Certification Authority
Figura 20: Nuova Certification Authority creata ma non ancora operativa
Aprite le proprietà della nuova Certification Authority creata e scaricate la CSR, che poi dovrete sottomettere alla vostra CA locale.
Figura 21: Download della Certificate Signing Request
Esistono due modi per firmare il file della richiesta di firma del certificato scaricato:
- Usare la registrazione Web della CA, una funzionalità di Servizi certificati Active Directory (ADCS). Questa opzione offre una semplice interfaccia Web che consente di eseguire attività specifiche dell’amministratore, ad esempio richiedere e rinnovare i certificati.
- Usare certreq.exe, l’eseguibile della riga di comando di Windows ADCS.
Io ho deciso di utilizzare lo strumento da riga di comando di Windows ADCS seguendo le indicazioni presenti alla pagina Bring your own certificate authority with Cloud PKI – Microsoft Intune | Microsoft Learn e utilizzando il comando certreq -submit -attrib “CertificateTemplate:SubCA” -config “DC1\VIRTUAL CA” “VIRTUAL CA Issuing.req” “VIRTUAL CA Issuing.cer”
Come si può vedere dalla figura sotto, il certifcato viene rilasciato senza problemi, anche se appare il messaggio che avvisa che il periodo di validità presente nella richiesta è stato sovrascritto dal periodo di validità del template disponibile sulla Root CA (come ci aspetatvamo)-
Figura 22: Firma della richiesta di firma del certificato ed emissione del certificato
Per completare il processo e consentire alla Issuing CA nel cloud di avviare l’emissione di certificati per i dispositivi gestiti da Microsoft Intune, è necessario disporre di:
- Certificato firmato per la CA emittente BYOCA.
- Catena completa della CA privata usata per firmare la richiesta di certificato.
Ho quindi caricato nel portale di Intune sia il certificato emesso in seguito alla CSR sia il certificato della Root CA, come mostrato nella figura sotto:
Figura 23: Upload del certificato nel portale di Intune
A questo punto la nuova Issuing CA è pronta per distribuire i certificati ai nostri dispositivi.
Figura 24: La nuova Issuing CA è operativa
Distribuzione dei certificati delle CA
Una volta che le CA sono state create siete pronti per la distribuzione dei certificati delle CA (sia quelli Root che quelli Issuing). Come prima operazione sarà necessario scaricare i certificati e successivamente sarà necessario creare dei profili di configurazione per distribuirli ai nostri dispositivi. Ho quindi provveduto a scaricare, per poi distribuire, i due certificati delle CA create in Microsoft Cloud PKI.
Figura 25: Download del certificato della Root CA
Figura 26: Download del certificato della Issuing CA
Create adesso le policy di configurazione per la distribuzione dei certificati. Nel portale amministrativo di Intune navigate in Devices > Configuration > Create > New policy. Selezionate Windows 10 and later > Templates e scegliete Trusted certificate. Fate clic su Create per lanciare il wizard.
Figura 27: Creazione del profilo per la distribuzione del certificato di Root CA
Figura 28: Nome del profilo per la distribuzione del certificato di Root CA
Caricate il certificato della Root CA e scegliete come destination store
Computer certificate store – Root.
Figura 29: Configurazione del profilo per la distribuzione del certificato di Root CA
Assegnate quindi il profilo di configurazione ad un gruppo di dispositivi. Io consiglio di cominciare con un piccolo gruppo di test.
Figura 30: Assegnazione del profilo per la distribuzione del certificato di Root CA
Potete rifinire la distribuzione del profilo di configurazione utilizzando anche della Applicability Rules. Le regole di applicabilità in Microsoft Intune sono un set di criteri che determinano se una configurazione, una policy o un’applicazione debbano essere applicate o meno a un dispositivo o a un utente. Queste regole sono fondamentali per garantire che le risorse giuste siano distribuite ai dispositivi corretti, evitando incompatibilità o problemi di performance che potrebbero sorgere dall’applicare configurazioni non appropriate a certi dispositivi o utenti.
Figura 31: Selezione delle Applicability Rules nel profilo per la distribuzione del certificato di Root CA
Controllate le informazioni inserite e completate il wizard facendo clic su Create.
Figura 32: Schermata finale del wizard per la creazione del profilo di distribuzione del certificato di Root CA
Figura 33: Profilo per la distribuzione del certificato di Root CA creato con successo
Create un nuovo profilo di configurazione per la distribuzione del certificato di Issuing CA, effettuando gli stessi passaggi già visti. La differenza tra i due wizard consiste solo nella scelta del certificato corretto e del destination store
Computer certificate store – Intermediate.
Figura 34: Scelta del certificato della Issuing CA e del destination store corretto
Figura 35: Profili di configurazione perla distribuzione dei certificati delle CA
Dopo qualche minuto nei dispositivi Windows configurati tramite i due profili di configurazione verranno distribuiti entrambi i certificati.
Figura 36: Certificato della Root CA distribuito sui dispositivi
Figura 37: Certificato della Issuing CA distribuito sui dispositivi
Distribuzione dei certificati emessi dalla Microsoft Cloud PKI
Microsoft Intune supporta l’utilizzo del Simple Certificate Enrollment Protocol (SCEP) per facilitare la distribuzione sicura dei certificati ai dispositivi mobili. SCEP è un protocollo che semplifica il processo di iscrizione e rinnovo dei certificati digitali, che sono fondamentali per l’autenticazione sicura e la crittografia delle comunicazioni.
Utilizzando SCEP in Microsoft Intune, le aziende possono automatizzare l’emissione di certificati ai dispositivi degli utenti senza interventi manuali.
Per la distribuzione dei certificati sarà sufficiente creare un nuovo profilo di configurazione. Dal portale amministrativo di Microsoft Intune scegliete Devices > Configuration > Create > New policy. Selezionate Windows 10 and later > Templates e quindi scegliete SCEP certificate. Fate clic su Create per lanciare il wizard di creazione del profilo.
Figura 38: Creazione di un profilo di configurazione per il Simple Certificate Enrollment Protocol (SCEP)
Figura 39: Nome del profilo di configurazione per il Simple Certificate Enrollment Protocol (SCEP)
Nella scheda dei Configuration Settings io ho configurato le opzioni con i seguenti parametri:
- Certificate Type: User
- Subject name format: Default
- Subject alternative name: Default
- Certificate validity period: 1 anno (default)
- Key storage provider: Enroll to Software KSP (opzione obbligatoria se avete scelto che la chiave sia a 4096 bit)
- Key usage: Digital signature & Key encipherment
- Key size (bits): 4096
- Hash algorithm: SHA-2
- Root CA: Issuing CA creata
- Extended Key Usage: Uno dei valori disponibili nel menù a tendina
- SCEP Server URLs: Valore della Issuing CA ricavato da Tenant administration > Cloud PKI > Issuing CA creata > Proprietà > SCEP URI
Figura 40: Configuration Settings del profilo di configurazione per il Simple Certificate Enrollment Protocol (SCEP)
Ho assegnato il profilo allo stesso gruppo di dispositivi dove ho precedentemente distribuito i due certificati della Root CA e della Intermediate CA.
Figura 41: Assegnazione del profilo di configurazione per il Simple Certificate Enrollment Protocol (SCEP)
Figura 42: Scelta della eventuali Applicability Rules
Figura 43: Schermata finale del wizard di creazione del profilo di configurazione per il Simple Certificate Enrollment Protocol (SCEP)
Figura 44: Profilo di configurazione per il Simple Certificate Enrollment Protocol (SCEP) creato con successo
Attendete quindi che il profilo venga distribuito ai vostri dispositivi (oppure forzatene il Sync dal portale di Microsoft Intune) e il certificato verrà creato dalla Microsoft Cloud PKI e installato nei vostri dispositivi Windows, come mostrato nella figura sotto:
Figura 45: Certificato distribuito all’utente in una macchina Windows
Se il certificato deve essere emesso dalla Microsoft Cloud PKI – Bring your own CA basterà eseguire gli stessi passaggi e creare tutti i profili per la distribuzione dei certificati:
- Creare un profilo di configurazione per distribuire il certificato della Root CA
- Creare un profilo di configurazione per distribuire il certificato della Issuing CA
- Creare un profilo di configurazione per l’utilizzo del Simple Certificate Enrollment Protocol (SCEP) per la richiesta del certificato.
Nella figura sotto vengono mostrati i 3 profili che ho creato per distribuire i certificati tramite Microsoft Cloud PKI – Bring your own CA
Figura 46: Profili creati per la distribuzione dei certificati della Microsoft Cloud PKI – Bring your own CA
Ovviamente anche in questo caso dovete attendere che i profili di configurazione vengano distribuiti alle vostre macchine Windows per poter verificare che sia il certificato di Root CA (privata), Issuing CA (Microsoft Cloud PKI – Bring your own CA) e il certificato per l’utente vengano distribuiti.
Nella figura sotto è mostrato il risultato finale, con il certificato utente emesso correttamente e con la catena di certificazione che è validata.
Figura 47: Certificato emesso dalla Microsoft Cloud PKI – Bring your own CA
Distribuzione dei certificati sui dispositivi mobili
Microsoft Cloud PKI permette di distribuire i certificati anche su dispositivi Android e iOS. I passaggi sono esattamente gli stessi che abbiamo già visto per i dispositivi Windows:
- Creare un profilo di configurazione per distribuire il certificato della Root CA
- Creare un profilo di configurazione per distribuire il certificato della Issuing CA
- Creare un profilo di configurazione per l’utilizzo del Simple Certificate Enrollment Protocol (SCEP) per la richiesta del certificato.
Nelle figure sotto sono mostrate tutte le schermate di configurazione. Io ho deciso di distribuire il certificato ad un dispositivo Android personale con il profilo di lavoro.
Figura 48: Creazione di un profilo per la distribuzione del certificato di Root CA
Figura 49: Nome del profilo per la distribuzione del certificato di Root CA
Figura 50: Scelta del certificato di Root CA
Figura 51: Assegnazione del profilo per la distribuzione del certificato di Root CA ad un gruppo di dispositivi
Figura 52: Schermata finale del wizard per la creazione del profilo per la distribuzione del certificato di Root CA
Create un altro profilo per la distribuzione del certificato della Issuing CA con la stessa procedura.
Al termine ci saranno i due profili per la distribuzione dei certificati per i dispositivi Android, come mostrato nella figura sotto:
Figura 53: Profili per la distribuzione dei certificati delle CA per i dispositivi Android
Procedete quindi alla creazione di un profilo per la distribuzione del certificato con il Simple Certificate Enrollment Protocol (SCEP).
Figura 54: Creazione del profilo per la distribuzione del certificato con il Simple Certificate Enrollment Protocol (SCEP)
Figura 55: Nome del profilo per la distribuzione del certificato con il Simple Certificate Enrollment Protocol (SCEP)
Per i configuration Settings ho utilizzato le seguenti impostazioni:
- Certificate Type: User
- Subject name format: Default
- Subject alternative name: Default
- Certificate validity period: 1 anno (default)
- Key storage provider: Enroll to Software KSP (opzione obbligatoria se avete scelto che la chiave sia a 4096 bit)
- Key usage: Digital signature & Key encipherment
- Key size (bits): 4096
- Hash algorithm: SHA-2
- Root CA: Issuing CA (distribuita per Android)
- Extended Key Usage: Uno dei valori disponibili nel menù a tendina
- SCEP Server URLs: Valore della Issuing CA ricavato da Tenant administration > Cloud PKI > Issuing CA creata > Proprietà > SCEP URI
Figura 56: Configuration Settings del profilo per la distribuzione del certificato con il Simple Certificate Enrollment Protocol (SCEP)
Figura 57: Assegnazione del profilo per la distribuzione del certificato con il Simple Certificate Enrollment Protocol (SCEP)
Figura 58: Schermata finale del wizard di creazione del profilo per la distribuzione del certificato con il Simple Certificate Enrollment Protocol (SCEP)
Figura 59: Profilo per la distribuzione del certificato con il Simple Certificate Enrollment Protocol (SCEP) creato con successo
Esperienza utente su Android
Poiché il dispositivo Android che ho utilizzato è un dispositivo personale con profilo di lavoro, all’utente appariranno le richieste di accettazione dei certificati, che ovviamente non appariranno nei dispositivi Android Enterprise fully managed.
Dal portale di Microsoft Intune sarà possibile verificare le configurazioni che sono state applicate al dispositivo Android.
Figura 60: Configurazioni applicate al dispositivo Android
Gestione e revoca dei certificati digitali
Il processo di revoca di un certificato digitale (Certificate Revocation) è una procedura critica nella gestione dei certificati digitali, che sono utilizzati per garantire la sicurezza nelle comunicazioni su Internet. Questo processo è necessario per invalidare un certificato prima della sua scadenza naturale in situazioni dove non è più sicuro o appropriato affidarsi a quel certificato. Ci sono varie ragioni per cui un certificato digitale potrebbe essere revocato:
- Compromissione della chiave privata: Se si sospetta o si ha la certezza che la chiave privata associata al certificato sia stata compromessa, cioè resa accessibile a persone non autorizzate, il certificato deve essere revocato per prevenire abusi.
- Errore nelle informazioni del certificato: Se le informazioni contenute nel certificato, come l’identità del proprietario o le autorizzazioni di sicurezza, sono errate o obsolete, il certificato deve essere revocato e rilasciato nuovamente con le informazioni corrette.
- Cambio di affiliazione: Se l’individuo o l’entità a cui è stato emesso il certificato cambia la propria affiliazione (ad esempio, un dipendente lascia l’azienda), il certificato non è più valido e deve essere revocato.
- Terminazione di un servizio: Se un servizio per il quale è stato emesso il certificato viene terminato, il certificato associato non è più necessario e può essere revocato.
- Violazione delle politiche di sicurezza: Se il titolare del certificato viola le politiche di sicurezza stabilite dall’autorità di certificazione (CA), il certificato può essere revocato come misura punitiva o precauzionale.
Per gestire la revoca dei certificati, le autorità di certificazione mantengono liste di revoca dei certificati (CRL, Certificate Revocation Lists) o utilizzano il protocollo OCSP (Online Certificate Status Protocol) per fornire informazioni in tempo reale sullo stato di validità di un certificato. Quando un utente o un sistema tenta di stabilire una connessione sicura, può verificare se il certificato presentato è stato revocato consultando queste risorse. Questo è essenziale per mantenere la fiducia e la sicurezza nella comunicazione digitale.
Con la Microsoft Cloud PKI, il processo di revoca di un certificato è gestito attraverso la distribuzione dei punti di distribuzione della lista di revoca dei certificati (CRL, Certificate Revocation List). Intune ospita il CRL distribution point (CDP) per ogni autorità di certificazione (CA), garantendo così che i certificati revocati possano essere identificati rapidamente dai clienti e dai sistemi che si affidano ai certificati per le comunicazioni sicure. La validità della CRL è di sette giorni, con pubblicazione e aggiornamento che avvengono ogni 3,5 giorni.
Questo sistema assicura che le informazioni sulla revoca dei certificati siano costantemente aggiornate e facilmente accessibili, mantenendo così un alto livello di sicurezza per le comunicazioni e i dati gestiti tramite Intune.
Selezionate la Issuing CA e visualizzate le Proprietà per conoscere il CRL distribution point. Navigando al link del CDP potrete scaricare la CRL corrente, come mostrato nella figura sotto:
Figura 61: CRL distribution point della Issuing CA
Dalla scheda Monitor potrete visualizzare le informazioni sui certificati emessi, scaduti e revocati. Fate clic su View all certificates per visualizzare i dettagli.
Figura 62: Scheda Monitor della Issuing CA
Cliccando sul certificato potrete visualizzarne tutte le informazioni e, se necessario, revocarlo.
Figura 63: Revoca del certificato
Nel giro di qualche minuto il certificato risulterà revocato. Se scaricate la CRL lo troverete nelle lista dei certificati revocati.
Figura 64: Il certificato è stato revocato correttamente
Conclusioni
Concludendo, l’adozione di Microsoft Cloud PKI segna un passo significativo verso la semplificazione della gestione dei certificati e l’incremento della sicurezza digitale all’interno delle organizzazioni. Tramite l’integrazione con Microsoft Azure, le aziende possono ora sfruttare una soluzione di Public Key Infrastructure (PKI) completamente gestita, riducendo la complessità e i costi associati alla manutenzione di infrastrutture PKI on-premise tradizionali.
La facilità d’uso, la scalabilità e la flessibilità di Microsoft Cloud PKI consentono alle organizzazioni di tutte le dimensioni di implementare rapidamente certificati digitali sicuri per una vasta gamma di applicazioni, inclusa l’autenticazione dei dispositivi, la crittografia dei dati, la firma digitale e la sicurezza delle comunicazioni. Inoltre, l’integrazione nativa con altri servizi Microsoft, come Intune per la gestione dei dispositivi e Entra ID per l’identità e l’accesso, offre un ecosistema coeso che facilita una gestione centralizzata della sicurezza.
Tuttavia, mentre Microsoft Cloud PKI rappresenta un’opzione attraente per molte organizzazioni, è fondamentale considerare attentamente le proprie specifiche esigenze di sicurezza e conformità prima di procedere con l’implementazione. La transizione da una PKI on-premise a una soluzione basata su cloud richiederà una pianificazione attenta, valutazioni di sicurezza e potenzialmente anche la formazione del personale per garantire che la migrazione e l’operatività siano eseguite senza intoppi.
In futuro, con l’evoluzione continua delle minacce alla sicurezza digitale, l’importanza di una gestione affidabile e sicura delle identità e delle credenziali digitali continuerà a crescere. Microsoft Cloud PKI, con il suo approccio moderno e integrato alla PKI, è ben posizionato per svolgere un ruolo chiave nell’abilitare le organizzazioni a proteggere le loro infrastrutture digitali e a costruire una fiducia digitale duratura con i loro utenti.