MCP सुरक्षा: 95 प्रोडक्शन आउटेज के बाद मैंने क्या सीखा
मुझे लगा था कि सुरक्षा सरल है। डिपेंडेंसीज़ (dependencies) अपडेट करें। HTTPS का उपयोग करें। सीक्रेट्स (secrets) को हार्डकोड न करें।
मैं गलत था।
95 प्रोडक्शन आउटेज और 1,800 घंटों के विकास के बाद, मैंने सीखा कि Model Context Protocol (MCP) की सुरक्षा अलग है। यह मानक REST API सुरक्षा की तरह नहीं है।
MCP नए जोखिम पैदा करता है क्योंकि क्लाइंट एक LLM है, इंसान नहीं।
अपने MCP सर्वर को सुरक्षित रखने के लिए आपको ये बातें जाननी चाहिए।
1. MCP थ्रेट मॉडल (Threat Model)
REST में, आप जानते हैं कि आपकी API को कौन कॉल कर रहा है। MCP में, LLM एक मध्यस्थ (middleman) के रूप में कार्य करता है। यह सब कुछ बदल देता है:
- LLMs टूल कॉल या पैरामीटर्स के बारे में गलत जानकारी (hallucinate) दे सकते हैं।
- उपयोगकर्ता सीधे टूल को कॉल नहीं करते हैं। वे LLM से बात करते हैं, और LLM आपके सर्वर से बात करता है।
- दुर्भावनापूर्ण (malicious) क्लाइंट डिस्कवरी के दौरान आपके सर्वर में छिपे हुए टूल खोजने की कोशिश कर सकते हैं।
आपका सबसे बड़ा खतरा सिर्फ एक हैकर नहीं है। यह एक नेक इरादे वाला LLM है जो अनजाने में ऐसी गलती कर देता है जिससे आपका सिस्टम क्रैश हो जाता है।
2. API Key मैनेजमेंट
कई डेवलपर्स काम आसान करने के लिए क्वेरी पैरामीटर्स (query parameters) में API keys पास करते हैं। यह एक गलती है। क्वेरी पैरामीटर्स हर सर्वर लॉग और प्रॉक्सी में दिखाई देते हैं।
इन नियमों का पालन करें:
- हेडर ऑथेंटिकेशन (
Authorization: Bearer) का उपयोग करें। - JSON बॉडी में कीज़ (keys) पास करने से बचें।
- प्रत्येक क्लाइंट के लिए एक अलग API key जारी करें। इससे आपको उपयोग को ट्रैक करने और सब कुछ खराब किए बिना एक्सेस वापस लेने (revoke) में मदद मिलती है।
3. सख्त इनपुट वैलिडेशन (Strict Input Validation)
LLMs गलत अनुमान लगाएंगे। वे गलत प्रकार (types) और अतिरिक्त पैरामीटर्स भेजेंगे। आपको हर कॉल को वैलिडेट (validate) करना चाहिए:
- सबसे पहले जांचें कि टूल का नाम आपकी सूची में मौजूद है या नहीं।
- अतिरिक्त पैरामीटर्स वाले कॉल्स को रिजेक्ट करें। उन्हें केवल अनदेखा न करें।
- पैरामीटर प्रकारों (types) का सटीक मिलान करें। डेटा प्रकारों को जबरदस्ती न बदलें (do not coerce)।
- मेमोरी क्रैश को रोकने के लिए स्ट्रिंग्स और एरेज़ (arrays) पर सख्त आकार सीमाएं निर्धारित करें।
- डायरेक्टरी ट्रैवर्सल (directory traversal) को रोकने के लिए सभी फ़ाइल पाथ को सैनिटाइज़ (sanitize) करें।
4. लेयर्ड रेट लिमिटिंग (Layered Rate Limiting)
एक यूजर प्रॉम्प्ट एक साथ दस टूल कॉल ट्रिगर कर सकता है। यह कुछ ही सेकंड में आपके कनेक्शन पूल को खत्म कर सकता है।
रक्षा के तीन स्तरों का उपयोग करें:
- क्लाइंट के उपयोग को नियंत्रित करने के लिए प्रति-API-key सीमाएं।
- ब्रूट फ़ोर्स हमलों को रोकने के लिए प्रति-IP सीमाएं।
- अचानक बढ़े हुए लोड (bursts) के दौरान अपने सर्वर को चालू रखने के लिए समवर्ती कनेक्शन (concurrent connection) सीमाएं।
5. प्रॉम्प्ट इंजेक्शन जोखिम (Prompt Injection Risks)
एक उपयोगकर्ता LLM को किसी विनाशकारी टूल को कॉल करने के लिए चकमा दे सकता है। यदि कोई उपयोगकर्ता LLM को सभी नोट्स हटाने के लिए कहता है, तो LLM वास्तव में ऐसा कर सकता है।
खुद को सुरक्षित रखें:
- रीड (read) और राइट (write) ऑपरेशन्स को अलग रखें।
- किसी भी डिलीट या अपडेट एक्शन के लिए मैन्युअल यूजर कन्फर्मेशन की आवश्यकता रखें।
- अपने डेटाबेस यूजर के लिए 'प्रिंसिपल ऑफ लीस्ट प्रिविलेज' (principle of least privilege) का उपयोग करें।
सुरक्षा एक निरंतर चलने वाली प्रक्रिया है। बेहतर की मैनेजमेंट और सख्त वैलिडेशन के साथ शुरुआत करें। ये कदम अधिकांश समस्याओं को हल कर देते हैं।
वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi