menu di navigazione del network

SPID: identity provider affidabile ed etico

Salve,
mi trovo costretto a richiede lo SPID dopo averne fatto a meno per molto tempo. Premetto che utilizzo solo GNU/linux, non ho uno smartphone e non ho intenzione di comprarlo almeno fino a quando non ci sarà qualcosa di usabile (non prototipo) dotato di GNU/linux (librem, pinephone, etc).
Quale dei seguenti identity provider disponibili mi consigliate di utilizzare? Qual è più affidabile dal punto di vista di eventuali data breach e quale maggiormente etico?
Grazie

2 Mi Piace

Ciao, credo che la domanda sia mal posta.

Da questo punto di vista la normativa è stringente per tutti. Tutti gli Identity Provider sono soggetti agli stessi rigidissimi obblighi cui sono sottoposte le aziende private che trattano dati “particolarmente sensibili” ed inoltre la procedura di accreditamento è un calvario non semplice per i responsabili delle suddette aziende, che termina con un decreto ministeriale di accreditamento.

Una procedura di per sé iper-sorvegliata e iper-burocratica. Per fortuna non parlo per esperienza. Posto che un data breach è un evento poco probabile ma non inverosimile/impossibile, possiamo considerare equipollenti tutti e 9 gli ID provider a mio avviso.

Dipende da cosa si intende per etica in questo caso. Da un punto di vista contrattuale lo SPID provider è tenuto a rispettare gli obblighi contrattuali.

Un ID Provider potrebbe, la sparo a caso, demandare lo sviluppo delle soluzioni tecnologiche a programmatori in Paesi sottosviluppati dove la manodopera costa poco (edit: ma dovrebbe avere il data centre di produzione in Europa). Potrebbe essere poco etico per taluni osservatori…

Un ID Provider potrebbe, la sparo più concreta con la tua prima affermazione, decidere di pubblicare o meno parte dei codici sorgenti della propria infrastruttura IT. Nessuno che io sappia lo fa. E questo potrebbe essere altrettanto poco etico per altri osservatori, vista anche la mia rigida posizione su servizi pubblici e open source.

Hai bisogno dell’autenticazione SMS fornita da tutti tranne Aruba (ammetto che stavo facendo la lista). Quindi ne abbiamo depennato uno su nove.

Su questa rispondo a titolo personale. AOSP è open source, OnePlus pubblica i suoi sorgenti, Lineage è molto ben usato. Poi ci sono kernel open source installabili, un giretto su XDA lo farei al tuo posto. Poi se la frase è riferita all’hardware open source tanto di cappello…

Vorrei aggiungere un concetto decisamente più pratico riguardo la questione sicurezza informatica, e raccontare un po’ quello che accade a volte “dietro le quinte”.

Premetto: queste informazioni riguardano best practice di mercato, non riguardano nessuna delle “9 sorelle” di SPID che potrebbero avere procedure ancora più rigide vista la natura pubblica di SPID. Andrebbe studiato il Regolamento SPID per informazioni esatte.

Uno degli aspetti di cui mi occupo nel mio lavoro sono gli audit di sicurezza. Se un’azienda vuole lavorare come fornitore di una multinazionale, deve dichiarare/dimostrare/contrattualizzare diverse feature di sicurezza, sia tecnica che organizzativa.

A questo scopo esistono i cd. audit.

Dal punto di vista contrattuale un fornitore deve garantire determinati livelli di servizio in termini di sicurezza. Può trattarsi di specifiche richieste di adesione a linee guida di mercato, come es. OWASP, specifiche caratteristiche come la crittografia o la rigorosa registrazione degli accessi alle infrastrutture ICT, o a superare gli audit disposti da aziende di IT security esterne.

Un audit spesso si manifesta come una richiesta di autocertificazione, dunque un questionario, da parte del fornitore. Sul questionario si dibatte nell’industria. Da un lato il fornitore potrebbe barare, o tentare di farlo, dall’altro lato il cliente può disporre delle verifiche anche sotto forma di demo.

Anche a verifica dei questionari e del rispetto delle clausole si pianificano i pen-test, cioè delle attività di verifica della sicurezza svolte da professionisti esterni che cercano letteramente di bucare il sistema.

Potrei sintetizzare con una metafora. Siamo in una botte di ferro, ma il negozio di bricolage vende le punte per trapano “da ferro”.

Non mi sembra mal posta. Comunque grazie gli spunti, ti rispondo brevemente.

I data breach non sono eventi eccezionali, ma purtroppo anche troppo ordinari wikipedia e haveIBeenPwned. Per questo chiedevo quale soluzione avesse l’infrastruttura, il codice sorgente e altri aspetti di sicurezza migliori.

Per etico, intendo rispettare i diritti degli utenti in termini di raccolta dei dati personali e naturalmente anche dei lavoratori. In questo caso, non
ho specificato il mio interesse per la prima categoria.
Come hai fatto notare anche tu, il codice sorgente dovrebbe essere disponibile per eventuali audit e, secondo me, anche obbligatorio per tutti i prodotti/servizi utilizzati dalla pubblica amministrazione visto che vengono pagati con fondi pubblici.

AOSP è open source, ma è considerato come “guardare, ma non toccare”. Infatti, l’ecosistema google è chiuso ovvero i servizi necessari a molte applicazioni per funzionare, i google services, sono closed source. Utilizzando per esempio lineageOS con il progetto microG o /e/ foundation si riesce a far funzionare quasi tutte le applicazioni, ma si rimane vincolati a un ecosistema chiuso e quindi non etico.

Per fortuna stanno arrivando progetti open source sia dal punto di vista software (pureOS una delle poche distribuzioni 100% FOSS) sia hardware (librem 5 e pinephone non sono 100% FOSS a causa di alcuni binari, ma si avvicinano molto).

Quindi secondo la tua analisi, escluso aruba, gli altri sono equivalenti dai punti di vista della sicurezza ed eticità.
Grazie

1 Mi Piace

Si applica solo la presunzione di buona fede. Quindi equipollenti fino a prova contraria.