Panoramica sulla sicurezza

Le app Bobuild sono sicure quanto i confini che configuri: chi può aprire il Builder, chi può entrare in ogni portale, cosa mostra ogni Widget e cosa consente ogni endpoint API. Questa pagina è la mappa; i dettagli sono nelle guide collegate.

Livelli di accesso

Builder collaborators  →  change structure and see raw data
        ↓
App portals + login    →  end users work through pages you design
        ↓
Widget visibility      →  hide actions and fields per role / status
        ↓
API endpoint auth      →  external systems get a deliberate slice of data

1. Builder

Considera gli accessi al Builder come accesso amministratore. Limita i collaborator. Non condividere le password del Builder con persone che devono solo gestire ticket.

2. Portali e login rule

Ogni pagina di primo livello può usare un oggetto utente diverso e login rule diverse (Active, ruoli, status). Divisione tipica:

• portale pubblico — nessun login;
• portale cliente / candidato — oggetto customer;
• backoffice — oggetto operator con tag di ruolo.

3. Display rule e menu

Anche all'interno di un portale, le display rule e la visibilità del menu dovrebbero nascondere le azioni riservate allo staff. Difesa a strati: login rule e regole UI.

4. API

Definisci gli endpoint in modo esplicito: campi, filtri e autenticazione. Non esporre mai note interne o campi password. Opzionalmente limita ogni endpoint agli IP di origine consentiti (indirizzi o range CIDR) così una chiave esposta non basta da una rete imprevista. Vedi API.

5. Agent AI (MCP)

I token agent sul Builder possono modificare la struttura dell'app e opzionalmente i dati record via SQL. Tratta i grant come accesso amministratore per le app elencate: minimo di app, minimo di permessi, revoca quando non servono. Preferisci app di sviluppo e Deployment per la produzione.

Pattern di permessi consigliati

Pattern	Come
Staff vs pubblico	Portali separati; solo il backoffice ha login Operator
Tag di ruolo	Multiple choice roles su Operator + login rule + regole menu
Gate di approvazione	La self-registration crea Active = false; lo staff approva prima che il login funzioni
Proprietà del record	Griglie del portale cliente filtrate sull'utente autenticato
Azioni batch pericolose	Task di griglia solo su pagine staff; nascoste per ruoli read-only

File e documenti

• I campi file e immagine sono raggiungibili dagli utenti che possono aprire il record tramite una pagina o API che hai esposto.
• Preferisci layout detail riservati allo staff per allegati sensibili (contratti, documenti d'identità).
• Le Task possono memorizzare un hash SHA-256 di un file per controlli di integrità (Operazioni sui record).
• Gli Snapshot possono includere file caricati — controlla chi può ripristinare e chi riceve app clonate (Snapshot).

Snapshot e Deployment

Meccanismo	Protegge	Non
Snapshot	Struttura point-in-time ± dati che puoi ripristinare in una app nuova	Da solo impedisce a chi ha accesso al Builder di modificare il live
Deployment	Promozione controllata della configurazione; Snapshot automatico del target prima dell'applicazione	Sovrascrivere o "correggere" dati record errati (i dati non vengono deployati)

Le app ripristinate disabilitano l'e-mail in uscita finché non la riabiliti — importante così i cloni non inviano e-mail a utenti reali.

Cloud vs Enterprise (aspetti di sicurezza)

• Custom domains — coordinate su Cloud; configurabili in Settings su Enterprise (Custom domains).
• SSO / SPID / CIE — disponibili per piano; le configurazioni enterprise spesso collegano gli IdP dell'organizzazione (Login).
• Conferma sempre la residenza dei dati e i termini contrattuali con Bobuild per carichi di lavoro regolamentati — la documentazione descrive i controlli del prodotto, non la tua attestazione di conformità.

Checklist prima del go-live

• Collaborator del Builder verificati
• Oggetto login e regole di ogni portale testati con un utente reale
• Campi cliente/staff separati nei layout
• Endpoint API verificati per perdite di campi e allowlist IP di origine dove appropriato
• Token agent del Builder verificati (app, scrittura structure/data, scadenza)
• Template e-mail in uscita puntano al pubblico giusto
• Snapshot effettuato; percorso staging→prod concordato (Production playbook)