I suoi dati restano dove devono stare.

Installazione e dati

• Self-hosted. SnagBane è un software che installa con Docker, su un VPS o su cPanel. Moduli, risposte, file e account sono salvati nel suo database (MySQL/MariaDB, PostgreSQL o SQLite) e nel suo storage.
• Nessuna password predefinita condivisa. Il database Docker parte con una password di installazione che l’installer sostituisce con una password casuale robusta; php artisan snagbane:db-password la cambia in seguito.
• Archiviazione privata dei file fuori dalla root web, con nomi di file casuali.
• Funziona su una rete interna. Il piano Free non richiede accesso a internet; Business ed Enterprise richiedono HTTPS in uscita per il controllo della licenza.

Identità e accesso

• Single sign-on con Microsoft Entra ID, Google Workspace, Okta e qualsiasi identity provider SAML 2.0 come AD FS o Ping (Business ed Enterprise): solo risposte SAML firmate ad accessi avviati da SnagBane, ciascuna accettata una sola volta. Gli accessi dalla directory non creano mai amministratori, e l’assegnazione dei ruoli tramite gruppi può solo innalzare un ruolo.
• Verifica in due passaggi per gli account SnagBane: un’app di autenticazione (la sua chiave di configurazione può andare in un gestore di password) o chiavi di sicurezza FIDO2 e passkey — YubiKey, Windows Hello, Gestore delle password di Google, Portachiavi iCloud. Viene chiesto prima il metodo più forte; i codici di recupero monouso sono la via d’uscita, mai la sola password. Può essere obbligatoria per gli amministratori, e un amministratore può chiedere di configurarla di nuovo.
• Blocco dell’account dopo ripetuti accessi falliti (anche per indirizzi sconosciuti, così gli account non si possono scoprire), regole rigorose sulle password e hashing bcrypt.
• Ruoli e aree di lavoro: proprietari, amministratori, editor, lettori e rispondenti; regole di accesso per modulo, portale e area di lavoro. I visitatori senza accesso vedono solo titolo e descrizione, mai le domande.
• Le nuove persone non hanno diritti di modifica per impostazione predefinita: il ruolo predefinito è rispondente.

Sicurezza dell’applicazione

• Content Security Policy rigorosa con nonce per richiesta, protezione dal clickjacking, HSTS su HTTPS, nosniff e una referrer policy. Protezione da CSRF e session fixation.
• I file caricati sono controllati con un elenco di estensioni consentite e l’analisi del contenuto; script, eseguibili, SVG/HTML e doppie estensioni vengono bloccati.
• Protezione SSRF per ogni webhook e integrazione: gli indirizzi privati e di metadati sono bloccati (resistente al DNS rebinding), con un elenco di host interni attendibili gestito dall’amministratore.
• Segreti cifrati con la sua chiave dell’applicazione. Token API, link di approvazione, di modifica e di ripresa sono salvati solo come hash.
• Validazione lato server di ogni risposta, percorso di diramazione e calcolo; le soluzioni dei quiz non arrivano mai al browser; l’iniezione di formule viene neutralizzata nelle esportazioni CSV, Excel e Google Sheets.
• Link costruiti dall’indirizzo configurato, mai dall’intestazione Host della richiesta.

Monitoraggio e audit

• Log di controllo di accessi, amministrazione, esportazioni e decisioni di approvazione, compreso chi ha cambiato un approvatore e perché.
• Invio al SIEM: ogni voce viene scritta anche come una riga JSON piatta in un file giornaliero, pronta per Microsoft Sentinel, Elastic o uno Splunk Universal Forwarder. Esportazione in CSV o JSON Lines.
• Webhook firmati (HMAC-SHA256 con timestamp), così i destinatari possono verificare ogni chiamata.

Aggiornamenti e catena di fornitura

• Aggiornamenti firmati: ogni versione viene verificata con Ed25519 prima dell’installazione, poi applicata in modalità manutenzione, con ripristino in un clic.
• Aggiornamenti puliti: i file rimossi in una versione vengono rimossi anche dal suo server, così un’installazione aggiornata corrisponde a una nuova.
• Le prove di licenza sono firmate e verificate con una chiave integrata nell’app: nessuna variabile d’ambiente può sbloccare un piano a pagamento.

Impostazioni sotto il suo controllo

Le impostazioni sicure sono attive fin da subito. In Impostazioni → Sicurezza può renderle ancora più rigorose:

• Richiedere l’autenticazione a due fattori agli amministratori
• Lunghezza minima della password (maiuscole, minuscole e cifre sempre obbligatorie) e durata della sessione
• Estensioni di file consentite e dimensione massima dei caricamenti
• Host privati consentiti per webhook e integrazioni: tutto ciò che è interno viene altrimenti bloccato
• Posizioni e account SharePoint, OneDrive e Google Drive che gli editor possono usare (gli amministratori possono sceglierne qualsiasi)
• Se gli account Microsoft, Google e Okta possono usare anche una password; gli account disattivati in Entra ID o Google Workspace non possono più accedere con essa
• Scrivere ogni risposta in un file di log JSON per il suo log shipper
• Conservazione dei dati: eliminare automaticamente le risposte vecchie dopo il periodo scelto (veda GDPR)

Architettura

Un’unica applicazione web sul suo server: nessun nostro servizio cloud sul percorso dei suoi dati.

• Applicazione: PHP 8.3+ (Laravel) dietro il suo web server, oppure l’immagine Docker. L’app del browser è servita dallo stesso indirizzo; non vengono caricati script, font o CDN di terze parti, e la Content-Security-Policy consente solo il suo server.
• Database: MySQL/MariaDB, PostgreSQL o SQLite: moduli, risposte, approvazioni, account e impostazioni. Password e chiavi API delle integrazioni sono cifrate con la chiave propria dell’installazione (APP_KEY).
• File: caricamenti, firme e PDF generati nella cartella storage, fuori dalla root web, con nomi casuali; vengono serviti solo dopo un controllo di accesso.
• Scheduler: una voce cron (schedule:run ogni minuto) invia i promemoria, applica la politica di conservazione e controlla aggiornamenti e licenza.
• Indirizzi pubblici: moduli (/f/…), portali (/p/…), link di approvazione (/approve/…) e ricevute (/r/…); ognuno verifica la propria regola di accesso o un token firmato. Tutto il resto (/app, /api) richiede un account con accesso effettuato; l’API REST (Business ed Enterprise) e SCIM (Enterprise) richiedono token.
• I backup sono suoi: il database più la cartella storage, compreso storage/.env con la chiave che decifra i segreti salvati.

Cosa esce dal suo server

SnagBane non ha analytics né telemetria. Di sua iniziativa stabilisce solo queste connessioni:

E queste solo se le configura:

Documenti per i valutatori

• Politica di divulgazione delle vulnerabilità: come segnalare un problema di sicurezza, e security.txt.
• Accordo sul trattamento dei dati: per i dati personali che potrebbe condividere con noi nelle richieste di assistenza (in inglese).
• GDPR e protezione dei dati, informativa sulla privacy e contratto di licenza (questi ultimi due in inglese).
• Il codice del server viene fornito leggibile con il software, così il suo team può esaminarlo e sottoporlo a test di sicurezza sulla sua installazione (EULA, sezione 2.3).

Non dichiariamo certificazioni come ISO 27001 o SOC 2: SnagBane gira nella sua infrastruttura, sotto i suoi controlli e audit.

Domande dei valutatori