உங்கள் .env கோப்புகளில் AWS access keys-களைப் பதிவிடுவதை நிறுத்துங்கள்.
நாம் அனைவரும் அந்தச் சூழ்நிலையை அனுபவித்திருக்கிறோம். நேரம் நள்ளிரவு, நீங்கள் ஒரு Lambda permission பிழையைத் திருத்த முயல்கிறீர்கள் (debugging), அப்போது உங்கள் AI உதவியாளர் கற்பனையான account IDs உடன் சேவைப் பெயர்களையோ அல்லது ARNs-ஐயோ உருவாக்கிக் கொண்டே இருக்கிறது. மாதிரி (model) கற்பனையான தகவல்களைத் தருவதை (hallucinating) நிறுத்திவிட்டு, உண்மையான தீர்வுகளைத் தர, அது உங்கள் உண்மையான ஆதாரங்களைக் (resources) காண வேண்டும் என்று நீங்கள் விரும்புகிறீர்கள். கடைசி முயற்சியாக, நீங்கள் ஒரு access key-ஐ எடுத்து, அதை ஒரு environment file-இல் போட்டு, ஏஜென்ட்டுக்கு (agent) வழங்குகிறீர்கள். அது வேலை செய்கிறது. உங்களுக்கு நிம்மதி கிடைக்கிறது. பிறகு காலை வருகிறது, அந்த ரகசியத் தகவல் (secret) உங்கள் shell history, terminal scrollback அல்லது மிக மோசமாக, பகிரப்பட்ட ஒரு repository-க்கு நீங்கள் vừa push செய்த commit-இல் இருக்கிறது என்பதை உணர்கிறீர்கள்.
Model Context Protocol இந்தச் சிக்கலைத் தடுக்கவே உருவாக்கப்பட்டது.
MCP உங்கள் AI ஏஜென்ட்டிற்கும் வெளிப்புற அமைப்புகளுக்கும் இடையே ஒரு நிலையான பாலத்தை உருவாக்குகிறது. வெறும் credentials-களைக் கொடுத்து, ஏஜென்ட் அவற்றை கசியவிடாமல் (leak) இருக்க praying செய்வதற்குப் பதிலாக, அங்கீகாரம் (authentication) மற்றும் அனுமதிகளை (permissions) கையாளும், உங்கள் keys-களை chat window-லிருந்து முற்றிலும் விலக்கி வைக்கும் ஒரு கட்டுப்படுத்தப்பட்ட சர்வர் (controlled server) மூலம் நீங்கள் இணைக்கலாம்.
AWS-க்கு, தற்போது நீங்கள் தேர்ந்தெடுக்க இரண்டு அதிகாரப்பூர்வ MCP சர்வர்கள் உள்ளன. தவறான ஒன்றைத் தேர்ந்தெடுப்பது உங்கள் ஏஜென்ட்டைத் தெரியாத நிலைக்குத் தள்ளலாம் அல்லது மிகக் குறைந்த கண்காணிப்புடன் அதிக அனுமதிகளை வழங்கலாம்.
வித்தியாசத்தைப் புரிந்துகொள்ளுங்கள்: Knowledge vs. Hands
முதல் விருப்பம் AWS Knowledge MCP Server. இதை முழு AWS ஆவண நூலகத்தையும் (documentation library) மனப்பாடம் செய்த ஒரு மூத்த பொறியாளர் (senior engineer) என்று நினைத்துக் கொள்ளுங்கள், ஆனால் உங்கள் கணக்கிற்கான login credentials அவரிடம் இல்லை. இது வடிவமைப்பிலேயே 'read-only' முறையில் உள்ளது, ஏஜென்ட் உண்மையான API syntax, சரியான சேவைப் பெயர்கள் மற்றும் தற்போதைய சிறந்த நடைமுறைகளை (best practices) அறிந்துகொள்ள அதிகாரப்பூர்வ AWS ஆவணங்களை இது மேற்கோள் காட்டுகிறது.
இதைப் பயன்படுத்த உங்களுக்கு AWS கணக்கு தேவையில்லை. இதை உங்கள் உள்கட்டமைப்போடு (infrastructure) இணைக்க வேண்டிய அவசியமில்லை. நீங்கள் ஒரு architecture diagram-ஐ உருவாக்கும்போதோ, ECS அல்லது EventBridge போன்ற புதிய சேவைகளைக் கற்கும்போது அல்லது ஒரு குறிப்பிட்ட API call இன்னும் நீங்கள் நினைவில் வைத்திருப்பதைப் போலவே செயல்படுகிறதா என்பதைச் சரிபார்க்கும்போது இதைப் பயன்படுத்தலாம். இது ஏஜென்ட் யூகங்களைச் செய்வதைத் தடுக்கிறது. நீங்கள் ஒரு S3 bucket policy-க்கான Terraform-ஐ எழுதச் சொன்னால், அது கடந்த ஆண்டுடன் முடிந்துபோன பயிற்சித் தரவிலிருந்து (training data) எடுக்காமல், மூலத் தரவிலிருந்து (source) எடுப்பதால், உண்மையான புலங்களையும் (fields) சரியான மதிப்புகளையும் (values) அது அறியும்.
இரண்டாவது விருப்பம் AWS MCP Server (Managed). இது உங்கள் ஏஜென்ட்டிற்கு நினைவாற்றலை மட்டுமல்லாமல், கைகளையும் வழங்குகிறது. முறையான அங்கீகாரத்துடன் (authentication), இது உங்கள் CloudWatch logs-களைப் பார்வையிடலாம், உங்கள் S3 buckets-களைப் பட்டியலிடலாம், உங்கள் DynamoDB table schemas-களைப் படிக்கலாம், ஒரு role-இன் সাথে இணைக்கப்பட்ட IAM policies-களைச் சரிபார்க்கலாம் அல்லது எந்த security groups இணையத்திற்குத் திறந்திருக்கின்றன என்பதைச் சரிபார்க்கலாம். இது உங்கள் உண்மையான கணக்கில் இயங்குவதால், production சிக்கல்களைத் தீர்க்க அல்லது நேரடி உள்கட்டமைப்பை (live infrastructure) மறுசீரமைக்க (refactoring) இது மிகவும் சக்தி வாய்ந்தது.
Managed சர்வர் நீண்ட காலம் நீடிக்கும் keys-களை (long-lived keys) நிராகரிக்கிறது. இது ஒரு பிரவுசர் சிக்-இன் (browser sign-in) மூலம் OAuth மூலமாகவோ அல்லது SigV4 signing மூலம் AWS CLI மூலமாகவோ அங்கீகரிக்கிறது. ஒவ்வொரு கருவி அழைப்பும் (tool call) குறுகிய கால டோக்கன்களுடன் (short-lived tokens) நடக்கும், ஒவ்வொரு செயலும் CloudTrail-இல் ஒரு தடயத்தை (trail) உருவாக்கும், மேலும் ஏஜென்ட் நீங்கள் வரையறுத்துள்ள IAM எல்லைகளுக்குள் (boundaries) மட்டுமே செயல்படும். உங்கள் நிறுவனத்தில் உள்ள மற்ற அனைத்து AWS பயனர்கள் அல்லது roles-களைக் கட்டுப்படுத்தும் அதே கொள்கை இயந்திரத்தால் (policy engine) இது கட்டுப்படுத்தப்படுவதால், இது தனது அனுமதிகளுக்கு வெளியே செல்ல முடியாது.
நினைவில் கொள்ள வேண்டிய பொன் விதி இதுதான்: ஒரு சர்வர் உங்கள் ஏஜென்ட்டிற்கு அறிவைத் தருகிறது, மற்றொன்று அதற்கு கைகளைத் தருகிறது. நீங்கள் படிக்கும்போதோ அல்லது வடிவமைக்கும்போதோ Knowledge சர்வரைப் பயன்படுத்துங்கள். நீங்கள் இயக்கும்போதோ அல்லது சரிசெய்யும்போதோ Managed சர்வரைப் பயன்படுத்துங்கள்.
பெரும்பாலான பணிகளுக்கு AWS ஏன் Managed Server-ஐப் பரிந்துரைக்கிறது
AWS இப்போது பெரும்பாலான பயனர்களை இரண்டு சர்வர்களையும் இணையாக இயக்குவதற்குப் பதிலாக, ஒற்றை Managed MCP Server-ஐ நோக்கித் தள்ளுகிறது. Knowledge சர்வர் வழங்கிய ஆவணத் தகவல்களை (documentation context) Managed சர்வர் உள்வாங்கிக் கொண்டதால், அது ஒரே endpoint மூலம் குறிப்புப் பொருட்கள் (reference material) மற்றும் நேரடி கணக்குச் செயல்பாடுகள் (live account actions) இரண்டையும் கையாள்கிறது.
இரண்டு சர்வர்களையும் ஒரே நேரத்தில் இயக்குவது அனுபவத்தைக் குறைக்கலாம். ஏஜென்ட் ஒன்றுடன் ஒன்று மேலோங்கும் கருவி வரையறைகளைப் (overlapping tool definitions) பெறுகிறது, இதனால் அது ஒரு read-only ஆவணத் தேடலை அழைக்க வேண்டுமா அல்லது உங்கள் கணக்கிற்கு எதிராக ஒரு நேரடி API-ஐ அழைக்க வேண்டுமா என்பதில் குழப்பமடையலாம். அந்தத் தயக்கம் மெதுவான பதில்களையும், அவ்வப்போது கருவித் தேர்வு பிழைகளையும் (tool-selection errors) உருவாக்குகிறது. Managed சர்வரைக் கொண்டு ஒருங்கிணைப்பது உங்கள் கட்டமைப்பை (configuration) எளிதாக்குகிறது மற்றும் ஏஜென்ட்டைத் துல்லியமாகச் செயல்பட வைக்கிறது.
OAuth மூலம் Managed Server-ஐ அமைத்தல்
Managed சர்வரை இயக்குவதற்கு சுமார் ஐந்து நிமிடங்கள் ஆகும், ஆனால் இந்த வழிமுறைகள் முக்கியமானவை, ஏனெனில் இது உங்கள் கணக்கிற்கான நேரடி இணைப்பு (live connection) ஆகும்.
படி 1: உங்கள் IAM அடையாளத்தைத் தயார் செய்யவும்
ஒரு பிரத்யேக IAM role அல்லது user-ஐ உருவாக்கவும் அல்லது தேர்ந்தெடுக்கவும். உங்கள் Root account-ஐப் பயன்படுத்த வேண்டாம். அதற்கு AWSMCPSignInOAuthAccessPolicy என்ற managed policy-ஐ இணைக்கவும். இந்த policy, MCP அணுகலுக்கான OAuth sign-in flow-வைத் தொடங்குவதற்குத் தேவையான அனுமதிகளை மட்டுமே வழங்குகிறது. இது தானாகவே பரந்த நிர்வாக உரிமைகளை (administrative rights) வழங்காது. உங்கள் agent-க்கு இருக்கும் உண்மையான திறன்கள், அந்த identity-யுடன் நீங்கள் இணைக்கும் மற்ற IAM policies-ஆல் தீர்மானிக்கப்படுகின்றன. நீங்கள் agent-ஐ CloudWatch logs-ஐப் படிக்க அனுமதிக்க விரும்புகிறீர்கள், ஆனால் IAM அல்லது billing-ஐத் தொடக்கூடாது என்று நினைத்தால், logs:DescribeLogGroups மற்றும் logs:FilterLogEvents ஆகியவற்றை மட்டுமே அனுமதிக்கும் ஒரு custom policy-யை உருவாக்கவும்.
படி 2: உங்கள் client-ஐ உள்ளமைக்கவும் (Configure)
அதிகாரப்பூர்வ AWS MCP server URL-ஐ உங்கள் client configuration-இல் சேர்க்கவும். இது Claude Desktop, Claude Code மற்றும் Kiro ஆகியவற்றுடன் செயல்படும். உங்கள் MCP settings file-இல், server endpoint-ஐப் பதிவு செய்யவும், இதன் மூலம் AWS தொடர்பான tool calls எங்கு அனுப்பப்பட வேண்டும் என்பதை client அறிந்து கொள்ளும்.
படி 3: உங்கள் browser மூலம் அங்கீகரிக்கவும் (Authenticate)
முதல் முறையாக agent ஒரு AWS tool-ஐ அழைக்க முயற்சிக்கும்போது, உங்கள் operating system ஒரு browser window-வைத் திறக்கும். படி 1-இல் நீங்கள் தயார் செய்த அதே IAM identity மூலம் sign in செய்யவும். OAuth flow, MCP server-க்கு ஒரு குறுகிய கால token-ஐத் திருப்பித் தரும். நீங்கள் ஒரு secret key-யைக் காண மாட்டீர்கள். configuration file-இல் எதையும் paste செய்ய வேண்டிய அவசியமில்லை. அந்த token தானாகவே புதுப்பிக்கப்படும் (refreshes) மற்றும் விரைவில் காலாவதியாகும் (expires).
படி 4: நம்பகத்தன்மை எல்லையை (trust boundary) சரிபார்க்கவும்
அங்கீகரிக்கப்பட்டதும், CloudTrail-ஐத் திறந்து, நீங்கள் உருவாக்கிய identity-ன் கீழ் செயல்பாடுகள் (actions) தோன்றுகிறதா என்பதை உறுதிப்படுத்தவும். அந்த குறிப்பிட்ட IAM user அல்லது role-உடன் தொடர்புடைய ListBuckets அல்லது DescribeInstances போன்ற நிகழ்வுகளை (events) நீங்கள் பார்க்க வேண்டும். நீங்கள் Root account செயல்பாடுகளைப் பார்த்தால், நீங்கள் ஏதோ தவறு செய்துவிட்டீர்கள் என்று அர்த்தம், உடனடியாக அந்த session-ஐ ரத்து (revoke) செய்ய வேண்டும்.
OAuth உங்கள் workflow-க்கு பொருந்தவில்லை என்றால், Managed server உங்கள் தற்போதைய AWS CLI credentials மூலம் SigV4 authentication-ஐயும் ஆதரிக்கிறது. இந்த முறை browser pop-up-ஐத் தவிர்க்கும், ஆனால் agent-க்கு நேரடி credentials-களை (raw credentials) வெளிப்படுத்துவதற்குப் பதிலாக, signing மற்றும் session management ஆகியவற்றை MCP server கையாளுவதால் நீங்கள் பயனடைவீர்கள்.
உண்மையில் முக்கியமான பாதுகாப்புப் பழக்கவழக்கங்கள்
ஒரு MCP server அதன் பின்னால் உள்ள IAM identity எவ்வளவு பாதுகாப்பானதோ அவ்வளவு பாதுகாப்பானது.
குறைந்தபட்ச அதிகாரத்துடன் (least privilege) தொடங்குங்கள். தவறாக வழிநடத்தப்பட்ட (misrouted) API Gateway integration-ஐ சரிசெய்ய உங்கள் agent-க்கு AdministratorAccess தேவையில்லை. தற்போதைய பணிக்குத் தேவையான சரியான read அல்லது write அனுமதிகளை மட்டும் வழங்கவும், பணி முடிந்ததும் அவற்றை மாற்றவும் (rotate) அல்லது ரத்து செய்யவும் (revoke). நீங்கள் ஒரு role-ஐப் பயன்படுத்தினால், குறுகிய கால session duration-ஐ அமைக்கவும். நீங்கள் ஒரு user-ஐப் பயன்படுத்தினால், உங்கள் tooling அனுமதிக்கும் இடங்களில் MFA-வைச் செயல்படுத்தவும்.
Root user ஆக ஒருபோதும் அங்கீகரிக்க வேண்டாம். Root, service control policies-களைத் தவிர்த்துவிட்டு, முழு கணக்கிற்கும் (account) கட்டுப்பாடற்ற அணுகலைப் பெறுகிறது. ஒருவேளை agent ஒரு prompt-ஐத் தவறாகப் புரிந்துகொண்டு, வளங்களை (resources) நீக்க முயற்சித்தால், அந்த கோரிக்கையை ஒரு boundary policy மூலம் தடுக்க வேண்டும். Root-க்கு அத்தகைய பாதுகாப்பு வழிமுறைகள் (guardrails) இல்லை.
இறுதியாக, agent-ஐ அறிவுரைகளைத் துல்லியமாகப் பின்பற்றும் ஆனால் பொது அறிவு (common sense) இல்லாத ஒரு புதிய பயிற்சியாளரைப் (intern) போலக் கருதுங்கள். நீங்கள் கேட்பதை அது அப்படியே, உடனடியாகச் செய்யும். நீங்கள் "பயன்படுத்தப்படாத security groups-களைச் சுத்தம் செய்யவும்" என்று சொன்னால், நீங்கள் கொடுத்த பரந்த அளவுகோல்களுடன் (broad criteria) ஒத்துப்போவதால், அது உங்கள் production database-உடன் இணைக்கப்பட்ட ஒன்றைத் துண்டிக்கக்கூடும். அழிவை ஏற்படுத்தும் எந்தவொரு கட்டளைகளையும் (destructive commands) உறுதிப்படுத்துவதற்கு முன் சரிபார்க்கவும், குறிப்பாக agent-க்கு write access இருக்கும்போது.
உண்மையான முக்கியக் கருத்து
பயனுள்ள தன்மைக்காகப் பாதுகாப்பை நீங்கள் விட்டுக்கொடுக்க வேண்டிய அவசியமில்லை. Managed AWS MCP Server உங்கள் AI assistant-க்கு உங்கள் உண்மையான உள்கட்டமைப்பைப் (infrastructure) பார்க்கவும், அதன் சொந்த மாயத்தோற்றங்களை (hallucinations) சரிசெய்யவும், உங்கள் குழுவின் மற்ற பகுதிகளைக் கட்டுப்படுத்தும் அதே IAM framework-க்குள் செயல்படவும் அனுமதிக்கிறது. environment files-களில் ரகசியங்களை (secrets) சேமிக்காமலேயே நீங்கள் நேரடித் தகவல்களைப் (live context) பெறலாம். OAuth flow-ஐ அமைக்கவும், அனுமதிகளைக் கட்டுப்படுத்தவும் (lock down), மேலும் agent உங்கள் கொள்கைகளின் (policies) கட்டுப்பாட்டிற்குள் செயல்பட அனுமதிக்கவும்.