اکثر پست‌های مربوط به ساخت سرور MCP بر روی خود پروتکل تمرکز می‌کنند: تعریف ابزارها، پردازش درخواست‌ها، اتصال مشتری. این قسمت واقعا واضح است. چیزی که اغلب نادیده گرفته می شود این است که وقتی ابزاری که در معرض نمایش قرار می دهید به جای برگرداندن داده ها با فایل ها کار می کند تغییر می کند. پردازش فایل مجموعه خاصی از مسائل امنیتی و قابلیت اطمینان را معرفی می کند که یک API معمولی فقط خواندنی نیازی به فکر کردن به آنها ندارد و اشتباه کردن آنها تا زمانی که مشکلی پیش نیاید به راحتی از دست می رود.
این خلاصه ای از تصمیماتی است که در ساختن یک سرور MCP که ابزارهای پردازش اسناد، ادغام، تبدیل، OCR و عملیات مشابه را در معرض دید قرار می دهد، و چرا برخی از رویکردهای آشکار نادرست بودند، بسیار مهم است.
چرا ابزارهای پردازش فایل یک مورد امنیتی متفاوت هستند
یک ابزار MCP معمولی که از پایگاه داده پرس و جو می کند یا یک API فقط خواندنی را فرا می خواند، سطح حمله محدود و قابل پیش بینی دارد. ابزاری که یک فایل یا بدتر از آن، نشانی اینترنتی اشاره به فایل را می پذیرد و آن را پردازش نمی کند. دو مشکل فوراً به وجود می‌آیند که API ساده‌تر به ندرت باید با آنها مقابله کند.
اول، هر پارامتر ابزاری که URL را می پذیرد، یک بردار SSRF بالقوه است. یک کلاینت MCP می تواند مستقیماً یا از طریق یک پاسخ مدل بالادستی در معرض خطر فریب داده شود تا یک URL که به یک سرویس داخلی، نقطه پایانی ابرداده ابری یا آدرس داخلی غیرقابل دسترسی اشاره دارد، ارسال کند. اگر سرور ساده لوحانه هر URL که داده شده را بازیابی کند، این درخواست از داخل زیرساخت شما با هر گونه دسترسی به شبکه سرور شما انجام می شود. در نظر گرفتن هر URL ورودی به عنوان یک ورودی نامعتبر، حل آن قبل از واکشی، و مسدود کردن صریح محدوده IP خصوصی و نقاط پایانی ابرداده برای ابزاری مانند این اختیاری است، سطح پایه است.
دوم، پردازش فایل در مقایسه با تماس معمولی API گران است. ادغام فایل‌های PDF، اجرای OCR، تبدیل بین فرمت‌ها، همگی CPU و حافظه واقعی را برای هر درخواست مصرف می‌کنند، به نحوی که جستجوهای پایگاه داده مصرف نمی‌کنند. این نحوه عملکرد محدود کردن نرخ را تغییر می دهد، که ارزش یک بخش جداگانه در زیر را دارد.
Auth: چرا کلیدهای API به اضافه JWT و نه فقط یکی یا دیگری
استفاده از یک کلید API با عمر طولانی آسان است و به راحتی درز می کند. پس از صدور، تا زمانی که به صورت دستی باطل نشود معتبر است، و اگر کلیدی به طور تصادفی در یک فایل گزارش، پیکربندی متعهد یا ادغام سمت مشتری قرار گیرد، محدودیت زمانی برای محدود کردن آسیب وجود ندارد.
رویکردی که در عمل بهتر پشتیبانی می شود: کلیدهای API هش شده bcrypt برای مرحله احراز هویت اولیه، سپس یک JWT کوتاه مدت که توسط آن صرافی برای جلسه واقعی صادر می شود. کلید API هرگز در هر درخواست ارسال نمی شود، فقط در ابتدا، و هرگز به صورت متن ساده در سمت سرور ذخیره نمی شود، بنابراین به خطر انداختن پایگاه داده به طور مستقیم اعتبار قابل استفاده را نشان نمی دهد. JWT که در ادامه می آید دارای یک انقضای واقعی است که مدت زمان مفید ماندن توکن منقضی شده را محدود می کند و یک مکانیسم ابطال طبیعی بدون نیاز به لغو کلید اصلی به شما می دهد.
این مدل جدید نیست. این روش استاندارد در بسیاری از طراحی های API است. شایان ذکر است که به راحتی می توان از اختصاصی بودن به سرور MCP غافل شد، زیرا ابزارها و نمونه های موجود در اکثر اسناد MCP برای سادگی، به طور پیش فرض یک کلید ثابت را دارند و اگر کسی دوباره آن را بررسی نکند، این پیش فرض بی سر و صدا تبدیل به پیاده سازی ارسال شده می شود.
بی‌توانی: شرطی که همه فراموش می‌کنند تا زمانی که نیش بزند
کلاینت های MCP دوباره امتحان کنید. وقفه های شبکه، وقفه های زمانی، مدلی که تصمیم به فراخوانی یک ابزار برگشتی می گیرد، همگی به این معنی است که یک درخواست منطقی یکسان می تواند بیش از یک بار به سرور شما برسد. برای یک ابزار فقط خواندنی، که بی ضرر است، شما فقط همان داده ها را دو بار برمی گردانید. برای ابزاری که یک فایل را پردازش و شارژ می‌کند، درخواست تکراری به معنای پردازش تکراری، فایل‌های خروجی بالقوه تکراری، و بسته به مدل صورت‌حساب شما، هزینه‌های تکراری برای هر اقدام کاربر است.
پچ یک کلید عدم توانایی است که به هر درخواست متصل می شود، توسط مشتری تولید می شود و قبل از شروع پردازش توسط سرور تأیید می شود. اگر درخواستی با یک کلید idempotency داده شده قبلا پردازش شده باشد، سرور به جای پردازش مجدد، نتیجه ذخیره شده را برمی گرداند. زمانی که گفته شد این واضح به نظر می رسد، اما ساخت یک سرور MCP کار بسیار آسان است که تمام آزمایشات را در مرحله توسعه پشت سر بگذارد، جایی که تکرارهای نادر هستند، و تنها پس از رسیدگی به اتصالات مشتری واقعی، گاهی ناپایدار، در تولید، شکاف را کشف می کنند.
محدودیت سرعتی که استفاده قانونی را جریمه نمی کند
از آنجایی که پردازش فایل برای هر درخواست به CPU و حافظه فشرده نیاز دارد، محدودیت‌های کلی نرخ در دقیقه که از یک REST API معمولی قرض گرفته می‌شوند، تمایل دارند یا اجازه سوء استفاده را می‌دهند یا جریان‌های کار دسته‌ای قانونی را مسدود می‌کنند، و تنظیم یک عدد واحد که از هر دو جلوگیری کند، دشوار است. شخصی که بیست فایل را در یک جریان کار دسته‌ای واقعی پردازش می‌کند، از نقطه نظر یک محدودکننده سرعت ساده یک اسکریپت که به نقطه پایانی برخورد می‌کند، یکسان به نظر می‌رسد.
چیزی که بهتر کار می‌کرد، ردیابی محدودیت‌های کلید API با جزئیات کافی برای تشخیص سوء استفاده مداوم با فرکانس بالا از یک انفجار مشروع از فعالیت بود، به‌جای اینکه یک سقف درخواست در دقیقه به‌طور یکنواخت اعمال شود. این مشکلی است که درست کردن آن سخت تر از آن است که به نظر می رسد، و این منطقه ای است که ارزش آن را دارد که به طور دوره ای با واضح تر شدن الگوهای استفاده واقعی، به جای اینکه پیکربندی اولیه را به عنوان نهایی تلقی کنیم، دوباره مرور کنیم.
ثبت حسابرسی به عنوان یک تصمیم طراحی، نه یک فکر بعدی
وسوسه انگیز است که با ورود به سیستم به عنوان چیزی برخورد کنید که پس از بروز یک مشکل امنیتی واقعاً با آن مقابله می کنید. برای ابزاری که فایل های کاربر را پردازش می کند، برعکس است. دانستن اینکه کدام کلید API کدام فایل را لمس کرده است، چه زمانی و چه عملیاتی انجام شده است، باید از اولین استقرار وجود داشته باشد، پس از تصادف به صورت عطف به ماسبق اضافه نشود، و واضح است که باید آنجا می بود. این پیامدهایی هم برای اشکال زدایی و هم برای امنیت دارد، زیرا تعداد شگفت انگیزی از سؤالات پشتیبانی را می توان در نهایت مستقیماً از لاگ های حسابرسی پاسخ داد، نه اینکه نیاز به عقب نشینی با کاربر باشد.
چه چیزی در زمان گذشته صرفه جویی می کرد
دو چیز اگر از نو شروع کنید. اولین مورد، تصمیم گیری در مورد الگوی احراز هویت، تبادل کلید API به همراه یک JWT کوتاه مدت در مقابل یک کلید ثابت قبل از نوشتن یک کنترل کننده ابزار واحد است، به جای شروع با کلید استاتیک ساده تر برای سرعت و مهاجرت بعدا. مهاجرت از نظر فنی دشوار نیست، اما بر هر یکپارچگی موجود و هر قطعه از اسناد مشتری تأثیر می گذارد، بنابراین هزینه تأخیر در راه حل بیشتر سازمانی است، نه فنی.
دومی ساختن بررسی عدم توانایی از ابزار اول به جای اضافه کردن آن پس از ظاهر شدن یک گزارش پردازش تکراری است. این مقدار کمی از کد، جستجوها و حافظه پنهان در ابتدای پردازش درخواست است، اما بازسازی مجدد آن به معنای ممیزی هر ابزار موجود است تا جایی که پیاده سازی تکراری واقعاً باعث ایجاد مشکل قابل مشاهده می شود در مقایسه با مواردی که بی ضرر است، که زمان بیشتری از ساختن آن از ابتدا صرف می کند.
مونتاژ کردن
هیچ یک از اینها به تنهایی ایده های عجیب و غریب نیستند. توکن‌های کوتاه‌مدت روی کلیدهای استاتیک، تلقی کردن URLهای ورودی به‌عنوان غیرقابل اعتماد، کلیدهای عدم توانایی برای تکرار عملیات، ثبت حسابرسی از روز اول، همگی الگوهای کاملاً درک شده در طراحی API هستند. چیزی که در مورد ساخت یک سرور MCP برای پردازش فایل مشخص است این است که ترکیب در اینجا بیشتر از یک ادغام فقط خواندنی معمولی اهمیت دارد، زیرا حالت های خرابی گران تر هستند: یک فایل تکراری، یک کلید منقضی نشده، یک سوراخ SSRF که از طریق یک پارامتر ابزار قابل دسترسی است، یا یک عملیات ردیابی نشده در یک سند کاربر.
اگر در حال ساختن یا ارزیابی یک سرور MCP هستید که روی فایل‌ها، نه فقط داده‌ها، تأثیر می‌گذارد، اینها سؤالاتی هستند که ارزش پرسیدن را دارند، قبل از اینکه اولین مشتری واقعی به آن متصل شود، نه بعد از آن.
