Securitate

Pericol

Acest modul poate fi periculos dacă nu este configurat cu atenție.

Un LLM conectat la Odoo poate, în funcție de ce activați:

  • Exfiltra date către un furnizor extern de modele (prompturile, rezultatele instrumentelor, atașamentele și istoricul conversațiilor părăsesc serverul dumneavoastră).

  • Citi orice date comerciale pe care utilizatorul care acționează (sau utilizatorul agent) le poate deja citi conform ACL-urilor Odoo — și, implicit, politica de acces AI permite citirea dacă nu o înăspriți.

  • Crea, modifica sau șterge înregistrări odată ce capabilitățile Write / Delete și regulile politicii de acces o permit — inclusiv prin rulări nesupravegheate ale agentului (după aprobarea unei propuneri de către supervizor sau imediat, dacă Mod de scriere al sarcinii respective este hybrid / auto) sau instantaneu, în modul de scriere din chat Aplică automat.

  • Apela acțiuni de business (metode de ciclu de viață) dacă capabilitatea Action și lista de permise le autorizează.

  • Accesa web-ul public sau instrumente MCP, care pot importa conținut nesigur în contextul modelului (prompt injection) sau pot trimite date în exterior.

  • Modifica interfața și schema dacă Customize este activat pentru un administrator.

Tratați fiecare privilegiu AI ca pe un acces root în producție pentru acel domeniu: începeți restrâns, măsurați, apoi deschideți doar ceea ce necesită un caz de utilizare concret.

Model de amenințări (ce poate merge prost)

Date care părăsesc compania

Fiecare rundă de chat și fiecare rezultat de instrument trimis furnizorului este procesat conform termenilor și jurisdicției acelui furnizor. Date personale sensibile, salarii, parole (dacă apar vreodată în text liber), termeni contractuali și secrete ale clienților pot apărea în:

  • mesajul utilizatorului și istoricul conversației;

  • instantaneele de înregistrare L4 când conversați dintr-un formular;

  • rezultatele instrumentelor (rezultate search / read / read_group);

  • fișierele încărcate și paginile web preluate;

  • pașii rulărilor agentului și jurnalele cu încărcătură completă (dacă jurnalizarea este setată pe încărcătură completă).

Măsuri de atenuare: alegeți un furnizor și o regiune pe care le acceptați contractual; păstrați Nivel de jurnalizare AI pe Doar metadate în producție, cu excepția investigării unui incident; refuzați modelele/câmpurile sensibile în regulile de acces AI; nu activați Web sau MCP pentru agenții care gestionează tichete confidențiale; instruiți utilizatorii să nu lipească secrete în chat.

Chat interactiv cu privilegii excesive

Dacă un angajat cu privilegii înalte folosește asistentul cu Write / Delete / Action activate și modul de scriere Aplică automat, o singură rundă greșită a modelului (sau un prompt injection într-un e-mail lipit) poate modifica imediat datele de producție.

Măsuri de atenuare: păstrați modul de scriere pe hybrid sau confirm; lăsați Delete dezactivat; restrângeți Write la grupuri de încredere prin capabilitatea Limitat la grupuri; reguli de refuz pe câmp/model pentru salarizare, bănci, taxe și modele de sistem.

Agent autonom cu privilegii excesive

Un agent asociat unui res.users rulează cu grupurile Odoo ale acelui utilizator. Dacă copiați valorile implicite „Internal User” fără a elimina grupuri, agentul este un angajat deplin. Combinat cu domeniul de canal agent_full și o audiență largă, orice solicitant din lista de permise poate declanșa lucrări la nivelul complet al claselor de capabilități ale agentului.

Măsuri de atenuare: creați un utilizator dedicat, doar cu grupurile necesare; nu asociați niciodată Settings / AI Administrator; setați un supervizor uman; folosiți implicit domeniul intersect; audiențele de canal goale înseamnă nimeni; păstrați capabilitatea Write dezactivată pe agenții orientați spre public; reverificați întotdeauna propunerile în calitate de supervizor.

Prompt injection și inginerie socială

Textul de la clienți, din e-mailuri, din chatter și din PDF-urile încărcate este material de lucru, nu o acordare de drepturi. Atacatorii încearcă totuși să:

  • suprascrie instrucțiunile de sistem („ignore previous rules…”);

  • constrângă modelul să apeleze instrumente pe care nu ar trebui;

  • itereze după refuzuri (atacuri adaptive).

Măsuri de atenuare (încorporate): modele de intrare blocate; plafoane de capabilități impuse la poartă; politică AI + ACL-uri Odoo; avertismente → blocare temporară la încălcări, astfel încât atacatorii să nu poată itera liber; strat de triere care poate doar să scadă autoritatea. Rețineți ce acoperă trierea: adresarea de intrare. O rulare programată sau cu Rulează acum a unei instrucțiuni permanente este triată doar atunci când sarcina optează cu Triere la expediere (consultați Verificarea instrucțiunii înainte de rulare). Nimic din acestea nu face injecția „rezolvată” — doar îi reduc impactul. Proiectați agenții astfel încât cea mai gravă injecție reușită să nu poată citi sau scrie mai mult decât era destinat agentului.

Ocolirea ciclului de viață / a stării

Scrierea brută a câmpului state poate ocoli butoane precum Confirmă / Postează. Poarta respinge scrierile directe în ``state``-ul ciclului de viață. Folosiți în schimb acțiuni de business din lista de permise (call_action), când capabilitatea Action este activată.

Pragul de refuz absolut (autoprotecție)

Un set fix de modele tehnice este întotdeauna refuzat instrumentelor AI, indiferent de regulile de acces. Administratorii nu le pot „deschide” prin ai.access.rule. Pragul include:

  • modele de sistem sensibile din punct de vedere al securității (drepturi de acces, reguli, grupuri, utilizatori și chei API, parametri de configurare, secvențe, meniuri, vizualizări, acțiuni de server, cron-uri, coada de e-mail, token-uri de plată, conturi bancare ale partenerilor, …);

  • toate modelele aplicației AI însăși (ai și orice nume ai.*) — agenții nu pot reconfigura politica, aptitudinile, blocările sau propriile rulări prin instrumente;

  • mail.message și discuss.channel brute (integritatea autorului / a probelor — chatter-ul legitim trece prin message_post al înregistrării proprietare, nu prin instrumente generice de creare).

Acesta este un prag, nu o politică completă de clasificare a datelor — modelele de business precum hr.employee sau account.move nu sunt refuzate absolut implicit; trebuie să le configurați dumneavoastră, dacă este nevoie.

ir.attachment și mail.activity se află chiar în afara pragului, într-un mic set cu permisiune exclusiv explicită: nicio valoare implicită globală nu le deschide vreodată, dar o regulă de acces o poate face, iar modulul livrează câte una pentru fiecare — atașamente citibile și scriptibile, activități citibile, scriptibile și creabile — astfel încât aptitudinile pentru documente și facturi furnizor să poată citi un PDF, iar agenții să poată lăsa un To-Do de verificare pe numele lor. Crearea sau ștergerea unui atașament și ștergerea unei activități rămân închise, deoarece niciunul dintre modele nu trece la valorile implicite globale. Citiți acele două reguli ca permisiuni reale, nu ca parte a pragului: un agent poate genera o activitate pe orice înregistrare pe care o poate citi și poate reatașa un fișier la o altă înregistrare. Restrângeți-le sau dezactivați-le dacă este mai mult decât necesită implementarea dumneavoastră.

Efecte secundare între modele

Un câmp poate scrie într-un model pe care nu l-ați deschis niciodată: crm.lead.email_from actualizează e-mailul partenerului. Poarta refuză astfel de câmpuri, iar cele două traversări nu sunt la fel de configurabile. Acolo unde traversarea este statică — un câmp related — refuzul este absolut și nicio regulă de acces nu îl ridică. Acolo unde este dinamică — un câmp cu inverse — este ridicat doar de o regulă care numește exact acel câmp, astfel încât o acordare la nivel de model să nu poată curge lateral, iar pista de audit să nu poată subraporta tacit ce a atins o scriere. Pe calea de preluare a fișierelor (fetch_file_to_field), activarea pe câmp nu se aplică deloc: un câmp țintă cu invers este refuzat indiferent de regula pe care o scrieți, deoarece conținutul provine dintr-un URL ales de model.

Zece permisiuni de scriere pe câmp sunt livrate activate pe bazele de date cu Contabilitate, pentru fluxul de facturare. Patru sunt pe account.move.line și, pe calea one2many imbricată, o permisiune la nivel de câmp este rezolvată înaintea nivelului de model, deci acele patru câmpuri de linie sunt scriptibile prin Linii factură chiar dacă nicio regulă nu permite scrierea pe account.move.line în sine. Analizați-le înainte de a certifica faptul că liniile de factură sunt închise. Unul dintre cele patru, analytic_distribution, necesită atenție suplimentară: este un câmp JSON, deci regula sa ridică atât refuzul valorilor de tip JSON, cât și protecția între modele, iar inversul său rescrie înregistrările analitice ale unei linii postate — ștergând și recreând înregistrări account.analytic.line pe un model pe care nicio regulă nu l-a numit. Consultați Protecția scrierii între modele.

Eliminarea câmpurilor sensibile

Câmpurile ale căror nume seamănă cu secrete (password, token, api_key, …), câmpurile magice și anumite tipuri complexe sunt eliminate sau refuzate la scriere. Aceasta este apărare în profunzime, nu un substitut pentru refuzarea unor modele întregi (de ex. HR).

Confirmare și reverificare

Scrierile în așteptare sunt revalidate la momentul aplicării, sub identitatea corectă care acționează și politica curentă. Aprobarea unei propuneri vechi după revocarea drepturilor ar trebui să eșueze închis. Propunerile agentului reconstruiesc autoritatea din rulare, nu din privilegiul celui care confirmă (cel care confirmă autorizează; agentul execută).

Starea de funcționare a rulării face parte din acea autoritate. O propunere de la o rulare oprită la cerere sau închisă de reaperul de rulări blocate deoarece worker-ul ei s-a oprit este refuzată la momentul aplicării și nu poate fi aprobată de nimeni: reaperul nu poate deosebi un worker mort de unul lent, astfel încât unei rulări declarate încheiate de altcineva nu i se permite niciodată să-și reia scrierile. Propunerile lăsate de o rulare care s-a încheiat singură — Efectuat, Eșuat sau Expirat — rămân aprobabile până când întreținerea le expiră.

Roluri și grupuri de securitate

Grup

Scop

AI: Utilizator

Folosește chatul, propriile conversații, propriile propuneri de scriere, memoria; supervizorii au nevoie de acesta pentru a aproba propunerile agentului.

Grupul AI: Administrator

Configurează agenți, capabilități, politici, aptitudini, MCP, monitorizare. Implică AI: Utilizator.

Settings (administrare de sistem)

Pagina aplicației Setări AI, configurare ghidată, planuri de configurare.

Important

Un utilizator agent nu trebuie să dețină niciodată Settings sau AI Administrator. Modulul blochează asocierea unor astfel de utilizatori pe formularul agentului (la momentul scrierii). Nu acordați ulterior nici acele grupuri pe formularul utilizatorului — aceasta ocolește constrângerea agentului și elimină comutatorul de oprire prin blocare pentru administratorii AI.

Controale stratificate (listă de verificare)

Folosiți toate straturile; niciunul nu le înlocuiește pe celelalte:

  1. Grupurile Odoo ale utilizatorului / utilizatorului agent — ce pot face fără AI.

  2. Capabilități AI — ce clase de instrumente există (ask, read, write, delete, web, mcp, action, customize, setup, navigate).

  3. Grupuri de acces AI + reguli — permisiune/refuz pe model/câmp pentru instrumentele AI.

  4. ``capability_ids`` ale agentului — plafon suplimentar doar pentru acel agent.

  5. Reguli de canal + audiență + scope_mode — cine poate declanșa agentul și dacă clasele de capabilități sunt intersectate cu cele ale solicitantului.

  6. Mod de scriere / scrieri în așteptare / supervizor — om în buclă. Chatul folosește modul global din Setări; fiecare sarcină a agentului are propriul mod (implicit confirm). Consultați Modul de scriere al sarcinii (doar pentru rulările agentului).

  7. Limite de rată, avertismente, blocări, modele blocate — abuz și iterare.

  8. Jurnalizare și retenție — probe și retenție minimă pentru jurnalele de pași.

Ce nu garantează securitatea

  • Rezistență perfectă la prompt injection.

  • Clasificarea din start a fiecărui câmp comercial sensibil.

  • Că presupunerile din datele de antrenare nu pot apărea în răspunsurile în text liber (regulile de ancorare reduc, dar nu elimină halucinațiile — acțiunile critice trebuie să treacă prin instrumente și confirmare).

  • Conformitatea GDPR/legală în sine — aveți în continuare nevoie de temei legal, DPA-uri cu furnizorii și politică de retenție pentru conversațiile pe care le păstrați.

Continuați cu Primii pași numai după ce această pagină a fost înțeleasă de persoanele care vor administra modulul.