Perché la domanda non ha una risposta sì/no
Se cercate una rassicurazione, la risposta onesta delude: nessuno può dirvi «sì, la vostra app è sicura» e avere ragione. La sicurezza non è uno stato che un'applicazione possiede o non possiede, è il risultato di una domanda a cui si può rispondere solo provando: «cosa succede se qualcuno prova davvero a entrare, e sa come si fa?». Finché quella prova non è stata fatta, quello che avete non è un'app sicura: è un'app di cui non si conoscono ancora i difetti. Sono due cose diverse.
Le tre frasi che sembrano prove e non lo sono
| Quello che si dice | Perché non è una prova |
|---|---|
| «Non abbiamo mai avuto problemi» | La maggior parte degli accessi non fa rumore: chi entra per rubare dati non lascia un cartello. Il tempo medio fra un'intrusione e la sua scoperta si misura in mesi. «Mai avuto problemi» spesso vuol dire «mai accorti». |
| «L'ha sviluppata un bravo programmatore» | Scrivere software che funziona e cercarne i difetti di sicurezza sono due mestieri diversi. Un ottimo sviluppatore può lasciare un difetto di logica proprio perché ragiona da chi costruisce, non da chi prova a rompere. |
| «È ospitata su un cloud sicuro» | Il cloud mette in sicurezza la sua parte — i server, la rete — non la vostra applicazione. Un difetto nel vostro codice resta vostro anche sul cloud migliore del mondo. È una divisione di responsabilità scritta nei contratti, non un'opinione. |
Le domande che vi dicono già molto, senza spendere nulla
Prima di far testare l'app da qualcuno, potete farvi una fotografia da soli rispondendo a queste domande. Non sostituiscono un test, ma se anche una sola risposta è «non lo so», avete già trovato dove guardare per primo.
Rispondete con sì / no / non lo so
- Se un cliente cambia un numero nell'indirizzo della pagina, può vedere i dati di un altro cliente? (È il difetto più comune in assoluto nei portali.)
- Quando un utente viene disattivato, la sua sessione già aperta smette davvero di funzionare, o resta valida fino a scadenza?
- Le librerie e i componenti che l'app usa sono aggiornati, o fermi alla versione del giorno del rilascio?
- Esiste un limite al numero di tentativi di accesso, o si può provare la password all'infinito?
- Se domani il server sparisse, avete una copia dei dati che qualcuno ha davvero provato a ripristinare?
- Chi, oggi, ha le credenziali di amministrazione? E qualcuno di loro non lavora più con voi?
Due verifiche che potete fare oggi, sul vostro sistema
Alla prima domanda dell'elenco — un cliente che vede i dati di un altro — potete rispondere con una prova concreta, e non serve essere tecnici per capirne l'esito. Alla domanda «quanto traffico regge» potete rispondere con una misura vera invece che con il numero scritto sul piano hosting. Le istruzioni passo per passo sono in due guide su questo sito, pensate per essere eseguite sul vostro sistema, con autorizzazione, in un pomeriggio.
- 01
Controllare se un cliente vede i dati di un altro
Con due utenti di prova e qualche minuto si verifica il difetto più diffuso nei portali e nei gestionali. La guida spiega cosa deve succedere (un rifiuto) e cosa non deve succedere (i dati altrui che compaiono).
- 02
Misurare quanto traffico regge davvero
Con uno strumento gratuito si simula un numero crescente di visitatori fino a trovare il punto in cui i tempi di risposta si guastano. Quel punto è la capacità reale, e quasi mai coincide con quella che si immaginava.
Quando la risposta smette di essere fai-da-te
Le verifiche che potete fare da soli coprono i difetti comuni e ripetitivi. Non coprono la logica della vostra applicazione — le regole specifiche del vostro business — perché per provarle bisogna sapere cosa l'app dovrebbe fare in ogni caso, e ragionare su come aggirarlo. È il lavoro che ha senso affidare a chi ha costruito lo stesso tipo di software e sa dove di solito è sbagliato. A quel punto la domanda «è sicura?» riceve finalmente la sua unica risposta possibile: «è stata provata sul serio, ecco cosa è emerso, ecco cosa è stato sistemato».