시스템 환경 설정¶

이 문서에서는 프로덕션 또는 인터넷 연결 서버에서 Odoo를 설정하는 기본 단계에 대해 설명합니다. 설치 대로 진행하며, 일반적으로 인터넷에 노출되지 않는 개발 시스템에서는 필요하지 않습니다.

dbfilter¶

Odoo에서는 멀티 테넌트 시스템을 사용하여, 하나의 Odoo 시스템이 여러 개의 데이터베이스 인스턴스를 실행하고 서비스할 수 있습니다. 또한 ‘현재의 데이터베이스’에 따라 (로드 중인 모듈부터) 사용자 지정을 할 수 있으므로 고도의 커스터마이징을 할 수 있습니다.

로그인한 회사 사용자가 백엔드 (웹 클라이언트)로 작업할 때는 문제가 되지 않습니다. 로그인할 때 데이터베이스를 선택하고 나중에 커스터마이징 항목을 로드할 수 있기 때문입니다.

그러나 문제가 되는 것은 로그인을 하지 않는 사용자 (포털, 웹사이트)로, 데이터베이스에 바인딩되지 않는 경우입니다: Odoo는 웹사이트 페이지를 로드하거나 작업을 수행하기 위해 어떤 데이터베이스를 사용해야 하는지 확인해야만 합니다. 멀티 테넌트를 사용하지 않는 경우에는 사용할 데이터베이스가 하나뿐이므로 문제가 되지 않지만, 액세스할 수 있는 데이터베이스가 여러 개 있는 경우에는 어떤 데이터베이스를 사용해야 하는지 알 수 있는 규칙이 필요합니다.

데이터베이스 필터 의 목적 중 하나는 요청하는 호스트 이름 (도메인)을 기반으로 데이터베이스를 선택하는 방법을 지정하는 것입니다. 값은 ‘정규 표현식’_ 이며, 동적으로 삽입된 호스트 이름 (%h) 또는 시스템에 액세스하는 첫 번째 하위 도메인 (%d)도 포함할 수 있습니다.

프로덕션 중에 서버에서 여러 데이터베이스를 호스팅하는 경우, 특히 ‘웹사이트’를 사용하는 경우에는 반드시 dbfilter를 **설정해야 하며, 그렇지 않으면 여러 기능이 제대로 작동하지 않습니다.

환경설정 샘플¶

• 이름이 ‘mycompany’로 시작하는 데이터베이스만 표시하기

환경 설정 파일 에 설정할 내용:

[options]
dbfilter = ^mycompany.*$

• www 다음에 오는 첫 번째 하위 도메인과 일치하는 데이터베이스만 표시합니다. 예를 들어, 수신 요청이 www.mycompany.com 또는 mycompany.co.uk 인 경우 데이터베이스 “mycompany” 가 표시되지만, www2.mycompany.com 또는 helpdesk.mycompany.com 인 경우에는 표시되지 않습니다.

환경 설정 파일 에 설정할 내용:

[options]
dbfilter = ^%d$

PostgreSQL¶

기본적으로 PostgreSQL은 UNIX 소켓을 통한 연결 및 루프백 연결 (‘로컬 호스트’, 즉 PostgreSQL 서버가 설치되어 있는 동일한 시스템에서)만 허용됩니다.

Odoo와 PostgreSQL을 동일한 컴퓨터에서 실행하려는 경우 UNIX 소켓을 사용하는 것이 좋으며 호스트가 없을 때는 기본값이지만 Odoo와 PostgreSQL을 다른 컴퓨터 1 에서 실행하려면 네트워크 인터페이스 수신 2 이 필요하며, 다음 중 하나를 선택합니다.

• 루프백 연결만 허용되고 Odoo가 실행되는 시스템과 PostgreSQL이 실행되는 시스템 간에 ‘SSH 터널 사용’ 을 하도록 허용한 다음 터널 끝에 연결하도록 Odoo를 설정합니다.

• Odoo가 설치되어 있는 시스템에 연결할 수 있도록 허용하며, 가능하면 ssl을 거쳐서 네트워크를 통해 연결하도록 Odoo를 설정합니다 (자세한 내용은 PostgreSQL 연결 설정 참조).

환경설정 샘플¶

• 로컬 호스트에서 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

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

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

Odoo 환경 설정하기¶

기본적으로 Odoo는 포트 5432를 통해 UNIX 소켓으로 로컬 postgres에 연결합니다. Postgres 배포가 로컬이 아니거나 설치 기본값을 사용하지 않는 경우 데이터베이스 옵션 을 사용하여 재정의할 수 있습니다.

패키지 설치 프로그램 에서는 자동으로 새로운 사용자 (odoo)를 생성하여 데이터베이스 사용자로 설정합니다.

• 데이터베이스 관리 화면은 어드민 비밀번호 설정으로 보호합니다. 이 설정은 환경 설정 파일을 통해서만 설정을 할 수 있으며, 데이터베이스를 변경하기 전에 간단한 확인 절차를 거칩니다. 제3자가 이 인터페이스를 사용할 수 없도록 무작위로 값을 생성하여 설정해야 합니다.

• 데이터베이스 관리 화면 외 모든 데이터베이스 작업에서는 데이터베이스 옵션 <reference/cmdline/server/database>`을 사용합니다. 데이터베이스 관리 화면이 작동하려면 PostgreSQL 사용자에게 ``createdb` 권한이 있어야 합니다.

• 사용자는 언제든지 자신이 소유한 데이터베이스를 삭제할 수 있습니다. 데이터베이스 관리 화면이 완전히 작동하지 않게 하려면 ``no-createdb``로 PostgreSQL 사용자를 생성해야 하며, 해당 데이터베이스는 다른 PostgreSQL 사용자가 소유하고 있어야 합니다.

  경고

  PostgreSQL 사용자는 슈퍼유저가 아니어야 합니다.

환경설정 샘플¶

• 192.168.1.2의 PostgreSQL 서버에 연결

• 포트 5432

• ‘odoo’ 사용자 계정을 사용하여,

• 비밀번호로 ‘pwd’ 사용

• 이름이 ‘mycompany’로 시작하는 db만 필터링

환경 설정 파일 에 설정할 내용:

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

Odoo와 PostgreSQL 간의 SSL¶

Odoo 11.0부터는 Odoo와 PostgreSQL 간에 ssl 연결을 강제할 수 있습니다. Odoo에서 db_sslmode는 ‘disable’, ‘allow’, ‘prefer’, ‘require’, ‘verify-ca’ 또는 ‘verify-full’ 중에서 선택한 값으로 연결의 ssl 보안을 제어하게 됩니다.

PostgreSQL 참조 문서

내장형 서버¶

Odoo에는 멀티 스레딩 또는 멀티 프로세싱이 적용되는 HTTP, 크론 및 실시간 채팅 서버가 내장되어 있습니다.

멀티스레드 서버는 개발, 데모 및 다양한 운영 체제 (Windows 포함)와의 호환하기 위해 주로 사용되는 좀 더 단순한 서버입니다. 웹소켓과 같이 장기적인 연결을 포함하여 모든 새로운 HTTP 요청에 대해 새로운 스레드가 생성됩니다. 추가 데몬 크론 스레드도 생성됩니다. 파이썬의 한계 (GIL)로 인해 하드웨어를 최대한 활용할 수 없습니다.

멀티 스레드 서버는 기본 서버이며, 도커 컨테이너도 마찬가지로 기본 컨테이너입니다. --작업자 옵션을 삭제하거나 ``0``으로 설정하면 선택할 수 있습니다.

멀티프로세싱 서버는 주로 프로덕션에 사용되는 전면적인 서버입니다. 이 서버는 리소스 사용에 대한 동일한 파이썬 제한 (GIL)의 적용을 받지 않으므로 하드웨어를 최대한 활용할 수 있습니다. 서버가 시작되면 작업자 풀이 생성됩니다. 새로운 HTTP 요청은 작업자가 처리할 준비가 될 때까지 OS에서 대기열에 대기합니다. 라이브 채팅용으로 추가 이벤트 기반 HTTP 작업자가 대체 포트에 스폰됩니다. 추가로 크론 워커도 스폰됩니다. 구성할 수 있는 프로세스 리퍼는 리소스 사용량을 모니터링하고 실패한 워커를 종료/재시작할 수 있습니다.

멀티 프로세싱 서버는 선택이 되어 있습니다. --작업자 옵션을 null이 아닌 정수로 설정하여 선택할 수 있습니다.

작업자 수 계산¶

• 경험 법칙 : (#CPU * 2) + 1

• 크론 작업자는 CPU 필요

• 작업자 1명 ~= 동시 사용자 6명

메모리 크기 계산¶

• 요청 중 20%는 과중한 요청이고 80%는 간단한 요청이라고 가정합니다.

• 모든 계산 필드 설계가 잘 되어 있고 SQL 요청도 잘 설계되된 경우… 과중한 작업을 진행에는 약 1GB의 RAM이 소비되는 것으로 추정합니다.

• 동일한 경우에 더 간단한 작업에는 약 150MB의 RAM이 소비되는 것으로 추정합니다.

필요한 RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * Heavy_worker_ram_estimation) )

실시간 채팅¶

멀티 프로세싱에서는, 전용 실시간 채팅 작업자가 자동으로 시작되어 --gevent-port <odoo-bin --gevent-port>`에서 수신 대기합니다. 기본적으로 HTTP 요청은 실시간 채팅이 아닌 일반 HTTP 워커에 계속 액세스합니다. Odoo 앞에 프록시를 배포하고 경로가 `/웹소켓/``으로 시작하는 수신 요청을 실시간 채팅 작업자로 이동시켜야 합니다. 또한 Odoo가 프록시 헤더 대신 실제 클라이언트 헤더 (예: 호스트 이름, 스키마 및 IP)를 사용하도록 :option:`–proxy-mode <odoo-bin –proxy-mode>`에서 시작해야 합니다.

환경설정 샘플¶

• CPU 4개, 스레드 8개를 갖춘 서버

• 동시 사용자 60명

• 사용자 60명 / 6 = 10 <- 이론 상 필요한 작업자 수

• (4 * 2) + 1 = 9 <- 이론 상 최대 작업자 수

• 크론에서 작업자 8개 + 작업자 1개를 사용합니다. 또한 모니터링 시스템을 사용하여 CPU 부하를 측정하고 7에서 7.5 사이인지 확인합니다.

• RAM = 9 * ((0.8*150) + (0.2*1024)) ~= Odoo용 3Go RAM

in 환경 설정 파일:

[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의 proxy 모드 를 활성화합니다. Odoo가 역방향 프록시 뒤에 있을 경우에만 활성화해야 합니다.

• SSL 종료 프록시 설정 (Nginx 종료 예시)

• 프록시 자체 설정 (Nginx 프록시 예시)

• 또한 SSL 종료 프록시에서는 보안되지 않는 연결을 보안 포트로 자동 리디렉션하게 됩니다.

환경설정 샘플¶

• http 요청을 https로 리디렉션

• odoo에 대한 프록시 요청

환경 설정 파일 에 설정할 내용:

proxy_mode = True

in /etc/nginx/sites-enabled/odoo.conf set:

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

session_id 쿠키에 대해 추가 설정을 지정할 수 있습니다. HTTP를 통해 전송되지 않도록 보안 플래그를 추가할 수 있으며, SameSite=Lax`를 추가하여 `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 cli 옵션 또는 http_enable = False 환경 설정 파일의 설정을 사용하여 HTTP 요청이 아닌 크론만 처리하도록 설정해야 합니다.

Linux와 같은 시스템에서는 멀티 스레딩 서버보다 멀티프로세싱 서버를 사용하는 것이 하드웨어 사용량 증대 및 안정성 향상면에 있어서 더욱 바람직하며, 예를 들면 --workers=-1 및 --max-cron-threads=n 옵션을 사용하는 것입니다.

실시간 채팅¶

실시간 채팅 기능이 올바르게 작동하게 하려면 gevent와 호환되는 WSGI 서버를 사용해야 합니다. 해당 서버는 지속 시간이 긴 다수 연결을 동시에 처리할 수 있어야 하지만 처리 능력이 많을 필요는 없습니다. 경로가 ``/websocket/``으로 시작하는 요청은 모두 해당 서버로 보내야 합니다. 다른 모든 요청에는 일반 (스레드/프로세스 기반) WSGI 서버를 사용해야 합니다.

Odoo 크론 서버를 통해 실시간 채팅 요청을 처리할 수도 있습니다. cron 서버에서 --no-http cli 옵션을 삭제하고 경로가 /websocket/ 으로 시작하는 요청이 --http-port <odoo-bin --http-port>`(멀티 스레딩 서버) 또는 :option:–gevent-port <odoo-bin –gevent-port>` (다중 처리 서버)에서 이 서버로 전달되기만 하면 됩니다.

정적 파일 및 첨부 파일 제공¶

개발 편의를 위해, Odoo에서는 모듈과 관련된 전체 정적 파일 및 첨부 파일을 직접 제공합니다. 이는 성능 측면에서는 이상적이지 않을 수 있으며, 정적 파일은 보통 정적 HTTP 서버를 통해 제공되어야 합니다.

정적 파일 제공¶

Odoo 정적 파일은 각 모듈의 static/ 폴더에 위치해 있으므로 /MODULE/static/FILE 에 대한 모든 요청을 중간에서 확인하여 다양한 애드온 경로에서 알맞은 모듈 (및 파일)을 조회하여 정적 파일을 제공할 수 있습니다.

웹 서버에서 제공하는 모든 이미지에서 Content-Security-Policy: default-src 'none' 헤더를 설정하는 것이 좋습니다. 모듈에 있는 static/ 폴더 내부의 콘텐츠를 수정/삽입할 수 없도록 하는 것이 반드시 필수는 아니며 기존 이미지를 최종 이미지로 사용합니다 (새로운 리소스를 자체적으로 가져오지 않음). 다만 그렇게 해 두는 것이 바람직합니다.

위의 NGINX (https) 환경 설정을 하여 다음 map 및 location 블록을 추가해야 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 지시문은 설치 내용에 따라 다르며, 특히 :option:`–addons-path <odoo-bin –addons-path>`에 따라 달라집니다.

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

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) 에 대해서 웹서버에서 확장 항목을 활성화하고 구성 설정을 실행해야 합니다. 설정이 완료되면, --x-sendfile CLI flag (해당 고유 플래그는 X-Sendfile and X-Accel 양쪽에서 사용됨) 로 Odoo를 실행합니다.

보안¶

먼저, 정보 시스템 보안은 단발성 작업이 아니라 지속적인 과정이라는 점을 명심하시기 바랍니다. 어느 순간에, 보안 확보 수준이 환경에서의 가장 약한 고리의 수준으로 떨어질 수 있습니다.

따라서 이 섹션에서 설명한 내용만으로 모든 보안 관련 문제를 방지하기 위한 궁극적인 조치로 판단하지 않으시기를 바랍니다. 이는 보안 작업 계획에 반드시 포함되어야 할 첫번째 중요 사항들을 요약한 내용에 불과합니다. 나머지 항목은 운영 체제 및 배포에 대한 최상의 보안 사례, 사용자 측면에서의 모범 사례, 암호 및 액세스 제어 관리 등에서 확인하시기 바랍니다.

인터넷 연결 서버를 배포할 경우, 다음의 보안 관련 주제를 반드시 고려하시기 바랍니다:

• 항상 강력한 최고 관리자용 관리자 비밀번호를 설정하고 시스템이 설정되는 즉시 데이터베이스 관리 페이지에 대한 액세스 권한을 제한하세요. 데이터베이스 관리자 보안 를 참조하세요.

• 데이터베이스에서는 모든 관리자 계정에 대해 고유한 로그인 정보 및 보안이 강력한 비밀번호를 선택하세요. 로그인 정보로 ‘admin’을 사용하지 마세요. 이와 같은 로그인 정보는 일상적인 작업에서는 사용하지 않도록 하며 설치 제어 및 관리용으로만 사용합니다. 테스트/스테이징 데이터베이스의 경우에도 admin/admin과 같은 기본 비밀번호를 절대 사용하지 마세요.

• 인터넷 연결 서버에 데모 데이터를 설치하지 마세요. 데모 데이터가 있는 데이터베이스에는 시스템 로그인에 사용할 수 있는 기본 로그인 정보 및 비밀번호가 포함되어 있으며 나아가 스테이징/개발 시스템에서도 심각한 문제를 일으킬 수 있습니다.

• 호스트명에 따라 데이터베이스가 표시되게 하려면 알맞은 데이터베이스 필터 ( --db-filter)를 사용하면 됩니다. 데이터베이스 필터 를 참조하세요. 시스템이 데이터베이스 백엔드에서 전체 데이터베이스를 가져오지 않고도 -d 를 사용하여 필터를 적용할 수 있는 자체 (쉼표로 구분) 데이터베이스 목록을 제공할 수도 있습니다.

• db_name 및 dbfilter``가 구성되고 호스트 주소당 하나의 데이터베이스만 일치하는 경우에는 ``list_db 구성 옵션을 거짓 으로 설정하여 데이터베이스 목록 전체를 나타내지 말고 데이터베이스 관리 화면에 대한 액세스를 차단해야 합니다 (--no-database-list 명령줄 옵션으로도 표시됨).

• PostgreSQL 사용자 (--db_user)가 슈퍼유저가 아니며, 데이터베이스를 다른 사용자가 소유하고 있는지 확인합니다. 예를 들어 권한이 없는 전용 db_user 를 사용하는 경우 postgres 해당 파일을 슈퍼유저가 소유할 수 있습니다. Odoo 환경 설정하기 도 참고할 수 있습니다.

• GitHub를 통해 최신 빌드를 정기적으로 설치하거나 https://www.odoo.com/page/download 또는 http://nightly.odoo.com 에서 최신 버전을 다운로드하여 설치 상태를 최신으로 유지하세요.

• 일반적인 사용량 (메모리/CPU/타임아웃)에 알맞게 적절히 제한하여 멀티 프로세싱 모드에서 서버를 설정합니다. buildin_server 도 참조해 보세요.

• 일반 텍스트 통신을 도청하지 못하도록 유효한 SSL 인증서로 HTTPS를 종료하도록 하는 웹 서버 배경에서 Odoo를 실행해 보세요. 저렴하고 다양한 SSL 인증서 무료 옵션이 있습니다. 웹 프록시를 설정하여 요청 사이즈를 제한하고 시간 제한을 적절하게 설정한 다음 proxy mode 옵션을 활성화합니다. :ref:`https_proxy`도 참고해 보세요.

• 서버에 대한 원격 SSH 액세스를 허용해야 하는 경우 ‘루트’뿐만 아니라 모든 계정에 강력한 비밀번호를 설정해야 합니다. 비밀번호 기반 인증은 전부 비활성화하고 공개 키 인증만 허용하는 것이 좋습니다. 또한 VPN을 통한 액세스를 제한하고 방화벽에서 신뢰할 수 있는 IP만 허용하거나 ‘fail2ban’ 또는 이에 상응하는 무차별 탐지 시스템 실행하는 것도 고려하도록 합니다.

• 무차별 대입 공격과 서비스 거부 공격을 방지하려면 프록시나 방화벽에 적절하게 속도를 제한하도록 설치하는 것이 좋습니다. 구체적인 방법에 대해서는 무차별 대입 공격 차단하기 를 참조하세요.

  많은 네트워크 제공업체에서 DDOS 공격 (분산 서비스 거부 공격)에 대한 자동 완화 기능을 제공하고 있으나 선택 서비스인 경우가 많으므로 해당 제공업체에 문의하시기 바랍니다.

• 가능하면 프로덕션 인스턴스가 아닌 다른 시스템에서 공개 데모/테스트/스테이징 인스턴스를 호스팅하세요. 또한 프로덕션과 동일한 보안 예방 조치를 적용합니다.

• 공개용 Odoo 서버가 민감한 내부 네트워크 리소스나 서비스에 액세스할 수 있는 경우 (예: 사설 VLAN을 통하는 경우), 해당 내부 리소스를 보호하기 위해 적절한 방화벽 규칙을 설정하세요. 이렇게 하면 실수로 (또는 악의적인 사용자 행동의 결과로) Odoo 서버가 해당 내부 리소스에 액세스하거나 중단시키는 데 사용되지 않도록 합니다. 일반적으로 방화벽에 아웃바운드 기본 거부 규칙을 적용한 다음 Odoo 서버가 액세스해야 하는 내부 리소스에 대한 액세스만 명시적으로 승인하면 됩니다. 시스템 IP 트래픽 액세스 제어 <http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html>`_는 프로세스별 네트워크 액세스 제어 설정에 유용하게 사용할 수 있습니다.

• 공개용 Odoo 서버가 웹 애플리케이션 방화벽, 로드 밸런서, 투명한 DDoS 보호 서비스 (예: CloudFlare) 또는 이와 유사한 네트워크 수준 장치 뒤에 있는 경우, Odoo 시스템에 직접 액세스하지 않는 것이 좋습니다. 보통 Odoo 서버의 엔드포인트 IP 주소를 기밀로 유지되기는 쉽지 않습니다. 예를 들어 공용 시스템을 쿼리할 때 웹 서버 로그에 표시되거나 Odoo에서 게시된 이메일의 헤더에 표시될 수 있습니다. 이러한 상황에서는 WAF, 로드 밸런서 또는 프록시 서비스의 특정 IP 주소를 제외하고는 엔드포인트에 공개적으로 액세스할 수 없도록 방화벽을 구성하는 것을 추천합니다. CloudFlare와 같은 서비스 제공업체는 일반적으로 이러한 목적을 위해 공개 목록을 IP 주소 범위로 유지합니다.

• 다수의 고객에게 호스팅하는 경우 컨테이너나 적절한 “jail” 기술을 사용하여 고객 데이터와 파일이 서로 격리되게 합니다.

• 데이터베이스 및 파일 저장소 데이터의 일일 백업을 설정한 후, 서버 자체에서는 액세스할 수 없는 원격 보관 서버에 복사합니다.

• Windows보다는, Linux에서 Odoo를 배포하는 것을 강력히 권장합니다. 그럼에도 불구하고 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`과 같은 침입 방지 시스템을 통해서 쉽게 분석할 수 있습니다.

예를 들어, 다음 fall2ban 필터 정의는 로그인 실패 내용과 일치해야 합니다:

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

이는 Jail 정의와 함께 사용하여 HTTP에서 공격 IP를 차단할 수 있습니다.

동일한 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 온프레미스 배포 시에는 보안 마스터 비밀번호가 있습니다.

마스터 비밀번호는 Odoo 설정 파일 (odoo.conf 또는 odoorc (숨김 파일))에 지정되어 있습니다. 그래픽 사용자 인터페이스 (GUI)를 통해 데이터베이스를 수정, 생성 또는 삭제하려면 Odoo 마스터 비밀번호가 있어야 합니다.

환경 설정 파일 찾기¶

먼저 Odoo 환경 설정 파일 (odoo.conf 또는 `odoorc`(숨겨진 파일))을 엽니다.

기존 비밀번호 변경하기¶

해당 파일을 열어서 설정 파일에 있는 이전 비밀번호를 임시 비밀번호로 수정합니다.

Odoo 서버 재시작¶

임시 비밀번호를 설정한 후에는 Odoo 서버를 반드시 재시작해야 합니다.

웹 인터페이스를 사용하여 비밀번호 재암호화¶

먼저 브라우저에서 /web/database/manager 또는 http://server_ip:port/web/database/manager 로 이동합니다.

다음으로 마스터 비밀번호 설정 을 클릭한 후 이전에 선택한 임시 비밀번호를 마스터 비밀번호 필드에 입력합니다. 이 단계에 이어 새로운 마스터 비밀번호 를 입력합니다. 계속하기 버튼을 클릭하면 새 마스터 비밀번호 가 해시 (또는 암호화)됩니다.

이 시점에서는 성공적으로 비밀번호 재설정이 완료되며 이제 새 비밀번호의 해시 버전이 설정 파일에 나타납니다.

지원되는 브라우저¶

게시자가 지원하는 한 Odoo는 시중에서 판매되는 모든 주요 데스크톱 및 모바일 브라우저를 지원합니다.

지원되는 브라우저는 다음과 같습니다.

• Google Chrome

• Mozilla Firefox

• Microsoft Edge

• Apple Safari

1

Odoo를 여러 개 설치할 때 동일한 PostgreSQL 데이터베이스를 사용하거나 컴퓨팅 리소스를 양쪽 소프트웨어에 더 제공하도록 설정할 수 있습니다.

2

기술적으로 socat 과 같은 도구를 사용하여 네트워크를 통해 UNIX 소켓을 프록시할 수 있으나 대부분의 경우에는 UNIX 소켓을 통해서만 사용할 수 있는 소프트웨어용입니다.

3

또는 내부 패킷 교환 네트워크를 통해서만 액세스할 수 있으나 ‘ARP 스푸핑’_ 에 대한 보호 스위치 및 보안이 필요하며 WiFi는 사용할 수 없습니다. 보안 패킷 교환 네트워크를 통해서도 HTTPS를 통한 배포를 권장하며, “자체 서명” 인증서는 인터넷보다 통제된 환경에서 배포하기가 더 쉽기 때문에 비용을 낮출 수 있습니다.