• Cloud, Guide, Sicurezza, Sistemi Operativi
• 12 Gennaio 2024

Abbiamo già visto nell’articolo Protezione dell’ambiente PowerShell mediante Script Firmati (con certificati Self-Signed), relativo alla firma di Script in PowerShell, le considerazioni generali inerenti gli aspetti di sicurezza, che portano alla scelta di utilizzare la firma digitale di questa tipologia di Script.

In questo nuovo articolo ci occuperemo di come è possibile utilizzare una Certification Authority, installata nell’infrastruttura aziendale, allo scopo di ottenere un certificato da utilizzare nel processo di firma.

Non tratteremo qui, gli aspetti legati alla installazione in Dominio di una Certification Authority, e per questo scopo rimandiamo agli articoli scritti e pubblicati dalla nostra Community

• 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
• Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA

Una volta terminata l’installazione della struttura PKI è necessario configurare la CA in modo che, tramite un Template, possa emettere (firmare) certificati di tipo Code Signing.

Dal punto di vista puramente operativo, il fatto che il certificato sia autofirmato oppure emesso da una CA non fa differenza, è necessario che preveda in sé l’OID relativo a questo utilizzo.

Precisazione riguardo agli OID relativi ai certificati

X509 è lo standard che definisce il formato dei certificati digitali, inclusi quelli utilizzati per il code signing, X509 tra le sue particolarità definisce l’EKU”Extended Key Usage” che è un’estensione dei certificati digitali X.509.

Questa estensione specifica uno o più scopi per i quali la chiave pubblica associata al certificato può essere utilizzata.

Gli scopi sono identificati da un insieme di Object Identifiers. (OID) X509 identifica diversi OID ( Object Identifier ) a seconda dell’uso per cui è previsto un certificato,

Nel caso del Code Signing, l’OID associato è 1.3.6.1.5.5.7.3.3 che è rilevabile nelle informazioni disponibili all’interno del certificato stesso.

Creazione del Template utilizzato per la generazione del Certificato di Firma

Questa procedura è necessaria per “istruire” la Certification Authority in modo che possa emettere i certificati necessari, il processo si snoda attraverso questi due momenti

• Duplicazione di un Template esistente di tipo Code Signing (con le caratteristiche necessarie al nostro scopo)
• Autorizzazione della CA all’emissione del Template Duplicato

 

Duplicazione di un Template esistente di tipo Code Signing

Dallo Snap-In di gestione della CA è necessario individuare il ramo “Certificate Templates” ed entrare nella gestione, selezionando Manage

Figura 1: Apertura dei Template dalla Management della CA

successivamente dopo aver fatto accesso alla gestione Template disponibili, individuare quello relativo al Code Signing, selezionarlo e tramite il tasto Dx del mouse scegliere Duplicate Template

Figura 2: Duplicazione del Template di Code Signing

confermando la scelta di duplicazione, nella maschera successiva dovremo fornire alcune informazioni necessarie alla gestione dei certificati rilasciati con questo template e dovremo agire su due Tab, General e Security.

Nel Tab General definiremo

• Il nome che sarà visualizzato per questo Template
• Il nome vero e proprio del Template stesso (che sarà quello che dovremo utilizzare per richiedere il Certificato)
• il periodo di validità dei certificati rilasciati tramite questo Template, anche in questo caso è necessario considerare la scelta di un periodo di validità sufficientemente ampio in modo da non costringere ad una frequente ri-emissione dei certificati, e quindi ad una nuova firma degli Script. Ovviamente la validità temporale dovrà essere valutata bilanciando e valutando le esigenze di sicurezza dell’infrastruttura con le attività di gestione della stessa.

Figura 3: Definizione dei valori relativi al nuovo Template duplicato

Nel Tab Security dovremo definire chi potrà richiedere, mediante il permesso di Enroll, i certificati generati tramite questo Template (il default prevede che i gruppi Domain Admins ed Enterprise Admins abbiano questo permesso assegnato)

Figura 4: Assegnazione del permesso di Enroll ad utenti o gruppi specifici

Terminata la fase di duplicazione del Template dovremo configurare la CA in modo che possa utilizzarlo per emettere i certificati, è necessario ritornare alla gestione della CA ( Figura 1 ) dal ramo “Certificate Templates selezionare New Certificate Template to Issue

Figura 5: Autorizzazione al rilascio di certificati secondo il Template duplicato

successivamente individuare il Template duplicato in precedenza, selezionarlo e confermare con OK.

Figura 6: Conferma della selezione del Template

Terminata questa fase di configurazione, che è focalizzata sulla gestione e configurazione lato Certification Authority, possiamo passare alla configurazione dell’ambiente AD predisponendo la Group Policy in modo che possano essere eseguiti esclusivamente script firmati digitalmente, questa parte della configurazione, che per semplicità riportiamo, è identica a quella già vista in precedenza nell’articolo relativo alla firma di Script in PowerShell con certificato Auto Segnato

Preparazione dell’ambiente di sicurezza per PowerShell

Ancor prima di procedere con la vera e propria procedura di firma è necessario impostare l’ambiente PowerShell in modo che vengano eseguiti esclusivamente Script firmati digitalmente

È quindi necessario creare una GPO che attiva questo comportamento, la Group Policy può essere definita sia nel contesto macchina che in quello utente (l’impostazione di macchina ha priorità nell’applicazione rispetto a quella per utente)

Figura 7: Creazione della GPO per la definizione della Executionpolicy di PowerShell

Le impostazioni possibili all’interno della GPO prevedono che si possa modulare l’esecuzione degli script in tre modi

• Solo esecuzione di script firmati
• Esecuzione di qualunque script locale e se da remoto solo script firmati
• Esecuzione di script libera e senza vincoli

Quando viene impostata l’esecuzione degli script in “Consenti solo Script Firmati” oppure “Allow only signed scritps” per i sistemi in lingua inglese, ogni script deve disporre di una firma digitale per poter essere eseguito, in caso contrario all’utente verrà presentato il messaggio mostrato bella figura sotto:

Figura 8: Messaggio relativo al tentativo di ‘esecuzione di uno Script non firmato

A questo punto abbiamo completato la configurazione della Certification Authority, definendo un Template ed abbiamo anche stabilito chi potrà richiedere un certificato per la firma ed abbiamo impostato l’ambiente affinché l’esecuzione degli script in PS avvenga esclusivamente se questi sono firmati digitalmente

Per completare l’intero processo dobbiamo ancora richiedere alla CA un certificato e successivamente con questo procedere alla firma dei vari Script.

Procedura per Richiesta di un Certificato alla CA

Esistono più modi per richiedere ad una Certification Authority il rilascio di certificati, il più semplice è probabilmente quello dell’utilizzo di PowerShell, tramite il CommandLet Get-Certificate che richiede un certificato ad una CA presente e pubblicata a livello di dominio

L’esempio riportato qui sopra è utilizzabile per effettuare la richiesta in modo coerente con le impostazioni viste in precedenza, ovviamente l’utente che esegue questo comando deve essere quello per cui il template è stato configurato.

Per ragioni di semplicità in questo articolo abbiamo riportato la configurazione definendo un singolo utente, in un ambiente di produzione è bene configurare nella security un gruppo a cui poi far appartenere l’utente che dovrà gestire i certificati.

La definizione di un gruppo all’interno della Security ci permette, senza più agire sulla configurazione della CA, di aggiungere o revocare i permessi di richiesta certificati agli utenti semplicemente aggiungendoli o rimuovendoli da gruppi AD.

Figura 9: Richiesta certificato secondo il Template creato per il Code Signing

A questo punto possiamo verificare che il certificato sia presente nello Store dell’utente che lo ha richiesto, utilizzando il CommandLet Get-ChildItem

Figura 10: Riepilogo del certificato presente nello store utente

Terminata anche questa ulteriore fase possiamo procedere con la firma vera e propria di uno script

Firma dello Script PowerShell

La procedura seguita finora ha permesso di creare la struttura di base per permetterci di firmare gli script che andremo produrre, in questo esempio lo script in PowerShell è collocato nella cartella C:\Temp ed ha nome MsgboxSigned.ps1, per la firma è necessario utilizzare il cmd-let SetAuthenticodeSignature

Se i passi sono stati completati in modo corretto il comando termina senza errori e con lo stato di Valido.

È importante tenere bene presente che la firma degli script in PS può avvenire esclusivamente sulla postazione che ha generato il certificato stesso, in quanto è presente anche la chiave privata.

Qualora fosse necessario utilizzare un’altra postazione per la firma, dovremo esportare il certificato in un formato che contenga anche la chiave privata, copiare il file esportato nella nuova postazione e reimportarlo.

Figura 11: Utilizzo del cmd-let di firma dello script

L’apposizione della firma sullo script esegue già di per sé la verifica, se tuttavia volessimo ri-verificare il file oppure fosse necessario verificare un altro file è possibile utilizzare il cmd-let Get-AuthenticodeSignature

che riporterà la condizione di validità o meno di una firma sullo script.

Verifica dell’esecuzione dello Script firmato e completamento della configurazione

L’esecuzione degli script a questo punto può avvenire, il sistema riconosce il certificato come valido, ma non “conosce” l’autore della firma e quindi viene proposto all’utente un messaggio ulteriore di conferma prima della sua esecuzione, chiedendo di rendere “fidato” l’utente che ha firmato il certificato mediante la richiesta di una ulteriore conferma

L’articolo di Ermanno Goletto PowerShell AllSigned execution policy e warning al primo avvio di uno script firmato – DevAdmin Blog spiega in modo preciso e dettagliato questo comportamento

Figura 12: Warning relativo a “Trusted Publisher” sconosciuto

Analogamente a quanto già visto nell’articolo precedente, anche in questo caso tramite una GPO, dobbiamo definire il certificato all’interno dello store relativo agli “Autori Attendibili” o “Trusted Publisher”

Questa ultima configurazione è realizzabile mediante due passaggi

• Esportazione del Certificato di firma
• Creazione di una Group Policy apposita di distribuzione del certificato esportato

Esportazione del Certificato di firma

Anche in questo caso possiamo utilizzare sistemi alternativi per esportare il certificato dallo store utente verso un file, tuttavia il modo più semplice ed immediato è quello di eseguire questa operazione per mezzo del commandlet Export-Certificate

Con questo comando avremo disponibile il certificato (la chiave pubblica) nel file RobertoMassaCodesignig.cer nella cartella C:\tem della postazione. È necessario che questa operazione venga effettuata sulla postazione dalla quale si era richiesto il certificato.

Figura 13: Visualizzazione del certificato esportato

Figura 14: Visualizzazione dell’OID relativo al certificato

Le due figure sopra riportano le informazioni contenute nel certificato, in particolare l’utente per il quale è stato rilasciato ed il suo utilizzo, desumibile anche dalla visualizzazione dell’OID relativo

Completato questo passaggio possiamo terminare la configurazione procedendo con l’ultima parte della configurazione.

Creazione di una Group Policy di distribuzione del certificato esportato

Dallo strumento di gestione delle GPO (Group Policy Management Console) GPMC creiamo una Policy, che può essere di Macchina o di Utente, dove nella sezione relativa alle impostazioni della PKI all’interno della gestione della sicurezza, è presente l’area relativa ai Trusted Publisher e dove importeremo il certificato esportato in precedenza.

Figura 15: Group Policy completa per la distribuzione del certificato Auto Segnato

Completato questo ultimo passaggio l’ambiente è completamente configurato per poter gestire script in PowerShell firmati, ed autorizzare utenti specifici per queste attività, anche in questo caso, la sola modifica di un carattere all’interno dello script ne impedisce l’esecuzione garantendo un livello di sicurezza maggiore.

Considerazioni

Un ambiente in cui è attivata una protezione di questo tipo è sicuramente più controllato e sicuro di un ambiente dove l’esecuzione di script è libera, ovviamente la sicurezza è anche in funzione della protezione dei certificati che vengono utilizzati.

Questa soluzione, rispetto a quella proposta nell’articolo precedente permette una maggior visibilità relativamente a chi è stato autorizzato a firmare questo tipo di file, in quanto accedendo al pannello di configurazione della CA è immediato il colpo d’occhio sui certificati rilasciati, quando ed a chi.

Riferimenti

PowerShell Execution Policies

PowerShell Deep Dive: Best Practices, Security And AI scripting assistant