Sicurezza avanzata Odoo: RBAC, multi-company, SoD, GDPR (guida PMI italiane)

Trentanovesima guida operativa Odoo 19 per PMI italiane. In un’azienda con 30+ utenti, dare a tutti “accesso a tutto” è il modo più veloce per: (1) violare il GDPR, (2) creare confusione operativa, (3) esporre dati sensibili ai concorrenti se un dipendente lascia l’azienda. RBAC (Role-Based Access Control) e multi-company permissions sono i due strumenti che permettono a una PMI Italiana di crescere mantenendo controllo, compliance e segregazione delle responsabilità. In questa guida vediamo come progettarli concretamente.

Vediamo: modello di sicurezza Odoo (groups, ACL, record rules), gerarchia ruoli, multi-company con permessi cross-azienda, segregation of duties, audit log, compliance GDPR/ISO, errori comuni, casi pratici PMI italiane.

Il modello di sicurezza Odoo: 3 livelli

Livello 1: Groups (gruppi sicurezza)

• Definiscono chi fa parte di un ruolo (es. “Sales User”, “Accounting Manager”)
• Gerarchia di ereditarietà: Manager eredita da User
• Visibilità menu, action, feature dipende dal gruppo
• Best practice: 1 gruppo per area funzionale × 2 livelli (User + Manager)

Livello 2: ACL (Access Control List)

• Definiscono operazioni CRUD permesse per modello × gruppo
• Read / Create / Write / Delete
• Default: Sales User ha read+create+write su crm.lead, NO delete
• Cap a livello modello, non a livello record

Livello 3: Record Rules

• Definiscono QUALI record dentro un modello sono visibili al gruppo
• Filtri dinamici con domain Python
• Esempio: Sales User vede solo opportunità di cui è owner
• Esempio: Accounting Manager vede solo fatture della propria company

Gerarchia ruoli tipica per PMI

Gruppi base per area

I gruppi sicurezza Odoo sono il cuore del modello RBAC. Una gerarchia chiara permette di scalare l’organizzazione mantenendo controllo:

• Vendite: Sales User (vendor base) + Sales Manager (vede tutto)
• Acquisti: Purchase User + Purchase Manager
• Magazzino: Stock User + Stock Manager
• Contabilità: Accounting User (registrazioni) + Accounting Manager (chiusure)
• HR: HR User (proprio profilo) + HR Manager (tutti) + Payroll Officer (paghe)
• IT: Settings (configurazione) + Developer (Studio + tecnico) + System Admin

Gruppi trasversali

• Project Sponsor: vista executive su tutti i moduli (read-only)
• Auditor: read-only per audit interno/esterno
• Portal: clienti/fornitori esterni con accesso limitato

Multi-company: organizzazioni con più aziende

Quando attivare multi-company

L’opzione multi-company di Odoo è potente ma complessa. Va attivata SOLO quando necessario, perché aumenta significativamente la complessità di setup e mantenimento:

• Holding con 2+ società operative
• Gruppi con società commerciale + produttiva
• Espansione internazionale (società estera)
• Spin-off di business unit
• Acquisizione mantenendo brand separati

Cosa è separato per company

• Conti contabili (piano dei conti per azienda)
• Sequenze documentali (fatture, ordini)
• Listini prezzi e clienti
• Fiscalità (regimi IVA, P.IVA diverse)
• Magazzini fisici
• Reportistica finanziaria

Cosa è condiviso

• Anagrafica prodotti (opzionale per company)
• Contatti (clienti/fornitori — opzionale)
• Utenti (accesso multi-company configurabile)
• Configurazioni Studio
• Reportistica consolidata

User permission multi-company

• Allowed companies: lista aziende a cui l’utente ha accesso
• Default company: azienda di default al login
• Company switcher in topbar per cambiare contesto
• Record rules automatiche basate su current company

Record rules: il vero potere di Odoo

Esempi pratici PMI

Le record rules sono regole dinamiche che filtrano i record visibili a livello utente. Sono il meccanismo che permette segregazione granulare dei dati:

Esempi tipici PMI italiane

• Agente vendite: vede solo opportunità di sua zona geografica (domain su partner_id.state_id)
• Branch manager: vede solo fatture della propria filiale (domain su warehouse_id)
• HR manager filiale: vede solo dipendenti della propria filiale
• Salary officer: vede solo stipendi sotto livello manageriale
• Portale cliente: vede solo i propri ordini/fatture

Domain Python esempi

# Sales user vede solo opportunità sue
[('user_id', '=', user.id)]

# Sales manager vede team
[('user_id.team_id', '=', user.team_id.id)]

# Accounting user vede solo registrazioni non chiuse
[('move_id.state', '!=', 'posted')]

# HR vede solo dipendenti del proprio reparto
[('department_id', 'in', user.employee_id.department_id.ids)]

Segregation of Duties (SoD)

Principio

Una stessa persona non deve poter completare un’intera transazione critica (es. creare fornitore + creare fattura + autorizzare pagamento + eseguire bonifico). Diversi step = diverse persone.

Aree critiche di SoD per PMI

• Acquisti: chi crea RDA ≠ chi approva ordine ≠ chi riceve merce ≠ chi paga fattura
• Vendite: chi gestisce CRM ≠ chi crea fattura ≠ chi gestisce sconti
• Magazzino: chi gestisce inventario ≠ chi rettifica giacenze ≠ chi audita
• Contabilità: chi registra ≠ chi riconcilia banca ≠ chi chiude esercizio
• HR/Payroll: chi inserisce dipendente ≠ chi calcola paga ≠ chi paga

Implementazione in Odoo

• Workflow approval Studio per ogni step critico
• Gruppi distinti per ruolo (no accumulo permessi)
• Audit log per tracciare chi fa cosa
• Review periodica permessi (trimestrale)

Compliance GDPR

Right to access

• Cliente può richiedere tutti i suoi dati: estraibili via API Odoo
• Implementazione: report custom per dump dati per res.partner
• Tempo risposta: 30 giorni massimo per legge

Right to erasure (oblio)

• Cancellazione dati personali su richiesta
• Eccezioni: obblighi legali (es. fatture 10 anni)
• Anonymization preferibile a deletion (preserva integrità contabile)

Right to portability

• Export dati in formato strutturato (CSV, JSON)
• Trasferimento a sistema terzo

Consent management

• Tracciamento consensi marketing per contatto
• Campi custom su res.partner per ogni tipologia consenso
• Date e fonte consenso documentata
• Workflow opt-in/opt-out automatizzato

Audit log: chi ha fatto cosa quando

Audit log nativo Odoo

• mail.thread traccia tutti i cambiamenti significativi
• Chatter su ogni record con storico modifiche
• Log automatico su create, write, unlink

Audit log esteso (modulo audit_log)

• Tracciamento granulare di ogni modifica
• Storico campi modificati con valore precedente
• Reportistica per audit esterni
• Performance: attenzione overhead su modelli ad alto volume

Cosa loggare

• Login/logout utenti
• Modifiche permessi (assegnazione gruppi)
• Cancellazione record critici
• Export dati massivi
• Accessi API esterne

Strong authentication e 2FA

2FA (Two-Factor Authentication)

• Modulo nativo auth_totp
• App authenticator (Google Authenticator, Microsoft, Authy)
• Backup codes per recovery
• Enforcement per ruoli critici (admin, accounting manager)

SSO (Single Sign-On)

• Integrazione con Azure AD, Google Workspace, Okta
• Modulo auth_oauth e auth_signup
• Centralizzazione policy password e MFA
• De-provisioning automatico quando utente lascia azienda

Password policy

• Minimum length (12+ caratteri)
• Complessità (numeri, simboli)
• Rotazione obbligatoria (90 giorni per ruoli critici)
• Lockout dopo N tentativi falliti
• Blocco password riutilizzate

Errori comuni nella sicurezza Odoo

“Admin per tutto”

Problema: 5+ utenti con gruppo Administrator. Ogni azione è “Admin x ha fatto y”.
Soluzione: 1-2 Administrator reali (IT). Altri ruoli a permessi specifici. Audit trail meaningful.

“Eccessiva customization gruppi”

Problema: 47 gruppi custom creati per casi edge.
Soluzione: max 15-20 gruppi attivi. Usa record rules per granularità entro gruppo.

“Permission creep”

Problema: utenti accumulano permessi nel tempo, dopo 2 anni hanno accesso a 80% del sistema.
Soluzione: review trimestrale permessi, principio “least privilege”.

“De-provisioning carente”

Problema: dipendente lascia azienda, account attivo per mesi.
Soluzione: process formale offboarding entro 24h, integrazione con HR/SSO.

“Multi-company senza training”

Problema: utente confuso passa da company A a B, registra fattura su azienda sbagliata.
Soluzione: training dedicato multi-company, company indicator visibile in topbar.

Casi pratici PMI italiane

Caso 1 — Holding con 3 società operative

• Multi-company: SpA holding + 2 SRL operative
• Setup gruppi: comune + 3 per company-specific
• 15 utenti totali, 3 cross-company (direzione)
• Effort setup RBAC: 25 ore consulente, 4k €
• Risultato: separazione dati pulita, reportistica consolidata corretta

Caso 2 — PMI singola con segregation of duties

• 22 utenti, ISO 27001 in corso certificazione
• 18 gruppi sicurezza dettagliati
• Workflow approval 3 livelli per acquisti
• Audit log esteso attivo
• Effort: 35 ore consulente, 5.5k €
• Risultato: certificazione ISO ottenuta al primo audit

Caso 3 — Retail multi-store con permessi geografici

• 5 punti vendita, store manager solo per propria store
• Record rules su warehouse_id
• Direzione vede tutto, store manager solo proprio
• Effort: 18 ore consulente, 2.5k €
• Risultato: store manager autonomi, no fughe dati intra-store

Caso 4 — Servizi B2B con SSO Azure AD

• 28 utenti, SSO con Azure AD aziendale
• 2FA obbligatorio per ruoli accounting + admin
• De-provisioning automatico via SCIM
• Effort: 45 ore consulente, 7k €
• Risultato: zero account orfani dopo offboarding

FAQ

Quanti gruppi sicurezza dovrei creare?

Regola pratica: numero dipendenti / 3-5 = numero gruppi sicurezza ragionevole. Per 30 utenti: 6-10 gruppi è il sweet spot. Sotto: troppo permissivo. Sopra: complessità ingestibile.

Devo attivare multi-company se ho un solo P.IVA?

No, multi-company aggiunge complessità senza benefici per singola entità legale. Eccezioni: vuoi simulare branch separati con regimi IVA diversi, gestione consolidata futura, scissione pianificata.

2FA è obbligatorio per la mia PMI?

Non obbligatorio per legge italiana (eccezioni: settori regolati come banche, sanità). Fortemente raccomandato per: amministrazione, IT, executive. Costo zero (modulo nativo gratis), beneficio massimo.

Come gestisco l’audit trimestrale dei permessi?

Process: (1) export utenti × gruppi via API; (2) review con manager per ogni reparto; (3) rimozione permessi non più necessari; (4) documentazione cambiamenti. Effort: 8-16 ore per ciclo trimestrale.

Cosa fare se un utente accidentalmente cancella dati critici?

Prevenzione: rimuovere permesso “delete” da ruoli operativi (solo “archive”). Recovery: backup giornaliero permette restore. Forensic: audit log tracciare cosa è stato cancellato. Training: comunicare differenza archive vs delete.

Prossimi passi

Nelle prossime guide vedremo come preparare il sistema per audit esterni (revisori, ISO 27001, SOC 2), come ottimizzare le performance Odoo su volumi alti, e come gestire backup e disaster recovery in ottica business continuity.

Vuoi un setup RBAC granulare per la tua PMI?
G Tech Group progetta architetture sicurezza Odoo per PMI italiane: gruppi, ACL, record rules, multi-company, SSO, 2FA, audit log. Conformità GDPR e supporto certificazioni ISO 27001 / SOC 2.
Richiedi un preventivo gratuito oppure prova la nostra demo Odoo 19 live. Oppure prova Odoo direttamente su odoo.com (link partner Brentasoft).