Chi può arrivare ai dati dei tuoi clienti?
Un CRM è la rubrica dei tuoi ricavi. Qui sotto c’è scritto, in parole normali, com’è separato, che cosa possiamo vedere noi e che cosa no, e che cosa non dichiariamo.
Separazione dentro il database
La tua organizzazione è separata dentro Postgres, non soltanto nell’applicazione. Un errore in una schermata non può quindi mostrare i dati di un’altra azienda.
Un registro che può solo crescere
Quello che succede resta scritto. Modificare o cancellare una riga non si può. Nemmeno da parte nostra, e nemmeno dal ruolo di amministrazione più alto.
L’assistenza entra con un orologio acceso
Non possiamo guardare nel tuo ambiente senza che si veda. Si passa soltanto da una sessione con un motivo, una fine e una riga di registro.
Secondo fattore per tutti
Ogni account, il tuo e il nostro, a ogni sessione deve passare da un codice di un’app di autenticazione. Ne puoi registrare due: il telefono e una di riserva, così un apparecchio perso non ti chiude fuori.
Un freno sui tentativi di accesso
Troppi tentativi in poco tempo vengono rifiutati. Succede in un punto solo, quindi funziona anche quando girano più server insieme.
A Francoforte, dentro l’UE
Il database sta su Supabase, su Postgres, su server a Francoforte (eu-central-1). I tuoi dati restano tuoi: li esporti da te in CSV, senza doverlo chiedere a noi.
La separazione sta nel database, non nella schermata
È la differenza più importante di questa pagina.
In molti programmi chi può vedere che cosa si decide nel punto in cui la schermata viene costruita. Funziona finché ogni schermata lo fa bene. Se una pagina sola si dimentica del controllo, lì finiscono i dati di un’altra azienda, e non te ne accorgi fino a quando qualcuno non lo segnala.
In Nermio quel confine sta uno strato più sotto: nel database. Ogni tabella con dati dei clienti porta regole scritte nella tabella stessa, che stabiliscono quali righe può vedere un account con la sessione aperta, e il database applica quelle regole a OGNI richiesta, da qualunque schermata o percorso arrivi. Un errore nell’applicazione può dare un messaggio di errore, ma non i dati di un’altra organizzazione. Chi arriva senza un account non ha alcun permesso di lettura su quelle tabelle.
Dentro la tua organizzazione decidi tu. Ci sono quattro ruoli — titolare, manager, utente e solo lettura — e chi sta su «solo lettura» non può cambiare niente nemmeno per una strada laterale: lo impone quello stesso strato.
Un registro che nessuno può ritoccare
Nermio tiene due registri. Uno annota quello che viene fatto nel tuo ambiente e chi lo fa. L’altro annota quello che accade agli account: tentativi di accesso, l’attivazione di un secondo fattore, un cambio di password. Stanno separati così che davanti a un incidente tu possa leggere l’uno senza doverlo pescare dentro l’altro.
Più importante è quello che con quei registri non si può fare. Per il registro delle attività è una proprietà della tabella: modificare o cancellare una riga lo rifiuta il database, anche quando la richiesta arriva dal nostro ruolo di amministrazione più alto. Per il registro degli account oggi poggia sui permessi e non sulla tabella stessa — questa differenza va qui e non in una nota a piè di pagina. Entrambi scompaiono alla scadenza del loro periodo di conservazione: ventiquattro mesi per le attività, sei per gli account. Un registro che l’amministratore può ripulire nel frattempo non è un registro.
Non guardiamo in silenzio
A volte qualcuno di qui deve guardare nel tuo ambiente per risolvere un problema. Si può, ma non alle tue spalle e non senza limite. Per farlo un collega apre una sessione di assistenza e deve indicare un motivo. Quella sessione ha una fine — quindici, trenta o al massimo sessanta minuti, mai una fine aperta — e si chiude da sola quando il tempo è finito. Un collega non può avere due sessioni aperte insieme, quindi «ero rimasto dentro da qualche parte» non esiste.
All’inizio si sceglie se la sessione può soltanto leggere o anche modificare; guardare è l’impostazione di partenza. Cancellare durante una sessione di assistenza non si può mai: non c’è nessun percorso per farlo, nemmeno con il ruolo giusto. E non è un accesso al posto tuo: nel registro non compare il tuo nome ma quello del collega, con la sessione accanto.
E lo puoi rileggere dopo. Il titolare di un’organizzazione ha il permesso di lettura sulla propria storia di assistenza: quali sessioni ci sono state, con quale motivo, quando, e che cosa è successo nel suo ambiente durante quella sessione. Non è un extra: è quello che rende spiegabile un accesso dell’assistenza.
L’accesso
La tua password non la conserviamo noi. Va cifrata in Supabase Auth e dopo non è più rileggibile, nemmeno da noi, nemmeno durante una sessione di assistenza. Una password dimenticata si può solo reimpostare, mai andare a vedere. Chi si spaccia per te e telefona per farsi leggere la sua password non la ottiene, perché non è possibile.
Sull’accesso e sul recupero della password c’è un limite: troppi tentativi in pochi minuti vengono rifiutati. Quel contatore sta nel database e non nella memoria di un server solo, perché con più server in parallelo un attaccante non sentirebbe quasi nessun limite.
Dopo la password arriva sempre un codice di un’app di autenticazione, per ogni account: il tuo, quello dei tuoi colleghi e quello del nostro personale. Il controllo è per sessione, non per account. Non «questo account a un certo punto ha attivato il secondo fattore», ma «questa sessione ci è passata»; altrimenti una password rubata basterebbe comunque.
Puoi registrare due app di autenticazione: il telefono e una di riserva, per esempio un gestore di password sul computer. Serve per il giorno in cui un telefono finisce nell’acqua. Con la riserva entri con l’altro apparecchio e ti configuri da te un telefono nuovo. Senza riserva non si può, e allora devi chiederlo a noi: soltanto noi possiamo riaprire un secondo fattore, non l’amministratore della tua organizzazione. È una scelta voluta, perché altrimenti il secondo fattore di una squadra intera vale quanto la persona meno attenta che c’è dentro. Più di due non si può, per la ragione contraria: ogni apparecchio in più è un posto in più da cui si può aprire il tuo account.
Dove stanno i tuoi dati
Su un database Postgres di Supabase, su server a Francoforte (eu-central-1), quindi dentro l’UE. Il traffico tra il tuo browser e Nermio passa da una connessione cifrata.
I tuoi dati restano tuoi, e te li tiri fuori da te: in Impostazioni c’è un pulsante di esportazione per ogni cosa, che ti dà le tue aziende, i contatti, le opportunità, le attività, la tua cronologia e le tue note in CSV. Si può ogni giorno in cui il tuo account è attivo, non solo quando vai via, e lo può fare chiunque del tuo team, anche con i permessi di sola lettura. Continua a funzionare per trenta giorni dopo che hai smesso; cambiare qualcosa, invece, no.
Che cosa non dichiariamo
Nermio è un prodotto giovane, e in una pagina sulla sicurezza questa è un’informazione che serve. Non abbiamo la certificazione ISO 27001 né un rapporto SOC 2, non abbiamo la qualificazione ACN dei servizi cloud per la pubblica amministrazione, e non abbiamo il rapporto di un test di intrusione fatto da fuori. Il software che mostra quei marchi senza averli fa esattamente il tipo di affermazione che si va a controllare solo quando qualcosa è già andato storto.
Quello che c’è scritto qui non è un bollino, quindi, ma la descrizione di che cosa sta nel codice e nel database. Se trovi un punto debole, ci fa piacere saperlo a info@nermio.com con «beveiliging» nell’oggetto — la parola olandese, perché è quella che cerchiamo nella casella di posta. Segnalare è più utile che tacere, e una segnalazione la prendiamo sul serio.
Verificalo con i tuoi dati
Crei il tuo ambiente, ci metti qualche azienda e guardi se quello che c’è scritto qui sopra sta in piedi. Non ti leghi a niente.