Rendszerkonfiguráció

Ez a dokumentum az Odoo éles környezetben vagy internetre néző szerveren történő beállításának alapvető lépéseit írja le. Követi a telepítést, és általában nem szükséges olyan fejlesztési rendszerekhez, amelyek nincsenek kitéve az internetnek.

Figyelem

Ha nyilvános szervert állít be, mindenképpen ellenőrizze biztonsági ajánlásainkat!

dbfilter

Odoo is a multi-tenant system: a single Odoo system may run and serve a number of database instances. It is also highly customizable, with customizations (starting from the modules being loaded) depending on the „current database”.

Ez nem jelent problémát, amikor a háttérben (web kliens) dolgozunk bejelentkezett vállalati felhasználóként: az adatbázis kiválasztható a bejelentkezéskor, és a testreszabások utána betöltődnek.

Azonban ez problémát jelent a nem bejelentkezett felhasználók (portál, weboldal) esetében, akik nincsenek adatbázishoz kötve: Odoo-nak tudnia kell, melyik adatbázist kell használni a weboldal oldalának betöltéséhez vagy a művelet végrehajtásához. Ha a több-bérlős megoldás nincs használatban, ez nem jelent problémát, csak egy adatbázis van használatban, de ha több adatbázis érhető el, Odoo-nak szüksége van egy szabályra, hogy tudja, melyiket kell használnia.

Ez az egyik célja a --db-filter opciónak: meghatározza, hogyan kell kiválasztani az adatbázist a kért hosztnév (domain) alapján. Az érték egy reguláris kifejezés, amely tartalmazhatja a dinamikusan beillesztett hosztnevet (%h) vagy az első aldomaint (%d), amelyen keresztül a rendszer elérhető.

Több adatbázist tartalmazó szerverek esetén a termelésben, különösen ha a website van használatban, a dbfilter kötelezően beállítandó, különben számos funkció nem fog megfelelően működni.

Konfigurációs minták

  • Csak azokat az adatbázisokat mutassa, amelyek neve «mycompany»-val kezdődik

a konfigurációs fájlban állítsa be:

[options]
dbfilter = ^mycompany.*$

  • Show only databases matching the first subdomain after www: for example the database „mycompany” will be shown if the incoming request was sent to www.mycompany.com or mycompany.co.uk, but not for www2.mycompany.com or helpdesk.mycompany.com.

a konfigurációs fájlban állítsa be:

[options]
dbfilter = ^%d$

Megjegyzés

A megfelelő --db-filter beállítása fontos része a telepítés biztonságának. Ha helyesen működik, és csak egy adatbázist illeszt hosztnévenként, erősen ajánlott blokkolni az adatbázis kezelő képernyőkhöz való hozzáférést, és használni a --no-database-list indítási paramétert az adatbázisok listázásának megakadályozására, valamint blokkolni az adatbázis kezelő képernyőkhöz való hozzáférést. Lásd még security.

PostgreSQL

By default, PostgreSQL only allows connection over UNIX sockets and loopback connections (from „localhost”, the same machine the PostgreSQL server is installed on).

A UNIX socket megfelelő, ha azt szeretné, hogy az Odoo és a PostgreSQL ugyanazon a gépen fusson, és ez az alapértelmezett, ha nincs megadva hoszt, de ha azt szeretné, hogy az Odoo és a PostgreSQL különböző gépeken fusson 1, akkor szükséges, hogy hálózati interfészekre hallgasson 2, akár:

  • Csak a loopback kapcsolatokat fogadja el, és használjon SSH alagutat azon gép között, amelyen az Odoo fut, és azon, amelyen a PostgreSQL fut, majd konfigurálja az Odoo-t, hogy csatlakozzon az alagút végéhez

  • Fogadja a kapcsolatokat azon gépre, amelyen az Odoo telepítve van, esetleg ssl-en keresztül (részletekért lásd a PostgreSQL kapcsolat beállításait), majd konfigurálja az Odoo-t, hogy hálózaton keresztül csatlakozzon

Konfigurációs minta

  • Engedélyezze a tcp kapcsolatot a localhoston

  • Engedélyezze a tcp kapcsolatot a 192.168.1.x hálózatról

az /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf fájlban állítsa be:

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

az /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf fájlban állítsa be:

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

Odoo konfigurálása

Alapértelmezés szerint az Odoo egy helyi postgreshez csatlakozik UNIX socketen keresztül a 5432-es porton. Ez felülírható a adatbázis opciók használatával, ha a Postgres telepítése nem helyi és/vagy nem az alapértelmezett telepítési beállításokat használja.

A csomagolt telepítők automatikusan létrehoznak egy új felhasználót (odoo), és beállítják azt adatbázis felhasználóként.

  • Az adatbázis-kezelő képernyőket az admin_passwd beállítás védi. Ez a beállítás csak konfigurációs fájlok használatával állítható be, és egyszerűen ellenőrzésre kerül az adatbázis módosítások végrehajtása előtt. Véletlenszerűen generált értékre kell beállítani, hogy harmadik felek ne használhassák ezt a felületet.

  • Minden adatbázis művelet a adatbázis opciókat használja, beleértve az adatbázis-kezelő képernyőt is. Az adatbázis-kezelő képernyő működéséhez szükséges, hogy a PostgreSQL felhasználónak createdb joga legyen.

  • A felhasználók mindig törölhetik az általuk birtokolt adatbázisokat. Ahhoz, hogy az adatbázis-kezelő képernyő teljesen működésképtelen legyen, a PostgreSQL felhasználót no-createdb joggal kell létrehozni, és az adatbázisnak egy másik PostgreSQL felhasználó tulajdonában kell lennie.

    Figyelem

    a PostgreSQL felhasználó nem lehet szuperfelhasználó

Konfigurációs minta

  • csatlakozás egy PostgreSQL szerverhez a 192.168.1.2 címen

  • 5432 port

  • egy «odoo» felhasználói fiók használatával,

  • «pwd» jelszóval

  • csak azokat az adatbázisokat szűrve, amelyek neve «mycompany»-val kezdődik

a konfigurációs fájlban állítsa be:

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

SSL Odoo és PostgreSQL között

Az Odoo 11.0 óta lehetőség van az Odoo és a PostgreSQL közötti SSL kapcsolat kényszerítésére. Az Odoo-ban a db_sslmode szabályozza a kapcsolat SSL biztonságát, a következő értékek közül választva: «disable», «allow», «prefer», «require», «verify-ca» vagy «verify-full».

PostgreSQL Doc

Beépített szerver

Az Odoo beépített HTTP, cron és élő csevegés szervereket tartalmaz, amelyek több szálú vagy több folyamatú működést használnak.

A több szálú szerver egy egyszerűbb szerver, amelyet elsősorban fejlesztéshez, bemutatókhoz és különböző operációs rendszerekkel (beleértve a Windows-t is) való kompatibilitása miatt használnak. Minden új HTTP kéréshez, még a hosszú élettartamú kapcsolatokhoz, mint például a websocket, új szál indul. További démonikus cron szálak is indulnak. Egy Python korlátozás (GIL) miatt nem használja ki a hardver lehetőségeit a legjobban.

A több szálú szerver az alapértelmezett szerver, még a docker konténerek esetében is. Ezt úgy választják ki, hogy kihagyják a --workers opciót, vagy 0-ra állítják.

A több folyamatú szerver egy teljes értékű szerver, amelyet elsősorban termelésre használnak. Nem vonatkozik rá ugyanaz a Python korlátozás (GIL) az erőforrás-használatra, így a legjobban kihasználja a hardver lehetőségeit. A szerver indításakor egy munkáscsoport jön létre. Az új HTTP kéréseket az operációs rendszer sorba állítja, amíg a munkások készen nem állnak azok feldolgozására. Egy extra eseményvezérelt HTTP munkás az élő csevegéshez egy alternatív porton indul. További cron munkások is indulnak. Egy konfigurálható folyamatfigyelő figyeli az erőforrás-használatot, és képes megölni/újraindítani a hibás munkásokat.

A több folyamatú szerver választható. Ezt úgy választják ki, hogy a --workers opciót nem nulla egész számra állítják.

Megjegyzés

Mivel erősen testreszabott Linux szerverekhez, a több folyamatú szerver nem érhető el Windows rendszeren.

Dolgozói számítás

  • Ökölszabály: (#CPU * 2) + 1

  • Cron munkavállalók CPU-t igényelnek

  • 1 munkavállaló ~= 6 egyidejű felhasználó

memóriaméret számítás

  • Úgy tekintjük, hogy a kérések 20%-a nehéz kérés, míg 80%-a egyszerűbb

  • Egy nehéz munkavállaló, amikor minden számított mező jól van megtervezve, az SQL kérések jól vannak megtervezve, … körülbelül 1GB RAM-ot fogyaszt

  • Egy könnyebb munkavállaló, ugyanebben a forgatókönyvben, körülbelül 150MB RAM-ot fogyaszt

Szükséges RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Élő Csevegés

Többprocesszoros üzemmódban egy dedikált LiveChat munkavállaló automatikusan elindul, és figyel a --gevent-port porton. Alapértelmezés szerint a HTTP kérések továbbra is a normál HTTP munkavállalókat érik el ahelyett, hogy a LiveChat munkavállalót. Proxy-t kell telepítenie az Odoo elé, és átirányítania azokat a bejövő kéréseket, amelyek útvonala /websocket/-tel kezdődik, a LiveChat munkavállalóra. Az Odoo-t is el kell indítania --proxy-mode módban, hogy a valódi kliens fejléceket (mint például a hosztnév, séma és IP) használja a proxy helyett.

Konfigurációs minta

  • Szerver 4 CPU-val, 8 szál

  • 60 egyidejű felhasználó

  • 60 felhasználó / 6 = 10 <- elméleti szükséges munkavállalók száma

  • (4 * 2) + 1 = 9 <- elméleti maximális munkavállalók száma

  • 8 munkavállalót fogunk használni + 1-et a cron számára. Használni fogunk egy monitorozó rendszert is a CPU terhelés mérésére, és ellenőrizzük, hogy 7 és 7.5 között van-e.

  • RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB RAM az Odoo számára

a konfigurációs fájlban:

[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

Akár weboldalon/web kliensen, akár webszolgáltatáson keresztül érik el, az Odoo tiszta szövegként továbbítja a hitelesítési információkat. Ez azt jelenti, hogy az Odoo biztonságos telepítéséhez HTTPS-t kell használni3. Az SSL terminálás szinte bármilyen SSL terminálási proxyval megvalósítható, de a következő beállítást igényli:

  • Engedélyezze az Odoo proxy mode opcióját. Ezt csak akkor szabad engedélyezni, ha az Odoo egy fordított proxy mögött van

  • Állítsa be az SSL termináló proxy-t (Nginx termination example)

  • Állítsa be magát a proxyzást (Nginx proxying example)

  • Az SSL termináló proxy-nak automatikusan át kell irányítania a nem biztonságos kapcsolatokat a biztonságos portra

Konfigurációs minta

  • Irányítsa át a http kéréseket https-re

  • Proxy kérések továbbítása az odoo felé

a konfigurációs fájlban állítsa be:

proxy_mode = True

az /etc/nginx/sites-enabled/odoo.conf fájlban állítsa be:

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

HTTPS megerősítése

Adja hozzá a Strict-Transport-Security fejlécet minden kéréshez, hogy megakadályozza a böngészőket abban, hogy valaha is egyszerű HTTP kérést küldjenek erre a domainre. Mindig működőképes HTTPS szolgáltatást kell fenntartania érvényes tanúsítvánnyal ezen a domainen, különben a felhasználói biztonsági figyelmeztetéseket fognak látni, vagy teljesen képtelenek lesznek elérni azt.

Kényszerítse a HTTPS kapcsolatok használatát egy éven keresztül minden látogató számára az NGINX-ben a következő sorral:

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

További konfigurációk határozhatók meg a session_id sütihez. A Secure zászló hozzáadható annak biztosítására, hogy soha ne kerüljön továbbításra HTTP-n keresztül, és a SameSite=Lax az autentikált CSRF megelőzésére.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo mint WSGI alkalmazás

Lehetőség van az Odoo-t szabványos WSGI alkalmazásként is telepíteni. Az Odoo biztosítja a WSGI indító szkript alapját odoo-wsgi.example.py néven. Ezt a szkriptet testre kell szabni (esetleg a telepítési könyvtárból való másolás után), hogy a konfigurációt közvetlenül a odoo.tools.config modulban állítsa be, nem pedig a parancssoron vagy egy konfigurációs fájlon keresztül.

Azonban a WSGI szerver csak a fő HTTP végpontot fogja kitenni a web kliens, weboldal és webszolgáltatás API számára. Mivel az Odoo már nem irányítja a munkavállalók létrehozását, nem tudja beállítani a cron vagy élő chat munkavállalókat.

Cron munkavállalók

Az egyik beépített Odoo szerver indítása a WSGI szerver mellett szükséges a cron feladatok feldolgozásához. Ezt a szervert úgy kell konfigurálni, hogy csak a cronokat dolgozza fel, és ne fogadjon HTTP kéréseket a --no-http parancssori opció vagy a http_enable = False konfigurációs fájl beállítás használatával.

Linux-szerű rendszereken ajánlott a több-folyamatos szerver használata a több-szálas helyett, hogy jobb hardverhasználatot és nagyobb stabilitást érjünk el, azaz a --workers=-1 és --max-cron-threads=n parancssori opciók használatával.

Élő Csevegés

Az élő chat funkció helyes működéséhez gevent-kompatibilis WSGI szerver használata szükséges. Ennek a szervernek képesnek kell lennie sok egyidejű, hosszú élettartamú kapcsolat kezelésére, de nem igényel sok feldolgozási teljesítményt. Minden kérés, amelynek útvonala /websocket/-tel kezdődik, erre a szerverre kell irányuljon. Minden más kéréshez egy hagyományos (szál/folyamat-alapú) WSGI szervert kell használni.

Az Odoo cron szerver is használható az élő chat kérések kiszolgálására. Egyszerűen hagyja el a --no-http parancssori opciót a cron szerverről, és győződjön meg róla, hogy a /websocket/-tel kezdődő útvonalú kérések erre a szerverre irányulnak, akár a --http-port (több-szálas szerver), akár a --gevent-port (több-folyamatos szerver) használatával.

Statikus fájlok és mellékletek kiszolgálása

A fejlesztés kényelme érdekében az Odoo közvetlenül szolgálja ki az összes statikus fájlt és mellékletet a moduljaiban. Ez nem feltétlenül ideális a teljesítmény szempontjából, és a statikus fájlokat általában egy statikus HTTP szervernek kellene kiszolgálnia.

Statikus fájlok kiszolgálása

Az Odoo statikus fájljai minden modul static/ mappájában találhatók, így a statikus fájlok kiszolgálhatók az összes /MODULE/static/FILE kérés elfogásával, és a megfelelő modul (és fájl) megkeresésével a különböző bővítmények útvonalain.

Ajánlott a Content-Security-Policy: default-src 'none' fejléc beállítása az összes web szerver által kiszolgált képre. Ez nem feltétlenül szükséges, mivel a felhasználók nem módosíthatják/injektálhatják a tartalmat a modulok static/ mappájába, és a meglévő képek véglegesek (nem töltenek le új erőforrásokat önmagukban). Azonban ez jó gyakorlat.

A fenti NGINX (https) konfiguráció használatával a következő map és location blokkokat kell hozzáadni a statikus fájlok NGINX általi kiszolgálásához.

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

A tényleges root és try_files direktívák a telepítéstől függnek, különösen a --addons-path beállítástól.

Example

Tegyük fel, hogy az Odoo a debian csomagok segítségével lett telepítve a Community és Enterprise verziókhoz, és hogy a --addons-path '/usr/lib/python3/dist-packages/odoo/addons'.

A root és try_files a következő legyen:

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

Mellékletek kiszolgálása

A mellékletek olyan fájlok, amelyek a filestore-ban vannak tárolva, és amelyekhez való hozzáférést az Odoo szabályozza. Ezekhez nem lehet közvetlenül hozzáférni egy statikus webszerveren keresztül, mivel a hozzáférésükhöz több adatbázis-keresés szükséges annak meghatározásához, hogy hol vannak a fájlok tárolva, és hogy az aktuális felhasználó hozzáférhet-e ezekhez vagy sem.

Mindazonáltal, miután a fájl megtalálásra került és az Odoo által az elérési jogok ellenőrizve lettek, érdemes a fájlt a statikus webszerver segítségével kiszolgálni az Odoo helyett. Ahhoz, hogy az Odoo a fájlok kiszolgálását a statikus webszerverre delegálja, az X-Sendfile (apache) vagy X-Accel (nginx) kiterjesztéseket engedélyezni és konfigurálni kell a statikus webszerveren. Miután ez beállításra került, indítsa el az Odoo-t az --x-sendfile CLI kapcsolóval (ez az egyedi kapcsoló mind az X-Sendfile, mind az X-Accel esetében használatos).

Megjegyzés

  • Az X-Sendfile kiterjesztés az apache (és kompatibilis webszerverek) esetében nem igényel semmilyen kiegészítő konfigurációt.

  • Az X-Accel kiterjesztés az NGINX esetében valóban igényli a következő kiegészítő konfigurációt:

    location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}

    Ha nem tudja, mi a filestore elérési útja, indítsa el az Odoo-t az --x-sendfile opcióval, és navigáljon közvetlenül az /web/filestore URL-re az Odoo-n keresztül (ne navigáljon az URL-re az NGINX-en keresztül). Ez figyelmeztetéseket naplóz, az üzenet tartalmazza a szükséges konfigurációt.

Biztonság

Először is, tartsa szem előtt, hogy egy információs rendszer biztonságának biztosítása egy folyamatos folyamat, nem pedig egyszeri művelet. Bármely pillanatban csak annyira lesz biztonságos, amennyire a környezetének leggyengébb láncszeme.

Ezért kérjük, ne tekintse ezt a részt az összes biztonsági probléma megelőzésére szolgáló végső intézkedések listájának. Csupán összefoglalója az első fontos dolgoknak, amelyeket biztosan be kell építenie a biztonsági akciótervébe. A többi a legjobb biztonsági gyakorlatokból fog származni az operációs rendszeréhez és disztribúciójához, a felhasználók, jelszavak és hozzáférés-vezérlés kezelésének legjobb gyakorlataiból stb.

Amikor internetre néző szervert telepít, kérjük, vegye figyelembe a következő biztonsággal kapcsolatos témákat:

  • Mindig állítson be erős szuper-admin admin jelszót, és korlátozza a hozzáférést az adatbázis-kezelő oldalakhoz, amint a rendszer be van állítva. Lásd: Adatbázis Kezelő Biztonság.

  • Válasszon egyedi bejelentkezéseket és erős jelszavakat minden adminisztrátori fiókhoz az összes adatbázisban. Ne használja az «admin» bejelentkezést. Ne használja ezeket a bejelentkezéseket a napi műveletekhez, csak a telepítés irányításához/kezeléséhez. Soha ne használjon alapértelmezett jelszavakat, mint például admin/admin, még tesztelési/előzetes rendszerek esetén sem.

  • Ne telepítsen demó adatokat internetre néző szerverekre. A demó adatokkal rendelkező adatbázisok alapértelmezett bejelentkezéseket és jelszavakat tartalmaznak, amelyekkel be lehet jutni a rendszereibe, és jelentős problémákat okozhatnak, még előzetes/fejlesztési rendszereken is.

  • Használjon megfelelő adatbázis szűrőket ( --db-filter) az adatbázisok láthatóságának korlátozására a hosztnév szerint. Lásd: dbfilter. Használhatja a -d opciót is, hogy saját (vesszővel elválasztott) listát adjon meg az elérhető adatbázisokról, amelyeket szűrni szeretne, ahelyett, hogy a rendszer mindet lekérné az adatbázis háttérből.

  • Miután a db_name és dbfilter beállításai úgy vannak konfigurálva, hogy csak egyetlen adatbázist illesszenek hosztnévenként, állítsa a list_db konfigurációs opciót False értékre, hogy teljesen megakadályozza az adatbázisok listázását, és blokkolja az adatbázis-kezelő képernyőkhöz való hozzáférést (ez a --no-database-list parancssori opcióként is elérhető)

  • Győződjön meg róla, hogy a PostgreSQL felhasználó (--db_user) nem szuper-felhasználó, és hogy az adatbázisok egy másik felhasználó tulajdonában vannak. Például lehetnek a postgres szuper-felhasználó tulajdonában, ha egy dedikált, nem privilegizált db_user-t használ. Lásd még: Odoo konfigurálása.

  • Tartsa naprakészen a telepítéseket azáltal, hogy rendszeresen telepíti a legújabb build-eket, akár a GitHub-on keresztül, akár a legújabb verzió letöltésével a https://www.odoo.com/page/download vagy http://nightly.odoo.com oldalról.

  • Konfigurálja a szerverét többfolyamatú módban, megfelelő korlátokkal, amelyek megfelelnek a tipikus használatának (memória/CPU/időkorlátok). Lásd még: Beépített szerver.

  • Futtassa az Odoo-t egy web szerver mögött, amely HTTPS végződést biztosít érvényes SSL tanúsítvánnyal, hogy megakadályozza a tiszta szövegű kommunikáció lehallgatását. Az SSL tanúsítványok olcsók, és sok ingyenes lehetőség létezik. Konfigurálja a web proxy-t a kérések méretének korlátozására, állítson be megfelelő időkorlátokat, majd engedélyezze a proxy mode opciót. Lásd még: HTTPS.

  • Ha távoli SSH hozzáférést kell engedélyeznie a szervereihez, győződjön meg róla, hogy minden fiókhoz erős jelszót állít be, nem csak a root-hoz. Erősen ajánlott a jelszó alapú hitelesítést teljesen letiltani, és csak a nyilvános kulcs alapú hitelesítést engedélyezni. Fontolja meg továbbá a hozzáférés korlátozását VPN-en keresztül, csak megbízható IP-k engedélyezését a tűzfalban, és/vagy egy brute-force felismerő rendszer, mint például a fail2ban vagy annak megfelelője futtatását.

  • Fontolja meg megfelelő sebességkorlátozás telepítését a proxyján vagy tűzfalán, hogy megakadályozza a brute-force támadásokat és a szolgáltatásmegtagadási támadásokat. Lásd még Brute Force Támadások Blokkolása a konkrét intézkedésekért.

    Számos hálózati szolgáltató automatikus enyhítést biztosít az elosztott szolgáltatásmegtagadási támadások (DDOS) ellen, de ez gyakran opcionális szolgáltatás, ezért konzultáljon velük.

  • Amikor csak lehetséges, a nyilvános demó/teszt/staging példányait külön gépeken hosztolja, mint a termelési példányokat. És alkalmazza ugyanazokat a biztonsági óvintézkedéseket, mint a termelés esetében.

  • Ha a nyilvános Odoo szervere hozzáfér érzékeny belső hálózati erőforrásokhoz vagy szolgáltatásokhoz (pl. privát VLAN-on keresztül), alkalmazzon megfelelő tűzfalszabályokat ezeknek a belső erőforrásoknak a védelmére. Ez biztosítja, hogy az Odoo szerver ne legyen véletlenül (vagy rosszindulatú felhasználói tevékenységek eredményeként) használható ezen belső erőforrások elérésére vagy megzavarására. Általában ezt úgy lehet megtenni, hogy egy kimenő alapértelmezett TILTÁS szabályt alkalmaz a tűzfalon, majd csak kifejezetten engedélyezi a hozzáférést azokhoz a belső erőforrásokhoz, amelyekhez az Odoo szervernek hozzá kell férnie. Systemd IP forgalom hozzáférés-vezérlés szintén hasznos lehet a folyamatonkénti hálózati hozzáférés-vezérlés megvalósításához.

  • Ha a nyilvános Odoo szervere egy Webalkalmazás Tűzfal, egy terheléselosztó, egy átlátszó DDoS védelmi szolgáltatás (mint például a CloudFlare) vagy egy hasonló hálózati szintű eszköz mögött van, érdemes elkerülni az Odoo rendszer közvetlen elérését. Általában nehéz titokban tartani az Odoo szerverek végponti IP-címeit. Például megjelenhetnek a webszerver naplóiban, amikor nyilvános rendszereket kérdeznek le, vagy az Odoo-ból küldött e-mailek fejlécében. Ilyen helyzetben érdemes lehet úgy konfigurálni a tűzfalát, hogy a végpontok ne legyenek nyilvánosan elérhetők, kivéve a WAF, terheléselosztó vagy proxy szolgáltatás konkrét IP-címeiről. A szolgáltatók, mint például a CloudFlare, általában nyilvános listát tartanak fenn az IP-cím tartományaikról erre a célra.

  • If you are hosting multiple customers, isolate customer data and files from each other using containers or appropriate „jail” techniques.

  • Állítson be napi biztonsági mentéseket az adatbázisairól és a fájltároló adatairól, és másolja azokat egy távoli archiváló szerverre, amely nem elérhető magáról a szerverről.

  • Az Odoo Linuxon történő telepítése erősen ajánlott a Windows helyett. Ha mégis úgy dönt, hogy Windows platformon telepít, alapos biztonsági megerősítési felülvizsgálatot kell végezni a szerveren, amely kívül esik ezen útmutató hatáskörén.

Brute Force Támadások Blokkolása

Az internetre néző telepítések esetén a felhasználói jelszavak elleni brute force támadások nagyon gyakoriak, és ezt a fenyegetést nem szabad elhanyagolni az Odoo szerverek esetében. Az Odoo naplóbejegyzést készít, amikor egy bejelentkezési kísérlet történik, és jelenti az eredményt: siker vagy kudarc, a cél bejelentkezéssel és a forrás IP-vel együtt.

A naplóbejegyzések a következő formátumúak lesznek.

Sikertelen bejelentkezés:

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

Sikeres bejelentkezés:

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

Ezeket a naplókat könnyen elemezheti egy behatolásmegelőző rendszer, mint például a fail2ban.

Például a következő fail2ban szűrődefiníciónak illeszkednie kell egy sikertelen bejelentkezéshez:

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

Ez használható egy börtön definícióval, hogy blokkolja a támadó IP-t HTTP(S) alatt.

Így nézhet ki, ha 15 percre blokkoljuk az IP-t, amikor 10 sikertelen bejelentkezési kísérletet észlelünk ugyanarról az IP-ről 1 percen belül:

[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

Adatbázis Kezelő Biztonság

Odoo konfigurálása említette az admin_passwd-t futólag.

Ez a beállítás az összes adatbázis-kezelő képernyőn használatos (adatbázisok létrehozására, törlésére, mentésére vagy visszaállítására).

Ha a kezelőfelületek egyáltalán nem lehetnek elérhetők, állítsa be a list_db konfigurációs opciót False értékre, hogy blokkolja az összes adatbázis kiválasztási és kezelési képernyőhöz való hozzáférést.

Figyelem

Nyomatékosan ajánlott a Database Manager letiltása minden internetre nyitott rendszeren! Ez egy fejlesztési/bemutató eszköz, amely megkönnyíti az adatbázisok gyors létrehozását és kezelését. Nem tervezett éles használatra, és akár veszélyes funkciókat is felfedhet a támadók számára. Nem tervezték nagy adatbázisok kezelésére sem, és memória korlátokat is kiválthat.

Éles rendszereken az adatbázis-kezelési műveleteket mindig a rendszergazdának kell elvégeznie, beleértve az új adatbázisok létrehozását és az automatikus biztonsági mentéseket.

Győződjön meg róla, hogy megfelelő db_name paramétert állít be (és opcionálisan dbfilter-t is), hogy a rendszer meg tudja határozni a céladatbázist minden kéréshez, különben a felhasználók blokkolva lesznek, mivel nem választhatják ki maguk az adatbázist.

Ha a kezelőfelületek csak egy kiválasztott gépcsoportból legyenek elérhetők, használja a proxy szerver funkcióit az összes /web/database-el kezdődő útvonalhoz való hozzáférés blokkolására, kivéve (esetleg) a /web/database/selector-t, amely az adatbázis-választó képernyőt jeleníti meg.

Ha az adatbázis-kezelő képernyő elérhető marad, a admin_passwd beállítást meg kell változtatni az alapértelmezett admin értékről: ezt a jelszót ellenőrzik, mielőtt engedélyeznék az adatbázis-módosító műveleteket.

Biztonságosan kell tárolni, és véletlenszerűen kell generálni, pl.

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

amely egy 32 karakter hosszú pszeudorandom nyomtatható karakterláncot generál.

A mester jelszó visszaállítása

Előfordulhatnak olyan esetek, amikor a mester jelszó elveszik vagy kompromittálódik, és vissza kell állítani. Az alábbi folyamat az Odoo helyszíni adatbázis rendszergazdáinak szól, részletezve, hogyan lehet manuálisan visszaállítani és újra titkosítani a mester jelszót.

Lásd még

További információ az Odoo.com fiók jelszavának megváltoztatásáról ebben a dokumentációban található: Odoo.com fiók jelszó módosítása.

Amikor új helyszíni adatbázist hoz létre, egy véletlenszerű mester jelszó generálódik. Az Odoo javasolja ennek a jelszónak a használatát az adatbázis biztonságának érdekében. Ez a jelszó alapértelmezés szerint van beállítva, így minden Odoo helyszíni telepítéshez van egy biztonságos mester jelszó.

Figyelem

Amikor Odoo helyszíni adatbázist hoz létre, a telepítés bárki számára elérhető az interneten, amíg ezt a jelszót nem állítják be az adatbázis biztonságának érdekében.

A mester jelszó az Odoo konfigurációs fájlban van megadva (odoo.conf vagy odoorc (rejtett fájl)). Az Odoo mester jelszóra van szükség az adatbázis módosításához, létrehozásához vagy törléséhez a grafikus felhasználói felületen (GUI) keresztül.

Konfigurációs fájl megkeresése

Először nyissa meg az Odoo konfigurációs fájlt (odoo.conf vagy odoorc (rejtett fájl)).

A konfigurációs fájl itt található: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

Régi jelszó megváltoztatása

Miután a megfelelő fájl megnyílt, folytassa a régi jelszó módosítását a konfigurációs fájlban egy ideiglenes jelszóra.

A konfigurációs fájl megtalálása után nyissa meg egy (GUI) segítségével. Ezt egyszerűen a fájlra duplán kattintva érheti el. Ekkor az eszköznek rendelkeznie kell egy alapértelmezett GUI-val a fájl megnyitásához.

Ezután módosítsa a mester jelszó sort admin_passwd = $pbkdf2-sha…-ról admin_passwd = newpassword1234-re, például. Ez a jelszó bármi lehet, amennyiben ideiglenesen el van mentve. Ügyeljen arra, hogy az = utáni összes karaktert módosítsa.

Example

A sor így néz ki: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

A módosított sor így néz ki: admin_passwd = newpassword1234

Fontos

Lényeges, hogy a jelszó valami másra legyen változtatva, ahelyett, hogy új jelszó visszaállítást indítana el egy pontosvessző ; hozzáadásával a sor elejére. Ez biztosítja, hogy az adatbázis biztonságban maradjon a teljes jelszó visszaállítási folyamat során.

Indítsa újra az Odoo szervert

Az ideiglenes jelszó beállítása után az Odoo szerver újraindítása szükséges.

Az Odoo szerver újraindításához először írja be a services szót a Windows Keresés mezőbe. Ezután válassza ki a Szolgáltatások alkalmazást, és görgessen le az Odoo szolgáltatásig.

Ezután kattintson jobb gombbal az Odoo-ra, és válassza a Indítás vagy Újraindítás lehetőséget. Ez a művelet manuálisan újraindítja az Odoo szervert.

Használja a webes felületet a jelszó újratitkosításához

Először navigáljon a /web/database/manager vagy http://server_ip:port/web/database/manager címre egy böngészőben.

Megjegyzés

Cserélje le a server_ip-t az adatbázis IP-címére. Cserélje le a port-ot arra a számozott portra, amelyen az adatbázis elérhető.

Ezután kattintson a Set Master Password gombra, és írja be a korábban kiválasztott ideiglenes jelszót a Master Password mezőbe. Ezt követően írjon be egy New Master Password-t. A New Master Password hashelve (vagy titkosítva) lesz, miután a Continue gombra kattint.

Ezen a ponton a jelszó sikeresen vissza lett állítva, és az új jelszó hashelt változata most már megjelenik a konfigurációs fájlban.

Lásd még

További információkért az Odoo adatbázis biztonságáról, lásd ezt a dokumentációt: Adatbázis Kezelő Biztonság.

Támogatott böngészők

Az Odoo a következő böngészők legújabb verzióját támogatja.

  • Google Chrome

  • Mozilla Firefox

  • Microsoft Edge

  • Apple Safari

1

több Odoo telepítés használatához ugyanazt a PostgreSQL adatbázist, vagy több számítási erőforrás biztosításához mindkét szoftver számára.

2

technikailag egy olyan eszköz, mint a socat használható UNIX socketek hálózatokon keresztüli proxyzására, de ez főként olyan szoftverek esetében van, amelyek csak UNIX socketeken keresztül használhatók

3

or be accessible only over an internal packet-switched network, but that requires secured switches, protections against ARP spoofing and precludes usage of WiFi. Even over secure packet-switched networks, deployment over HTTPS is recommended, and possible costs are lowered as „self-signed” certificates are easier to deploy on a controlled environment than over the internet.