از کپی کردن کلیدهای دسترسی AWS در فایلهای .env خود خودداری کنید.
همه ما این تجربه را داشتهایم. دیر وقت است، در حال عیبیابی یک خطای دسترسی Lambda هستید و دستیار هوش مصنوعی شما مدام نام سرویسها یا ARNهایی با شناسههای حساب کاربری خیالی میسازد. شما میخواهید مدل منابع واقعی شما را ببیند تا از توهم زدن دست بردارد و شروع به اصلاح کند. از روی ناچاری، یک کلید دسترسی برمیدارید، آن را در یک فایل محیطی قرار میدهید و به عامل (agent) میدهید. کار میکند. احساس آرامش میکنید. اما صبح که میشود، متوجه میشوید که آن رمز عبور در تاریخچه شل (shell history)، اسکرول ترمینال یا بدتر از آن، در یک کامیت (commit) که به یک مخزن مشترک ارسال شده، باقی مانده است.
این دقیقاً همان آشفتگیای است که Model Context Protocol برای جلوگیری از آن ساخته شده است.
MCP یک پل استاندارد بین عامل هوش مصنوعی شما و سیستمهای خارجی ایجاد میکند. به جای تحویل دادن اعتبارنامههای خام و امید به اینکه عامل آنها را لو ندهد، شما از طریق یک سرور کنترلشده متصل میشوید که احراز هویت را مدیریت میکند، محدودههای دسترسی (scopes) را تعیین میکند و کلیدهای شما را کاملاً از پنجره چت دور نگه میدارد.
برای AWS، در حال حاضر دو سرور رسمی MCP برای انتخاب دارید. انتخاب اشتباه یا عامل شما را نابینا میکند و یا با نظارت بسیار کم، دسترسی بیش از حد به او میدهد.
تفاوت را بدانید: دانش در مقابل دستها
گزینه اول، AWS Knowledge MCP Server است. آن را مانند یک مهندس ارشد تصور کنید که تمام کتابخانه مستندات AWS را حفظ کرده است اما هیچ اعتبارنامهای برای ورود به حساب شما ندارد. این سرور طبق طراحی، فقط خواندنی (read-only) است و با ارجاع به مستندات رسمی AWS، عامل را با نحو (syntax) واقعی API، نامهای صحیح سرویسها و بهترین روشهای فعلی همسو میکند.
برای استفاده از آن نیازی به حساب AWS ندارید. آن را به زیرساخت خود متصل نمیکنید. زمانی از آن استفاده میکنید که در حال ترسیم یک نمودار معماری هستید، در حال یادگیری یک سرویس جدید مانند ECS یا EventBridge هستید، یا در حال بررسی این هستید که آیا یک فراخوانی API خاص هنوز همانطور که دو سال پیش به یاد داشتید رفتار میکند یا خیر. این کار مانع از حدس زدن عامل میشود. اگر از او بخواهید برای یک S3 bucket policy کد Terraform بنویسد، او فیلدهای واقعی و مقادیر معتبر را میشناسد، زیرا اطلاعات را از منبع اصلی میگیرد، نه از دادههای آموزشی که سال گذشته متوقف شدهاند.
گزینه دوم، AWS MCP Server (Managed) است. این گزینه به عامل شما نه فقط حافظه، بلکه «دست» (توانایی انجام کار) میدهد. با احراز هویت مناسب، میتواند لاگهای CloudWatch شما را بررسی کند، لیست S3 bucketهای شما را بیاورد، طرحوارههای (schemas) جدول DynamoDB شما را بخواند، سیاستهای IAM متصل به یک نقش (role) را چک کند، یا تأیید کند که کدام گروههای امنیتی (security groups) برای اینترنت باز هستند. این سرور روی حساب واقعی شما کار میکند که آن را برای عیبیابی مشکلات محیط عملیاتی (production) یا بازسازی (refactoring) زیرساختهای زنده بسیار قدرتمند میکند.
سرور Managed از کلیدهای طولانیمدت خودداری میکند. این سرور از طریق OAuth با ورود از طریق مرورگر، یا از طریق AWS CLI با استفاده از امضای SigV4 احراز هویت میکند. هر فراخوانی ابزار با توکنهای کوتاهمدت انجام میشود، هر اقدام ردپایی در CloudTrail به جا میگذارد و عامل دقیقاً در محدودههای IAM که شما تعریف کردهاید عمل میکند. عامل نمیتواند از مجوزهای خود فراتر برود، زیرا توسط همان موتور سیاستی محدود شده است که بر هر کاربر یا نقش دیگر AWS در سازمان شما حاکم است.
این قانون طلایی است که باید به خاطر بسپارید: یک سرور به عامل شما دانش میدهد و دیگری به او دست میدهد. زمانی که در حال مطالعه یا طراحی هستید، از سرور Knowledge استفاده کنید. زمانی که در حال عملیات یا تعمیر هستید، از سرور Managed استفاده کنید.
چرا AWS سرور Managed را برای اکثر وظایف توصیه میکند
اکنون AWS اکثر کاربران را به جای اجرای همزمان هر دو، به سمت استفاده از یک سرور واحد Managed MCP سوق میدهد. سرور Managed، بافت مستنداتی را که سرور Knowledge ارائه میداد، در خود جذب کرده است، بنابراین هم مطالب مرجع و هم اقدامات حساب زنده را تحت یک نقطه اتصال (endpoint) مدیریت میکند.
اجرای همزمان هر دو سرور در واقع میتواند تجربه کاربری را کاهش دهد. عامل با تعاریف ابزار همپوشان مواجه میشود و ممکن است گیج شود که آیا باید یک جستجوی مستنداتِ فقط خواندنی را فراخوانی کند یا یک API زنده را روی حساب شما اجرا کند. این تردید باعث کندی پاسخها و خطاهای گاهبهگاه در انتخاب ابزار میشود. تجمیع در سرور Managed، پیکربندی شما را سادهتر کرده و تمرکز عامل را حفظ میکند.
راهاندازی سرور Managed با OAuth
راهاندازی سرور Managed حدود پنج دقیقه زمان میبرد، اما مراحل اهمیت دارند زیرا این یک اتصال زنده به حساب شماست.
مرحله ۱: هویت IAM خود را آماده کنید
یک نقش یا کاربر اختصاصی IAM ایجاد یا انتخاب کنید. از حساب Root خود استفاده نکنید. سیاست مدیریتشده (managed policy) با نام AWSMCPSignInOAuthAccessPolicy را به آن متصل کنید. این سیاست تنها مجوزهای لازم برای شروع جریان ورود OAuth جهت دسترسی به MCP را اعطا میکند. این سیاست به خودی خود حقوق مدیریتی گستردهای نمیدهد. قابلیتهای واقعی که عامل (agent) شما خواهد داشت، توسط سایر سیاستهای IAM که به آن هویت متصل میکنید، تعیین میشود. اگر میخواهید عامل بتواند لاگهای CloudWatch را بخواند اما هرگز به IAM یا صورتحساب (billing) دسترسی نداشته باشد، یک سیاست سفارشی بسازید که فقط اجازه logs:DescribeLogGroups و logs:FilterLogEvents را بدهد و نه هیچ چیز دیگر.
مرحله ۲: پیکربندی کلاینت خود
آدرس URL رسمی سرور AWS MCP را به پیکربندی کلاینت خود اضافه کنید. این کار با Claude Desktop، Claude Code و Kiro سازگار است. در فایل تنظیمات MCP خود، نقطه پایانی (endpoint) سرور را ثبت کنید تا کلاینت بداند فراخوانیهای ابزار مربوط به AWS را به کجا هدایت کند.
مرحله ۳: احراز هویت از طریق مرورگر
اولین باری که عامل سعی میکند یک ابزار AWS را فراخوانی کند، سیستمعامل شما یک پنجره مرورگر باز میکند. با همان هویت IAM که در مرحله ۱ آماده کردید، وارد شوید. جریان OAuth یک توکن با عمر کوتاه را به سرور MCP بازمیگرداند. شما کلید مخفی (secret key) نخواهید دید. چیزی را در فایل پیکربندی کپی نخواهید کرد. توکن به طور خودکار بازنشانی (refresh) شده و به سرعت منقضی میشود.
مرحله ۴: تأیید مرز اعتماد
پس از احراز هویت، CloudTrail را باز کنید و تأیید کنید که اقدامات تحت هویت ساختهشده شما ظاهر میشوند. شما باید رویدادهایی مانند ListBuckets یا DescribeInstances را ببینید که به آن کاربر یا نقش خاص IAM متصل هستند. اگر فعالیت حساب Root را مشاهده کردید، اشتباهی انجام دادهاید و باید بلافاصله نشست (session) را لغو کنید.
اگر OAuth با گردش کار شما سازگار نیست، سرور Managed از احراز هویت SigV4 از طریق اعتبارنامههای موجود AWS CLI شما نیز پشتیبانی میکند. این مسیر پنجره پاپآپ مرورگر را حذف میکند، اما همچنان از این مزیت بهره میبرید که سرور MCP مدیریت امضا و نشست را بر عهده میگیرد، به جای اینکه اعتبارنامههای خام را در اختیار عامل قرار دهد.
عادتهای امنیتی که واقعاً اهمیت دارند
امنیت یک سرور MCP دقیقاً به اندازه هویت IAM پشت آن است.
با اصل حداقل امتیاز (least privilege) شروع کنید. عامل شما برای اصلاح یک یکپارچهسازی اشتباه در API Gateway نیازی به AdministratorAccess ندارد. دقیقاً همان مجوزهای خواندن یا نوشتن مورد نیاز برای وظیفه فعلی را به آن بدهید و پس از انجام کار، آنها را تغییر داده یا لغو کنید. اگر از یک نقش (role) استفاده میکنید، مدت زمان نشست را کوتاه تنظیم کنید. اگر از یک کاربر استفاده میکنید، در هر کجا که ابزارهای شما اجازه میدهند، MFA را فعال کنید.
هرگز با کاربر Root احراز هویت نکنید. کاربر Root سیاستهای کنترل سرویس (SCPs) را دور میزند و دسترسی نامحدود به کل حساب دارد. اگر عامل یک دستور (prompt) را اشتباه تفسیر کند و سعی در حذف منابع داشته باشد، شما میخواهید آن درخواست توسط یک سیاست مرزی (boundary policy) مسدود شود. کاربر Root چنین حفاظهایی ندارد.
در نهایت، با عامل مانند یک کارآموز جدید رفتار کنید که دستورات را دقیقاً اجرا میکند اما فاقد درک عمومی است. عامل دقیقاً همان چیزی را که از او بخواهید، به صورت تحتاللفظی و فوری اجرا خواهد کرد. اگر به او بگویید "گروههای امنیتی استفاده نشده را پاکسازی کن"، ممکن است گروهی را که به پایگاه داده عملیاتی (production) شما متصل است حذف کند، زیرا با معیارهای گستردهای که به او دادهاید مطابقت داشت. هر دستور مخربی را قبل از تأیید بررسی کنید، به خصوص زمانی که عامل دسترسی نوشتن دارد.
نتیجهگیری اصلی
نیازی نیست امنیت را فدای کاربردی بودن کنید. سرور Managed AWS MCP به دستیار هوش مصنوعی شما اجازه میدهد زیرساخت واقعی شما را ببیند، توهمات (hallucinations) خود را اصلاح کند و در همان چارچوب IAM که بر سایر اعضای تیم شما حاکم است، فعالیت کند. شما بدون قرار دادن رمزهای عبور در فایلهای محیطی (environment files)، به بافت (context) زنده دسترسی خواهید داشت. جریان OAuth را راهاندازی کنید، مجوزها را محدود کنید و اجازه دهید عامل با چشمهای باز و در حالی که دستانش به سیاستهای شما بسته شده است، کار کند.