Verificare referenze e certificati SaaS: fonti pubbliche

Cosa si può verificare pubblicamente nelle referenze e nei certificati

Le fonti pubbliche e indipendenti dai fornitori per le prove SaaS sono il registro dei certificati dell'ente emittente, la verifica delle firme, gli avvisi di aggiudicazione, il diritto svizzero (LPD, OLCert) e l'integrazione eIAM. Ciascuna di queste fonti attesta aspetti diversi.

Un sigillo ISO 27001, i loghi dei clienti e la dicitura «certificato» sulla pagina di marketing sono autodichiarazioni. Diventano verificabili solo tramite un ente terzo indipendente dal fornitore. Può trattarsi del registro dell'ente di certificazione emittente, di una chiave pubblica per la verifica della firma o dell'avviso di aggiudicazione dell'ente committente. La verifica non avviene quindi chiedendo al fornitore, ma controllando le sue dichiarazioni presso terzi.

Quattro categorie di prove sono accessibili pubblicamente e ciascuna attesta qualcosa di diverso. Una voce nel registro dell'ente di certificazione attesta l'esistenza, il titolare, l'ambito di validità e la durata di un certificato. Non attesta che tale ambito copra la prestazione SaaS concretamente acquistata. Una firma attesta che un documento proviene inalterato dal titolare di una determinata chiave, non che il contenuto sia corretto.

Una chiave pubblica sotto un indirizzo fisso sul dominio del fornitore attesta chi è autorizzato all'emissione. Rende la verifica indipendente dalla collaborazione del fornitore. Un avviso di aggiudicazione attesta chi ha ricevuto un appalto pubblico e quando, non come si è svolto il progetto.

Per gli acquisti ciò significa: definire per ogni prova cosa viene richiesto e dove viene verificato autonomamente. Chiedere al fornitore il numero del certificato e l'ente emittente invece di una copia PDF. Chiedere la posizione di archiviazione della chiave pubblica con impronta digitale invece di un report come allegato e-mail. Per i progetti di riferimento, chiedere l'ente aggiudicatore e la data di aggiudicazione, in modo da poter cercare autonomamente l'avviso.

Da regolamentare contrattualmente è l'aggiornamento: i certificati devono essere rinnovati senza interruzioni, le nuove versioni dei report devono essere fornite firmate.

Le fonti accessibili pubblicamente in Svizzera sono la circolare eIAM (versione 1.7 del 9 ottobre 2024), l'Ordinanza sulle certificazioni in materia di protezione dei dati (OLCert) e lo standard W3C DID:web per gli identificativi degli emittenti. Queste fonti sono consultabili senza la collaborazione del fornitore.

La LPD del 25 settembre 2020 è consultabile pubblicamente su Fedlex. L'OLCert la integra. Entruni gli atti possono essere verificati senza la collaborazione di un fornitore.

Esempi concreti possono essere verificati in questo modo. QSearch fornisce i suoi report di sicurezza firmati PGP ed è registrato in Svizzera. Priverion gestisce una piattaforma ISMS ospitata in Svizzera per ISO 27001:2022. Nel modello di verifica per il Passaporto Digitale di Prodotto descritto da Transpareo, ogni produttore pubblica il proprio identificativo dell'emittente sul proprio dominio, secondo lo standard W3C DID:web.

Chi vuole verificare cerca la voce di registro, la firma e l'avviso di aggiudicazione. Se manca una di queste tracce, la dichiarazione rimane un'autodichiarazione.

Confronto delle fonti di verifica pubbliche per certificati e referenze SaaS

Controllare i certificati nel registro dell'ente di certificazione

Un certificato ISO 27001 non viene rilasciato dall'organizzazione verificata. Un ente di certificazione accreditato svolge un audit esterno e verifica se il sistema di gestione della sicurezza delle informazioni (ISMS) soddisfa i requisiti della norma. L'emittente e il titolare del certificato sono due parti diverse; l'ente emittente gestisce un proprio registro dei certificati. Il controcontrollo avviene lì, non sul sito del fornitore.

L'ente di certificazione emittente deve essere accreditato per la norma. Una voce di registro senza un'accreditamento rintracciabile non è una prova solida. Verificate l'accreditamento prima di accettare la voce come prova.

Dal certificato vanno riportate sei indicazioni: la denominazione legale dell'azienda certificata invece della denominazione del prodotto o del marchio, il numero del certificato, la norma con l'anno di edizione (ad esempio ISO/IEC 27001:2022), l'ente di certificazione emittente, la durata di validità e l'ambito di validità letterale. L'ambito di validità decide sull'utilità: esso nomina le sedi, le unità operative e le attività che sono state sottoposte ad audit.

I certificati di gruppo raramente coprono ogni società figlia e ogni servizio. Un certificato per sviluppo e operazione non significa automaticamente che il data center rilevante per voi o i subappaltatori utilizzati siano inclusi.

Oltre all'ambito di validità, va verificato il ciclo di audit. I certificati hanno una durata di validità e durante questo periodo sono accompagnati da audit di sorveglianza ricorrenti; prima della scadenza è previsto un audit di rinnovo. Chiedete la data e il tipo dell'ultimo audit e confrontateli con la durata di validità. Se un certificato scade tra pochi mesi e manca la prova del rinnovo, l'affermazione «certificato» è solida quanto la carta su cui è stampata.

Il tempo necessario fino alla certificazione è un indicatore di plausibilità. Il fornitore svizzero di ISMS Priverion indica per una certificazione secondo ISO 27001:2022 generalmente da 6 a 12 mesi, a seconda del grado di maturità dell'ISMS. Ciò permette di classificare il periodo tra audit ed emissione del certificato.

Chi vuole controverificare un certificato cerca la voce nel registro dell'ente emittente. Se manca la voce o l'accreditamento, manca la prova.

Classificare le certificazioni sulla protezione dei dati secondo il diritto svizzero

Dal 1° settembre 2023 sono in vigore la Legge federale sulla protezione dei dati rivista (LPD) nonché le nuove disposizioni di esecuzione nell'Ordinanza sulla protezione dei dati (OPD) e nell'Ordinanza sulle certificazioni in materia di protezione dei dati (OLCert). Non sono previsti termini transitori.

La LPD rivista protegge la personalità e i diritti fondamentali delle persone fisiche che si trovano in Svizzera, i cui dati sono trattati da privati o dallo Stato; i dati delle persone giuridiche non sono più protetti. Per l'acquisto di SaaS ciò significa: una certificazione sulla protezione dei dati riguarda i dati personali di persone fisiche – i dati aziendali che lo stesso servizio elabora non rientrano in questa categoria.

I dati personali sono tutte le informazioni che si riferiscono a una persona fisica determinata o determinabile (art. 5 lett. a LPD). Il trattamento è qualsiasi operazione con dati personali, indipendentemente dai mezzi e dalle procedure applicate (art. 5 lett. b LPD). La LPD presenta una grande vicinanza contenutuale al Regolamento generale sulla protezione dei dati (RGPD).

L'OLCert costituisce il quadro per le certificazioni sulla protezione dei dati secondo la LPD. Verificabili sono, come per ogni certificato, l'ente emittente, la sua autorizzazione per il settore concerned, l'oggetto descritto nel certificato – quali trattamenti e quali parti dell'organizzazione sono stati verificati – nonché la durata di validità. Chiedete il certificato e la denominazione dell'ente certificatore e insistete per poter consultare autonomamente la voce di registro.

Una certificazione del fornitore non sostituisce la verifica della propria responsabilità. Chi, in qualità di responsabile, esternalizza dati personali a un fornitore SaaS, rimane responsabile del trattamento nei confronti delle persone interessate; certificati sono i processi del fornitore, non l'utilizzo del servizio da parte vostra.

Agli acquisti appartengono quindi anche chiarimenti propri: quali dati personali e in quale misura confluiscono nel servizio, quale trattamento su incarico viene concordato, dove i dati vengono trattati e archiviati. Da chiarire è anche come i dati vengono recuperati e cancellati alla fine del contratto.

La LPD vigente data dal 25 settembre 2020 ed è consultabile pubblicamente su Fedlex, il sito web del diritto federale. L'Ordinanza sulle certificazioni in materia di protezione dei dati (OLCert) la integra. Entrambi gli atti possono essere verificati senza la collaborazione di un fornitore.

Chi vuole verificare una certificazione sulla protezione dei dati secondo l'OLCert cerca l'ente emittente, l'autorizzazione, l'oggetto e la durata di validità. Se manca l'autorizzazione, il certificato rimane privo di prova.

Verificare autonomamente report firmati e chiavi pubbliche

I report di sicurezza, i report di penetration test e i documenti di audit dovrebbero essere richiesti come file firmati, non come normali allegati PDF. Il fornitore svizzero QSearch fornisce i suoi report di sicurezza firmati PGP. Se la firma è valida, il file è inalterato dall'emissione e proviene dal titolare della corrispondente chiave privata. La firma permette un controcontrollo senza dover richiedere al mittente.

Il modello di verifica che Transpareo descrive per il Passaporto Digitale di Prodotto può essere trasferito direttamente: il produttore pubblica il suo identificativo oppure la sua chiave pubblica sul proprio dominio sotto un indirizzo fisso (secondo lo standard W3C DID:web). La verifica avviene nel browser dell'osservatore e non contatta alcun server del fornitore. L'app di visualizzazione è open source, così il codice di verifica può essere letto. La chiave privata rimane presso il produttore; Transpareo aggiunge solo la propria controfirma.

Per gli acquisti ciò significa: chiedete l'indirizzo dell'archivio delle chiavi e verificate autonomamente un file fornito.

Consapevolmente nessuna catena di certificati classica: le catene di certificati scadono nel corso di decenni, mentre un indirizzo sul proprio dominio rimane robusto. Chi conserva prove che devono essere verificabili anche dopo molto tempo, punta quindi su indirizzi di chiave raggiungibili durevolmente e non su una catena, la cui radice nel frattempo potrebbe essere scaduta. Se la firma non si trova come blocco sopra il documento, ma sopra ogni singola indicazione, anche i campi aggiunti successivamente rimangono dimostrabili senza dover firmare nuovamente.

Da regolamentare contrattualmente sono il luogo di pubblicazione della chiave pubblica e dell'impronta digitale nonché l'obbligo di fornire ogni report firmato. Da regolamentare è anche la conservazione della chiave e del report nel proprio archivio, perché una firma rimane verificabile solo finché la chiave è reperibile.

L'app di visualizzazione open source per questo modello di verifica si chiama Transpareo Time Machine. Carica il passaporto, ricalcola la sua impronta digitale e verifica entrambe le firme, senza contattare un server del fornitore. Chi è diffidente può leggere il codice.

Chi vuole verificare una firma cerca l'indirizzo fisso della chiave sul dominio del fornitore e l'impronta digitale. Se manca l'indirizzo, il report rimane non verificato.

Ricostruire le referenze dai dati pubblici sugli appalti

Le referenze possono essere ricostruite tramite le informazioni pubbliche sugli appalti, poiché le aggiudicazioni e gli accordi quadro vengono pubblicati. L'approccio metodologico utilizza tre orizzonti temporali simultaneamente: il passato (chi è il leader di mercato?), il presente (quali bandi di gara corrispondono oggi?) e il futuro (quali accordi quadro scadono presto?). Per la verifica dei fornitori ciò significa: cercare gli avvisi di aggiudicazione con il nome del fornitore e registrare il committente, l'oggetto, la data e la durata. Non fidatevi della lista di referenze nella presentazione.

In Germania, l'Ufficio centrale per gli acquisti IT (ZIB) presso l'Ufficio federale degli appalti del BMI gestisce un volume annuale di accordi quadro IT di circa 4 miliardi di euro. In Austria e nell'UE ci sono oltre 16'000 enti pubblici committenti IT.

Per il timing vale la pena dare un'occhiata ai contratti: in Germania valgono gli accordi quadro EVB-IT, in Austria AVB-IT e in Svizzera le CGA Informatica con i loro cicli quadriennali. Queste durate sono uno strumento di timing. Chi sa quando scade un accordo quadro, sa anche quando un fornitore è di nuovo in concorrenza. Allora si possono confrontare nuovamente referenze e condizioni.

Un contratto cloud EVB-IT richiede una prova di protezione di base BSI. Chi conosce tali requisiti può verificare le referenze in modo più mirato. Il vendor lock-in può essere riconosciuto così prima.

Un incumbent ricorrente è la referenza più significativa e allo stesso tempo il segnale di avvertimento più chiaro. Un fornitore che siede presso il committente da quattro anni conosce l'infrastruttura e ha già integrato il suo sistema; chi offre per la prima volta parte da zero. Dalla sequenza delle aggiudicazioni e dalle durate degli accordi quadro si può quindi dedurre dove esistono dipendenze. Diventa altrettanto visibile da quanto tempo un committente è vincolato e quando il mercato si apre per una nuova aggiudicazione.

Il panorama dei portali nell'area DACH è frammentato. Solo in Austria vengono pubblicati annualmente centinaia di procedimenti IT rilevanti, con la massima densità a Vienna. Una ricerca per una parola chiave come «IT» o «Software» fornisce migliaia di risultati e nasconde proprio i grandi progetti.

Chi vuole verificare una referenza cerca l'avviso di aggiudicazione con nome del fornitore, committente, oggetto, data e durata. Se manca l'avviso, la referenza rimane un'affermazione.

Durate degli accordi quadro nell'area DACH

Verificare le prove di integrazione e interoperabilità nell'ambiente federale

I fornitori SaaS attivi nell'ambiente federale devono dimostrare la loro integrazione eIAM. Questa prova è verificabile pubblicamente. La base è la circolare eIAM «Integrazione di applicazioni in eIAM».

eIAM è il sistema centrale di accesso e autorizzazione della Confederazione. AGOV è una componente intrinseca di eIAM e occupa una posizione speciale; CH-LOGIN si trova in fase di dismissione. Consultabile pubblicamente è la circolare per gli acquisti «Integrazione di applicazioni in eIAM» (versione 1.7 del 9 ottobre 2024). Serve come base per le questioni di integrazione e va letta nella versione attuale al momento dell'acquisto.

eIAM incluso AGOV autentica persone fisiche, non giuridiche. Questa distinzione va considerata nella verifica di referenze e certificati, perché le prove sulla protezione dei dati si riferiscono a persone fisiche.

Secondo questa circolare, per le applicazioni web e le app mobile native vale l'obbligo di riferimento eIAM. L'integrazione può avvenire direttamente o indirettamente; esistono diverse varianti di integrazione indiretta. La circolare distingue inoltre i casi in cui vanno utilizzati i servizi del DFJP da quelli in cui viene utilizzato il servizio eIAM. Prima di accettare una promessa di interoperabilità, fatevi indicare per iscritto la variante di integrazione scelta e la via prevista. Verificate l'obbligo di riferimento rispetto alla circolare.

Ciò è verificabile senza la collaborazione del fornitore: la circolare è disponibile pubblicamente, così come le indicazioni su eIAM, AGOV e i provider di identità, da cui eIAM ottiene le identità elettroniche. Le domande al fornitore si rivolgono quindi a elementi dimostrabili – quale variante di integrazione, basata su quale versione della circolare, coordinata con quale ente. Assicurazioni generali di interoperabilità non sono sufficienti.

Nel sistema centrale eIAM incl. AGOV attualmente non viene impiegata alcuna IA. Questa indicazione di trasparenza è consultabile pubblicamente.

La circolare è pubblicata pubblicamente sul sito web eIAM della Confederazione. I provider di identità sono la fonte delle identità elettroniche per eIAM. Il passaggio da CH-LOGIN porta ad AGOV e FED-LOGIN. Anche la federazione di Entra con eIAM è documentata pubblicamente.

Chi vuole verificare una prova di integrazione cerca la variante di integrazione scelta e la versione della circolare. Se manca l'indicazione, la promessa di interoperabilità rimane generica.

Segnali di avvertimento e limiti della verifica pubblica

Segnali di avvertimento risultano direttamente dalle fonti pubbliche: un sigillo senza voce di registro reperibile; un certificato il cui ambito di validità non comprende la prestazione esercitata, la sede o i subappaltatori. Altri segnali di avvertimento sono un certificato scaduto senza prova del rinnovo; clienti di riferimento nominati senza avviso di aggiudicazione e senza data; un report di sicurezza come PDF senza firma.

Le domande che ne conseguono vanno direttamente al fornitore: numero del certificato, ente emittente, ambito di validità letterale, durata di validità, data e tipo dell'ultimo audit. Da chiedere sono anche l'indirizzo e l'impronta digitale della chiave pubblica nonché la promessa di fornire ogni report firmato. Per ogni referenza nominata vanno indicati l'ente aggiudicatore, l'oggetto dell'appalto e la data; per l'integrazione la variante di integrazione eIAM scelta con la versione della circolare. Chi non riceve nessuna di queste indicazioni, ha già una risposta.

I limiti della verifica pubblica sono altrettanto chiari: Rintracciabile è solo ciò che un ente terzo pubblica. Riscontri interni dell'audit, la lista dei subappaltatori, la storia degli incidenti e lo stato attuale di un'istanza produttiva non possono essere verificati così; per questo servono informazioni e diritti di verifica assicurati contrattualmente. Un certificato attesta un sistema di gestione funzionante, non la sicurezza di una determinata configurazione in esercizio.

Ciò che non è reperibile pubblicamente, manca come prova. Voce di registro, firma e avviso di aggiudicazione sono le tracce solide.

Vantaggi e limiti della verifica pubblica delle prove SaaS