ශ්‍රී ලංකාවේ නවතම තාක්ෂණික පුවත් 2026-07-28, Tuesday
💻 ක්‍රමලේඛනය · 🕒 කියවීමට විනාඩි 2 · 👁 1

MCP සේවාදායකයේ එකම ප්‍රොසෙස් එකේ API යතුරු දෙක – ආරක්ෂක අවදානම සහ විසඳුම

MCP සේවාදායකයේ එකම ප්‍රොසෙස් එකේ API යතුරු දෙක – ආරක්ෂක අවදානම සහ විසඳුම

මේ සතියේ Dev.to වෙතින් කියවූ ලිපියක, තිදෙනෙකු MCP සේවාදායකයන් එකම ඒජන්තය සමඟ සම්බන්ධ කර, නිෂ්පාදන පරිසරයට සමාන ප්‍රවේශයක් ඉල්ලා සිටින ආකාරය දැක්වූ විට, බොහෝ අය "MCP හි ප්‍රධාන ගැටලුව මෙන්න" කියා පවසනවා. මටත් ඒක මතකයි – මම ත්‍රිත්ව සේවාදායකයක් නොදුවා, එකක් පමණක් ධාවනය කරමි.

කියවලා බැලූ පසු, server.py ෆයිලය විවෘත කරද්දී, ඒ එක සේවාදායකය තුළද ඒම ගැටලුව ඇති බව ඇගැයුමක් ලැබුණා. මේ FastMCP සේවාදායකය 8 ක්‍රියාකාරකම් (tools) දෙකක් වෙනස් ව්‍යාපෘති වලින් – GitHub පිරික්සුම්/රෙපොස් කියවීම, DEV.to ලිපි ලිවීම සහ කියවීම – එකට එකතු කර තිබුණා. .env ගොනුවේ තිබෙන GITHUB_TOKEN සහ DEV_TO_API යතුරු, ආයාත (import) වේලාවේම os.environ තුළ දාගෙන, ඒම ප්‍රොසෙස් එකේ සෑම function එකකටම ලැබෙනවා.

උදාහරණයක් ලෙස, _gh function එක GitHub API කටයුතු සඳහා Authorization: token ශීර්ෂකය භාවිතා කරන අතර, _dev function එක DEV.to API සඳහා api-key ශීර්ෂකය භාවිතා කරනවා. මෙහි වැරැද්ද යනු, මෙවැනි යතුරු “tool‑level” එකකට සීමා නොවී, **ප්‍රොසෙස් පරිසරය** තුළ සෑම tool එකකටම ලැබෙමින් ඇති බවයි.

ඒ නිසා, GitHub token එකක් අවශ්‍ය නොවන tool එකක් (උදා: generate_commit_message) පවා, අනාගතයේදී කේතයේ වෙනසක් හෝ දෝෂයක් හේතුවෙන් DEV.to API යතුරට ප්‍රවේශ වීමට ඉඩ ඇති. මෙය ත්‍රිත්ව MCP සේවාදායකයක් සමඟ එකම ඒජන්තය භාවිතා කරන විට ඇති “සංයුක්ත විශ්වාස සීමාව” (shared trust boundary) සමඟ සමානයි – නමුත් එක ෆයිලයක් තුළ ඇති බැවින්, ගැටලුව අඩු තරම් පෙනෙයි.

මෙම ගැටලුවේ ප්‍රායෝගික වැදගත්කම, tool‑වලට ඇතුළත් කරන දත්ත සෑම විටම විශ්වාසදායක නොවේ. update_article වැනි function එක අහඹු අංකයක් සහ අහඹු පෙළ (LLM‑එකෙන් සාරාංශ කරන ලද තොරතුරු, scrape කරන ලද ලිපි) ලබා ගත හැක. එම තොරතුරු විශ්වාසදායක නොවේ නම්, අනිසි API යතුරු භාවිතා කරමින් අනවශ්‍ය ක්‍රියා සිදු විය හැක.

ශ්‍රී ලංකාවට ඇති වැදගත්කම

ශ්‍රී ලංකාවේ තරුණ සංවර්ධකයින්ට, මෙම අවදානම තේරුම් ගැනීම මූලික සයිබර් ආරක්ෂක අධ්‍යාපනයක් වේ. එක් ප්‍රොසෙස් එකේ බහු API යතුරු රැඳීම, දේශීය startups සහ ව්‍යාපාරිකයන්ගේ සේවාදායක ආරක්ෂාව අඩු කරයි. මෙය නිවැරදිව විසඳීමෙන්:

  • API යතුරු වෙන වෙනම ප්‍රොසෙස් වලට වෙන් කර, අනවශ්‍ය ප්‍රවේශය අවහිර කරයි.
  • කේත පිරික්සුම් හා CI/CD පද්ධති තුළ ආරක්ෂක පරීක්ෂණයන් සරල කරයි.
  • දෙවැනි පාර්ශව API භාවිතයේ දෝෂ හෝ නඩුවකින් පසු පාරිභෝගික දත්ත ආරක්ෂා කරයි.

ඒ නිසා, ශ්‍රී ලංකාවේ තාක්ෂණික පරිසරයට මනා ආරක්ෂක පළපුරුදුකමක් ගොඩ නැගීමට මෙය හොඳ අවස්ථාවක්.

ප්‍රතිකාරය සරලයි: API යතුරු පරිසරය අනුව සේවාදායකය දෙකට (github_server.py, dev_server.py) වෙන් කර, එක් එක් ප්‍රොසෙස් එකට ඒම යතුරු පමණක් පූරණය කිරීම. මෙය වැඩි සම්පත් අවශ්‍ය කරනවා වුවත්, ආරක්ෂාව වැඩි කරන ප්‍රධාන පියවරයි.

අවසන් වශයෙන්, ඔබේ MCP සේවාදායකය එකම ප්‍රොසෙස් එකේ බහු API යතුරු රැඳවන්නේ නම්, එය ඉක්මනින් වෙන් කර, ආරක්ෂක “process boundary” නවතා ගන්න. එය ඔබේ පද්ධතියේ අනාගතය සඳහා විශ්වාසදායක පදනමක් වේ.

💡 ඔබේ සේවාදායකයේ ආරක්ෂාව අදම බලන්න!
මූලාශ්‍රය මෙම ලිපිය AI මගින් රචිත මුල් සාරාංශයකි. සම්පූර්ණ වාර්තාව කියවන්න:
Dev.to ↗
#MCP #API #Security #Python #DevOps