Tryggðu öryggi MCP-kerfisins þíns: 11 algengir áhættuþættir og hvernig á að verjast þeim

Áhættu tengda MCP má í stórum dráttum skipta í þrjá flokka: misnotkun á LLM-líkönum, öryggi gagna og aðgangs, og veikleika í innviðum.

Þar sem MCP-þjónar veita oft aðgang að fjölda innri kerfa er hugsanleg öryggisáhætta mikil. Líkurnar ráðast þó mjög af uppsetningunni.

Einstaklingar og fyrirtæki geta gripið til margra ráðstafana til að tryggja að kerfi þeirra séu varin, og verklag ætti alltaf að vera í réttu hlutfalli við þá getu og þau gögn sem tengdir MCP-þjónar gætu afhjúpað.

Hvað er MCP og MCP-öryggi?

Model Context Protocol (MCP) er opinn staðall sem Anthropic bjó til til að tengja forrit sem byggja á LLM-líkönum (eða hýsla) við ytri kerfi.

Í MCP-kerfi eru þrír meginþættir: hýsillinn, biðlarinn og þjónninn. Hýsillinn, sem er oft gervigreindaraðstoðarmaður, tengist ytri MCP-þjóni í gegnum biðlara. Hann getur síðan sent beiðnir um að keyra ytri virkni (verkfæri) eða sækja gögn (tilföng) eða fyrirmæli til að bæta við samhengisglugga LLM-líkansins.

Stækka

MCP-öryggi vísar til þeirra verklagsreglna sem vernda tengingar og íhluti í MCP-kerfi. Nokkrar lykiláskoranir eru einstakar fyrir MCP, meðal annars sú staðreynd að gervigreindarforrit geta oft framkvæmt aðgerðir sjálfstætt og að hægt er að fela skaðleg fyrirmæli í skilaboðum.

Þekkt vandamál sem eru ekki bundin við MCP, svo sem fyrirmælainnspýting (prompt injection), veik auðkenning og óörugg samþætting við þriðju aðila, skapa einnig vanda. Eins og á við um öll tölvukerfi reiðir MCP sig á blöndu af verklagsreglum, eins og að nota eingöngu trausta þjóna, og tæknilegum stýringum, eins og API-gáttum, til verndar.

Hversu alvarlegar eru MCP-ógnir?

MCP hefur fljótt orðið vinsæl LLM-tækni og mörg fyrirtæki og stofnanir, sem og forrit fyrir almenna notendur, nota hana. Þar sem MCP-þjónar eru forrit skrifuð í kóða eru á þeim veikleikar eins og á hverju öðru forriti.

Þegar fyrirtæki nota MCP í stýrðu umhverfi er það þó almennt öruggt. Það er reginmunur á því að byggja kerfi með traustum þjónum og staðfestum heimildum og að tengja sjálfstæðan gervigreindarfulltrúa við tylft óyfirfarinna þjóna.

Ógn nr. 1: Óbein fyrirmælainnspýting

Árásaraðili getur komið fyrirmælum sem beinast að LLM-líkaninu fyrir í skjali, vefsíðu eða úttaki verkfæris sem MCP-þjónn skilar. Ef hýsillinn bætir þessu efni við samhengisgluggann er hætta á að LLM-líkanið telji það vera raunveruleg fyrirmæli.

Það sem meira er, þessi fyrirmæli geta virst eðlileg á yfirborðinu. Til dæmis gæti þjónustubeiðni sem sótt er sagt LLM-líkaninu að flytja út viðkvæmar viðskiptavinaskrár áður en það býr til svar.

Hvernig á að verjast óbeinni fyrirmælainnspýtingu

Yfirleitt ætti að taka á fyrirmælainnspýtingu á stigi hýsilsins. Merkja ætti ytra efni sem ótraust og beiðnir um viðkvæmar upplýsingar ættu að krefjast upplýsts samþykkis frá manneskju sem hefur eftirlit með ferlinu. Öryggisprófanir þar sem skaðleg skjöl eða gögn eru kölluð fram til að sjá hvernig hýsillinn og LLM-líkanið bregðast við geta einnig komið að gagni.

Ógn nr. 2: Eitrun verkfæra og teppisvik (rug pulls)

Í verkfæraeitrunarárás er skaðlegum kóða bætt við lýsingu eða skema MCP-verkfæris. Þetta getur haft áhrif á LLM-líkanið í uppgötvunarfasanum, þegar MCP birtir fyrst tiltæk verkfæri.

Stækka

Teppisvik (rug pull) eru sérstök tegund verkfæraeitrunar þar sem samþykktum lýsigögnum er breytt. Þetta form verkfæraeitrunar gæti breytt því hvernig líkan notar traust verkfæri í stað þess að kalla beint á skaðlegt verkfæri.

Hvernig á að verjast eitrun verkfæra og teppisvikum

Hýsillinn ætti að skoða alla skilgreiningu hvers verkfæris áður en það er notað og bera hana saman við lista yfir samþykkt og traust verkfæri og greina þannig allar breytingar. Færibreytuathuganir geta hjálpað til við að bera kennsl á mögulega hættulega getu og merkja hana.

Ógn nr. 3: Óhóflegar heimildir

Algengt er að notendur veiti MCP-þjónum og tengdum LLM-líkönum (í gegnum hýsilinn) víðtækari heimildir en nauðsynlegt er fyrir verkefnið. Til dæmis skrifheimildir þegar lesaðgangur myndi nægja, eða fullan aðgang að innra skráakerfi (eins og Google Drive).

Þessi víðtæka heimildaþensla getur aukið umfang tjóns af öðrum veikleikum, eins og skaðlegum verkfæraköllum. Algengt er að heimildir „safnist upp“ þegar notendur veita réttindi í daglegu starfi með gervigreindarverkfærum innan fyrirtækis (uppsöfnun réttinda).

Hvernig á að verjast óhóflegum heimildum

Beinasta leiðin til að verjast þessu vandamáli er að takmarka heimildir og OAuth-umfang (lestur, ritun, fullur aðgangur o.s.frv.). Samþykki notenda, sérstaklega fyrir viðkvæmar aðgerðir, er mikilvægur hluti af þessu, en einnig ætti að stýra heimildum á kerfisstigi (stýrikerfi, MCP-hýsill og þjónn).

Ógn nr. 4: Veik auðkenning og heimildastýring

Auðkenning staðfestir auðkenni notenda eða forrita sem tengjast MCP-þjóni. Heimildastýring kveður á um hvaða verkfæri og tilföng þeir hafa aðgang að.

Illa stilltir MCP-þjónar geta tekið við beiðnum eða tókum án þess að auðkenna notendur rétt eða framfylgja aðgangstakmörkunum. Auk þess geta stolnar innskráningarupplýsingar gert óprúttnum aðilum kleift að komast inn ef sannprófun er veik.

Hvernig á að verjast veikri auðkenningu og heimildastýringu

OAuth-auðkenning fyrir fjartengda MCP-þjóna, skammlífir tókar og hlutverkatengd aðgangsstýring (RBAS) eru allt ráðstafanir sem hjálpa til við að draga úr hættu vegna veikrar heimildastýringar. Hlutverkatengdur aðgangur er gagnlegur vegna þess að hann kemur í veg fyrir að notendur fái aðgang að gögnum og verkfærum umfram heimildir sínar, jafnvel þótt þjónninn sjálfur hafi aðgang.

Ógn nr. 5: Leki og misnotkun innskráningarupplýsinga

MCP-þjónar nota reglulega innskráningarupplýsingar eins og API-lykla og OAuth-aðgangstóka til að tengjast ytri þjónustum. Ef þær verða afhjúpaðar eða misnotaðar geta árásaraðilar fengið aðgang að viðkvæmum gögnum og virkni.

Eitt dæmi er framsending tóka (token passthrough), þar sem MCP-þjónn framsendir aðgangstóka til annarrar þjónustu án þess að staðfesta að hann sé í raun ætlaður þjónustunni sem tekur við honum. Það getur síðan leitt til leka ef móttökuþjónustan er ekki nægilega varin.

Hvernig á að verjast leka og misnotkun innskráningarupplýsinga

Skammlífir tókar með þröngt umfang og regluleg endurnýjun innskráningarupplýsinga takmarka á áhrifaríkan hátt hversu mikið óprúttnir aðilar geta nýtt sér gögn sem leka. API-lykla og innskráningarupplýsingar ætti alltaf að geyma á öruggan hátt í leyndarmálastjóra.

Ógn nr. 6: Árásir á ruglaðan staðgengil (confused deputy)

Árás á ruglaðan staðgengil (confused deputy) á sér stað þegar árásaraðili blekkir traust forrit til að nota heimildir sínar til að framkvæma aðgerð sem lögmætur notandi hefur ekki heimilað. Í þessu tilviki er MCP-þjónninn staðgengillinn.

Stækka

Árásaraðilinn nýtir sér veikleika í MCP-þjóni (eins og veika OAuth-sannprófun) til að keyra skaðlegt ferli, svo sem verkfærakall eða gagnaöflun.

Hvernig á að verjast árásum á ruglaðan staðgengil

Sannprófun heimilda, þar sem staðfest er að hvert verkfærakall tilheyri tilteknum notanda, hjálpar til við að takmarka árásir á ruglaðan staðgengil. Auk þess ættu viðkvæmar aðgerðir, svo sem gagnaútflutningur, að krefjast skýrrar heimildar.

Ógn nr. 7: Skaðlegir þjónar og sýkt hæði (dependencies)

MCP-þjónar geta innihaldið skaðlegan kóða (þeir eru í raun ytri forrit) eða reitt sig á sýkt hæði, svo sem kóðasöfn frá þriðju aðilum. Þetta er vandamál í aðfangakeðju hugbúnaðar frekar en vandamál sem er einstakt fyrir MCP.

Ein einföld leið til að þetta gerist er ef árásaraðili dreifir samþættingu sem virðist lögmæt. Þegar hún hefur verið sett upp getur hún stolið innskráningarupplýsingum og endurnýtt þær, fengið aðgang að viðkvæmum gögnum og framkvæmt óheimilar aðgerðir.

Hvernig á að verjast skaðlegum þjónum og sýktu hæði

Settu aðeins upp MCP-þjóna frá traustum og yfirförnum aðilum. Ef mögulegt er skaltu fara yfir kóðann þeirra og alltaf athuga öll ytri hæði. Gakktu úr skugga um að þjónar séu uppfærðir og plástraðir reglulega.

Ógn nr. 8: Fölsun beiðna á þjónshlið (SSRF)

Fölsun beiðna á þjónshlið (SSRF) á sér stað þegar árásaraðili blekkir MCP-þjón til að senda netbeiðnir á innri vistföng sem notandinn ætlaði sér ekki að fá aðgang að.

Þetta getur gerst þegar MCP-þjónn býður upp á verkfæri sem sækir upplýsingar af vefslóð. Ef árásaraðili getur haft áhrif á vefslóðarfæribreytuna getur hann breytt henni í það netvistfang sem hann vill, svo sem innra API eða skýjaþjónustu. Það getur leitt til þess að viðkvæm gögn séu sótt og hugsanlega gerð aðgengileg

Hvernig á að verjast fölsun beiðna á þjónshlið (SSRF)

MCP-þjónar ættu alltaf að sannprófa vefslóðir, loka á aðgang að takmörkuðum innri netvistföngum og koma í veg fyrir netaðgang út á við. Áframsendingar ættu einnig að fylgja þessu verklagi.

Ógn nr. 9: Lotuyfirtaka

Lotuyfirtaka felst í því að árásaraðili tekur stjórn á virkri tengingu milli MCP-biðlara og þjóns.

Til dæmis gæti hann stolið lotuauðkenni úr illa vörðu MCP-forriti (t.d. hýsli eða þjóni). Ef MCP-þjónninn samþykkir þetta auðkenni getur árásaraðilinn hugsanlega kallað á verkfæri með lögmætum heimildum notandans.

Hvernig á að verjast

Draga má úr hættu á lotuyfirtöku með strangri auðkennisstaðfestingu í öllum forritum MCP-kerfis. Dulkóðun milli MCP-biðlara og fjartengdra þjóna er einnig nauðsynleg til að koma í veg fyrir að hægt sé að greina lotuauðkenni.

Ógn nr. 10: Víxlárásir (mix-up attacks)

Í víxlárás blekkir árásaraðilinn MCP-biðlara til að senda heimildarkóða til skaðlegs heimildaþjóns sem situr á milli biðlarans og MCP-þjónsins. Heimildaþjónn er forrit sem gefur út OAuth-aðgangstóka eftir að hafa gengið úr skugga um að umbeðinn aðgangur sé heimilaður.

Stækka

Ef MCP-hýsill tengist mörgum þjónustum sem hver notar sinn heimildaþjón getur árásaraðili hugsanlega náð stjórn á einum þeirra (ef til vill með því að skrá skaðlega þjónustu) og fengið biðlarann til að senda heimildarkóða, sem lögmætur þjónn gaf út, til skaðlega þjónsins. Þessi víxlun getur gert árásaraðilanum kleift að þykjast vera heimilaða forritið og fá aðgang að vernduðum þjónustum.

Hvernig á að verjast víxlárásum

MCP-biðlarar ættu að staðfesta auðkenni heimildaþjónsins í gegnum allt OAuth-ferlið. Nánar tiltekið ættu þeir að bera útgefandaauðkenni þjónsins (iss) saman við væntanlegt auðkenni og hafna því ef það passar ekki.

Ógn nr. 11: Innbrot í staðbundinn MCP-þjón

Margir MCP-þjónar keyra á tölvu notandans. Notandinn gæti sett þjóninn upp frá þriðja aðila eða smíðað hann sjálfur. Ef árásaraðila tekst að brjótast inn í þennan staðbundna MCP-þjón getur hann hugsanlega fengið aðgang að stórum hlutum staðbundna kerfisins.

Árásaraðili getur komist inn með ýmsum hætti. Hann getur dreift skaðlegum þjóni dulbúnum sem lögmætri samþættingu, breytt stillingum MCP-hýsils þannig að hann gefi skaðlega skipun, eða fengið aðgang að MCP-þjóni sem keyrir í umhverfi með ófullnægjandi öryggisstýringum, til dæmis með DNS-endurbindingu (DNS rebinding), sem blekkir vafra til að senda beiðnir til þjónustu á localhost.

Hvernig á að verjast innbroti í staðbundinn MCP-þjón

Keyrsla í sandkassa og strangar reglur um samþykki eru mikilvægar þegar staðbundnir MCP-þjónar eru notaðir. MCP-þjóna ætti aldrei að setja upp nema frá traustum veitendum og heimildir stýrikerfisins ættu að takmarka hvaða möppum þeir hafa aðgang að.

Veikleikar í MCP eru oft gamlar ógnir í nýjum búningi

Veikleikar í MCP stafa oft af nýrri beitingu þekktrar áhættu og árásaraðferða. MCP opnar árásaraðilum nýjar leiðir til að nýta sér þessa veikleika í gegnum samspil LLM-líkana, MCP-þjóna og ytri þjónusta.

Vissulega eru til ógnir sem eru sértækar fyrir MCP. Þó er vert að hafa í huga að hefðbundnar öryggisráðstafanir, svo sem að framfylgja strangri heimildastýringu, nota trausta veitendur og verjast fyrirmælainnspýtingu, gera mikið gagn við að vernda hvaða MCP-innleiðingu sem er.