În primele trei rapoarte ale seriei noastre de investigații tehnice, am analizat în detaliu riscurile concrete care apar atunci când companiile încredințează operațiunile critice unor aplicații web artizanale sau platforme serverless neconsolidate:
- Exfiltrarea masivă a datelor apare prin puncte finale publice și formulare deschise de înregistrare care permit descărcarea a zeci de mii de înregistrări cu date personale (PII);
- Atribuirea în masă pe partea de client (CWE-915) permite angajaților cu drepturi limitate să își acorde singuri privilegii de Super-Administrator direct din consola browserului;
- Compromiterea centralei telefonice (CWE-522) este cauzată de parolele principale de administrare SIP și credențialele statice TURN livrate în clar către browsere, expunând compania la fraudă internațională;
- Colapsul evidenței financiare rezultă din avalanșe de execuție serverless de 622.000 GB-secunde de calcul și diferențe de milioane de euro în registrul de casă din cauza lipsei partidei duble.
Toate aceste incidente au o cauză structurală comună: presupunerea naivă că browserul client poate fi considerat de încredere pentru validarea securității sau calculul logicii de afaceri.
Când o organizație își migrează activitatea operațională către nucleul Odoo 19 CE găzduit pe mașini virtuale dedicate cu PostgreSQL, această întreagă suprafață de atac este eliminată din start. Securitatea nu este un artificiu de interfață adăugat ulterior, ci o barieră matematică garantată direct la nivelul nucleului sistemului și al bazei de date.
Acest document detaliază Standardul în 10 Puncte Zero Client-Side Trust, oferind echipelor de conducere tehnică un instrument verificabil pentru securizarea sistemelor ERP împotriva amenințărilor moderne.
Bariera de izolare pe trei niveluri în modelul Zero-Trust
Diferența structurală majoră dintre Odoo 19 CE și aplicațiile web de tip thick-client constă în separarea strictă a trei planuri de execuție:
Fluxul de Securitate pe Trei Niveluri în Odoo 19
Perimetrul Client Nedeîncredere
Browserele web, aplicațiile mobile și integrările API externe operează într-o zonă complet nesigură. Comunicarea se face strict prin HTTPS / JSON-RPC.
Gateway-ul de Securitate Odoo ORM (Python)
Fiecare cerere este interceptată de serverul Odoo. Nucleul verifică matricile de acces (ACL), adaugă filtrele de rând (ir.rule) și curăță câmpurile ascunse.
Motorul de Baze de Date PostgreSQL Izolat
PostgreSQL ascultă strict pe interfața locală (127.0.0.1 sau rețea privată VPC). Accesul direct de pe internet este blocat fizic.
Garanția Tranzacțională ACID
Baza de date execută tranzacții atomice cu blocare la nivel de rând (SELECT FOR UPDATE) și validează egalitatea dintre debit și credit.
În acest model, browserul este un simplu terminal de afișare. El nu deține conexiune de rețea directă cu PostgreSQL, nu poate trimite comenzi SQL brute și nu poate ocoli regulile de afaceri definite pe server.
Matricea comparativă în 10 puncte
Tabelul de mai jos compară deficiențele identificate în timpul auditurilor noastre asupra sistemelor serverless cu mecanismele de protecție active în Standardul Enterprise Odoo 19 de la dlab.md:
Matricea în 10 Puncte: Sistem Personalizat Vulnerabil vs. Odoo 19 Hardened
Sistem Personalizat Vulnerabil (React + NoSQL)
Anti-Pattern Vulnerabil- Comenzi accesibile prin numere secvențiale ușor de ghicit (BOLA)
- Înregistrare publică deschisă pentru a permite crearea de conturi din browser
- Operatorii spread permit trimiterea câmpului 'role' la salvare (CWE-915)
- Cheile Google Cloud și parolele de SMS vizibile în colecția settings
- Drepturile de acces sunt limitate doar prin ascunderea butoanelor din meniu
- Parolele angajaților salvate în text clar direct în fișele clienților
- Parola sip:admin a centralei trimisă în fișierul JSON al softphone-ului
- Deduplicarea brută pe telefon șterge comenzile clienților existenți
- Declanșatori reactivi care descarcă toată baza în memorie (622k GB-s)
- Statut de plată pe text ('PAID' vs 'paid') și stocuri cu minus
Standardul Enterprise dlab.md Odoo 19 CE
Standard Enterprise Certificat- Jetoane criptografice unice UUIDv4 (const_eq) obligatorii pentru vizualizare
- Perimetru închis: înregistrarea de conturi este strict pe bază de invitație (b2b)
- Câmpuri protejate prin SELF_WRITEABLE_FIELDS; modificările nepermise dau eroare
- Datele sensibile sunt izolate în ir.config_parameter pentru administratori
- Filtrare SQL forțată la nivel de rând prin reguli de sistem (ir.rule)
- Parole stocate cu algoritmi PBKDF2-SHA512 și legături sigure de resetare
- Gateway B2BUA intermediar și jetoane efemere TURN conform RFC 5389
- Relaționare corectă: clientul existent generează automat o oportunitate nouă
- Agregări SQL pe indecși B-Tree executate în sub 2 milisecunde
- Partidă dublă obligatorie (account.move.line) și blocare exclusivă a stocului
Detalierea tehnică a celor 10 vectori
Enumerarea obiectelor fără autentificare (CWE-639 / BOLA)
În sistemul vulnerabil, datele comenzilor puteau fi vizualizate simplu prin modificarea parametrului din adresa web (ORD-202508-0117). În Odoo 19, accesul din portalul public se bazează pe clasa abstractă portal.mixin. Vizualizarea unui document fără autentificare activă impune transmiterea unui jeton criptografic UUIDv4 de 36 de caractere (access_token). Nucleul verifică acest jeton prin comparare în timp constant (const_eq), eliminând atacurile prin analiză de latență. Enumerarea numerelor secvențiale precum SO001 întoarce automat codul 403 Forbidden.
Înregistrarea publică de conturi (CWE-250)
În soluția personalizată, formularul de creare a conturilor a fost lăsat public pe internet pentru ca dispecerii să poată adăuga tehnicieni noi. În Odoo 19, parametrul auth_signup.invitation_scope este fixat ferm pe valoarea b2b (Doar pe bază de invitație). Nicio persoană neautorizată din exterior nu își poate crea singură un cont de angajat.
Atribuirea în masă pe partea de client (CWE-915)
În sistemul auditat, comanda updateDoc(userRef, { role: "admin" }) funcționa deoarece baza de date nu verifica permisiunile pe fiecare proprietate a documentului. În Odoo 19, drepturile pe câmpuri sunt validate pe server prin atributul groups="base.group_system". În plus, modificările de profil făcute de utilizatorii obișnuiți sunt filtrate prin lista albă SELF_WRITEABLE_FIELDS. Orice încercare de a modifica atribute privilegiate generează o excepție AccessError.
Expunerea cheilor în setările globale (CWE-522)
În sistemul nesigur, cheile de acces în cloud și parolele de trimitere a mesajelor SMS se aflau într-un document accesibil oricărui utilizator conectat. În Odoo 19, parametrii de sistem sunt păstrați în tabela ir.config_parameter, protejată exclusiv pentru grupul base.group_system. Niciun tehnician sau operator nu poate citi aceste date prin interfață sau API.
Descărcarea datelor prin filtrare exclusiv în frontend (CWE-284)
În aplicația vulnerabilă, drepturile utilizatorilor se limitau la ascunderea butoanelor din meniul principal, în timp ce interfețele API livrau toate înregistrările. În Odoo 19, securitatea operează direct în faza de construire a interogării SQL prin ir.rule (Securitate la Nivel de Rând). Când un tehnician cere comenzile de lucru, serverul adaugă automat condiția WHERE user_id = current_user.id, blocând descărcarea altor date.
Parole stocate în text clar (CWE-256)
În sistemul analizat, parolele generate erau salvate în clar în fișele clienților pentru a putea fi consultate ulterior. Odoo 19 nu stochează niciodată parole în clar, ci folosește algoritmul criptografic PBKDF2-SHA512 cu sare unică pentru fiecare cont, iar configurarea parolei se realizează prin legături temporare de unică folosință trimise pe email.
Scurgerea parolei administrative a centralei telefonice (CWE-798)
În sistemul auditat, credențialele de administrator ale trunchiului SIP erau trimise în clar către softphone-ul din browser. În Odoo 19, telefonia funcționează printr-un gateway dedicat de tip B2BUA. Browserul interacționează doar cu extensii interne cu drepturi minime, iar traversarea media folosește jetoane efemere TURN conform RFC 5389, cu valabilitate de 3.600 de secunde.
Ștergerea solicitărilor recurente prin deduplicare greșită
În soluția artizanală, o simplă verificare a ultimelor cifre ale numărului de telefon ștergea comenzile noi de la clienții vechi. În Odoo 19, o solicitare venită de la un client existent (res.partner) creează o nouă oportunitate comercială (crm.lead), păstrând întregul istoric de comenzi și echipamente instalate anterior.
Facturi cloud explozive din declanșatori reactivi
În sistemul NoSQL, fiecare modificare rula funcții care descărcau zeci de mii de documente în memoria serverless, consumând 622.000 GB-secunde. În Odoo 19, agregările sunt efectuate direct de PostgreSQL prin indecși B-Tree optimizați, oferind rezultatele în mai puțin de 2 milisecunde, fără costuri suplimentare de cloud.
Contabilitate fictivă pe texte și stocuri negative
În sistemul slab proiectat, plățile erau simple etichete text ("PAID" vs "paid"), iar lipsa blocărilor permitea stocuri negative. În Odoo 19, toate tranzacțiile financiare sunt legate de Registrul în Partidă Dublă (account.move.line), iar scăderile de stoc sunt protejate prin blocări exclusive la nivel de rând (SELECT ... FOR UPDATE), garantând integritatea gestiunii.
Modele de configurare și implementare practică în cod
Cele trei exemple de mai jos ilustrează modul în care Standardul Zero-Trust este implementat în Odoo 19 la nivel de reguli XML, modele ORM în Python și configurări de securitate în PostgreSQL:
Exemple de Configurare a Securității pentru Odoo 19 și PostgreSQL
<?xml version="1.0" encoding="utf-8"?>
<odoo>
<data noupdate="1">
<!-- Izolarea sarcinilor de lucru pe companii în mod multi-company -->
<record id="fsm_task_multi_company_isolation_rule" model="ir.rule">
<field name="name">Izolare Sarcini Multi-Company</field>
<field name="model_id" ref="project.model_project_task"/>
<field name="domain_force">['|', ('company_id', '=', False), ('company_id', 'in', company_ids)]</field>
<field name="global" eval="True"/>
<field name="perm_read" eval="True"/>
<field name="perm_write" eval="True"/>
<field name="perm_create" eval="True"/>
<field name="perm_unlink" eval="True"/>
</record>
<!-- Restricționarea vizualizării doar la sarcinile alocate tehnicianului -->
<record id="fsm_technician_dispatch_personal_rule" model="ir.rule">
<field name="name">Tehnicienii văd doar propriile sarcini</field>
<field name="model_id" ref="project.model_project_task"/>
<field name="domain_force">[('user_ids', 'in', [user.id])]</field>
<field name="groups" eval="[(4, ref('project.group_project_user'))]"/>
<field name="perm_read" eval="True"/>
<field name="perm_write" eval="True"/>
<field name="perm_create" eval="False"/>
<field name="perm_unlink" eval="False"/>
</record>
</data>
</odoo># -*- coding: utf-8 -*-
from odoo import models, fields, api, exceptions, _
class ResPartnerEnterpriseSecurity(models.Model):
_inherit = 'res.partner'
# Limita de credit este protejată și poate fi modificată doar de managerii financiari
credit_limit = fields.Monetary(
string="Limită Credit Comercial",
groups="account.group_account_manager",
tracking=True
)
tax_compliance_status = fields.Selection([
('verified', 'Verificat Fiscal'),
('hold', 'Reținere Administrativă'),
('blacklisted', 'Blocat Comercial')
], default='verified', groups="base.group_system", tracking=True)
@api.model_create_multi
def create(self, vals_list):
for vals in vals_list:
# Blocarea atribuirii neautorizate a limitei de credit prin cereri API
if 'credit_limit' in vals and not self.env.user.has_group('account.group_account_manager'):
raise exceptions.AccessError(_("Eroare de securitate: Doar controlorii financiari pot stabili limite de credit."))
return super().create(vals_list)
def write(self, vals):
if 'tax_compliance_status' in vals and not self.env.user.has_group('base.group_system'):
raise exceptions.AccessError(_("Eroare de securitate: Modificarea stării de conformitate fiscală este rezervată administratorilor."))
return super().write(vals)-- Configurare de securitate pentru nucleul bazei de date PostgreSQL
-- Revocarea permisiunilor publice periculoase
REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT USAGE ON SCHEMA public TO odoo_app_user;
-- Setarea căii sigure și limitarea conexiunilor
ALTER USER odoo_app_user SET search_path = public;
ALTER USER odoo_app_user CONNECTION LIMIT 100;
-- Tabela de audit: Înregistrează modificările critice de roluri și permisiuni
CREATE TABLE IF NOT EXISTS audit_security_log (
id SERIAL PRIMARY KEY,
event_timestamp TIMESTAMPTZ DEFAULT NOW(),
db_user VARCHAR(64) DEFAULT CURRENT_USER,
target_table VARCHAR(64),
operation VARCHAR(16),
old_data JSONB,
new_data JSONB
);
CREATE OR REPLACE FUNCTION log_critical_security_event()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO audit_security_log (target_table, operation, old_data, new_data)
VALUES (TG_TABLE_NAME, TG_OP, to_jsonb(OLD), to_jsonb(NEW));
RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE OR REPLACE TRIGGER trg_audit_user_groups
AFTER UPDATE ON res_groups_users_rel
FOR EACH ROW EXECUTE FUNCTION log_critical_security_event();Verificarea securității în producție prin exemple executabile
Pentru a asigura integritatea automatizată a implementării, auditorii de securitate pot executa următoarele scripturi de validare direct în mediile de testare și producție.
Model securizat Odoo 19 în Python
# -*- coding: utf-8 -*-
from odoo import models, fields, api, exceptions, _
class EnterpriseSecurityPolicy(models.Model):
_name = 'enterprise.security.policy'
_description = 'Politici de Securitate Zero-Trust Enterprise'
_check_company_auto = True
name = fields.Char(string="Identificator Politică", required=True)
company_id = fields.Many2one('res.company', string="Companie", required=True, default=lambda s: s.env.company)
active_mfa_required = fields.Boolean(string="Impune MFA Hardware Token", default=True)
allowed_cidr = fields.Char(string="Subrețele Permise CIDR", default="10.0.0.0/8,192.168.1.0/24")
@api.constrains('company_id', 'allowed_cidr')
def _check_security_isolation(self):
for record in self:
if not record.company_id:
raise exceptions.ValidationError(_("Încălcare Zero-Trust: Politica de securitate trebuie asociată unei companii validate."))
def write(self, vals):
if not self.env.user.has_group('base.group_system'):
raise exceptions.AccessError(_("Încălcare Zero-Trust: Doar Administratorii Root pot modifica politicile de securitate."))
return super().write(vals)Declanșator de audit și securitate la nivel de rând în PostgreSQL
-- Apărare în adâncime PostgreSQL: Auditul modificărilor de privilegii
CREATE TABLE IF NOT EXISTS sys_security_audit_vault (
audit_id BIGSERIAL PRIMARY KEY,
audit_timestamp TIMESTAMPTZ DEFAULT CLOCK_TIMESTAMP(),
operator_user VARCHAR(64) DEFAULT CURRENT_USER,
action_type VARCHAR(16) NOT NULL,
affected_user_id INT NOT NULL,
granted_group_id INT NOT NULL
);
CREATE OR REPLACE FUNCTION trap_privilege_escalation()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO sys_security_audit_vault (action_type, affected_user_id, granted_group_id)
VALUES (TG_OP, NEW.uid, NEW.gid);
RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE OR REPLACE TRIGGER trg_vault_user_privileges
AFTER INSERT OR UPDATE ON res_groups_users_rel
FOR EACH ROW
EXECUTE FUNCTION trap_privilege_escalation();Metodologia de migrare securizată în patru etape
Atunci când companiile migrează de la sisteme artizanale vulnerabile la Odoo 19 CE, procesul de tranziție urmează un protocol clar structurat:
Metodologia de Migrare în 4 Etape (Protocolul dlab.md)
Auditul Criminalistic și Blocarea Imediată a Scurgerilor (Zilele 1–2)
Identificăm toate punctele finale vulnerabile și cheile expuse. Schimbăm imediat parolele trunchiurilor telefonice și cheile de acces în cloud.
Pregătirea Serverului Odoo 19 Securizat (Săptămâna 1)
Configurăm serverul virtual dedicat pe infrastructură cloud europeană securizată, cu PostgreSQL legat la interfața locală și reguli ir.rule active.
Curățarea Datelor și Reconstrucția Balanței (Săptămâna 2)
Curățăm baza de date de clienți, eliminăm dublurile de telefoane și reconstituim soldurile inițiale corecte prin note în partidă dublă.
Lansarea în Producție și Monitorizarea Continuă
Comutăm traficul de producție, rutăm telefonia prin gateway-ul B2BUA securizat și activăm monitorizarea automată a incidentelor.
Când modelele rigide Zero-Trust sunt excesive și când devin obligatorii
În ingineria software este necesar să existe un echilibru corect între cerințele de securitate și obiectivele de viteză ale proiectului.
Adecvarea Măsurilor de Securitate: Prototipare Rapidă vs. Nucleul ERP de Producție
Prototipare Rapidă Permisivă (Risc Redus)
Medii Temporare- Proiecte interne de tip hackathon cu date de test fictive
- Pagini web promoționale temporare cu text exclusiv informativ
- Sesiuni de testare timpurie a interfeței grafice (wireframes)
- Calculatoare de dezvoltare izolate ce folosesc date simulate
- Portaluri publice cu documentație tehnică statică
ERP Tranzacțional Zero-Trust (Mediu de Producție)
Standard Obligatoriu- Sisteme care procesează plăți reale, facturi și relații comerciale
- Baze de date ce gestionează date personale (PII) și salarii
- Infrastructură de telecomunicații conectată la operatori naționali
- Gestiune a stocurilor în mai multe depozite cu bunuri fizice de valoare
- Sisteme supuse auditurilor financiare, conformității GDPR și directivelor NIS2
Analiza compromisurilor tehnice
- Raportul dintre viteza inițială de lucru și apărarea în adâncime arată că definirea detaliată a drepturilor de acces în fișierele
ir.model.access.csv, crearea domeniilor de securitate înir.ruleși configurarea grupurilor de câmpuri necesită un efort inițial structurat. Pentru o pagină temporară de marketing, acest efort este nejustificat. Pentru un ERP care calculează salarii și gestionează depozite, omiterea acestui strat reprezintă o neglijență gravă. - Evaluarea latenței de execuție față de verificarea regulilor demonstrează că filtrarea pe server adaugă o verificare la fiecare cerere. Cu toate acestea, deoarece Odoo 19 traduce aceste reguli direct în clauze SQL
WHERErulate pe indecșii rapizi din PostgreSQL, impactul este de sub 2 milisecunde pe tranzacție, un cost insesizabil în schimbul blocării complete a atacurilor informatice. - Echilibrul dintre libertatea utilizatorilor și conformitatea cu legea evidențiază faptul că un sistem fără jurnale stricte de audit poate părea mai comod pentru utilizatori. Totuși, în cazul unui incident de securitate sau al unui control fiscal, lipsa unei evidențe sigure lasă conducerea companiei fără mijloace de apărare legală.
Ghidul de verificare pre-lansare pentru responsabilii de securitate (CISO)
Înainte de a valida lansarea în producție a oricărui sistem informatic corporativ, solicitați confirmarea acestor zece cerințe:
-
1. Verificați izolarea portului bazei de date confirmând că PostgreSQL ascultă strict pe adresa
127.0.0.1sau într-o rețea privată VPC, astfel încât portul 5432 să nu fie accesibil din internetul public. -
2. Impuneți înregistrarea conturilor doar pe bază de invitație asigurându-vă că parametrul
auth_signup.invitation_scopeare valoareab2bși că înregistrarea publică este oprită. - 3. Auditați criptarea sigură a parolelor verificând în baza de date că toate parolele sunt stocate sub formă de hash-uri PBKDF2-SHA512 cu sare unică.
-
4. Confirmați protejarea parametrilor de configurare încercând să citiți tabela
ir.config_parameterprintr-un cont obișnuit via JSON-RPC și verificând că solicitarea este respinsă cuAccessError. -
5. Validați activarea securității pe rând verificând că există reguli
ir.ruleactive pentru modelele operaționale (sale.order,project.task,account.move), care limitează accesul doar la datele proprii. -
6. Inspectați restricționarea câmpurilor sensibile asigurându-vă că atributele critice (
credit_limit,security_role,cost_price) au setat grupul de acces adecvat (groups="..."). - 7. Verificați rutarea telefoniei prin gateway-ul B2BUA astfel încât softphone-ul să comunice prin serverul B2BUA intermediar, iar credențialele TURN să folosească jetoane efemere RFC 5389.
- 8. Testați constrângerea echilibrului partidei duble confirmând că baza de date blochează tranzacțiile financiare care nu respectă egalitatea ∑Debit - ∑Credit = 0.
-
9. Verificați blocarea accesului concurent la stoc asigurându-vă că rezervările de produse folosesc clauze
SELECT ... FOR UPDATEpentru a preveni stocurile negative. - 10. Confirmați jurnalizarea schimbărilor administrative verificând că modificarea rolurilor de securitate generează automat înregistrări într-o tabelă de audit securizată.
Întrebări frecvente privind auditul de securitate Odoo 19 și PostgreSQL
Odoo 19 folosește motorul ir.rule pentru a intercepta cererile înainte de execuție. Când un utilizator solicită înregistrări, nucleul evaluează regulile active și le adaugă automat ca filtre WHERE direct în interogarea SQL trimisă către PostgreSQL. Acest lucru garantează că datele neautorizate sunt eliminate direct de baza de date, indiferent de parametrii trimiși din browser.
Clasa portal.mixin protejează accesul neautentificat la documente comerciale (cum ar fi facturi sau comenzi de vânzare). În loc să folosească numere secvențiale, sistemul generează un jeton criptografic UUIDv4 de 36 de caractere (access_token). Documentul poate fi deschis doar dacă acest jeton este furnizat și validat printr-o funcție de comparare în timp constant (const_eq).
Instalarea Odoo 19 Community Edition pe propria mașină virtuală dedicată oferă control deplin asupra perimetrului de rețea, a cheilor de criptare a bazei de date și a politicilor de acces. Ea elimină riscurile de 'vecin zgomotos' și partajarea parolelor între companii diferite, asigurând totodată conformitatea completă cu normele europene de suveranitate a datelor.
În Odoo 19, modificările trimise asupra conturilor de utilizatori sunt filtrate prin lista albă SELF_WRITEABLE_FIELDS, care permite doar atribute nepericuloase precum limba sau fusul orar. Câmpurile legate de rolurile de securitate (groups_id) pot fi modificate exclusiv de administratori autentificați (base.group_system), blocând atacurile de tip atribuire în masă CWE-915.
Recomandări strategice pentru securizarea infrastructurii ERP
Securitatea sistemelor unei companii este rezultatul arhitecturii alese, nu al bunelor intenții. Atunci când companiile utilizează sisteme neconsolidate, ele își asumă riscuri majore: scurgeri de date confidențiale, fraudă pe rețeaua telefonică și compromiterea evidenței contabile.
Standardul în 10 Puncte Zero Client-Side Trust creează o protecție impenetrabilă: izolarea completă a bazei de date în spatele serverului de aplicații, respectarea contabilității în partidă dublă, folosirea jetoanelor criptografice efemere și verificarea fiecărei operațiuni prin filtrele multi-nivel ale Odoo 19 CE și PostgreSQL.
Doriți să programați un audit independent de securitate înainte de lansarea unui nou sistem ERP sau să migrați către o arhitectură securizată Odoo 19? Contactați echipa de inginerie de la dlab.md.
Pregătiți arhitectura AI și ERP pentru un audit de securitate enterprise?
Arhitecții noștri de sistem realizează audituri Zero-Trust cu scop fix în 10 zile (OAuth 2.0 CAB, EU AI Act Art. 12/14, GDPR Art. 25, securizare PostgreSQL și Odoo 19), livrând un plan complet de remediere.