Sicurezza in sintesi

Chi l'ha approvato, a quale cambio, in che giorno: registrato, che qualcuno lo chieda o no.

Approvazioni, stato dei pagamenti, cambi valuta e modifiche dei ruoli vengono registrati dal server nel momento in cui avvengono, non ricostruiti da una chat di gruppo sei settimane dopo.

Registro di audit
Winter Beats
  • Spesa approvata · €980,00
    A. Silva · 2 min fa · sopra soglia
  • Ruolo di un membro modificato · M. Lopes → Amministrazione
    A. Silva · 14 min fa
  • Spesa inviata · $500 → €462,18 @ 0,9244
    J. Costa · 1 h fa
  • Riga di budget modificata · Produzione +€2.000
    A. Silva · ieri
Pilastro 01 // Audit trail

Audit trail di serie

Ogni modifica finanziaria porta con sé chi l'ha fatta e quando. Creare l'evento, approvare una spesa, spostare una riga di budget: tutto finisce nello storico dell'evento.


  • Autore e orario su ogni modifica
  • Scritto dall'API, non dal client
Pilastro 02 // Accesso

Accesso per ruolo

Un direttore di palco che carica ricevute e una contabile che segna fatture come pagate non hanno bisogno degli stessi permessi. Quattro ruoli, e ogni endpoint verifica quello di chi chiama prima di agire.


  • Quattro ruoli, verificati lato server
  • Claim dell'organizzazione nel token
Pilastro 03 // Storico

Cambi storici conservati

Un fornitore che fattura in dollari mantiene l'importo in dollari e il cambio del giorno in cui l'hai inserito. Un report tirato fuori mesi dopo mostra quanto è costato lo spettacolo, non quanto costerebbe al cambio di oggi.


  • Cambio salvato all'inserimento
  • Trattamento IVA bloccato per riga
Pilastro 04 // Chiarezza

Chiarezza operativa

Budget, spese, ricavi e approvazioni stanno sugli stessi record, così il margine che leggi in un report nasce da righe su cui puoi fare clic.


  • Budget, spese e ricavi insieme
  • Esportazioni dagli stessi record
Come viene verificata una richiesta

Quattro confini per ogni scrittura.

Sono i livelli che una richiesta attraversa prima di poter cambiare un numero. Sono gli stessi in ogni ambiente.

Confine 01Firebase Auth

Sessione autenticata

Firebase Auth stabilisce chi sta chiedendo. L'accesso supporta email e SSO Google.


  • Email e SSO Google
  • Sessione stabilita prima di tutto
Confine 02Emesso dal server

Claim dell'organizzazione nel token

Un claim orgId emesso lato server limita ogni lettura ai dati di quell'organizzazione. Tutti i record stanno sotto /orgs/{orgId}.


  • Claim orgId nel token
  • Tutti i record sotto /orgs/{orgId}
Confine 03Per endpoint

Verifica dei permessi lato server

Ogni endpoint verifica il ruolo di chi chiama prima di agire. Nascondere un pulsante non è il controllo; il controllo è la verifica sul server.


  • requireRole() prima di agire
  • Un pulsante nascosto non è un controllo
Confine 04Imposto dalle regole

Le scritture passano dall'API

Le regole di sicurezza rifiutano le scritture dal client, quindi le istantanee di IVA e cambio non si possono falsificare dal browser.


  • Scritture dal client rifiutate
  • Istantanee non falsificabili
Un esempio concreto

Quattro righe dal registro di un evento.

Ogni riga qui è scritta dal server. Il client non può creare una voce di audit né un'istantanea del cambio.

Cosa conserva il registro
Winter Beats · registro dell'evento
  • Spesa approvata · €980,00
    A. Silva · sopra soglia · registrata con autore e orario
  • Aliquota IVA bloccata · IVA 23% salvata sulla riga
    Rinominare l'aliquota nel catalogo in seguito non cambierà questa riga
  • Cambio registrato all'inserimento · $500 → €462,18 @ 0,9244
    Salvato sul record, mai ricalcolato al momento del report
  • Ruolo modificato · M. Lopes → Amministrazione
    Claim riemesso lato server; vale dal prossimo aggiornamento del token
Due diligence

Cosa possiamo mettere per iscritto.

La versione onesta di una pagina sulla sicurezza: cosa è implementato oggi e dove puoi verificarlo da solo. Quando qualcosa non c'è, lo diciamo chiaramente.

AmbitoStato attualeCome verificarlo
Localizzazione dei datiFirebase (Google Cloud), europe-west1, Belgio. Solo UE per impostazione predefinita.Indicato nella nostra informativa sulla privacy, con l'elenco dei sub-responsabili.
GDPRSono supportate le richieste di accesso, rettifica, cancellazione e portabilità.Informativa sulla privacy; scrivici per esercitare un diritto.
Dati delle carteCashbox non conserva mai i dati delle carte. Stripe gestisce i dati di pagamento nel proprio ambiente conforme PCI.Stripe è indicato come sub-responsabile.
Isolamento tra organizzazioniSeparazione per organizzazione imposta dalle regole di sicurezza di Firestore su un claim emesso lato server.Le regole sono coperte da una suite di test automatici nel repository.
Audit trailLe modifiche finanziarie vengono registrate con autore e orario, scritte lato server.Visibile nel prodotto, nello storico di ogni evento.
Accordo sul trattamento dei datiDisponibile su richiesta; DPA personalizzato con il piano Enterprise.Contattaci e ti mandiamo l'accordo in vigore.
Certificazione formaleAl momento Cashbox non è certificato SOC 2 né ISO 27001. Non diremo il contrario.Chiedici direttamente dei piani e dei tempi attuali.
Buone pratiche

Come lo configurano i team di eventi.

Accessi e permessi

Solo i titolari accedono alla fatturazione. Titolari e direzione possono invitare. Dai al resto del team di produzione il ruolo di responsabile evento e al tuo commercialista il ruolo amministrazione.

Controllo delle approvazioni

Imposta la soglia sull'importo che vorresti vedere prima che venga speso. Tutto ciò che è pari o inferiore viene approvato all'invio; ciò che la supera aspetta un revisore.

Documenti allegati ai record

Allega la fattura alla spesa quando la registri. Resta sul record, dietro lo stesso controllo di organizzazione di tutto il resto, così la chiusura non diventa una ricerca tra le email.

Verificabilità in chiusura

Esporta dagli stessi record da cui sono passate le approvazioni. Il tuo commercialista riceve i numeri dell'evento con lo storico dietro, non un foglio ribattuto a mano.

Ti serve il DPA, o vuoi vedere più da vicino?

Chiedi e ti mandiamo l'accordo sul trattamento dei dati in vigore, l'elenco dei sub-responsabili o una presentazione di come sono configurati ruoli e approvazioni.