2. Firma digitale degli archivi¶
Un archivio di log serve a dimostrare cosa è accaduto. Perché possa farlo, chi lo esamina deve poter verificare due cose: che il contenuto non sia stato alterato dopo la produzione, e che esistesse già a una certa data.
L'appliance risponde a entrambe le esigenze firmando digitalmente ogni archivio e apponendovi una marca temporale.
2.1 La firma con tecnologia Authenticode¶
Gli archivi vengono firmati con la tecnologia Authenticode, lo standard usato da Microsoft per firmare software e componenti eseguibili.
La scelta ha una conseguenza concreta: essendo Authenticode una tecnologia diffusa e collaudata da anni, la firma di un archivio si verifica con gli strumenti di sistema già presenti su Windows, senza software specifico e senza l'appliance che l'ha prodotto. Chi riceve l'archivio per una verifica non deve installare nulla né fidarsi di uno strumento fornito dalla stessa parte che ha generato il file.
Se il contenuto dell'archivio viene modificato anche di un solo byte, la firma non risulta più valida.
Su quali standard si basa¶
Authenticode è una specifica Microsoft, non uno standard IETF: non esiste quindi un RFC che la definisca. Poggia però interamente su standard pubblici e consolidati, ed è questo a renderla verificabile con strumenti di terze parti.
| Standard | Ruolo |
|---|---|
| RFC 5652 — Cryptographic Message Syntax | Il formato in cui la firma è racchiusa, evoluzione di PKCS #7 |
| RFC 2315 — PKCS #7 | La specifica originaria su cui Authenticode fu costruita |
| RFC 5280 — Certificati X.509 | Il formato dei certificati usati per firmare |
| RFC 3161 — Time-Stamp Protocol | Il protocollo con cui si richiede e si verifica la marca temporale |
Una descrizione generale della firma del codice e di Authenticode è disponibile sulla voce Code signing di Wikipedia.
2.2 Il certificato¶
La firma è apposta con un certificato autoemesso dall'appliance stessa, generato in fase di configurazione. È la modalità predefinita e non richiede alcun intervento.
Usare un proprio certificato¶
Se l'organizzazione dispone di un proprio certificato Authenticode — per esempio un certificato di firma del codice emesso da un'autorità commerciale — può essere utilizzato al posto di quello autoemesso. Gli archivi risultano allora firmati da un soggetto già riconosciuto, e la verifica su un computer qualsiasi non produce l'avviso sull'emittente non attendibile descritto più avanti.
La pagina Certification Authority dell'appliance permette di generare e rigenerare certificati autofirmati e di gestire certificati Let's Encrypt, ma non prevede l'importazione di un certificato di terze parti dall'interfaccia web: la sostituzione richiede un intervento sul sistema.
Come procedere
Se volete far firmare gli archivi con un vostro certificato Authenticode, contattate l'assistenza GIGASYS: l'installazione va eseguita sull'apparato insieme ai formati derivati richiesti dalla firma.
2.3 Algoritmi utilizzati¶
| Elemento | Algoritmo |
|---|---|
| Chiave del certificato di firma | RSA a 4096 bit |
| Firma del certificato | SHA-256 con RSA |
| Formato della firma sull'archivio | Authenticode, su PKCS #7 / CMS |
| Marca temporale | Richiesta a timestamp.digicert.com |
La stessa coppia — RSA 4096 e firma SHA-256 — vale anche per la CA interna che emette il certificato dell'apparato.
L'archivio è firmato, non cifrato
La compressione dell'archivio non comporta alcuna cifratura: non esiste una password né una chiave da impostare, e chiunque disponga del file può leggerne il contenuto.
Firma e marca temporale garantiscono integrità e data certa, non riservatezza. Se l'archivio contiene dati che non devono essere letti da terzi, la protezione va gestita altrove: nel modo in cui il file viene conservato e trasmesso.
L'integrità è garantita dalla firma apposta sull'archivio nel suo complesso: i singoli file JSON e XML al suo interno non portano un proprio codice di controllo separato.
2.4 La marca temporale esterna¶
La sola firma locale dimostra l'integrità, ma non la data: un certificato emesso dalla stessa appliance che produce l'archivio non può attestare in modo indipendente quando la firma è stata apposta.
Per questo, oltre al certificato locale, l'appliance applica una marca
temporale rilasciata da DigiCert, un'autorità di certificazione esterna,
interrogando il servizio timestamp.digicert.com.
Il ruolo del soggetto terzo
La marca temporale di un ente esterno introduce nella catena qualcuno che non ha interesse nella vicenda. È l'elemento che permette di sostenere che l'archivio esisteva già in quella forma a quella data, senza doversi affidare all'orologio dell'apparato o alla parola di chi lo gestisce.
La marca temporale ha un secondo effetto, meno evidente ma importante: rende la firma verificabile anche dopo la scadenza del certificato, perché attesta che la firma esisteva già quando il certificato era valido.
Verifica la raggiungibilità del servizio
Al momento della firma l'appliance deve poter raggiungere il servizio di marcatura. La pagina Firma & Archivio → Certification Authority riporta lo stato: se il servizio è raggiungibile compare l'indicazione che la marcatura sarà applicata, altrimenti l'avviso che non può esserlo.
Controllalo dopo ogni modifica a firewall, proxy o DNS: senza marca temporale l'archivio conserva l'integrità ma perde la prova di data.
Senza certificato non c'è firma
Se il certificato di firma non è stato generato, l'archivio viene comunque prodotto ma resta non firmato, e con ciò privo di valore probatorio. In quel caso la pagina iniziale dell'appliance segnala che il certificato predefinito per la firma non è stato generato: provvedi prima del ciclo notturno successivo.
2.5 Un archivio per azienda¶
Ogni archivio contiene i log di una singola azienda. La separazione non è solo organizzativa: permette di consegnare a un cliente, a un revisore o a un'autorità l'archivio che riguarda quel soggetto, senza esporre i dati degli altri clienti presenti sulla stessa appliance.
2.6 Verificare un archivio¶
La verifica non si esegue nell'appliance: essendo l'archivio un eseguibile firmato Authenticode, si verifica su un qualsiasi computer, anche scollegato dal sistema che l'ha prodotto.
Su Windows, il modo più semplice: fai clic destro sul file, apri Proprietà e seleziona la scheda Firme digitali. Lì si leggono il firmatario e, nei dettagli, la marca temporale rilasciata da DigiCert.
Chi preferisce la riga di comando può usare signtool verify /pa /v sul file;
su Linux lo strumento equivalente è osslsigncode verify.
Il certificato pubblico con cui confrontare la firma si scarica dalla pagina Certification Authority, dove si leggono anche i dettagli e l'impronta del certificato.
Che cosa dimostra la verifica¶
- Integrità: qualunque modifica al contenuto, anche di un solo byte, rende la firma non valida.
- Provenienza: l'archivio è stato prodotto dall'appliance titolare di quel certificato.
- Data certa: la marca temporale prova che l'archivio esisteva già in quella forma a quella data.
Windows segnalerà che l'emittente non è attendibile
Con il certificato autoemesso, Windows avvisa che l'autorità che lo ha emesso non è fra quelle attendibili del computer. È un comportamento atteso e non invalida né l'integrità né la marca temporale: significa soltanto che il PC non conosce quella CA. Per togliere l'avviso si installa il certificato pubblico dell'appliance fra le autorità attendibili.
Conserva il certificato insieme agli archivi
Gli archivi già firmati restano verificabili anche se il certificato viene in seguito rigenerato, ma per verificarli serve il certificato pubblico con cui furono firmati. Scaricarlo dalla pagina Certification Authority e conservarlo insieme agli archivi è una precauzione che costa poco.
Non modificare né rinominare il contenuto
L'archivio va conservato e trasmesso così com'è. Estrarne il contenuto, ricomprimerlo o alterarlo in qualsiasi modo produce un file che non è più quello firmato, e la verifica fallisce: si conserva l'informazione ma si perde la possibilità di dimostrarne l'autenticità.