Questa lista di controllo descrive in dettaglio dieci criteri da verificare prima di firmare con un backend as a Service (BaaS), con la domanda precisa da porre a ciascun fornitore per ciascuno.
Il criterio più spesso dimenticato è la nazionalità del fornitore, distinta dall'ubicazione dei suoi server. Una società madre americana rimane soggetta al CLOUD Act anche se i suoi dati vengono eseguiti su server in Francia o Germania. La nostra guida completa al GDPR e alla sovranità dell'UE descrive dettagliatamente questa distinzione legale; Questa lista di controllo si concentra sui punti operativi da verificare durante una valutazione del fornitore.
L'essenziale
- Una casella selezionata “Regione UE” copre solo una parte del rischio: la nazionalità dell’azienda che ospita i tuoi dati è altrettanto importante di fronte al CLOUD Act.
- Il DPA (articolo 28 GDPR) è obbligatorio non appena un fornitore tratta dati per tuo conto, indipendentemente dalle dimensioni della tua azienda.
- L'isolamento tra client non è un dettaglio implementativo: una tabella condivisa con tenant_id non offre le stesse garanzie di un database dedicato per progetto.
- Una certificazione “roadmap” non è una certificazione ottenuta: richiede il rapporto di audit firmato, non una promessa di marketing.
- I diritti di accesso, cancellazione e portabilità devono essere esercitabili in modalità self-service: un fornitore che risponde con script SQL personalizzati rallenta la tua stessa compliance.
- L'hosting autonomo elimina il contraente ma sposta l'intero onere operativo della notifica di sicurezza e violazione sul tuo team.
Ubicazione dei dati e nazionalità del fornitore
Due fatti separati determinano la tua esposizione legale: dove sono archiviati i dati e qual è la nazionalità legale della società che li ospita. Il GDPR disciplina il primo punto. Il secondo è regolato dall’American CLOUD Act.
Questo testo autorizza le autorità federali americane a richiedere dati a qualsiasi società costituita secondo la legge americana, comprese le sue filiali. Ciò vale anche quando questi dati sono ospitati su server fisicamente ubicati in Europa. Un badge "ospitato nell'UE" su un sito di marketing non dice nulla sulla nazionalità della società madre.
Aurabase è una società francese, Aurabase SAS, con sede a Parigi. La sua infrastruttura di produzione funziona su data center Hetzner a Norimberga, Falkenstein (Germania) e Helsinki (Finlandia): sovranità dell’UE. Due fatti distinti, sede legale e ubicazione dei server, da non confondere nella stessa diligenza.
La domanda da porre a qualsiasi fornitore: la tua società madre è registrata al di fuori dell'UE, anche se i tuoi server sono in Europa?
Il Garante: cosa prevede l’articolo 28 del GDPR
Il GDPR richiede un contratto scritto tra te, titolare del trattamento, e il tuo fornitore, subappaltatore: questo è l’articolo 28. Senza questo documento, non sei conforme, indipendentemente dalla serietà tecnica del fornitore altrove.
Un DPA valido specifica lo scopo e la durata del trattamento, le categorie di dati e interessati e l'elenco dei subappaltatori. Vengono inoltre dettagliate le misure di sicurezza applicate e gli obblighi di assistenza in caso di richiesta dell'utente. Infine, determina la sorte dei dati alla fine del contratto: cancellazione o restituzione.
Aurabase pubblica un DPA sottoscrivibile direttamente dallo Studio, costruito sulle clausole contrattuali standard adottate dalla Commissione Europea (decisione 2021/914). Il nostro articolo dedicato al DPA di un backend as a service dettaglia clausola per clausola cosa controllare prima di firmare.
L'elenco dei subappaltatori deve essere pubblico e notificato
L'articolo 28 GDPR richiede inoltre che il tuo subappaltatore elenchi i propri subappaltatori: host, gateway di pagamento, servizio di posta elettronica transazionale. Qualsiasi modifica dovrà esserti notificata, con diritto di opposizione.
Richiedi questo elenco per iscritto e controlla che anche ogni subappaltatore critico, in particolare l'ospite, abbia sede nell'UE. Altrimenti, la catena di subappalto ricrea l’esposizione al CLOUD Act che cercavi di evitare cambiando il tuo fornitore principale.
Isolamento tra clienti: condiviso o dedicato?
L'isolamento tra i tuoi dati e quelli di altri clienti dello stesso fornitore determina l'entità di una fuga di dati in caso di bug. Esistono tre architetture, con garanzie molto diverse.
Il modello più comune, una grande tabella condivisa con una colonna tenant_id, è anche il più fragile. Una policy RLS scritta in modo inadeguato o una query senza una clausola di filtro può esporre più client contemporaneamente. Una base per progetto, con il proprio ruolo di connessione, elimina questa classe di bug: il limite è impostato a livello di connessione, non una clausola WHERE che uno sviluppatore potrebbe dimenticare.
A questo punto, ogni progetto Aurabase riceve il proprio database Postgres, con il proprio ruolo di connessione nell'ambito di search_path iniettato dal JWT a livello di gateway. Tra due organizzazioni, l'isolamento diventa fisico: cluster Postgres dedicato, spazio dei nomi Kubernetes separato. Dettagli completi sulla pagina Sicurezza.
Sicurezza tecnica: crittografia, audit, bug bounty
Il GDPR impone “misure tecniche e organizzative adeguate” (articolo 32), senza elencare uno standard preciso. In pratica, tre elementi concreti da verificare: la crittografia in transito e a riposo, l'esistenza di un programma di audit indipendente e un canale documentato di segnalazione delle vulnerabilità.
Aurabase crittografa gli scambi in TLS 1.3 e i dati inattivi in AES-256, con un'opzione BYOK (chiavi gestite da te tramite AWS KMS o HashiCorp Vault) sul piano Enterprise. Il programma pubblico bug bounty, ospitato su huntr.dev/aurabase, paga da € 200 a € 10.000 a seconda della gravità del difetto riscontrato. La politica di informativa coordinata ha durata di 90 giorni. Un fornitore senza un canale di reporting documentato, per definizione, non ha in corso audit indipendenti.
Diritti degli interessati: self-service o script manuale?
Gli articoli 15, 17 e 20 del GDPR garantiscono agli utenti finali il diritto di accesso, cancellazione e portabilità dei propri dati. La domanda da porre al tuo BaaS: questi diritti possono essere esercitati in modalità self-service o richiedono uno script SQL su misura per ogni richiesta?
Sei tu, il titolare del trattamento, che sei legalmente obbligato a rispondere entro 30 giorni, anche se l'infrastruttura sottostante è opaca. Un provider che richiede uno script manuale per ogni richiesta rallenta i tempi di risposta. In Aurabase, l'esportazione e l'eliminazione sono accessibili da Studio → Impostazioni → Privacy o tramite privacy@aurabase.cloud per casi più complessi.
Notifica di violazione: termine di legge versus impegno contrattuale
Il GDPR prevede che il titolare del trattamento, Lei, notifichi la violazione alla propria autorità di controllo entro 72 ore dal momento in cui ne viene a conoscenza (articolo 33). Questo periodo inizia solo quando vieni informato dal tuo fornitore.
L'impegno contrattuale del fornitore alla notifica è quindi importante quanto il termine legale stesso. Chiedere il termine contrattuale massimo che si impegna a rispettare per notificarvi un incidente e cosa deve includere tale notifica: natura della violazione, categorie e volume approssimativo dei dati interessati. Questa cifra deve essere scritta nero su bianco nel DPA, non solo menzionata oralmente prima della vendita.
Certificazioni: ottenute o roadmap?
Una certificazione annunciata su un sito di marketing non equivale a una certificazione ottenuta. Molti fornitori BaaS comunicano una “roadmap di conformità” (SOC 2, ISO 27001) senza aver avviato il corrispondente audit di parte terza.
Su questo punto specifico la trasparenza conta più del bando stesso. La pagina Sicurezza di Aurabase afferma esplicitamente che ad oggi non è stata impegnata alcuna certificazione di terze parti e pubblica la propria roadmap su un Trust Center dedicato anziché visualizzare un badge non acquisito. Richiedere sistematicamente il rapporto di audit firmato, e non solo il nome dello standard in questione, prima di considerare concessa una certificazione da qualsiasi fornitore.
Self-hosting: la piena conformità ha un costo operativo
L'hosting autonomo del tuo Postgres elimina la questione del subappaltatore, ma non risolve automaticamente la conformità al GDPR. La responsabilità per la sicurezza, i backup crittografati, l'applicazione di patch e la risposta alle violazioni rimane interamente a te.
Per un team senza SRE dedicato alla sicurezza Postgres, un BaaS sovrano dell'UE con DPA firmato trasferisce parte di questo onere operativo a una terza parte sottoposta a audit, senza sacrificare la giurisdizione. Il nostro confronto self-hosting vs BaaS sovrano dell'UE quantifica questo compromesso per un piccolo team.
I dieci criteri e la domanda da porre
Una versione ridotta, utile nelle riunioni di valutazione dei fornitori o per costruire la propria griglia di audit.
| Criterio | Domanda da porre al fornitore |
|---|---|
| Posizione E nazionalità | Dove sono i server e dove è registrata la società madre del provider? |
| DPA (articolo 28 GDPR) | Il contratto di subappalto è firmato o menzionato solo nella prevendita? |
| Elenco dei subappaltatori | È pubblico, aggiornato, con avviso in caso di modifica? |
| Isolamento dei dati | Tabella condivisa con una colonna tenant_id o base dedicata per cliente? |
| Crittografia | TLS in transito, AES a riposo, opzione BYOK disponibile? |
| Revisione indipendente | Bug bounty attivo o pentest esterno datato, con canale di segnalazione documentato? |
| Diritti GDPR (accesso, cancellazione, portabilità) | Può essere esercitato in modalità self-service, oppure solo tramite script manuale su richiesta? |
| Notifica di violazione | Quale durata contrattuale massima è scritta nero su bianco nel DPA? |
| Certificazioni | Ottenuto con un rapporto di audit firmato o solo come tabella di marcia? |
| Responsabile della conformità | BaaS sovrano dell'UE sottoposto a revisione o self-hosting con l'onere operativo assunto internamente? |
Domande frequenti: conformità al GDPR e scelta di un BaaS
Prossimo passo
Nessuno di questi dieci criteri è sufficiente da solo per garantire la conformità al GDPR per un backend come servizio. È la loro combinazione, verificata punto per punto e non dedotta da un badge di marketing, che costruisce una seria valutazione del fornitore.
Per conoscere tutte le sfumature legali tra regione ospitante e nazionalità del fornitore, consulta la nostra GDPR e guida alla sovranità dell'UE. Per i dettagli sulle misure tecniche di sicurezza menzionate nei criteri 4 e 5, la pagina Aurabase Sicurezza rimane il riferimento aggiornato.