CSA STAR Level 1

O Odoo participa do programa CSA Security Trust Assurance and Risk (STAR).
Veja suas respostas para o questionário CAIQv3.1

— Odoo Cloud (a plataforma) —

Backups / Recuperação de Desastres

  • Nós mantemos 14 backups completos de cada base de dados do Odoo por pelo menos 3 meses: 1 por dia por 7 dias, 1 por semana por 4 semanas, 1 por mês por 3 meses.
  • Backups são replicados em pelo menos 3 centros de dados diferentes, em pelo menos 2 continentes diferentes.
  • As localizações reais dos nossos centros de dados estão especificadas no nosso Política de Privacidade.
  • Você também pode baixar backups manual dos seus dados em qualquer momento usando o painel de controle.
  • Você pode contactar nossa Central de Ajuda para recuperar qualquer um desses backups na sua base de dados ativa (or em outras)
  • Falha no Hardware: para serviços armazenados em metal sem isolamento, no qual falhas do hardware são possíveis, implementamos a replicação em espera ativa, com monitoramento e procedimento manual de falhas que leva menos de cinco minutos.
  • Recuperação de desastres: no caso de um desastre total, com um centro de dados completamente fora do ar por um período estendido, para evitar o fracasso do nosso hot-standby local (nunca aconteceu antes, e é o pior dos cenários), nós temos os seguintes objetivos:
    • RPO (Objetivo do Ponto de Recuperação) = 24h. Isso significa que você pode perder no máximo 24 horas de trabalho se os dados não puderem ser recuperados e precisarmos restaurar seu último backup diário.
    • RTO (Recovery Time Objective, objetivo de tempo de recuperação) = 24h para assinaturas pagas, 48h para avaliações gratuitas, ofertas educacionais, usuários freemium etc. Esse é o tempo para restaurar o serviço em um data center diferente se ocorrer um desastre e um data center ficar completamente inoperante.
    • Como isso é feito: monitoramos ativamente nossos backups diários e eles são replicados em vários locais em diferentes continentes. Temos provisionamento automatizado para implementar nossos serviços em um novo local de hospedagem. A restauração dos dados com base em nossos backups do dia anterior pode ser feita em algumas horas (para os maiores clusters), com prioridade para as assinaturas pagas.
      Usamos rotineiramente os backups diários e os scripts de provisionamento para operações diárias, de modo que ambas as partes do procedimento de recuperação de desastres são testadas o tempo todo.

Segurança da Base de Dados

  • Dados de clientes são armazenados em uma base de dados dedicada - sem compartilhamento de dados entre clientes.
  • As regras de controle de acesso aos dados implementam o isolamento completo entre as bases de dados de clientes executadas no mesmo cluster, não sendo possível o acesso de uma base de dados a outra.

Segurança da Senha

  • As senhas dos clientes são protegidas com a criptografia PBKDF2+SHA512 padrão do setor ("salted" + "stretched" por milhares de rodadas).
  • O pessoal do Odoo não tem acesso à sua senha e não pode recuperá-la, a única opção se a perder é redefini-la.
  • Credenciais de Login são sempre transmitidas de maneira segura através do HTTPS.
  • Os administradores de bases de dados de clientes têm até a opção de configurar o limite da taxa and duração de cooldown para tentativas de login repetidas.
  • Políticas de senha: administradores de bases de dados têm uma configuração preconfigurada para forçar um comprimento mínimo de senha do usuário. Outras políticas de senhas como exigir classes de caracteres não são suportadas por padrão porque elas se provaram contraproducentes. Veja o exemplo, [Shay et al. 2016]), bem como NIST SP 800-63b.

Acesso da Equipe

  • A equipe da Central de Ajuda do Odoo pode entrar na sua conta para acessar as configurações relacionadas ao seu problema de suporte. Para isso, utilizam as suas próprias credenciais especiais de pessoal, não a sua senha (que eles não têm como saber).
  • Esse acesso especial da equipe melhora a eficiência e a segurança: podem reproduzir imediatamente o problema que você está vendo, você nunca precisa compartilhar a sua senha, e podemos auditar e controlar as ações da equipe separadamente!
  • A nossa equipe da Central de Ajuda se esforça para respeitar sua privacidade o máximo possível e só acessa arquivos e configurações necessários para diagnosticar e resolver seu problema.

Segurança do Sistema

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

Segurança Física

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

  • Perímetro restrito, acessado fisicamente apenas por funcionários autorizados do data center.
  • Controle de acesso físico com crachás de segurança ou segurança biométrica.
  • Câmeras de segurança monitorando as localizações dos centros de dados 24 horas por dia, 7 dias por semana.
  • Pessoal de segurança no local 24 horas por dia, 7 dias por semana.

Segurança de Cartão de Crédito

  • Nós nunca armazenamos informações de cartões de crédito em nossos sistemas.
  • As informações do seu cartão de crédito são sempre transmitidas de maneira segura diretamente entre você e o nosso Conformidade com o PCI adquirente de pagamentos (veja a lista em Política de Privacidade página).

Criptografia de dados

Os dados dos clientes são sempre transferidos e armazenados de forma criptografada (criptografia em trânsito e em repouso).
  • Todas as comunicações de dados para instâncias de clientes são protegidas com criptografia SSL de 256 bits (HTTPS) de última geração.
  • Todas as comunicações internas de dados entre nossos servidores também são protegidas com criptografia de última geração (SSH).
  • Nossos servidores são mantidos sob rigorosa vigilância de segurança e sempre atualizados contra as mais recentes vulnerabilidades de SSL, desfrutando de Classe A Classificações SSL em todos os momentos.
  • Todos os nossos certificados SSL usam um módulo robusto de 2048 bits com cadeias de certificados SHA-2 completas.
  • Todos os dados do cliente (conteúdo da base de dados e arquivos armazenados) são criptografados em repouso, tanto na produção quanto nos backups (AES-128 ou AES-256)

Rede defesa

  • Todos os provedores de data center usados pela Odoo Cloud têm capacidades de rede muito grandes e projetaram sua infraestrutura para suportar os maiores ataques de negação de serviço distribuído (DDoS). Seus sistemas de mitigação automática e manual podem detectar e desviar o tráfego de ataque na borda de suas redes multicontinentais, antes que ele tenha a chance de interromper a disponibilidade do serviço.
  • Os firewalls e os sistemas de prevenção de invasões nos servidores do Odoo Cloud ajudam a detectar e bloquear ameaças, como ataques de senha de execução direta.
  • Os administradores de bases de dados de clientes têm até a opção de configurar o limite da taxa e duração de cooldown para tentativas repetidas de login.

— Odoo (o software) —

Segurança do Software

O Odoo tem código aberto, por isso, toda a base de código está sendo analisada permanentemente pelos usuários e colaboradores do Odoo em todo o mundo. Os relatórios de bugs da comunidade são, portanto, uma importante fonte de feedback em relação à segurança. Encorajamos os programadores a auditar o código e a comunicar problemas de segurança.

Os processos Odoo R&D tem etapas de revisão de código que incluem aspectos de segurança, para peças de código novas e provenientes de contribuições.

Segurança por Design

O Odoo foi projetado de forma a evitar a apresentação das vulnerabilidades de segurança mais comuns:

  • As injeções de SQL são evitadas pelo uso de uma API de nível superior que não exige consultas SQL manuais.
  • Os ataques de XSS são evitados com o uso de um sistema de modelos de alto nível que escapa automaticamente dos dados introduzidos.
  • A estrutura impede o acesso RPC a métodos privados, tornando mais difícil a introduçao de vulnerabilidades exploráveis.

Veja também OWASP Maiores Vulnerabilidades seção para ver como Odoo é desenhado desde o início para prevenir essas vulnerabilidades de aparecer.

Auditorias de segurança independentes

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

No entanto, não podemos divulgar nenhum desses resultados, porque são confidenciais e pertencem aos comissários. Por favor, não pergunte ;-)

Odoo também tem uma comunidade muito ativa de analistas de segurança independentes, que monitorizam continuamente o código fonte e trabalham conosco para melhorar e reforçar a segurança do Odoo. O nosso programa de segurança está descrito no nosso Divulgação Responsável página.

OWASP Maiores Vulnerabilidades

Aqui está a posição do Odoo em relação ao principal problema de segurança para aplicativos da Web, conforme listado pelo Projeto aberto de segurança de aplicativos da Web (OWASP):

  • Falhas de injeção: As falhas de injeção, especialmente a injeção de SQL, são comuns em aplicativos da web. A injeção ocorre quando os dados fornecidos pelo usuário são enviados a um intérprete como parte de um comando ou consulta. Os dados hostis do invasor induzem o intérprete a executar comandos não intencionais ou a alterar dados.

    O Odoo conta com uma estrutura de mapeamento objeto-relacional (ORM) que abstrai a criação de consultas e evita injeções de SQL por padrão. Normalmente, os desenvolvedores não criam consultas SQL manualmente, elas são geradas pelo ORM e os parâmetros são sempre escapados corretamente.

  • Cross Site Scripting (XSS): Falhas XSS ocorrem sempre que um aplicativo coleta os dados fornecidos pelos usuários e envia a um navegador da web sem antes validar ou codificar aquele conteúdo. O XSS permite que invasores executem scripts no navegador das vítimas, o que possibilita sequestro de sessões do usuário, corrupção de sites da internet, introdução de vírus, etc.

    Por padrão, a estrutura do Odoo escapa de todas as expressões renderizadas em visualizações e páginas, evitando XSS. Os desenvolvedores precisam marcar especialmente as expressões como "seguras" para inclusão bruta em páginas renderizadas.

  • Solicitação Intersite Forjada (SIF): Um ataque SIF força o navegador de uma vítima com a sessão iniciada a enviar um pedido HTTP forjado, incluindo o cookie de sessão da vítima e outras informações de autenticação incluídas automaticamente, a um aplicativo web vulnerável. Isto permite ao invasor forçar o navegador da vítima a gerar pedidos que o aplicativo vulnerável considera como pedidos legítimos da vítima.

    O mecanismo do site Odoo inclui um mecanismo de proteção CSRF integrado. Ele impede que qualquer controlador HTTP receba uma solicitação POST sem o token de segurança correspondente. Essa é a técnica recomendada para a prevenção de CSRF. Esse token de segurança só é conhecido e está presente quando o usuário realmente acessou o formulário relevante do site, e um invasor não pode forjar uma solicitação sem ele.

  • Execução de arquivos mal intencionados: O código vulnerável à inclusão remota de arquivos (RFI) permite que os invasores incluam códigos e dados hostis, resultando em ataques devastadores, como o comprometimento total do servidor.

    O Odoo não expõe funções para realizar a inclusão remota de arquivos. No entanto, permite que usuários privilegiados personalizem recursos adicionando expressões personalizadas que serão avaliadas pelo sistema. Estas expressões são sempre avaliadas por um ambiente a área de segurança e sanitizado que apenas permite o acesso a funções permitidas.

  • Referência de objeto direto não seguro: Uma referência direta a um objeto ocorre quando um desenvolvedor expõe uma referência a um objeto de implementação interna, como um arquivo, diretório, registro da base de dados ou chave, como um URL ou parâmetro de formulário. Os invasores podem manipular essas referências para acessar outros objetos sem autorização.

    O controle de acesso do Odoo não é implementado ao nível da interface do usuário, por isso não há risco em expor referências a objetos internos em URLs. Os invasores não podem contornar a camada de controle de acesso manipulando essas referências, porque cada pedido ainda tem de passar pela camada de validação de acesso aos dados.

  • Armazenamento criptográfico não seguro:Os aplicativos da web raramente usam funções criptográficas de maneira adequada para proteger dados e credenciais. Os invasores usam dados pouco protegidos para roubo de identidade e outros crimes, como fraude de cartão de crédito.

    O Odoo usa hashing seguro padrão do setor para senhas de usuários (por padrão, PKFDB2 + SHA-512, com alongamento de chave) para proteger as senhas armazenadas. Também é possível usar sistemas de autenticação externos, como OAuth 2.0 ou LDAP, para evitar o armazenamento local de senhas de usuários.

  • Comunicações não seguras: Os aplicativos frequentemente não criptografam o tráfego de rede quando é necessário proteger comunicações confidenciais.

    O Odoo Cloud é executado em HTTPS por padrão. Para instalações no local, recomenda-se para executar o Odoo por trás de um servidor da Web que implementa a criptografia e a solicitação de proxy para o Odoo, por exemplo, Apache, Lighttpd ou nginx. O guia de implementação do Odoo inclui um Checklist de segurança para implementações públicas seguras.

  • Falha ao Restringir Acesso do URL: Muitas vezes, os aplicativos protegem apenas as funcionalidades sensíveis ao impedir a apresentação de links ou URLs para usuários não autorizados. Cyber attackers podem usar essa fraqueza para acessar e fazer operações não autorizadas ao acessar esses URLs diretamente.

    O controle de acesso do Odoo não é implementado ao nível da interface do usuário, e a segurança não se baseia na ocultação de URLs especiais. Os invasores não podem contornar a camada de controle de acesso reutilizando ou manipulando qualquer URL, porque cada pedido ainda tem que passar pela camada de validação de acesso a 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, estes URLs são assinados digitalmente com tokens únicos e apenas enviados por e-mail para o destinatário previsto.

Reportando Vulnerabilidades de Segurança

Se você precisar reportar uma vulnerabilidade de segurança, por favor se direcione para o nosso página de divulgação responsável. Os relatórios são tratados com alta prioridade. O problema é imediatamente avaliado e resolvido pela equipe de segurança da Odoo. em colaboração com o relator e, então, isso é divulgado de forma responsável aos clientes e usuários do Odoo.