Sicurezza delle web app: 12 punti da verificare e le prove da chiedere

Prima di dare l'ok definitivo a una web app sviluppata da terzi, pretendi e verifica otto controlli: autenticazione a più fattori, TLS su tutta l'applicazione, backup cifrati con un ripristino testato, log centralizzati, un calendario di patch documentato, un accordo sul trattamento dei dati firmato con i subincaricati indicati per nome e un piano scritto di risposta agli incidenti. Chiedi al fornitore una checklist documentata o un verbale di accettazione collegato a ogni voce, più un piano di rimedio con priorità per tutto ciò che non passa. Usa lo schema qui sotto come test di accettazione o come allegato al tuo bando, voce per voce.

---

In breve:

• Il fornitore deve dimostrare, con screenshot o report a conferma, di aver attivato autenticazione a più fattori, cifratura TLS e backup cifrati prima che l'app vada online.

• Un calendario di patch documentato, un ambiente di staging separato, un accordo sul trattamento dei dati firmato e un piano di risposta agli incidenti sono presupposti indispensabili per approvare il lancio.

• La verifica periodica dei controlli d'accesso, comprese le matrici dei ruoli e la sicurezza delle sessioni, va mantenuta con log e revisioni regolari, idealmente da una sessione in incognito.

• Pratiche di sicurezza continue come controlli settimanali delle patch, revisioni trimestrali e scansioni annuali delle vulnerabilità servono a contenere i rischi che cambiano dopo il lancio.

• Ampersand Labs può occuparsi di valutazioni di sicurezza continuative e integrare questa checklist negli incarichi di sviluppo e di assistenza, per progetti già attivi o in arrivo.

---

Cosa deve contenere la tua checklist di sicurezza per una web app?

Per usare questa checklist non serve saper leggere il codice. Serve sapere cosa chiedere e cosa vale come prova. Ogni voce qui sotto indica il documento o il materiale che il fornitore deve consegnare e come lo verifichi, oltre a dirti se blocca il go-live o se puoi pianificarla nei primi 30 o 90 giorni.

1. Autenticazione a più fattori su tutti gli account amministratore. Chiedi uno screenshot delle impostazioni che la rendono obbligatoria. Indispensabile prima del go-live.

2. Cifratura TLS dei dati in transito. Chiedi i dettagli del certificato SSL o un report di scansione. Indispensabile prima del go-live.

3. Cifratura a riposo dei campi sensibili. Chiedi quali campi del database sono cifrati e con quale metodo. Indispensabile prima del go-live.

4. Calendario dei backup documentato con un test di ripristino completato. Chiedi data ed esito dell'ultimo test di ripristino. Indispensabile prima del go-live.

5. Log centralizzati per le azioni degli amministratori e sui dati. Chiedi un esempio di esportazione relativo a una settimana. Da pianificare entro 30 giorni.

6. Cadenza scritta di patch e aggiornamento delle dipendenze. Chiedi l'ultimo report di scansione delle dipendenze. Da pianificare entro 30 giorni.

7. Ambiente di staging separato dalla produzione. Chiedi il documento che descrive il processo di rilascio. Indispensabile prima del go-live.

8. Piano di rollback per i deploy non riusciti. Chiedi l'ultimo log di rollback o il resoconto di una prova a vuoto. Da pianificare entro 30 giorni.

9. Accordo sul trattamento dei dati firmato, con subincaricati e luoghi di archiviazione indicati. Chiedi il documento firmato. Indispensabile prima del go-live.

10. Piano di risposta agli incidenti con referenti indicati per nome. Chiedi il runbook e i contatti per l'escalation. Indispensabile prima del go-live.

11. Monitoraggio e avvisi per attività anomale. Chiedi un esempio di avviso o uno screenshot della dashboard. Da pianificare entro 90 giorni.

12. Matrice dei ruoli che mostra chi ha accesso da amministratore. Chiedi l'elenco aggiornato e la data dell'ultima revisione. Da pianificare entro 30 giorni.

Un fornitore che tergiversa sui punti 1, 2, 4, 7, 9 o 10 non è pronto per il go-live, per quanto curata sia la demo.

Autenticazione e controllo degli accessi: cosa pretendere

Un controllo degli accessi debole è la via più rapida perché un'app costruita da un'agenzia venga compromessa, di solito attraverso una password di amministratore condivisa che nessuno ha più cambiato dal lancio. Il tuo compito non è configurare tu queste cose. È pretendere la prova che siano configurate bene.

• Pretendi l'autenticazione a più fattori su ogni account amministratore, più l'elevazione dei privilegi solo quando serve, così nessuno resta collegato con permessi completi per impostazione predefinita.

• Chiedi una matrice dei ruoli che elenchi ogni account amministratore e il relativo responsabile, con l'impegno a rivedere i privilegi ogni mese.

• Chiedi note di configurazione o screenshot che mostrino i timeout di sessione, i flag sui cookie sicuri e la politica delle password in vigore.

• Accedi con un account di test a privilegi ridotti e verifica che davvero non riesci ad arrivare alle pagine di amministrazione né a esportare dati che non dovresti vedere.

Consiglio: fai le tue verifiche di accesso da una sessione in incognito o da un browser pulito, mai dal portatile del tuo sviluppatore già collegato. Una sessione piena di vecchi cookie di amministrazione o di permessi in cache nasconde proprio le lacune che stai cercando.

Chiedi log che dimostrino l'applicazione effettiva delle restrizioni d'accesso in una settimana recente, non solo un documento di policy che descrive come dovrebbero funzionare.

Protezione dei dati: cifratura, luogo di archiviazione e log

La protezione dei dati è l'ambito in cui è più facile mettere nel sacco un committente non tecnico, perché "usiamo la cifratura" suona rassicurante indipendentemente dal fatto che valga per i campi che contano.

• Pretendi il TLS su tutta l'applicazione, non solo sulla pagina di login, e chiedi un report sul certificato che lo dimostri.

• Pretendi la cifratura a riposo dei campi sensibili (dati di pagamento, identificativi personali, informazioni sulla salute) e chiedi quali colonne sono coperte nello specifico.

• Chiedi dove avviene effettivamente il trattamento e fatti dare l'elenco dei subincaricati e dei luoghi di archiviazione, scritto nell'accordo sul trattamento dei dati.

• Pretendi log e tracciabilità su chi ha consultato o modificato dati sensibili, più procedure documentate di conservazione e cancellazione.

Se la tua app gestisce grandi volumi di dati sensibili o fa qualcosa che assomiglia alla profilazione automatizzata, dovresti pretendere una valutazione d'impatto sulla protezione dei dati prima del lancio. La prassi svizzera in materia di protezione dei dati si aspetta questo tipo di documentazione e tracciabilità per i trattamenti a rischio elevato, e le indicazioni sulla verifica preventiva dei servizi cloud raccomandano la stessa attenzione verso i subincaricati prima di firmare qualsiasi cosa, come spiega la Chambers and Partners’ cloud computing practice guide.

Sviluppo e rilascio sicuri: i controlli da pretendere

Il percorso che il codice fa dal portatile dello sviluppatore al tuo sito online decide se un aggiornamento sbagliato ti tiene fuori servizio per un'ora o per una settimana. È una questione di processo, non di tecnica, e puoi chiederne conto a un fornitore senza leggere una riga di codice.

• Pretendi un processo di rilascio documentato con ambienti di staging e produzione separati, un piano di rollback scritto e un calendario dei deploy concordato.

• Chiedi chi custodisce le credenziali e le chiavi di produzione, e insisti perché le persone con accesso diretto siano il minor numero possibile.

• Chiedi prove dei test automatici (evidenze della CI) e i log dei deploy che mostrino cosa è stato rilasciato e quando.

• Pretendi backup pianificati con un test di ripristino documentato e datato, non solo un processo di backup che gira e che si dà per funzionante.

Un backup che nessuno ha mai ripristinato è una speranza, non una protezione. Chiedi la data dell'ultimo test di ripristino riuscito prima di autorizzare il go-live.

Dipendenze e patch: tenere sotto controllo il rischio di terze parti

Quasi tutte le web app girano su decine di librerie di terzi che il fornitore non ha scritto e che magari non tiene d'occhio con attenzione. È da lì che nasce una quota enorme delle violazioni reali, in silenzio, attraverso un componente che nessuno si è ricordato di aggiornare.

• Pretendi un inventario delle dipendenze e una persona o un ruolo indicato come responsabile della cadenza delle patch.

• Chiedi una politica scritta sui componenti fuori supporto e sui tempi di reazione del fornitore a una nuova vulnerabilità critica resa pubblica (CVE).

• Verifica con un report recente di scansione delle dipendenze o con una dichiarazione chiara del fornitore sulla frequenza degli aggiornamenti.

Un fornitore che non sa risponderti alla domanda "in quanto tempo applicate la patch a una CVE critica" ti sta dicendo che le patch arrivano in reazione ai problemi, quando arrivano.

Monitoraggio, log e risposta agli incidenti: quali prove chiedere

Prima o poi ogni app viene sondata, scansionata o colpita da tentativi di accesso con credenziali rubate. La differenza tra un incidente gestibile e un disastro sta nel fatto che qualcuno se ne accorga in tempo e che la risposta sia provata in anticipo invece di improvvisata.

1. Pretendi log e avvisi operativi, più un piano scritto di risposta agli incidenti con referenti indicati per nome e davvero raggiungibili.

2. Chiedi la prova che il piano sia stato effettivamente messo alla prova, con una simulazione a tavolino o con un incidente reale gestito nell'ultimo anno.

3. Insisti su un tempo di prima reazione messo per iscritto, per esempio l'avvio dell'analisi entro 24 ore dal rilevamento.

4. Pretendi impegni contrattuali (SLA) sulla rapidità della notifica degli incidenti e sul supporto nella risoluzione.

5. Verifica chiedendo i runbook, un resoconto di incidente in forma anonimizzata o il rapporto interno su un incidente gestito in un incarico precedente.

Consiglio: chiedi esplicitamente un resoconto di incidente anonimizzato, non un certificato di buona salute. Un fornitore che in anni di applicazioni in produzione non ha mai avuto un solo evento di sicurezza è molto fortunato oppure non guarda con abbastanza attenzione.

Il Centro nazionale per la cibersicurezza svizzero pubblica standard minimi TIC che richiedono esplicitamente monitoraggio e preparazione agli incidenti: un riferimento utile se un fornitore obietta che queste richieste sono eccessive.

Valutazione del fornitore: la checklist contrattuale

Il contratto è il punto in cui le promesse sulla sicurezza diventano esigibili oppure svaniscono al primo problema. Vale tanto per una web app bancaria che tratta dati finanziari regolamentati quanto per un semplice sito di marketing che raccoglie indirizzi e-mail.

• Pretendi un accordo sul trattamento dei dati che indichi per nome ogni subincaricato, dica dove risiedono fisicamente i dati e definisca gli obblighi di collaborazione in caso di violazione.

• Chiedi certificazioni o rapporti di audit di terzi dove pertinenti, per esempio ISO/IEC 27001 o ISAE 3402, soprattutto per fornitori che trattano dati finanziari o sanitari.

• Negozia il diritto di svolgere audit o di ricevere rapporti periodici di terzi, e pretendi che ogni rilievo arrivi con un piano di rimedio con priorità e scadenze reali, non con la promessa di "dare un'occhiata".

Un fornitore che si oppone a una clausola sul diritto di audit ti sta dicendo qualcosa su quanta fiducia ha nei propri controlli.

Ogni quanto verificare la sicurezza dopo il lancio?

La sicurezza non è un collaudo una volta per tutte. È un'abitudine di manutenzione, e quasi tutti i founder la abbandonano nel momento in cui l'app va online.

1. Fai un controllo settimanale delle patch per confermare che dipendenze e aggiornamenti di piattaforma siano aggiornati.

2. Pianifica un controllo trimestrale su log, ripristini dei backup e revisione degli accessi.

3. Commissiona una scansione delle vulnerabilità o un audit esterno una volta all'anno, con risultati che alimentino un registro documentato dei rimedi.

4. Pretendi un test di ripristino ogni volta che cambia l'infrastruttura di backup, e fai i test di accettazione dopo ogni rilascio importante.

Le indicazioni di Alpine Excellence per le PMI svizzere presentano tutto questo come a risk-based ongoing program e non come una casella da spuntare il giorno del lancio, e suggeriscono di calibrare la spesa per la sicurezza sul rischio che l'app comporta davvero, invece che su una cifra media di settore. Tieni un registro dei rimedi aggiornato e ordinato per gravità, così nessun punto critico resta in sospeso per mesi perché nessuno se ne occupa.

Come Ampersand Labs applica questa checklist nella pratica

Ampersand Labs è uno studio con sede a Zurigo in cui sviluppatori senior seguono il progetto dalla prima consulenza fino alla consegna, per garantire continuità e controllo della qualità.

• Nel progetto NeuroMynds il team ha realizzato il sito di un founder pensato per essere veloce, sicuro e pronto ad accogliere abbonati paganti dal primo giorno, con i controlli su accessi e rilasci descritti sopra integrati dall'inizio invece che aggiunti dopo.

• Il coinvolgimento di figure senior dal via al progetto significa che la persona che ha definito il tuo modello di autenticazione è ancora lì quando l'app va online, e non è stata sostituita da chi era libero in quello sprint.

Come Ampersand Labs può aiutarti a usare questa checklist

Ci sono altre strade: ingaggiare un auditor freelance per una scansione una tantum, oppure affidarsi all'agenzia che hai già perché si autocertifichi su una checklist come questa. Funzionano entrambe, ma nessuna delle due ti dà un ingegnere senior che resta responsabile dopo che il rapporto è stato archiviato. Ampersand Labs integra la sicurezza direttamente nello sviluppo, negli incarichi per MVP e web app, così i controlli qui sopra diventano criteri di accettazione dal primo giorno invece di una corsa contro il tempo prima del lancio.

Se la tua app è già online, l'assistenza mensile copre la cadenza continuativa descritta in questo articolo: controlli delle patch, revisioni trimestrali e un registro dei rimedi che viene davvero lavorato, non solo scritto. Per i team che stanno ancora valutando un fornitore o che vogliono verificarne uno già sotto contratto, Ampersand Labs può svolgere una revisione mirata della checklist o un audit breve sugli stessi punti elencati sopra. Dai un'occhiata ai casi di studio per vedere come funziona su progetti reali, poi scrivici per definire una revisione o una proposta di assistenza mensile.

Fonti

• a risk-based ongoing program

• Chambers and Partners’ cloud computing practice guide

Domande frequenti

Qual è la voce più importante di una checklist di sicurezza per una web app?

L'autenticazione a più fattori sugli account amministratore e un ripristino dei backup già testato sono le due voci che evitano più danni, e nessuna delle due dovrebbe essere negoziabile prima del go-live.

Ogni quanto va testata la sicurezza di una web app commissionata a terzi?

Fai un controllo settimanale delle patch, un controllo interno trimestrale e una scansione delle vulnerabilità o un audit esterno una volta all'anno, aumentando la frequenza per le app che trattano dati di pagamento o sanitari.

Cosa deve contenere l'accordo sul trattamento dei dati di un fornitore?

L'accordo deve indicare per nome ogni subincaricato, dire dove sono fisicamente archiviati i dati, descrivere gli obblighi di collaborazione in caso di violazione e richiamare le certificazioni pertinenti, come ISO/IEC 27001 dove applicabile.

Come verifico le affermazioni di un fornitore sulla sicurezza senza competenze tecniche?

Chiedi prove concrete, non descrizioni: report sui certificati, log esportati, date dei test di ripristino e un resoconto di incidente anonimizzato, poi controlla che le date siano recenti e non di anni fa.

Ampersand Labs può fare una revisione di sicurezza sulla mia app già esistente?

Sì. Ampersand Labs offre revisioni mirate basate su questa checklist e assistenza mensile continuativa per app già in produzione, partendo dall'approccio guidato da figure senior usato in progetti come NeuroMynds.

Da leggere anche

• NeuroMynds: il sito di un founder veloce, sicuro e pronto ad accogliere abbonati.

• Sviluppo di MVP, web app e app mobile a Zurigo

• Repa Immobiliare: un portafoglio immobiliare fuori dalla carta, con un software che non va mai online.