Odoo Security Hardening: Authentication, Access Rights, and Encryption

Comprehensive Odoo 19 security hardening guide covering authentication, access rights, record rules, encryption, network security, and audit logging for enterprise deployments.

E
ECOSIRE Research and Development Team
|19 मार्च 202610 मिनट पढ़ें2.1k शब्द|
odoosecurityhardeningaccess-rights+1

ओडू सिक्योरिटी हार्डनिंग: प्रमाणीकरण, एक्सेस अधिकार और एन्क्रिप्शन

एंटरप्राइज़ ईआरपी सिस्टम साइबर हमलों के लिए उच्च-मूल्य वाले लक्ष्य हैं। ग्राहक पीआईआई, वित्तीय रिकॉर्ड, आपूर्तिकर्ता अनुबंध और कर्मचारी डेटा वाला एक ओडू उदाहरण एक महत्वपूर्ण हमले की सतह का प्रतिनिधित्व करता है जो जानबूझकर, स्तरित सुरक्षा नियंत्रण की मांग करता है।

यह मार्गदर्शिका ओडू 19 एंटरप्राइज के लिए संपूर्ण सुरक्षा सख्त प्रक्रिया को कवर करती है: प्रमाणीकरण सुदृढ़ीकरण और नेटवर्क हार्डनिंग, एन्क्रिप्शन, ऑडिट लॉगिंग और घटना प्रतिक्रिया तैयारी के माध्यम से एक्सेस अधिकार डिजाइन तक।

मुख्य बातें

  • सुरक्षा दृष्टिकोण से डिफ़ॉल्ट ओडू कॉन्फ़िगरेशन उत्पादन के लिए तैयार नहीं हैं
  • संवेदनशील पहुंच वाले सभी उपयोगकर्ताओं के लिए दो-कारक प्रमाणीकरण (2FA) अनिवार्य होना चाहिए
  • एक्सेस अधिकार कम से कम विशेषाधिकार के सिद्धांत का पालन करते हैं - उपयोगकर्ताओं को केवल वही मिलता है जो उन्हें चाहिए
  • रिकॉर्ड नियम डेटा अलगाव को लागू करने के लिए पंक्ति-स्तरीय सुरक्षा प्रदान करते हैं
  • सभी अंतर-सेवा संचार में टीएलएस का उपयोग होना चाहिए; उत्पादन में 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.")

दो-कारक प्रमाणीकरण (2एफए)

सेटिंग्स → अनुमतियाँ → दो-कारक प्रमाणीकरण के अंतर्गत 2FA सक्षम करें।

कॉन्फ़िगरेशन विकल्प:

  • वैकल्पिक: उपयोगकर्ता चुनते हैं कि 2FA सक्षम करना है या नहीं
  • विशिष्ट समूहों के लिए आवश्यक: प्रशासकों और लेखाकारों पर लागू करें
  • सभी उपयोगकर्ताओं के लिए आवश्यक: अधिकतम सुरक्षा

एंटरप्राइज़ परिनियोजन के लिए, 2FA की आवश्यकता है:

  • प्रशासक खाते (base.group_system)
  • वित्त उपयोगकर्ता (account.group_account_manager)
  • पेरोल पहुंच वाले मानव संसाधन प्रबंधक
  • एपीआई कुंजी पहुंच वाले सभी उपयोगकर्ता

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',
    }
]

यह आपके पहचान प्रदाता में प्रमाणीकरण को केंद्रीकृत करता है, जिससे कर्मचारियों के जाने पर एकल साइन-ऑन, केंद्रीकृत एमएफए और स्वचालित खाता डीप्रोविजनिंग जैसी सुविधाएं सक्षम होती हैं।

API Key Security

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

एक नीति लागू करें: एपीआई कुंजियाँ 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)

न्यूनतम विशेषाधिकार का सिद्धांत: प्रत्येक उपयोगकर्ता के पास अपना काम करने के लिए आवश्यक न्यूनतम पहुंच होनी चाहिए। यह समझौता किए गए खातों के ब्लास्ट दायरे को सीमित करता है।

एक्सेस कंट्रोल सूचियाँ (एसीएल)

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 ऑपरेटरों के साथ जटिल रिकॉर्ड नियम सूची दृश्य को काफी धीमा कर सकते हैं। उत्पादन में तैनात करने से पहले बड़े डेटासेट के विरुद्ध सभी रिकॉर्ड नियमों का परीक्षण करें।

नेटवर्क सुरक्षा

टीएलएस/एचटीटीपीएस प्रवर्तन

उत्पादन में ओडू को कभी भी सादे HTTP पर न चलाएँ। सभी ट्रैफ़िक को एन्क्रिप्ट किया जाना चाहिए.

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}

ऑडिट लॉगिंग

ओडू की अंतर्निहित ऑडिट लॉगिंग सभी मॉडल परिवर्तनों को ट्रैक करती है। संवेदनशील मॉडलों के लिए इसे सक्षम करें:

# 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 (ग्राहक/विक्रेता पीआईआई परिवर्तन)
  • ir.model.access, ir.rule (अनुमति परिवर्तन)
  • ir.config_parameter (सिस्टम कॉन्फ़िगरेशन परिवर्तन)

सुरक्षा पैच प्रबंधन

Odoo सुरक्षा सलाह की सदस्यता लें:

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 डिफ़ॉल्ट रूप से विलोपन लॉग नहीं करता है। ओडू कम्युनिटी एसोसिएशन (ओसीए) से auditlog मॉड्यूल स्थापित करें या अपने संवेदनशील मॉडलों में एक कस्टम unlink() ओवरराइड लागू करें। OCA ऑडिटलॉग मॉड्यूल उपयोगकर्ता, टाइमस्टैम्प और फ़ील्ड-स्तरीय परिवर्तन ट्रैकिंग के साथ auditlog.log मॉडल में ऑपरेशन बनाता है, लिखता है और अनलिंक करता है।

क्या मैं आईपी पते द्वारा ओडू पहुंच को प्रतिबंधित कर सकता हूं?

ओडू में मूल रूप से नहीं। Nginx या फ़ायरवॉल स्तर पर IP अनुमति सूची लागू करें। प्रशासनिक पहुंच के लिए, एक शर्त के रूप में वीपीएन कनेक्शन की आवश्यकता होती है। Odoo का ir.config_parameter web.base.url प्रतिबंध का समर्थन करता है, लेकिन वास्तविक IP-आधारित पहुंच नियंत्रण नेटवर्क परत में होता है।

एक्सेस राइट्स (एसीएल) और रिकॉर्ड नियमों के बीच क्या अंतर है?

एक्सेस अधिकार (ACL, ir.model.access में संग्रहीत) नियंत्रित करता है कि उपयोगकर्ता समूह किसी मॉडल के किसी भी रिकॉर्ड को पढ़, लिख, बना या हटा सकता है या नहीं - यह मॉडल-स्तरीय नियंत्रण है। रिकॉर्ड नियम फ़िल्टर करते हैं कि उपयोगकर्ता डोमेन अभिव्यक्तियों का उपयोग करके मॉडल के भीतर कौन से विशिष्ट रिकॉर्ड तक पहुंच सकता है - यह पंक्ति-स्तरीय नियंत्रण है। दोनों एक साथ काम करते हैं: उपयोगकर्ता को रिकॉर्ड देखने के लिए ACL पढ़ने की अनुमति की आवश्यकता होती है और रिकॉर्ड नियम डोमेन फ़िल्टर को पास करना होगा।

मुझे ओडू मास्टर पासवर्ड (admin_passwd) को कैसे संभालना चाहिए?

Odoo.conf में admin_passwd /web/database/manager पर डेटाबेस प्रबंधन इंटरफ़ेस तक पहुंच को नियंत्रित करता है। उत्पादन में: इसे एक लंबी यादृच्छिक स्ट्रिंग (32+ अक्षर) पर सेट करें, इसे पासवर्ड मैनेजर में संग्रहीत करें, इसे कभी भी साझा न करें, और यदि आप सीधे PostgreSQL एक्सेस के माध्यम से डेटाबेस का प्रबंधन करते हैं तो odoo.conf में list_db = False के साथ डेटाबेस मैनेजर को पूरी तरह से अक्षम करने पर विचार करें।

क्या मुझे ओडू को रूट के रूप में चलाना चाहिए?

कभी नहीं। बिना किसी शेल एक्सेस और सीमित फ़ाइल सिस्टम अनुमतियों के एक समर्पित odoo सिस्टम उपयोगकर्ता बनाएं। ओडू उपयोगकर्ता को ओडू कोडबेस तक पढ़ने की पहुंच और केवल फाइलस्टोर और लॉग निर्देशिकाओं तक लिखने की पहुंच की आवश्यकता होती है। इस उपयोगकर्ता के रूप में सिस्टमड सेवा चलाएँ। रूट के रूप में चलाना न्यूनतम विशेषाधिकार के सिद्धांत का उल्लंघन करता है और किसी भी कोड निष्पादन भेद्यता से क्षति को अधिकतम करता है।

अगले चरण

सुरक्षा सख्त करना एक बार का काम नहीं है - यह एक सतत अभ्यास है। नई कमजोरियाँ उभरती हैं, उपयोगकर्ता पहुँच आवश्यकताएँ बदलती हैं, और अनुपालन ढाँचा विकसित होता है। एक सुरक्षित ओडू परिनियोजन के लिए नियमित सुरक्षा समीक्षा, पैच प्रबंधन अनुशासन और एक्सेस अधिकार ऑडिट की आवश्यकता होती है।

ECOSIRE Odoo सुरक्षा सख्त मूल्यांकन प्रदान करता है जो गलत कॉन्फ़िगरेशन, अत्यधिक अनुमतियाँ, लापता नियंत्रण और अनुपालन अंतराल की पहचान करता है। हमारी सुरक्षा टीम के पास ओडू वातावरण में ISO 27001, SOC 2 और GDPR आवश्यकताओं का अनुभव है।

ECOSIRE से ओडू सुरक्षा आकलन का अनुरोध करें →

हम उद्योग मानकों के अनुरूप आपके वर्तमान कॉन्फ़िगरेशन की समीक्षा करेंगे और कार्यान्वयन समर्थन के साथ प्राथमिकता वाली सुधारात्मक योजना प्रदान करेंगे।

टैग:odoosecurityhardeningaccess-rightsencryption
शेयर करें:
E

लेखक

ECOSIRE Research and Development Team

ECOSIRE में एंटरप्राइज़-ग्रेड डिजिटल उत्पाद बना रहे हैं। Odoo एकीकरण, ई-कॉमर्स ऑटोमेशन, और AI-संचालित व्यावसायिक समाधानों पर अंतर्दृष्टि साझा कर रहे हैं।

सभी पोस्ट देखें

संबंधित लेख

accounting

Odoo Accounting vs QuickBooks: Detailed Comparison 2026

In-depth 2026 comparison of Odoo Accounting vs QuickBooks covering features, pricing, integrations, scalability, and which platform fits your business needs.

15 मिनट पढ़ें
api

API Rate Limiting: Patterns and Best Practices

Master API rate limiting with token bucket, sliding window, and fixed counter patterns. Protect your backend with NestJS throttler, Redis, and real-world configuration examples.

11 मिनट पढ़ें
case-study

Case Study: eCommerce Migration to Shopify with Odoo Backend

How a fashion retailer migrated from WooCommerce to Shopify and connected it to Odoo ERP, cutting order fulfillment time by 71% and growing revenue 43%.

13 मिनट पढ़ें
सभी लेखों पर वापस
WhatsApp पर चैट करें