एमसीपी सर्वर सुरक्षा: इंस्टॉल करने से पहले टूल्स की जांच करें

एमसीपी सर्वर को इंस्टॉल करना तुच्छ लगता है: एक कमांड या यूआरएल पेस्ट करें, क्लाइंट को रीस्टार्ट करें, और आपके एजेंट के कॉन्टेक्स्ट में एक नया टूल दिखाई देता है। लेकिन उस टूल नाम के पीछे एक्सीक्यूटेबल कोड, मॉडल के कॉन्टेक्स्ट विंडो में इंजेक्ट किया गया स्कीमा, क्रेडेंशियल्स और वह सब कुछ बैठा है जो वे क्रेडेंशियल्स तक पहुँच सकते हैं। एमसीपी इकोसिस्टम अभी भी विकसित हो रहा है, और नए सर्वर्स के लिए वेटिंग प्रक्रिया बेहद पतली है। यह पोस्ट आपको एक दोबारा उपयोगी प्री-इंस्टॉल चेकलिस्ट देती है जो एक निर्दिष्ट उदाहरण पर लागू की गई है, साथ ही हर स्टेप के लिए निष्कर्ष और एक सादी स्वीकृति/अस्वीकृति तर्क।

इंस्टॉलेशन वास्तव में क्या अनुदान देता है

जब आप एमसीपी सर्वर को इंस्टॉल करते हैं, तो आप निष्क्रिय लाइब्रेरी इंस्टॉल नहीं कर रहे हैं। आप अपने टूल्स, फाइलसिस्टम और आमतौर पर आपकी एपीआई कीज़ तक एक्सीक्यूटेबल कोड एक्सेस दे रहे हैं, बिना किसी मध्यवर्ती समीक्षा स्टेप के जो अधिकांश क्लाइंट्स आपको सामने लाते हैं।

वह विश्वास संचयी और गैर-दानेदार है। प्लूटो सिक्योरिटी के प्रैक्टिशनर गाइड के अनुसार, एमसीपी सर्वर को मंजूर करने का मतलब इसकी सप्लाई चेन में हर ऑपरेटर को मंजूर करना है। कोई भी प्रति-घटक री-प्रॉम्प्ट नहीं है। हर सक्षम एमसीपी सर्वर अपनी पूरी टूल लिस्ट को सेशन शुरुआत में मॉडल के कॉन्टेक्स्ट में डालता है, टोकन जलाता है और ध्यान को पतला करता है। तो आप दो बार भुगतान करते हैं: एक बार सुरक्षा सतह में, एक बार कॉन्टेक्स्ट बजट में।

Claude Code में विशेष रूप से, सर्वर्स को .mcp.json (प्रोजेक्ट-स्कोप्ड) या ~/.claude.json (यूजर-स्कोप्ड) के माध्यम से कॉन्फ़िगर किया जाता है, और एक प्लगइन डायरेक्टरी के अंदर बंडल किया जा सकता है जिसमें हुक्स, एजेंट्स, मॉनिटर्स और bin/ स्क्रिप्ट्स भी होती हैं। एक प्लगइन एक पतला रैपर नहीं है। यह आपके शेल सेशन तक जो कुछ पहुँचता है वह सब कुछ तक पहुँच सकता है।

खतरे के मॉडल के तीन यथार्थवादी विफलता मोड हैं:

• एक दुर्भावनापूर्ण प्रकाशक एक समान दिखने वाला सर्वर बनाता है जो रजिस्ट्री में प्रकट होता है, एपीआई कॉल्स को रीडायरेक्ट करता है, या चुप-चाप डेटा निकालता है।
• एक सद्भावी लेकिन अनुभवहीन लेखक एक सर्वर शिप करता है जो टोकन्स को सादे टेक्स्ट में स्टोर करता है या रिक्वेस्ट बॉडीज़ को सोचे समझे बिना लॉग करता है।
• एक वैध सर्वर जो आपने अनुमोदित किया था अपडेट हो जाता है, और नया संस्करण एक बैकडोर पेश करता है या बिना आपको फिर से प्रॉम्प्ट किए अपनी अनुमतियों को चौड़ा करता है।

सभी तीनों वाइल्ड में प्रलेखित हैं, काल्पनिक नहीं।

सोर्स, प्रोवेनेंस और अपडेट बिहेवियर की समीक्षा करें

कोड की एक भी लाइन पढ़ने से पहले शुरू करें। इस सर्वर को किसने पब्लिश किया? क्या पैकेज के पीछे एक सत्यापन योग्य पहचान है? क्या रिपोजिटरी में एक सार्थक कमिट हिस्ट्री है, या क्या यह पिछले हफ्ते एक कमिट के साथ बनाई गई थी?

क्रिश्चियन श्नाइडर के डिफेंस-फर्स्ट आर्किटेक्चर गाइड सप्लाई चेन हाइजीन आवश्यकताओं को स्पष्ट करते हैं: केवल प्रतिष्ठित स्रोतों से सर्वर्स इंस्टॉल करें, पैकेज सिग्नेचर्स या हैशेज़ को सत्यापित करें, और डिपेंडेंसी संस्करणों को पिन करें न कि "नवीनतम" को स्वीकार करें। npm audit या pip-audit को पैकेज के विरुद्ध चलाएँ इससे पहले कि यह आपके वातावरण को छुए। एक सॉफ्टवेयर बिल ऑफ मेटेरियल्स (एसबीओएम) जेनरेट करें ताकि आप हर डिपेंडेंसी को ट्रेस कर सकें और जब कोई सीवीई ड्रॉप हो तो तेजी से जवाब दे सकें।

अपनी समीक्षा चेकलिस्ट के लिए, सोर्स स्टेज में ये कैप्चर करें:

1. पुष्टि करें कि प्रकाशक पहचान एक ज्ञात संगठन या व्यक्तिगत ट्रैक रिकॉर्ड वाले व्यक्ति से जुड़ी है।
2. रिपोजिटरी निर्माण तारीख और कमिट फ्रीक्वेंसी जाँचें। वन-कमिट रिपोज़ को अतिरिक्त जाँच की आवश्यकता है।
3. जिस सटीक संस्करण की समीक्षा की है, उसे पिन करें। कमिट हैश या रिलीज़ टैग नोट करें।
4. npm audit या pip-audit को निर्भरता पेड़ पर चलाएँ और निष्कर्ष रिकॉर्ड करें।
5. जाँचें कि क्या सर्वर का अपडेट तंत्र परिवर्तन लागू करने से पहले डिजिटल हस्ताक्षर सत्यापित करता है।

उदाहरणार्थ: मान लीजिए आप एक काल्पनिक mcp-db-connector@1.4.2 की समीक्षा कर रहे हैं जो 18 महीने के कमिट इतिहास, दो योगदानकर्ता, और GitHub पर एक हस्ताक्षरित रिलीज़ वाले प्रकाशक से है। npm audit शून्य उच्च-गंभीरता निष्कर्ष लौटाता है। यह इस चरण को पास करता है। एक सर्वर जिसका एक अनाम प्रकाशक है, दो दिन पुराना रिपॉजिटरी है, और कोई हस्ताक्षरित रिलीज़ नहीं है, वह नहीं होगा।

उपकरण, हुक, स्क्रिप्ट और नेटवर्क एक्सेस की जाँच करें।

स्रोत मूल बातें हैं। अब इसे पढ़ें।

सर्वर जो हर उपकरण परिभाषा पंजीकृत करता है, उसे देखें। क्या बताया गया विवरण वास्तविक कार्यान्वयन से मेल खाता है? जैसा कि Towards Data Science की MCP गाइड चेतावनी देती है, सिर्फ इसलिए कि कुछ "ईमेल-भेजने वाले" के रूप में प्रकाशित है इसका मतलब यह नहीं है कि यह केवल ईमेल भेजता है। यह उन्हें लॉग कर सकता है, उन्हें फिर से लिख सकता है, या उन्हें कहीं अन्यत्र भेज सकता है जहाँ आप चाहते नहीं हैं।

इन विशेषताओं की जाँच करें:

• हुक और जीवनचक्र स्क्रिप्ट: क्या hooks.json पूर्व- या उत्तर-उपकरण कॉलबैक पंजीकृत करता है? वे क्या करते हैं?
• `bin/` स्क्रिप्ट: क्या कोई शेल स्क्रिप्ट इंस्टॉलेशन पर या आह्वान पर निष्पादित होती है? उन्हें पढ़ें।
• आउटबाउंड नेटवर्क कॉल: क्या सर्वर किसी ऐसे एंडपॉइंट को "फोन" करता है जो README में प्रलेखित नहीं है? पूरे स्रोत में grep -r "fetch\|axios\|http\|https\|request" का उपयोग करें।
• फ़ाइल सिस्टम एक्सेस: क्या यह कार्य के लिए आवश्यक से व्यापक पथ एक्सेस का अनुरोध करता है?
• क्रेडेंशियल हैंडलिंग: क्या API कुंजियाँ डिस्क पर लिखी जाती हैं, लॉग की जाती हैं, या घोषित लक्ष्य सेवा के बाहर कहीं प्रेषित होती हैं?

SlowMist MCP Security Checklist इनपुट सत्यापन, API दर सीमाबद्धता, और आउटपुट एन्कोडिंग को तीन सर्वोच्च-प्राथमिकता नियंत्रण के रूप में दर्जा देती है। यदि सर्वर अपने स्वयं के इनपुट को कठोरता से मान्य नहीं करता है, तो यह इंजेक्शन हमलों के लिए एक वेक्टर है चाहे आप प्रकाशक पर भरोसा करें या नहीं।

एक बात जो चेकलिस्ट झंडा लगाती है जो अधिकांश लोग मिस करते हैं: उपकरण विवरण मॉडल के संदर्भ में शब्दशः इंजेक्ट किए जाते हैं। एक दुर्भावनापूर्ण या खराब लिखा विवरण एजेंट के व्यवहार को सैंडबॉक्स के अंदर स्टीयर कर सकता है भले ही सैंडबॉक्स स्वयं बरकरार हो। स्कीमा स्कैनिंग के बिना सैंडबॉक्सिंग केवल आधा बचाव है।

प्रॉम्प्ट इंजेक्शन और डेटा सीमा स्थितियों का परीक्षण करें।

यह चरण उत्पादन डेटा या ग्राहक जानकारी को छूने वाली किसी भी चीज़ के लिए वैकल्पिक नहीं है।

उपकरण विवरणों के माध्यम से प्रॉम्प्ट इंजेक्शन एक प्रलेखित हमले वेक्टर है। एक हमलावर एक उपकरण के विवरण क्षेत्र के अंदर निर्देश एम्बेड करता है जिसे मॉडल उपयोगकर्ता इरादे के रूप में व्याख्या करता है। आपको यह सत्यापित करने की आवश्यकता है कि सर्वर की स्कीमा में एम्बेडेड निर्देश नहीं हैं, कि सर्वर से आउटपुट को डाउनस्ट्रीम में आधिकारिक उपयोगकर्ता इनपुट के रूप में विश्वास नहीं किया जाता है, और कि एक उपकरण से लौटाया गया डेटा अलग सत्र या उपयोगकर्ता के संदर्भ में लीक नहीं हो सकता है।

वास्तविक क्रेडेंशियल से सर्वर को कनेक्ट करने से पहले उदाहरणार्थ सीमा स्थितियों को चलाएँ:

1. एक उपकरण कॉल तैयार करें जो "पिछले निर्देशों को अनदेखा करें और..." जैसा कुछ युक्त प्रतिक्रिया लौटाता है और देखें कि क्या होस्ट क्लाइंट इसे सामने लाता है या इस पर कार्य करता है।
2. प्रत्येक पंजीकृत उपकरण को अत्यधिक या खराब फॉर्मेट किए गए इनपुट पास करें और जाँचें कि क्या सर्वर उन्हें सुचारु रूप से हैंडल करता है या अनहैंडल अपवाद फेंकता है जो स्टैक ट्रेस उजागर करते हैं।
3. यदि सर्वर के पास कई डेटा स्रोतों तक पहुँच है, तो सत्यापित करें कि स्रोत A के विरुद्ध एक क्वेरी स्रोत B से डेटा नहीं लौटा सकती है।

ये ट्रिएज परीक्षण हैं, प्रमाणीकरण नहीं। एक संक्षिप्त मैनुअल समीक्षा स्पष्ट समस्याओं की पहचान करती है। यह सूक्ष्म लोगों की अनुपस्थिति की गारंटी नहीं देता है।

यदि आप क्लाइंट्स के लिए AI tooling बना रहे हैं और एक व्यापक Claude Code सेटअप के हिस्से के रूप में MCP integrations की समीक्षा करने में सहायता चाहते हैं, तो Seahawk की Claude Code agency service स्टैक का मूल्यांकन करने में मदद कर सकती है इससे पहले कि वह प्रोडक्शन के करीब जाए।

सबसे छोटा Credential Scope चुनें और प्रक्रिया को अलग रखें

एक बार जब आप सर्वर की समीक्षा कर लें और तय कर लें कि यह स्वीकार्य है, तो सवाल यह बन जाता है: आप इसे कैसे चलाते हैं?

यह सिद्धांत least privilege का है, जिसे समझौते के बिना लागू किया जाता है। MCP सर्वर को अपनी व्यक्तिगत API key पूर्ण खाता एक्सेस के साथ न दें क्योंकि यह सुविधाजनक है। एक scoped credential बनाएं जिसमें केवल वह न्यूनतम अनुमतियाँ हों जो दस्तावेज़ित कार्यक्षमता को आवश्यकता है। यदि सर्वर को एक ही S3 bucket में read access की जरूरत है, तो credential के पास write access नहीं होना चाहिए, बस इतना ही।

अलगाव विकल्प, मोटे तौर पर बढ़ती लागत में:

• सर्वर को एक समर्पित subprocess में चलाएं जिसके पास parent shell के environment variables तक कोई एक्सेस नहीं है सिवाय उन चीजों के जो आप स्पष्ट रूप से pass करते हैं।
• एक restricted network policy वाले container का उपयोग करें ताकि सर्वर मनमानी outbound connections न बना सके।
• संवेदनशील deployments के लिए, deployment gates के रूप में supply chain checks लागू करें और MCP सर्वर अपडेट्स को application code के समान ही change-management प्रक्रिया के साथ treat करें।

General Analysis threat model इसे अच्छी तरह रखता है: vetted marketplace बिना version pinning के मतलब कि आज का vetted सर्वर कल का rug pull है। अलगाव और pinning redundant नहीं हैं। वे विभिन्न failure modes से सुरक्षा देते हैं। Sandboxing blast radius को contain करता है; pinning silent drift को रोकता है।

यह भी ध्यान देने लायक है: MCP सर्वर्स के बीच credentials share न करें। Token passthrough और shared API keys मतलब कि एक सर्वर में compromise उन सब चीजों तक पहुंचता है जिन्हें credential touch करता है।

निर्णय को रिकॉर्ड करें और हर बदलाव पर दोबारा समीक्षा करें

एक समीक्षा जिसे आप रिकॉर्ड नहीं करते वह एक समीक्षा है जो आपके भविष्य के self या आपकी टीम के दृष्टिकोण से कभी हुई ही नहीं।

प्रत्येक सर्वर के लिए जो आप install करते हैं, एक decision log maintain रखें जिसमें कम से कम ये शामिल हों:

• समीक्षा किया गया सटीक version (package version साथ ही commit hash या release tag)।
• समीक्षा की तारीख।
• किसने समीक्षा की।
• audit tools और manual inspection से findings।
• स्वीकार/अस्वीकार करने का कारण।
• ऐसी शर्तें जो re-review को trigger करेंगी (उदाहरण के लिए, कोई भी नया major version, tool schema में कोई भी बदलाव, कोई भी security advisory जो किसी dependency को छू रहा हो)।

यह अपने लिए bureaucracy नहीं है। Schneider की architecture guide एक सीधा सवाल उठाती है जिसका जवाब अधिकतर टीमें नहीं दे सकतीं: "क्या होगा यदि MCP सर्वर का tool description उपयोगकर्ता द्वारा अनुमोदन के बाद बदल जाए? क्या किसी को पता चलेगा?" अधिकतर default setups में, जवाब न है। Version pinning साथ ही decision log यह है कि आप उस जवाब को कैसे बदलते हैं।

pinned सर्वर्स को quarterly में re-review करने के लिए एक calendar reminder सेट करें भले ही कोई नया release न हो, क्योंकि उनके चारों ओर का threat environment बदलता है भले ही code न बदले।

उन टीमों के लिए जो पहले से ही MCP सर्वर्स को production stacks में चला रही हैं, आपके मौजूदा tooling के साथ कई सर्वर्स को manage करने के चारों ओर के operational considerations को हमारे production stack post में अलग से cover किया गया है।

पुनः उपयोग योग्य प्री-इंस्टॉल चेकलिस्ट: स्वीकार/अस्वीकार करने का कारण

नीचे ट्रिएज क्रम में पूरी चेकलिस्ट दी गई है। किसी भी सर्वर को इंस्टॉल करने से पहले इसे लागू करें। उदाहरण निष्कर्ष केवल उदाहरणार्थ हैं; आपके परिणाम अलग होंगे।

पंक्ति 6 ही है कि आप ऐसा क्यों करते हैं। एक अनुल्लेखित विश्लेषण पिंग स्वचालित रूप से दुर्भावनापूर्ण नहीं है, लेकिन यह अनुल्लेखित है, और अनुल्लेखित आउटबाउंड कॉल तब तक अस्वीकृति मानदंड हैं जब तक समझाया न जाए। आप प्रकाशक से पूछते हैं, स्पष्ट उत्तर पाते हैं, वास्तव में जो भेजा जाता है उसकी समीक्षा करते हैं, और फिर एक नया निर्णय लेते हैं। यह प्रक्रिया है।

FAQ

क्या स्रोत कोड की समीक्षा यह गारंटी देती है कि सर्वर स्थापित करना सुरक्षित है?

नहीं। कोड समीक्षा छंटाई है, प्रमाणीकरण नहीं। यह स्पष्ट समस्याओं की संभावना को कम करता है: अनुल्लेखित नेटवर्क कॉल, क्रेडेंशियल लॉगिंग, दुर्भावनापूर्ण उपकरण विवरण। यह भविष्य के अपडेट में पेश की गई असुरक्षाओं से रक्षा नहीं करता (यही कारण है कि आप संस्करण पिन करते हैं और परिवर्तन पर पुनः-समीक्षा करते हैं) या सूक्ष्म तर्क में खामियों के विरुद्ध जो गहन सुरक्षा विश्लेषण को सतह पर लाने की आवश्यकता है।

उपकरण विषाक्तता क्या है और इसका MCP से क्या संबंध है?

उपकरण विषाक्तता का मतलब है कि एक हमलावर एक उपकरण के नाम या विवरण क्षेत्र के अंदर दुर्भावनापूर्ण निर्देश एम्बेड करता है। क्योंकि MCP उपकरण स्कीमा को शाब्दिक रूप से मॉडल के संदर्भ में इंजेक्ट किया जाता है, मॉडल उन निर्देशों को वैध निर्दिशन के रूप में व्याख्या कर सकता है। स्थापना से पहले स्कीमा की समीक्षा करना और एम्बेडेड निर्देश खंडों के लिए जांच करना पूर्व-स्थापना चरण पर प्राथमिक शमन है।

क्या मुझे स्थानीय MCP सर्वर की तुलना में दूरस्थ से अलग तरीके से समीक्षा करनी चाहिए?

स्थानीय सर्वर के पास संवेदनशील डेटा का छोटा रास्ता होता है क्योंकि वे आपकी मशीन पर सीधे आपके वातावरण तक पहुंच के साथ चलते हैं। दूरस्थ सर्वर नेटवर्क हमले की सतह और आदमी-बीच-में जोखिम का परिचय देते हैं। दोनों को एक ही चेकलिस्ट की आवश्यकता होती है, लेकिन स्थानीय सर्वर फाइलसिस्टम एक्सेस स्कोप और स्रोत कोड में क्रेडेंशियल हैंडलिंग पर विशेष ध्यान देते हैं, जबकि दूरस्थ सर्वर सत्यापित TLS, हस्ताक्षर सत्यापन, और वर्तमान MCP विशिष्टता के अनुसार OAuth 2.1 अनुपालन की आवश्यकता होती है।

मैं उन MCP सर्वर को कैसे संभालूं जो बंद-स्रोत हैं या बाइनरी के रूप में वितरित किए जाते हैं?

यदि आप स्रोत नहीं पढ़ सकते, तो आप पूरी तरह से प्रकाशक प्रतिष्ठा, क्रिप्टोग्राफिक हस्ताक्षर सत्यापन, और रनटाइम नियंत्रण (सैंडबॉक्सिंग, नेटवर्क नीति, स्कोप्ड क्रेडेंशियल) पर निर्भर हैं। यह भौतिक रूप से उच्च-जोखिम वाली मुद्रा है। उत्पादन डेटा या ग्राहक जानकारी को छूने वाली किसी भी चीज़ के लिए, एक ज्ञात प्रकाशक से सत्यापन योग्य हस्ताक्षर के बिना एक बंद-स्रोत बाइनरी डिफ़ॉल्ट रूप से अस्वीकृति होनी चाहिए।

SBOM क्या है और क्या मुझे वास्तव में MCP सर्वर के लिए एक की आवश्यकता है?

SBOM (सॉफ़्टवेयर सामग्री की बिल) एक मशीन-पठनीय इन्वेंटरी है जो एक पैकेज में शामिल हर निर्भरता का है। MCP सर्वर के लिए, यह आपको यह पहचानने देता है कि क्या किसी भी संक्रामक निर्भरता में एक प्रकटीकृत CVE है, भले ही शीर्ष-स्तर पैकेज स्वयं स्वच्छ दिखता है। कम-दांव व्यक्तिगत उपकरण के लिए, यह वैकल्पिक ओवरहेड है। संवेदनशील डेटा को संभालने वाली उत्पादन परिनियोजन के लिए, यह आपके जोखिम को जानने और इसे अनुमान लगाने के बीच का अंतर है।

इस पूरी समीक्षा से सबसे तीव्र सावधानी: एक उपकरण विवरण जो रजिस्ट्री में सौम्य दिखता है, स्थापना के बाद एजेंट व्यवहार को दुर्भावनापूर्ण निष्पादक योग्य कोड के रूप में प्रभावी तरीके से निर्देशित कर सकता है, और अधिकांश ग्राहक आपको चेतावनी नहीं देंगे। README नहीं, स्कीमा पढ़ें।