اوڈو سیکیورٹی سخت: توثیق، رسائی کے حقوق، اور خفیہ کاری

انٹرپرائز ERP سسٹم سائبر حملوں کے لیے اعلیٰ قدر کے اہداف ہیں۔ ایک Odoo مثال جس میں گاہک PII، مالیاتی ریکارڈ، سپلائی کنٹریکٹس، اور ملازمین کے ڈیٹا پر مشتمل ایک اہم حملے کی سطح کی نمائندگی کرتا ہے جو جان بوجھ کر، تہہ دار سیکیورٹی کنٹرولز کا مطالبہ کرتا ہے۔

یہ گائیڈ Odoo 19 انٹرپرائز کے لیے مکمل حفاظتی سختی کے عمل کا احاطہ کرتا ہے: نیٹ ورک سختی، خفیہ کاری، آڈٹ لاگنگ، اور واقعے کے ردعمل کی تیاری کے ذریعے تصدیق کو مضبوط بنانے اور حقوق کے ڈیزائن تک رسائی۔

اہم ٹیک ویز

پہلے سے طے شدہ Odoo کنفیگریشنز حفاظتی نقطہ نظر سے پیداوار کے لیے تیار نہیں ہیں۔

دو عنصر کی تصدیق (2FA) حساس رسائی والے تمام صارفین کے لیے لازمی ہونی چاہیے

رسائی کے حقوق کم از کم استحقاق کے اصول پر عمل کرتے ہیں — صارفین کو صرف وہی ملتا ہے جس کی انہیں ضرورت ہوتی ہے۔

ریکارڈ کے قواعد ڈیٹا کی تنہائی کو نافذ کرنے کے لیے قطار کی سطح کی حفاظت فراہم کرتے ہیں۔

تمام انٹر-سروس کمیونیکیشن TLS کا استعمال کریں۔ پیداوار میں HTTP کبھی نہیں

ڈیٹا بیس کی اسناد کو باقاعدگی سے گھمایا جانا چاہیے اور کبھی ہارڈ کوڈ نہیں کیا جانا چاہیے۔

آڈٹ لاگز چھیڑ چھاڑ سے پاک اور تعمیل کے تقاضوں کے لیے برقرار رکھے جائیں۔

Odoo SA کے اعلانات کے 48 گھنٹوں کے اندر سیکیورٹی پیچ لاگو کیے جائیں۔

توثیق سخت کرنا

پاس ورڈ کی پالیسی

Odoo 19 ترتیبات → صارفین اور کمپنیاں → پاس ورڈ دوبارہ ترتیب دینے کی پالیسی کے تحت قابل ترتیب پاس ورڈ کی پالیسیوں کو سپورٹ کرتا ہے۔

تجویز کردہ ترتیبات:

کم از کم لمبائی: 12 حروف
بڑے، چھوٹے، نمبر اور خصوصی حروف کی ضرورت ہے۔
پاس ورڈ کی میعاد: 90 دن
آخری 12 پاس ورڈز کے دوبارہ استعمال کو روکیں۔
5 ناکام کوششوں کے بعد اکاؤنٹ لاک آؤٹ (15 منٹ کا لاک آؤٹ)

# Custom password validator in a security module
from odoo import api, models
from odoo.exceptions import UserError
import re

class ResUsers(models.Model):
    _inherit = 'res.users'

    @api.constrains('password')
    def _check_password_strength(self):
        for user in self:
            if user.password:
                pwd = user.password
                if len(pwd) < 12:
                    raise UserError("Password must be at least 12 characters.")
                if not re.search(r'[A-Z]', pwd):
                    raise UserError("Password must contain an uppercase letter.")
                if not re.search(r'[a-z]', pwd):
                    raise UserError("Password must contain a lowercase letter.")
                if not re.search(r'\d', pwd):
                    raise UserError("Password must contain a number.")
                if not re.search(r'[!@#$%^&*(),.?":{}|<>]', pwd):
                    raise UserError("Password must contain a special character.")

دو عنصر کی توثیق (2FA)

سیٹنگز → پرمیشنز → ٹو فیکٹر توثیق کے تحت 2FA کو فعال کریں۔

ترتیب کے اختیارات:

اختیاری: صارفین انتخاب کرتے ہیں کہ آیا 2FA کو فعال کرنا ہے۔
مخصوص گروپس کے لیے ضروری: ایڈمنسٹریٹرز اور اکاؤنٹنٹس کے لیے درخواست دیں۔
تمام صارفین کے لیے ضروری: زیادہ سے زیادہ سیکیورٹی

انٹرپرائز کی تعیناتیوں کے لیے، 2FA کی ضرورت ہے:

ایڈمنسٹریٹر اکاؤنٹس (base.group_system)
مالیاتی صارفین (account.group_account_manager)
پے رول تک رسائی کے ساتھ HR مینیجرز
API کلیدی رسائی والے تمام صارفین

OAuth اور SSO انٹیگریشن

موجودہ شناخت فراہم کنندگان والی تنظیموں کے لیے، SAML 2.0 یا OAuth 2.0 استعمال کرنے کے لیے Odoo کو ترتیب دیں:

# In odoo.conf — configure OAuth
oauth_providers = [
    {
        'name': 'Your SSO Provider',
        'client_id': 'odoo-client-id',
        'auth_endpoint': 'https://sso.company.com/auth',
        'validation_endpoint': 'https://sso.company.com/userinfo',
        'scope': 'openid email profile',
    }
]

یہ آپ کے شناختی فراہم کنندہ میں توثیق کو مرکزی بناتا ہے، ملازمین کے رخصت ہونے پر سنگل سائن آن، سنٹرلائزڈ MFA، اور خودکار اکاؤنٹ کی عدم فراہمی جیسی خصوصیات کو فعال کرتا ہے۔

API کلیدی سیکیورٹی

# Restrict API key creation to administrators only
# In custom security module:

# ir.rule to prevent non-admin users from creating API keys
<record id="rule_api_key_admin_only" model="ir.rule">
    <field name="name">API Keys: Admin Only</field>
    <field name="model_id" ref="base.model_auth_api_key"/>
    <field name="domain_force">[('create_uid', '=', user.id)]</field>
    <field name="groups" eval="[(4, ref('base.group_user'))]"/>
    <field name="perm_create" eval="False"/>
    <field name="perm_unlink" eval="False"/>
</record>

پالیسی نافذ کریں: API کیز 90 دن کے بعد ختم ہو جاتی ہیں، کم سے کم اجازتوں کے ساتھ وقف سروس اکاؤنٹس سے منسلک ہوتی ہیں، اور کسی بھی مشتبہ سمجھوتے پر گھمائی جاتی ہیں۔

رسائی کے حقوق فن تعمیر

گروپ کے درجہ بندی کا ڈیزائن

اوڈو کا رسائی کنٹرول گروپوں پر مبنی ہے۔ ایک گروپ کے درجہ بندی کو ڈیزائن کریں جو آپ کے تنظیمی ڈھانچے کی عکاسی کرتا ہے:

base.group_user (Internal User)
├── sales.group_sale_salesman (Salesperson)
│   └── sales.group_sale_manager (Sales Manager)
├── account.group_account_user (Accounting User)
│   └── account.group_account_manager (Accounting Manager)
├── stock.group_stock_user (Inventory User)
│   └── stock.group_stock_manager (Inventory Manager)
└── base.group_system (Administrator)

کم سے کم استحقاق کا اصول: ہر صارف کو اپنا کام انجام دینے کے لیے کم سے کم رسائی حاصل ہونی چاہیے۔ یہ سمجھوتہ شدہ اکاؤنٹس کے دھماکے کے رداس کو محدود کرتا ہے۔

رسائی کنٹرول فہرستیں (ACL)

ir.model.access میں ACL اندراجات ماڈل کی سطح کی CRUD اجازتوں کی وضاحت کرتی ہیں:

id,name,model_id,group_id,perm_read,perm_write,perm_create,perm_unlink
# Salesperson: can read/write own orders, cannot delete
access_sale_order_salesman,sale.order.salesman,sale.model_sale_order,sales.group_sale_salesman,1,1,1,0
# Manager: full CRUD
access_sale_order_manager,sale.order.manager,sale.model_sale_order,sales.group_sale_manager,1,1,1,1
# Accounting user: read-only on sales orders
access_sale_order_accountant,sale.order.accountant,sale.model_sale_order,account.group_account_user,1,0,0,0

ریکارڈ کے قواعد (قطار کی سطح کی حفاظت)

ریکارڈ رولز فلٹر جو صارف ماڈل میں دیکھ سکتا ہے:

<!-- Salesperson sees only their own opportunities -->
<record id="rule_crm_salesman" model="ir.rule">
    <field name="name">CRM: Own Leads</field>
    <field name="model_id" ref="crm.model_crm_lead"/>
    <field name="domain_force">
        ['|', ('user_id', '=', user.id), ('user_id', '=', False)]
    </field>
    <field name="groups" eval="[(4, ref('sales.group_sale_salesman'))]"/>
</record>

<!-- Multi-company isolation: users see only their company's records -->
<record id="rule_sale_order_company" model="ir.rule">
    <field name="name">Sale Order: Company</field>
    <field name="model_id" ref="sale.model_sale_order"/>
    <field name="domain_force">
        [('company_id', 'in', company_ids)]
    </field>
    <field name="groups" eval="[(4, ref('base.group_user'))]"/>
</record>

کارکردگی کی وارننگ: بہت سے search() یا child_of آپریٹرز کے ساتھ ریکارڈ کے پیچیدہ قواعد فہرست کے نظارے کو نمایاں طور پر سست کر سکتے ہیں۔ پروڈکشن میں تعینات کرنے سے پہلے بڑے ڈیٹا سیٹس کے خلاف ریکارڈ کے تمام قواعد کی جانچ کریں۔

نیٹ ورک سیکیورٹی

TLS/HTTPS نفاذ

پیداوار میں سادہ HTTP پر Odoo کو کبھی نہ چلائیں۔ تمام ٹریفک کو انکرپٹ کیا جانا چاہیے۔

Nginx TLS کنفیگریشن:

server {
    listen 80;
    server_name your-odoo.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name your-odoo.com;

    ssl_certificate /etc/ssl/certs/your-odoo.com.pem;
    ssl_certificate_key /etc/ssl/private/your-odoo.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
                ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;
    ssl_session_tickets off;

    # HSTS: 2 years, include subdomains
    add_header Strict-Transport-Security
        "max-age=63072000; includeSubDomains; preload" always;

    # Security headers
    add_header X-Frame-Options DENY always;
    add_header X-Content-Type-Options nosniff always;
    add_header Referrer-Policy strict-origin-when-cross-origin always;
    add_header Permissions-Policy
        "camera=(), microphone=(), geolocation=()" always;
}

فائر وال کنفیگریشن

# UFW firewall rules for Odoo server
ufw default deny incoming
ufw default allow outgoing

# Allow SSH from management IP only
ufw allow from 10.0.1.100 to any port 22

# Allow HTTPS from anywhere
ufw allow 443/tcp

# Allow HTTP (for Let's Encrypt renewal)
ufw allow 80/tcp

# Allow PostgreSQL only from Odoo server (if separate DB server)
ufw allow from 10.0.1.10 to any port 5432

# Block direct access to Odoo port (must go through Nginx)
ufw deny 8069/tcp
ufw deny 8072/tcp

ufw enable

شرح کی حد

بروٹ فورس کے حملوں کو روکنے کے لیے Nginx میں شرح کو محدود کرنا:

# Rate limiting zones
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=api:10m rate=60r/m;

server {
    # Apply rate limiting to login endpoint
    location /web/login {
        limit_req zone=login burst=3 nodelay;
        limit_req_status 429;
        proxy_pass http://odoo;
    }

    # Apply rate limiting to API
    location /web/dataset/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://odoo;
    }
}

ڈیٹا انکرپشن

ڈیٹا بیس لیول کی خفیہ کاری

انتہائی حساس ڈیٹا کے لیے، Odoo فیلڈز کو آرام سے خفیہ کیا جا سکتا ہے:

# Custom encrypted field using Fernet symmetric encryption
from cryptography.fernet import Fernet
from odoo import api, fields, models
import base64, os

class EncryptedField(models.Model):
    _name = 'my.sensitive.model'

    _fernet_key = os.environ.get('ODOO_FIELD_ENCRYPTION_KEY')

    ssn_encrypted = fields.Char(string='SSN (Encrypted)', groups='hr.group_hr_user')
    ssn_display = fields.Char(
        string='SSN', compute='_compute_ssn_display',
        inverse='_inverse_ssn_display'
    )

    def _get_fernet(self):
        return Fernet(self._fernet_key.encode())

    def _compute_ssn_display(self):
        f = self._get_fernet()
        for record in self:
            if record.ssn_encrypted:
                decrypted = f.decrypt(record.ssn_encrypted.encode()).decode()
                record.ssn_display = f"***-**-{decrypted[-4:]}"
            else:
                record.ssn_display = False

    def _inverse_ssn_display(self):
        f = self._get_fernet()
        for record in self:
            if record.ssn_display:
                encrypted = f.encrypt(record.ssn_display.encode()).decode()
                record.ssn_encrypted = encrypted

ماحولیاتی متغیر سیکیورٹی

کبھی بھی راز کو odoo.conf میں سادہ متن میں ذخیرہ نہ کریں۔ ماحولیاتی متغیرات کا استعمال کریں:

# /etc/systemd/system/odoo.service
[Service]
Environment="ODOO_DB_PASSWORD=your_secure_password"
Environment="ODOO_ADMIN_PASSWD=your_master_password"
Environment="ODOO_FIELD_ENCRYPTION_KEY=your_fernet_key"
EnvironmentFile=/etc/odoo/secrets.env

# odoo.conf — reference env vars
[options]
db_password = ${ODOO_DB_PASSWORD}
admin_passwd = ${ODOO_ADMIN_PASSWD}

آڈٹ لاگنگ

Odoo کی بلٹ ان آڈٹ لاگنگ ماڈل کی تمام تبدیلیوں کو ٹریک کرتی ہے۔ اسے حساس ماڈلز کے لیے فعال کریں:

# Enable audit logging via the Audit Trail module
# Or implement custom logging:

class AuditableMixin(models.AbstractModel):
    _name = 'audit.mixin'

    def write(self, vals):
        # Log what changed before the write
        for record in self:
            old_vals = {f: record[f] for f in vals if f in record._fields}
            self.env['audit.log'].create({
                'model_name': self._name,
                'record_id': record.id,
                'user_id': self.env.uid,
                'action': 'write',
                'old_values': str(old_vals),
                'new_values': str(vals),
                'ip_address': self.env.context.get('remote_addr'),
            })
        return super().write(vals)

    def unlink(self):
        for record in self:
            self.env['audit.log'].create({
                'model_name': self._name,
                'record_id': record.id,
                'user_id': self.env.uid,
                'action': 'unlink',
                'old_values': str({f: record[f] for f in ['name', 'id']}),
            })
        return super().unlink()

آڈٹ کے لیے تعمیل کے لیے اہم ماڈلز:

res.users (صارف کی تخلیق، اجازت میں تبدیلی)
account.move (انوائس میں ترمیم)
hr.payslip (پے رول میں تبدیلیاں)
res.partner (کسٹمر/وینڈر PII تبدیلیاں)
ir.model.access، ir.rule (اجازت میں تبدیلی)
ir.config_parameter (نظام کی ترتیب میں تبدیلیاں)

سیکیورٹی پیچ مینجمنٹ

اوڈو سیکیورٹی ایڈوائزریز کو سبسکرائب کریں:

Odoo SA https://github.com/odoo/odoo/security/advisories پر حفاظتی مشورے شائع کرتا ہے۔ اس ذخیرہ کے لیے GitHub اطلاعات کو سبسکرائب کریں۔

پیچ درخواست کا عمل:

# Check current Odoo version
python3 odoo-bin --version

# Pull latest security patches (within a minor version)
cd /opt/odoo
git fetch origin
git log origin/19.0..HEAD --oneline  # See what's changed

# Apply patches on staging first
git merge origin/19.0
python3 odoo-bin -d staging_db -u all --stop-after-init

# Test critical workflows on staging
# If all clear, apply to production during maintenance window

ہدف: 48 گھنٹے کے اندر پیچ ایک اہم یا زیادہ شدت کے مشورے کے۔ درمیانی شدت: 1 ہفتے کے اندر۔ کم شدت: اگلی منصوبہ بند دیکھ بھال کی کھڑکی۔

اکثر پوچھے گئے سوالات

میں کیسے آڈٹ کروں کہ کس نے Odoo میں ریکارڈ حذف کیا؟

Odoo ڈیفالٹ کے ذریعے ڈیلیٹ کو لاگ نہیں کرتا ہے۔ Odoo Community Association (OCA) سے auditlog ماڈیول انسٹال کریں یا اپنے حساس ماڈلز میں حسب ضرورت unlink() اوور رائڈ کو لاگو کریں۔ OCA auditlog ماڈیول لاگز صارف، ٹائم اسٹیمپ، اور فیلڈ لیول کی تبدیلی سے باخبر رہنے کے ساتھ auditlog.log ماڈل سے آپریشنز تخلیق، لکھتے اور ان کا لنک بناتے ہیں۔

کیا میں IP ایڈریس کے ذریعے Odoo تک رسائی کو محدود کر سکتا ہوں؟

مقامی طور پر اوڈو میں نہیں۔ Nginx یا فائر وال کی سطح پر IP کی اجازت کی فہرست کو نافذ کریں۔ انتظامی رسائی کے لیے، بطور شرط VPN کنکشن درکار ہے۔ Odoo کا ir.config_parameter web.base.url پابندی کی حمایت کرتا ہے، لیکن حقیقی IP پر مبنی رسائی کنٹرول نیٹ ورک کی تہہ سے تعلق رکھتا ہے۔

رسائی حقوق (ACL) اور ریکارڈ کے قواعد میں کیا فرق ہے؟

رسائی کے حقوق (ACL، ir.model.access میں محفوظ) کنٹرول کرتا ہے کہ آیا صارف گروپ کسی ماڈل کے کسی بھی ریکارڈ کو پڑھ سکتا ہے، لکھ سکتا ہے، بنا سکتا ہے یا حذف کر سکتا ہے — یہ ماڈل سطح کا کنٹرول ہے۔ ریکارڈ رولز فلٹر کرتے ہیں کہ صارف ڈومین ایکسپریشنز کا استعمال کرتے ہوئے ماڈل کے اندر کن مخصوص ریکارڈز تک رسائی حاصل کر سکتا ہے — یہ قطار کی سطح کا کنٹرول ہے۔ دونوں ایک ساتھ کام کرتے ہیں: صارف کو ACL پڑھنے کی اجازت درکار ہوتی ہے اور ریکارڈ دیکھنے کے لیے اسے ریکارڈ رول ڈومین فلٹر پاس کرنا چاہیے۔

مجھے Odoo ماسٹر پاس ورڈ (admin_passwd) کو کیسے ہینڈل کرنا چاہیے؟

odoo.conf میں admin_passwd /web/database/manager پر ڈیٹا بیس مینجمنٹ انٹرفیس تک رسائی کو کنٹرول کرتا ہے۔ پیداوار میں: اسے ایک طویل بے ترتیب تار (32+ حروف) پر سیٹ کریں، اسے پاس ورڈ مینیجر میں اسٹور کریں، اسے کبھی بھی شیئر نہ کریں، اور اگر آپ براہ راست PostgreSQL رسائی کے ذریعے ڈیٹا بیس کا نظم کرتے ہیں تو odoo.conf میں list_db = False کے ساتھ ڈیٹا بیس مینیجر کو مکمل طور پر غیر فعال کرنے پر غور کریں۔

کیا مجھے Odoo کو روٹ کے طور پر چلانا چاہیے؟

کبھی نہیں۔ ایک سرشار odoo سسٹم صارف بنائیں جس میں شیل تک رسائی اور فائل سسٹم کی محدود اجازت نہیں ہے۔ اوڈو صارف کو اوڈو کوڈبیس تک پڑھنے اور صرف فائل اسٹور اور لاگ ڈائرکٹری تک رسائی کی ضرورت ہے۔ سسٹمڈ سروس کو اس صارف کے بطور چلائیں۔ جڑ کے طور پر چلانے سے کم از کم استحقاق کے اصول کی خلاف ورزی ہوتی ہے اور کوڈ پر عمل درآمد کے خطرے سے زیادہ سے زیادہ نقصان ہوتا ہے۔

اگلے اقدامات

سیکیورٹی کو سخت کرنا ایک بار کا کام نہیں ہے - یہ ایک جاری عمل ہے۔ نئی کمزوریاں ابھرتی ہیں، صارف تک رسائی کے تقاضے بدل جاتے ہیں، اور تعمیل کا فریم ورک تیار ہوتا ہے۔ ایک محفوظ Odoo تعیناتی کے لیے باقاعدگی سے حفاظتی جائزے، پیچ مینجمنٹ ڈسپلن، اور رسائی کے حقوق کے آڈٹ کی ضرورت ہوتی ہے۔

ECOSIRE Odoo سیکیورٹی کو سخت کرنے کے جائزے فراہم کرتا ہے جو غلط کنفیگریشنز، ضرورت سے زیادہ اجازتوں، گمشدہ کنٹرولز، اور تعمیل کے فرق کی نشاندہی کرتا ہے۔ ہماری سیکیورٹی ٹیم کو Odoo ماحول میں ISO 27001, SOC 2 اور GDPR کے تقاضوں کا تجربہ ہے۔

ECOSIRE سے ایک Odoo سیکیورٹی اسسمنٹ کی درخواست کریں →

ہم صنعت کے معیارات کے خلاف آپ کی موجودہ ترتیب کا جائزہ لیں گے اور نفاذ کے تعاون کے ساتھ ایک ترجیحی تدارک کا منصوبہ پیش کریں گے۔

Odoo Security Hardening: Authentication, Access Rights, and Encryption