तुमची MCP सिस्टिम सुरक्षित करा: 11 सामान्य धोके आणि त्यांच्यापासून संरक्षण कसे करावे

MCP चे धोके मुख्यतः तीन श्रेणींमध्ये मोडतात: LLM मध्ये फेरफार, डेटा आणि ॲक्सेस सुरक्षा, आणि इन्फ्रास्ट्रक्चरमधील त्रुटी.

MCP सर्व्हर अनेकदा विविध अंतर्गत सिस्टिम्सचा ॲक्सेस देत असल्यामुळे संभाव्य सुरक्षा धोका जास्त असतो. मात्र, तो धोका प्रत्यक्षात उद्भवण्याची शक्यता मुख्यत्वे सेटअपवर अवलंबून असते.

व्यक्ती आणि एंटरप्राइझ त्यांच्या सिस्टिम्स सुरक्षित राहाव्यात यासाठी अनेक पावले उचलू शकतात, आणि कनेक्ट केलेले MCP सर्व्हर ज्या क्षमता आणि डेटा उघड करू शकतात, त्यांच्या प्रमाणातच सुरक्षा प्रोटोकॉल नेहमी असावेत.

MCP आणि MCP सुरक्षा म्हणजे काय?

Model Context Protocol (MCP) हे LLM-आधारित ॲप्स (किंवा होस्ट) बाह्य सिस्टिम्सशी जोडण्यासाठी Anthropic ने तयार केलेले एक ओपन स्टँडर्ड आहे.

MCP सिस्टिममध्ये तीन मुख्य घटक असतात: होस्ट, क्लायंट आणि सर्व्हर. होस्ट, जो बहुतेकदा AI असिस्टंट असतो, क्लायंटद्वारे बाह्य MCP सर्व्हरशी कनेक्ट होतो. त्यानंतर तो बाह्य कार्यक्षमता (टूल्स) चालवण्यासाठी, डेटा (रिसोर्सेस) मिळवण्यासाठी किंवा LLM च्या कॉन्टेक्स्ट विंडोमध्ये जोडण्यासाठी प्रॉम्प्ट्स मिळवण्यासाठी विनंत्या पाठवू शकतो.

विस्तृत करा

MCP सुरक्षा म्हणजे MCP सिस्टिममधील कनेक्शन्स आणि घटकांचे संरक्षण करणारे प्रोटोकॉल. MCP साठी विशिष्ट अशी अनेक प्रमुख आव्हाने आहेत; उदाहरणार्थ, AI ॲप्समध्ये अनेकदा एजंटिक क्षमता असतात आणि संदेशांमध्ये दुर्भावनापूर्ण सूचना दडवल्या जाऊ शकतात.

केवळ MCP पुरत्या मर्यादित नसलेल्या प्रस्थापित समस्या, जसे की प्रॉम्प्ट इंजेक्शन, कमकुवत प्रमाणीकरण आणि असुरक्षित थर्ड-पार्टी इंटिग्रेशन्स, याही अडचणी निर्माण करतात. इतर कोणत्याही संगणक प्रणालीप्रमाणे, MCP देखील संरक्षणासाठी प्रक्रियात्मक प्रोटोकॉल (उदा. केवळ विश्वासार्ह सर्व्हर वापरणे) आणि तांत्रिक नियंत्रणे (उदा. API गेटवे) यांच्या मिश्रणावर अवलंबून असते.

MCP धोके किती गंभीर आहेत?

MCP हे झपाट्याने लोकप्रिय LLM तंत्रज्ञान बनले आहे आणि अनेक संस्था तसेच ग्राहकाभिमुख ॲप्स ते वापरतात. MCP सर्व्हर हे कोडमध्ये लिहिलेले प्रोग्राम असल्यामुळे, इतर कोणत्याही ॲप्लिकेशनप्रमाणे त्यांच्यातही त्रुटी असतात.

मात्र, संस्था नियंत्रित डिप्लॉयमेंटमध्ये MCP वापरतात तेव्हा ते साधारणपणे सुरक्षित असते. विश्वासार्ह सर्व्हर आणि पडताळलेल्या परवानग्यांसह सिस्टिम तयार करणे आणि एखाद्या स्वायत्त एजंटला डझनभर न तपासलेल्या सर्व्हरशी जोडणे यात खूप मोठा फरक आहे.

धोका #1: अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन

हल्लेखोर LLM ला उद्देशून सूचना एखाद्या दस्तऐवजात, वेबपेजमध्ये किंवा MCP सर्व्हर परत करत असलेल्या टूल आउटपुटमध्ये ठेवू शकतो. होस्टने हा मजकूर कॉन्टेक्स्ट विंडोमध्ये जोडल्यास, LLM त्याला खऱ्या सूचना समजण्याची शक्यता असते.

इतकेच नाही, तर या सूचना वरकरणी योग्य वाटू शकतात. उदाहरणार्थ, मिळवलेले एखादे सपोर्ट तिकीट LLM ला उत्तर तयार करण्यापूर्वी संवेदनशील ग्राहक रेकॉर्ड्स एक्सपोर्ट करण्यास सांगू शकते.

अप्रत्यक्ष प्रॉम्प्ट इंजेक्शनपासून संरक्षण कसे करावे

प्रॉम्प्ट इंजेक्शन्सचा सामना साधारणपणे होस्टच्या स्तरावर केला पाहिजे. बाह्य मजकूर अविश्वसनीय म्हणून लेबल केला जावा, आणि संवेदनशील माहितीच्या विनंत्यांसाठी प्रक्रियेत सहभागी असलेल्या व्यक्तीची (ह्युमन-इन-द-लूप) माहितीपूर्ण मंजुरी आवश्यक असावी. होस्ट आणि LLM कसा प्रतिसाद देतात हे पाहण्यासाठी दुर्भावनापूर्ण दस्तऐवज किंवा डेटा कॉल करणाऱ्या सुरक्षा चाचण्याही उपयुक्त ठरू शकतात.

धोका #2: टूल पॉयझनिंग आणि रग पुल्स

टूल पॉयझनिंग हल्ल्यात, MCP टूलच्या वर्णनात किंवा स्कीमामध्ये दुर्भावनापूर्ण कोड जोडला जातो. यामुळे डिस्कव्हरी टप्प्यात, म्हणजेच MCP प्रथम उपलब्ध टूल्स उघड करते तेव्हा, LLM वर प्रभाव पडण्याची शक्यता असते.

विस्तृत करा

रग पुल हा टूल पॉयझनिंगचा एक विशेष प्रकार आहे, ज्यात मंजूर मेटाडेटा बदलला जातो. टूल पॉयझनिंगचा हा प्रकार थेट दुर्भावनापूर्ण टूल चालवण्याऐवजी, मॉडेल विश्वासार्ह टूल्स कसे वापरते ते बदलू शकतो.

टूल पॉयझनिंग आणि रग पुल्सपासून संरक्षण कसे करावे

होस्टने प्रत्येक टूल वापरण्यापूर्वी त्याची संपूर्ण व्याख्या तपासावी आणि मंजूर विश्वासार्ह टूल्सच्या यादीशी तिची तुलना करावी, जेणेकरून कोणतेही बदल लक्षात येतील. पॅरामीटर तपासण्यांमुळे धोकादायक क्षमतांची शक्यता ओळखण्यास आणि त्या फ्लॅग करण्यास मदत होऊ शकते.

धोका #3: अतिरिक्त परवानग्या

वापरकर्त्यांनी MCP सर्व्हर आणि (होस्टद्वारे) कनेक्ट केलेल्या LLM ना एखाद्या कामासाठी आवश्यकतेपेक्षा जास्त परवानग्या देणे सामान्य आहे. उदाहरणार्थ, केवळ वाचण्याचा ॲक्सेस पुरेसा असताना लिहिण्याच्या परवानग्या देणे, किंवा फाइल्सच्या अंतर्गत सिस्टिमचा (जसे की Google Drive) पूर्ण ॲक्सेस देणे.

परवानग्यांचा हा व्यापक फैलाव (परमिशन क्रीप) दुर्भावनापूर्ण टूल कॉल्ससारख्या इतर असुरक्षिततांच्या परिणामांची व्याप्ती वाढवू शकतो. एंटरप्राइझमध्ये वापरकर्ते AI टूल्ससोबतच्या दैनंदिन कामादरम्यान जसजसे विशेषाधिकार देत जातात, तसतशा परवानग्या “वाढत जाणे” सामान्य आहे (विशेषाधिकार संचय).

अतिरिक्त परवानग्यांपासून संरक्षण कसे करावे

या समस्येपासून संरक्षण करण्याचा सर्वात थेट मार्ग म्हणजे परवानग्या आणि OAuth स्कोप्स (वाचणे, लिहिणे, पूर्ण ॲक्सेस इ.) मर्यादित करणे. वापरकर्त्यांच्या मंजुऱ्या, विशेषतः संवेदनशील ऑपरेशन्ससाठी, हा याचा महत्त्वाचा भाग आहे, परंतु परवानग्या सिस्टिम स्तरावरही (ऑपरेटिंग सिस्टिम, MCP होस्ट आणि सर्व्हर) नियंत्रित केल्या पाहिजेत.

धोका #4: कमकुवत प्रमाणीकरण आणि अधिकृतता

प्रमाणीकरण MCP सर्व्हरशी कनेक्ट होणाऱ्या वापरकर्त्यांची किंवा ॲप्लिकेशन्सची ओळख पडताळते. अधिकृतता ते कोणती टूल्स आणि रिसोर्सेस ॲक्सेस करू शकतात हे ठरवते.

चुकीच्या पद्धतीने कॉन्फिगर केलेले MCP सर्व्हर वापरकर्त्यांचे योग्य प्रमाणीकरण न करता किंवा ॲक्सेस निर्बंध लागू न करता विनंत्या किंवा टोकन्स स्वीकारू शकतात. याशिवाय, पडताळणी कमकुवत असल्यास, चोरलेल्या क्रेडेन्शियल्सच्या मदतीने गैरप्रवृत्त व्यक्तींना ॲक्सेस मिळू शकतो.

कमकुवत प्रमाणीकरण आणि अधिकृततेपासून संरक्षण कसे करावे

रिमोट MCP सर्व्हरसाठी OAuth-आधारित प्रमाणीकरण, अल्पकाळ टिकणारे टोकन्स आणि भूमिका-आधारित ॲक्सेस नियंत्रण (RBAS) हे सर्व उपाय कमकुवत अधिकृततेचा धोका कमी करण्यास मदत करतात. भूमिका-आधारित ॲक्सेस उपयुक्त आहे, कारण सर्व्हरला स्वतः ॲक्सेस असला तरीही तो वापरकर्त्यांना त्यांच्या परवानग्यांपलीकडील डेटा आणि टूल्स ॲक्सेस करण्यापासून रोखतो.

धोका #5: क्रेडेन्शियल लीक्स आणि गैरवापर

बाह्य सेवांशी कनेक्ट होण्यासाठी MCP सर्व्हर नियमितपणे API कीज आणि OAuth ॲक्सेस टोकन्स यांसारखी क्रेडेन्शियल्स वापरतात. ही उघड झाल्यास किंवा त्यांचा गैरवापर झाल्यास, हल्लेखोरांना संवेदनशील डेटा आणि कार्यक्षमतेचा ॲक्सेस मिळू शकतो.

याचे एक उदाहरण म्हणजे टोकन पासथ्रू, ज्यात MCP सर्व्हर एखादे ॲक्सेस टोकन खरोखर प्राप्त करणाऱ्या सेवेसाठीच आहे याची पडताळणी न करता ते दुसऱ्या सेवेकडे पाठवतो. प्राप्त करणाऱ्या सेवेचे संरक्षण अपुरे असल्यास, यामुळे पुढे डेटा लीक होऊ शकतो.

क्रेडेन्शियल लीक्स आणि गैरवापरापासून संरक्षण कसे करावे

लीक झालेला डेटा दुर्भावनापूर्ण घटक कितपत वापरू शकतात, हे मर्यादित करण्यात अल्पकाळ टिकणारे, मर्यादित स्कोप असलेले टोकन्स आणि क्रेडेन्शियल रोटेशन प्रभावी ठरतात. API कीज आणि क्रेडेन्शियल्स नेहमी सीक्रेट मॅनेजर वापरून सुरक्षितपणे स्टोअर केली पाहिजेत.

धोका #6: कन्फ्यूज्ड डेप्युटी हल्ले

हल्लेखोर एखाद्या विश्वासार्ह ॲप्लिकेशनला फसवून, वैध वापरकर्त्याने अधिकृत न केलेली कृती करण्यासाठी त्याच्या परवानग्या वापरायला लावतो, तेव्हा कन्फ्यूज्ड-डेप्युटी हल्ला होतो. या प्रकरणात, MCP सर्व्हर हा डेप्युटी असतो.

विस्तृत करा

हल्लेखोर MCP सर्व्हरमधील एखाद्या त्रुटीचा (जसे की कमकुवत OAuth पडताळणी) फायदा घेऊन टूल कॉल किंवा डेटा पुनर्प्राप्ती यांसारखी दुर्भावनापूर्ण प्रक्रिया चालवतो.

कन्फ्यूज्ड डेप्युटी हल्ल्यांपासून संरक्षण कसे करावे

अधिकृतता पडताळणी, ज्यात प्रत्येक टूल कॉल विशिष्ट वापरकर्त्याचा आहे याची पडताळणी केली जाते, कन्फ्यूज्ड डेप्युटी हल्ले मर्यादित करण्यास मदत करते. याशिवाय, डेटा एक्सपोर्टसारख्या संवेदनशील कृतींसाठी स्पष्ट अधिकृतता आवश्यक असावी.

धोका #7: दुर्भावनापूर्ण सर्व्हर आणि तडजोड झालेल्या डिपेंडन्सीज

MCP सर्व्हरमध्ये दुर्भावनापूर्ण कोड असू शकतो (ते मूलतः बाह्य प्रोग्राम असतात) किंवा ते थर्ड-पार्टी लायब्ररींसारख्या तडजोड झालेल्या डिपेंडन्सीजवर अवलंबून असू शकतात. ही केवळ MCP ची विशिष्ट समस्या नसून सॉफ्टवेअर सप्लाय चेनची समस्या आहे.

हे घडण्याचा एक सोपा मार्ग म्हणजे हल्लेखोराने वैध वाटणारे इंटिग्रेशन वितरित करणे. एकदा सेट अप झाल्यानंतर, ते क्रेडेन्शियल्स चोरून पुन्हा वापरू शकते, संवेदनशील डेटा ॲक्सेस करू शकते आणि अनधिकृत ऑपरेशन्स चालवू शकते.

दुर्भावनापूर्ण सर्व्हर आणि तडजोड झालेल्या डिपेंडन्सीजपासून संरक्षण कसे करावे

MCP सर्व्हर फक्त विश्वासार्ह आणि तपासलेल्या स्रोतांकडूनच इंस्टॉल करा. शक्य असल्यास त्यांचा कोड तपासा, आणि बाहेरील डिपेंडन्सीज नेहमी तपासा. सर्व्हर नियमितपणे अपडेट आणि पॅच केले जातील याची खात्री करा.

धोका #8: सर्व्हर-साइड रिक्वेस्ट फोर्जरी (SSRF)

सर्व्हर-साइड रिक्वेस्ट फोर्जरी (SSRF) म्हणजे हल्लेखोराने MCP सर्व्हरला फसवून, वापरकर्त्याचा ॲक्सेस करण्याचा हेतू नसलेल्या अंतर्गत पत्त्यांवर नेटवर्क विनंत्या पाठवायला लावणे.

जेव्हा MCP सर्व्हर URL वरून माहिती मिळवणारे टूल उपलब्ध करून देतो, तेव्हा असे घडू शकते. हल्लेखोर URL पॅरामीटरवर प्रभाव टाकू शकल्यास, तो ते अंतर्गत API किंवा क्लाउड सेवेसारख्या त्याला हव्या असलेल्या नेटवर्क पत्त्यावर बदलू शकतो. यामुळे संवेदनशील डेटा मिळवला जाऊन तो संभाव्यतः ॲक्सेस करण्यायोग्य होऊ शकतो

सर्व्हर-साइड रिक्वेस्ट फोर्जरी (SSRF) पासून संरक्षण कसे करावे

MCP सर्व्हरनी नेहमी URL ची पडताळणी करावी, प्रतिबंधित अंतर्गत नेटवर्क पत्त्यांचा ॲक्सेस ब्लॉक करावा आणि आउटबाउंड नेटवर्क ॲक्सेस रोखावा. रीडायरेक्ट्सनीही याच प्रोटोकॉलचे पालन करावे.

धोका #9: सेशन हायजॅकिंग

सेशन हायजॅकिंगमध्ये हल्लेखोर MCP क्लायंट आणि सर्व्हर यांच्यातील सक्रिय कनेक्शनचा ताबा घेतो.

उदाहरणार्थ, ते अपुरी सुरक्षा असलेल्या MCP ॲप्लिकेशनमधून (उदा. होस्ट किंवा सर्व्हर) सेशन आयडेंटिफायर चोरू शकतात. MCP सर्व्हरने हा आयडेंटिफायर स्वीकारल्यास, हल्लेखोर संभाव्यतः वापरकर्त्याच्या वैध परवानग्यांसह टूल्स कॉल करू शकतो.

यापासून संरक्षण कसे करावे

MCP सिस्टिममधील सर्व ॲप्लिकेशन्समध्ये कठोर ओळख पडताळणी करून सेशन हायजॅकिंगचा धोका कमी करता येतो. सेशन आयडेंटिफायर्स उघड होऊ नयेत यासाठी MCP क्लायंट्स आणि रिमोट सर्व्हर यांच्यातील एन्क्रिप्शनही आवश्यक आहे.

धोका #10: मिक्स-अप हल्ले

मिक्स-अप हल्ल्यात, हल्लेखोर MCP क्लायंटला फसवून, क्लायंट आणि MCP सर्व्हर यांच्यामध्ये असलेल्या दुर्भावनापूर्ण ऑथोरायझेशन सर्व्हरकडे ऑथोरायझेशन कोड पाठवायला लावतो. ऑथोरायझेशन सर्व्हर हे असे ॲप्लिकेशन आहे, जे विनंती केलेला ॲक्सेस अधिकृत असल्याची तपासणी केल्यानंतर OAuth ॲक्सेस टोकन्स जारी करते.

विस्तृत करा

जर एखादा MCP होस्ट अनेक सेवांशी कनेक्ट होत असेल आणि प्रत्येक सेवा वेगळा ऑथरायझेशन सर्व्हर वापरत असेल, तर हल्लेखोर संभाव्यतः त्यापैकी एकावर नियंत्रण मिळवू शकतो (कदाचित दुर्भावनापूर्ण सेवा नोंदणी करून) आणि वैध सर्व्हरने जारी केलेला ऑथरायझेशन कोड क्लायंटला त्या दुर्भावनापूर्ण सर्व्हरकडे पाठवायला लावू शकतो. या गोंधळामुळे हल्लेखोराला अधिकृत ॲप्लिकेशनची तोतयेगिरी करून संरक्षित सेवांचा ॲक्सेस मिळवता येऊ शकतो.

मिक्स-अप हल्ल्यांपासून संरक्षण कसे करावे

MCP क्लायंट्सनी संपूर्ण OAuth प्रक्रियेदरम्यान ऑथोरायझेशन सर्व्हरच्या ओळखीची पडताळणी करावी. विशेषतः, त्यांनी सर्व्हरचा इश्युअर आयडेंटिफायर (iss) अपेक्षित ओळखीशी तपासावा आणि जुळत नसल्यास तो नाकारावा.

धोका #11: लोकल MCP सर्व्हरशी तडजोड

अनेक MCP सर्व्हर वापरकर्त्याच्या लोकल मशीनवर चालतात. वापरकर्ता सर्व्हर थर्ड पार्टीकडून इंस्टॉल करू शकतो किंवा स्वतः तयार करू शकतो. हल्लेखोर या लोकल MCP सर्व्हरशी तडजोड करू शकल्यास, त्याला संभाव्यतः लोकल सिस्टिमच्या मोठ्या भागाचा ॲक्सेस मिळू शकतो.

हल्लेखोर विविध मार्गांनी ॲक्सेस मिळवू शकतो. तो वैध इंटिग्रेशन असल्याचे भासवणारा दुर्भावनापूर्ण सर्व्हर वितरित करू शकतो, MCP होस्टचे कॉन्फिगरेशन अशा प्रकारे बदलू शकतो की तो दुर्भावनापूर्ण कमांड जारी करेल, किंवा अपुरी सुरक्षा नियंत्रणे असलेल्या वातावरणात चालणारा MCP सर्व्हर ॲक्सेस करू शकतो, उदाहरणार्थ DNS रीबाइंडिंगद्वारे, ज्यात ब्राउझरला फसवून localhost सेवेकडे विनंत्या पाठवायला लावले जाते.

लोकल MCP सर्व्हरशी तडजोड होण्यापासून संरक्षण कसे करावे

लोकल MCP सर्व्हर वापरताना सँडबॉक्सिंग आणि कठोर संमती प्रोटोकॉल महत्त्वाचे आहेत. MCP सर्व्हर फक्त विश्वासार्ह प्रदात्यांकडूनच इंस्टॉल केले जावेत, आणि ते कोणत्या डिरेक्टरीज ॲक्सेस करू शकतात यावर ऑपरेटिंग सिस्टिमच्या परवानग्यांनी निर्बंध घालावेत.

MCP मधील त्रुटी म्हणजे बहुतेकदा नव्या रूपातील जुनेच धोके

MCP मधील त्रुटी बहुतेकदा प्रस्थापित धोके आणि हल्ल्यांच्या पद्धतींच्या नव्या वापरांमधून निर्माण होतात. LLM, MCP सर्व्हर आणि बाह्य सेवांमधील परस्परसंवादांद्वारे या त्रुटींचा गैरफायदा घेण्याचे नवे मार्ग MCP हल्लेखोरांना उपलब्ध करून देते.

अर्थातच, MCP-विशिष्ट धोके अस्तित्वात आहेत. मात्र, हे लक्षात ठेवणे महत्त्वाचे आहे की कठोर अधिकृतता लागू करणे, विश्वासार्ह प्रदाते वापरणे आणि प्रॉम्प्ट इंजेक्शन्सपासून बचाव करणे यांसारखे मानक सुरक्षा प्रोटोकॉल कोणत्याही MCP अंमलबजावणीचे संरक्षण करण्यात मोठी भूमिका बजावतात.