Serverul tău MCP este securizat. Registrul din spatele lui, nu.

Într-un articol publicat recent aici, pe Unite.AI, Gil Feig a prezentat șase bune practici pentru construirea unui server MCP securizat. Sunt recomandări solide, pe care ar trebui să le urmeze oricine lansează un server MCP. Sfatul său de a atribui fiecărei integrări „propriul rol cu permisiuni granulare, limitat strict la permisiunile necesare” este cât se poate de corect. Însă presupune și că sistemul de la celălalt capăt dispune de roluri cu permisiuni granulare. De aici rezultă o presupunere mai amplă, rareori enunțată: că sistemele din spatele serverului pot fi securizate la același nivel.

În software-ul pentru companii, acest lucru este adesea imposibil. Conduc echipa de inginerie care dezvoltă un strat de integrare conectat la 32 de sisteme de contabilitate și ERP, peste care se poate adăuga opțional un server MCP. Vedem în mod regulat agenți bine autentificați, cu permisiuni bine delimitate și ale căror activități sunt bine înregistrate de partea noastră, care scriu în sisteme incapabile să-și dea seama că a fost implicat vreun agent.

Acest articol se ocupă de cealaltă jumătate a problemei: ce oferă, de fapt, sistemele din amonte, ce poți controla din stratul de integrare și unde se oprește acest control.

Unde predă ștafeta specificația MCP

Specificația autorizării MCP este clară în ceea ce privește propria sa limită. Serverul MCP este un server de resurse OAuth pentru clienții săi. Atunci când apelează o API din amonte, acționează ca un client OAuth separat, cu un token separat emis de sistemul din amonte. Trecerea tokenului clientului prin sistem este interzisă în mod explicit.

Acesta este designul corect. Înseamnă totodată că tot ce ține de apelul către sistemul din amonte, inclusiv cine are voie să facă ce și cum se înregistrează acest lucru, depinde în întregime de sistemul respectiv. Specificația nu poate remedia ceea ce sistemul din amonte nu oferă.

Același lucru este valabil și pentru recomandările OWASP privind autonomia excesivă a agenților. Acestea recomandă limitarea permisiunilor pe care extensiile unui agent le au în alte sisteme la strictul necesar și executarea acțiunilor în contextul utilizatorului în numele căruia acționează. Ambele recomandări sunt bune. Ambele presupun că celălalt sistem oferă o modalitate de a defini permisiunile minime și contextul utilizatorului.

Ce oferă, de fapt, sistemele din amonte

Iată cum se prezintă, din perspectiva unui integrator, cele 32 de sisteme de contabilitate și ERP la care ne conectăm.

O treime nu oferă deloc OAuth

21 dintre cele 32 folosesc OAuth. Celelalte 11 se bazează pe acreditări statice: chei API, nume de utilizator și parolă sau o pereche de tokenuri. Unele dintre aceste chei nu expiră niciodată. Un sistem utilizat pe scară largă precizează în documentația API-ului că tokenurile sale au o durată de viață nelimitată, atât timp cât utilizatorul există.

Durată lungă de viață, posibilități limitate de revocare

OAuth ajută mai puțin decât ai spera. Un furnizor emite tokenuri de reîmprospătare cu o durată de viață de aproximativ 20 de ani. Este o acreditare concepută să supraviețuiască agentului care o folosește, cadrului pe baza căruia a fost construit agentul și, foarte posibil, chiar persoanei care a făcut clic pe „permite”. Într-un alt sistem, nici măcar tokenurile de acces nu expiră.

Iar odată ce o acreditare a fost emisă, întrebarea este cine o poate dezactiva. Standardul relevant în acest caz, revocarea tokenurilor OAuth (RFC 7009), există din 2013. Cu toate acestea, aproximativ patru din zece sisteme nu oferă integratorilor nicio modalitate tehnică de a revoca acreditările. Toate sistemele bazate pe chei API fac parte din acest grup. Singura opțiune rămasă este să îi ceri clientului să revoce manual accesul.

Domenii de autorizare generale, fără identitatea agentului

Majoritatea cheilor statice moștenesc pur și simplu toate drepturile utilizatorului care le-a creat; doar câteva sisteme permit restricționarea unei chei la anumite puncte finale. Multe sisteme OAuth au domenii de autorizare, dar acestea tind să fie generale, de tipul „contabilitate, citire și scriere”. Și nu am găsit niciunul dintre cele 32 de sisteme care să permită înregistrarea, prin API, atât a agentului, cât și a persoanei în numele căreia acționează, pentru aceeași tranzacție. Agenții externi apar fie ca utilizatorul care i-a conectat, fie ca utilizator generic de sistem. Este semnificativ faptul că, atunci când un furnizor își integrează agenții în propriul produs, așa cum a făcut Microsoft în Business Central, le atribuie conturi de utilizator dedicate. Este același model pe care îl recomand mai jos, doar că este rezervat agenților proprii ai furnizorului.

Ce poate impune stratul de integrare

Nimic din toate acestea nu înseamnă că trebuie să renunți. Între agent și sistemul de contabilitate, poți controla aproape totul:

• acreditări distincte pentru fiecare agent în relația cu propriul tău strat
• propriile domenii de autorizare, de exemplu acces doar pentru citirea facturilor
• un jurnal de audit pentru fiecare apel al agentului, care să indice persoana în numele căreia a acționat
• chei de idempotență, astfel încât un agent care reîncearcă o operațiune să nu înregistreze de două ori aceeași factură
• limite de rată pentru fiecare agent
• etape de aprobare înainte de orice operațiune de scriere

Nimic din toate acestea nu depinde de funcționalitățile oferite de sistemul țintă. Un strat de control al accesului capabil, la nivelul integrării, poate fi implementat chiar astăzi și, dacă folosești agenți în apropierea datelor financiare, ar trebui să construiești unul.

Unde se oprește

Ce nu poți face este să extinzi acest nivel dincolo de limitele sistemului. Acolo apar trei probleme.

Atribuire

În sistemul de contabilitate, operațiunea de scriere efectuată de agent apare ca fiind realizată de persoana care a autorizat conexiunea sau de un utilizator tehnic. Oricine auditează sistemul vede o înregistrare făcută de acel utilizator. Nu poate afla dacă a fost introdusă de o persoană sau de un agent. Pentru registrul contabil, un agent care înregistrează 400 de facturi la 3 dimineața arată exact ca un manager financiar foarte conștiincios. Pentru a reconstitui ce s-a întâmplat, sunt necesare jurnalele integratorului, ceea ce presupune un lanț de încredere diferit de cel al sistemului de evidență. Din perspectiva investigațiilor criminalistice sau a unui audit, aceasta este o poziție vulnerabilă.

Nici majoritatea organizațiilor nu sunt cu un pas înainte în această privință. Într-un sondaj al Cloud Security Alliance, doar 28% dintre respondenți au declarat că pot urmări în mod fiabil acțiunile agenților până la o persoană sau un sistem în toate mediile, iar 44% folosesc sau intenționează să folosească chei API statice pentru agenții lor.

Principiul privilegiului minim

Poți impune ca un agent să citească doar facturi. Dar, dacă sistemul țintă nu are domenii de acces, acreditările din spatele nivelului tău păstrează accesul complet. Oricine le obține poate ocoli cu totul nivelul tău și toate regulile pe care le-ai configurat acolo.

Revocare

Îți poți dezactiva instantaneu propriul agent. Asta nu te ajută dacă sunt compromise chiar acreditările pentru sistemul țintă. Iar pentru cele patru din zece sisteme care nu au un punct final de revocare, oprirea de urgență înseamnă să trimiți un e-mail clientului.

Soluția pragmatică: un utilizator dedicat agentului

Cel mai util lucru pe care îl poți face astăzi nu e deloc spectaculos. Creează un utilizator dedicat agentului în sistemul țintă și conectează agentul numai prin acel utilizator.

Funcționează în orice sistem care permite crearea de utilizatori și oferă trei avantaje pe care nivelul de integrare nu le poate asigura:

• Atribuirea acțiunilor în sistemul de evidență.Înregistrările apar cu numele „agent AP”, nu cu numele managerului financiar care a apăsat pe „conectare” în urmă cu șase luni.
• O modalitate de revocare, chiar și fără un API dedicat.Clientul poate dezactiva utilizatorul din interfață, inclusiv în sistemele care nu oferă un punct final de revocare.
• Privilegiu minim parțial.Dacă sistemul are măcar un model de roluri, utilizatorul agentului poate fi adesea limitat la modulele de care are efectiv nevoie.

Costurile sunt reale. Cineva trebuie să creeze manual utilizatorul în timpul procesului de integrare, ceea ce adaugă dificultăți exact în momentul cel mai nepotrivit. Aproximativ jumătate dintre sisteme taxează fiecare utilizator suplimentar, de la câțiva euro pe lună în instrumentele pentru întreprinderi mici până la peste o sută de euro într-un sistem ERP complet. Mai multe alte sisteme limitează numărul de utilizatori în funcție de abonament, astfel că un singur utilizator în plus poate însemna un abonament mai scump pentru întreaga companie. În plus, un utilizator de serviciu de care nu răspunde nimeni devine un risc în sine, parte a fenomenului de proliferare a identităților non-umane despre care Unite.AI a mai scris. Ca orice alt cont, are nevoie de un responsabil și de o dată de revizuire.

De asemenea, nu rezolvă problema domeniilor de acces în sistemele care nu le au. Însă readuce atribuirea acțiunilor și revocarea în sistemul pe care îl verifică efectiv auditorii.

Soluția structurală: identitatea delegată

Soluția corectă există deja, cel puțin pe hârtie. Schimbul de tokenuri OAuth 2.0 (RFC 8693)face distincția între impersonare și delegare. În cazul delegării, agentul își păstrează propria identitate, iar tokenul consemnează că acționează în numele unei persoane, prin revendicarea „act”.

Aplicată contabilității, aceasta ar însemna:

• registrul contabil consemnează că acest agent a făcut înregistrarea în numele acestei persoane
• domeniile de acces sunt acordate pentru fiecare delegare, nu pentru fiecare utilizator
• o singură delegare poate fi revocată fără a afecta contul persoanei

Din câte am putut afla, niciunul dintre cele 32 de sisteme nu oferă ceva de acest fel. Așadar, deocamdată rămâne o direcție de urmat, nu o opțiune. Prin urmare, solicitarea trebuie adresată furnizorilor de software de contabilitate și ERP, nu integratorilor: agenții fac deja înregistrări în registrele voastre contabile, iar API-urile voastre ar trebui să poată indica acest lucru.

Ce trebuie făcut înainte ca un agent să acceseze un registru contabil

Dacă integrați agenți cu sisteme de contabilitate sau ERP, iată o listă scurtă de verificări:

1. Analizați modelul de acreditări al fiecărui sistem țintă.Folosește OAuth sau o cheie statică? Cât timp este valabilă acreditarea? Are domenii de acces și poate fi revocată?
2. Construiți-vă oricum propriul nivel de control al accesului.Identitatea fiecărui agent, domeniile de acces, idempotența și aprobările țin de partea voastră, indiferent de ce oferă sistemul țintă.
3. Folosiți un utilizator dedicat agentului oriunde permite sistemul.Acceptați efortul necesar la integrare și costul licenței ca preț al atribuirii acțiunilor.
4. Păstrați un jurnal de audit propriu, rezistent la manipulare.Pentru multe sisteme, acesta va fi singura dovadă a implicării unui agent.
5. Consemnați riscul rezidual. Dacă un sistem nu are domenii de autorizare și nici posibilitatea revocării, precizați acest lucru clientului și în propriul registru de riscuri.

Granița este esențială

Securizarea serverului MCP este necesară, dar nu suficientă. Securitatea unui agent care scrie într-un registru este determinată de granița dintre nivelul dumneavoastră și sistemul de evidență, iar astăzi această graniță este stabilită de sisteme, nu de dumneavoastră.

Vestea bună este că lacuna este bine definită. Standardele există. Ceea ce lipsește este suportul pentru ele în sistemele în care sunt păstrate registrele.