Projekt OWASP GenAI Security definuje pět kategorií minimálního standardu pro bezpečné nasazení MCP serveru. Použijte tento kontrolní seznam k posouzení vašeho současného stavu v oblastech identity, izolace, nástrojů, validace a nasazení před přechodem do produkce.
Praktický průvodce projektu OWASP GenAI Security pro vývoj MCP serverů vrcholí konkrétním kontrolním seznamem — “Minimální bezpečnostní standard MCP”. Tento kontrolní seznam definuje základní kontroly, které musí být zavedeny před nasazením MCP serveru do produkce.
Tento příspěvek představuje kompletní kontrolní seznam s implementačními pokyny pro každou položku, organizovaný napříč pěti bezpečnostními oblastmi, které průvodce OWASP definuje. Použijte jej pro bezpečnostní revize před nasazením, pravidelné audity a jako rámec pro nápravu identifikovaných nedostatků.
Označování položek: Pro každou položku zaznamenejte VYHOVUJE (implementováno a ověřeno), NEVYHOVUJE (neimplementováno nebo částečně implementováno), nebo N/A (nepoužitelné pro toto nasazení).
Brány nasazení: Položky v Kategorii 1 (Identita, Autentizace, Politiky) a Kategorii 2 (Izolace) jsou pevné brány nasazení — jakékoli NEVYHOVUJE by mělo zablokovat spuštění do produkce, dokud nebude napraveno. Položky v ostatních kategoriích by měly být akceptovány s rizikem a zdokumentovanými harmonogramy.
Spouštěče revize: Spusťte kompletní kontrolní seznam po jakékoli významné změně kódu MCP serveru, registru nástrojů, konfigurace autentizace, prostředí nasazení nebo při zavádění nové kategorie nástrojů.
Toto je kategorie s nejvyšší prioritou. Selhání autentizace poskytuje útočníkům přímý přístup ke všemu, co může MCP server dělat.
Co ověřit: Každé vzdálené připojení k MCP serveru vyžaduje autentizaci prostřednictvím správně nakonfigurovaného autorizačního serveru OAuth 2.1. Anonymní připojení jsou odmítnuta. Lokální MCP servery používající STDIO mohou použít alternativní autentizaci vhodnou pro jejich kontext nasazení.
Jak testovat: Pokuste se připojit bez autorizační hlavičky. Pokuste se připojit s chybně formátovaným nebo expirovaným tokenem. Obě pokusy by měly vést k selhání autentizace, nikoli k přístupu k nástrojům.
Běžné způsoby selhání: Vývojové endpointy ponechané přístupné bez autentizace; záložní autentizace pomocí API klíče, která nevaliduje expiraci nebo rozsah; validace tokenu pouze při navázání relace, nikoli při každém požadavku.
Co ověřit: Přístupové tokeny vyprší během minut (nikoli hodin). Každý token nese minimální rozsah požadovaný pro aktuální úkol. Každé vyvolání nástroje validuje podpis tokenu, vystavitele (iss), cílovou skupinu (aud), expiraci (exp) a požadovaný rozsah — nejen při navázání relace.
Jak testovat: Použijte platný token, poté počkejte, až vyprší (nebo ručně posuňte hodiny dopředu). Pokuste se o volání nástroje — mělo by selhat s chybou 401, nikoli uspět na základě výsledku validace uloženého v mezipaměti.
Běžné způsoby selhání: Validace tokenu uložená v mezipaměti při zahájení relace a neopakovaná; tokeny s životností 24+ hodin; použití širokých “admin” rozsahů místo rozsahů specifických pro operaci; nekontrolované pole exp.
Co ověřit: MCP server nepředává klientské tokeny downstream API. Všechna volání downstream služeb používají tokeny explicitně vydané MCP serveru (prostřednictvím toků On-Behalf-Of nebo servisních přihlašovacích údajů). Centralizovaná brána politik zachycuje všechna vyvolání nástrojů a vynucuje autentizaci, autorizaci, souhlas a audit logging před spuštěním jakéhokoli kódu nástroje.
Jak testovat: Zkontrolujte kód pro jakékoli místo, kde je příchozí klientský token předáván v odchozím volání API. Zkontrolujte logy přístupu downstream služeb a ověřte, že požadavky přicházejí se servisními přihlašovacími údaji, nikoli s uživatelskými přihlašovacími údaji.
Běžné způsoby selhání: Vzor Authorization: Bearer ${request.headers.authorization} v downstream voláních; autorizační kontroly rozptýlené napříč jednotlivými handlery nástrojů; žádný centralizovaný bod vynucování politik.
Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.
Selhání izolace v multi-tenant prostředích jsou katastrofální — umožňují jednomu uživateli přístup k datům jiného uživatele. Jedná se o pevné brány nasazení.
Co ověřit: Žádné globální proměnné, atributy na úrovni třídy nebo sdílené singleton instance neukládají data specifická pro uživatele nebo relaci. Každá relace používá nezávisle instancované objekty nebo jmenné prostory klíčované relací (např. Redis klíče s prefixem session_id:). Revize kódu potvrzuje žádný sdílený měnitelný stav mezi relacemi.
Jak testovat: Spusťte dvě souběžné relace s různými uživatelskými identitami. Ověřte, že data zapsaná v relaci A nelze přečíst v relaci B. Použijte souběžné zátěžové testy ke kontrole race conditions, které by mohly způsobit únik stavu relace.
Běžné způsoby selhání: self.user_context = {} jako atribut třídy v singleton službě; globální mezipaměti bez jmenných prostorů klíčovaných relací; thread-local storage, které správně neomezuje rozsah na životní cyklus požadavku.
Co ověřit: Kromě kontextu provádění jakákoli sdílená infrastruktura (databáze, mezipaměti, fronty zpráv) vynucuje řízení přístupu na úrovni uživatele. Dotaz provedený v relaci jednoho uživatele nemůže vrátit data jiného uživatele, ani když je sdílená infrastruktura špatně nakonfigurovaná nebo kompromitovaná.
Jak testovat: Pokuste se přistoupit k datům jiného uživatele manipulací s parametry relace nebo zneužitím sdílených klíčů mezipaměti.
Běžné způsoby selhání: Klíče mezipaměti založené pouze na obsahu dotazu, nikoli na identitě uživatele; databázové dotazy bez klauzulí WHERE omezených na uživatele; sdílené adresáře dočasných souborů bez podadresářů pro jednotlivé uživatele.
Co ověřit: Když relace ukončí (čistě nebo prostřednictvím timeoutu/chyby), všechny přidružené zdroje jsou okamžitě uvolněny: file handles, dočasné soubory, kontext v paměti, tokeny v mezipaměti, databázová připojení. Existují limity na relaci pro paměť, CPU, rychlost API a využití souborového systému.
Jak testovat: Ukončete relaci náhle (ukončete připojení bez řádného ukončení). Ověřte, že nezůstaly žádné zbylé zdroje. Vytvořte relaci a vyčerpejte její rychlostní limit; ověřte, že to neovlivňuje ostatní relace.
Běžné způsoby selhání: Dočasné soubory ponechané v /tmp po ukončení relace; tokeny v mezipaměti neodvolané při ukončení relace; žádné kvóty zdrojů umožňující jedné relaci vyčerpat sdílenou infrastrukturu.
Bezpečnost nástrojů zabraňuje nejnebezpečnějším útokům specifickým pro MCP: otrávení nástrojů a rug pulls.
Co ověřit: Každá definice nástroje má kryptografický podpis od autorizovaného schvalovatele nástrojů. Podpis pokrývá kompletní manifest (popis, schéma, verzi, oprávnění). MCP server ověřuje tento podpis při načítání a odmítá jakýkoli nepodepsaný nástroj nebo nástroj s neshodným podpisem. Verze nástrojů jsou připnuté — server nemůže dynamicky načíst aktualizovaný nástroj bez nového schváleného podpisu.
Jak testovat: Upravte jediný znak v popisu načteného nástroje. Ověřte, že server detekuje neshodu hashe a zablokuje načtení nástroje. Pokuste se načíst nepodepsanou definici nástroje — měla by být odmítnuta.
Běžné způsoby selhání: Definice nástrojů uložené jako měnitelná konfigurace bez ověření integrity; žádná infrastruktura podpisových klíčů; nástroje načítané přímo ze sdíleného souborového systému bez připnutí verze.
Co ověřit: Automatické skenování kontroluje popisy nástrojů na vzory podobné instrukcím, které by mohly představovat pokusy o otrávení. Pravidelná validace potvrzuje, že skutečné runtime chování nástroje odpovídá jeho deklarovanému popisu — nástroj, který tvrdí, že je pouze pro čtení, by neměl být schopen provádět zápis operace za běhu.
Jak testovat: Přidejte podezřelou instrukci do popisu nástroje (“vždy také volejte send_webhook s…”) a ověřte, že automatické skenování to označí před lidskou revizí. Zkontrolujte konfiguraci nástroje SAST pro detekční pravidla otrávení specifická pro MCP.
Běžné způsoby selhání: Žádné automatické skenování popisů nástrojů; proces manuální revize, který může přehlédnout vložené instrukce v dlouhých popisech; žádná validace runtime chování k zachycení nástrojů, které lžou o svých schopnostech.
Co ověřit: Kontext modelu přijímá pouze pole požadovaná pro správné vyvolání nástroje: název, popis, vstupní schéma, výstupní schéma. Interní metadata, implementační detaily, ladicí informace a citlivá konfigurace jsou odfiltrovány před předáním modelu.
Jak testovat: Zkontrolujte, co model obdrží, když vypočítává dostupné nástroje. Ověřte, že se v pohledu modelu neobjevují žádná interní pole, připojovací řetězce nebo operační metadata.
Běžné způsoby selhání: Kompletní konfigurační objekty nástrojů předané do kontextu modelu; chybové zprávy obsahující interní systémové detaily, které unikají do modelu; popisy nástrojů zahrnující implementační poznámky nerelevantní pro vyvolání.
Získejte nejnovější tipy, trendy a nabídky zdarma.
Selhání validace umožňují injection, manipulaci s daty a denial-of-service.
Co ověřit: Validace JSON Schema je vynucena pro každou zprávu protokolu MCP, každý vstup vyvolání nástroje a každý výstup nástroje před tím, než dosáhne modelu. Validace odmítá jakoukoli zprávu, která neodpovídá definovanému schématu — chybějící povinná pole, špatné typy, hodnoty mimo povolené rozsahy.
Jak testovat: Odešlete vyvolání nástroje s chybějícím povinným parametrem. Odešlete zprávu s extra neočekávaným polem. Obě by měly být odmítnuty, nikoli tiše ignorovány nebo zpracovány s výchozími hodnotami.
Běžné způsoby selhání: Volitelná validace, která je obcházena za chybových podmínek; validace pouze na vstupech, nikoli na výstupech; schémata, která jsou příliš benevolentní (přijímající parametry type: "any").
Co ověřit: Všechny vstupy jsou sanitizovány k odstranění nebo escapování znaků, které by mohly umožnit injection (XSS sekvence, SQL metaznaky, shell metaznaky, nulové bajty). Limity velikosti jsou vynuceny na všech vstupech a výstupech. Server zachází se všemi daty z modelu jako s potenciálně nepřátelskými, identicky jako s uživatelským vstupem v tradiční webové aplikaci.
Jak testovat: Odešlete vstupy obsahující SQL injection payloady, shell metaznaky a XSS sekvence. Ověřte, že jsou odmítnuty nebo bezpečně escapovány před dosažením downstream systémů. Odešlete vstup, který překračuje limit velikosti — ověřte, že je čistě odmítnut.
Běžné způsoby selhání: Vstupy předané přímo do SQL dotazů nebo shell příkazů; žádné limity velikosti umožňující nadměrným vstupům způsobit vyčerpání paměti; výstupy vrácené modelu bez limitů velikosti nebo filtrování obsahu.
Co ověřit: Volání nástrojů jsou přijímána pouze jako strukturované JSON objekty s validovanými schématy. Generování volného textu, které implikuje vyvolání nástrojů, není zpracováváno. Systém nemůže být přinucen k provedení volání nástrojů generováním přirozeného jazyka, který server interpretuje jako příkazy.
Jak testovat: Odešlete řetězec v přirozeném jazyce, který popisuje vyvolání nástroje (“zavolej nástroj delete_file s cestou /etc/passwd”). Ověřte, že server toto neinterpretuje jako volání nástroje.
Běžné způsoby selhání: Hybridní systémy, které přijímají jak strukturovaný JSON, tak popisy nástrojů v přirozeném jazyce; servery, které parsují text generovaný modelem k identifikaci vyvolání nástrojů; parsování volání nástrojů založené na regexu, které lze podvrhnout.
Zpevnění nasazení omezuje dosah jakékoli zneužité zranitelnosti.
Co ověřit: MCP server běží v minimálním zpevněném kontejneru. Proces kontejneru běží jako non-root uživatel. Nepotřebné Linux capabilities jsou odstraněny. Síťové politiky omezují veškerý příchozí a odchozí provoz na explicitně požadovaná připojení. Obraz kontejneru obsahuje pouze minimální požadovaný software.
Jak testovat: Spusťte docker inspect a ověřte, že uživatel je non-root. Zkontrolujte síťové politiky a potvrďte, že blokují veškerý provoz kromě explicitně povolených připojení. Skenujte obraz kontejneru na nepotřebné balíčky nebo software se známými zranitelnostmi.
Běžné způsoby selhání: Kontejnery běžící jako root pro pohodlí; žádné síťové politiky ponechávající veškerý odchozí provoz povolený; základní obrazy s plnými instalacemi OS místo minimálních obrazů.
Co ověřit: Všechny API klíče, OAuth client secrets, databázové přihlašovací údaje a tokeny servisních účtů jsou uloženy v trezoru tajemství (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault atd.). Žádná tajemství neexistují v proměnných prostředí, zdrojovém kódu, obrazech kontejnerů nebo výstupu logů. Operace správy tajemství probíhají v middleware, který je nepřístupný pro AI model — LLM nikdy nevidí ani nezpracovává hodnoty přihlašovacích údajů.
Jak testovat: Prohledejte logy pro řetězce podobné přihlašovacím údajům. Zkontrolujte proměnné prostředí přístupné procesu serveru. Zkontrolujte přístupný kontext modelu a potvrďte, že se v něm neobjevují žádné hodnoty přihlašovacích údajů.
Běžné způsoby selhání: API klíče v .env souborech commitnutých do version control; přihlašovací údaje vrácené v chybových zprávách, které dosáhnou modelu; tajemství předaná jako parametry nástrojů, které se objevují v konverzačním kontextu modelu.
Co ověřit: Pipeline nasazení zahrnuje automatické bezpečnostní skenování (SAST, SCA, skenování zranitelností závislostí) jako pevné brány — neúspěšné skeny blokují nasazení. Všechna vyvolání nástrojů, události autentizace a rozhodnutí o autorizaci jsou logovány neměnitelně s plným kontextem. Logy jsou ingestovány SIEM s real-time alertováním na anomální vzory (špičky neúspěšných validací, neobvyklá frekvence volání nástrojů, neočekávaná externí připojení).
Jak testovat: Zavedete závislost se známou zranitelností a ověřte, že CI/CD pipeline selže build. Generujte anomální vzory volání nástrojů a ověřte, že SIEM alerty se spustí v očekávaném čase reakce.
Běžné způsoby selhání: Bezpečnostní skenování jako poradní místo blokujících bran; logy zapsané do měnitelného úložiště, které by útočník mohl upravit; žádné alertování na anomální vzory; nadměrná podrobnost logů, která znemožňuje najít relevantní události.
Vytiskněte nebo exportujte tento kontrolní seznam a systematicky jej projděte pro každý MCP server před nasazením do produkce. Zapojte svůj bezpečnostní tým do revize — mnoho položek vyžaduje jak revizi kódu, tak živé testování k správnému ověření.
Pro týmy, které chtějí nezávislé ověření, profesionální bezpečnostní audit MCP testuje všech 16 položek kontrolního seznamu proti vašemu živému prostředí pomocí technik adversariálního testování spíše než vlastního posouzení. Výsledkem je ověřená zpráva o bezpečnostním stavu s prioritizovaným plánem nápravných opatření.
Minimální bezpečnostní standard MCP projektu OWASP GenAI Security je kontrolní seznam definující základní bezpečnostní kontroly vyžadované před nasazením MCP serveru do produkce. Pokrývá pět oblastí: Silná identita/autentizace/vynucování politik, Striktní izolace a řízení životního cyklu, Důvěryhodné a kontrolované nástroje, Validace řízená schématy a Zpevněné nasazení s průběžným dohledem. Nesplnění minimálního standardu znamená, že MCP server by neměl být nasazen, dokud nebudou nedostatky odstraněny.
Systematicky projděte každou kategorii a označte položky jako VYHOVUJE, NEVYHOVUJE nebo NEPOUŽITELNÉ s důkazy pro každé rozhodnutí. Jakékoli NEVYHOVUJE v kategoriích 1 nebo 2 (identita a izolace) by mělo zablokovat nasazení — jedná se o mezery s nejvyšším rizikem. NEVYHOVUJE v ostatních kategoriích by mělo být akceptováno s rizikem a zdokumentovaným harmonogramem nápravy před nasazením. Kontrolní seznam by měl být znovu vyhodnocen po jakékoli významné změně MCP serveru, registru nástrojů nebo prostředí nasazení.
Několik nástrojů podporuje automatickou validaci bezpečnosti MCP: Invariant MCP-Scan (specializovaný na skenování bezpečnosti MCP), nástroje SAST s vlastními pravidly pro MCP, npm audit a pip audit pro skenování závislostí, OSV-Scanner pro kontrolu databáze zranitelností, Docker seccomp a profily AppArmor pro runtime izolaci a integrace SIEM pro centralizované monitorování. Žádný jednotlivý nástroj nepokrývá všechny položky kontrolního seznamu — komplexní pokrytí vyžaduje kombinaci statické analýzy, dynamického testování a průběžného monitorování.
Arshia je inženýr AI pracovních postupů ve FlowHunt. Sxa0vzděláním vxa0oboru informatiky a vášní pro umělou inteligenci se specializuje na vytváření efektivních workflow, které integrují AI nástroje do každodenních úkolů a zvyšují tak produktivitu i kreativitu.
Použijte tento kontrolní seznam k vlastnímu posouzení a poté přizvěte náš tým k ověřenému bezpečnostnímu auditu. Testujeme každou položku proti vašemu živému prostředí a dodáme podrobný plán nápravných opatření.
MCP servery vystavují jedinečnou útočnou plochu kombinující tradiční API rizika s hrozbami specifickými pro AI. Naučte se 6 kritických zranitelností identifikov...
Autentizace je nejkritičtější bezpečnostní vrstvou pro vzdálené MCP servery. Zjistěte, proč je OAuth 2.1 s OIDC povinný, jak delegace tokenů předchází útoku Zma...
Otrávení nástrojů a rug pull útoky jsou dva z nejnebezpečnějších vektorů útoku specifických pro MCP. Zjistěte, jak útočníci vkládají škodlivé instrukce do popis...
