システム設定¶

このドキュメントでは、本番環境またはインターネットに公開されたサーバで Odoo をセットアップするための基本的な手順を説明します。これは installation に従うものであり、インターネット上に公開されていない開発システムでは一般的に必要ありません。

警告

公開サーバをセットアップする場合は、セキュリティの推奨事項を必ず確認して下さい!

データベースフィルター¶

Odooはマルチテナントシステムです。つまり、1つのOdooシステムで複数のデータベースインスタンスを実行し、サービスを提供することができます。また、高度なカスタマイズが可能であり、カスタマイズ（読み込まれるモジュールから開始）は "現在のデータベース" に依存します。

これは、会社ユーザとしてログインしてバックエンド(ウェブクライアント)で作業している場合には問題になりません。ログイン時にデータベースを選択でき、その後でカスタマイズを読み込むことができます。

しかし、これはデータベースに紐づけられていない非ログインユーザ(ポータル、ウェブサイト)に関する問題です。Odooはウェブサイトページの読み込みやオペレーションの実行にどのデータベースを使用すべきかを把握する必要があります。マルチテナントが使用されていない場合は問題ありません。使用するデータベースは1つだけです。しかし、複数のデータベースにアクセスできる場合は、Odooは使用すべきデータベースを把握するための規則が必要です。

--db-filter の目的の1つは、リクエストされたホスト名(ドメイン)に基づいてデータベースを選択する方法を指定することです。値は 正規表現 であり、システムにアクセスする際に使用される動的に挿入されたホスト名(%h)または最初のサブドメイン(%d)を含めることができます。

プロダクトで複数のデータベースをホスティングするサーバでは、特に ウェブサイト を使用している場合は、dbfilter を設定する必要があります。そうしないと、多くの機能が正しく動作しません。

設定サンプル¶

Show only databases with names beginning with 'mycompany'

設定ファイルで以下を設定します:

[options]
dbfilter = ^mycompany.*$

www の後の最初のサブドメインに一致するデータベースのみを表示します。例えば、受信リクエストが www.mycompany.com または``mycompany.co.uk`` に送信された場合、データベース "mycompany" が表示されますが、www2.mycompany.com または ``helpdesk.mycompany.com``には適用されません。

設定ファイルで以下を設定します:

[options]
dbfilter = ^%d$

注釈

適切な --db-filter を設定することは、デプロイのセキュリティ確保において重要です。ホスト名ごとに単一のデータベースのみに一致するよう正しく動作するようになったら、データベースマネジャー画面へのアクセスをブロックし、データベースのリストを防止するために起動パラメータとして --no-database-list を使用し、データベース管理画面へのアクセスをブロックすることを強くお勧めします。 security も参照して下さい。

PostgreSQL¶

デフォルトでは、PostgreSQLはUNIXソケット経由とループバック接続( "localhost"、つまりPostgreSQLサーバがインストールされているのと同じマシンからの接続) のみを許可します。

OdooとPostgreSQLを同じマシンで実行する場合はUNIXソケットで問題ありません。ホストが指定されていない場合はデフォルトでUNIXソケットが使用されますが、OdooとPostgreSQLを異なるマシンで実行する場合は、1 ネットワークインターフェースをリッスンする 2 必要があります。

ループバック接続のみを受け入れ、Odooが動作するマシンとPostgreSQLが動作するマシンとの間で SSHトンネルを使用し、その後、Odooをトンネルの終端に接続するように設定します。
Odooがインストールされているマシンへの接続を受け入れ、必要に応じてSSL経由で接続します(詳細は PostgreSQL接続設定を参照)。その後、ネットワーク経由で接続するようにOdooを設定します。

設定サンプル¶

localhostでのTCP接続を許可します。
192.168.1.xネットワークからのTCP接続を許可します。

in /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf set:

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

/etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf 内で以下を設定します:

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

Odooの設定¶

Odooは、デフォルトではポート5432を介してUNIXソケット経由でローカルのPostgresに接続します。Postgresがローカルに展開されていない場合、および/またはインストール時のデフォルト設定を使用していない場合は、:ref:`データベースオプション <reference/cmdline/server/database>`を使用してこれを上書きすることができます。

パッケージインストーラは、自動的に新しいユーザ (odoo) を作成し、それをデータベースユーザとして設定します。

データベース管理画面は admin_passwd 設定により保護されています。この設定は設定ファイルを使用してのみ設定でき、データベースの変更を行う前に確認されます。このインターフェースを第三者が使用できないようにするため、ランダムに生成された値を設定する必要があります。
データベース管理画面を含め、全てのデータベースオペレーションは、データベースオプションを使用します。データベース管理画面が機能するには、PostgreSQLユーザに``createdb`` (データベース作成)権限が必要です。
ユーザは、常に自分自身が所有するデータベースを削除することができます。データベース管理画面を完全に無効にするには、PostgreSQLユーザを``no-createdb`` (データベース作成なし)で作成し、データベースを別のPostgreSQLユーザが所有している必要があります。

警告
PostgreSQLユーザはスーパーユーザであっては いけません

設定サンプル¶

192.168.1.2でPostgreSQLに接続
ポート5432
'odoo' ユーザアカウントを使用、
パスワードとして 'pwd' を使用
filtering only db with a name beginning with 'mycompany'

設定ファイルで以下を設定します:

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

SSL OdooとPostgreSQLの間¶

Odoo 11.0 以降では、Odoo と PostgreSQL の間の SSL 接続を強制することができます。 Odoo では、db_sslmode により、'disable'、'allow'、'prefer'、'require'、'verify-ca'、または 'verify-full' から選択した値で、接続の SSL セキュリティを制御します。

PostgreSQL ドキュメント

ビルトインサーバ¶

Odooには、マルチスレッドまたはマルチプロセッシングを使用するHTTP、cron、ライブチャットのサーバが組み込まれています。

マルチスレッド サーバは、主に開発、デモンストレーション、および(Windowsを含む)各種オペレーティングシステムとの互換性のために使用される、よりシンプルなサーバです。ウェブソケットのような長寿命の接続の場合でも、新しいHTTPリクエストごとに新しいスレッドが生成されます。また、追加のデーモンcronスレッドも生成されます。Pythonの制限(GIL)により、ハードウェアを最大限に活用はできません。

マルチスレッドサーバは、デフォルトのサーバであり、Dockerコンテナでも同様です。このサーバは、--workers オプションを省略するか、または 0 に設定することで選択されます。

マルチプロセッシング サーバは、主にプロダクト用に使用される本格的なサーバです。リソース使用におけるPythonの制限（GIL）を受けないため、ハードウェアを最大限に活用できます。ワーカーのプールはサーバの起動時に作成されます。新しいHTTPリクエストは、処理可能なワーカーが準備できるまでOSによってキューに入れられます。ライブチャット用の追加のイベント駆動型HTTPワーカーは代替ポートで生成されます。追加のcronワーカーも生成されます。設定可能なプロセスリーパーがリソース使用を監視し、失敗したワーカーを終了または再起動することができます。

マルチプロセッシングサーバはオプトインです。--workers オプションを非Null整数値に設定することで選択します。

注釈

Linuxサーバ向けに高度にカスタマイズされているため、マルチプロセッシングサーバはWindowsではご利用頂けません。

ワーカー数計算¶

経験則 : (#CPU * 2) + 1
CronワーカーはCPUが必要です
1ワーカー ~= 6 同時ユーザ

メモリサイズ計算¶

リクエストの20%は負荷の高いリクエストであり、80%はよりシンプルなリクエストであると考えています。
負荷の高いワーカー、全ての計算フィールドが適切に設計されている場合、SQLリクエストが適切に設計されている場合、... 1GBのRAMを消費すると推定されます。
同じシナリオで、より負荷の低いワーカーは、RAMを約150MB消費すると推定されます。

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

LiveChat¶

マルチプロセッシングでは、専用の LiveChat ワーカーが自動的に開始され、--gevent-port をリッスンします。デフォルトでは、HTTP リクエストは LiveChat ワーカーではなく、通常の HTTP ワーカーにアクセスし続けます。 Odoo の前にプロキシを配置し、パスが /websocket/ で始まる受信リクエストを LiveChat ワーカーにリダイレクトする必要があります。また、Odoo を --proxy-mode で起動し、プロキシの代わりに実際のクライアントヘッダー(ホスト名、スキーム、IP など)を使用するようにする必要があります。

設定サンプル¶

サーバー4 CPU, 8スレッド
同時使用ユーザ: 60
60 ユーザ / 6 = 10 <- 必要とされるワーカー数の理論値
(4 * 2) + 1 = 9 <- 理論上の最大ワーカー数
8人の作業員と1人のcronを使用します。また、CPU負荷を測定する監視システムを使用し、CPU負荷が7から7.5の間にあることを確認します。
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB RAM for Odoo

設定ファイル内:

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

ウェブサイト/ウェブクライアントまたはウェブサービス経由でアクセスされる場合、Odooは認証情報を平文で送信します。つまり、Odooを安全に展開するには HTTPS3 を使用する必要があります。SSL終端は、ほぼすべてのSSL終端プロキシ経由で実装できますが、以下の設定が必要です。

Odooの:option:プロキシモード <odoo-bin --proxy-mode> を有効にします。これは、Odooがリバースプロキシの後ろにある場合にのみ有効にする必要があります。
SSL終端プロキシの設定 (Nginx終了例)
プロキシ自体の設定 (Nginx proxying example)
また、SSL終端プロキシは、非セキュア接続をセキュアポートに自動的にリダイレクトする必要があります。

設定サンプル¶

HTTPリクエストをHTTPSにリダイレクトする
Odooへのプロキシリクエスト

設定ファイルで以下を設定します:

proxy_mode = True

/etc/nginx/sites-enabled/odoo.conf 内で設定:

#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 強化¶

ブラウザがこのドメインに平文のHTTPリクエストを送信しないようにするため、全てのリクエストに Strict-Transport-Security ヘッダを追加します。このドメインで常に有効な証明書付きの稼働中のHTTPSサービスを維持する必要があります。そうでないと、ユーザにセキュリティ警告が表示されたり、アクセスできなくなったりします。

NGINXで、すべての訪問者に対して1年間にわたってHTTPS接続を強制するには、次の行を使用します:

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

Additional configuration can be defined for the session_id cookie. The Secure flag can be added to ensure it is never transmitted over HTTP and SameSite=Lax to prevent authenticated CSRF.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

WSGIアプリケーションとしてのOdoo¶

Odooを標準のWSGIアプリケーションとしてマウントすることも可能です。OdooはWSGIランチャースクリプトの基盤として odoo-wsgi.example.py を提供しています。そのスクリプトは、コマンドラインや設定ファイルではなく、odoo.tools.config に直接設定を正しく行うために(おそらくセットアップディレクトリからコピーした後で)カスタマイズする必要があります。

しかし、WSGIサーバはウェブクライアント、ウェブサイト、ウェブサービスAPI用のメインのHTTPエンドポイントのみを公開します。Odooはワーカーの作成を制御しなくなったため、クロンやライブチャットワーカーを設定できなくなりました。

クロンワーカー¶

WSGIサーバの隣にOdooの組み込みサーバを起動することは、クロンジョブを処理するために必要です。そのサーバは、--no-http コマンドラインオプションまたは http_enable = False 設定ファイル設定を使用して、クロンのみを処理し、HTTPリクエストを処理しないように設定する必要があります。

Linux系システムでは、マルチスレッドサーバよりもマルチプロセッシングサーバを使用することを推奨します。これにより、ハードウェアの使用効率が向上し、安定性も高まります。例えば、コマンドラインオプションとして --workers=-1 および --max-cron-threads=n を使用します。

LiveChat¶

ライブチャット機能の正常なオペレーションには、geventと互換性のあるWSGIサーバの使用が必要です。そのサーバは、多数の同時かつ長時間にわたる接続を処理できる必要がありますが、高い処理能力は必要ありません。パスが /websocket/ で始まる全てのリクエストは、そのサーバに送信されなければなりません。その他の全てのリクエストには、通常の（スレッド/プロセス基盤の）WSGIサーバを使用して下さい。

Odooクロンサーバは、ライブチャットのリクエストに応答するためにも使用できます。クロンサーバから --no-http コマンドラインオプションを削除し、パスが /websocket/ で始まるリクエストがこのサーバに送信されるようにします。 --http-port <odoo-bin --http-port>` (マルチスレッドサーバ)または --gevent-port (マルチプロセッシングサーバ) のいずれかです。

静的ファイルと添付ファイルの提供¶

開発の利便性を考慮して、Odooはモジュール内の全ての静的ファイルと添付ファイルを直接提供します。パフォーマンスの観点では理想的ではないかもしれません。静的ファイルは通常、静的HTTPサーバによって提供されるべきです。

静的ファイルの提供¶

Odooの静的ファイルは各モジュールの static/ フォルダに配置されているため、静的ファイルは /MODULE/static/FILE への全てのリクエストを傍受し、適切なモジュール(およびファイル)を様々なアドオンのパスから探し出すことで提供することができます。

ウェブサーバから配信される全ての画像に対して、コンテンツ-セキュリティ-ポリシー: default-src 'なし' ヘッダを設定することを推奨します。ユーザがモジュールの static/ フォルダ内のコンテンツを修正/挿入できないこと、また既存の画像は最終的なものである(それ自体で新しいリソースを取得しない)ことから、厳密には必要ではありませんが、グッドプラクティスです。

上記のNGINX(https)設定を使用して、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;
    }
}

実際の root および try_files ディレクティブは、インストール、特に --addons-path に依存します。

Example

Odooがコミュニティおよびエンタープライズ向けの debianパッケージ でインストールされ、--addons-path が``'/usr/lib/python3/dist-packages/odoo/addons'`` であるとします。

root と try_files は以下である必要があります:

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

Odooが ソース 経由でインストールされ、コミュニティおよびエンタープライズのgitリポジトリがそれぞれ /opt/odoo/community および:file:/opt/odoo/enterprise にクローンされ、オプション :--addons-path <odoo-bin --addons-path> が '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise' であることを確認して下さい。

root と try_files は以下である必要があります:

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

添付ファイルの提供¶

添付ファイルは、Odooによってアクセスが規制されているファイルストアに保存されているファイルです。静的ウェブサーバから直接アクセスすることはできません。アクセスするには、ファイルが保存されている場所と、現在のユーザがアクセスできるかどうかを判断するために、データベースで複数の検索を行う必要があります。

とはいえ、ファイルが特定され、Odooによってアクセス権が確認された後は、Odooではなく静的ウェブサーバを使用してファイルを配信するのが良いでしょう。Odooがファイルの送信を静的ウェブサーバに委任するには、X-Sendfile (apache) または X-Accel (nginx) 拡張機能を有効にし、静的ウェブサーバ上で設定する必要があります。設定が完了したら、CLIフラグ --x-sendfile でOdooを起動します(この一意のフラグは、X-SendfileとX-Accelの両方に使用されます)。

注釈

Apache(および互換性のあるウェブサーバ)用のX-Sendfile拡張機能は、追加の設定は必要ありません。
NGINX用のX-Accel拡張機能では、以下の追加設定が 必要です。
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
ファイルストアへのパスがわからない場合は、Odoo を --x-sendfile オプション付きで起動し、Odoo から直接 /web/filestore URL に移動して下さい。(NGINX 経由で URL に移動しないで下さい)。これにより警告が記録され、そのメッセージに必要な設定が含まれています。

セキュリティ¶

まず、情報システムのセキュリティ確保は、一度限りのオペレーションではなく、継続的なプロセスであることを念頭に置いて下さい。どんな時でも、環境の中で最も脆弱な部分が、セキュリティのレベルを決定します。

よって、このセクションを、全てのセキュリティ問題を防ぐための究極の対策リストとして捉えないで下さい。これは、セキュリティ対策計画に必ず盛り込むべき重要な事項の概要を提示しているにすぎません。残りの部分は、オペレーティングシステムやディストリビューションのベストプラクティス、ユーザ、パスワード、アクセス制御管理などのベストプラクティスから得られます。

インターネットに公開するサーバを導入する際には、以下のセキュリティ関連のトピックを必ず考慮して下さい。

常に強力なスーパー管理者および管理者のパスワードを設定し、システムが設定されたらすぐにデータベース管理ページへのアクセスを制限して下さい。参照：db_manager_security。
全てのデータベース上の全ての管理者アカウントには、固有のログイン名と強力なパスワードを設定してください。ログイン名として "admin" を使用しないで下さい。これらのログイン名は、インストールを制御/管理する場合のみに使用し、日常的なオペレーションには使用しないで下さい。テスト/ステージングデータベースであっても、admin/adminなどのデフォルトパスワードを決して使用しないで下さい。
インターネットに公開されているサーバにデモデータをインストールしないで下さい。デモデータを含むデータベースには、デフォルトのログイン名とパスワードが含まれており、それを使用してシステムに侵入し、ステージング/開発システムであっても深刻な問題を引き起こす可能性があります。
適切なデータベースフィルタ (--db-filter) を使用して、ホスト名に応じてデータベースの可視性を制限します。データベースフィルター (データベースフィルタ)を参照して下さい。また、-d を使用して、フィルタリングから除外するデータベースの (カンマ区切りの) リストを指定することもできます。この場合、システムがデータベースバックエンドから全てを取得するのではなく、指定したデータベースのみを取得します。
db_name と dbfilter が設定され、ホスト名ごとに単一のデータベースのみに一致するようになったら、データベースの一覧表示を完全に防止し、データベース管理画面へのアクセスをブロックするために、list_db 設定オプションを False に設定して下さい。(これは、コマンドラインオプション --no-database-list としても利用できます)。
PostgreSQLユーザ (--db_user) がスーパーユーザではないこと、およびデータベースが別のユーザによって所有されていることを確認して下さい。例えば、権限のない db_user を使用している場合は、データベースはスーパーユーザである postgres によって所有されている可能性があります。参照 Odooの設定。
GitHub経由、または https://www.odoo.com/page/download または http://nightly.odoo.com から最新バージョンをダウンロードするなどして、定期的に最新のビルドをインストールし、インストールを最新の状態に保って下さい。
典型的な使用状況に適した適切な制限値を設定して、サーバをマルチプロセスモードで設定します(メモリ/CPU/タイムアウト)。ビルトインサーバもご確認下さい。
平文通信の盗聴を防止するため、有効な SSL 証明書を使用して HTTPS 終端を提供するウェブサーバの裏でOdooを実行します。 SSL証明書は安価で、多くの無料オプションが存在します。ウェブプロキシを設定してリクエストのサイズを制限し、適切なタイムアウトを設定し、proxy mode オプションを有効にします。HTTPS もご確認下さい。
サーバへのリモートSSHアクセスを許可する必要がある場合は、root だけでなく、全てのアカウントに強力なパスワードを設定して下さい。パスワードに基づく認証を完全に無効にし、公開鍵認証のみを許可することを強くお勧めします。また、VPN経由のアクセスを制限し、信頼できるIPアドレスのみをファイアウォールで許可すること、および/または、fail2ban または同等のブルートフォース検出システムを実行することも検討して下さい。
ブルートフォース攻撃やサービス拒否攻撃を防ぐために、プロキシまたはファイアウォールに適切なレート制限を導入することを検討して下さい。具体的な対策については、ブルートフォース攻撃のブロックも参照して下さい。

多くのネットワークプロバイダーは分散型サービス拒否攻撃(DDoS)に対する自動的な緩和策を提供していますが、これはオプションサービスである場合が多いので、プロバイダーに確認する必要があります。
可能な限り、公開用のデモ/テスト/ステージング環境は、本番環境とは別のマシンでホストしてください。また、本番環境と同様のセキュリティ対策を適用して下さい。
公開されているOdooサーバが、機密性の高い内部ネットワークリソースやサービス(プライベートVLAN経由など)にアクセスできる場合は、それらの内部リソースを保護するために適切なファイアウォール規則を実装してください。これにより、Odooサーバが誤って(または悪意のあるユーザの行動により)それらの内部リソースにアクセスしたり、混乱させたりすることがないようにすることができます。通常、ファイアウォールに送信時のデフォルトの拒否規則を適用し、Odooサーバがアクセスする必要がある内部リソースへのアクセスだけを明示的に許可することで、これを実現できます。 Systemd IPトラフィックアクセス制御も、プロセスごとのネットワークアクセス制御の実装に役立つ場合があります。
公開されているOdooサーバがWebアプリケーションファイアウォール、ロードバランサー、透明なDDoS保護サービス(CloudFlareなど)または同様のネットワークレベルのデバイスに後ろに隠れている場合、Odooシステムへの直接アクセスを避けることをお勧めします。一般的に、OdooサーバのエンドポイントIPアドレスを秘密にしておくことは困難です。例えば、パブリックシステムへの問い合わせ時にウェブサーバのログに表示されたり、Odooから送信されたEメールのヘッダーに表示されることがあります。このような状況では、ファイアウォールを設定して、WAF、ロードバランサー、またはプロキシサービスの特定のIPアドレスからのアクセス以外は、エンドポイントがパブリックにアクセスできないようにすることが望ましいでしょう。CloudFlareのようなサービスプロバイダーは、通常、この目的のためにIPアドレスの範囲の公開リストを維持しています。
複数の顧客をホスティングしている場合は、コンテナや適切な "jail" 技術を使用して、顧客データとファイルを互いに分離して下さい。
データベースとファイルストアのデータのバックアップを日次で取得し、サーバ自体からはアクセスできないリモートアーカイブサーバにコピーします。
Odooの導入には、WindowsよりもLinuxの使用が強く推奨されます。それでもWindowsプラットフォームへの導入を選択する場合は、サーバのセキュリティ強化に関する徹底的なレビューを実施する必要があります。これは本ガイドの対象外です。

ブルートフォース攻撃のブロック¶

インターネットに公開されている環境では、ユーザパスワードに対するブルートフォース攻撃が非常に一般的であり、この脅威はOdooサーバでは無視できません。Odooはログイン試行が行われるたびにログエントリを発行し、その結果(成功または失敗)と対象のログインおよびソースIPを報告します。

ログのエントリは以下の形式となります。

失敗したログイン:

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

これらのログは、fail2ban などの侵入防止システムで簡単に分析できます。

例えば、以下のfail2banフィルタ定義は失敗したログインに一致するはずです:

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

これは、攻撃元のIPアドレスをHTTP(S)上でブロックするよう、jail定義と併用することができます。

同じIPアドレスから1分以内に10回のログイン失敗が検出された場合、15分間IPをブロックすると、次のような表示になります:

[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

データベースマネジャーセキュリティ¶

Odooの設定では admin_passwd についても言及しています。

この設定は、データベース管理画面(データベースの作成、削除、ダンプ、復元)で使用されます。

もし、管理画面に一切アクセスできないようにする必要がある場合は、list_db 設定オプションを` False` に設定し、全てのデータベース選択および管理画面へのアクセスをブロックして下さい。

警告

インターネットに公開されているシステムでは、データベースマネジャーを無効にすることを強くお勧めします。これは、データベースを簡単に素早く作成および管理するための開発/デモツールです。本番での使用を想定して設計されたものではなく、攻撃者に危険な機能がさらされる可能性もあります。また、大規模なデータベースを処理するように設計されておらず、メモリ制限がトリガされる可能性もあります。

本番システムでは、データベース管理オペレーションは、常にシステム管理者によって実行されるべきであり、これには新しいデータベースのプロビジョニングや自動バックアップも含まれます。

システムが各リクエストの対象データベースを決定できるように、適切な db_name パラメータ(およびオプションで dbfilter も)を設定して下さい。そうしないと、ユーザがデータベースを選択できないため、ユーザがブロックされてしまいます。

もし管理画面へのアクセスを特定のマシン群からのみに制限する必要がある場合は、プロキシサーバの機能を使用して、データベース選択画面を表示する``/web/database/selector`` を(おそらく)除き、/web/database で始まる全てのルートへのアクセスをブロックします。

データベース管理画面にアクセス可能な状態にしておく場合は、admin_passwd の設定をデフォルトの admin から変更する必要があります。このパスワードは、データベース変更オペレーションを許可する前に確認されます。

安全に保管し、ランダムに生成する必要があります。例えば、

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

これは、32文字の疑似乱数からなる印刷可能な文字列を生成します。

マスタパスワードのリセット¶

マスターパスワードが紛失したり、漏洩したりして、リセットが必要になる場合があります。以下の手順は、Odooオンプレミスデータベースのシステム管理者向けに、マスターパスワードを手動で再設定し、再暗号化する方法を説明しています。

設定ファイルの場所を特定する¶

まず、Odooの設定ファイル(odoo.conf`または`odoorc (隠しファイル))を開きます。

設定ファイルは以下にあります: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

Linuxマシンへの Odoo のインストール方法によって、設定ファイルは2つの異なる場所のどちらかに配置されます。

パッケージインストール: /etc/odoo.conf
ソースインストール: ~/.odoorc

古いパスワード変更¶

適切なファイルが開けたら、設定ファイル内の古いパスワードを一時的なパスワードに変更します。

設定ファイルを見つけたら、(GUI)を使用して開きます。これは、ファイルをダブルクリックするだけで実行できます。次に、デバイスにはデフォルトで GUI が用意されており、このGUIを使用してファイルを開きます。

次に、マスターパスワードの明細 admin_passwd = $pbkdf2-sha… を、例えば admin_passwd = newpassword1234 に変更します。このパスワードは一時的に保存されるものであれば何でも構いません。必ず = の後の全てを変更して下さい。

Example

行は次のように表示されます。 admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDx Dv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

変更された行は次のようになります: admin_passwd = newpassword1234

以下の Unix コマンドを使用して、マスターパスワード行を変更します。

Secure Shell (SSH) プロトコル経由で Odoo サーバのターミナルに接続し、設定ファイルを編集します。設定ファイルを変更するには、次のコマンドを入力します。sudo nano /etc/odoo.conf

設定ファイルを開いたら、マスターパスワードの明細 admin_passwd = $pbkdf2-sha… を admin_passwd = newpassword1234 に変更します。このパスワードは一時的に保存されるものであれば、何でも構いません。必ず = の後の全てを変更して下さい。

Example

行は次のように表示されます。 admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDx Dv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

変更された行は次のようになります: admin_passwd = newpassword1234

重要

パスワードを別のものに変更するには、明細の先頭にセミコロン ; を追加して新しいパスワードのリセットをトリガするのではなく、別のものに変更することが不可欠です。これにより、パスワードのリセットプロセス全体を通じてデータベースの安全性が確保されます。

Odooサーバを再起動する¶

仮パスワードを設定した後、Odooサーバの再起動が必要です。

Odooサーバを再起動するには、まず、Windowsの:guilabel:検索 バーに サービス と入力します。次に、サービスアプリケーションを選択し、Odoo サービスまでスクロールダウンします。

次に、Odoo`を右クリックして、:guilabel:`起動または:guilabel:再起動 を選択します。この操作により、Odooサーバが手動で再起動されます。

コマンドを入力して、Odooサーバを再起動します。sudo service odoo15 restart

注釈

odoo の後の数字を、サーバが実行している特定のバージョンに合わせて変更します。

ウェブインターフェースを使用してパスワードを再暗号化して下さい。¶

まずは /web/database/manager またはブラウザの http://server_ip:port/web/database/manager に進みます。

注釈

server_ip をデータベースの IP アドレスに置き換えます。 port をデータベースにアクセスするポート番号に置き換えます。

次に、マスターパスワードの設定をクリックし、先に選択した仮のパスワードをマスターパスワードフィールドに入力します。この手順の後、新しいマスターパスワードを入力します。続行ボタンをクリックすると、新しいマスターパスワードがハッシュ化(または暗号化)されます。

この時点で、パスワードのリセットは正常に完了し、設定ファイルに新しいパスワードのハッシュ化されたバージョンが表示されます。

サポートされているブラウザ¶

Odoo supports the latest version of the following browsers.

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

1: 複数のOdooを同じPostgreSQLデータベースで使用したり、両方のソフトウェアに多くのコンピューティングリソースを提供したりする場合。
2: 技術的には socat のようなツールを使用して、ネットワーク越しに UNIX ソケットをプロキシすることができますが、それは主に UNIX ソケットでしか使用できないソフトウェア向けです。
3: または、内部パケット交換ネットワーク経由でのみアクセス可能ですが、その場合はセキュアなスイッチ、`ARPスプーフィング`対策が必要となり、WiFiの利用はできません。セキュアなパケット交換ネットワーク経由でも、HTTPSでの展開が推奨され、インターネット経由よりも管理された環境での展開が容易な "自己署名" 証明書を使用することで、コストを低く抑えることができます。