Odoo Security


— Odoo Cloud (the platform) —

Copia de Seguridad / Recuperación de Desastres

  • Guardamos 14 copias de seguridad completas de cada instancia de Odoo durante 3 meses: 1/día durante 7 días, 1/semana durante 4 semanas, 1/mes durante 3 meses.
  • Las copias de seguridad se replican en al menos 3 centros de datos diferentes en diferentes continentes.
  • The actual locations of our data centers are specified in our Privacy Policy.
  • También puedes descargar copias de seguridad manuales de tus datos a tiempo real usando el panel de control de Odoo Online.
  • Puedes consultar con nuestro Centro de Soporte para restaurar cualquiera de estas copias de seguridad en tu base de datos activa (o a un lado).
  • Conmutación del Hardware: para servicios alojados en metal expuesto, donde fallos en el hardware son posibles, implementamos una réplica del sistema de espera activa local con monitoreo y un proceso manual de conmutación que tarda menos de 5 minutos.
  • Recuperación de desastres: en caso de desastre completo, con un centro de datos completamente inactivo durante un largo periodo de tiempo, previniendo conmutación a nuestro sistema de espera activa (por el momento nunca ha pasado, pero este es el plan para el peor de los casos), tenemos los siguientes objetivos:
    • RPO (Objetivo de Punto de Recuperación) = 24h. Esto significa que puedes perder un máximo de 24h de trabajo si los datos no se pueden recuperar y necesitamos restaurar tu última copia de seguridad.
    • RTO (Tiempo de Recuperación del Objetivo) = 8h para suscripciones de pago, 48h para pruebas gratuítas, ofertas de educación, usuarios freemium, etc. Este es el tiempo para restaurar el servicio en un centro de datos diferente si ocurre un desastre y el centro de datos está completamente inactivo.
    • Cómo se logra esto: monitoreamos activamente nuestras copias de seguridad, y son replicadas en múltiples ubicaciones en diferentes continentes. Tenemos provisionamiento automatizado para deployar nuestros servicios en una nueva ubicación de almacenaje en menos de 30 minutos. Restaurar los datos basados en nuestras copias de seguridad  del día anterior puede ser realizado en un par de horas con prioridad en las suscripciones de pago.
      Usamos las copias de seguridad diarias y el provisionamiento de scripts para operaciones diarias, así que ambas partes del procedimiento de recuperación de desastre se testea en todo momento.

Seguridad de Bases de Datos

  • Los datos de los clientes se almacenan en una base de datos dedicada - no se comparten los datos entre clientes.
  • Las reglas de control de acceso de datos implementan aislamiento completo entre las bases de datos de los clientes corriendo en el mismo conjunto, no se permite el acceso de una base de datos a otra. 

Seguridad de Contraseñas

  • Customer passwords are protected with industry-standard PBKDF2+SHA512 encryption (salted + stretched for thousands of rounds).
  • Los empleados de Odoo no tienen acceso a tu contraseña, y no la pueden recuperar por ti. La única opción si la pierdes es resetearla.
  • Las credenciales de inicio siempre se transmited de manera segura a través de HTTPS.
  • As of Odoo 12.0, customer database administrators even have the option to configure the rate limiting and cooldown duration for repeated login attempts.
  • Password policies: as of Odoo 12 database administrators have a built-in setting for enforcing a minimum user password length. For older versions it is possible to achieve the same effect through customization. Other password policies like required character classes are not supported by default because they have been proven counter-productive - see e.g. [Shay et al. 2016]).

Acceso a Empleados

  • Los empleados del Centro de Soporte de Odoo pueden entrar a tu cuenta para acceder a la configuración relacionada con tu ticket de soporte. Para hacer esto usan sus propias credenciales de empleados, no tu contraseña (que no tienen forma de saber).
  • Este acceso especial de los empleados mejora la eficiencia y seguridad: pueden reproducir de inmediato los problemas que estás teniendo. En ningún caso necesitas compartir tu contraseña, y podemos auditar y controlar las acciones de los empleados de manera independiente. 
  • Nuestro Centro de Soporte trabaja para respetar tu privacidad en todo momento, y solo accede a archivos y configuraciones que necesitan para diagnosticar y resolver tu problema.

Seguridad del Sistema

  • All Odoo Cloud servers are running hardened Linux distributions with up-to-date security patches.
  • Las instalaciones son a medida y mínimas para limitar el número de servicios que puedan contener vulnerabilidades (no PHP/MySQL stack por ejemplo).
  • Only a few trusted Odoo engineers have clearance to remotely manage the servers - and access is only possible using an encrypted personal SSH keypair, from a computer with full-disk encryption.

Seguridad Física

Los servidores de Odoo Online están alojados en centros de datos de confianza en varias regiones del mundo (p.e OVH, Google Cloud), y todos deben seguir nuestro criterio de seguridad física:

  • Perímetro restringido, accesible físicamente por empleados autorizados de los centros de datos únicamente.
  • Control del acceso físico con tarjetas de seguridad o seguridad biométrica.
  • Cámaras de seguridad monitoreando los centros de datos 24/7
  • Personal de seguridad en el lugar 24/7

Seguridad de Tarjetas de Crédito

  • We never store credit card information on our own systems.
  • La información de tu tarjeta de crédito solo se transmite entre tú y tus pasarelas de pago PCI-Compliant payment acquirers (see the list on our Privacy Policy page).

Comunicaciones

  • Todas las conexiones web a instancias de clientes están protegidas con encriptación de vanguardia 256-bit SSL.
  • Nuestros servidores están vigilados estríctamente, y siempre parcheados contra las vulnerabilidades SSL, y valoraciones de SLL
    Grade A en todo momento.
  • Todos nuestros certificados SLL usan un módulo 2048-bit con cadenas de certificados SHA-2 completas.

Network defense

  • All data center providers used by Odoo Cloud have very large network capacities, and have designed their infrastructure to withstand the largest Distributed Denial of Service (DDoS) attacks. Their automatic and manual mitigation systems can detect and divert attack traffic at the edge of their multi-continental networks, before it gets the chance to disrupt service availability.
  • Firewalls and intrusion prevention systems on Odoo Cloud servers help detect and block threats such as brute-force password attacks.
  • As of Odoo 12.0, customer database administrators even have the option to configure the rate limiting and cooldown duration for repeated login attempts.

— Odoo (the software) —

Seguridad del Software

Odoo is de código abierto, así que toda la base del código está contínuamente bajo examinación por parte de usuarios de Odoo y contribuidores a nivel global. Los reportes de problemas de la comunidad son una manera importante de conseguir feedback relacionado a la seguridad. Animamos a los desarrolladores a auditar el código y reportar problemas en la seguridad.

Los procesos de I+D de Odoo tienen pasos para revisar el código que incluyen aspectos de seguridad, para piezas de código nuevas y contribuídas.

Seguridad por Diseño

Odoo está diseñado de manera que previene la invasión de las más comunes vulnerabilidades de seguridad:

  • Las inyecciones SQL se previenen por el uso de una API de más alto nivel que no requiere queries manuales.
  • Los ataques XSS se previenen por el uso de un sistema de alto nivel de templado que automáticamente escapa los datos inyectados.
  • El framework previene acceso RPC a métodos privados, haciéndolo más difícil de explotar las vulnerabilidades.

Puedes ver la sección de las Mayores Vulnerabilidades OWASP para ver cómo Odoo está diseñado para prevenir la aparición de esas vulnerabilidades.

Auditorías de Seguridad Independientes

Odoo se audita automáticamente por compañías independientes que son contratadas por nuestros clientes y prospectos para realizar auditorías y exámenes de penetración. El equipo de seguridad de Odoo recibe los resultados y toma medidas apropiadas de corrección cuando sea necesario.

No podemos revelar ninguno de esos resultados, porque son confidenciales y pertenecen a los comisarios. Por favor no pregunten  ;-)

Odoo también tiene una comunidad muy activa de investigadores de seguridad independientes, que contínuamente monitorean el código fuente y trabajan con nosotros para mejorar la seguridad de Odoo. Nuestro programa de seguridad se describe aquí: Responsible Disclosure  

Mayores Vulnerabilidades OWASP

Aquí es donde Odoo se posiciona en cuanto a problemas de alta seguridad en aplicaciones web como se listan en Open Web Application Security Project (OWASP):

  • Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

    Odoo relies on an object-relational-mapping (ORM) framework that abstracts query building and prevents SQL injections by default. Developers do not normally craft SQL queries manually, they are generated by the ORM, and parameters are always properly escaped.

  • Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

    The Odoo framework escapes all expressions rendered into views and pages by default, preventing XSS. Developers have to specially mark expressions as "safe" for raw inclusion into rendered pages.

  • Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

    The Odoo website engine includes a built-in CSRF protection mechanism. It prevents any HTTP controller to receive a POST request without the corresponding security token. This is the recommended technique for CSRF prevention. This security token is only known and present when the user genuinely accessed the relevant website form, and an attacker cannot forge a request without it.

  • Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise.

    Odoo does not expose functions to perform remote file inclusion. However it allows privileged users to customize features by adding custom expressions that will be evaluated by the system. These expressions are always evaluated by a sandboxed and sanitized environment that only allows access to permitted functions.

  • Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

    Odoo access control is not implemented at the user interface level, so there is no risk in exposing references to internal objects in URLs. Attackers cannot circumvent the access control layer by manipulation those references, because every request still has to go through the data access validation layer.

  • Insecure Cryptographic Storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

    Odoo uses industry-standard secure hashing for user passwords (by default PKFDB2 + SHA-512, with key stretching) to protect stored passwords. It is also possible to use external authentication systems such as OAuth 2.0 or LDAP, in order to avoid storing user passwords locally at all.

  • Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

    Odoo Cloud runs on HTTPS by default. For on-premise installations, it is recommend to run Odoo behind a web server implementing the encryption and proxying request to Odoo, for example Apache, Lighttpd or nginx.

  • Failure to Restrict URL Access: Frequently an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

    El control de acceso de Odoo no está implementado a nivel de interfaz de usuario, y la seguridad no depende de esconder ninguna URL en especial. Los atacantes no pueden evitar la capa de control de acceso o manupilar ninguna URL porque cada petición todavía tiene que estar hecha a través de la capa de validación de acceso. En los casos raros en los que una URL provee de acceso no autorizado a datos sensibles, como URLs especiales que los clientes usan para confirmar una orden, estas URLs son firmadas digitalmente con tókens únicos y solo se envían vía email a los receptores intencionados.

Reportando Vulnerabilidades de Seguridad

Si necesitas reportar una vulnerabilidad de seguridad, por favor ve a nuestra página de responsible disclosure page. Estos reportes son tratados como de alta prioridad, el problema es tratado de inmediato y resuelto por el equipo de seguridad de Odoo, en colaboración con la persona que reporta, y luego compartido de manera responsable con el cliente de Odoo y los usuarios.