CAPICOM è una libreria di crittografia sviluppata da Microsoft, a lungo utilizzata per gestire la firma elettronica e l’autenticazione nelle applicazioni Windows. Per le amministrazioni locali, questo strumento ha permesso per anni di garantire scambi di documenti e di validare certificati digitali.
Il suo status è cambiato radicalmente: Microsoft ha ufficialmente deprecato CAPICOM e cessato il suo supporto, il che pone le amministrazioni locali di fronte a una scelta tecnica con conseguenze dirette sulla loro conformità e sicurezza informatica.
CAPICOM e amministrazioni: una dipendenza tecnica ereditata
Prima di parlare di migrazione o sostituzione, è necessario capire perché CAPICOM si sia trovato al centro di alcuni sistemi informativi pubblici. La libreria offriva un’interfaccia COM (Component Object Model) accessibile da linguaggi di scripting come VBScript o ambienti Visual Basic. Per i servizi informatici di comuni o unioni di comuni con risorse limitate, questa facilità di integrazione rappresentava un vantaggio concreto.
Gli usi più frequenti nel settore pubblico ruotavano attorno a tre funzioni: la firma elettronica di documenti amministrativi, la crittografia di dati sensibili scambiati tra servizi e la verifica di certificati durante connessioni sicure. Applicazioni aziendali sviluppate internamente o da fornitori locali hanno integrato CAPICOM senza sempre documentare questa dipendenza.
Il problema è che questa integrazione risale spesso a più di un decennio fa. I team che hanno implementato queste soluzioni hanno a volte lasciato l’amministrazione, e la documentazione tecnica è carente. Per saperne di più su Capicom su Collectivité Numérique, diverse risorse dettagliano i casi d’uso storici nel settore pubblico.
Deprecazione da parte di Microsoft: cosa significa in pratica
Microsoft ha annunciato l’interruzione di CAPICOM e raccomanda di migrare verso le API CryptoAPI o le classi .NET Framework (System.Security.Cryptography). L’ultima versione disponibile, CAPICOM 2.1.0.2, era inclusa nel Windows SDK per Windows Server 2008, Windows Vista e Windows XP. Per i sistemi a 64 bit e le versioni più recenti di Windows, Microsoft indirizza verso .NET o .NET Framework.
In concreto, la deprecazione significa diverse cose per un’amministrazione:
- Nessuna patch di sicurezza sarà pubblicata se viene scoperta una vulnerabilità in CAPICOM, il che espone i sistemi che lo utilizzano ancora a rischi non corretti.
- Gli aggiornamenti di Windows possono rompere la compatibilità in qualsiasi momento, senza preavviso né soluzione ufficiale.
- Gli audit di cybersicurezza, sempre più frequenti nel settore pubblico, segnalano sistematicamente l’uso di componenti obsoleti come un punto di non conformità.
I recenti riferimenti di cybersicurezza pubblici sconsigliano l’uso di librerie crittografiche obsolete. Utilizzare CAPICOM in produzione equivale a mantenere una porta di cui il produttore ha gettato la chiave.
Migrazione verso CryptoAPI e .NET: vincoli reali per il settore pubblico
Su carta, passare da CAPICOM a .NET o CryptoAPI sembra logico. Nella realtà delle amministrazioni, la migrazione solleva difficoltà che le guide tecniche di Microsoft non affrontano.
Il primo vincolo è di natura budgetaria. I piccoli comuni e le unioni di comuni non sempre dispongono di un servizio informatico dedicato. Far auditare tutte le applicazioni che dipendono da CAPICOM, per poi riscrivere il codice pertinente, rappresenta un costo che molte strutture non hanno previsto nella loro programmazione pluriennale.
Identificare le applicazioni interessate
Il lavoro inizia con un inventario. Si tratta di individuare ogni script, ogni applicazione aziendale e ogni processo automatizzato che chiama la libreria CAPICOM. Nelle amministrazioni di medie dimensioni, questo inventario rivela a volte usi insospettati: un modulo di firma sull’intranet, uno script di crittografia di file HR, un’interfaccia con un software di gestione finanziaria.
Senze questo inventario preliminare, ogni migrazione rimane parziale e lascia componenti vulnerabili in funzione.
Scegliere la tecnologia di sostituzione
Microsoft propone due strade principali. CryptoAPI rimane un’opzione a basso livello, adatta per sviluppi in C/C++. Per la maggior parte delle amministrazioni le cui applicazioni si basano su linguaggi di alto livello, le classi System.Security.Cryptography di .NET costituiscono la sostituzione naturale. Esse coprono la firma, la crittografia simmetrica e asimmetrica, e la gestione dei certificati X.509.
I feedback sul campo divergono sulla facilità di questa transizione. Alcune amministrazioni riportano una migrazione fluida quando le applicazioni erano ben documentate. Altre affrontano codice legacy difficilmente leggibile, dove ogni modifica rischia di introdurre regressioni.
Sicurezza e conformità: i rischi concreti dell’inaction
Mantenere CAPICOM in produzione non è solo una scelta tecnica discutibile. È un rischio legale e operativo per le amministrazioni.
Le obbligazioni di protezione dei dati personali impongono l’uso di mezzi crittografici aggiornati. Un componente senza supporto di sicurezza indebolisce l’intera catena di fiducia, anche se il resto dell’infrastruttura è recente. Un certificato firmato tramite una libreria vulnerabile non garantisce più l’integrità del documento.
Il rischio operativo è altrettanto concreto. Un aggiornamento di sistema applicato un venerdì sera può rendere inoperativa un’applicazione di firma utilizzata per convalidare appalti pubblici il lunedì mattina. Senza supporto del produttore, la ricerca di una soluzione ricade interamente sulle risorse interne o su un fornitore, con tempi incompatibili con la continuità del servizio pubblico.
Le amministrazioni che non hanno ancora avviato la loro migrazione si trovano in una situazione in cui ogni mese che passa aumenta il rischio di incidente senza ridurre il costo della transizione. L’inventario delle dipendenze CAPICOM, anche parziale, rimane la prima azione utile, quella che consente di misurare l’ampiezza del lavoro prima di budgetizzarlo.