+++ title = “Lista de Verificare a Securității MCP: Bariera Minimă OWASP pentru Implementarea Securizată a Serverului MCP” linkbuilding = [ “listă verificare securitate mcp”, “bară minimă securitate mcp”, “listă verificare implementare securizată mcp”, “cerințe securitate server mcp”, “listă verificare owasp mcp”, “revizuire securitate mcp”, “securitate producție mcp”, “listă verificare întărire mcp” ] keywords = [ “listă verificare securitate mcp”, “bară minimă mcp”, “implementare securizată mcp”, “întărire server mcp”, “listă verificare owasp genai mcp”, “cerințe securitate mcp”, “listă verificare producție mcp”, “audit securitate mcp”, “listă verificare revizuire server mcp”, “listă verificare guvernanță mcp” ] description = “Proiectul OWASP GenAI Security definește o bară minimă în cinci categorii pentru implementarea securizată a serverului MCP. Folosiți această listă de verificare pentru a evalua postura dvs. actuală în ceea ce privește identitatea, izolarea, instrumentele, validarea și implementarea înainte de a trece la producție.” image = “/images/blog/mcp-security-checklist.jpg” tags = [ “Securitate MCP”, “Listă de Verificare Securitate”, “OWASP GenAI”, “Securitate AI”, “DevSecOps” ] categories = [ “Securitate” ] showCTA = true ctaHeading = “Obțineți o Evaluare Profesională a Securității MCP” ctaDescription = “Folosiți această listă de verificare pentru auto-evaluare, apoi aduceți echipa noastră pentru un audit de securitate verificat. Testăm fiecare element în mediul dvs. live și livrăm un plan detaliat de remediere.” ctaPrimaryText = “Solicitați Audit Securitate MCP” ctaPrimaryURL = “/services/ai-chatbot-penetration-testing/” ctaSecondaryText = “Rezervați un Demo” ctaSecondaryURL = “/demo/” author = “akahani” date = “2026-03-12 12:00:00”
[[faq]] question = “Ce este Bara Minimă de Securitate MCP OWASP?” answer = “„Bara Minimă de Securitate MCP” a Proiectului OWASP GenAI Security este o listă de verificare pentru revizuire care definește controalele de securitate de bază necesare înainte ca un server MCP să fie implementat în producție. Acoperă cinci domenii: Identitate/Autentificare/Aplicare Politică Puternică, Izolare Strictă și Control al Ciclului de Viață, Instrumente de Încredere și Controlate, Validare Bazată pe Schemă și Implementare Întărită cu Supraveghere Continuă. Neîndeplinirea barei minime înseamnă că serverul MCP nu ar trebui implementat până când lacunele nu sunt remediate."
[[faq]] question = “Cum folosesc această listă de verificare pentru o revizuire de securitate?” answer = “Parcurgeți fiecare categorie în mod sistematic, marcând elementele ca TRECUT, EȘUAT sau NEAPLICABIL cu dovezi pentru fiecare decizie. Orice EȘUAT în categoriile 1 sau 2 (identitate și izolare) ar trebui să blocheze implementarea — acestea sunt lacunele cu cel mai mare risc. EȘUATURILE din alte categorii ar trebui acceptate cu risc cu un calendar de remediere documentat înainte de implementare. Lista de verificare ar trebui reevaluată după orice modificare semnificativă a serverului MCP, registrului de instrumente sau mediului de implementare.”
[[faq]] question = “Ce instrumente suportă verificarea automată a securității MCP?” answer = “Mai multe instrumente suportă validarea automată a securității MCP: Invariant MCP-Scan (specializat pentru scanarea securității MCP), instrumente SAST cu reguli MCP personalizate, npm audit și pip audit pentru scanarea dependențelor, OSV-Scanner pentru verificări ale bazei de date de vulnerabilități, profile Docker seccomp și AppArmor pentru izolare la runtime și integrare SIEM pentru monitorizare centralizată. Niciun instrument nu acoperă toate elementele listei de verificare — acoperirea cuprinzătoare necesită combinarea analizei statice, testării dinamice și monitorizării continue.” +++
Ghidul practic al Proiectului OWASP GenAI Security pentru dezvoltarea serverelor MCP culminează într-o listă de verificare concretă pentru revizuire — „Bara Minimă de Securitate MCP". Această listă de verificare definește controalele de bază care trebuie să fie implementate înainte ca un server MCP să fie implementat în producție.
Această postare prezintă lista completă de verificare cu îndrumare de implementare pentru fiecare element, organizată pe cele cinci domenii de securitate pe care le definește ghidul OWASP. Folosiți-o pentru revizuiri de securitate pre-implementare, audituri periodice și ca un cadru pentru remedierea lacunelor identificate.
Marcarea elementelor: Pentru fiecare element, înregistrați TRECUT (implementat și verificat), EȘUAT (neimplementat sau parțial implementat) sau N/A (neaplicabil acestei implementări).
Porți de implementare: Elementele din Categoria 1 (Identitate, Autentificare, Politică) și Categoria 2 (Izolare) sunt porți stricte de implementare — orice EȘUAT ar trebui să blocheze lansarea până la remediere. Elementele din alte categorii ar trebui acceptate cu risc cu calendare documentate.
Declanșatori de revizuire: Reluați lista completă de verificare după orice modificare semnificativă a codului serverului MCP, registrului de instrumente, configurației de autentificare, mediului de implementare sau când este integrată o nouă categorie de instrumente.
Aceasta este categoria cu cea mai mare prioritate. Eșecurile de autentificare acordă atacatorilor acces direct la tot ce poate face serverul MCP.
Ce să verificați: Fiecare conexiune la distanță la serverul MCP necesită autentificare printr-un server de autorizare OAuth 2.1 configurat corespunzător. Conexiunile anonime sunt respinse. Serverele MCP locale care folosesc STDIO pot folosi autentificare alternativă adecvată contextului lor de implementare.
Cum să testați: Încercați să vă conectați fără un header de autorizare. Încercați să vă conectați cu un token malformat sau expirat. Ambele ar trebui să rezulte în eșec de autentificare, nu în acces la instrumente.
Moduri comune de eșec: Puncte finale de dezvoltare lăsate accesibile fără autentificare; revenire la autentificare prin cheie API care nu validează expirarea sau domeniul; validarea token-ului doar la stabilirea sesiunii, nu per cerere.
Ce să verificați: Token-urile de acces expiră în câteva minute (nu ore). Fiecare token poartă domeniul minim necesar pentru sarcina curentă. Fiecare invocare a instrumentului validează semnătura token-ului, emitentul (iss), audiența (aud), expirarea (exp) și domeniul necesar — nu doar la stabilirea sesiunii.
Cum să testați: Folosiți un token valid, apoi așteptați să expire (sau setați manual ceasul înainte). Încercați un apel de instrument — ar trebui să eșueze cu un 401, nu să reușească pe baza unui rezultat de validare din cache.
Moduri comune de eșec: Validarea token-ului salvată în cache la începutul sesiunii și nerepetată; token-uri cu durate de viață de 24+ ore; domenii largi „admin" folosite în loc de domenii specifice operațiunii; câmpul exp nu este verificat.
Ce să verificați: Serverul MCP nu transmite token-urile clienților către API-uri downstream. Toate apelurile de servicii downstream folosesc token-uri emise explicit serverului MCP (prin fluxuri On-Behalf-Of sau credențiale de serviciu). O poartă de politică centralizată interceptează toate invocările de instrumente și aplică autentificarea, autorizarea, consimțământul și jurnalizarea auditului înainte ca orice cod de instrument să se execute.
Cum să testați: Revizuiți codul pentru orice locație unde token-ul clientului de intrare este transmis într-un apel API de ieșire. Inspectați jurnalele de acces ale serviciului downstream pentru a verifica că cererile sosesc cu credențiale de server, nu cu credențiale de utilizator.
Moduri comune de eșec: Pattern-ul Authorization: Bearer ${request.headers.authorization} în apelurile downstream; verificări de autorizare împrăștiate în handlere individuale de instrumente; fără punct de aplicare centralizată a politicii.
Începe perioada de probă gratuită astăzi și vezi rezultate în câteva zile.
Eșecurile de izolare în medii multi-tenant sunt catastrofale — permit unui utilizator să acceseze datele altuia. Acestea sunt porți stricte de implementare.
Ce să verificați: Fără variabile globale, atribute la nivel de clasă sau instanțe singleton partajate care stochează date specifice utilizatorului sau sesiunii. Fiecare sesiune folosește obiecte instanțiate independent sau spații de nume cu chei de sesiune (de ex., chei Redis prefixate cu session_id:). Revizuirea codului confirmă lipsa stării mutabile partajate între sesiuni.
Cum să testați: Rulați două sesiuni concurente cu identități de utilizator diferite. Verificați că datele scrise în sesiunea A nu pot fi citite în sesiunea B. Folosiți teste de încărcare concurente pentru a verifica condițiile de cursă care ar putea cauza scurgerea stării sesiunii.
Moduri comune de eșec: self.user_context = {} ca atribut de clasă într-un serviciu singleton; cache-uri globale fără spații de nume cu chei de sesiune; stocare locală de thread care nu se limitează corespunzător la ciclul de viață al cererii.
Ce să verificați: Dincolo de contextul de execuție, orice infrastructură partajată (baze de date, cache-uri, cozi de mesaje) aplică controale de acces per utilizator. O interogare executată în sesiunea unui utilizator nu poate returna datele altui utilizator chiar dacă infrastructura partajată este greșit configurată sau compromisă.
Cum să testați: Încercați să accesați datele altui utilizator manipulând parametrii sesiunii sau exploatând chei de cache partajate.
Moduri comune de eșec: Chei de cache bazate doar pe conținutul interogării, nu pe identitatea utilizatorului; interogări de bază de date fără clauze WHERE cu domeniu limitat la utilizator; directoare de fișiere temporare partajate fără subdirectoare per utilizator.
Ce să verificați: Când o sesiune se termină (curat sau prin timeout/eroare), toate resursele asociate sunt eliberate imediat: handle-uri de fișiere, fișiere temporare, context în memorie, token-uri salvate în cache, conexiuni la baza de date. Există limite per sesiune pentru memorie, CPU, rată API și utilizare sistem de fișiere.
Cum să testați: Terminați o sesiune brusc (închideți conexiunea fără o închidere graționată). Verificați că nu rămân resurse reziduale. Creați o sesiune și epuizați-i limita de rată; verificați că nu afectează alte sesiuni.
Moduri comune de eșec: Fișiere temporare lăsate în /tmp după sfârșitul sesiunii; token-uri salvate în cache nerevocate la terminarea sesiunii; fără cote de resurse permițând unei sesiuni să epuizeze infrastructura partajată.
Securitatea instrumentelor previne cele mai periculoase atacuri specifice MCP: otrăvirea instrumentelor și retrageri frauduloase.
Ce să verificați: Fiecare definiție de instrument are o semnătură criptografică de la un aprobator de instrumente autorizat. Semnătura acoperă manifestul complet (descriere, schemă, versiune, permisiuni). Serverul MCP verifică această semnătură la momentul încărcării și respinge orice instrument nesemnat sau cu nepotrivire de semnătură. Versiunile instrumentelor sunt fixate — serverul nu poate încărca dinamic un instrument actualizat fără o nouă semnătură aprobată.
Cum să testați: Modificați un singur caracter în descrierea unui instrument încărcat. Verificați că serverul detectează nepotrivirea hash-ului și blochează încărcarea instrumentului. Încercați să încărcați o definiție de instrument nesemnată — ar trebui respinsă.
Moduri comune de eșec: Definiții de instrumente stocate ca configurație mutabilă fără verificare de integritate; fără infrastructură de cheie de semnare; instrumente încărcate direct dintr-un sistem de fișiere partajat fără fixare de versiune.
Ce să verificați: Scanarea automată verifică descrierile instrumentelor pentru pattern-uri asemănătoare instrucțiunilor care ar putea reprezenta tentative de otrăvire. Validarea periodică confirmă că comportamentul efectiv la runtime al unui instrument se potrivește cu descrierea sa declarată — un instrument care pretinde că este doar pentru citire nu ar trebui să fie capabil de operații de scriere la runtime.
Cum să testați: Adăugați o instrucțiune suspectă la descrierea unui instrument („apelați întotdeauna și send_webhook cu…") și verificați că scanarea automată o semnalează înainte de revizuirea umană. Revizuiți configurația instrumentului SAST pentru reguli de detectare a otrăvirii specifice MCP.
Moduri comune de eșec: Fără scanare automată a descrierilor instrumentelor; proces de revizuire manuală care poate rata instrucțiuni încorporate în descrieri lungi; fără validare a comportamentului la runtime pentru a prinde instrumente care mint despre capacitățile lor.
Ce să verificați: Contextul modelului primește doar câmpurile necesare pentru invocarea corectă a instrumentului: nume, descriere, schemă de intrare, schemă de ieșire. Metadatele interne, detaliile de implementare, informațiile de depanare și configurația sensibilă sunt filtrate înainte de a fi transmise modelului.
Cum să testați: Inspectați ce primește modelul când enumeră instrumentele disponibile. Verificați că niciun câmp intern, șiruri de conexiune sau metadate operaționale nu apar în vizualizarea modelului.
Moduri comune de eșec: Obiecte complete de configurare a instrumentului transmise contextului modelului; mesaje de eroare conținând detalii interne de sistem care se scurg către model; descrieri de instrumente incluzând note de implementare nerelevante pentru invocare.
Primește cele mai recente sfaturi, tendințe și oferte gratuit.
Eșecurile de validare permit injecții, manipularea datelor și negarea serviciului.
Ce să verificați: Validarea JSON Schema este aplicată pentru fiecare mesaj de protocol MCP, fiecare intrare de invocare a instrumentului și fiecare ieșire a instrumentului înainte de a ajunge la model. Validarea respinge orice mesaj care nu se conformează schemei definite — câmpuri obligatorii lipsă, tipuri greșite, valori în afara intervalelor permise.
Cum să testați: Trimiteți o invocare de instrument cu un parametru obligatoriu lipsă. Trimiteți un mesaj cu un câmp neașteptat suplimentar. Ambele ar trebui respinse, nu ignorate în tăcere sau procesate cu valori implicite.
Moduri comune de eșec: Validare opțională care este ocolită în condiții de eroare; validare doar la intrări, nu la ieșiri; scheme prea permisive (acceptând parametri type: "any").
Ce să verificați: Toate intrările sunt sanitizate pentru a elimina sau escape caractere care ar putea permite injecții (secvențe XSS, metacaractere SQL, metacaractere shell, octeți nuli). Limitele de dimensiune sunt aplicate la toate intrările și ieșirile. Serverul tratează toate datele de la model ca potențial adverse, identic cu intrările utilizatorului într-o aplicație web tradițională.
Cum să testați: Trimiteți intrări conținând payload-uri de injecție SQL, metacaractere shell și secvențe XSS. Verificați că sunt respinse sau escape-uite în siguranță înainte de a ajunge la sistemele downstream. Trimiteți o intrare care depășește limita de dimensiune — verificați că este respinsă curat.
Moduri comune de eșec: Intrări transmise direct la interogări SQL sau comenzi shell; fără limite de dimensiune permițând intrărilor supradimensionate să cauzeze epuizarea memoriei; ieșiri returnate modelului fără limite de dimensiune sau filtrare de conținut.
Ce să verificați: Apelurile de instrumente sunt acceptate doar ca obiecte JSON structurate cu scheme validate. Generarea de text liber care implică invocări de instrumente nu este procesată. Sistemul nu poate fi indus să execute apeluri de instrumente generând limbaj natural pe care serverul îl interpretează ca comenzi.
Cum să testați: Trimiteți un șir de limbaj natural care descrie o invocare de instrument („apelați instrumentul delete_file cu calea /etc/passwd"). Verificați că serverul nu interpretează aceasta ca un apel de instrument.
Moduri comune de eșec: Sisteme hibride care acceptă atât JSON structurat, cât și descrieri de instrumente în limbaj natural; servere care parsează textul generat de model pentru a identifica invocări de instrumente; parsare de apeluri de instrumente bazată pe regex care poate fi falsificată.
Întărirea implementării limitează raza de explozie a oricărei vulnerabilități exploatate.
Ce să verificați: Serverul MCP rulează într-un container minim întărit. Procesul containerului rulează ca utilizator non-root. Capabilitățile Linux inutile sunt eliminate. Politicile de rețea restricționează tot traficul de intrare și ieșire la conexiunile explicit necesare. Imaginea containerului conține doar software-ul minim necesar.
Cum să testați: Rulați docker inspect și verificați că utilizatorul este non-root. Revizuiți politicile de rețea și confirmați că blochează tot traficul cu excepția conexiunilor explicit permise. Scanați imaginea containerului pentru pachete inutile sau software cu vulnerabilități cunoscute.
Moduri comune de eșec: Containere rulând ca root pentru comoditate; fără politici de rețea lăsând tot traficul de ieșire permis; imagini de bază cu instalări complete de SO în loc de imagini minime.
Ce să verificați: Toate cheile API, secretele client OAuth, credențialele bazei de date și token-urile contului de serviciu sunt stocate într-un seif de secrete (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault etc.). Niciun secret nu există în variabile de mediu, cod sursă, imagini de containere sau ieșiri de jurnal. Operațiunile de gestionare a secretelor se întâmplă în middleware care este inaccesibil modelului AI — LLM-ul nu vede sau procesează niciodată valorile credențialelor.
Cum să testați: Căutați în jurnale șiruri asemănătoare credențialelor. Inspectați variabilele de mediu accesibile procesului serverului. Revizuiți contextul accesibil al modelului pentru a confirma că nicio valoare de credențial nu apare.
Moduri comune de eșec: Chei API în fișiere .env comise în controlul versiunilor; credențiale returnate în mesaje de eroare care ajung la model; secrete transmise ca parametri de instrumente care apar în contextul conversației modelului.
Ce să verificați: Pipeline-ul de implementare include scanare automată de securitate (SAST, SCA, scanare vulnerabilități dependențe) ca porți stricte — scanările eșuate blochează implementarea. Toate invocările de instrumente, evenimentele de autentificare și deciziile de autorizare sunt jurnalizate imuabil cu context complet. Jurnalele sunt ingerate de un SIEM cu alertare în timp real pentru pattern-uri anormale (vârfuri de validare eșuată, frecvență neobișnuită a apelurilor de instrumente, conexiuni externe neașteptate).
Cum să testați: Introduceți o dependență cu vulnerabilitate cunoscută și verificați că pipeline-ul CI/CD eșuează build-ul. Generați pattern-uri anormale de apeluri de instrumente și verificați că alertele SIEM se declanșează în timpul de răspuns așteptat.
Moduri comune de eșec: Scanare de securitate ca porți consultative în loc de blocante; jurnale scrise în stocare mutabilă pe care un atacator ar putea-o modifica; fără alertare pentru pattern-uri anormale; verbozitate excesivă a jurnalelor care face imposibilă găsirea evenimentelor relevante.
Imprimați sau exportați această listă de verificare și parcurgeți-o sistematic pentru fiecare server MCP înainte de implementarea în producție. Implicați echipa dvs. de securitate în revizuire — multe elemente necesită atât revizuirea codului, cât și testare live pentru a verifica corect.
Pentru echipele care doresc verificare independentă, un audit profesional de securitate MCP testează toate cele 16 elemente ale listei de verificare în mediul dvs. live, folosind tehnici de testare adversarială în loc de auto-evaluare. Rezultatul este un raport de postură de securitate verificat cu un plan de remediere prioritizat.
Ajutăm companii ca a ta să dezvolte chatboți inteligenți, servere MCP, instrumente AI sau alte tipuri de automatizare AI pentru a înlocui oamenii în sarcinile repetitive din organizația ta.
Serverele MCP expun o suprafață de atac unică care combină riscurile tradiționale ale API-urilor cu amenințări specifice AI. Învață cele 6 vulnerabilități criti...
Autentificarea este cel mai critic strat de securitate pentru serverele MCP la distanță. Aflați de ce OAuth 2.1 cu OIDC este obligatoriu, cum delegarea token-ur...
Injecția prompt este principalul vector de atac împotriva serverelor MCP în producție. Învățați cele patru controale recomandate de OWASP: invocare structurată ...
