Sicurezza progettata, non aggiunta
Ogni richiesta attraversa autenticazione, autorizzazione per modulo e azione, ambito sui dati e filtro dei campi. L'enforcement è sempre lato server, mai affidato all'interfaccia: l'ambito è composto dentro la query SQL, e un record fuori portata non viene nemmeno estratto.
- Precedenza
- Grant di ruolo, poi negazione
- Enforcement
- Sempre lato server
- Isolamento
- Istanza e database dedicati
Permessi granulari fino al singolo campo
La precedenza è sempre esplicita: quello che il ruolo concede, e nient'altro. I permessi si assegnano per ruolo, mai cuciti sulla singola persona, e ciò che nessun ruolo concede resta negato.
-
01
Autenticazione
Sessione server-side valida, altrimenti si ferma qui.
-
02
Ruolo
Permesso per modulo e azione, concesso in modo esplicito.
-
03
Ambito dati
own, team o all: composto dentro la query SQL.
-
04
Campo
Nascosto, sola lettura o scrivibile, ruolo per ruolo.
-
05
Risposta
La stessa regola filtra JSON, viste ed export.
RBAC gerarchico
Ruoli con permessi per modulo e azione. La visibilità dei dati (own, team, all) è composta direttamente nelle query SQL: un record fuori ambito non viene nemmeno estratto, e risponde come inesistente.
Field-level security
Per ogni campo e per ogni ruolo si stabilisce se è nascosto, in sola lettura o modificabile: un campo nascosto non viene inviato dal server, non è celato dall'interfaccia. La stessa regola governa esportazioni, importazioni e storico delle modifiche: nessuna via di fuga. Le regole si impostano per ruolo, non per singolo utente.
Autenticazione robusta
Password conservate come impronta argon2id, con regole di robustezza imposte dal server; chi sceglie una password riceve anche un avviso se compare in violazioni pubblicamente note, senza che venga mai trasmessa per intero. MFA TOTP disponibile su ogni account, con dieci codici di recupero monouso, reset self-service anti-enumerazione, cambio password forzato al primo accesso.
Difesa in profondità, di default
Le protezioni sono attive appena installi, non opzioni da ricordarsi di configurare.
-
Strato 01
CSP restrittiva
Header di sicurezza emessi dall'applicazione; CSP strict con gli script autorizzati per impronta, nessun host esterno ammesso: font e librerie li serve l'istanza, quindi nessun indirizzo IP dei tuoi utenti raggiunge terze parti.
-
Strato 02
Rate limiting e lockout
Limiti per IP sugli endpoint sensibili con contatori persistenti su PostgreSQL (sopravvivono ai riavvii), blocco per account e risposte uniformi contro l'enumerazione utenti.
-
Strato 03
Sessioni revocabili
Token di accesso vincolati a sessioni server-side: logout, revoca e cambio password invalidano immediatamente l'accesso.
-
Strato 04
Segreti cifrati a riposo
Credenziali della posta, dello spazio di archiviazione e dei provider di fatturazione, più il segreto della MFA, cifrati con AES-256-GCM: la chiave è dedicata all'istanza e non risiede mai nel database. In produzione l'applicazione rifiuta di avviarsi se quella chiave manca o è debole. Guardia SSRF sulle chiamate in uscita, limiti sulle dimensioni dei payload.
Il dato in chiaro vive solo dentro l'ultimo strato
Audit log append-only: chi, cosa, quando
Le operazioni sui dati lasciano una traccia che si scrive e non si modifica: il divieto è un vincolo imposto dal database, non una convenzione applicativa. Il registro è consultabile in autonomia dagli amministratori del cliente, e le voci si cancellano solo per scadenza: la retention è configurabile e vale 730 giorni (24 mesi) di default.
- Fail-closed sulle scritture dei record: se la riga di audit non si scrive, la modifica del record non avviene
- Accessi riusciti e falliti, blocchi dell'account, creazione, modifica, cancellazione e ripristino di record
- Tentativi di accesso negati dai permessi
- Importazioni ed esportazioni, compreso l'invio per posta di un'esportazione
- Limite dichiarato: l'amministrazione degli accessi non è coperta. Creazione e modifica di utenti, ruoli, permessi e reset password da amministratore non lasciano una voce; fanno eccezione le squadre e il reset della MFA
Un'istanza tua, una catena di fornitori corta
La misura architetturale più forte non è una funzionalità: è che i tuoi dati non condividono mai un database con quelli di altri. E chi li tratta per conto nostro è dichiarato, per nome.
- Niente multi-tenancy: ogni cliente ha la sua installazione e il suo database
- Self-hosted sul tuo server, oppure in hosting gestito su un'istanza che è comunque solo tua
- Con hosting gestito istanza e copie vivono in Italia, senza trasferimenti fuori dall'UE; in self-hosted l'infrastruttura è la tua, e la scelta resta tua
- Nessun servizio terzo di analisi o marketing dentro il tuo CRM
-
Titolare
La tua azienda
Decide finalità e mezzi del trattamento. I dati restano nel tuo database.
-
Responsabile
BlueGem
Tratta per tuo conto, nei limiti del DPA. Nel funzionamento ordinario il nostro personale non consulta i tuoi dati: si accede solo per assistenza, manutenzione, diagnosi o ripristino, per il tempo dell'intervento e da chi ne ha effettiva necessità. In self-hosted, solo previa tua autorizzazione.
-
Sub-responsabili
Hosting dell'istanza, spazio delle copie e degli allegati
In hosting gestito la catena è di un solo fornitore di infrastruttura, Aruba S.p.A., con trattamento in Italia: è elencato per nome, servizio e sede nel documento di trasparenza, che dichiara anche la concentrazione di rischio che ne deriva. Nessun soggetto extra-UE fra i nostri sub-responsabili. Posta e fatturazione elettronica restano fornitori tuoi, con i tuoi contratti.
Compliance con i documenti, non con gli aggettivi
DPO e legali non cercano rassicurazioni: cercano carte. Il pacchetto contrattuale include i documenti che servono alla due diligence, versionati e riconciliati con i controlli tecnici che trovi in questa pagina. L'elenco completo è in Come lavoriamo.
| Riferimento | Documento | Cosa contiene |
|---|---|---|
| Art. 28 | BG-LEG-002 · Accordo sul trattamento dei dati (DPA) | Ruoli chiari (tu titolare, noi responsabile), matrice di responsabilità per modalità di erogazione, autorizzazione generale ai sub-responsabili con preavviso e diritto di opposizione motivata. |
| Art. 28.2 | BG-LEG-004 · Fornitori e sub-responsabili del trattamento | Allegato C del DPA: l'elenco di trasparenza di chi tratta dati per conto nostro, con quali dati e in quale sede. Oggi un solo fornitore di infrastruttura, in Italia, per l'istanza e per lo spazio delle copie e degli allegati. Riesame almeno annuale e nuova versione a ogni variazione, comunicata al cliente. |
| Art. 32 | BG-LEG-003 · Misure tecniche e organizzative | Allegato B del DPA: organizzato sulle quattro capacità dell'articolo 32, misura per misura, con i tempi di ripristino misurati e non stimati. Il paragrafo finale elenca per esteso i limiti dichiarati delle misure, e fa parte del documento quanto il resto. |
| Art. 17 | BG-LEG-006 · Conservazione e cancellazione dei dati | Sui sistemi attivi il record esce subito dall'operatività e finisce nel cestino, dove resta 30 giorni prima della purga definitiva, che è irreversibile. Nelle copie il dato resta congelato e decade con la rotazione, entro la profondità del livello e comunque entro 12 mesi. Ogni cancellazione è annotata in un registro in sola aggiunta, scritto nella stessa transazione: dopo un ripristino le cancellazioni intervenute nel frattempo si possono rigiocare, con una decisione esplicita di chi conduce l'operazione. |
| Art. 15 e 20 | BG-LEG-002 §9 · Assistenza sui diritti degli interessati | Quando una persona chiede quali suoi dati tratti, un comando amministrativo percorre tutti i moduli, base e personalizzati, e restituisce le righe che contengono il termine cercato, dichiarando su quali moduli ha cercato, quali ha saltato e se il risultato è completo. È riservato agli amministratori per costruzione: con una visibilità ridotta i record fuori portata non risultano nascosti ma inesistenti. Il DPA dichiara anche i limiti: tetto di 5000 righe per modulo, una ricerca per ogni identificativo della persona, note scollegate, allegati e registro di audit da raccogliere a mano. La completezza della risposta resta di chi la prepara. La riga di audit viene scritta con il termine e i conteggi, mai i dati. |
| Art. 33 | BG-LEG-002 §10 · Violazioni dei dati | Impegno di notifica al titolare senza ingiustificato ritardo definito nel DPA, con quanto serve per valutare l'impatto e adempiere verso l'autorità, cui spetta al titolare rivolgersi. |
| Policy | BG-SEC-001 · Politica di sicurezza delle informazioni | Principi e controlli attivi descritti per lo stato reale del servizio: enforcement lato server, privilegio minimo, difesa in profondità, istanza dedicata come isolamento primario. |
Il tuo security team vorrà i dettagli. Noi li abbiamo.
Richiedi il pacchetto di due diligence (DPA, TOM, sub-responsabili, politica di sicurezza) o una sessione di approfondimento con il nostro team.