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.

Example

How to configure it in the builder

How it looks like in the resulting app

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 chi può accedere al Builder. 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

• Accessi al 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)