CSA STAR Livello 1

Odoo partecipa al programma STAR di CSA per garantire un ambiente di cloud più sicuro.
Vedi le nostre risposte al questionario CAIQv3.1

— Odoo Cloud (la piattaforma) —

Backup/Ripristino di emergenza

  • Conserviamo 14 backup completi per ogni database creato su Odoo fino a 3 mesi: 1 al giorno per 7 giorni, 1 a settimana per 4 settimane, 1 al mese per 3 mesi.
  • I backup sono riprodotti in almeno 3 centri dati diversi, in almeno 2 continenti.
  • Le ubicazioni attuali dei nostri centri dati sono specificate nella Informativa sulla privacy.
  • Utilizzando il pannello di controllo puoi anche scaricare backup manuali dei tuoi dati correnti, in qualsiasi momento.
  • Puoi contattare l'Helpdesk per ripristinare qualsiasi backup del tuo database attivo (o di un altro).
  • Failover dell'hardware: per i servizi ospitati su un bare metal, dove è possibile il verificarsi di un errore hardware, realizziamo una replica locale in hotstandby attraverso il monitoraggio e una procedura manuale per il failover per la quale servono meno di 5 minuti.
  • Ripristino di emergenza: in caso di emergenza, con un centro dati completamente fuori uso per un lungo periodo di tempo, impedire il failover nei nostri hotstanby locali (non è mai successo, si tratta dello scenario peggiore) abbiamo i seguenti obiettivi:
    • RPO (Obiettivo punto di ripristino)=24 ore. Significa che puoi perdere un massimo di 24 ore di lavoro se i dati non possono essere recuperati e se abbiamo bisogno di ripristinare il tuo ultimo backup giornaliero.
    • RTO (Obiettivo tempo di ripristino)=24 ore per gli abbonamenti a pagamento, 48 ore per le prove gratuite, offerta formativa, utenti freemium, ecc. Se si verifica un disastro e uno dei centri dati è completamente fuori uso, bisognerà ripristinare il servizio in un centro diverso.
    • In che modo è possibile: monitoriamo attivamente i nostri backup giornalieri che vengono replicati in diverse posizioni e in vari continenti. Abbiamo automatizzato il provisioning per dislocare i nostri servizi in un nuovo percorso di hosting. Il ripristino dei dati in base ai backup dei giorni precedenti può essere fatto in poche ore (per i cluster più grandi) con priorità per gli abbonamenti a pagamento.
      Utilizziamo regolarmente sia backup giornalieri che gli script di provisioning per le operazioni di tutti i giorni quindi entrambe le parti della procedura di ripristino di emergenza vengono sempre testate.

Sicurezza dei database

  • I dati dei clienti sono archiviati in uno specifico database, non vengono condivisi dati tra i clienti.
  • Le regole di controllo per l'accesso ai dati rendono completa la separazione tra i database dei clienti che utilizzano lo stesso cluster. Non è possibile accedere da un database ad un altro.

Sicurezza della password

  • Le password dei clienti sono protette da crittografia standard conforme alle norme del settore PBKDF2+SHA512 (rese più appetibili e più lunghe attraverso più tentativi).
  • Lo staff di Odoo non ha accesso alla tua password e non può recuperarla per te. Nel caso in cui tu la perda l'unica soluzione è ripristinarla.
  • Le credenziali di accesso vengono sempre trasmesse in maniera sicura sugli HTTP.
  • A partire da Odoo 12.0, anche gli amministratori dei database dei clienti hanno la possibilità di  configurare la limitazione della velocità e prolungare il tempo di attesa nel caso di tentativi di login ripetuti.
  • Politiche sulle password: a partire da Odoo 12.0 gli amministratori dei database hanno un'impostazione predefinita per far rispettare il requisito relativo alla lunghezza minima della password. Per le versioni precedenti è possibile sbloccare la stessa funzione attraverso la personalizzazione. Altre politiche come leclassi di caratteri richiesti non sono supportate di default perché considerate controproducenti. Vedi ad esempio [Shay et al. 2016]).

Accesso dello staff

  • Lo staff dell'helpdesk di Odoo può accedere al tuo account per verificare le impostazioni relative al problema da te segnalato. Per fare ciò, utilizzano le proprie credenziali speciali e non la tua password (delle quale non possono essere in alcun modo a conoscenza).
  • L'accesso speciale dello staff migliora l'efficienza e la sicurezza: possono riprodurre immediatamente il problema da te segnalato, senza il bisogno di condividere la tua password personale e possiamo verificare e controllare le operazioni dello staff separatamente!
  • Lo staff del nostro Helpdesk si impegna al massimo per rispettare la tua privacy ed esegue l'accesso solo ai file e alle impostazioni richieste per diagnosticare e risolvere la tua problematica.

Sicurezza del sistema

  • Tutti i server cloud di Odoo eseguono distribuzioni Linux con protezione avanzata con patch di sicurezza aggiornate.
  • Le installazioni sono ad hoc e minime per limitare il numero di servizi che potrebbero contenere delle vulnerabilità (ad esempio, nessuno stack PHP/MySQL).
  • Solamente pochi ingegneri Odoo fidati hanno l'autorizzazione per gestire da remoto i server e l'accesso è possibile solamente utilizzando una chiave personale di tipo SSH crittografata da un computer dotato di crittografia del disco.

Sicurezza materiale

I server di Odoo cloud sono ospitati in centri dati fidati in varie regioni del mondo (ad esempio, OVH, Google Cloud) e tutti devono rispettare i nostri criteri di sicurezza materiale:

  • Perimetro ristretto, accessibile esclusivamente dai dipendenti autorizzati dei centri dati.
  • Controllo dell'accesso con badge di sicurezza o dispositivi biometrici
  • Telecamere di sicurezza per i centri dati 24/7
  • Personale di sicurezza sul posto 24/7.

Sicurezza carta di credito

  • Non conserviamo mai sui nostri sistemi le informazioni relative alle carte di credito.
  • Le informazioni relative alla tua carta di credito sono sempre condivise in maniera diretta e sicura tra te e i nostri acquirer di pagamenti conformi al PCI(consulta la lista sulla nostra pagina Informativa sulla privacy ).

Crittografia dei dati

I dati dei clienti sono sempre trasferiti e archiviati in moduli crittografati (crittografia in transito e a riposo).
  • Tutte le comunicazioni di dati alle istanze dei clienti sono protette da crittografia all'avanguardia 256-bit SSL (HTTPS).
  • Tutte le comunicazioni interne di dati tra i nostri server sono protette da crittografia di ultima generazione (SSH).
  • I nostri server sono sorvegliati in maniera rigidissima per garantirne la sicurezza e le patch vengono continuamente aggiornate contro le ultime vulnerabilità di SSL, beneficiando di Grado A valutazioni SSL in ogni momento.
  • Tutti i nostri certificati utilizzano moduli solidi di tipo 2048-bit con certificati SHA-2.
  • Tutti i dati dei clienti (contenuto dei database e file archiviati) sono crittografati a riposo, sia durante la produzione che nei backup (AES-128 o AES-256)

Difesa della rete

  • Tutti i fornitori di centri dati utilizzati da Odoo Cloud hanno capacità di rete molto ampie oltre ad un'infrastruttura progettata per sostenere gli attacchi più grandi di tipo DDoS. I sistemi di mitigazione automatica e manuale posso rilevare e deviare il traffico degli attacchi ai margini delle loro reti multicontinentali prima che abbia la possibilità di compromettere la disponibilità del servizio.
  • I firewall e i sistemi di prevenzione delle intrusioni sui server di Odoo aiutano a rilevare e bloccare minacce come attacchi di forza bruta alle password.
  • A partire da Odoo 12.0, anche gli amministratori dei database dei clienti hanno la possibilità di configurare la limitazione della velocità e prolungare il tempo di attesa nel caso di tentativi di login ripetuti.

— Odoo (il software) —

Sicurezza del software

Odoo è un software open source quindi l'intera base di codici viene continuamente esaminata dagli utenti e dai collaboratori di Odoo in tutto il mondo. I report sui bug della community sono un'importante fonte di feedback sulla sicurezza. Incoraggiamo gli sviluppatori a verificare i problemi relativi al codice e alla sicurezza.

I processi di R&S di Odoo constano di step di revisone del codice che includono gli aspetti relativi alla sicurezza anche per le nuove parti di codice.

Sicurezza da progettazione

Odoo è progettato in modo da prevenire l'introduzione delle vulnerabilità di sicurezza più comuni:

  • Le injection SQL sono prevenute attraverso l'utilizzo di un API di alto livello che non richiede delle query SQL manuali.
  • Gli attacchi XSS sono prevenuti attraverso l'utilizzo di un sistema di modellazione di alto livello che evita automaticamente i dati contaminati.
  • Il framework prevede l'accesso RPC a metodi privati rendendo più difficile l'introduzione di vulnerabilità sfruttabili.

Consulta la sezione Principali vulnerabilità OWASP per vedere in che modo Odoo è progettato da cima a fondo per prevenire il verificarsi di tali vulnerabilità.

Controlli di sicurezza indipendenti

Odoo viene regolarmente controllato da aziende indipendenti che vengono assunte dai nostri clienti, esistenti e potenziali per effettuare test degli audit e di penetrazione. Il team di sicurezza di Odoo riceve i risultati e adotta le misure di correzione idonee se necessario.

Tuttavia, non possiamo divulgare nessun risultato perché confidenziali e di proprietà dei committenti. Per favore, non chiedete nulla ;-)

Inoltre, Odoo ha una community molto attiva di ricercatori di sicurezza indipendenti che monitorano in continuazione il codice sorgente e lavorano con noi per migliorare e rafforzare la sicurezza di Odoo. Il Programma di sicurezza è descritto alla pagina Divulgazione responsabile .

Principali vulnerabilità OWASP

Ecco come si colloca Odoo rispetto ai principali problemi di sicurezza per le applicazioni web, secondo l'elenco stilato da Open Web Application Security Project (OWASP):

  • Difetti di injection: i difetti di injection, in particolare quelle di tipo SQL, sono comuni nelle applicazioni web. Le injection si verificano quando i dati forniti dagli utenti vengono inviati ad un interprete come parte di un comando o di una query. I dati ostili dell'autore dell'attacco ingannano l'interprete nell'eseguire comandi indesiderati o nel cambiare i dati.

    Odoo si affida a un framework ORM che ricava la costruzione delle query e previene automaticamente le injection SQL. Gli sviluppatori normalmente non realizzano le query SQL manualmente dato che sono generate dall'ORM e i parametri vengono sempre evitati adeguatamente.

  • Scripting intersito (XSS): i difetti di tipo XSS si verificano quando un'applicazione prende i dati forniti da un utente e li invia ad un browser web senza aver prima verificato o codificato il contenuto. Lo scripting intersito permette agli autori di attacchi informatici di eseguire script nel browser della vittima e può assumere il controllo delle sessioni dell'utente, sabotare siti web, introdurre potenzialmente dei worm, ecc.

    Il framework Odoo esegue l'escape di tutte le espressioni rese nelle viste e nelle pagine per impostazione predefinita, impedendo così gli XSS. Gli sviluppatori devono contrassegnare appositamente le espressioni come "sicure" per l'inclusione nelle pagine visualizzate.

  • Richiesta intersito falsa (CSRF): un attacco CSRF impone al browser di una vittima collegata di inviare una richiesta di HTTP falsificata verso un'app web vulnerabile, includendo i cookie della sessione e ogni altra informazione relativa all'autenticazione. Questo consente all'autore dell'attacco di forzare il browser della vittima per generare richieste che sembrano essere leggittime.

    Il motore del sito web di Odoo include un meccanismo integrato di protezione da attacchi CSRF. Infatti, impedisce a qualsiasi controller HTTP di ricevere una richiesta POST senza il token di sicurezza corrispondente. Questa è la tecnica consigliata per la prevenzione da CSRF. Il token di sicurezza è noto e presente solo quando l'utente accede effettivamente al modulo del sito web in questione e l'autore di un attacco non può falsificare una richiesta senza di esso.

  • Esecuzione malware: i codici vulnerabili a RFI (Remote FIle Inclusion) permettono agli autori di un attacco di includere dati e codici ostili che sfociano in attacchi devastanti come la compromissione totale del server.

    Odoo non presenta funzioni per eseguire l'inclusione di file remoti. Tuttavia, consente agli utenti privilegiati di personalizzare le funzioni aggiungendo espressioni ad hoc che saranno valutate dal sistema. Queste espressioni sono sempre valutate da un ambiente sandbox, puro, che consente l'accesso solo alle funzioni consentite.

  • RIferimento oggetto diretto non sicuro: tale fenomeno si verifica quando uno sviluppatore espone riferimenti ad un oggetto di implementazione interno tra cui un file, una directory, record del database o una chiave come URL o parametro modulo. Gli autori di un attacco possono manipolare questi riferimenti per accedere ad altri oggetti senza autorizzazione.

    Il controllo di accesso a Odoo non è implementato a livello dell'interfaccia utente quindi non c'è alcun rischio nell'esporre riferimenti a oggetti interni negli URL. Gli autori di un attacco non possono aggirare il livello di controllo degli accessi manipolando tali riferimenti, perché ogni richiesta deve comunque passare attraverso il livello di convalida dell'accesso ai dati.

  • Archiviazione crittografica non sicura: le applicazioni web utilizzano raramente funzionalità di crittografia in maniera appropriata per proteggere dati e credenziali. Gli autori dell'attacco utilizzano dati poco protetti per rubare identità o mettere a punto altri crimini come frodi con carte di credito.

    Odoo utilizza il metodo crittografico hash standard comune per le password degli utenti (per impostazione predefinita PKFDB2 + SHA-512, con adattamento della chiave) per proteggere le password memorizzate. È anche possibile utilizzare sistemi di autenticazione esterni come OAuth 2.0 o LDAP, per evitare di memorizzare le password degli utenti a livello locale.

  • Comunicazioni non sicure: le applicazioni spesso non riescono a crittografare il traffico di rete quando è necessario proteggere comunicazioni sensibili.

    Odoo Cloud funziona su HTTP da impostazione predefinita. Per le installazioni in loco è raccomandabile eseguire Odoo tramite un server web che implementa la crittografia e invia la richiesta a Odoo stesso, ad esempio Apache, Lighttpd o nginx. La guida di implementazione di Odoo include una lista di sicurezza per implementazioni pubbliche più sicure.

  • Limitazione dell'accesso agli URL non riuscita: spesso un'applicazione protegge esclusivamente le funzioni sensibili impedendo la visualizzazione di link o URL agli utenti non autorizzati. Gli autori di un attacco possono usare questa debolezza per accedere ed eseguire operazioni non autorizzate utilizzando in maniera diretta gli URL.

    Il controllo degli accessi di Odoo non è implementato a livello di interfaccia utente e la sicurezza non si basa sul nascondere URL speciali. Gli autori di un attacco non possono aggirare il livello di controllo degli accessi riutilizzando o manipolando qualsiasi URL, perché ogni richiesta deve comunque passare attraverso il livello di convalida. Nei rari casi in cui un URL fornisce un accesso non autenticato a dati sensibili, come ad esempio gli URL speciali utilizzati dai clienti per confermare un ordine, questi URL vengono firmati digitalmente con token unici e inviati via e-mail solo al destinatario previsto.

Segnalare vulnerabilità di protezione

Se hai bisogno di segnalare una vulnerabilità di protezione consulta la nostra pagina divulgazione responsabile.. Le segnalazioni sono trattate con la massima priorità, il problema viene esaminato e risolto dal team sicurezza di Odoo, in collaborazione con la persona che ha segnalato il problema per poi essere comunicato adeguatamente agli utenti e ai clienti di Odoo.