--- title: "Accesso per un'app web svizzera senza un cloud statunitense" summary: "Cosa verificare prima di affidare a un provider l'accesso dei Suoi utenti, e come risponde EAuth: dove gira, l'esportazione, il contratto, l'eccezione." author: "Samuel Krauss" author_title: "Founder" publisher: "Elchi Studios" published: 2026-10-03 updated: 2026-10-09 url: https://elchi.dev/it/journal/accesso-per-un-app-web-svizzera-senza-un-cloud-statunitense language: it translation_of: https://elchi.dev/en/journal/sign-in-for-a-swiss-web-app-without-a-us-cloud tags: ["eauth","hosting","data-protection","switzerland"] words: 1180 --- # Accesso per un'app web svizzera senza un cloud statunitense *Di Samuel Krauss, Founder. Pubblicato il 3 ottobre 2026.* > Cosa verificare prima di affidare a un provider l'accesso dei Suoi utenti, e come risponde EAuth: dove gira, l'esportazione, il contratto, l'eccezione. Se sviluppa un'applicazione web in Svizzera e affida l'accesso a un provider, gli indirizzi e-mail e gli hash delle password dei Suoi utenti stanno ovunque stia quel provider. Per la maggior parte di quelli noti si tratta di un'azienda statunitense, soggetta al diritto statunitense, su server che Lei non sceglie. Non è automaticamente un problema. È una domanda a cui la Sua informativa sulla protezione dei dati deve rispondere, e che un cliente aziendale porrà nel questionario di sicurezza prima di firmare. Gestiamo EAuth, un provider OpenID Connect, dalla Svizzera, su eauth.me. Questo articolo è la checklist che userei per giudicare qualsiasi provider di accesso, il nostro compreso, con ciò che EAuth fa su ogni punto. Compreso l'unico punto in cui la nostra risposta non è «solo Europa». ## Dove sono i server, e chi li gestisce Chieda quali sono i server e le aziende che ci stanno dietro, non un bollino. Dal 3 ottobre 2026 EAuth gira sul nostro cluster: otto server presso cinque provider in quattro Paesi. - Due ingressi, dove termina la connessione cifrata da un browser: Hetzner a Falkenstein e UpCloud ad Amsterdam. Quando uno cade, l'altro prende il traffico. - Due nodi applicativi, che servono entrambi gli accessi nello stesso momento: Infomaniak a Ginevra e Scaleway ad Amsterdam. - Tre nodi PostgreSQL: Tavuru a Francoforte, Hetzner a Norimberga e Scaleway a Parigi. La replica verso entrambe le repliche è sincrona, quindi una modifica conta come scritta solo quando ce l'hanno tutti e tre. - Un sorvegliante presso Infomaniak a Ginevra, che controlla gli altri dall'esterno. Le immagini del profilo e i loghi stanno in un object storage presso Infomaniak, con una copia notturna presso Scaleway. Davanti a tutto questo non c'è il proxy di nessuna terza parte: la connessione da un browser termina su un ingresso che gestiamo noi, e da lì viaggia sulla nostra rete cifrata tra i nodi. Ogni connessione usa TLS 1.3 e niente di più vecchio, e i domini inviano HSTS con preload. Due servizi DNS vedono le risoluzioni dei nomi e nient'altro: Cloudflare ospita le nostre zone, e ClouDNS risponde per l'unico nome che punta agli ingressi in buona salute. Nessuno dei due vede una richiesta o un accesso. ## L'eccezione: la posta EAuth invia e-mail: il link che conferma un indirizzo, il reset della password, gli inviti, l'avviso che è stata aggiunta una passkey. Quella posta parte tramite Resend, un'azienda statunitense. Il nostro invio è impostato sulla sua regione UE, che Resend colloca in Irlanda, ma la sua stessa documentazione dice che i dati dell'account restano negli Stati Uniti qualunque sia la regione. Quindi l'indirizzo del destinatario e il testo di ogni e-mail passano per un'azienda statunitense. Dal 3 ottobre questo non è un caso marginale. Nessuna applicazione riceve un account il cui indirizzo non sia stato confermato, quindi ogni nuovo account riceve almeno un'e-mail tramite Resend. Preferisco che Lei lo legga qui piuttosto che scoprirlo nella risposta a un questionario. ## Cosa viene salvato, e come Chieda cosa contiene il database e in quale forma. EAuth salva gli hash delle password con Argon2id (64 MiB di memoria, tre iterazioni), refresh token, codici e codici di recupero solo come digest SHA-256, e chiavi di firma e credenziali di terzi cifrate con AES-256-GCM sotto una chiave che non sta nel database. Un dump restituisce testo cifrato e digest. Le sessioni registrano il browser e la piattaforma, «Firefox on Windows», mai l'header User-Agent grezzo, e il Paese con due lettere, mai un indirizzo IP. I rate limit tengono un indirizzo solo per la durata della loro finestra. L'elenco completo di ciò che viene trattato, e per quanto tempo, è l'allegato A delle condizioni: sette righe in una tabella. ## Cosa può portare con sé È qui che la maggior parte dei provider è più debole. Chieda: se me ne vado, i miei utenti devono reimpostare la password? Con EAuth la risposta è no. La console esporta un'applicazione con i suoi utenti, le organizzazioni e le impostazioni in JSON, in qualsiasi momento, senza chiedere a noi, e l'esportazione contiene gli hash delle password nella loro forma originale: Argon2id per chi ha già effettuato l'accesso da noi, oppure l'hash con cui è stato importato chi non l'ha ancora fatto. Un provider che accetta Argon2id può importarli e i Suoi utenti accedono come prima. Lo stesso funziona nella direzione opposta: EAuth importa Argon2id, bcrypt, scrypt e PBKDF2-SHA256, e sostituisce ciascuno con Argon2id al successivo accesso della persona. Per me poter andarsene è una funzione. Un provider che tiene in ostaggio gli hash dei Suoi utenti non offre un servizio, offre un affitto. ## Cosa dice il contratto Un contratto per il trattamento dei dati ai sensi dell'art. 28 GDPR e della LPD svizzera non è un documento in più da negoziare. È l'allegato B delle condizioni di EAuth, e si applica non appena Lei ha un account. Le condizioni dicono che i dati vengono trattati solo in Svizzera e nello Spazio economico europeo, cosa viene conservato e per quanto tempo, che ogni loro versione resta pubblicata con la sua data, che una modifica sostanziale viene annunciata con 30 giorni di preavviso, che anche l'aggiunta di un subresponsabile ha 30 giorni di preavviso, e che finora non è stato eseguito alcun audit di sicurezza indipendente. Quest'ultima frase c'è perché l'alternativa è lasciarLe credere il contrario. Legga la clausola sui trasferimenti accanto al paragrafo sulla posta qui sopra. La regione di invio della posta è nell'UE; l'azienda che la gestisce no, ed è questo il vuoto che ho indicato. ## Cosa deve fare comunque la tecnologia La posizione dei dati non sostituisce le basi. Qualunque provider scelga, dovrebbe richiedere PKCE su ogni richiesta di autorizzazione, confrontare i redirect URI in modo esatto, ruotare i refresh token a ogni uso e chiudere l'intera catena quando un token già ruotato viene ripresentato, offrire passkey e un secondo fattore, e contare ogni tentativo di password per indirizzo e per account prima di verificarlo. Dovrebbe anche rifiutarsi di consegnare alla Sua applicazione un account il cui indirizzo e-mail nessuno ha confermato: un indirizzo non confermato è un nome che chiunque potrebbe digitare. EAuth fa ognuna di queste cose, e `email_verified` nei suoi ID token è sempre true. L'allegato C delle condizioni elenca le misure così come sono implementate, con i loro numeri. ## I limiti I limiti sono gli stessi per ogni applicazione: 25 applicazioni per account, 20 redirect URI per applicazione e 120 richieste di token al minuto per applicazione, che uno sviluppatore può portare a 600 nella console. Oltre, basta chiedere e li alziamo. Non c'è un service level agreement: la clausola 4.1 delle condizioni lo dice in una frase, perché una cifra che non possiamo garantire è peggio di nessuna cifra. ## Cosa non è fatto EAuth non è stato sottoposto a un audit da parte di un soggetto indipendente. La pagina di stato su status.elchi.dev è online, e la disponibilità misurata del cluster ci finirà quando sarà stato misurato un mese intero; fino ad allora non c'è un numero da citare, e non ne citerò uno. Entrambe le cose verranno riportate qui quando ci saranno, qualunque sia il risultato. ## Fonti 1. [Federal Act on Data Protection (FADP)](https://www.fedlex.admin.ch/eli/cc/2022/491/en), Swiss Confederation, consultato il 2026-10-03 2. [Art. 28 GDPR, Processor](https://gdpr-info.eu/art-28-gdpr/), gdpr-info.eu, consultato il 2026-10-03 3. [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), OWASP, consultato il 2026-10-03 4. [Choosing a Region](https://resend.com/docs/dashboard/domains/regions), Resend, consultato il 2026-10-03 5. [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700), IETF, consultato il 2026-10-03 6. [HSTS Preload List Submission](https://hstspreload.org/), hstspreload.org, consultato il 2026-10-03