گیت‌وی مرکزی؛ راهکار مدیریت دسترسی ۱۲ سرور MCP در محیط عملیاتی

یک محیط عملیاتی با ۱۲ سرور پروتکل زمینه مدل (MCP) تنها به اندازهٔ ضعیف‌ترین توکن آن امن است. این واقعیت تلخ، کابوس هماهنگی در مدیریت اعتبارنامه برای عامل‌های مختلف و هویت‌های انسانی را آشکار می‌کند؛ مشکلی که کلیدهای استاتیک هرگز نمی‌توانند آن را حل کنند. طبق یک گزارش فنی که در ۱ ژوئیه ۲۰۲۶ منتشر شد، انتقال از فایل‌های مشترک .env به یک گیت‌وی مرکزی، دقیقاً همان اقدامی بود که از دست رفتن داده‌های حیاتی و دسترسی‌های غیرمجاز جلوگیری کرد.

اکثر توسعه‌دهندگان مسیر خود را با یک تنظیم ساده شروع می‌کنند: یک کلید API مشترک در فایل تنظیمات. این روش برای نمونه‌های اولیه جواب می‌دهد، اما به محض مقیاس‌پذیر شدن تیم، شکست می‌خورد. هشت ماه پیش، سیستم احراز هویت این تیم تنها یک کلید API مشترک در فایل .env بود که هر توسعه‌دهنده‌ای به همه چیز دسترسی داشت. این وضعیت منجر به دو حادثه «نزدیک به فاجعه» شد؛ یک بار عاملی به دلیل پیکربندی غلط ابزار نوشتن، نزدیک بود داده‌های محیط عملیاتی را پاک کند و بار دیگر، یک پیمانکار پس از ترک شرکت، همچنان به سرورهای MCP دسترسی داشت.

همان‌طور که در بررسی‌های پیشین ما درباره امنیت مدل‌های عامل‌محور اشاره کردیم، مدیریت دسترسی در MCP سخت‌تر از APIهای استاندارد است، چون به جای یک رابطه، سه رابطه متمایز دارد. اول، رابطه «کلاینت به گیت‌وی/سرور» است که نشان می‌دهد عامل چگونه هویت خود را به زیرساخت MCP ثابت می‌کند. دوم، رابطه «گیت‌وی به سرویس‌های پایین‌دستی» است که نحوه احراز هویت سرور MCP در مقابل بک‌اندهایی مثل گیت‌هاب (GitHub)، جیرا (Jira) یا اسلک (Slack) را تعیین می‌کند. سوم، تفویض کاربر است؛ یعنی وقتی عامل به نمایندگی از یک انسان عمل می‌کند — مثلاً پیامی را در اسلک به نام کاربر می‌فرستد و نه به نام ربات — هویت کاربر باید در تمام زنجیره فراخوانی جریان یابد.

مدیریت دستی این سه رابطه برای هر سرور، توسعه‌دهنده و عامل، منجر به انفجار پیچیدگی می‌شود. در واقع بیشتر مشکلات احراز هویت در MCP، مشکلات هماهنگی هستند و نه مشکلات رمزنگاری.

تکامل روش‌های احراز هویت در MCP

این تیم پیش از رسیدن به معماری نهایی، چهار الگوی اصلی را آزمایش کرد:

• کلیدهای API استاتیک / توکن‌های Bearer: ساده‌ترین گزینه است که در آن سرور انتظار یک توکن Bearer ثابت در هدر Authorization را دارد. پیکربندی معمولاً به این شکل است:
  { "mcpServers": { "my-server": { "url": "https://my-mcp-server.internal/mcp", "headers": { "Authorization": "Bearer your-static-token-here" } } } }
  این روش برای سرورهای داخلی با یک اپراتور یا نمونه‌های اولیه سریع کاربردی است، اما هنگام چرخش توکن‌ها شکست می‌خورد. در تیمی با ۱۵ توسعه‌دهنده و ۸ سرور، هر تغییر توکن به یک کابوس هماهنگی تبدیل می‌شود. علاوه بر این، توکن‌های استاتیک هیچ هویت کاربری ندارند. ردپای عملیات فقط نشان می‌دهد «توکن X ابزار Y را فراخواند»، که برای پاسخ به حوادث یا رعایت قوانین نظارتی بی‌فایده است.

• متغیرهای محیطی برای سرورهای stdio: سرورهای MCP مبتنی بر stdio به عنوان پردازش‌های محلی اجرا می‌شوند و احراز هویت خارج از پروتکل و از طریق متغیرهای محیطی رخ می‌دهد. در ابزارهایی مثل کلود کد (Claude Code) و کِرسور (Cursor)، سینتکس ${env:VAR} داده‌ها را از محیط شِل می‌گیرد:
  { "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}" } } } }
  این کار اسرار را از کنترل نسخه دور نگه می‌دارد اما مقیاس‌پذیر نیست. هر توسعه‌دهنده اعتبارنامه‌های خود را جداگانه برای هر سرور مدیریت می‌کند و هیچ راهی برای ابطال مرکزی دسترسی‌ها وجود ندارد. وقتی یک توسعه‌دهنده شرکت را ترک می‌کند، هیچ تضمینی نیست که محیط محلی خود را پاک کرده باشد.

• OAuth 2.1 با PKCE: طبق بازبینی مارس ۲۰۲۵ در پروتکل MCP، این روش پاسخ بلندمدت برای سرورهای راه دور است. جریان کار شامل شروع اتصال توسط عامل، هدایت سرور به یک تامین‌کننده هویت (IdP) مثل اوکتا (Okta)، آژور ای‌دی (Azure AD) یا آت‌زیرو (Auth0)، احراز هویت کاربر در مرورگر و در نهایت تبادل کد مجوز برای دریافت توکن دسترسی توسط کلاینت است. PKCE تضمین می‌کند کدها رهگیری نشوند. این روش فراخوانی ابزارها را به هویت واقعی کاربران گره می‌زند و ابطال کاربر در IdP به‌طور خودکار دسترسی MCP را می‌بندد. با این حال، هنوز همه کلاینت‌ها بازبینی نوامبر ۲۰۲۵ را به‌طور کامل پیاده‌سازی نکرده‌اند.

• PATs و VATs برای حساب‌های سرویس: برای عامل‌هایی که بدون حضور انسان اجرا می‌شوند (جایی که هدایت به مرورگر غیرممکن است)، تیم از دو نوع توکن استفاده کرد. توکن‌های دسترسی شخصی (PATs) به هویت یک کاربر خاص برای گردش‌کارهای توسعه متصل هستند. توکن‌های حساب مجازی (VATs) اعتبارنامه‌های حساب‌های سرویس با مجوزهای تعریف‌شده برای عامل‌های خودکار هستند. این تفکیک اجازه می‌دهد ردپای عملیات توسعه‌دهنده از اقدامات حساب‌های سرویس به‌طور شفاف جدا شود.

راهکار گیت‌وی

برای جلوگیری از مدیریت تک‌تک جریان‌های OAuth برای هر سرور و هر توسعه‌دهنده، تیم گیت‌وی MCP ترو-فاندری (TrueFoundry's MCP Gateway) را پیاده کرد. این لایه مرکزی تمام مدیریت اعتبارنامه‌های پایین‌دستی و نوسازی (Refresh) آن‌ها را برای گیت‌هاب، کانفلونس (Confluence)، جیرا و APIهای داخلی بر عهده می‌گیرد.

جزئیات عملیاتی گیت‌وی

• ساده‌سازی هویت: توسعه‌دهندگان با یک PAT واحد به گیت‌وی متصل می‌شوند و عامل‌های سرویس از VAT استفاده می‌کنند. گیت‌وی توکن‌های پیچیده پایین‌دستی را مدیریت کرده و پیش از انقضا، آن‌ها را به‌طور خودکار نوسازی می‌کند.
• کنترل دسترسی مبتنی بر نقش (RBAC): دسترسی‌ها در سطح ابزار اعمال می‌شوند. مثلاً گیت‌وی طوری پیکربندی می‌شود که «تیم نوع A» بتواند در جیرا از ابزارهای search_issues و create_issue استفاده کند، اما دسترسی به delete_issue برای آن‌ها به‌طور کامل مسدود باشد. این سیاست‌ها به ازای هر سرور، هر ابزار و هر نقش تعریف می‌شوند.
• فیلتر دینامیک ابزارها: عامل هوش مصنوعی هرگز ابزارهایی را نمی‌بیند که مجاز به فراخوانی آن‌ها نیست. پاسخ دستور tools/list توسط گیت‌وی بر اساس هویت فراخواننده فیلتر می‌شود و سپس به عامل می‌رسد.
• اقدامات تفویضی کاربر: برای کارهایی که باید به نام یک انسان ثبت شوند — مثل ایجاد تیکت جیرا برای یک مهندس خاص — گیت‌وی تبادل توکن اوکتا و نوسازی آن را مدیریت می‌کند و عامل‌ها مستقیماً با جریان‌های OAuth درگیر نمی‌شوند.
• گزارش‌های جامع حسابرسی: هر فراخوانی ابزار با مجموعه‌ای از داده‌های غیرقابل‌تغییر ثبت می‌شود: چه عاملی، با چه هویت کاربری، کدام ابزار، با چه پارامترهایی، چه پاسخی دریافت شده و در چه زمانی (Timestamp) استفاده کرده است. این موضوع برای انطباق امنیتی و عیب‌یابی شکست‌های عامل‌ها در محیط عملیاتی حیاتی است.

ریسک‌های امنیتی و CVEها

این پیاده‌سازی بدون ریسک نیست. در اوایل سال ۲۰۲۶، تحقیقات امنیتی جی‌فروگ (JFrog Security Research) یک آسیب‌پذیری در پیاده‌سازی‌های رایج OAuth در MCP (نسخه‌های v0.1.16 و قدیمی‌تر) افشا کرد. در این نسخه‌ها، URLهای نقطه انتهایی مجوز OAuth بدون پاک‌سازی (Sanitization) به هندلرهای سیستم ارسال می‌شد. این نقص اجازه می‌داد یک سرور MCP مخرب، URLای بسازد که دستورات произвоی سیستم‌عامل را روی ماشین توسعه‌دهنده اجرا کند. این مشکل در نسخه v0.1.16 برطرف شد.

علاوه بر CVEهای خاص، تیم متوجه شد که استاندارد MCP هنوز در حال تثبیت است. بازبینی نوامبر ۲۰۲۵، «اسناد متادیتای شناسه کلاینت» را به عنوان روش ترجیحی ثبت معرفی کرد و جایگزین «ثبت دینامیک کلاینت» (Dynamic Client Registration) در اکثر موارد نمود. توسعه‌دهندگان باید پیش از استقرار OAuth در محیط عملیاتی، سطح پچ کلاینت و نسخه انطباق با استاندارد را بررسی کنند.

سرمایه‌گذاری روی گیت‌وی سریعاً به نتیجه داد. ادغام با اوکتا حدود یک روز و تنظیم RBAC برای هر سرور تقریباً یک روز زمان برد. خروج یک کارمند از سازمان، تنها با یک اقدام در داشبورد مدیریت شد و نیاز به جست‌وجو برای یافتن ۶ اعتبارنامه مختلف را از بین برد.

این چرخش نشان می‌دهد که امنیت MCP کمتر به رمزنگاری مربوط است و بیشتر به هماهنگی برمی‌گردد. با جداسازی عامل از اعتبارنامه، تیم‌ها می‌توانند ابزارهای هوش مصنوعی را بدون قربانی کردن ایمنی و قابلیت حسابرسی، به محیط عملیاتی منتقل کنند.

گام بعدی شما

• اگر از سرورهای MCP در محیط تیمی استفاده می‌کنید، فوراً تمام توکن‌های استاتیک را به یک سیستم مدیریت متمرکز یا OAuth منتقل کنید.
• سطح پچ کلاینت‌های خود را بررسی کنید تا از آسیب‌پذیری‌های گزارش‌شده توسط JFrog در امان باشید.
• برای هر ابزار حساس، سیاست‌های RBAC را در سطح «عمل» (Action) تعریف کنید، نه فقط در سطح «سرور».

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.