MCP ಭದ್ರತೆ: 95 ಪ್ರೊಡಕ್ಷನ್ ಔಟ್ವೇಜ್ಗಳ ನಂತರ ನಾನು ಕಲಿತದ್ದು
ಭದ್ರತೆ ಎಂಬುದು ಸರಳ ಎಂದು ನಾನು ಭಾವಿಸಿದ್ದೆ. dependencies ಅಪ್ಡೇಟ್ ಮಾಡುವುದು. HTTPS ಬಳಸುವುದು. secrets ಅನ್ನು hardcode ಮಾಡದಿರುವುದು.
ನಾನು ತಪ್ಪು ಮಾಡಿದ್ದೆ.
95 ಪ್ರೊಡಕ್ಷನ್ ಔಟ್ವೇಜ್ಗಳು ಮತ್ತು 1,800 ಗಂಟೆಗಳ ಅಭಿವೃದ್ಧಿಯ ನಂತರ, Model Context Protocol (MCP) ಭದ್ರತೆಯು ವಿಭಿನ್ನವಾಗಿದೆ ಎಂದು ನಾನು ಕಲಿತೆ. ಇದು ಸಾಮಾನ್ಯ REST API ಭದ್ರತೆಯಂತೆಯಲ್ಲ.
MCP ಹೊಸ ಅಪಾಯಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ (client) ಒಬ್ಬ ಮನುಷ್ಯನಲ್ಲ, ಬದಲಾಗಿ ಒಂದು LLM ಆಗಿದೆ.
ನಿಮ್ಮ MCP ಸರ್ವರ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿಡಲು ನೀವು ತಿಳಿದುಕೊಳ್ಳಲೇಬೇಕಾದ ವಿಷಯಗಳು ಇಲ್ಲಿವೆ.
1. MCP ಬೆದರಿಕೆಯ ಮಾದರಿ (The MCP Threat Model)
REST ನಲ್ಲಿ, ನಿಮ್ಮ API ಅನ್ನು ಯಾರು ಕರೆಯುತ್ತಿದ್ದಾರೆ ಎಂಬುದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿರುತ್ತದೆ. MCP ನಲ್ಲಿ, LLM ಮಧ್ಯವರ್ತಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಎಲ್ಲವನ್ನೂ ಬದಲಾಯಿಸುತ್ತದೆ:
- LLMಗಳು tool calls ಅಥವಾ parameters ಅನ್ನು ತಪ್ಪಾಗಿ ಕಲ್ಪಿಸಿಕೊಳ್ಳಬಹುದು (hallucinate).
- ಬಳಕೆದಾರರು tools ಅನ್ನು ನೇರವಾಗಿ ಕರೆಯುವುದಿಲ್ಲ. ಅವರು LLM ಜೊತೆ ಮಾತನಾಡುತ್ತಾರೆ ಮತ್ತು LLM ನಿಮ್ಮ ಸರ್ವರ್ ಜೊತೆ ಮಾತನಾಡುತ್ತದೆ.
- ದುರುದ್ದೇಶಪೂರಿತ ಕ್ಲೈಂಟ್ಗಳು discovery ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಸರ್ವರ್ನಲ್ಲಿ ಅಡಗಿರುವ tools ಪತ್ತೆಹಚ್ಚಲು ಪ್ರಯತ್ನಿಸಬಹುದು.
ನಿಮ್ಮ ದೊಡ್ಡ ಬೆದರಿಕೆ ಕೇವಲ ಹ್ಯಾಕರ್ ಮಾತ್ರವಲ್ಲ. ಅದು ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಕುಸಿಯುವಂತೆ ಮಾಡುವ ಅಚಾತುರ್ಯದಿಂದ ಮಾಡಿದ ತಪ್ಪು ಮಾಡುವ ಸದ್ಭಾವನೆಯುಳ್ಳ LLM ಕೂಡ ಹೌದು.
2. API Key ನಿರ್ವಹಣೆ (Api Key Management)
ಅನೇಕ ಡೆವಲಪರ್ಗಳು ಕೆಲಸವನ್ನು ಸುಲಭಗೊಳಿಸಲು query parameters ಮೂಲಕ API keys ಅನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. ಇದು ತಪ್ಪು. Query parameters ಪ್ರತಿ ಸರ್ವರ್ ಲಾಗ್ ಮತ್ತು proxy ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ.
ಈ ನಿಯಮಗಳನ್ನು ಪಾಲಿಸಿ:
- header authentication (Authorization: Bearer) ಬಳಸಿ.
- JSON body ನಲ್ಲಿ keys ಕಳುಹಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ.
- ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ವಿಭಿನ್ನ API key ನೀಡಿ. ಇದು ಬಳಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಹಾಳು ಮಾಡದೆ ಪ್ರವೇಶವನ್ನು ರದ್ದುಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
3. ಕಟ್ಟುನಿಟ್ಟಿನ ಇನ್ಪುಟ್ ವ್ಯಾಲಿಡೇಶನ್ (Strict Input Validation)
LLMಗಳು ತಪ್ಪಾಗಿ ಊಹಿಸಬಹುದು. ಅವು ತಪ್ಪು ಪ್ರಕಾರದ (types) ಮತ್ತು ಹೆಚ್ಚುವರಿ parametersಗಳನ್ನು ಕಳುಹಿಸಬಹುದು. ನೀವು ಪ್ರತಿಯೊಂದು ಕರೆಯನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಲೇಬೇಕು:
- ಮೊದಲು tool ಹೆಸರು ನಿಮ್ಮ ಪಟ್ಟಿಯಲ್ಲಿ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
- ಹೆಚ್ಚುವರಿ parameters ಇರುವ ಕರೆಯನ್ನು ತಿರಸ್ಕರಿಸಿ. ಅವುಗಳನ್ನು ಕೇವಲ ನಿರ್ಲಕ್ಷಿಸಬೇಡಿ.
- parameter types ಅನ್ನು ನಿಖರವಾಗಿ ಹೊಂದಿಸಿ. data types ಅನ್ನು ಬಲವಂತವಾಗಿ ಬದಲಾಯಿಸಬೇಡಿ (coerce).
- ಮೆಮೊರಿ ಕ್ರ್ಯಾಶ್ ಆಗುವುದನ್ನು ತಡೆಯಲು strings ಮತ್ತು arrays ಮೇಲೆ ಕಟ್ಟುನಿಟ್ಟಿನ ಗಾತ್ರದ ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ.
- directory traversal ತಡೆಯಲು ಎಲ್ಲಾ file paths ಅನ್ನು sanitize ಮಾಡಿ.
4. ಪದರವಾದ ರೇಟ್ ಲಿಮಿಟಿಂಗ್ (Layered Rate Limiting)
ಒಂದು ಬಳಕೆದಾರರ ಪ್ರಾಂಪ್ಟ್ (prompt) ಏಕಕಾಲದಲ್ಲಿ ಹತ್ತು tool calls ಅನ್ನು ಪ್ರಚೋದಿಸಬಹುದು. ಇದು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ನಿಮ್ಮ connection pool ಅನ್ನು ಖಾಲಿ ಮಾಡಬಹುದು.
ರಕ್ಷಣೆಯ ಮೂರು ಪದರಗಳನ್ನು ಬಳಸಿ:
- ಕ್ಲೈಂಟ್ ಬಳಕೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಪ್ರತಿ-API-key ಮಿತಿಗಳು.
- brute force ದಾಳಿಗಳನ್ನು ತಡೆಯಲು ಪ್ರತಿ-IP ಮಿತಿಗಳು.
- ಹೆಚ್ಚಿನ ಒತ್ತಡದ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಸರ್ವರ್ ಕಾರ್ಯನಿರ್ಿಯುವಂತೆ ಮಾಡಲು concurrent connection ಮಿತಿಗಳು.
5. ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಅಪಾಯಗಳು (Prompt Injection Risks)
ಬಳಕೆದಾರರು LLM ಅನ್ನು ವಂಚಿಸಿ ವಿನಾಶಕಾರಿ tool ಅನ್ನು ಕರೆಯುವಂತೆ ಮಾಡಬಹುದು. ಬಳಕೆದಾರರು ಎಲ್ಲಾ ನೋಟ್ಸ್ಗಳನ್ನು ಅಳಿಸಲು LLM ಗೆ ಹೇಳಿದರೆ, LLM ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಮಾಡಬಹುದು.
ನಿಮ್ಮನ್ನು ನೀವು ರಕ್ಷಿಸಿಕೊಳ್ಳಿ:
- read ಮತ್ತು write ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ.
- ಯಾವುದೇ ಅಳಿಸುವಿಕೆ (delete) ಅಥವಾ ಅಪ್ಡೇಟ್ ಕ್ರಿಯೆಗೆ ಬಳಕೆದಾರರ ಮ್ಯಾನುಯಲ್ ಕನ್ಫರ್ಮೇಶನ್ ಅಗತ್ಯವಿರಲಿ.
- ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಬಳಕೆದಾರರಿಗೆ 'least privilege' ತತ್ವವನ್ನು ಬಳಸಿ.
ಭದ್ರತೆಯು ನಿರಂತರ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ಉತ್ತಮ ಕೀ ನಿರ್ವಹಣೆ ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಿನ ವ್ಯಾಲಿಡೇಶನ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ. ಈ ಹಂತಗಳು ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ.
Optional learning community: https://t.me/GyaanSetuAi