إعدادات النظام

يصف هذا المستند الخطوات الأساسية لإعداد أودو في الإنتاج أو في الخادم المواجه للإنترنت. إنه يتبع installation، ولا يعد ضرورياً لأنظمة التطوير غير المكشوفة على الإنترنت.

تحذير

إذا كنت تقوم بإعداد خادم عام، لا تنس إلقاء نظرة على توصيات الأمان الخاصة بنا!

dbfilter

أودو هو نظام متعدد المستأجرين: بوسع نظام أودو واحد تشغيل وخدمة عدد من مثيلات قواعد البيانات. إنه أيضاً قابل للتخصيص بشكل كبير، مع تخصيصات بدءاً من (التطبيقات التي يتم تحميلها) بناءً على "قاعدة البيانات الحالية".

لا تُعد هذه مشكلة عند العمل في الواجهة الخلفية (عميل الويب) كمستخدم شركة مسجل دخوله: يمكن تحديد قاعدة البيانات عند تسجيل الدخول، ويتم تحميل التخصيصات بعد ذلك.

ومع ذلك، فهذه مشكلة بالنسبة للمستخدمين غير المسجلين (البوابة، الموقع الإلكتروني) وغير المرتبطين بقاعدة بيانات: يحتاج أودو إلى معرفة قاعدة البيانات التي يجب استخدامها لتحميل صفحة الموقع الإلكتروني أو إجراء العملية. إذا لم يتم استخدام الإيجار المتعدد، فهذه ليست مشكلة، فهناك قاعدة بيانات واحدة فقط يمكن استخدامها، ولكن إذا كانت هناك قواعد بيانات متعددة يمكن الوصول إليها، سيكون أودو بحاجة إلى قاعدة لمعرفة القاعدة التي يجب أن يستخدمها.

هذا هو أحد أغراض --db-filter: فهو يحدد كيفية اختيار قاعدة البيانات بناءً على اسم المضيف (النطاق) المطلوب. القيمة هي تعبير نمطي، ومن المحتمل أن تتضمن اسم المضيف الذي تم إدخاله ديناميكياً (%h) أو النطاق الفرعي الأول (%d) الذي يتم من خلاله الوصول إلى النظام.

بالنسبة للخوادم التي تستضيف قواعد بيانات متعددة في الإنتاج، خاصة إذا تم استخدام الموقع الإلكتروني، يجب تعيين dbfilter، وإلا فلن يعمل عدد من الميزات بشكل صحيح.

عينات التكوين

  • إظهار قواعد البيانات ذات الأسماء التي تبدأ بـ "mycompany" فقط

في مجموعة ملف التهيئة:

[options]
dbfilter = ^mycompany.*$

  • إظهار قواعد البيانات المطابقة للنطاق الفرعي الأول بعد www فقط: على سبيل المثال، سيتم عرض قاعدة البيانات "mycompany" إذا تم إرسال الطلب الوارد إلى www.mycompany.com أو mycompany.co.uk ، ولكن ليس لـ www2.mycompany.com أو helpdesk.mycompany.com.

في مجموعة ملف التهيئة:

[options]
dbfilter = ^%d$

ملاحظة

يعد إعداد --db-filter المناسب جزءاً مهماً من تأمين عملية النشر الخاصة بك. بمجرد أن تعمل بشكل صحيح وتتطابق فقط مع قاعدة بيانات واحدة لكل اسم مضيف، نوصى بشدة بحظر الوصول إلى شاشات مدير قاعدة البيانات، واستخدام معيار بدء التشغيل --no-database-list لمنع إدراج قواعد البيانات الخاصة بك، ومنع الوصول إلى شاشات إدارة قاعدة البيانات. ألقِ نظرة أيضاً على الأمان.

PostgreSQL

افتراضياً، يسمح PostgreSQL فقط بالاتصال عبر منافذ UNIX واتصالات الاسترجاع (من "المضيف المحلي"، وهو نفس الجهاز الذي تم تثبيت خادم PostgreSQL عليه).

يعد منفذ UNIX جيداً إذا كنت تريد تنفيذ أودو وPostgreSQL على نفس الجهاز، وهو الإعداد الافتراضي عند عدم توفير مضيف، ولكن إذا كنت تريد تنفيذ أودو وPostgreSQL على أجهزة مختلفة [#different-machines] _ فسوف تحتاج إلى الاستماع إلى واجهات الشبكة 2، إما:

  • اقبل فقط اتصالات الاسترجاع و"استخدم نفق SSH"_ بين الجهاز الذي يعمل عليه أودو والجهاز الذي يعمل عليه PostgreSQL، ثم قم بتهيئة أودو للاتصال بنهاية النفق الخاص به

  • اقبل الاتصالات بالجهاز الذي تم تثبيت أودو عليه، ربما عبر SSL (راجع إعدادات اتصال PostgreSQL للحصول على التفاصيل)، ثم قم بتهيئة أودو للاتصال عبر الشبكة

مثال على التهيئة

  • السماح باتصال TCP في المضيف المحلي

  • السماح باتصال TCP من شبكة 192.168.1.x

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

تهيئة أودو

بإمكان أودو الاتصال مباشرة بـ postgres محلي عبر مقبس UNIX عبر المنفذ 5432. ويمكن تجاوز ذلك باستخدام خيارات قاعدة البيانات عندما لا يكون نشر Postgres محلياً و/أو لا يستخدم إعدادات التثبيت الافتراضية.

ستقوم المثبتات المجمعة تلقائياً بإنشاء مستخدم جديد (أودو) وتعيينه كمستخدم لقاعدة البيانات.

  • شاشات إدارة قاعدة البيانات محمية بواسطة الإعداد admin_passwd. لا يمكن ضبط هذا الإعداد إلا باستخدام ملفات التهيئة، ويتم فحصه ببساطة قبل إجراء تعديلات على قاعدة البيانات. ويجب ضبطها على قيمة يتم إنشاؤها عشوائياً لضمان عدم تمكن الجهات الخارجية من استخدام هذه الواجهة.

  • تستخدم كافة عمليات قواعد البيانات خيارات قاعدة البيانات، شاملة شاشة إدارة قاعدة البيانات. حتى تعمل شاشة إدارة قاعدة البيانات، يجب أن يكون لمستخدم PostgreSQL صلاحيات createdb.

  • بإمكان المستخدمين دائماً تعطيل قواعد البيانات التي يملكونها. حتى تصبح شاشة إدارة قاعدة البيانات غير فعالة تماماً، يجب أن يتم إنشاء مستخدم PostgreSQL و no-createdb ويجب أن تكون قاعدة البيانات تابعة لمستخدم PostgreSQL آخر.

    تحذير

    the PostgreSQL user must not be a superuser

مثال على التهيئة

  • اتصل بخادم PostgreSQL على 192.168.1.2

  • منفذ 5432

  • باستخدام حساب مستخدم "أودو"،

  • مع استخدام 'pwd' ككلمة مرور

  • فلترة قواعد البيانات ذات الأسماء التي تبدأ بـ "mycompany" فقط

في مجموعة ملف التهيئة:

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

SSL بين أودو و PostgreSQL

منذ أودو 11.0، بإمكانك إنشاء اتصال ssl بين أودو و PostgreSQL. في أودو، يتحكم db_sslmode في أمن ssl للاتصال، مع القيمة المحددة من بين 'تعطيل'، 'سماح'، 'يفضل'، 'يتطلب'، 'verify-ca' أو 'verify-full'

PostgreSQL Doc

خادم مدمج

يحتوي أودو على خوادم HTTP و cron ودردشة مباشرة مدمجة باستخدام إما نظام أداء المهام في آن واحد أو المعالجة في آن واحد.

خادم أداء المهام في آن واحد هو خادم أبسط يستخدم بشكل أساسي للتطوير والعروض التوضيحية وتوافقه مع أنظمة التشغيل المختلفة (بما في ذلك Windows). يتم إنشاء مؤشر ترابط جديد لكل طلب HTTP جديد، حتى بالنسبة للاتصالات طويلة الأمد مثل websocket. يتم أيضاً إنشاء سلاسل daemonic cron إضافية. نظراً لقيود Python (GIL)، فإنه لا يحقق الاستفادة القصوى من الأجهزة.

The multi-threaded server is the default server, also for docker containers. It is selected by leaving the --workers option out or setting it to 0.

الخادم متعدد المعالجة هو خادم كامل يستخدم بشكل أساسي للإنتاج. إنه لا يخضع لنفس قيود Python (GIL) لاستخدام الموارد، وبالتالي يحقق أفضل استفادة من الأجهزة. يتم إنشاء مجموعة من المشغلين عند بدء تشغيل الخادم. يتم وضع طلبات HTTP الجديدة في قائمة الانتظار بواسطة نظام التشغيل حتى يكون هناك مشغلون جاهزون لمعالجتها. يتم إنشاء مشغل HTTP إضافي مرتبط بالحدث للدردشة المباشرة على منفذ بديل. يتم إنشاء مشغلي cron إضافيين أيضاً. يقوم جهاز حصاد العمليات القابل للتهيئة بمراقبة استخدام الموارد ويمكنه التخلص من/إعادة تشغيل المشغلات التي بها أعطال.

The multi-processing server is opt-in. It is selected by setting the --workers option to a non-null integer.

ملاحظة

لأنه قابل للتخصيص للغاية لخوادم Linux، الخادم من نوع multi-processing server غير متاح على Windows.

حساب عدد المشغلات

  • القاعدة الأساسية : (#CPU*2) + 1

  • تحتاج مشغلات Cron إلى وحدة المعالجة المركزية

  • مشغّل واحد 1 ~= 6 مستخدمين في آن واحد

حساب حجم الذاكرة

  • نعتبر 20% من الطلبات معقدة، بينما الـ 80% الأخرى بسيطة

  • المشغّل الثقيل، عندما تكون كافة الحقول المحسوبة مصممة بشكل جيد وتكون طلبات SQL مصممة بشكل جيد، ... من المقدر أن يستهلك حوالي 1 جيجابايت من ذاكرة الوصول العشوائي (RAM)

  • من المقدر أن يستهلك المشغّل الأخف، في نفس السيناريو، حوالي 150 ميجابايت من ذاكرة الوصول العشوائي (RAM)

ذاكرة الوصول العشوائي (RAM) المطلوبة = عدد المشغلين * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

الدردشة المباشرة

في المعالجة المتعددة، يتم تشغيل عامل LiveChat مخصص تلقائيًا ويستمع إلى --gevent-port. افتراضيًا، ستستمر طلبات HTTP في الوصول إلى عمال HTTP العاديين بدلاً من عامل LiveChat. يجب عليك نشر وكيل أمام Odoo وإعادة توجيه الطلبات الواردة التي يبدأ مسارها بـ /websocket/ إلى عامل LiveChat. يجب عليك أيضًا تشغيل Odoo في --proxy-mode بحيث يستخدم رؤوس العميل الحقيقية (مثل اسم المضيف والمخطط وIP) بدلاً من رؤوس الوكيل.

مثال على التهيئة

  • Server with 4 CPU, 8 Thread

  • 60 مستخدم في آن واحد

  • 60 مستخدم / 6 = 10 <- العدد النظري للمشغلين المطلوبين

  • (4 * 2) + 1 = 9 <- الحد الأقصى النظري لعدد المشغلين

  • سوف نستخدم 8 مشغلين + 1 لـ cron. سنستخدم أيضاً نظام مراقبة لقياس حمل وحدة المعالجة المركزية (CPU) والتحقق مما إذا كان يتراوح بين 7 و7.5.

  • RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB RAM لأودو

في ملف التهيئة:

[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 mode. يجب أن يتم تمكينه فقط عندما يكون أودو خلف وكيل عكسي

  • قم بإعداد وكيل إنهاء SSL (مثال إنهاء Nginx)

  • قم بإعداد الوكيل نفسه (مثال Nginx للوكيل)

  • يجب أيضاً على وكيل إنهاء SSL الخاص بك إعادة توجيه الاتصالات غير الآمنة تلقائياً إلى المنفذ الآمن

مثال على التهيئة

  • إعادة توجيه طلبات http إلى https

  • طلبات الوكيل إلى أودو

في مجموعة ملف التهيئة:

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

أضف رأس Strict-Transport-Security إلى جميع الطلبات، وذلك لمنع المتصفحات من إرسال طلب HTTP عادي إلى هذا النطاق. ستحتاج إلى الحفاظ على خدمة HTTPS عاملة بشهادة صالحة على هذا النطاق في جميع الأوقات، وإلا فسيرى المستخدمون لديك تنبيهات أمنية أو لن يتمكنوا تمامًا من الوصول إليها.

قم بفرض اتصالات HTTPS خلال عام لكل زائر في NGINX باستخدام السطر:

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

يمكن تحديد تكوين إضافي لملف تعريف الارتباط "session_id". يمكن إضافة العلامة Secure لضمان عدم إرسالها مطلقًا عبر HTTP و`SameSite=Lax` لمنع CSRF المصادق عليه.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

أودو كتطبيق WSGI

من الممكن أيضاً تركيب أودو كتطبيق WSGI قياسي. يمنحك أودو الأساس لنَص مُشغّل WSGI كـ odoo-wsgi.example.py. يجب أن يكون هذا النص مخصصاً (يمكن أو يكون بعد نسخه من دليل الإعداد) لإعداد التهيئة بشكل صحيح مباشرة في odoo.tools.config عوضا ًعن القيام بها من خلال بند الأمر أو ملف التهيئة.

ولكن سيكشف خادم WSGI فقط نقطة نهاية HTTP الأساسية لعميل الويب والموقع الإلكتروني والواجهة البرمجية لخدمة الويب. لأن أودو لا يتحكم في إنشاء المشغلات بعد الآن، لا يمكنه إعداد مشغلات cron أو الدردشة المباشرة

مشغلات Cron

تحتاج إلى تشغيل أحد خوادم أودو المدمجة بجانب خادم WSGI لمعالجة أعمال cron. يجب أن تتم تهيئة ذلك الخادم ليقوم بمعالجة crons فقط وليس طلبات HTTP باستخدام خيار --no-http cli أو http_enable = False في إعدادات ملف التهيئة.

في الأنظمة المشابهة لنظام Linux، يوصى باستخدام خادم متعدد المعالجة بدلاً من خادم متعدد الخيوط للاستفادة من استخدام أفضل للأجهزة وزيادة الاستقرار، أي باستخدام --workers=-1 و --max-cron-threads=n خيارات cli.

الدردشة المباشرة

يلزم استخدام خادم WSGI متوافق مع gevent للتشغيل الصحيح لميزة الدردشة المباشرة. يجب أن يكون هذا الخادم قادرًا على التعامل مع العديد من الاتصالات المتزامنة طويلة الأمد ولكنه لا يحتاج إلى قدر كبير من قوة المعالجة. يجب توجيه كافة الطلبات التي يبدأ مسارها بـ /websocket/ إلى ذلك الخادم. يجب استخدام خادم WSGI عادي (يعتمد على مؤشر الترابط/العملية) لجميع الطلبات الأخرى.

يمكن أيضًا استخدام خادم Odoo cron لخدمة طلبات الدردشة المباشرة. ما عليك سوى إسقاط الخيار --no-http cli من خادم cron والتأكد من توجيه الطلبات التي يبدأ مسارها بـ /websocket/ إلى هذا الخادم، إما على --http-port (خادم متعدد الخيوط) أو على --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`` على التثبيت لديك، وتحديداً على --addons-path.

Example

لنفترض أنه تم تثبيت Odoo عبر حزم دبيان للمجتمع والمؤسسات، وأن --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. لا يمكن الوصول إليها مباشرة عبر خادم ويب ثابت لأن الوصول إليها يتطلب عمليات بحث متعددة في قاعدة البيانات لتحديد مكان تخزين الملفات وما إذا كان المستخدم الحالي يمكنه الوصول إليها أم لا.

ومع ذلك، بمجرد تحديد موقع الملف والتحقق من حقوق الوصول بواسطة Odoo، من الأفضل تقديم الملف باستخدام خادم الويب الثابت بدلاً من Odoo. لكي يفوض Odoo تقديم الملفات إلى خادم الويب الثابت، يجب تمكين وتكوين ملحقات X-Sendfile (apache) أو X-Accel (nginx) على خادم الويب الثابت. بمجرد إعداده، ابدأ Odoo مع علامة CLI --x-sendfile (يتم استخدام هذه العلامة الفريدة لكل من X-Sendfile وX-Accel).

ملاحظة

  • لا يتطلب ملحق X-Sendfile لـ Apache (وخوادم الويب المتوافقة) أي تهيئة إضافية.

  • يتطلب ملحق X-Accel لـ NGINX **** التهيئة الإضافية التالية:

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

    في حال كنت لا تعرف ما هو المسار إلى مخزن الملفات الخاص بك، ابدأ تشغيل Odoo باستخدام خيار --x-sendfile وانتقل إلى ``/web/filestore `` عنوان URL مباشرة عبر Odoo (لا تنتقل إلى عنوان URL عبر NGINX). يؤدي هذا إلى تسجيل تحذيرات، وتحتوي الرسالة على التكوين الذي تحتاجه.

الأمن

بالنسبة للمبتدئين، ضع في اعتبارك أن تأمين نظام المعلومات هو عملية مستمرة، وليست عملية لمرة واحدة. في أي لحظة، ستكون آمنًا بقدر أضعف حلقة في بيئتك.

لذا يرجى عدم اعتبار هذا القسم بمثابة القائمة النهائية للإجراءات التي من شأنها منع جميع المشكلات الأمنية. الغرض منه فقط هو أن يكون ملخصًا للأشياء المهمة الأولى التي يجب عليك التأكد من تضمينها في خطة العمل الأمنية الخاصة بك. سيأتي الباقي من أفضل ممارسات الأمان لنظام التشغيل والتوزيع الخاص بك، وأفضل الممارسات فيما يتعلق بالمستخدمين وكلمات المرور وإدارة التحكم في الوصول وما إلى ذلك.

عند استخدام خادم متصل بالإنترنت، يرجى التأكد من مراعاة المواضيع التالية المتعلقة بالأمان:

  • قم دائمًا بتعيين كلمة مرور قوية للمسؤول المتميز، وتقييد الوصول إلى صفحات إدارة قاعدة البيانات بمجرد إعداد النظام. راجع :المرجع:`db_manager_security`.

  • اختر تسجيلات دخول فريدة وكلمات مرور قوية لجميع حسابات المسؤولين في جميع قواعد البيانات. لا تستخدم "المسؤول" لتسجيل الدخول. لا تستخدم عمليات تسجيل الدخول هذه للعمليات اليومية، فقط للتحكم/إدارة التثبيت. لا تستخدم أبدًا أي كلمات مرور افتراضية مثل admin/admin، حتى بالنسبة لقواعد بيانات الاختبار/التدريج.

  • لا لا تثبت البيانات التجريبية على الخوادم التي تواجه الإنترنت. تحتوي قواعد البيانات التي تحتوي على بيانات تجريبية على معلومات تسجيل الدخول وكلمات المرور الافتراضية التي يمكن استخدامها للدخول إلى أنظمتك والتسبب في مشاكل كبيرة، حتى في أنظمة التدريج/التطوير.

  • استخدم فلاتر قاعدة البيانات المناسبة ( --db-filter) لتقييد رؤية قواعد البيانات الخاصة بك وفقًا لاسم المضيف. راجع:المرجع:dbfilter. يمكنك أيضًا استخدام -d لتوفير قائمة خاصة بك (مفصولة بفواصل) بقواعد البيانات المتاحة للتصفية منها، بدلاً من السماح للنظام بجلبها جميعًا من الواجهة الخلفية لقاعدة البيانات.

  • بمجرد تكوين db_name و``dbfilter`` ومطابقة قاعدة بيانات واحدة فقط لكل اسم مضيف، يجب عليك تعيين خيار التكوين list_db على False، لمنع إدراج قواعد البيانات بالكامل، ولحظر الوصول إلى شاشات إدارة قاعدة البيانات (يتم عرض هذا أيضًا كخيار سطر الأوامر --no-database-list)

  • تأكد من أن مستخدم PostgreSQL (--db_user) ليس مستخدماً خارقاً، وأن قواعد بياناتك يملكها مستخدم مختلف. على سبيل المثال، يمكن أن تكون تابعة لمستخدم postgres الخارق إذا كنت تستخدم db_user المخصص غير المميز. ألقِ نظرة أيضاً على تهيئة أودو.

  • حافظ على تحديث عمليات التثبيت عن طريق تثبيت أحدث الإصدارات بانتظام، إما عبر GitHub أو عن طريق تنزيل أحدث إصدار من https://www.odoo.com/page/download أو http://nightly.odoo.com

  • قم بتهيئة خادمك في وضع العمليات المتعددة مع الحدود المناسبة التي تتوافق مع استخدامك المعتاد (الذاكرة/وحدة المعالجة المركزية/أوقات التوقف). ألقِ نظرة أيضاً على خادم مدمج.

  • قم بتشغيل أودو خلف خادم ويب يوفر إنهاء HTTPS مع شهادة SSL صالحة، وذلك لمنع التنصت على اتصالات cleartext. شهادات SSL رخيصة الثمن، وتوجد العديد من الخيارات المجانية. قم بتتهيئة وكيل الويب للحد من حجم الطلبات، وقم بتعيين أوقات التوقف المناسبة، ثم قم بتمكين خيار proxy mode. ألقِ نظرةأيضاً على HTTPS.

  • إذا كنت بحاجة إلى السماح بوصول SSH عن بعد إلى خوادمك، فتأكد من تعيين كلمة مرور قوية لكافة الحسابات، وليس الجذر فحسب. نوصى بشدة بتعطيل المصادقة المستندة إلى كلمة المرور بالكامل، والسماح فقط بمصادقة المفتاح العام. ضع بعين الاعتبار أيضاً تقييد الوصول عبر شبكة VPN، والسماح فقط بعناوين IP الموثوقة في جدار الحماية، و/أو تشغيل نظام كشف القوة الغاشمة مثل "fail2ban" أو ما يعادله.

  • يمكنك أيضاً تثبيت تحديد المعدل المناسب على الخادم الوكيل أو جدار الحماية الخاص بك، لمنع هجمات القوة الغاشمة وهجمات رفض الخدمة. ألقِ نظرة أيضاً على منع هجمات القوة الغاشمة للتعرف على التدابير المحددة.

    يوفر العديد من مزودي الشبكات تخفيفاً تلقائياً لهجمات رفض الخدمة الموزعة (DDOS)، ولكن غالباً ما تكون هذه الخدمة اختيارية، لذا عليك استشارتهم.

  • كلما أمكن، قم باستضافة مثيلاتك التجريبية/الاختبارية/التدريجية العامة على أجهزة مختلفة عن الأجهزة الخاصة بالإنتاج. وتطبيق نفس الاحترازات الأمنية المتبعة في الإنتاج.

  • إذا كان خادم أودو العام لديك يتمتع بإمكانية الوصول إلى موارد أو خدمات الشبكة الداخلية الحساسة (على سبيل المثال من خلال VLAN)، فقم بتنفيذ قواعد جدار الحماية المناسبة لحماية تلك الموارد الداخلية. سيضمن ذلك عدم إمكانية استخدام خادم أودو عن طريق الخطأ (أو نتيجة لإجراءات المستخدم الضارة) للوصول إلى تلك الموارد الداخلية أو تعطيلها. عادةً ما يمكن القيام بذلك عن طريق تطبيق قاعدة DENY الافتراضية الصادرة على جدار الحماية، وبعد ذلك فقط يتم السماح بشكل صريح بالوصول إلى الموارد الداخلية التي يحتاج خادم أودو للوصول إليها. التحكم في الوصول إلى حركة مرور IP للنظام قد يكون مفيداً أيضاً في تنفيذ التحكم في الوصول إلى الشبكة لكل عملية.

  • إذا كان خادم أودو الخاص بك موجوداً خلف جدار حماية لتطبيق الويب، أو مٌوازن التحميل، أو خدمة حماية DDoS تتسم بالشفافية (مثل CloudFlare) أو جهاز مشابه على مستوى الشبكة، فقد ترغب في تجنب الوصول المباشر إلى نظام أودو. من الصعب عموماً المحفاظة على سرية عناوين IP لنقطة النهاية لخوادم أودو الخاصة بك. على سبيل المثال، يمكن أن تظهر في سجلات خادم الويب عند الاستعلام عن الأنظمة العامة، أو في ترويسات رسائل البريد الإلكتروني المرسلة من أودو. في مثل هذه الحالة، قد ترغب في تهيئة جدار الحماية الخاص بك بحيث لا يمكن الوصول إلى نقاط النهاية بشكل عام إلا من خلال عناوين IP المحددة لخدمة WAF أو مُوازن التحميل أو خدمة الوكيل. عادةً ما يحتفظ مقدمو الخدمات مثل CloudFlare بقائمة عامة بنطاقات عناوين IP الخاصة بهم لهذا الغرض.

  • إذا كنت تستضيف عدة عملاء، قم بعزل بيانات وملفات العملاء عن بعضها البعض باستخدام الحاويات أو تقنيات "السجن" المناسبة.

  • قم بإعداد نسخ احتياطية يومية لقواعد البيانات وبيانات مخزن الملفات، وانسخها إلى خادم أرشفة عن بُعد لا يمكن الوصول إليه من الخادم نفسه.

  • نوصى بشدة باستخدام أودو على نظام تشغيل Linux عوضاً عن نظام تشغيل Windows. ومع ذلك، إذا اخترت استخدام نظام Windows الأساسي، فيجب إجراء مراجعة شاملة لتعزيز الأمان للخادم، وهذا خارج نطاق هذا الدليل.

منع هجمات القوة الغاشمة

بالنسبة لعمليات إعداد النظام المواجهة للإنترنت، تعد هجمات القوة الغاشمة على كلمات مرور المستخدم شائعة جداً، ويجب عدم إهمال هذا التهديد بالنسبة لخوادم أودو. يقوم أودو بإصدار قيد سجل كلما تم إجراء محاولة لتسجيل الدخول، وبقوم بالإبلاغ عن النتيجة: النجاح أو الفشل، بالإضافة إلى تسجيل الدخول المستهدف وعنوان 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).

إليك ما يمكن أن يبدو عليه حظر عنوان IP لمدة 15 دقيقة عند اكتشاف 10 محاولات تسجيل دخول فاشلة من نفس عنوان 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

أمن مدير قاعدة البيانات

تهيئة أودو قام بذكر admin_passwd عند المرور.

يُستخدم هذا الإعداد على كافة شاشات إدارة قواعد البيانات (لإنشاء قواعد البيانات أو حذفها أو تفريغها أو استعادتها).

إذا كان لا بد من عدم إمكانية الوصول إلى شاشات الإدارة على الإطلاق، فيجب عليك تعيين خيار التهيئة list_db كـ``خطأ``، لمنع الوصول إلى كافة شاشات اختيار قاعدة البيانات وإدارتها.

تحذير

نوصى بشدة بتعطيل مدير قاعدة البيانات لأي نظام متصل بالإنترنت! والغرض من الأداة هو أن تكون أداةً للتطوير/للتوضيح، لتسهيل إنشاء قواعد البيانات وإدارتها بسرعة. إنه غير مصمم للاستخدام في الإنتاج، وقد يؤدي حتى إلى تعريض خصائص خطيرة للمهاجمين. كما أنه غير مصمم للتعامل مع قواعد البيانات الكبيرة، وقد يؤدي إلى حدود للذاكرة.

في أنظمة الإنتاج، يجب دائماً تنفيذ عمليات إدارة قاعدة البيانات بواسطة مسؤول النظام، بما في ذلك توفير قواعد بيانات جديدة ونسخ احتياطية آلية.

تأكد من إعداد معيار db_name مناسب (واختيارياً، dbfilter أيضاً) حتى يتمكن النظام من تحديد قاعدة البيانات المستهدفة لكل طلب، وإلا فسيتم حظر المستخدمين لأنه لن يُسمح لهم باختيار قاعدة البيانات نفسها.

إذا كان يجب الوصول إلى شاشات الإدارة فقط من مجموعة محددة من الأجهزة، فاستخدم خصائص الخادم الوكيل لمنع الوصول إلى كافة المسارات التي تبدأ بـ /web/database باستثناء (ربما) /web/database/selector الذي يعرض شاشة اختيار قاعدة البيانات.

إذا كان يجب ترك شاشة إدارة قاعدة البيانات متاحة للوصول إليها، فيجب تغيير إعداد admin_passwd من الإعداد الافتراضي admin: يتم التحقق من كلمة المرور هذه قبل السماح بعمليات تغيير قاعدة البيانات.

يجب أن يتم تخزينها بشكل آمن، ويجب أن يتم إنشاؤها بشكل عشوائي على سبيل المثال

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

which generates a 32-character pseudorandom printable string.

Reset the master password

There may be instances where the master password is misplaced, or compromised, and needs to be reset. The following process is for system administrators of an Odoo on-premise database detailing how to manually reset and re-encrypt the master password.

انظر أيضًا

حساب Odoo.com

When creating a new on-premise database, a random master password is generated. Odoo recommends using this password to secure the database. This password is implemented by default, so there is a secure master password for any Odoo on-premise deployment.

تحذير

When creating an Odoo on-premise database the installation is accessible to anyone on the internet, until this password is set to secure the database.

The master password is specified in the Odoo configuration file (odoo.conf or odoorc (hidden file)). The Odoo master password is needed to modify, create, or delete a database through the graphical user interface (GUI).

Locate configuration file

First, open the Odoo configuration file (odoo.conf or odoorc (hidden file)).

The configuration file is located at: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

Change old password

Once the appropriate file has been opened, proceed to modify the old password in the configuration file to a temporary password.

After locating the configuration file, open it using a (GUI). This can be achieved by simply double clicking on the file. Then, the device should have a default GUI to open the file with.

Next, modify the master password line admin_passwd = $pbkdf2-sha… to admin_passwd = newpassword1234, for example. This password can be anything, as long as it is saved temporarily. Make sure to modify all characters after the =.

Example

The line appears like this: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

The modified line appears like this: admin_passwd = newpassword1234

مهم

It is essential that the password is changed to something else, rather than triggering a new password reset by adding a semicolon ; at the beginning of the line. This ensures the database is secure throughout the entire password reset process.

Restart Odoo server

After setting the temporary password, a restart of the Odoo server is required.

To restart the Odoo server, first, type services into the Windows Search bar. Then, select the Services application, and scroll down to the Odoo service.

Next, right click on Odoo, and select Start or Restart. This action manually restarts the Odoo server.

Use web interface to re-encrypt password

First, navigate to /web/database/manager or http://server_ip:port/web/database/manager in a browser.

ملاحظة

Replace server_ip with the IP address of the database. Replace port with the numbered port the database is accessible from.

Next, click Set Master Password, and type in the previously-selected temporary password into the Master Password field. Following this step, type in a New Master Password. The New Master Password is hashed (or encrypted), once the Continue button is clicked.

At this point, the password has been successfully reset, and a hashed version of the new password now appears in the configuration file.

انظر أيضًا

For more information on Odoo database security, see this documentation: أمن مدير قاعدة البيانات.

المتصفحات المدعومة

يدعم أودو أحدث الإصدارات للمتصفحات التالية.

  • Google Chrome

  • Mozilla Firefox

  • Microsoft Edge

  • Apple Safari

1

حتى تقوم عدة عمليات تثبيت لأودو باستخدام نفس قاعدة بيانات PostgreSQL، أو لتوفير المزيد من موارد الحوسبة لكلا البرنامجين.

2

من الناحية الفنية، يمكن استخدام أداة مثل socat لتوكيل مقابس توصيل UNIX عبر الشبكات، ولكن ذلك مخصص في الغالب للبرامج التي لا يمكن استخدامها إلا عبر مقابس توصيل UNIX

3

أو يمكن الوصول إليها فقط عبر شبكة داخلية لتبديل الحزم، ولكن يتطلب ذلك محولات آمنة وحماية ضد ``انتحال الشخصية ARP`_ ويمنع استخدام WiFi. وحتى عبر شبكات تبديل الحزم الآمنة، نوصي بالاستخدام عبر HTTPS، ويتم تقليل التكاليف المحتملة، حيث من الأسهل استخدام الشهادات "الموقعة ذاتياً" في بيئة خاضعة للرقابة مقارنة بالإنترنت.