MCP സുരക്ഷ: 95 പ്രൊഡക്ഷൻ ഔട്ട്ഏജുകൾക്ക് ശേഷം ഞാൻ പഠിച്ച കാര്യങ്ങൾ
സുരക്ഷ ലളിതമാണെന്നാണ് ഞാൻ കരുതിയത്. ഡിപെൻഡൻസികൾ (dependencies) അപ്ഡേറ്റ് ചെയ്യുക. HTTPS ഉപയോഗിക്കുക. സീക്രട്ടുകൾ (secrets) ഹാർഡ്കോഡ് ചെയ്യാതിരിക്കുക.
ഞാൻ തെറ്റായിരുന്നു.
95 പ്രൊഡക്ഷൻ ഔട്ട്ഏജുകൾക്കും 1,800 മണിക്കൂർ വികസന പ്രവർത്തനങ്ങൾക്കും ശേഷം, Model Context Protocol (MCP) സുരക്ഷ വ്യത്യസ്തമാണെന്ന് ഞാൻ മനസ്സിലാക്കി. ഇത് സാധാരണ REST API സുരക്ഷ പോലെയല്ല.
ക്ലയന്റ് ഒരു മനുഷ്യനല്ല, മറിച്ച് ഒരു LLM ആയതുകൊണ്ട് MCP പുതിയ അപകടസാധ്യതകൾ സൃഷ്ടിക്കുന്നു.
നിങ്ങളുടെ MCP സെർവർ സുരക്ഷിതമായി സൂക്ഷിക്കാൻ നിങ്ങൾ അറിഞ്ഞിരിക്കേണ്ട കാര്യങ്ങൾ ഇതാ.
- MCP Threat Model
REST-ൽ, നിങ്ങളുടെ API വിളിക്കുന്നത് ആരാണെന്ന് നിങ്ങൾക്ക് കൃത്യമായി അറിയാം. എന്നാൽ MCP-യിൽ, LLM ഒരു ഇടനിലക്കാരനായി പ്രവർത്തിക്കുന്നു. ഇത് എല്ലാം മാറ്റുന്നു:
- LLM-കൾക്ക് ടൂൾ കോളുകളോ (tool calls) പാരാമീറ്ററുകളോ തെറ്റായി നിർമ്മിക്കാൻ (hallucinate) സാധ്യതയുണ്ട്.
- ഉപയോക്താക്കൾ നേരിട്ട് ടൂളുകൾ വിളിക്കുന്നില്ല. അവർ LLM-നോട് സംസാരിക്കുന്നു, LLM നിങ്ങളുടെ സെർവറുമായി സംസാരിക്കുന്നു.
- ദുരുദ്ദേശ്യപരമായ ക്ലയന്റുകൾ ഡിസ്കവറി സമയത്ത് നിങ്ങളുടെ സെർവറിലെ മറഞ്ഞിരിക്കുന്ന ടൂളുകൾക്കായി തിരയാൻ സാധ്യതയുണ്ട്.
നിങ്ങളുടെ ഏറ്റവും വലിയ ഭീഷണി ഒരു ഹാക്കർ മാത്രമല്ല. നിങ്ങളുടെ സിസ്റ്റം തകരാറിലാക്കുന്ന തരത്തിലുള്ള അബദ്ധങ്ങൾ അറിയാതെ ചെയ്യുന്ന ഒരു നല്ല ഉദ്ദേശ്യമുള്ള LLM കൂടിയാണ്.
- API Key മാനേജ്മെന്റ്
കാര്യങ്ങൾ എളുപ്പമാക്കാൻ പല ഡെവലപ്പർമാരും ക്വറി പാരാമീറ്ററുകളിൽ (query parameters) API കീകൾ നൽകുന്നു. ഇത് ഒരു തെറ്റാണ്. ക്വറി പാരാമീറ്ററുകൾ എല്ലാ സെർവർ ലോഗുകളിലും പ്രോക്സിയിലും കാണപ്പെടും.
ഈ നിയമങ്ങൾ പാലിക്കുക:
- ഹെഡർ ഓതന്റിക്കേഷൻ (Authorization: Bearer) ഉപയോഗിക്കുക.
- JSON ബോഡിയിൽ കീകൾ നൽകുന്നത് ഒഴിവാക്കുക.
- ഓരോ ക്ലയന്റിനും വ്യത്യസ്തമായ API കീ നൽകുക. ഇത് ഉപയോഗം ട്രാക്ക് ചെയ്യാനും എല്ലാം തകരാതെ തന്നെ ആക്സസ് റദ്ദാക്കാനും നിങ്ങളെ സഹായിക്കും.
- കർശനമായ ഇൻപുട്ട് വാലിഡേഷൻ (Strict Input Validation)
LLM-കൾ തെറ്റായ ഊഹങ്ങൾ നടത്തും. അവ തെറ്റായ ടൈപ്പുകളും അധിക പാരാമീറ്ററുകളും അയച്ചേക്കാം. നിങ്ങൾ ഓരോ കോളും പരിശോധിക്കണം (validate):
- ആദ്യം ടൂൾ പേര് നിങ്ങളുടെ ലിസ്റ്റിൽ ഉണ്ടോ എന്ന് പരിശോധിക്കുക.
- അധിക പാരാമീറ്ററുകളുള്ള കോളുകൾ നിരസിക്കുക. അവ അവഗണിക്കരുത് മാത്രം പോരാ.
- പാരാമീറ്റർ ടൈപ്പുകൾ കൃത്യമായി പൊരുത്തപ്പെടുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. ഡാറ്റാ ടൈപ്പുകൾ നിർബന്ധപൂർവ്വം മാറ്റാൻ ശ്രമിക്കരുത് (Do not coerce).
- മെമ്മറി ക്രാഷുകൾ ഒഴിവാക്കാൻ സ്ട്രിംഗുകൾക്കും (strings) അറേകൾക്കും (arrays) കർശനമായ സൈസ് പരിധികൾ നിശ്ചയിക്കുക.
- ഡയറക്ടറി ട്രാവേഴ്സൽ (directory traversal) തടയാൻ എല്ലാ ഫയൽ പാത്തുകളും സാനിറ്റൈസ് (sanitize) ചെയ്യുക.
- ലെയറുകളായുള്ള റേറ്റ് ലിമിറ്റിംഗ് (Layered Rate Limiting)
ഒരു യൂസർ പ്രോംപ്റ്റ് ഒരേസമയം പത്ത് ടൂൾ കോളുകൾക്ക് കാരണമായേക്കാം. ഇത് നിമിഷങ്ങൾക്കുള്ളിൽ നിങ്ങളുടെ കണക്ഷൻ പൂൾ (connection pool) തീർന്നുപോകാൻ കാരണമാകും.
മൂന്ന് പാളികളായുള്ള പ്രതിരോധം ഉപയോഗിക്കുക:
- ക്ലയന്റ് ഉപയോഗം നിയന്ത്രിക്കാൻ ഓരോ API കീയ്ക്കും പരിധികൾ നിശ്ചയിക്കുക.
- ബ്രൂട്ട് ഫോഴ്സ് ആക്രമണങ്ങൾ തടയാൻ ഓരോ IP-യ്ക്കും പരിധികൾ നിശ്ചയിക്കുക.
- പെട്ടെന്നുണ്ടാകുന്ന തിരക്കുകളിൽ സെർവർ പ്രവർത്തനക്ഷമമായിരിക്കാൻ കൺകറന്റ് കണക്ഷൻ പരിധികൾ (concurrent connection limits) നിശ്ചയിക്കുക.
- പ്രോംപ്റ്റ് ഇൻജക്ഷൻ അപകടസാധ്യതകൾ (Prompt Injection Risks)
ഒരു ഉപയോക്താവിന് ഒരു LLM-നെ വഞ്ചിച്ചുകൊണ്ട് നാശമുണ്ടാക്കുന്ന ഒരു ടൂൾ പ്രവർത്തിപ്പിക്കാൻ സാധിക്കും. എല്ലാ കുറിപ്പുകളും (notes) ഡിലീറ്റ് ചെയ്യാൻ ഒരു ഉപയോക്താവ് LLM-നോട് പറഞ്ഞാൽ, LLM അത് ചെയ്തേക്കാം.
സ്വയം സംരക്ഷിക്കുക:
- റീഡ് (read), റൈറ്റ് (write) പ്രവർത്തനങ്ങൾ വേർതിരിക്കുക.
- ഡിലീറ്റ് അല്ലെങ്കിൽ അപ്ഡേറ്റ് ചെയ്യുന്ന ഏതൊരു പ്രവർത്തനത്തിനും ഉപയോക്താവിന്റെ നേരിട്ടുള്ള സ്ഥിരീകരണം ആവശ്യമാക്കുക.
- നിങ്ങളുടെ ഡാറ്റാബേസ് യൂസർക്ക് 'പ്രിൻസിപ്പിൾ ഓഫ് ലീസ്റ്റ് പ്രിവിലേജ്' (principle of least privilege) ഉപയോഗിക്കുക.
സുരക്ഷ എന്നത് തുടർച്ചയായ ഒരു പ്രക്രിയയാണ്. മികച്ച കീ മാനേജ്മെന്റിലൂടെയും കർശനമായ വാലിഡേഷനിലൂടെയും തുടങ്ങുക. ഈ ഘട്ടങ്ങൾ മിക്ക പ്രശ്നങ്ങളും പരിഹരിക്കും.
ഓപ്ഷണൽ ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi