Segurança do Odoo

Cópias de segurança/recuperação de desastres

• Histórico de 14 cópias de segurança completas de cada base de dados do Odoo durante pelo menos 3 meses: 1 por dia por 7 dias, 1 por semana por 4 semanas, 1 por mês por 3 meses.
• Cópias de segurança replicadas em, pelo menos, 3 centros de dados diferentes.
• As localizações reais dos nossos centros de dados estão especificadas na nossa Política de Privacidade.
• Pode também descarregar cópias de segurança manuais dos seus dados em tempo real a qualquer momento através do painel de controlo.
• Pode contactar o nosso serviço de apoio ao cliente para restaurar qualquer uma dessas cópias de segurança na sua base de dados em produção (ou num ambiente paralelo).
• Failover de hardware: para serviços alojados em servidores físicos, onde a falha de hardware é possível, implementamos replicação local em hot-standby, com monitorização e um procedimento manual de failover.
• Recuperação de desastres: em caso de desastre total, com um centro de dados totalmente indisponível durante um período prolongado, impedindo a transferência para o nosso hot-standby local (nunca aconteceu até agora, este é o plano para o pior cenário), temos os seguintes objetivos:
  • RPO (Objetivo de Ponto de Recuperação) = 24h. Isto significa que pode perder no máximo 24 horas de trabalho se os dados não puderem ser recuperados e for necessário restaurar a sua última cópia de segurança diária.
  • RTO (Objetivo de Tempo de Recuperação) = 24h para assinaturas pagas, 48h para períodos de teste gratuitos, oferta educativa, utilizadores freemium, etc. Este é o tempo necessário para restaurar o serviço num centro de dados diferente caso ocorra um desastre e um centro de dados fique completamente indisponível.
  • How is this accomplished: we actively monitor our daily backups, and they are replicated in multiples distant locations. We have automated provisioning to deploy our services in a new hosting location. Restoring the data based on our backups of the previous day can then be done in a few hours (for the largest clusters), with priority on the paid subscriptions.
    We routinely use both the daily backups and provisioning scripts for daily operations, so both parts of the disaster recovery procedure are tested all the time.

Segurança da base de dados

• Os dados dos clientes são armazenados numa base de dados dedicada – sem partilha de dados entre clientes.
• As regras de controlo de acesso aos dados implementam isolamento completo entre as bases de dados dos clientes que correm no mesmo agrupamento de servidores; não é possível aceder de uma base de dados a outra.

Segurança da palavra-passe

• As palavras-passe dos clientes são protegidas com encriptação PBKDF2+SHA512 padrão da indústria (com salt e reforçadas através de milhares de iterações).
• Os colaboradores do Odoo não têm acesso à sua palavra-passe e não a podem recuperar por si; a única opção em caso de perda é redefini-la.
• As credenciais de acesso são sempre transmitidas de forma segura através de HTTPS.
• Os administradores da base de dados dos clientes têm mesmo a opção de configurar o limite da taxa e a duração do período de bloqueio para tentativas de início de sessão repetidas.
• Políticas de palavras-passe: os administradores de bases de dados têm uma configuração incorporada para impor um comprimento mínimo de palavra-passe dos utilizadores. Outras políticas de palavras-passe, como classes de caracteres obrigatórias, não são suportadas por defeito porque se demonstrou que são contraproducentes. Ver, por exemplo, [Shay et al. 2016]), bem como NIST SP 800-63b.

Acesso da equipa

• O pessoal do serviço de apoio do Odoo pode aceder à sua conta para consultar definições relacionadas com o seu problema. Para tal, utilizam as suas próprias credenciais especiais de colaborador, não a sua palavra-passe (que não têm forma de conhecer).
• Este acesso especial do pessoal melhora a eficiência e a segurança: podem reproduzir imediatamente o problema que está a observar, nunca precisa de partilhar a sua palavra-passe, e podemos auditar e controlar as ações do pessoal separadamente!
• A equipa de apoio ao cliente procura respeitar ao máximo a sua privacidade e acede apenas aos ficheiros e definições necessários para diagnosticar e resolver o seu problema.

Segurança do sistema

• Todos os servidores do Odoo na nuvem estão a executar distribuições Linux reforçadas com os patches de segurança atualizados.
• As instalações são pontuais e mínimas para limitar o número de serviços que possam conter vulnerabilidades (por exemplo, sem pilha PHP/MySQL).
• Apenas alguns engenheiros de confiança do Odoo têm autorização para gerir remotamente os servidores — e o acesso só é possível através de um par de chaves SSH pessoais encriptadas, a partir de um computador com encriptação total do disco.

Segurança física

Os servidores do Odoo Cloud estão alojados em centros de dados de confiança em várias regiões do mundo (por exemplo, OVH, Google Cloud) e todos devem cumprir critérios de segurança física rigorosos:

• Perímetro restrito, com acesso físico apenas a colaboradores autorizados do centro de dados.
• Controlo de acesso físico com cartões de segurança ou autenticação biométrica.
• Câmaras de vigilância a monitorizar as instalações dos centros de dados 24/7.
• Pessoal de segurança presente nas instalações 24/7.

Segurança nos pagamentos com cartão de crédito

• Nunca armazenamos informações de cartões de crédito nos nossos próprios sistemas.
• As informações do seu cartão de crédito são sempre transmitidas de forma segura diretamente entre si e os nossos adquirentes de pagamentocompatíveis com PCI (consulte a lista na nossa página de Política de Privacidade .

Encriptação de dados

• Todas as comunicações de dados com as instâncias dos clientes estão protegidas com encriptação SSL de 256 bits (HTTPS).
• Todas as comunicações de dados internas entre os nossos servidores também estão protegidas com encriptação de ponta a ponta.
• Os nossos servidores estão sob vigilância de segurança rigorosa e são sempre atualizados com os últimos patches de correção de vulnerabilidades SSL.
• Todos os nossos certificados SSL utilizam um módulo de 2048 bits com cadeias completas de certificados SHA-2 - Classificação A+
• Todos os dados dos clientes (conteúdo da base de dados e ficheiros armazenados) estão encriptados em repouso, tanto em produção como nas cópias de segurança, utilizando AES-256.

Defesa da rede

• Todos os fornecedores de centros de dados utilizados pelo Odoo Cloud possuem capacidades de rede muito elevadas e desenharam a sua infraestrutura para resistir aos maiores ataques de negação de serviço distribuídos (DDoS). Os seus sistemas de mitigação automáticos e manuais conseguem detetar e desviar o tráfego de ataque na periferia das suas redes multi-continentais, antes que tenha a oportunidade de comprometer a disponibilidade do serviço.
• Firewalls e sistemas de prevenção de intrusões nos servidores do Odoo Cloud ajudam a detetar e bloquear ameaças, como ataques de força bruta a palavras-passe.
• Os administradores da base de dados dos clientes têm mesmo a opção de configurar o limite da taxa e a duração de bloqueio para tentativas de login repetidas ou configurar um CAPTCHA para mitigar ataques automatizados de força bruta.

Segurança do software

O Odoo é de código aberto, pelo que todo o código-fonte é continuamente analisado por utilizadores e contribuidores em todo o mundo. Os relatórios de erros da comunidade constituem, assim, uma importante fonte de feedback em matéria de segurança. Incentivamos os programadores a auditar o código e a reportar vulnerabilidades de segurança.

Os processos de I+D do Odoo incluem etapas de revisão de código que abrangem aspetos de segurança, tanto para código novo como para contribuições externas.

Concebido com segurança

O Odoo foi concebido de forma a prevenir a introdução das vulnerabilidades de segurança mais comuns:

• As injeções SQL são prevenidas através da utilização de uma API de nível superior que não requer consultas SQL manuais.
• Os ataques XSS são prevenidos através da utilização de um sistema de templates de alto nível que escapa automaticamente os dados injetados.
• A estrutura impede o acesso remoto a métodos privados, tornando mais difícil a introdução de vulnerabilidades exploráveis.

Consulte também a secção das Principais vulnerabilidades da OWASP para ver como o Odoo é concebido desde a base para impedir que tais vulnerabilidades surjam.

Auditorias de segurança externas

O Odoo é regularmente auditado por empresas independentes contratadas pelos nossos clientes e potenciais clientes para realizar auditorias e testes de intrusão. A equipa de segurança do Odoo recebe os resultados e toma as medidas corretivas adequadas sempre que necessário.

Não podemos, no entanto, divulgar quaisquer desses resultados, pois são confidenciais e pertencem aos comissionadores. Por favor, não peça :)

O Odoo conta também com uma comunidade muito ativa de investigadores de segurança independentes, que monitorizam continuamente o código-fonte e colaboram connosco para melhorar e reforçar a segurança do Odoo. O nosso programa de segurança está descrito na nossa divulgação responsável .

Principais vulnerabilidades da OWASP

Aqui é apresentado o posicionamento do Odoo face à principal questão de segurança para aplicações web, conforme listado pelo Open Web Application Security Project (OWASP):

• Falhas de injeção: falhas de injeção, particularmente injeção SQL, são comuns em aplicações web. A injeção ocorre quando dados fornecidos pelo utilizador são enviados a um interpretador como parte de um comando ou consulta. Os dados maliciosos do atacante enganam o interpretador, levando-o a executar comandos não pretendidos ou a alterar dados.

  O Odoo baseia-se numa estrutura de mapeamento objeto-relacional (ORM) que abstrai a construção de consultas e previne injeções SQL por defeito. Os programadores normalmente não constroem consultas SQL manualmente, sendo estas geradas pelo ORM, e os parâmetros são sempre devidamente escapados.

• Cross Site Scripting (XSS): falhas XSS ocorrem sempre que uma aplicação recebe dados fornecidos pelo utilizador e os envia para um navegador web sem primeiro validar ou codificar esse conteúdo. O XSS permite aos atacantes executar scripts no navegador da vítima, podendo sequestrar sessões de utilizador, desfigurar sites, possivelmente introduzir worms, entre outros.

  A estrutura do Odoo escapa todas as expressões apresentadas em vistas e páginas por defeito, prevenindo XSS. Os programadores têm de marcar especificamente as expressões como "seguras" para inclusão direta nas páginas renderizadas.

• Cross Site Request Forgery (CSRF): um ataque CSRF força o navegador de uma vítima com sessão iniciada a enviar uma solicitação HTTP falsificada, incluindo o cookie de sessão da vítima e qualquer outra informação de autenticação automaticamente incluída, para uma aplicação web vulnerável. Isto permite ao atacante obrigar o navegador da vítima a gerar solicitações que a aplicação vulnerável interpreta como solicitações legítimas da vítima.

  O motor de sites do Odoo inclui um mecanismo de proteção CSRF incorporado. Este impede que qualquer controlador HTTP receba um pedido POST sem o token de segurança correspondente. Esta é a técnica recomendada para prevenção de CSRF. O token de segurança só é conhecido e existe quando o utilizador acedeu genuinamente ao formulário relevante do website, e um atacante não pode falsificar um pedido sem ele.

• Execução de ficheiros maliciosos: código vulnerável à inclusão remota de ficheiros (RFI) permite que atacantes incluam código e dados hostis, resultando em ataques devastadores, como a compromissão total do servidor.

  O Odoo não expõe funções para realizar inclusão remota de ficheiros. No entanto, permite que utilizadores privilegiados personalizem funcionalidades através da adição de expressões personalizadas que serão avaliadas pelo sistema. Estas expressões são sempre avaliadas num ambiente isolado e sanitizado que apenas permite acesso a funções autorizadas.

• Referência direta insegura a objetos: uma referência direta a um objeto ocorre quando um programador expõe uma referência a um objeto de implementação interno, como um ficheiro, diretório, registo de base de dados ou chave, através de um URL ou parâmetro de formulário. Os atacantes podem manipular essas referências para aceder a outros objetos sem autorização.

  O controlo de acesso do Odoo não é implementado ao nível da interface de utilizador, pelo que não existe risco em expor referências a objetos internos em URLs. Os atacantes não podem contornar a camada de controlo de acesso ao manipular essas referências, pois cada pedido ainda tem de passar pela camada de validação de acesso aos dados.

• Armazenamento criptográfico inseguro: as aplicações web raramente utilizam corretamente funções criptográficas para proteger dados e credenciais. Os atacantes exploram dados pouco protegidos para cometer roubo de identidade e outros crimes, como fraude com cartões de crédito.

  O Odoo utiliza funções de dispersão seguras padrão da indústria para as palavras-passe dos utilizadores (por defeito PBKDF2 + SHA-512, com alongamento de chave) para proteger as palavras-passe armazenadas. É também possível utilizar sistemas de autenticação externos, como OAuth 2.0 ou LDAP, de forma a evitar o armazenamento local de palavras-passe dos utilizadores.

• Comunicações inseguras: as aplicações falham frequentemente em encriptar o tráfego de rede quando é necessário proteger comunicações sensíveis.

  O Odoo Cloud funciona por HTTPS por predefinição. Para instalações on-premise, recomenda-se executar o Odoo atrás de um servidor web que implemente encriptação e encaminhe os pedidos para o Odoo, por exemplo Apache, Lighttpd ou nginx. O guia de implementação do Odoo inclui uma Lista de verificação de segurança para uma implementação pública mais segura.

• Falha ao restringir o acesso a URLs: frequentemente, uma aplicação protege funcionalidades sensíveis apenas impedindo a exibição de links ou URLs a utilizadores não autorizados. Os atacantes podem explorar esta vulnerabilidade para aceder e executar operações não autorizadas ao aceder diretamente a essas URLs.

  O controlo de acesso do Odoo não é implementado ao nível da interface de utilizador, e a segurança não depende de ocultar URLs especiais. Os atacantes não podem contornar a camada de controlo de acesso reutilizando ou manipulando qualquer URL, pois cada pedido ainda tem de passar pela camada de validação de acesso aos dados. Em casos raros em que um URL fornece acesso não autenticado a dados sensíveis, como URLs especiais que os clientes utilizam para confirmar uma encomenda, esses URLs são assinados digitalmente com tokens únicos e apenas enviados por e-mail ao destinatário pretendido.

Comunicação de vulnerabilidades de segurança

Se precisar de reportar uma vulnerabilidade de segurança, por favor aceda à nossa página de divulgação responsável. Estes relatórios são tratados com elevada prioridade, o problema é imediatamente avaliado e resolvido pela equipa de segurança do Odoo, em colaboração com o remetente, e posteriormente divulgado de forma responsável aos clientes e utilizadores do Odoo.