Architettura di sicurezza
Privacy per architettura
Schweizerform è un sistema zero-knowledge. Ogni invio viene bloccato nel browser del rispondente prima di lasciare la pagina, e le chiavi che lo sbloccano non esistono mai al di fuori della sessione del proprietario. Questa pagina spiega come — e cosa, di conseguenza, non possiamo fare.
Cifrario simmetrico
AES-256-GCM
Cifrario asimmetrico
RSA-OAEP 2048, SHA-256
Derivazione della chiave
PBKDF2-SHA-256 · 100 000
Giurisdizione dell'hosting
Svizzera — Infomaniak
Princìpi fondamentali
Tre pilastri di fiducia.
La sicurezza non è una funzionalità aggiunta sopra a un form builder. È la forma attorno a cui è stato costruito il form builder.
Principio 01
Infrastruttura svizzera
Non "non lo farà". Non può. Un operatore fidato è un singolo punto di fallimento — e un magnete per ordinanze del tribunale, minacce interne e credenziali rubate. Il nostro sistema ci rimuove completamente dal percorso di sblocco.
Principio 02
Conforme alla nLPD
Una clausola di "residenza dei dati" in un contratto è solo carta — cambiare giurisdizione richiede un'integrazione contrattuale. Noi gestiamo tutto lo stack — applicazione, database, archiviazione, e-mail — su infrastruttura svizzera. Nessun fornitore statunitense o europeo si trova mai nel percorso dei dati.
Principio 03
Il browser del rispondente appartiene al rispondente.
La pagina pubblica del modulo non carica alcuno script di terze parti. Niente Google Analytics, niente Sentry, niente Mixpanel, niente Intercom, niente pixel pubblicitari. L'unica rete che il rispondente tocca è la nostra.
Gerarchia delle chiavi
Quattro livelli di chiavi. Nessuno sui nostri server.
Il suo Access Code, digitato nel browser, produce in memoria una Master Key. Quella Master Key apre la Form Key di ogni modulo. La Form Key apre la chiave privata del modulo. Quella chiave privata apre la chiave monouso di ogni invio. La catena finisce nella sua testa — mai nel nostro database.
Livello 01 · Segreto del proprietario
Access Code
Origin: Una passphrase scelta da lei (minimo 6 caratteri)
Storage: Solo nella memoria del proprietario — mai trasmesso
↓ PBKDF2-SHA-256 · 100 000 iterazioni · sale da 32 byte
Livello 02 · Derivata
Master Key
Algorithm: AES-256-GCM (usato come chiave di cifratura di chiavi)
Storage: Solo nella memoria del browser · cancellata al logout
↓ apre
Livello 03 · Per modulo
Form Key
Algorithm: AES-256-GCM · vincolata a form_key_creation
Storage: Memorizzata nel database — ma solo nella versione sigillata, mai in chiaro
↓ apre
Livello 04 · Per modulo
Chiave privata RSA del modulo
Algorithm: RSA-OAEP 2048 · SHA-256 · vincolata a form_private_key
Storage: Nel database, sigillata sotto la Form Key
↓ apre
Livello 05 · Per invio
Submission Key
Algorithm: AES-256-GCM · vincolata a formId:submissionId
Storage: Sigillata sotto la chiave pubblica RSA del modulo
Ciclo di vita dell'invio
Il testo in chiaro entra nel browser del rispondente. Il testo in chiaro esce dal browser del proprietario. Tra i due, solo byte cifrati.
Browser del rispondente
Crittografare → inviare
- 1Carica la pagina pubblica del modulo. Riceve solo il lucchetto pubblico del modulo (una chiave pubblica RSA) — mai la chiave che lo apre.
- 2Se il modulo è protetto da password, le domande restano sul server fino alla verifica della password — l'elenco delle domande non raggiunge nemmeno il browser prima di allora.
- 3Compila le risposte. Seleziona i file da allegare.
- 4Il browser genera una nuova Submission Key AES-256 tramite l'API Web Crypto integrata — la stessa fornita con Chrome, Firefox e Safari.
- 5Cifra il payload delle risposte con AES-GCM, vincolato all'ID del modulo e all'ID dell'invio, in modo che non possa essere replicato altrove.
- 6Cifra ciascun file separatamente. Genera un nome di file casuale per ognuno.
- 7Sigilla la Submission Key con il lucchetto pubblico RSA del modulo (OAEP, SHA-256).
- 8Invia la chiave sigillata, il vettore di inizializzazione e i blob cifrati alla nostra API.
Server Schweizerform
Persistere → dimenticare
- 1Controlla la dimensione della richiesta, i limiti di frequenza e l'eventuale verifica della password.
- 2Scrive i blob cifrati nello storage compatibile S3 di Infomaniak in {userId}/forms/{formId}/submissions/{submissionId}/.
- 3Salva la chiave sigillata e il vettore di inizializzazione in MySQL sulla riga dell'invio. Sono gli unici dati "a forma di chiave" che conserviamo — e sono inutili senza il suo Access Code.
- 4Incrementa il contatore delle risposte del modulo.
- 5Restituisce 201 Created. Fine del coinvolgimento del server.
- 6Non vediamo mai il testo in chiaro. Non deriviamo mai una chiave. Non deteniamo mai una chiave privata.
Decrittazione — lato proprietario
Quando apre un invio, il suo browser percorre a ritroso la catena di quattro chiavi: Access Code → Master Key → Form Key → Chiave privata del modulo → Submission Key → contenuto leggibile. Tutto avviene localmente; nulla di decifrato lascia mai il suo dispositivo.
Modello di minaccia
Cosa dovrebbe fare un attaccante per leggere i suoi moduli.
Abbiamo documentato questi scenari affinché i nostri clienti e i loro team di sicurezza possano esaminarli. Se individua un caso che non abbiamo trattato, scriva a support@schweizerform.ch.
| Avversario | Cosa ottiene | Cosa facciamo al riguardo |
|---|---|---|
| Dump del database trafugato o rubato | Blob di dati sigillati e blob di chiavi sigillati. Nessun contenuto leggibile. | Tutto è cifrato con AES-256-GCM. Senza l'Access Code del proprietario, nessuna riga si decifra. |
| Amministratore di server o insider compromesso | Lo stesso di sopra. Il nostro codice lato server non vede mai la Master Key né alcun testo in chiaro. | Un audit log append-only registra internamente ogni azione privilegiata. La produzione segue il principio del minimo privilegio; i nostri ingegneri non possono leggere gli invii dalla dashboard. |
| Citazione / ordine legale di divulgazione | Blob di testo cifrato e metadati (data di creazione, IP, ID della richiesta). | Possiamo conformarci a un ordine valido e al tempo stesso non consegnare nulla di leggibile. Lo documentiamo sulla pagina pubblica. |
| Cookie di sessione del proprietario rubato | Accesso al guscio della dashboard — ma ogni modulo resta bloccato dietro l'Access Code, che non conserviamo nella sessione. | Le sessioni sono brevi e si estendono solo con l'attività. L'Access Code va inserito ad ogni sessione e vive solo nella memoria del browser. |
| Phishing / estensione del browser dannosa | Qualsiasi cosa l'utente digiti. Questo è al di fuori del nostro confine di fiducia. | Content Security Policy rigorosa sulla pagina pubblica del modulo. Nessuno script di terze parti consentito. Durante l'onboarding mettiamo in guardia i proprietari sui dispositivi condivisi o non affidabili. |
| Forza bruta sull'Access Code | Un muro lento di 100 000 iterazioni PBKDF2 tra loro e ogni singolo tentativo di indovinare. | Ogni tentativo costa circa 80 ms in un browser moderno. Limitiamo i login lato server, blocchiamo l'account dopo errori ripetuti e indirizziamo i proprietari verso Access Code lunghi e difficili da indovinare. |
| Invio falsificato / replay | Byte spazzatura che falliscono l'autenticazione al momento della decifratura. | Ogni ciphertext è vincolato all'ID del proprio modulo e dell'invio. Un blob replicato contro un altro modulo fallisce semplicemente l'autenticazione e viene respinto. |
Infrastruttura
Ogni byte, ogni server, in Svizzera.
Server applicativi, database MySQL, archiviazione file compatibile S3 ed e-mail transazionali girano tutti su Infomaniak — un provider svizzero al 100 %, controllato dai dipendenti. Le uniche chiamate verso l'esterno dai nostri server sono una breve verifica IP (timeout di 3 secondi, fail-closed) e Stripe per la fatturazione dei proprietari.
Stripe non tocca mai i dati dei rispondenti. Vede solo i dati di fatturazione del proprietario per l'abbonamento stesso.
Server applicativi (Next.js)
Infomaniak · CH
Database MySQL
Infomaniak · CH
Storage a oggetti (compatibile con S3)
Infomaniak · CH
E-mail transazionale (SMTP)
Infomaniak Mail · CH
DNS / edge di rete
Infomaniak Envoy · CH
Risoluzione Geo IP
ipinfo.io · solo server-to-server
Fatturazione (solo proprietari)
Stripe · solo proprietari, mai i dati dei rispondenti
Limiti onesti
Cose che non possiamo fare — e che non fingeremo di fare.
Lo zero-knowledge taglia in entrambe le direzioni. Ecco cosa le costa, detto chiaramente.
Recuperare un Access Code smarrito.
Il suo Access Code è il punto di partenza di ogni chiave che protegge i suoi moduli. Non lo riceviamo mai, non lo memorizziamo mai, non lo inviamo mai per e-mail. Se lo perde, i dati sigillati sotto di esso sono irrecuperabili. Può cambiarlo dal suo account — il che ricifra ogni modulo sotto il nuovo codice.
Ripristinare una password e "decifrare i suoi dati automaticamente."
Alcuni servizi "cifrati" lo fanno — il che, in silenzio, vuol dire che avevano le chiavi tutto il tempo. Noi no. Un reset della password la riporta nella dashboard, ma le serve comunque il suo Access Code per leggere qualunque modulo.
Consultare il contenuto di un invio per il supporto.
Se ci scrive "cosa ha inviato il signor X martedì?", non possiamo davvero rispondere. Il nostro team di supporto vede gli stessi byte cifrati di chiunque altro. Possiamo aiutare con i metadati: conteggi, timestamp, fatturazione.
Eseguire IA / analisi sul contenuto degli invii.
Non addestriamo modelli di IA sui dati dei suoi moduli — perché non li possediamo in alcuna forma utilizzabile per quello scopo. I conteggi aggregati provengono dai metadati lato server, mai dalle risposte stesse.
Cosa è crittografato, cosa non lo è
Piena visibilità sulla nostra visibilità.
Alcuni dati devono restare leggibili perché il sistema funzioni — il suo indirizzo e-mail (per il reset password) e il lucchetto pubblico del modulo (così i rispondenti possono cifrare verso di esso). Tutto il resto resta opaco.
| Dati | Visibile a noi | Perché / come protetto |
|---|---|---|
| Risposte del modulo (testi, numeri, scelte) | No | AES-256-GCM. La chiave non lascia mai il browser del proprietario. |
| Caricamenti di file (PDF, immagini, ecc.) | No | Ogni file viene cifrato con la stessa Submission Key monouso. I nomi originali vengono sostituiti lato server con ID casuali. |
| Titoli dei moduli, etichette delle domande | Parziale | Memorizzati sul record del modulo affinché la pagina pubblica possa renderizzarlo. Nascosti ai rispondenti dietro la protezione con password finché non viene accettata. |
| E-mail + nome del proprietario | Parziale | Necessari per login, fatturazione, codici monouso e reset password. Trattati come dati personali ai sensi della nLPD e del GDPR. |
| Hash della password del proprietario | No | bcrypt con 12 round. Non vediamo mai la password stessa, solo l'hash. |
| Timestamp degli invii + IP del rispondente | Parziale | Necessari per il rate-limiting e l'audit. L'IP viene registrato nell'audit log; non appare mai in chiaro nel payload del modulo. |
| Testo cifrato dell'invio + chiave incapsulata | No | Memorizzati in S3 e MySQL. Entrambi inutili senza la catena di chiavi che termina nel suo Access Code. |
| Eventi di analisi del sito (lato operatore) | Aggregato | Pseudonimi (impronta digitale hashata), ospitati da noi sui nostri server svizzeri. Usati solo per il sito di marketing e per l'osservabilità interna — mai per le risposte dei rispondenti. |
Conformità
Allineata alle regole che contano per i dati sensibili.
Schweizerform non è uno strumento da casella di conformità, ma la sua architettura è progettata in modo che la conformità diventi sensibilmente più semplice per i nostri clienti.
nLPD
Legge svizzera revisionata sulla protezione dei dati
In vigore dal 1° settembre 2023. Ci allineiamo ai suoi requisiti: residenza dei dati in Svizzera, prontezza nella notifica delle violazioni, diritti degli interessati e cifratura dei dati personali a riposo e in transito.
Architettura allineata · Conforme per progettazioneGDPR
Regolamento generale sulla protezione dei dati dell'UE
Architettura compatibile: base giuridica per i dati limitati lato proprietario che conserviamo; i dati dei rispondenti non lasciano mai la Svizzera (quindi nessuna Clausola Contrattuale Standard è necessaria); un accordo di trattamento dati è disponibile su richiesta per i clienti business.
Architettura allineata · DPA su richiestaHIPAA
Legge statunitense sulla portabilità e responsabilità dell'assicurazione sanitaria
Le nostre primitive crittografiche sono compatibili con la Security Rule HIPAA (cifratura, controllo degli accessi, audit). Al momento non firmiamo Business Associate Agreement — ci scriva se le serve, le mostreremo dove si colloca nella roadmap.
Primitive compatibili · BAA in roadmapOltre la crittografia
I controlli noiosi che sorreggono tutto il resto.
Registro di audit append-only (lato operatore)
Manteniamo una traccia interna a prova di manomissione di ogni login, codice monouso, pubblicazione di modulo ed evento di fatturazione — con IP, browser e ID richiesta — che usiamo per la revisione di sicurezza e la risposta agli incidenti. È uno strumento interno, non una dashboard rivolta al cliente.
Sessione & OTP
Le sessioni si estendono per attività fino a 7 giorni, con token opachi da 128 caratteri in cookie HttpOnly + Secure + SameSite. Usiamo un codice monouso a 6 cifre per la registrazione e il reset password.
Rate limiting
Rate-limit token-bucket persistenti su login, codici monouso, tentativi di password e tentativi di Access Code. Sopravvive ai riavvii e funziona su più istanze.
Protezione CSRF
Il cross-site request forgery è bloccato da un token double-submit sull'intera superficie autenticata. La rotta pubblica del modulo è esente per design (nessuna sessione) ma soggetta a rate-limit.
CSP e header rigorosi
La pagina pubblica del modulo vieta gli script di terze parti a livello di browser tramite Content Security Policy. HSTS, X-Frame-Options e X-Content-Type-Options sono applicati su tutta la superficie.
Logger di errori e analisi del sito, in casa
Il nostro logger degli errori e le analitiche del sito di marketing girano sui nostri server svizzeri. Sentry, Google Analytics e Mixpanel non entrano in gioco — e i dati degli invii dei rispondenti non vengono mai toccati da nessuno dei due.
Divulgazione
Ha trovato qualcosa?
Prendiamo sul serio le segnalazioni di sicurezza e rispondiamo entro un giorno lavorativo. La preghiamo di procedere in modo responsabile — su richiesta riconosciamo il merito ai ricercatori.
Contatto
support@schweizerform.chChiave PGP su richiesta. Includa i passi per riprodurre, l'impatto ed eventuali log — e non includa dati reali dei clienti nel report.
Domande frequenti