MCP பாதுகாப்பு: 95 உற்பத்திச் சேவைகள் முடங்கிய பிறகு நான் கற்றுக்கொண்டவை
பாதுகாப்பு என்பது எளிமையானது என்று நான் நினைத்தேன். சார்புகளை (dependencies) புதுப்பிப்பது. HTTPS பயன்படுத்துவது. ரகசியத் தகவல்களை (secrets) நேரடியாகக் குறியீட்டில் (hardcode) சேர்க்காமல் இருப்பது.
நான் தவறாக நினைத்தேன்.
95 உற்பத்திச் சேவைகள் முடங்கிய பிறகு மற்றும் 1,800 மணிநேர மேம்பாட்டுப் பணிகளுக்குப் பிறகு, Model Context Protocol (MCP) பாதுகாப்பு என்பது வேறுபட்டது என்பதை நான் கற்றுக்கொண்டேன். இது சாதாரண REST API பாதுகாப்பைப் போன்றது அல்ல.
MCP புதிய அபாயங்களை உருவாக்குகிறது, ஏனெனில் இதில் கிளையண்ட் (client) ஒரு மனிதர் அல்ல, ஒரு LLM ஆகும்.
உங்கள் MCP சேவையகத்தை (server) பாதுகாப்பாக வைத்திருக்க நீங்கள் தெரிந்து கொள்ள வேண்டியவை இதோ.
1. MCP அச்சுறுத்தல் மாதிரி (The MCP Threat Model)
REST-இல், உங்கள் API-ஐ அழைப்பவர் யார் என்பதை நீங்கள் துல்லியமாகத் தெரிந்து கொள்ளலாம். ஆனால் MCP-இல், LLM ஒரு இடைத்தரகராகச் செயல்படுகிறது. இது அனைத்தையும் மாற்றுகிறது:
- LLM-கள் கருவி அழைப்புகள் (tool calls) அல்லது அளவுருக்களை (parameters) தவறாகக் கற்பனை செய்து அழைக்கலாம் (hallucinate).
- பயனர்கள் கருவிகளை நேரடியாக அழைப்பதில்லை. அவர்கள் LLM-உடன் பேசுகிறார்கள், LLM உங்கள் சேவையகத்துடன் பேசுகிறது.
- தீய நோக்கமுள்ள கிளையண்ட்கள், கண்டறியும் (discovery) போது உங்கள் சேவையகத்தில் மறைந்திருக்கும் கருவிகளைத் தேடிப் பார்க்கக்கூடும்.
உங்கள் மிகப்பெரிய அச்சுறுத்தல் ஒரு ஹேக்கர் மட்டுமல்ல. உங்கள் அமைப்பை முடக்கும் வகையில், ஒரு நற்புள்ளி கொண்ட LLM செய்யும் தற்செயலான தவறுதான் அது.
2. API Key மேலாண்மை
பல மேம்பாட்டாளர்கள் விஷயங்களை எளிதாக்க API சாவிகளை (keys) query parameters மூலம் அனுப்புகிறார்கள். இது ஒரு தவறு. Query parameters ஒவ்வொரு சேவையகப் பதிவிலும் (server log) மற்றும் proxy-களிலும் தோன்றும்.
இந்த விதிகளைப் பின்பற்றவும்:
- header அங்கீகாரத்தைப் (authentication) பயன்படுத்தவும் (
Authorization: Bearer). - JSON body-இல் சாவிகளை அனுப்புவதைத் தவிர்க்கவும்.
- ஒவ்வொரு கிளையண்டிற்கும் ஒரு தனி API சாவியை வழங்கவும். இது பயன்பாட்டைக் கண்காணிக்கவும், அனைத்தையும் பாதிக்காமல் அணுகலை ரத்து செய்யவும் உதவும்.
3. கடுமையான உள்ளீட்டுச் சரிபார்ப்பு (Strict Input Validation)
LLM-கள் தவறாகக் கணிக்கக்கூடும். அவை தவறான வகைகளையும் (types) கூடுதல் அளவுருக்களையும் (parameters) அனுப்பும். நீங்கள் ஒவ்வொரு அழைப்பையும் சரிபார்க்க வேண்டும்:
- முதலில் கருவியின் பெயர் உங்கள் பட்டியலில் உள்ளதா என்று சரிபார்க்கவும்.
- கூடுதல் அளவுருக்கள் கொண்ட அழைப்புகளை நிராகரிக்கவும். அவற்றை அப்படியே விட்டுவிடாதீர்கள்.
- அளவுரு வகைகளை (parameter types) துல்லியமாகப் பொருத்தவும். தரவு வகைகளை (data types) வலுக்கட்டாயமாக மாற்ற வேண்டாம் (coerce).
- நினைவக முடக்கங்களைத் (memory crashes) தவிர்க்க, strings மற்றும் arrays-களுக்குக் கடுமையான அளவு வரம்புகளை நிர்ணயிக்கவும்.
- directory traversal-ஐத் தவிர்க்க அனைத்து கோப்புப் பாதைகளையும் (file paths) தூய்மைப்படுத்தவும் (sanitize).
4. அடுக்குமுறை விகிதக் கட்டுப்பாடு (Layered Rate Limiting)
ஒரு பயனர் தூண்டுதல் (prompt) ஒரே நேரத்தில் பத்து கருவி அழைப்புகளைத் தூண்டக்கூடும். இது சில நொடிகளில் உங்கள் இணைப்புத் தொகுப்பை (connection pool) தீர்த்துவிடும்.
மூன்று அடுக்கு பாதுகாப்பைப் பயன்படுத்தவும்:
- கிளையண்ட் பயன்பாட்டைக் கட்டுப்படுத்த API-key வாரியான வரம்புகள்.
- brute force தாக்குதல்களைத் தடுக்க IP வாரியான வரம்புகள்.
- திடீர் அதிகரிப்பின் போது உங்கள் சேவையகம் இயங்கிக் கொண்டிருக்க ஒரே நேரத்தில் இணைக்கும் வரம்புகள் (Concurrent connection limits).
5. Prompt Injection அபாயங்கள்
ஒரு பயனர் ஒரு அழிவை ஏற்படுத்தும் கருவியை அழைக்க LLM-ஐ ஏமாற்ற முடியும். ஒரு பயனர் அனைத்து குறிப்புகளையும் நீக்குமாறு LLM-இடம் கூறினால், LLM அதைச் செய்துவிடக்கூடும்.
உங்களைப் பாதுகாத்துக் கொள்ள:
- வாசித்தல் (read) மற்றும் எழுதுதல் (write) செயல்பாடுகளைத் தனித்தனியாகப் பிரிக்கவும்.
- எந்தவொரு நீக்குதல் அல்லது புதுப்பித்தல் நடவடிக்கைக்கும் பயனரின் நேரடி உறுதிப்படுத்தலைத் தேவைப்படுத்தவும்.
- உங்கள் தரவுத்தளப் பயனருக்கு (database user) குறைந்தபட்ச அதிகாரக் கொள்கையைப் (principle of least privilege) பயன்படுத்தவும்.
பாதுகாப்பு என்பது ஒரு தொடர்ச்சியான செயல்முறை. சிறந்த சாவிக் மேலாண்மை மற்றும் கடுமையான சரிபார்ப்புடன் தொடங்குங்கள். இந்த நடவடிக்கைகள் பெரும்பாலான சிக்கல்களைத் தீர்க்கும்.
Optional learning community: https://t.me/GyaanSetuAi