Konfiguracja systemu¶

Ten dokument opisuje podstawowe kroki konfiguracji Odoo w środowisku produkcyjnym lub na serwerze dostępnym z internetu. Jest kontynuacją instalacji i generalnie nie jest konieczny w przypadku systemów deweloperskich, które nie są wystawione na internet.

Ostrzeżenie

Pokud nastavujete veřejný server, nezapomeňte zkontrolovat naše doporučení Uprawnienia!

dbfilter¶

Odoo je vícenájemní systém: jediný systém Odoo může provozovat a obsluhovat několik instancí databází. Je také vysoce přizpůsobitelný, přičemž přizpůsobení (počínaje načítanými moduly) závisí na „aktuální databázi”.

Toto není problém při práci s backendem (webovým klientem) jako přihlášený firemní uživatel: databázi lze vybrat při přihlášení a přizpůsobení načíst poté.

Je to však problém pro nepřihlášené uživatele (portál, webové stránky), kteří nejsou vázáni na databázi: Odoo potřebuje vědět, kterou databázi použít k načtení webové stránky nebo provedení operace. Pokud není používána vícenájemnost, není to problém, existuje pouze jedna databáze k použití, ale pokud je přístupných více databází, Odoo potřebuje pravidlo, které určí, kterou má použít.

To je jeden z účelů --db-filter: určuje, jak má být databáze vybrána na základě názvu hostitele (domény), který je požadován. Hodnotou je regulární výraz, případně včetně dynamicky vloženého názvu hostitele (%h) nebo první subdomény (%d), přes kterou je systém přístupný.

Pro servery hostující více databází v produkci, zejména pokud je používána webová stránka, musí být nastaven dbfilter, jinak nebude řada funkcí fungovat správně.

Ukázky konfigurace¶

Zobrazit pouze databáze s názvy začínajícími na «mycompany»

v konfiguračním souboru nastavte:

[options]
dbfilter = ^mycompany.*$

Zobrazit pouze databáze odpovídající první subdoméně po www: například databáze „mycompany” bude zobrazena, pokud byl příchozí požadavek odeslán na www.mycompany.com nebo mycompany.co.uk, ale ne pro www2.mycompany.com nebo helpdesk.mycompany.com.

v konfiguračním souboru nastavte:

[options]
dbfilter = ^%d$

Informacja

Nastavení správného --db-filter je důležitou součástí zabezpečení vašeho nasazení. Jakmile správně funguje a odpovídá pouze jedné databázi na jeden název hostitele, důrazně se doporučuje zablokovat přístup k obrazovkám správce databází a použít spouštěcí parametr --no-database-list k zabránění výpisu vašich databází a zablokování přístupu k obrazovkám správy databází. Viz také security.

PostgreSQL¶

Ve výchozím nastavení PostgreSQL povoluje připojení pouze přes UNIX sockety a zpětné smyčky (z „localhost”, stejného stroje, na kterém je nainstalován server PostgreSQL).

UNIX socket je v pořádku, pokud chcete, aby Odoo a PostgreSQL běžely na stejném stroji, a je to výchozí nastavení, pokud není zadán žádný hostitel, ale pokud chcete, aby Odoo a PostgreSQL běžely na různých strojích 1, bude muset naslouchat na síťových rozhraních 2, buď:

Přijímat pouze připojení zpětné smyčky a použít SSH tunel mezi strojem, na kterém běží Odoo, a tím, na kterém běží PostgreSQL, poté nakonfigurovat Odoo pro připojení ke svému konci tunelu
Přijímat připojení ke stroji, na kterém je nainstalováno Odoo, případně přes ssl (podrobnosti viz PostgreSQL connection settings), poté nakonfigurovat Odoo pro připojení přes síť

Ukázka konfigurace¶

Povolit tcp připojení na localhost
Povolit tcp připojení ze sítě 192.168.1.x

v /etc/postgresql/<VAŠE VERZE POSTGRESQL>/main/pg_hba.conf nastavte:

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

w /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf ustaw:

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

Konfiguracja Odoo¶

Po wyjęciu z pudełka Odoo łączy się z lokalnym postgresem przez gniazdo UNIX przez port 5432. Można to zmienić używając opcji bazy danych, gdy wdrożenie Postgres nie jest lokalne i/lub nie używa domyślnych ustawień instalacji.

Instalatory pakietów automatycznie utworzą nowego użytkownika (odoo) i ustawią go jako użytkownika bazy danych.

Ekrany zarządzania bazą danych są chronione ustawieniem admin_passwd. To ustawienie można ustawić tylko za pomocą plików konfiguracyjnych i jest po prostu sprawdzane przed wykonaniem zmian w bazie danych. Powinno być ustawione na losowo wygenerowaną wartość, aby zapewnić, że strony trzecie nie mogą używać tego interfejsu.
Wszystkie operacje na bazie danych używają opcji bazy danych, w tym ekran zarządzania bazą danych. Aby ekran zarządzania bazą danych działał, wymaga się, aby użytkownik PostgreSQL miał uprawnienie createdb.
Użytkownicy zawsze mogą usuwać bazy danych, których są właścicielami. Aby ekran zarządzania bazą danych był całkowicie niefunkcjonalny, użytkownik PostgreSQL musi zostać utworzony z no-createdb, a baza danych musi być własnością innego użytkownika PostgreSQL.

Ostrzeżenie
użytkownik PostgreSQL nie może być superużytkownikiem

Ukázka konfigurace¶

połącz się z serwerem PostgreSQL na 192.168.1.2
port 5432
używając konta użytkownika «odoo»,
z hasłem «pwd»
filtrując tylko bazy danych z nazwą zaczynającą się od «mycompany»

v konfiguračním souboru nastavte:

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

SSL między Odoo a PostgreSQL¶

Od wersji Odoo 11.0 można wymusić połączenie ssl między Odoo a PostgreSQL. W Odoo parametr db_sslmode kontroluje bezpieczeństwo ssl połączenia z wartością wybraną spośród «disable», «allow», «prefer», «require», «verify-ca» lub «verify-full»

Dokumentacja PostgreSQL

Wbudowany serwer¶

Odoo zawiera wbudowane serwery HTTP, cron i czatu na żywo, używające wielowątkowości lub wieloprocesowości.

Serwer wielowątkowy to prostszy serwer używany głównie do rozwoju, demonstracji i jego kompatybilności z różnymi systemami operacyjnymi (w tym Windows). Nowy wątek jest tworzony dla każdego nowego żądania HTTP, nawet dla długotrwałych połączeń takich jak websocket. Tworzone są również dodatkowe wątki cron działające w tle. Ze względu na ograniczenie Pythona (GIL) nie wykorzystuje najlepiej sprzętu.

Serwer wielowątkowy jest domyślnym serwerem, również dla kontenerów docker. Jest wybierany przez pominięcie opcji --workers lub ustawienie jej na 0.

Serwer wieloprocesowy to w pełni rozwinięty serwer używany głównie do produkcji. Nie podlega temu samemu ograniczeniu Pythona (GIL) dotyczącemu wykorzystania zasobów, a zatem najlepiej wykorzystuje sprzęt. Pula pracowników jest tworzona przy uruchomieniu serwera. Nowe żądania HTTP są kolejkowane przez system operacyjny, dopóki nie będzie gotowych pracowników do ich przetworzenia. Dodatkowy pracownik HTTP sterowany zdarzeniami dla czatu na żywo jest tworzony na alternatywnym porcie. Tworzone są również dodatkowe pracownicy cron. Konfigurowalny monitor zasobów monitoruje wykorzystanie zasobów i może zabijać/restartować nieudane procesy pracowników.

Serwer wieloprocesowy jest opcjonalny. Jest wybierany przez ustawienie opcji --workers na niezerową liczbę całkowitą.

Informacja

Ponieważ jest wysoce dostosowany do serwerów Linux, serwer wieloprocesowy nie jest dostępny w systemie Windows.

Obliczanie liczby workerów¶

Zasada: (#CPU * 2) + 1
Workery cron potrzebują CPU
1 worker ~= 6 jednoczesnych użytkowników

Obliczanie rozmiaru pamięci¶

Zakładamy, że 20% żądań to żądania ciężkie, a 80% to żądania prostsze
Ciężki worker, gdy wszystkie pola obliczane są dobrze zaprojektowane, zapytania SQL są dobrze zaprojektowane, … szacuje się, że zużywa około 1GB RAM
Lżejszy worker, w tym samym scenariuszu, szacuje się, że zużywa około 150MB RAM

Potrzebna RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

LiveChat¶

W trybie wieloprocesowym dedykowany worker LiveChat jest automatycznie uruchamiany i nasłuchuje na --gevent-port. Domyślnie żądania HTTP będą nadal kierowane do zwykłych workerów HTTP zamiast do workera LiveChat. Musisz wdrożyć proxy przed Odoo i przekierować przychodzące żądania, których ścieżka zaczyna się od /websocket/, do workera LiveChat. Musisz również uruchomić Odoo w trybie --proxy-mode, aby używało rzeczywistych nagłówków klienta (takich jak nazwa hosta, schemat i IP) zamiast nagłówków proxy.

Ukázka konfigurace¶

Serwer z 4 CPU, 8 wątków
60 jednoczesnych użytkowników
60 użytkowników / 6 = 10 <- teoretyczna liczba potrzebnych workerów
(4 * 2) + 1 = 9 <- teoretyczna maksymalna liczba workerów
Użyjemy 8 workerów + 1 dla cron. Użyjemy również systemu monitorowania do pomiaru obciążenia CPU i sprawdzimy, czy mieści się między 7 a 7,5.
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB RAM dla Odoo

w pliku konfiguracyjnym:

[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¶

Niezależnie od tego, czy dostęp odbywa się przez stronę internetową/klienta webowego czy usługę webową, Odoo przesyła informacje uwierzytelniające w postaci jawnego tekstu. Oznacza to, że bezpieczne wdrożenie Odoo musi używać HTTPS[#switching]_. Zakończenie SSL może być zaimplementowane za pomocą prawie każdego proxy zakończenia SSL, ale wymaga następującej konfiguracji:

Włącz tryb proxy Odoo. Powinien być włączony tylko wtedy, gdy Odoo działa za reverse proxy
Skonfiguruj proxy terminacji SSL (Nginx termination example)
Skonfiguruj samo proxy (Nginx proxying example)
Twoje proxy terminacji SSL powinno także automatycznie przekierowywać niezabezpieczone połączenia do bezpiecznego portu

Ukázka konfigurace¶

Przekierowanie żądań http do https
Przekierowanie żądań do odoo

v konfiguračním souboru nastavte:

proxy_mode = True

w /etc/nginx/sites-enabled/odoo.conf ustaw:

#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;
}

Wzmocnienie HTTPS¶

Dodaj nagłówek Strict-Transport-Security do wszystkich żądań, aby zapobiec wysyłaniu przez przeglądarki zwykłego żądania HTTP do tej domeny. Będziesz musiał utrzymywać działającą usługę HTTPS z ważnym certyfikatem dla tej domeny przez cały czas, w przeciwnym razie użytkownicy zobaczą ostrzeżenia bezpieczeństwa lub w ogóle nie będą mieli dostępu.

Wymuszanie połączeń HTTPS przez rok dla każdego odwiedzającego w NGINX za pomocą linii:

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

Dodatkową konfigurację można zdefiniować dla ciasteczka session_id. Można dodać flagę Secure, aby upewnić się, że nigdy nie jest przesyłane przez HTTP oraz SameSite=Lax, aby zapobiec uwierzytelnionemu CSRF.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo jako aplikacja WSGI¶

Możliwe jest również zamontowanie Odoo jako standardowej aplikacji WSGI. Odoo dostarcza podstawę skryptu uruchamiającego WSGI jako odoo-wsgi.example.py. Ten skrypt powinien być dostosowany (ewentualnie po skopiowaniu go z katalogu konfiguracyjnego), aby poprawnie ustawić konfigurację bezpośrednio w odoo.tools.config, a nie przez wiersz poleceń lub plik konfiguracyjny.

Jednak serwer WSGI będzie wystawiał tylko główny punkt końcowy HTTP dla klienta webowego, strony internetowej i API usług webowych. Ponieważ Odoo nie kontroluje już tworzenia workerów, nie może skonfigurować workerów cron ani czatu na żywo

Workery cron¶

Uruchomienie jednego z wbudowanych serwerów Odoo obok serwera WSGI jest wymagane do przetwarzania zadań cron. Ten serwer musi być skonfigurowany tak, aby przetwarzał tylko zadania cron, a nie żądania HTTP, używając opcji cli --no-http lub ustawienia pliku konfiguracyjnego http_enable = False.

W systemach linuksowych zaleca się użycie serwera wieloprocesowego zamiast wielowątkowego, aby uzyskać lepsze wykorzystanie sprzętu i zwiększoną stabilność, tj. używając opcji cli --workers=-1 i --max-cron-threads=n.

LiveChat¶

Użycie serwera WSGI kompatybilnego z gevent jest wymagane do prawidłowego działania funkcji czatu na żywo. Ten serwer powinien być w stanie obsłużyć wiele jednoczesnych długotrwałych połączeń, ale nie potrzebuje dużej mocy obliczeniowej. Wszystkie żądania, których ścieżka zaczyna się od /websocket/, powinny być kierowane do tego serwera. Zwykły serwer WSGI (oparty na wątkach/procesach) powinien być używany do wszystkich innych żądań.

Serwer cron Odoo może być również używany do obsługi żądań czatu na żywo. Wystarczy usunąć opcję cli --no-http z serwera cron i upewnić się, że żądania, których ścieżka zaczyna się od /websocket/, są kierowane do tego serwera, albo na --http-port (serwer wielowątkowy), albo na --gevent-port (serwer wieloprocesowy).

Serwowanie plików statycznych i załączników¶

Dla wygody programistów Odoo bezpośrednio udostępnia wszystkie pliki statyczne i załączniki w swoich modułach. Może to nie być idealne pod względem wydajności, a pliki statyczne powinny być zazwyczaj udostępniane przez statyczny serwer HTTP.

Udostępnianie plików statycznych¶

Pliki statyczne Odoo znajdują się w folderze static/ każdego modułu, więc pliki statyczne mogą być udostępniane przez przechwytywanie wszystkich żądań do /MODULE/static/FILE i wyszukiwanie odpowiedniego modułu (i pliku) w różnych ścieżkach dodatków.

Zaleca się ustawienie nagłówka Content-Security-Policy: default-src 'none' dla wszystkich obrazków dostarczanych przez serwer WWW. Nie jest to ściśle konieczne, ponieważ użytkownicy nie mogą modyfikować/wstrzykiwać treści w folderze static/ modułów, a istniejące obrazy są finalne (nie pobierają samodzielnie nowych zasobów). Jednak jest to dobra praktyka.

Przy użyciu powyższej konfiguracji NGINX (https) należy dodać następujące bloki map i location, aby udostępniać pliki statyczne przez 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;
    }
}

Rzeczywiste dyrektywy root i try_files zależą od twojej instalacji, w szczególności od --addons-path.

Example

Załóżmy, że Odoo zostało zainstalowane za pośrednictwem pakietów debiana dla wersji Community i Enterprise, a --addons-path wynosi '/usr/lib/python3/dist-packages/odoo/addons'.

Dyrektywy root i try_files powinny brzmieć:

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

Załóżmy, że Odoo zostało zainstalowane ze źródeł, że repozytoria git Community i Enterprise zostały sklonowane odpowiednio w /opt/odoo/community i /opt/odoo/enterprise, a --addons-path wynosi '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

Dyrektywy root i try_files powinny brzmieć:

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

Udostępnianie załączników¶

Załączniki to pliki przechowywane w repozytorium plików, do których dostęp jest regulowany przez Odoo. Nie mogą być bezpośrednio dostępne przez statyczny serwer WWW, ponieważ dostęp do nich wymaga wielu wyszukiwań w bazie danych w celu określenia, gdzie są przechowywane pliki i czy bieżący użytkownik może uzyskać do nich dostęp.

Niemniej jednak, gdy plik zostanie zlokalizowany i prawa dostępu zweryfikowane przez Odoo, dobrym pomysłem jest serwowanie pliku za pomocą statycznego serwera web zamiast Odoo. Aby Odoo mogło delegować serwowanie plików do statycznego serwera web, rozszerzenia X-Sendfile (apache) lub X-Accel (nginx) muszą być włączone i skonfigurowane na statycznym serwerze web. Po skonfigurowaniu uruchom Odoo z flagą CLI --x-sendfile (ta pojedyncza flaga jest używana zarówno dla X-Sendfile, jak i X-Accel).

Informacja

Rozszerzenie X-Sendfile dla apache (i kompatybilnych serwerów WWW) nie wymaga żadnej dodatkowej konfiguracji.
Rozszerzenie X-Accel dla NGINX wymaga następującej dodatkowej konfiguracji:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
    add_header Content-Security-Policy $upstream_http_content_security_policy;
    add_header X-Content-Type-Options nosniff;
}
```
Jeśli nie wiesz, jaka jest ścieżka do repozytorium plików, uruchom Odoo z opcją --x-sendfile i przejdź bezpośrednio do adresu URL /web/filestore przez Odoo (nie przechodz do adresu URL przez NGINX). Spowoduje to zarejestrowanie ostrzeżenia, którego komunikat zawiera potrzebną konfigurację.

Uprawnienia¶

Na początek należy pamiętać, że zabezpieczanie systemu informatycznego to proces ciągły, a nie jednorazowa operacja. W każdej chwili będziesz tylko tak bezpieczny, jak najsłabsze ogniwo w twoim środowisku.

Dlatego nie traktuj tej sekcji jako ostatecznej listy środków, które zapobiegną wszystkim problemom z bezpieczeństwem. Ma ona jedynie służyć jako podsumowanie pierwszych ważnych rzeczy, które powinienes uwzględnić w swoim planie działań w zakresie bezpieczeństwa. Resztę stanowią najlepsze praktyki bezpieczeństwa dla twojego systemu operacyjnego i dystrybucji, najlepsze praktyki w zakresie użytkowników, haseł i zarządzania kontrolą dostępu itp.

Wdrażając serwer dostępny z internetu, uwzględnij następujące tematy związane z bezpieczeństwem:

Zawsze ustaw silne hasło superadministratora i ogranicz dostęp do stron zarządzania bazą danych zaraz po skonfigurowaniu systemu. Zobacz Bezpieczeństwo menedżera baz danych.
Wybierz unikalne loginy i silne hasła dla wszystkich kont administratorów we wszystkich bazach danych. Nie używaj «admin» jako loginu. Nie używaj tych loginów do codziennych operacji, tylko do kontrolowania/zarządzania instalacją. Nigdy nie używaj żadnych domyślnych haseł takich jak admin/admin, nawet dla baz testowych/przejściowych.
Nie instaluj danych demonstracyjnych na serwerach dostępnych z internetu. Bazy danych z danymi demonstracyjnymi zawierają domyślne loginy i hasła, które mogą zostać użyte do dostania się do twoich systemów i spowodowania poważnych problemów, nawet w systemach przejściowych/deweloperskich.
Użyj odpowiednich filtrów baz danych (--db-filter), aby ograniczyć widoczność twoich baz danych według nazwy hosta. Zobacz dbfilter. Możesz również użyć -d, aby podać własną (oddzieloną przecinkami) listę dostępnych baz danych do filtrowania, zamiast pozwalać systemowi pobrać je wszystkie z backendu bazy danych.
Gdy twoja db_name i dbfilter są skonfigurowane i pasują tylko do jednej bazy danych na nazwę hosta, powinieneś ustawić opcję konfiguracji list_db na False, aby całkowicie zapobiec listowaniu baz danych i zablokować dostęp do ekranów zarządzania bazą danych (jest to również udostępnione jako opcja linii poleceń --no-database-list)
Upewnij się, że użytkownik PostgreSQL (--db_user) nie jest super-użytkownikiem i że twoje bazy danych są własnością innego użytkownika. Na przykład mogą być własnością super-użytkownika postgres, jeśli używasz dedykowanego nieuprzywilejowanego db_user. Zobacz również Konfiguracja Odoo.
Utrzymuj instalacje zaktualizowane, regularnie instalując najnowsze wersje, poprzez GitHub lub pobierając najnowszą wersję z https://www.odoo.com/page/download lub http://nightly.odoo.com
Skonfiguruj swój serwer w trybie wieloprocesowym z odpowiednimi limitami pasującymi do typowego użycia (pamięć/CPU/limity czasu). Zobacz również Wbudowany serwer.
Uruchom Odoo za serwerem WWW zapewniającym zakończenie HTTPS z ważnym certyfikatem SSL, aby zapobiec podsłuchiwaniu komunikacji w postaci jawnej. Certyfikaty SSL są tanie, a istnieje wiele darmowych opcji. Skonfiguruj serwer proxy, aby ograniczyć rozmiar żądań, ustaw odpowiednie limity czasu, a następnie włącz opcję proxy mode. Zobacz również HTTPS.
Jeśli musisz zezwolić na zdalny dostęp SSH do swoich serwerów, upewnij się, że ustawiłeś silne hasło dla wszystkich kont, nie tylko dla root. Zdecydowanie zaleca się całkowite wyłączenie uwierzytelniania opartego na hasłach i zezwolenie tylko na uwierzytelnianie za pomocą klucza publicznego. Rozważ również ograniczenie dostępu przez VPN, zezwolenie tylko na zaufane adresy IP w zaporze ogniowej i/lub uruchomienie systemu wykrywania ataków siłowych, takiego jak fail2ban lub równoważnego.
Rozważ zainstalowanie odpowiedniego ograniczania szybkości na swoim serwerze proxy lub zaporze ogniowej, aby zapobiec atakom siłowym i atakom typu odmowa usługi. Zobacz również Blokowanie ataków siłowych dla konkretnych środków.

Wielu dostawców sieci zapewnia automatyczne łagodzenie ataków typu rozproszona odmowa usługi (DDOS), ale często jest to usługa opcjonalna, więc powinieneś skonsultować się z nimi.
Kiedy tylko jest to możliwe, hostuj swoje publiczne instancje demo/testowe/przejściowe na innych maszynach niż produkcyjne. I stosuj te same środki ostrożności co dla produkcji.
Jeśli twój publicznie dostępny serwer Odoo ma dostęp do wrażliwych wewnętrznych zasobów sieciowych lub usług (np. przez prywatny VLAN), wdróż odpowiednie reguły zapory ogniowej, aby chronić te zasoby wewnętrzne. Zapewni to, że serwer Odoo nie może być użyty przypadkowo (lub w wyniku złośliwych działań użytkownika) do uzyskania dostępu lub zakłócenia tych zasobów wewnętrznych. Zazwyczaj można to zrobić, stosując wychodzącą domyślną regułę DENY na zaporze ogniowej, a następnie tylko wyraźnie autoryzując dostęp do zasobów wewnętrznych, do których serwer Odoo musi uzyskać dostęp. Systemd IP traffic access control może być również przydatne do implementacji kontroli dostępu do sieci dla poszczególnych procesów.
Jeśli twój publicznie dostępny serwer Odoo znajduje się za zaporą aplikacji webowych, load-balancerem, przezroczystą usługą ochrony DDoS (jak CloudFlare) lub podobnym urządzeniem sieciowym, możesz chcieć uniknąć bezpośredniego dostępu do systemu Odoo. Zasadniczo trudno jest zachować adresy IP punktów końcowych serwerów Odoo w tajemnicy. Na przykład mogą pojawić się w logach serwera WWW podczas odpytywania systemów publicznych lub w nagłówkach e-maili wysyłanych z Odoo. W takiej sytuacji możesz skonfigurować zaporę ogniową tak, aby punkty końcowe nie były publicznie dostępne z wyjątkiem określonych adresów IP twojego WAF, load-balancera lub usługi proxy. Dostawcy usług, tacy jak CloudFlare, zazwyczaj utrzymują publiczną listę swoich zakresów adresów IP w tym celu.
Jeśli hostujesz wielu klientów, izoluj dane klientów i pliki od siebie nawzajem, używając kontenerów lub odpowiednich technik „jail”.
Skonfiguruj codzienne kopie zapasowe swoich baz danych i danych filestore oraz kopiuj je na zdalny serwer archiwizacyjny, który nie jest dostępny z samego serwera.
Wdrażanie Odoo na Linuksie jest zdecydowanie zalecane nad Windows. Jeśli mimo to zdecydujesz się wdrożyć na platformie Windows, należy przeprowadzić dokładny przegląd zabezpieczeń serwera, co wykracza poza zakres tego przewodnika.

Blokowanie ataków siłowych¶

W przypadku wdrożeń dostępnych z internetu ataki siłowe na hasła użytkowników są bardzo powszechne i nie należy lekceważyć tego zagrożenia dla serwerów Odoo. Odoo emituje wpis w logu przy każdej próbie logowania i zgłasza wynik: sukces lub porażkę, wraz z docelowym loginem i źródłowym IP.

Wpisy w logu będą miały następującą formę.

Nieudane logowanie:

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

Udane logowanie:

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

Te dzienniki mogą być łatwo analizowane przez system zapobiegania włamaniom, taki jak fail2ban.

Na przykład następująca definicja filtra fail2ban powinna pasować do nieudanego logowania:

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

Można to wykorzystać z definicją więzienia, aby zablokować atakujący adres IP na HTTP(S).

Oto jak mogłoby to wyglądać przy blokowaniu adresu IP na 15 minut, gdy wykryto 10 nieudanych prób logowania z tego samego adresu IP w ciągu 1 minuty:

[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

Bezpieczeństwo menedżera baz danych¶

Konfiguracja Odoo wspomniał mimochodem o admin_passwd.

To ustawienie jest używane na wszystkich ekranach zarządzania bazami danych (do tworzenia, usuwania, zrzucania lub przywracania baz danych).

Jeśli ekrany zarządzania nie powinny być w ogóle dostępne, należy ustawić opcję konfiguracji list_db na False, aby zablokować dostęp do wszystkich ekranów wyboru i zarządzania bazami danych.

Ostrzeżenie

Zdecydowanie zaleca się wyłączenie menedżera baz danych dla każdego systemu dostępnego z internetu! Jest to narzędzie programistyczne/demonstracyjne, które ułatwia szybkie tworzenie i zarządzanie bazami danych. Nie jest przeznaczone do użytku produkcyjnego i może nawet udostępniać niebezpieczne funkcje atakującym. Nie jest również zaprojektowane do obsługi dużych baz danych i może przekroczyć limity pamięci.

W systemach produkcyjnych operacje zarządzania bazami danych powinny być zawsze wykonywane przez administratora systemu, w tym tworzenie nowych baz danych i automatyczne kopie zapasowe.

Należy ustawić odpowiedni parametr db_name (i opcjonalnie również dbfilter), aby system mógł określić docelową bazę danych dla każdego żądania, w przeciwnym razie użytkownicy zostaną zablokowani, ponieważ nie będą mogli sami wybrać bazy danych.

Jeśli ekrany zarządzania mają być dostępne tylko z wybranego zestawu maszyn, użyj funkcji serwera proxy, aby zablokować dostęp do wszystkich tras zaczynających się od /web/database z wyjątkiem (być może) /web/database/selector, który wyświetla ekran wyboru bazy danych.

Jeśli ekran zarządzania bazą danych ma pozostać dostępny, ustawienie admin_passwd musi zostać zmienione z domyślnej wartości admin: to hasło jest sprawdzane przed zezwoleniem na operacje modyfikacji bazy danych.

Powinno być przechowywane bezpiecznie i powinno być wygenerowane losowo, np.

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

co generuje 32-znakowy pseudolosowy ciąg znaków drukowalnych.

Zresetuj hasło główne¶

Mogą wystąpić sytuacje, gdy hasło główne zostanie zgubione lub skompromitowane i wymaga resetowania. Poniższy proces jest przeznaczony dla administratorów systemu lokalnej bazy danych Odoo i szczegółowo opisuje, jak ręcznie zresetować i ponownie zaszyfrować hasło główne.

Zobacz także

Konto Odoo.com

Podczas tworzenia nowej lokalnej bazy danych generowane jest losowe hasło główne. Odoo zaleca użycie tego hasła do zabezpieczenia bazy danych. To hasło jest implementowane domyślnie, więc dla każdego lokalnego wdrożenia Odoo istnieje bezpieczne hasło główne.

Ostrzeżenie

Podczas tworzenia bazy danych Odoo w trybie on-premise instalacja jest dostępna dla każdego w internecie, dopóki nie zostanie ustawione to hasło w celu zabezpieczenia bazy danych.

Hasło główne jest określone w pliku konfiguracyjnym Odoo (odoo.conf lub odoorc (plik ukryty)). Hasło główne Odoo jest potrzebne do modyfikacji, tworzenia lub usuwania bazy danych przez graficzny interfejs użytkownika (GUI).

Zlokalizuj plik konfiguracyjny¶

Najpierw otwórz plik konfiguracyjny Odoo (odoo.conf lub odoorc (plik ukryty)).

Plik konfiguracyjny znajduje się w: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

W zależności od tego, jak Odoo jest zainstalowane na maszynie Linux, plik konfiguracyjny znajduje się w jednym z dwóch różnych miejsc:

Instalacja z pakietu: /etc/odoo.conf
Instalacja ze źródeł: ~/.odoorc

Zmień stare hasło¶

Po otwarciu odpowiedniego pliku przystąp do modyfikacji starego hasła w pliku konfiguracyjnym na hasło tymczasowe.

Po zlokalizowaniu pliku konfiguracyjnego otwórz go za pomocą (GUI). Można to osiągnąć poprzez zwykłe dwukrotne kliknięcie pliku. Następnie urządzenie powinno mieć domyślny GUI, którym można otworzyć plik.

Następnie zmodyfikuj linię hasła głównego admin_passwd = $pbkdf2-sha… na admin_passwd = newpassword1234, na przykład. Hasło to może być dowolne, o ile zostanie tymczasowo zapisane. Upewnij się, że modyfikujesz wszystkie znaki po =.

Example

Linia wygląda następująco: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

Zmodyfikowana linia wygląda następująco: admin_passwd = newpassword1234

Zmodyfikuj linię hasła głównego za pomocą następującego polecenia Unix opisanego poniżej.

Połącz się z terminalem serwera Odoo za pomocą protokołu Secure Shell (SSH) i edytuj plik konfiguracyjny. Aby zmodyfikować plik konfiguracyjny, wprowadź następujące polecenie: sudo nano /etc/odoo.conf

Po otwarciu pliku konfiguracyjnego zmodyfikuj linię hasła głównego admin_passwd = $pbkdf2-sha… na admin_passwd = newpassword1234. Hasło to może być dowolne, o ile zostanie tymczasowo zapisane. Upewnij się, że modyfikujesz wszystkie znaki po =.

Example

Linia wygląda następująco: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

Zmodyfikowana linia wygląda następująco: admin_passwd = newpassword1234

Ważne

Kluczowe jest, aby hasło zostało zmienione na inne, zamiast wyzwalać nowe resetowanie hasła poprzez dodanie średnika ; na początku linii. Zapewnia to bezpieczeństwo bazy danych podczas całego procesu resetowania hasła.

Uruchom ponownie serwer Odoo¶

Po ustawieniu tymczasowego hasła wymagane jest ponowne uruchomienie serwera Odoo.

Aby uruchomić ponownie serwer Odoo, najpierw wpisz services w pasku Wyszukiwania Windows. Następnie wybierz aplikację Usługi i przewiń w dół do usługi Odoo.

Następnie kliknij prawym przyciskiem myszy na Odoo i wybierz Uruchom lub Uruchom ponownie. Ta czynność ręcznie uruchamia ponownie serwer Odoo.

Uruchom ponownie serwer Odoo wpisując polecenie: sudo service odoo15 restart

Informacja

Zmień numer po odoo, aby dopasować go do konkretnej wersji, na której działa serwer.

Użyj interfejsu webowego do ponownego zaszyfrowania hasła¶

Najpierw przejdź do /web/database/manager lub http://server_ip:port/web/database/manager w przeglądarce.

Informacja

Zastąp server_ip adresem IP bazy danych. Zastąp port numerowanym portem, z którego baza danych jest dostępna.

Następnie kliknij Ustaw hasło główne i wpisz wcześniej wybrane hasło tymczasowe w polu Hasło główne. Po tym kroku wpisz Nowe hasło główne. Nowe hasło główne jest haszowane (lub szyfrowane) po kliknięciu przycisku Kontynuuj.

W tym momencie hasło zostało pomyślnie zresetowane, a zahaszowana wersja nowego hasła pojawia się teraz w pliku konfiguracyjnym.

Zobacz także

Więcej informacji na temat bezpieczeństwa bazy danych Odoo można znaleźć w tej dokumentacji: Bezpieczeństwo menedżera baz danych.

Obsługiwane przeglądarki¶

Odoo obsługuje najnowszą wersję następujących przeglądarek.

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

1: aby wiele instalacji Odoo korzystało z tej samej bazy danych PostgreSQL lub aby zapewnić więcej zasobów obliczeniowych dla obu programów.
2: technicznie narzędzie takie jak socat może być użyte do przekierowywania gniazd UNIX przez sieci, ale jest to głównie dla oprogramowania, które może być używane tylko przez gniazda UNIX
3: lub być dostępny tylko przez wewnętrzną sieć komutowaną pakietowo, ale wymaga to zabezpieczonych przełączników, ochrony przed ARP spoofing i wyklucza użycie WiFi. Nawet w zabezpieczonych sieciach komutowanych pakietowo zalecane jest wdrożenie przez HTTPS, a możliwe koszty są niższe, ponieważ „samopodpisane” certyfikaty są łatwiejsze do wdrożenia w kontrolowanym środowisku niż w internecie.

Edytuj na GitHub