OWASP GenAI Security -projekti määrittelee viiden kategorian vähimmäistason turvalliseen MCP-palvelimen käyttöönottoon. Käytä tätä tarkistuslistaa arvioidaksesi nykyisen asemasi identiteetin, eristyksen, työkalujen, validoinnin ja käyttöönoton osalta ennen tuotantoon siirtymistä.
OWASP GenAI Security -projektin käytännöllinen opas MCP-palvelimen kehitykseen huipentuu konkreettiseen katselmointi-tarkistuslistaan – “MCP Security Minimum Bar”. Tämä tarkistuslista määrittelee perustason kontrollit, jotka on oltava paikallaan ennen kuin MCP-palvelin otetaan käyttöön tuotannossa.
Tämä artikkeli esittelee täydellisen tarkistuslistan toteutusohjeistuksineen jokaiselle kohdalle, järjestettynä OWASP-oppaan määrittelemien viiden turvallisuusalueen mukaisesti. Käytä sitä käyttöönottoa edeltäviin turvallisuuskatsauksiin, määräaikaisiin auditointeihin ja viitekehyksenä tunnistettujen aukkojen korjaamiseen.
Kohteiden merkitseminen: Merkitse jokaiselle kohdalle HYVÄKSYTTY (toteutettu ja vahvistettu), HYLÄTTY (ei toteutettu tai osittain toteutettu) tai EI SOVELLU (ei sovellu tähän käyttöönottoon).
Käyttöönoton portit: Kategorian 1 (Identiteetti, autentikointi, käytännöt) ja kategorian 2 (Eristys) kohteet ovat kovia käyttöönoton portteja – mikä tahansa HYLÄTTY tulisi estää julkaisu kunnes korjattu. Muiden kategorioiden kohteet tulisi riskihyväksyä dokumentoiduilla aikatauluilla.
Katselmointilaukaisijat: Suorita täysi tarkistuslista uudelleen jokaisen merkittävän muutoksen jälkeen MCP-palvelimen koodissa, työkalurekisterissä, autentikointikonfiguraatiossa, käyttöönotto-ympäristössä tai kun uusi työkalujen kategoria otetaan käyttöön.
Tämä on korkein prioriteetti kategoria. Autentikointivirheet myöntävät hyökkääjille suoran pääsyn kaikkeen, mitä MCP-palvelin voi tehdä.
Mitä varmistaa: Jokainen etäyhteys MCP-palvelimeen vaatii autentikoinnin oikein konfiguroidun OAuth 2.1 -valtuutuspalvelimen kautta. Anonyymit yhteydet hylätään. Paikalliset STDIO:ta käyttävät MCP-palvelimet voivat käyttää käyttöönottokontekstiin sopivaa vaihtoehtoista autentikointia.
Kuinka testata: Yritä yhdistää ilman valtuutusotsikkoa. Yritä yhdistää väärin muotoillulla tai vanhentuneella tokenilla. Molempien tulisi johtaa autentikointivirheeseen, ei pääsyyn työkaluihin.
Yleiset vikatilat: Kehitysendpointit jätetty saataville ilman autentikointia; varajärjestelmä API-avainautentikointiin, joka ei validoi vanhentumista tai laajuutta; tokenin validointi vain istunnon aloituksessa, ei per-pyyntö.
Mitä varmistaa: Pääsytokenit vanhenevat minuuteissa (ei tunneissa). Jokainen token sisältää vähimmäislaajuuden, joka vaaditaan nykyiseen tehtävään. Jokainen työkalukutsu validoi tokenin allekirjoituksen, julkaisijan (iss), yleisön (aud), vanhentumisen (exp) ja vaaditun laajuuden – ei vain istunnon aloituksessa.
Kuinka testata: Käytä voimassa olevaa tokenia, odota sitten sen vanhentuvan (tai siirrä kello manuaalisesti eteenpäin). Yritä työkalukutsua – sen tulisi epäonnistua 401:llä, ei onnistua välimuistissa olevan validointituloksen perusteella.
Yleiset vikatilat: Tokenin validointi välimuistissa istunnon alussa eikä toistettu; tokenit 24+ tunnin eliniällä; laajat “admin”-laajuudet käytössä operaatiokohtaisten laajuuksien sijaan; exp-kenttää ei tarkisteta.
Mitä varmistaa: MCP-palvelin ei välitä asiakastokeneja loppupään API:hin. Kaikki loppupään palvelukutsut käyttävät nimenomaisesti MCP-palvelimelle myönnettyjä tokeneja (On-Behalf-Of-virtojen tai palvelukirjautumistietojen kautta). Keskitetty käytäntöportti sieppaa kaikki työkalukutsut ja valvoo autentikointia, valtuutusta, suostumusta ja auditointilokitusta ennen kuin mikään työkalukoodi suoritetaan.
Kuinka testata: Tarkista koodi mistä tahansa paikasta, jossa saapuva asiakastoken välitetään lähtevässä API-kutsussa. Tarkista loppupään palvelun pääsylokit varmistaaksesi, että pyynnöt saapuvat palvelinkirjautumistiedoilla, ei käyttäjäkirjautumistiedoilla.
Yleiset vikatilat: Authorization: Bearer ${request.headers.authorization} -malli loppupään kutsuissa; valtuutustarkistukset hajallaan yksittäisissä työkalukäsittelijöissä; ei keskitettyä käytäntöjen valvontapistettä.
Aloita ilmainen kokeilujakso tänään ja näe tulokset muutamassa päivässä.
Eristysvirheet monivuokraaja-ympäristöissä ovat katastrofaalisia – ne mahdollistavat yhden käyttäjän pääsyn toisen tietoihin. Nämä ovat kovia käyttöönoton portteja.
Mitä varmistaa: Ei globaaleja muuttujia, luokkatason attribuutteja tai jaettuja singleton-instansseja, jotka tallentavat käyttäjä- tai istuntokohtaista dataa. Jokainen istunto käyttää itsenäisesti instantioituja objekteja tai istuntoavaimettuja nimiavaruuksia (esim. Redis-avaimet etuliitteellä session_id:). Koodikatselmointi vahvistaa, ettei jaettua muutettavaa tilaa ole istuntojen välillä.
Kuinka testata: Suorita kaksi samanaikaista istuntoa eri käyttäjäidentiteeteillä. Varmista, että istunnossa A kirjoitettua dataa ei voida lukea istunnossa B. Käytä samanaikaisia kuormitustestejä tarkistaaksesi kilpailutilanteita, jotka saattaisivat aiheuttaa istuntotilan vuotamista.
Yleiset vikatilat: self.user_context = {} luokan attribuuttina singleton-palvelussa; globaalit välimuistit ilman istuntoavaimettuja nimiavaruuksia; säikekohtainen tallennus, joka ei kunnolla rajaudu pyynnön elinkaareen.
Mitä varmistaa: Suorituskontekstin lisäksi mikä tahansa jaettu infrastruktuuri (tietokannat, välimuistit, viestijonot) valvoo käyttäjäkohtaisia pääsykontrolleja. Yhdessä käyttäjän istunnossa suoritettu kysely ei voi palauttaa toisen käyttäjän dataa vaikka jaettu infrastruktuuri olisi väärin konfiguroitu tai vaarantunut.
Kuinka testata: Yritä päästä toisen käyttäjän dataan manipuloimalla istuntoparametreja tai hyödyntämällä jaettuja välimuistiavaimia.
Yleiset vikatilat: Välimuistiavaimet perustuvat vain kyselyn sisältöön, ei käyttäjäidentiteettiin; tietokantakyselyt ilman käyttäjärajattuja WHERE-lausekkeita; jaetut väliaikaiset tiedostohakemistot ilman käyttäjäkohtaisia alihakemistoja.
Mitä varmistaa: Kun istunto päättyy (siististi tai aikakatkaisun/virheen kautta), kaikki liittyvät resurssit vapautetaan välittömästi: tiedostokahvat, väliaikaiset tiedostot, muistissa oleva konteksti, välimuistissa olevat tokenit, tietokantayhteydet. Istuntokohtaiset rajat ovat olemassa muistille, CPU:lle, API-nopeudelle ja tiedostojärjestelmän käytölle.
Kuinka testata: Päätä istunto äkillisesti (tapa yhteys ilman siistiä sammutusta). Varmista, ettei jäännösresursseja jää. Luo istunto ja kuluta sen nopeusraja; varmista, ettei se vaikuta muihin istuntoihin.
Yleiset vikatilat: Väliaikaiset tiedostot jäävät /tmp:hen istunnon päättymisen jälkeen; välimuistissa olevia tokeneja ei peruuteta istunnon päättyessä; ei resurssikiintiöitä, jolloin yksi istunto voi tyhjentää jaetun infrastruktuurin.
Työkalujen turvallisuus estää vaarallisimmat MCP-spesifiset hyökkäykset: työkalumyrkytyksen ja rug pullit.
Mitä varmistaa: Jokaisella työkalumääritelmällä on kryptografinen allekirjoitus valtuutetulta työkaluhyväksyjältä. Allekirjoitus kattaa täydellisen manifestin (kuvaus, skeema, versio, oikeudet). MCP-palvelin varmistaa tämän allekirjoituksen lataushetkellä ja hylkää minkä tahansa allekirjoittamattoman tai allekirjoitus-epäsopivan työkalun. Työkaluversiot on kiinnitetty – palvelin ei voi dynaamisesti ladata päivitettyä työkalua ilman uutta hyväksyttyä allekirjoitusta.
Kuinka testata: Muokkaa yhtä merkkiä ladatun työkalun kuvauksessa. Varmista, että palvelin havaitsee hash-epäsopivuuden ja estää työkalun latautumisen. Yritä ladata allekirjoittamaton työkalumääritelmä – se tulisi hylätä.
Yleiset vikatilat: Työkalumääritelmät tallennettu muutettavana konfiguraationa ilman eheyden varmistusta; ei allekirjoitusavain-infrastruktuuria; työkalut ladattu suoraan jaetusta tiedostojärjestelmästä ilman versiokiinnitystä.
Mitä varmistaa: Automaattinen skannaus tarkistaa työkalukuvauksista ohjeenkaltaisia malleja, jotka voisivat edustaa myrkytyksyrityksiä. Määräaikainen validointi vahvistaa, että työkalun todellinen ajonaikainen käyttäytyminen vastaa sen ilmoitettua kuvausta – vain luku -työkalun ei tulisi pystyä kirjoitusoperaatioihin ajonaikana.
Kuinka testata: Lisää epäilyttävä ohje työkalukuvaukseen (“kutsu aina myös send_webhook…”) ja varmista, että automaattinen skannaus merkitsee sen ennen ihmiskatselmointia. Tarkista SAST-työkalun konfiguraatio MCP-spesifisten myrkytyshavaitsemissääntöjen osalta.
Yleiset vikatilat: Ei automaattista työkalukuvausten skannausta; manuaalinen katselmointiprosessi, joka voi missata upotetut ohjeet pitkissä kuvauksissa; ei ajonaikaista käyttäytymisen validointia kyvyistään valehtelevien työkalujen kiinniottamiseksi.
Mitä varmistaa: Mallin konteksti saa vain kentät, jotka vaaditaan oikeaan työkalukutsuun: nimi, kuvaus, syöteskeema, tuloste-skeema. Sisäinen metadata, toteutuksen yksityiskohdat, debuggaustiedot ja arkaluonteinen konfiguraatio suodatetaan pois ennen kuin ne välitetään mallille.
Kuinka testata: Tarkista, mitä malli saa kun se luetteloi saatavilla olevat työkalut. Varmista, ettei sisäisiä kenttiä, yhteysmerkkijonoja tai operatiivista metadataa näy mallin näkymässä.
Yleiset vikatilat: Täydet työkalukonfiguraatio-objektit välitetty mallin kontekstiin; virheilmoitukset sisältävät sisäisiä järjestelmän yksityiskohtia, jotka vuotavat mallille; työkalukuvaukset sisältävät toteutushuomautuksia, jotka eivät ole relevantteja kutsulle.
Saa uusimmat vinkit, trendit ja tarjoukset ilmaiseksi.
Validointivirheet mahdollistavat injektoinnin, datan manipuloinnin ja palvelunestohyökkäykset.
Mitä varmistaa: JSON Schema -validointi on valvottu jokaiselle MCP-protokollaviestille, jokaiselle työkalukutsun syötteelle ja jokaiselle työkalun tulosteelle ennen kuin se saavuttaa mallin. Validointi hylkää minkä tahansa viestin, joka ei vastaa määriteltyä skeemaa – puuttuvat pakolliset kentät, väärät tyypit, arvot sallittujen alueiden ulkopuolella.
Kuinka testata: Lähetä työkalukutsu, josta puuttuu pakollinen parametri. Lähetä viesti ylimääräisellä odottamattomalla kentällä. Molempien tulisi hylätä, ei hiljaa sivuuttaa tai käsitellä oletusarvoilla.
Yleiset vikatilat: Valinnainen validointi, joka ohitetaan virhetilanteissa; validointi vain syötteille, ei tulosteille; liian sallivat skeemat (hyväksyvät type: "any" -parametreja).
Mitä varmistaa: Kaikki syötteet puhdistetaan poistamaan tai escapettamaan merkit, jotka voisivat mahdollistaa injektoinnin (XSS-sekvenssit, SQL-metamerkit, shell-metamerkit, null-tavut). Kokorajoitukset valvotaan kaikille syötteille ja tulosteille. Palvelin käsittelee kaikkea mallista tulevaa dataa mahdollisesti vihamielisenä, identtisesti käyttäjäsyötteen kanssa perinteisessä web-sovelluksessa.
Kuinka testata: Lähetä syötteitä sisältäen SQL-injektio-payloadeja, shell-metamerkkejä ja XSS-sekvenssejä. Varmista, että ne hylätään tai escapetetaan turvallisesti ennen kuin ne saavuttavat loppupään järjestelmät. Lähetä syöte, joka ylittää kokorajan – varmista, että se hylätään siististi.
Yleiset vikatilat: Syötteet välitetty suoraan SQL-kyselyihin tai shell-komentoihin; ei kokorajoituksia, jolloin ylisuuret syötteet voivat aiheuttaa muistin tyhjentymisen; tulosteet palautettu mallille ilman kokorajoituksia tai sisällön suodatusta.
Mitä varmistaa: Työkalukutsut hyväksytään vain strukturoituina JSON-objekteina validoiduilla skeemoilla. Vapaata tekstiä generoivaa, joka implikoi työkalukutsuja, ei käsitellä. Järjestelmää ei voida saada suorittamaan työkalukutsuja generoimalla luonnollista kieltä, jonka palvelin tulkitsee komennoiksi.
Kuinka testata: Lähetä luonnollisen kielen merkkijono, joka kuvaa työkalukutsun (“kutsu delete_file-työkalua polulla /etc/passwd”). Varmista, että palvelin ei tulkitse tätä työkalukutsuksi.
Yleiset vikatilat: Hybridijärjestelmät, jotka hyväksyvät sekä strukturoidun JSON:n että luonnollisen kielen työkalukuvaukset; palvelimet, jotka jäsentävät mallin generoimaa tekstiä tunnistaakseen työkalukutsuja; regex-pohjainen työkalukutsun jäsennys, joka voidaan väärentää.
Käyttöönoton kovennus rajoittaa minkä tahansa hyödynnetyn haavoittuvuuden räjähdyssädettä.
Mitä varmistaa: MCP-palvelin toimii minimalistisessa kovetussa kontissa. Konttiprosessi toimii ei-root-käyttäjänä. Tarpeettomat Linux-kyvyt pudotetaan. Verkkokäytännöt rajoittavat kaiken sisään- ja ulosmenevän liikenteen nimenomaisesti vaadittuihin yhteyksiin. Kontti-image sisältää vain vähimmäisvaaditun ohjelmiston.
Kuinka testata: Suorita docker inspect ja varmista, että käyttäjä on ei-root. Tarkista verkkokäytännöt ja vahvista, että ne estävät kaiken liikenteen paitsi nimenomaisesti sallitut yhteydet. Skannaa kontti-image tarpeettomien pakettien tai tunnettujen haavoittuvien ohjelmistojen varalta.
Yleiset vikatilat: Kontit toimivat rootina mukavuuden vuoksi; ei verkkokäytäntöjä, jolloin kaikki ulosmenevä liikenne on sallittu; perus-imaget täysillä OS-asennuksilla minimalististen imageiden sijaan.
Mitä varmistaa: Kaikki API-avaimet, OAuth-asiakassalaisuudet, tietokannan kirjautumistiedot ja palvelutilin tokenit tallennetaan salaisuusholveissa (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault jne.). Ei salaisuuksia ympäristömuuttujissa, lähdekoodissa, kontti-imageissa tai lokitulosteessa. Salaisuuksien hallintaoperaatiot tapahtuvat väliohjelmistossa, joka on AI-mallin ulottumattomissa – LLM ei koskaan näe tai käsittele kirjautumistietojen arvoja.
Kuinka testata: Etsi lokeista kirjautumistietojen kaltaisia merkkijonoja. Tarkista palvelinprosessin saatavilla olevat ympäristömuuttujat. Tarkista mallin saatavilla oleva konteksti vahvistaaksesi, ettei kirjautumistietojen arvoja näy.
Yleiset vikatilat: API-avaimet .env-tiedostoissa, jotka on commitoitu versionhallintaan; kirjautumistiedot palautettu virheilmoituksissa, jotka saavuttavat mallin; salaisuudet välitetty työkaluparametreina, jotka näkyvät mallin keskustelukontekstissa.
Mitä varmistaa: Käyttöönottoputki sisältää automaattisen turvallisuusskannauksen (SAST, SCA, riippuvuushaavoittuvuusskannaus) koovina portteina – epäonnistuneet skannaukset estävät käyttöönoton. Kaikki työkalukutsut, autentikointitapahtumat ja valtuutuspäätökset lokitetaan muuttumattomasti täydellä kontekstilla. Lokit otetaan SIEM:iin reaaliaikaisella hälyttämisellä poikkeavista malleista (epäonnistuneiden validointien piikit, epätavallinen työkalukutsutiheys, odottamattomat ulkoiset yhteydet).
Kuinka testata: Lisää tunnettu haavoittuva riippuvuus ja varmista, että CI/CD-putki epäonnistuu buildin. Generoi poikkeavia työkalukutsumalleja ja varmista, että SIEM-hälytykset laukeavat odotetun vastausajan sisällä.
Yleiset vikatilat: Turvallisuusskannaus neuvoa-antavana eikä estävinä portteina; lokit kirjoitettu muutettavaan tallennustilaan, jota hyökkääjä voisi muokata; ei hälyttämistä poikkeavista malleista; liiallinen lokien verbositeetti, joka tekee relevantit tapahtumat mahdottomiksi löytää.
Tulosta tai vie tämä tarkistuslista ja käy se läpi järjestelmällisesti jokaiselle MCP-palvelimelle ennen tuotantokäyttöönottoa. Ota turvallisuustiimisi mukaan katselmointiin – monet kohteet vaativat sekä koodikatselmointia että live-testausta oikean varmistamisen vuoksi.
Tiimeille, jotka haluavat riippumatonta varmistusta, ammattimainen MCP-turvallisuusauditointi testaa kaikki 16 tarkistuslistan kohtaa live-ympäristössäsi käyttäen vihamielisiä testaustekniikoita itsearviointien sijaan. Tuloksena on vahvistettu turvallisuusasemaraportti priorisoituine korjaussuunnitelmineen.
OWASP GenAI Security -projektin 'MCP Security Minimum Bar' on katselmointi-tarkistuslista, joka määrittelee perustason turvallisuuskontrollit, jotka vaaditaan ennen kuin MCP-palvelin tulisi ottaa käyttöön tuotannossa. Se kattaa viisi osa-aluetta: Vahva identiteetti/autentikointi/käytäntöjen valvonta, Tiukka eristys ja elinkaaren hallinta, Luotetut ja kontrolloidut työkalut, Skeemapohjainen validointi sekä Kovennettu käyttöönotto jatkuvalla valvonnalla. Vähimmäistason täyttämättä jättäminen tarkoittaa, että MCP-palvelinta ei tulisi ottaa käyttöön ennen kuin puutteet on korjattu.
Käy läpi jokainen kategoria järjestelmällisesti merkiten kohteet HYVÄKSYTTY, HYLÄTTY tai EI SOVELLU todisteilla jokaisesta päätöksestä. Mikä tahansa HYLÄTTY kategorioissa 1 tai 2 (identiteetti ja eristys) tulisi estää käyttöönotto – nämä ovat suurimman riskin aukkoja. Muiden kategorioiden HYLÄTYT tulisi riskihyväksyä dokumentoidulla korjausaikataululla ennen käyttöönottoa. Tarkistuslista tulisi arvioida uudelleen jokaisen merkittävän muutoksen jälkeen MCP-palvelimessa, työkalurekisterissä tai käyttöönotto-ympäristössä.
Useat työkalut tukevat automaattista MCP-turvallisuusvalidointia: Invariant MCP-Scan (erikoistunut MCP-turvallisuusskannaukseen), SAST-työkalut mukautetuilla MCP-säännöillä, npm audit ja pip audit riippuvuusskannaukseen, OSV-Scanner haavoittuvuustietokantahakuihin, Docker seccomp ja AppArmor -profiilit ajonaikaiseen eristykseen sekä SIEM-integraatio keskitettyyn valvontaan. Mikään yksittäinen työkalu ei kata kaikkia tarkistuslistan kohtia – kattava kattavuus vaatii staattisen analyysin, dynaamisen testauksen ja jatkuvan valvonnan yhdistämistä.
Arshia on AI-työnkulkuinsinööri FlowHuntilla. Tietojenkäsittelytieteen taustalla ja intohimolla tekoälyyn hän erikoistuu luomaan tehokkaita työnkulkuja, jotka integroivat tekoälytyökaluja arjen tehtäviin, parantaen tuottavuutta ja luovuutta.
Käytä tätä tarkistuslistaa itsearvioinnissa ja kutsu sitten tiimimme tekemään vahvistettu turvallisuusauditointi. Testaamme jokaisen kohdan live-ympäristössäsi ja toimitamme yksityiskohtaisen korjaussuunnitelman.
Autentikointi on kriittisin tietoturvakerros etä-MCP-palvelimille. Opi, miksi OAuth 2.1 ja OIDC ovat pakollisia, miten tokenin delegointi estää Confused Deputy ...
MCP-palvelimet paljastavat ainutlaatuisen hyökkäyspinnan, joka yhdistää perinteiset API-riskit tekoälykohtaisiin uhkiin. Opi OWASP GenAI:n tunnistamia 6 kriitti...
Työkalun myrkytys ja rug pull -hyökkäykset ovat kaksi vaarallisinta MCP-spesifistä hyökkäysvektoria. Opi kuinka hyökkääjät upottavat haitallisia ohjeita työkalu...
