Configuração do sistema¶

Este documento descreve as etapas básicas para configurar o Odoo em produção ou em um servidor voltado para a Internet. Isso dá sequência à installation, e geralmente não é necessário para sistemas de desenvolvimento que não estão expostos na internet.

Aviso

Se estiver configurando um servidor público, não deixe de verificar nossas recomendações de segurança!

dbfilter¶

O Odoo é um sistema multilocatário: um único sistema Odoo pode executar e atender a várias instâncias de base de dados. Ele também é altamente personalizável, com personalizações (a partir dos módulos carregados) dependendo da “base de dados atual”.

Isso não é um problema ao trabalhar no back-end (cliente da web) como um usuário da empresa conectado: a base de dados pode ser selecionada ao fazer login e as personalizações carregadas posteriormente.

No entanto, é um problema para usuários não logados (portal, site) que não estão vinculados a uma base de dados: o Odoo precisa saber qual base de dados deve ser usada para carregar a página do site ou executar a operação. Se não for usada multilocação, isso não é um problema, pois há apenas uma base de dados para usar, mas se houver várias bases de dados acessíveis, o Odoo precisará de uma regra para saber qual delas deve ser usada.

Essa é uma das finalidades do --db-filter: ele especifica como a base de dados deve ser selecionada de acordo com o nome do host (domínio) que está sendo solicitado. O valor é uma expressão regular, possivelmente incluindo o nome de host injetado dinamicamente (%h) ou o primeiro subdomínio (%d) pelo qual o sistema está sendo acessado.

Para servidores que hospedam várias bases de dados de produção, especialmente se for usado o site, o dbfilter deve ser definido, caso contrário, muitos recursos não funcionarão corretamente.

Exemplos de configuração¶

Mostrar apenas bases de dados com nomes que começam com ‘mycompany’

no arquivo de configuração, defina:

[options]
dbfilter = ^mycompany.*$

Mostrar apenas bases de dados que correspondam ao primeiro subdomínio após www: por exemplo, a base de dados “mycompany” será exibida se a solicitação de entrada tiver sido enviada para www.mycompany.com ou mycompany.co.uk, mas não para www2.mycompany.com ou helpdesk.mycompany.com.

no arquivo de configuração, defina:

[options]
dbfilter = ^%d$

Nota

A configuração de um --db-filter adequado é uma parte importante da segurança de sua implementação. Quando estiver funcionando corretamente e corresponder apenas a uma única base de dados por nome de host, é altamente recomendável bloquear o acesso às telas do gerenciador da base de dados e usar o parâmetro de inicialização --no-database-list para evitar a listagem das bases de dados e para bloquear o acesso às telas de gerenciamento da base de dados. Consulte também security.

PostgreSQL¶

Por padrão, o PostgreSQL só permite conexão por soquetes UNIX e conexões de loopback (de “localhost”, a mesma máquina em que o servidor PostgreSQL está instalado).

O soquete UNIX é adequado se você quiser que o Odoo e o PostgreSQL sejam executados na mesma máquina, e é o padrão quando nenhum host é fornecido, mas se você quiser que o Odoo e o PostgreSQL sejam executados em máquinas diferentes 1, ele precisará ler as interfaces de rede 2, seja para:

Aceitar apenas conexões de loopback e use um túnel SSH entre a máquina na qual o Odoo é executado e a máquina na qual o PostgreSQL é executado e, em seguida, configure o Odoo para se conectar à sua extremidade do túnel
Aceitar conexões com a máquina na qual o Odoo está instalado, possivelmente por ssl (consulte Configurações de conexão PostgreSQL para obter detalhes) e, em seguida, configure o Odoo para se conectar pela rede

Exemplo de configuração¶

Permitir conexão tcp no host local
Permitir conexão tcl da rede 192.168.1.x

em /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf, defina:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

em /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf, defina:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Configurar o Odoo¶

Fora da caixa, o Odoo se conecta a um Postgres local através de um soquete UNIX pela porta 5432. Isso pode ser substituído usando as opções de base de dados quando sua implementação do Postgres não for local e/ou não usar os padrões de instalação.

Com os instaladores de pacotes, um novo usuário (odoo) será automaticamente criado e definido como o usuário da base de dados.

As telas de gerenciamento da base de dados são protegidas pela configuração admin_passwd. Essa configuração só pode ser definida através de arquivos de configuração e é verificada antes da realização de alterações na base de dados. Ela deve ser definida como um valor gerado aleatoriamente para garantir que terceiros não possam usar essa interface.
Todas as operações da base de dados utilizam as opções de base de dados, incluindo a tela de gerenciamento. Para que a tela de gerenciamento de base de dados funcione, é necessário que o usuário do PostgreSQL tenha o direito createdb.
Os usuários sempre podem abandonar as bases de dados que possuem. Para que a tela de gerenciamento de base de dados fique completamente não funcional, o usuário do PostgreSQL precisa ser criado com no-createdb e a base de dados deve pertencer a um usuário do PostgreSQL diferente.

Aviso
o usuário do PostgreSQL não deve ser um superusuário

Exemplo de configuração¶

conectar-se a um servidor PostgreSQL em 192.168.1.2
porta 5432
usar uma conta de usuário ‘odoo’,
com ‘pwd’ como senha
filtragem de bd com nome que começa com ‘mycompany’

no arquivo de configuração, defina:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

SSL entre Odoo e PostgreSQL¶

A partir do Odoo 11.0, você pode impor a conexão ssl entre o Odoo e o PostgreSQL. No Odoo, o db_sslmode controla a segurança ssl da conexão com o valor escolhido entre ‘disable’, ‘allow’, ‘prefer’, ‘require’, ‘verify-ca’ ou ‘verify-full’

Doc do PostgreSQL

Servidor integrado¶

O Odoo inclui servidores HTTP, cron e chat ao vivo integrados, usando multi-threading ou multiprocessamento.

O servidor de multi-threading é um servidor mais simples, usado principalmente para desenvolvimento, demonstrações e sua compatibilidade com vários sistemas operacionais (inclusive o Windows). Um novo thread é gerado para cada nova solicitação HTTP, mesmo para conexões de longa duração, como o websocket. Também são gerados threads cron extra daemônicos. Devido a uma limitação do Python (GIL), ele não faz o melhor uso do hardware.

O servidor multi-threading é o padrão, também para contêineres docker. Ele é selecionado deixando a opção --workers de fora ou definindo-a como 0.

O servidor de multiprocessamento é um servidor completo usado principalmente para produção. Ele não está sujeito à mesma limitação do Python (GIL) sobre o uso de recursos e, portanto, faz o melhor uso do hardware. Um pool de workers é criado na inicialização do servidor. Novas solicitações HTTP são enfileiradas pelo sistema operacional até que haja workers prontos para processá-las. Um worker HTTP adicional acionado por eventos do chat ao vivo é gerado em uma porta alternativa. Também são gerados workers adicionais do cron. Um reaper de processo configurável monitora o uso de recursos e pode eliminar/reiniciar os workers com falha.

O servidor de multiprocessamento é opcional. Ele é selecionado ao definir a opção --workers como um número inteiro não nulo.

Nota

Por ser altamente personalizado para servidores Linux, o servidor de multiprocessamento não está disponível no Windows.

Cálculo do número de workers¶

Regra geral: (#CPU * 2) + 1
Os workers Cron precisam de CPU
1 worker ~= 6 usuários simultâneos

Cálculo do tamanho da memória¶

Consideramos que 20% das solicitações são pesadas, enquanto 80% são mais simples
Estima-se que um worker pesado, quando todos os campos computados estão bem projetados, as solicitações SQL estão bem projetadas… consome cerca de 1 GB de RAMt
Estima-se que um worker mais leve, no mesmo cenário, consuma cerca de 150 MB de RAM

RAM necessária = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Chat ao vivo¶

No multiprocessamento, um trabalhador dedicado do Chat ao Vivo é iniciado automaticamente e escuta --gevent-port. Por padrão, as solicitações HTTP continuarão acessando os workers HTTP normais em vez do chat ao vivo. Você deve implementar um proxy na frente do Odoo e redirecionar as solicitações de entrada cujo caminho começa com /websocket/ para o worker do chat ao vivo. Você também deve iniciar o Odoo em --proxy-mode para que ele use os cabeçalhos reais do cliente (como nome do host, esquema e IP) em vez dos cabeçalhos do proxy.

Exemplo de configuração¶

Servidor com 4 CPUs, 8 threads
60 usuários simultâneos
60 usuários / 6 = 10 <- número teórico de workers necessários
(4 * 2) + 1 = 9 <- número máximo teórico de workers
Usaremos 8 workers + 1 para o cron. Também usaremos um sistema de monitoramento para medir a carga da CPU e verificar se ela está entre 7 e 7,5.
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB RAM for Odoo

no o arquivo de configuração:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS¶

Independentemente de ser acessar pelo site/cliente da web ou pelo serviço da Web, o Odoo transmite informações de autenticação em texto simples. Isso significa que uma implementação segura do Odoo deve usar HTTPS3. A terminação SSL pode ser implementada por praticamente qualquer proxy de terminação SSL, mas requer a seguinte configuração:

Habilitar o proxy mode do Odoo. Isso só deve ser ativado quando o Odoo estiver atrás de um proxy reverso
Configurar o proxy de terminação SSL (exemplo de terminação Nginx)
Configurar o proxy propriamente dito (exemplo de proxy Nginx)
Seu proxy de terminação SSL também deve redirecionar automaticamente as conexões não seguras para a porta segura

Exemplo de configuração¶

Redirecionar solicitações http para https
Solicitações de proxy para odoo

no arquivo de configuração, defina:

proxy_mode = True

em /etc/nginx/sites-enabled/odoo.conf, defina:

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

# http -> https
server {
  listen 80;
  server_name odoo.mycompany.com;
  rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443 ssl;
  server_name odoo.mycompany.com;
  proxy_read_timeout 720s;
  proxy_connect_timeout 720s;
  proxy_send_timeout 720s;

  # SSL parameters
  ssl_certificate /etc/ssl/nginx/server.crt;
  ssl_certificate_key /etc/ssl/nginx/server.key;
  ssl_session_timeout 30m;
  ssl_protocols TLSv1.2;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;

  # log
  access_log /var/log/nginx/odoo.access.log;
  error_log /var/log/nginx/odoo.error.log;

  # Redirect websocket requests to odoo gevent port
  location /websocket {
    proxy_pass http://odoochat;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # Redirect requests to odoo backend server
  location / {
    # Add Headers for odoo proxy mode
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_redirect off;
    proxy_pass http://odoo;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # common gzip
  gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
  gzip on;
}

Proteção de HTTPS¶

Adicione o cabeçalho Strict-Transport-Security a todas as solicitações, para evitar que os navegadores enviem uma solicitação HTTP simples para esse domínio. Você precisará manter um serviço HTTPS em funcionamento com um certificado válido nesse domínio o tempo todo; caso contrário, seus usuários receberão alertas de segurança ou não conseguirão acessá-lo.

Forçar conexões HTTPS durante um ano para cada visitante no NGINX com a linha:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Configurações adicionais podem ser definidas para o cookie session_id. O sinalizador Secure pode ser adicionado para garantir que ele nunca seja transmitido por HTTP e SameSite=Lax para evitar CSRF autenticado.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo como um aplicativo WSGI¶

Também é possível montar o Odoo como um aplicativo WSGI padrão. O Odoo fornece a base para um script de lançamento WSGI como odoo-wsgi.example.py. Esse script deve ser personalizado (possivelmente depois de copiá-lo do diretório de configuração) para definir a configuração correta diretamente no odoo.tools.config em vez de usar a linha de comando ou um arquivo de configuração.

No entanto, o servidor WSGI exporá apenas o endpoint HTTP principal do cliente da web, o site e a API do serviço da web. Como o Odoo não controla mais a criação de workers, não é possível configurar workers cron ou chat ao vivo.

Workers Cron¶

É necessário iniciar um dos servidores Odoo integrados ao lado do servidor WSGI para processar os trabalhos cron. Esse servidor deve ser configurado para processar apenas crons e não solicitações HTTP com a opção --no-http do cli ou a definição do arquivo de configuração http_enable = False.

Em sistemas do tipo Linux, é recomendável usar o servidor de multiprocessamento em vez do de multi-threading para se aproveitar o melhor uso do hardware e a maior estabilidade, ou seja, usar as opções --workers=-1 e --max-cron-threads=n de cli.

Chat ao vivo¶

O uso de um servidor WSGI compatível com gevent é necessário para a operação correta do recurso de chat ao vivo. Esse servidor deve ser capaz de lidar com muitas conexões simultâneas de longa duração, mas não precisa de muita capacidade de processamento. Todas as solicitações cujo caminho começa com /websocket/ devem ser direcionadas a esse servidor. Um servidor WSGI normal (baseado em thread/processo) deve ser usado para todas as outras solicitações.

O servidor cron do Odoo também pode ser usado para atender às solicitações de chat ao vivo. Basta remover a opção --no-http do servidor cron e certificar-se de que as solicitações cujo caminho começa com /websocket/ sejam direcionadas para esse servidor, seja no servidor --http-port (servidor multi-threading) ou no --gevent-port (servidor de multiprocessamento).

Fornecimento de arquivos estáticos e anexos¶

Para maior conveniência no desenvolvimento, o Odoo fornece todos os arquivos estáticos e anexos diretamente em seus módulos. Isso pode não ser ideal quando se trata de desempenho, e os arquivos estáticos geralmente devem ser fornecidos por um servidor HTTP estático.

Fornecimento de arquivos estáticos¶

Os arquivos estáticos do Odoo estão localizados na pasta static/ de cada módulo, de modo que os arquivos estáticos podem ser fornecidos interceptando todas as solicitações para /MODULE/static/FILE e procurando o módulo (e o arquivo) correto nos vários caminhos de complementos.

Recomenda-se definir o cabeçalho Content-Security-Policy: default-src 'none' em todas as imagens fornecidas pelo servidor Web. Isso não é obrigatório, pois os usuários não podem modificar/injetar conteúdo dentro da pasta static/ dos módulos e as imagens existentes são finais (elas não buscam novos recursos por si mesmas). No entanto, é uma boa prática.

Usando a configuração do NGINX (https) acima, os blocos mapa e localização devem ser adicionados para fornecer arquivos estáticos por NGINX.

map $sent_http_content_type $content_type_csp {
    default "";
    ~image/ "default-src 'none'";
}

server {
    # the rest of the configuration

    location @odoo {
        # copy-paste the content of the / location block
    }

    # Serve static files right away
    location ~ ^/[^/]+/static/.+$ {
        # root and try_files both depend on your addons paths
        root ...;
        try_files ... @odoo;
        expires 24h;
        add_header Content-Security-Policy $content_type_csp;
    }
}

As diretivas root e try_files dependem da sua instalação, especificamente de --addons-path.

Example

Digamos que o Odoo tenha sido instalado pelos pacotes Debian para Community e Enterprise, e que --addons-path seja '/usr/lib/python3/dist-packages/odoo/addons'`.

O root e o try_files devem ser:

root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;

Digamos que o Odoo tenha sido instalado por fontes, que os repositórios git Community e Enterprise tenham sido clonados em /opt/odoo/community e /opt/odoo/enterprise respectivamente, e que --addons-path é '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

O root e o try_files devem ser:

root /opt/odoo;
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;

Fornecimento de anexos¶

Os anexos são arquivos armazenados no armazenamento de arquivos cujo acesso é regulado pelo Odoo. Eles não podem ser acessados diretamente por um servidor da web estático, pois o acesso a eles requer várias pesquisas na base de dados para determinar onde os arquivos estão armazenados e se o usuário atual pode acessá-los ou não.

No entanto, uma vez que o arquivo tenha sido localizado e os direitos de acesso verificados pelo Odoo, é uma boa ideia fornecer o arquivo usando o servidor da web estático, em vez do Odoo. Para que o Odoo delegue o fornecimento de arquivos ao servidor web estático, as extensões X-Sendfile (apache) ou X-Accel (nginx) devem estar ativadas e configuradas no servidor web estático. Depois de configurado, inicie o Odoo com o sinalizador --x-sendfile de CLI (esse sinalizador exclusivo é usado tanto para o X-Sendfile quanto para o X-Accel).

Nota

A extensão X-Sendfile para Apache (e servidores da web compatíveis) não requer nenhuma configuração adicional.
A extensão X-Accel para o NGINX exige a seguinte configuração adicional:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
Caso não saiba qual é o caminho para o seu armazenamento de arquivos, inicie o Odoo com a opção --x-sendfile e navegue até o URL /web/filestore diretamente do Odoo (não acesse o URL pelo NGINX). Isso registra um aviso, a mensagem contém a configuração necessária.

Segurança¶

Para começar, tenha em mente que a proteção de um sistema de informações é um processo contínuo, não uma operação única. Você sempre estará tão seguro quanto o elo mais fraco do seu ambiente.

Portanto, não considere esta seção como a lista definitiva de medidas que evitarão todos os problemas de segurança. Ela serve apenas como um resumo das primeiras coisas importantes que você deve incluir em seu plano de ação de segurança. O restante virá das práticas recomendadas de segurança de sua distribuição e sistema operacional, práticas recomendadas em termos de usuários, senhas e gerenciamento de controle de acesso etc.

Ao implementar um servidor voltado para a Internet, não deixe de considerar os seguintes tópicos de segurança:

Sempre defina uma senha forte de superadministrador e restrinja o acesso às páginas de gerenciamento da base de dados assim que o sistema for configurado. Consulte Segurança do gerenciador da base de dados.
Escolha logins exclusivos e senhas fortes para todas as contas de administrador em todas as bases de dados. Não use “admin” como login. Não use esses logins para operações diárias, apenas para controlar/gerenciar a instalação. *Nunca use senhas padrão como admin/admin, mesmo para bases de dados de teste.
Não instale dados de demonstração em servidores voltados para a Internet. As bases com dados de demonstração contêm logins e senhas padrão que podem ser usados para entrar em seus sistemas e causar problemas significativos, mesmo em sistemas de teste/dev.
Use filtros adequados de base de dados ( --db-filter) para restringir a visibilidade das suas bases de acordo com o nome do host. Consulte dbfilter. Você também pode usar -d para fornecer sua própria lista (separada por vírgulas) de bases de dados disponíveis a filtrar, em vez de permitir que o sistema busque todas elas no backend.
Depois que db_name e dbfilter estiverem configurados e corresponderem a apenas uma base de dados por nome de host, você deverá definir a opção de configuração list_db como False, para impedir totalmente a listagem de bases de dados e bloquear o acesso às telas de gerenciamento da base (isso também é exposto como a opção de linha de comando --no-database-list)
Certifique-se de que o usuário do PostgreSQL (--db_user) não seja um superusuário e de que suas bases de dados sejam de propriedade de um usuário diferente. Por exemplo, eles podem ser de propriedade do superusuário postgres se você estiver usando um db_user dedicado e sem privilégios. Consulte também Configurar o Odoo.
Mantenha as instalações atualizadas instalando regularmente as últimas compilações, seja pelo GitHub ou baixando a versão mais recente em https://www.odoo.com/page/download ou http://nightly.odoo.com
Configure seu servidor no modo multiprocessos com limites adequados que correspondam ao seu uso normal (memória/CPU/tempo limite). Consulte também Servidor integrado.
Execute o Odoo em um servidor da web que forneça terminação HTTPS com um certificado SSL válido, para evitar a interceptação de comunicações em texto simples. Os certificados SSL são baratos e existem muitas opções gratuitas. Configure o proxy da web para limitar o tamanho das solicitações, defina tempos limite apropriados e, em seguida, ative a opção proxy mode. Consulte também HTTPS.
Se você precisar permitir o acesso SSH remoto aos seus servidores, certifique-se de definir uma senha forte para todas as contas, não apenas para o root. É altamente recomendável desativar totalmente a autenticação baseada em senha e permitir apenas a autenticação por chave pública. Considere também a possibilidade de restringir o acesso com uma VPN, permitindo apenas IPs confiáveis no firewall e/ou executando um sistema de detecção de força bruta, como o fail2ban ou equivalente.
Considere a possibilidade de instalar uma limitação de taxa adequada em seu proxy ou firewall para evitar ataques de força bruta e ataques de negação de serviço. Consulte também Bloqueio de ataques de força bruta para obter medidas específicas.

Muitos provedores de rede oferecem atenuação automática para ataques distribuído de negação de serviço (DDOS), mas isso geralmente é um serviço opcional, portanto, você deve consultá-los.
Sempre que possível, hospede suas instâncias de demonstração/teste voltadas para o público em máquinas diferentes das de produção, e aplique as mesmas precauções de segurança que nas de produção.
Se o seu servidor Odoo voltado para o público tiver acesso a recursos ou serviços de rede interna confidenciais (por exemplo, por uma VLAN privada), implemente regras de firewall adequadas para proteger esses recursos internos. Isso garantirá que o servidor Odoo não possa ser usado acidentalmente (ou como resultado de ações maliciosas do usuário) para acessar ou interromper esses recursos internos. Normalmente, isso pode ser feito aplicando uma regra DENY padrão de saída no firewall e, então, autorizando explicitamente somente o acesso aos recursos internos que o servidor Odoo precisa acessar. O Controle de acesso ao tráfego IP do sistema também pode ser útil para implementar o controle de acesso à rede por processo.
Se o seu servidor Odoo voltado para o público estiver atrás de um firewall de aplicativo web, um balanceador de carga, um serviço transparente de proteção contra DDoS (como o CloudFlare) ou um dispositivo semelhante no nível da rede, talvez você queira evitar o acesso direto ao sistema Odoo. Geralmente, é difícil manter os endereços IP do endpoint de seus servidores Odoo em segredo. Por exemplo, eles podem aparecer nos registros do servidor da Web ao consultar sistemas públicos ou nos cabeçalhos de e-mails enviados a partir do Odoo. Em tal situação, pode ser interessante configurar seu firewall para que os endpoints não sejam acessíveis publicamente, exceto a partir dos endereços IP específicos do seu WAF, balanceador de carga ou serviço de proxy. Provedores de serviços como o CloudFlare geralmente mantêm uma lista pública de seus intervalos de endereços IP para essa finalidade.
Se estiver hospedando vários clientes, isole os dados e arquivos dos clientes uns dos outros usando contêineres ou técnicas apropriadas de “jail”.
Configure backups diários de suas bases de dados e dados de armazenamento de arquivos e copie-os para um servidor de arquivamento remoto que não seja acessível a partir do próprio servidor.
Recomenda-se fortemente a implementação do Odoo no Linux, em vez de no Windows. Se, mesmo assim, você optar por implementar em uma plataforma Windows, deverá ser realizada uma revisão completa da solidez da segurança do servidor, o que está fora do escopo deste guia.

Bloqueio de ataques de força bruta¶

Em implementações voltadas para a Internet, ataques de força bruta às senhas dos usuários são muito comuns, e essa ameaça não deve ser negligenciada nos servidores Odoo. O Odoo emite uma entrada de registro sempre que uma tentativa de login é realizada e informa o resultado (sucesso ou falha), juntamente com o login de destino e o IP de origem.

As entradas de registro terão o seguinte formato.

Falha no login:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login failed for db:db_name login:admin from 127.0.0.1

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login successful for db:db_name login:admin from 127.0.0.1

Esses registros podem ser facilmente analisados por um sistema de prevenção de intrusões, como o fail2ban.

Por exemplo, a seguinte definição de filtro fail2ban deve corresponder a um login com falha:

[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =

Seu uso com uma definição de jail pode servir para bloquear o IP de ataque em HTTP(S).

Isso poderia ser feito para bloquear o IP por 15 minutos quando 10 tentativas de login com falha são detectadas do mesmo IP em 1 minuto:

[odoo-login]
enabled = true
port = http,https
bantime = 900  ; 15 min ban
maxretry = 10  ; if 10 attempts
findtime = 60  ; within 1 min  /!\ Should be adjusted with the TZ offset
logpath = /var/log/odoo.log  ;  set the actual odoo log path here

Segurança do gerenciador da base de dados¶

Configurar o Odoo fez menção, de passagem, à admin_passwd.

Essa configuração é usada em todas as telas de gerenciamento de base de dados (para criar, excluir, fazer dump ou restaurar bases de dados).

Se as telas de gerenciamento não devem ser acessadas de forma alguma, defina a opção de configuração list_db como False para bloquear o acesso a todas as telas de seleção e gerenciamento de base de dados.

Aviso

É altamente recomendável desativar o gerenciador de base de dados em qualquer sistema voltado para a internet! Ele foi criado como uma ferramenta de desenvolvimento/demo, para facilitar a criação e o gerenciamento rápidos de bases de dados. Não foi projetado para uso em produção e pode até expor recursos perigosos a invasores. Também não foi projetado para lidar com bases de dados grandes e pode disparar limites de memória.

Em sistemas de produção, as operações de gerenciamento da base de dados devem sempre ser realizadas pelo administrador do sistema, inclusive o provisionamento de novos bases de dados e backups automatizados.

Certifique-se de configurar um parâmetro db_name adequado (e, opcionalmente, dbfilter também) para que o sistema possa determinar a base de dados de destino em cada solicitação; caso contrário, os usuários serão bloqueados, pois não poderão escolher a base de dados por conta própria.

Se as telas de gerenciamento só puderem ser acessadas a partir de um conjunto selecionado de máquinas, use os recursos do servidor proxy para bloquear o acesso a todas as rotas que começam com /web/database, exceto (talvez) /web/database/selector, que exibe a tela de seleção de base de dados.

Se a tela de gerenciamento da base de dados permanecer acessível, a configuração admin_passwd deverá ser alterada do padrão admin: essa senha é verificada antes de permitir operações de alteração da base de dados.

Ela deve ser armazenada de forma segura e deve ser gerada aleatoriamente, ex.:

$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

que gera uma string imprimível pseudo-aleatória de 32 caracteres.

Redefinir a senha mestra¶

Pode haver casos em que a senha mestra tenha sido perdida ou comprometida e precise ser redefinida. O processo a seguir é para administradores do sistema de uma base de dados local do Odoo, detalhando como redefinir manualmente e criptografar novamente a senha mestra.

Veja também

Para obter mais informações sobre como alterar a senha de uma conta do Odoo.com, consulte esta documentação: Alteração da senha da conta do Odoo.com.

Ao criar uma nova base de dados no local, é gerada uma senha mestra aleatória. A Odoo recomenda o uso dessa senha para proteger a base. Essa senha é implementada por padrão, portanto, há uma senha mestra segura para qualquer implantação local do Odoo.

Aviso

Ao criar uma base de dados do Odoo on-premise, a instalação fica acessível a qualquer pessoa na Internet, até que essa senha seja definida para proteger a base de dados.

A senha mestra é especificada no arquivo de configuração do Odoo (odoo.conf ou odoorc (arquivo oculto)). Essa senha é necessária para modificar, criar ou excluir uma base de dados pela interface gráfica do usuário (GUI).

Localizar o arquivo de configuração¶

Primeiro, abra o arquivo de configuração do Odoo (odoo.conf ou odoorc (arquivo oculto)).

O arquivo de configuração está localizado em: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

Dependendo de como o Odoo está instalado na máquina Linux, o arquivo de configuração estará localizado em um de dois lugares diferentes:

Instalação do pacote: /etc/odoo.conf
Instalação da fonte: ~/.odoorc

Alterar senha antiga¶

Depois que o arquivo apropriado tiver sido aberto, prossiga para alterar a senha antiga no arquivo de configuração para uma senha temporária.

Depois de localizar o arquivo de configuração, abra-o usando uma (GUI). Para fazer isso, basta clicar duas vezes no arquivo. Então, o dispositivo deverá ter uma :abbr:`GUI (interface gráfica do usuário) ` padrão para abrir o arquivo.

Em seguida, modifique a linha da senha mestra admin_passwd = $pbkdf2-sha... para admin_passwd = newpassword1234, por exemplo. Essa senha pode ser qualquer coisa, desde que seja salva temporariamente. Certifique-se de modificar todos os caracteres após o =.

Example

A linha aparece assim: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

A linha modificada aparece assim: admin_passwd = newpassword1234

Modifique a linha da senha mestra usando o seguinte comando Unix detalhado abaixo.

Conecte-se ao terminal do servidor Odoo pelo protocolo Secure Shell (SSH) e edite o arquivo de configuração. Para modificar o arquivo de configuração, digite o seguinte comando: sudo nano /etc/odoo.conf

Depois de abrir o arquivo de configuração, modifique a linha da senha mestra admin_passwd = $pbkdf2-sha... para admin_passwd = newpassword1234. Essa senha pode ser qualquer coisa, desde que seja salva temporariamente. Certifique-se de modificar todos os caracteres após o =.

Example

A linha aparece assim: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

A linha modificada aparece assim: admin_passwd = newpassword1234

Importante

É essencial que a senha seja alterada para outra coisa, em vez de acionar uma nova redefinição de senha adicionando um ponto-e-vírgula ; no início da linha. Isso garante que a base de dados esteja segura durante todo o processo de redefinição de senha.

Reiniciar o servidor do Odoo¶

Depois de definir a senha temporária, é necessário reiniciar o servidor do Odoo.

Para reiniciar o servidor do Odoo, primeiro, digite serviços na barra de pesquisaa do Windows. Em seguida, selecione o aplicativo Serviços e role para baixo até o serviço Odoo.

Em seguida, clique com o botão direito do mouse em Odoo e selecione Iniciar ou Reiniciar. Essa ação reinicia manualmente o servidor do Odoo.

Reinicie o servidor do Odoo digitando o comando: sudo service odoo15 restart

Nota

Altere o número após odoo para corresponder à versão específica em que o servidor está sendo executado.

Use a interface da web para criptografar novamente a senha¶

Primeiro, navegue até /web/database/manager ou http://server_ip:port/web/database/manager em um navegador.

Nota

Substitua server_ip pelo endereço IP da base de dados. Substitua port pela porta numerada da qual a base de dados pode ser acessada.

Em seguida, clique em Definir senha mestra e digite a senha temporária selecionada anteriormente no campo Senha mestra. Após essa etapa, digite uma Nova senha mestra. A Nova senha mestra é transformada em hash (ou criptografada), assim que o botão Continuar é clicado.

Nesse momento, a senha foi redefinida com êxito e uma versão com hash da nova senha aparece no arquivo de configuração.

Veja também

Para obter mais informações sobre a segurança da base de dados do Odoo, consulte esta documentação: Segurança do gerenciador da base de dados.

Navegadores compatíveis¶

Odoo supports the latest version of the following browsers.

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

1: para que várias instalações do Odoo usem a mesma base de dados PostgreSQL ou para fornecer mais recursos de computação para ambos os softwares.
2: Tecnicamente, uma ferramenta como socat pode ser usada para fazer proxy de soquetes UNIX em redes, mas isso é sobretudo para softwares que só podem ser usado em soquetes UNIX
3: ou ser acessível somente em uma rede interna comutada por pacotes, mas isso requer switches seguros, proteções contra ARP spoofing e impede o uso de Wi-Fi. Mesmo em redes seguras de comutação de pacotes, recomenda-se a implementação em HTTPS, e os possíveis custos são reduzidos, pois os certificados “autoassinados” são mais fáceis de implementar em um ambiente controlado do que na internet.

Edit on GitHub