Verificare referenze e certificati dei fornitori 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 directory 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 informazioni al fornitore, ma controllando le sue dichiarazioni presso terzi.

Quattro categorie di prove sono accessibili pubblicamente e ciascuna attesta qualcosa di diverso. Una registrazione 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 specificamente la prestazione SaaS 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 è andato 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. Richiedere la posizione di archiviazione della chiave pubblica con impronta digitale invece di un report come allegato e-mail. Per i progetti di riferimento, richiedere 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 e le nuove versioni dei report devono essere fornite firmate.

Le fonti accessibili pubblicamente in Svizzera sono la direttiva eIAM (versione 1.7 del 9 ottobre 2024), l'Ordinanza sulla certificazione della 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. Entratti 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 registrazione nel registro, la firma e l'avviso di aggiudicazione. Se manca una di queste tracce, la dichiarazione rimane un'autodichiarazione.

Fonti di verifica pubbliche per i fornitori SaaS in Svizzera

Controllare i certificati nel registro dell'ente di certificazione

Un certificato ISO 27001 non viene rilasciato dall'organizzazione verificata. Un ente di certificazione accreditato esegue 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 controllo incrociato avviene lì, non sul sito del fornitore.

L'ente di certificazione emittente deve essere accreditato per la norma. Una registrazione nel registro senza un'accettazione verificabile non costituisce una prova solida. Verificate l'accreditamento prima di accettare la registrazione come prova.

Dal certificato vanno riportate sei indicazioni: la denominazione giuridica 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à determina l'utilità: elenca 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 lo sviluppo e l'esercizio 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» è valida quanto la carta su cui è stampata.

Il tempo necessario per la certificazione è un indicatore di plausibilità. Il fornitore svizzero di ISMS Priverion indica generalmente da 6 a 12 mesi per una certificazione secondo ISO 27001:2022, a seconda del grado di maturità dell'ISMS. Questo permette di classificare il periodo tra l'audit e il rilascio del certificato.

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

Classificare le certificazioni della protezione dei dati secondo il diritto svizzero

Dal 1° settembre 2023 sono in vigore la Legge federale sulla protezione dei dati (LPD) rivista, nonché le nuove disposizioni di esecuzione nell'Ordinanza sulla protezione dei dati (OPD) e nell'Ordinanza sulla certificazione della protezione dei dati (OLCert). Non sono previste scadenze transitorie.

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 della 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 della protezione dei dati secondo la LPD. Come per ogni certificato, sono verificabili l'ente emittente, la sua autorizzazione per il settore interessato, l'oggetto descritto nel certificato – quali trattamenti e quali parti dell'organizzazione sono stati verificati – nonché la durata di validità. Richiedete il certificato e la denominazione dell'ente certificatore e insistete per poter consultare autonomamente la registrazione.

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.

Pertanto, agli acquisti appartengono anche chiarimenti propri: quali dati personali entrano nel servizio e in quale misura, quale trattamento su incarico viene concordato, dove i dati vengono trattati e archiviati. Va chiarito 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 sulla certificazione della protezione dei dati (OLCert) la integra. Entrambi gli atti possono essere verificati senza la collaborazione di un fornitore.

Chi vuole verificare una certificazione della 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 fondamento.

Quadri giuridici rilevanti in Svizzera

Verificare autonomamente report firmati e chiavi pubbliche

I report di sicurezza, i report dei 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 è corretta, il file è inalterato dal momento dell'emissione e proviene dal titolare della chiave privata corrispondente. La firma permette una controprova senza dover chiedere al mittente.

Il modello di verifica descritto da Transpareo per il Passaporto Digitale di Prodotto può essere trasferito direttamente: il produttore pubblica il suo identificativo o 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: richiedete 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 è 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 dell'elenco delle referenze nella presentazione.

In Germania, l'Ufficio centrale per gli acquisti IT (ZIB) presso l'Ufficio federale degli acquisti 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 CG 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 della protezione di base BSI. Chi conosce questi 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 qualcosa di nuovo 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.

Verificare le prove di connessione 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 direttiva eIAM «Collegamento di applicazioni a 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 nella fase di dismissione. Consultabile pubblicamente è la direttiva per gli acquisti «Collegamento di applicazioni a eIAM» (versione 1.7 del 9 ottobre 2024). Serve come base per le questioni di collegamento e deve essere 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 di protezione dei dati si riferiscono a persone fisiche.

Secondo questa direttiva, per le applicazioni web e le app mobile native vale l'obbligo di riferimento eIAM. Il collegamento può avvenire direttamente o indirettamente; esistono diverse varianti di collegamento indiretto. La direttiva 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 collegamento scelta e la via prevista. Verificate l'obbligo di riferimento rispetto alla direttiva.

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

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

La direttiva è pubblicata pubblicamente sul sito web eIAM della Confederazione. Gli identity provider 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 collegamento cerca la variante di collegamento scelta e la versione della direttiva. Se manca l'indicazione, la promessa di interoperabilità rimane generica.

Segnali di avvertimento e limiti della verifica pubblica

I segnali di avvertimento risultano direttamente dalle fonti pubbliche: un sigillo senza registrazione nel 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 derivano 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é l'impegno a fornire ogni report firmato. Per ogni referenza nominata vanno indicati l'ente aggiudicatore, l'oggetto dell'appalto e la data; per il collegamento la variante di collegamento eIAM scelta con la versione della direttiva. Chi non riceve nessuna di queste informazioni, ha già una risposta.

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

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

Vantaggi e limiti della verifica pubblica delle prove SaaS