MCP सर्वर और क्लाइंट को सुरक्षित (हार्डन) करना
मॉडल कॉन्टेक्स्ट प्रोटोकॉल (MCP) एजेंट्स में टूल्स जोड़ना बहुत आसान बना देता है। यही आसानी सबसे बड़ा जोखिम भी है। यहाँ बताया गया है कि अपनी कंपनी का डेटा लीक किए बिना MCP को सुरक्षित रूप से कैसे चलाएँ।
60 सेकंड में
MCP सर्वर और क्लाइंट को सुरक्षित (हार्डन) करना
मॉडल कॉन्टेक्स्ट प्रोटोकॉल (MCP) एजेंट्स में टूल्स जोड़ना बहुत आसान बना देता है। यही आसानी सबसे बड़ा जोखिम भी है। यहाँ बताया गया है कि अपनी कंपनी का डेटा लीक किए बिना MCP को…
दो बहुत अलग तरह के सर्वर
| लोकल सर्वर | रिमोट सर्वर | |
|---|---|---|
| यह कहाँ चलता है | यूज़र की अपनी मशीन पर, जिसे होस्ट ऐप द्वारा शुरू किया जाता है | किसी नेटवर्क सर्विस पर, जहाँ HTTP के ज़रिए पहुँचा जाता है |
| किसके अधिकार (राइट्स) | यूज़र के तौर पर चलता है: अक्सर उनकी फ़ाइलें, कीज़ (keys) और ब्राउज़र डेटा पढ़ सकता है | इसके पास वही अधिकार होते हैं जो इसके ऑपरेटर ने इसे दिए हों |
| मुख्य जोखिम | एक दुर्भावनापूर्ण (malicious) या बग से भरा सर्वर यूज़र के पूरे लोकल एक्सेस के साथ काम करता है | कमज़ोर या नदारद ऑथेंटिकेशन; कई यूज़र्स को सर्विस देने वाला एक ही सर्वर उनके बीच डेटा लीक कर सकता है |
| मुख्य सुरक्षा नियंत्रण (कंट्रोल्स) | केवल अनुमति सूची (allow-list) में शामिल सर्वर ही इंस्टॉल करें; जहाँ संभव हो, कंटेनर या सैंडबॉक्स में चलाएँ | मजबूत ऑथेंटिकेशन और प्रति-यूज़र ऑथराइज़ेशन; TLS; लॉगिंग |
रिमोट सर्वर: ऑथेंटिकेट और ऑथराइज़ करें
- हर रिमोट सर्वर के लिए ऑथेंटिकेशन अनिवार्य करें। किसी इंटरनल MCP सर्वर को कभी भी नेटवर्क पर खुला न छोड़ें कि "यह तो सिर्फ इंटरनल है"।
- MCP स्पेसिफिकेशन OAuth पर आधारित एक ऑथराइज़ेशन का तरीका बताता है। इसका या अपनी कंपनी के स्टैंडर्ड आइडेंटिटी सिस्टम का इस्तेमाल करें, ताकि हर रिक्वेस्ट के साथ किसी असली यूज़र या एजेंट की पहचान जुड़ी हो।
- प्रति-यूज़र, प्रति-टूल ऑथराइज़ करें: कई यूज़र्स को सर्विस देने वाले सर्वर को यह जांचना चाहिए कि यह यूज़र क्या देख सकता है, न कि केवल यह कि कॉल करने वाला एक मान्य क्लाइंट है या नहीं।
- किसी यूज़र के टोकन को सीधे अन्य बैक-एंड सर्विसेज़ तक न भेजें। उस खास सर्विस के लिए बना टोकन ही हासिल करें (डेलिगेटेड एक्सेस वाला पाठ देखें)।
कंपनी-व्यापी MCP नीति (पॉलिसी)
- 1
अनुमति-सूची (Allow-list)
केवल मंज़ूर की गई सूची के सर्वर ही इस्तेमाल किए जा सकते हैं। बाकी सभी को होस्ट के कॉन्फ़िगरेशन में ब्लॉक कर दें, जहाँ टूल अनुमति दे वहाँ इसे सेंट्रली मैनेज करें। - 2
वर्ज़न पिन करें
किसी खास वर्ज़न (और जहाँ संभव हो उसके हैश) को मंज़ूरी दें, न कि "latest" को। अपडेट्स का रिव्यू होना चाहिए। - 3
न्यूनतम-विशेषाधिकार (लीस्ट-प्रिविलेज) टूल्स
उन टूल्स को बंद कर दें जिनकी टीम को ज़रूरत नहीं है। केवल पढ़ने (रीड-ओनली) वाले काम के लिए रीड-ओनली सर्वर ही दें। - 4
इनपुट की पुष्टि (Validate) करें
हर टूल अपने तर्कों (arguments) की जांच वैसे ही करे जैसे कोई पब्लिक API करता है: डेटा टाइप्स, लंबाई, स्वीकार्य वैल्यूज़, और मंज़ूर किए गए फ़ोल्डर्स के अंदर के पाथ। - 5
लॉग रखें
एजेंट, यूज़र, आर्ग्युमेंट्स और नतीजों के सारांश के साथ हर टूल कॉल को रिकॉर्ड करें, और इसे अपने सेंट्रल लॉग्स में भेजें।
{
"server": "internal-tickets",
"transport": "https",
"url": "https://mcp.tickets.internal.example/",
"version": "2.3.1",
"sha256": "<hash of the approved package or image>",
"owner": "IT Service Desk platform team",
"auth": "company SSO, per-user tokens",
"allowed_tools": ["search_tickets", "get_ticket", "add_comment"],
"blocked_tools": ["delete_ticket", "change_assignee_bulk"],
"data_class": "internal",
"review_due": "next quarter"
}इनपुट वैलिडेशन अभी भी ज़रूरी है
../ पाथ स्वीकार करता है, एक क्वेरी टूल जो SQL को जोड़ता (कनकेटिनेट करता) है। अब इनपुट भेजने वाला मॉडल है, और मॉडल को हमलावर द्वारा भटकाया जा सकता है। इनपुट की पुष्टि ऐसे करें जैसे हर आर्ग्युमेंट इंटरनेट से आया हो, क्योंकि परोक्ष रूप से वह वहीं से आया है।from pathlib import Path
ALLOWED_ROOT = Path("/srv/agent-docs").resolve()
def read_doc(relative_path: str) -> str:
target = (ALLOWED_ROOT / relative_path).resolve()
# Refuse anything that escapes the allowed folder (e.g. "../../etc/passwd")
if not target.is_relative_to(ALLOWED_ROOT):
raise PermissionError("path outside allowed folder")
if target.suffix not in {".md", ".txt"}:
raise PermissionError("file type not allowed")
return target.read_text(encoding="utf-8")[:20_000] # cap sizePath.is_relative_to के लिए Python 3.9 या उसके बाद का वर्ज़न चाहिए। यही विचार किसी भी भाषा पर लागू होता है: पहले पूरा पाथ पता करें (resolve करें), फिर जांचें कि यह मंज़ूर किए गए फ़ोल्डर के अंदर है या नहीं।और देखें और पढ़ें
लैब
तीन MCP सर्वर के लिए एक सुरक्षित अनुमति-सूची (allow-list) और एक सुधरा हुआ, सुरक्षित फ़ाइल टूल।
समस्या
भाग A: आपकी टीम तीन MCP सर्वर का इस्तेमाल करती है: एक लोकल "filesystem" सर्वर, एक रिमोट इंटरनल "tickets" सर्वर, और एक कम्युनिटी "web search" सर्वर। प्रत्येक के लिए एक अनुमति-सूची (allow-list) एंट्री लिखें (पाठ के फ़ॉर्मेट का उपयोग करें): ओनर, वर्ज़न, ट्रांसपोर्ट, ऑथेंटिकेशन, मंज़ूर और ब्लॉक किए गए टूल्स, डेटा क्लास। लोकल सर्वर के लिए, यह दो सीमाएँ लिखें कि वह किन फ़ोल्डर्स तक पहुँच सकता है।
भाग B: अपनी मशीन पर स्टार्टर कोड सेव करें, कुछ टेक्स्ट फ़ाइलों के साथ एक टेस्ट फ़ोल्डर बनाएँ, और इसे चलाएँ। फिर फ़ंक्शन को इस तरह ठीक करें कि नीचे दिए गए टेस्ट पास हो जाएँ। केवल टेस्ट फ़ाइलों का ही उपयोग करें।
प्रैक्टिस लैब
कोड में बदलाव करें और इसे रन करें। Python आपके ब्राउज़र में चलता है — हमारे सर्वर पर कुछ नहीं भेजा जाता।
कोई आउटपुट नहीं। वैल्यूज़ देखने के लिए print(...) जोड़ें।
आपका काम तब पूरा होगा जब
कठिन सवाल
उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।
Q1"/etc/hosts" जैसा ऐब्सोल्यूट पाथ फ़ोल्डर से बाहर कैसे निकल सकता है, भले ही आपने इसे ALLOWED_ROOT के साथ जोड़ा हो?दिखाएं
Python के pathlib में, किसी बेस पाथ को ऐब्सोल्यूट पाथ से जोड़ने पर बेस पाथ हट जाता है: Path("/srv/docs") / "/etc/hosts" बन जाता है /etc/hosts। यही कारण है कि आपको अंतिम पाथ को पहले resolve करना चाहिए और फिर जांचना चाहिए कि यह रूट के अंदर है, न कि यह मान लेना चाहिए कि जोड़ने से आप अंदर ही रहेंगे।
Q2कम्युनिटी वेब सर्च सर्वर भरोसेमंद और अच्छी तरह से लिखा गया है। फिर भी इसे अन्य चीज़ों के साथ जोड़ने पर सीमाएँ क्यों तय की जानी चाहिए?दिखाएं
क्योंकि यह एजेंट के कॉन्टेक्स्ट में अविश्वसनीय सामग्री (वेब पेज) लाता है। यदि उसी एजेंट के पास प्राइवेट डेटा और डेटा बाहर भेजने का साधन भी है, तो यह लेथल ट्राइफ़ेक्टा बन जाता है, भले ही हर सर्वर अपने आप में ईमानदार क्यों न हो। अनुमति-सूची (Allow-listing) का संबंध इनके मेल (कॉम्बिनेशन) से है, सिर्फ हर एक सर्वर से नहीं।
अक्सर पूछे जाने वाले सवाल
क्या MCP अपने आप में असुरक्षित है?
किसी भी प्लग-इन सिस्टम से ज़्यादा नहीं। यह प्रोटोकॉल चीज़ों को आपस में जोड़ता है; जोखिम इस बात से आता है कि आप किन सर्वर्स पर भरोसा करते हैं, वे किन अधिकारों के साथ चलते हैं, और उनके टूल्स कैसे लिखे गए हैं। अच्छी नीतियाँ और अच्छा सर्वर कोड इसे सुरक्षित बना सकते हैं।
क्या हम सभी लोकल सर्वर को बस कंटेनर में नहीं चला सकते?
इससे बहुत मदद मिलती है: एक कंटेनर यह सीमित कर सकता है कि सर्वर किन फ़ाइलों और नेटवर्कों तक पहुँच सकता है। लेकिन यह ऐसे सर्वर को ठीक नहीं कर सकता जिसे अपने कानूनी टूल के ज़रिए आपका डेटा बाहर भेजने के लिए ही डिज़ाइन किया गया हो। आपको अभी भी अनुमति-सूची (allow-listing) और रिव्यू की ज़रूरत होगी।
इंटरनल MCP सर्वर का मालिक (owner) किसे होना चाहिए?
उस टीम को, जिसके सिस्टम को यह सर्वर रैप करता है, जबकि प्लेटफ़ॉर्म टीम साझा स्टैंडर्ड (ऑथेंटिकेशन, लॉगिंग, वर्ज़न तय करना) बनाएगी। जिस सर्वर का कोई मालिक नहीं होगा, उसे सिक्योरिटी फ़िक्स नहीं मिलेंगे।
क्या हमें टूल के नतीजों को भी लॉग करने की ज़रूरत है?
जांच-पड़ताल के लिए ज़रूरी जानकारी ही लॉग करें: टूल का नाम, आर्ग्युमेंट्स, किसने किया, कब किया, सफलता या विफलता, और नतीजों का एक सारांश या हैश। पूरे नतीजों में संवेदनशील डेटा हो सकता है, इसलिए उन्हें केवल वहीं स्टोर करें जहाँ आपके डेटा नियम अनुमति देते हैं।
पाठ का टेस्ट
5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।