ایزولاسیون Localhost و Nginx؛ راهکار سخت‌افزاری برای ایمن‌سازی مدل‌های میزبانی

اگر امروز یک مدل زبانی را روی سخت‌افزار شخصی خود میزبانی می‌کنید، احتمالاً یک حفره امنیتی عظیم را به روی کل اینترنت باز گذاشته‌اید. متصل کردن سرور استنتاج هوش مصنوعی شما به 127.0.0.1 تنها راه برای اطمینان از این است که وزن‌های مدل و داده‌های شما به اینترنت باز نشت نکنند. یک اشتباه کوچک در پیکربندی پورت‌ها می‌تواند نه تنها گفتگوهای شما، بلکه کل سیستم‌فایل و متغیرهای محیطی (Environment Variables) حاوی کلیدهای حساس API شما را در معرض سرقت قرار دهد. وزن‌های مدل شما — که اغلب ارزش ده‌ها هزار دلار هزینه محاسباتی دارند — روی همان ماشینی قرار دارند که سرور استنتاج روی آن اجرا می‌شود و همین موضوع ریسک‌ها را به شدت بالا می‌برد.

این ریسک دیگر یک احتمال تئوریک نیست و به صورت قابل اندازه‌گیری درآمده است. طبق گزارش Shodan در سال ۲۰۲۳، بیش از ۳۲۰۰ نمونه از Ollama و حدود ۱۱۰۰ سرور vLLM بدون هیچ‌گونه احراز هویتی در فضای عمومی اینترنت شناسایی شدند. این اعداد نشان‌دهنده یک سطح حمله (Attack Surface) بحرانی است که تا دو سال پیش وجود نداشت.

همان‌طور که در تحلیل قبلی ما درباره‌ی جایگزین‌های میزبانی شخصی مانند Helical Insight اشاره کردیم، عبور از APIهای مدیریت‌شده به معنای پذیرش کامل مسئولیت‌های امنیتی است. استانداردهای امنیتی وب در اینجا اغلب شکست می‌خورند؛ زیرا سرورهای هوش مصنوعی برای راحتی پژوهشگران طراحی شده‌اند، نه برای سخت‌سازی در محیط عملیاتی (Production Hardening). در واقع، اینجاست که امنیت هوش مصنوعی با الگوهای کلاسیک زیرساختی تلاقی می‌کند: همان اصولی که از پایگاه‌های داده محافظت می‌کنند — یعنی جداسازی شبکه، پروکسی‌های معکوس و پایان‌دهی TLS — اکنون باید برای هسته‌های هوش مصنوعی به کار گرفته شوند، هرچند باید قابلیت پشتیبانی از اتصالات طولانی‌مدت و پاسخ‌های جریانی (Streaming) را داشته باشند.

الگوی ایزولاسیون Localhost

اساس یک استقرار امن، متصل کردن هسته هوش مصنوعی منحصراً به رابط لوپ‌بک (127.0.0.1 یا ::1) است. وقتی سروری مثل Ollama روی 0.0.0.0:11434 گوش می‌دهد، هر میزبان (Host) که به آن IP دسترسی داشته باشد، می‌تواند درخواست بفرستد. اما با محدود کردن آن به 127.0.0.1، دسترسی خارجی در سطح سیستم‌عامل حذف می‌شود و مرزی سخت و پاک بین شبکه نامطمئن و هسته مدل ایجاد می‌گردد.

برای Ollama، این کار مستلزم یک پیکربندی جایگزین (Override) در systemd است تا مقدار OLLAMA_HOST=127.0.0.1:11434 در مسیر /etc/systemd/system/ollama.service.d/override.conf قرار گیرد. این پیکربندی مانع از آن می‌شود که سرویس به هر رابط (Interface) دیگری متصل شود. در مورد vLLM که در کانتینر داکر اجرا می‌شود، اپراتور باید از پرچم --host 127.0.0.1 استفاده کرده و پورت را دقیقاً به رابط محلی متصل کند (-p 127.0.0.1:8000:8000). این کار تضمین می‌کند که API سازگار با OpenAI فقط از داخل خود ماشین قابل دسترسی باشد، در حالی که حالت شبکه روی host تنظیم شده است.

این ایزولاسیون مانع از دسترسی مهاجمان به نقاط انتهایی مدیریتی می‌شود. برای مثال، نقطه انتهایی /api/pull در Ollama می‌تواند برای دانلود مدل‌های دلخواه مورد سوءاستفاده قرار گیرد که منجر به پر شدن فضای دیسک یا احتمال ورود فایل‌های آلوده به زنجیره تأمین (Supply-chain compromised files) می‌شود. با متصل کردن سرور به localhost، شما کل این کلاس از مخاطرات را حذف می‌کنید. این جداسازی شبکه در سطح سیستم‌عامل از طریق اتصال سوکت (Socket Binding) اعمال می‌شود که بسیار مستحکم‌تر از تکیه بر قوانین فایروال است که ممکن است به اشتباه پیکربندی شوند یا دور زده شوند.

Nginx به عنوان دروازه امنیتی

وقتی هسته مدل در Localhost قفل می‌شود، Nginx به تنها نقطه ورود تبدیل می‌گردد. این ابزار وظیفه پایان‌دهی TLS (TLS Termination) — یعنی رمزنگاری ارتباطات — را بر عهده می‌گیرد تا عملیات سنگین رمزنگاری از روی دوش سرور استنتاج (Inference) برداشته شود. بارهای کاری هوش مصنوعی از پیش محدود به توان محاسباتی (Compute-bound) هستند؛ شما نمی‌خواهید سربار دست‌دادن‌های TLS (TLS Handshake) با چرخه پردازنده (CPU Cycles) روی همان ماشین رقابت کند. با استفاده از دستورات سخت‌افزاری AES-NI در OpenSSL، Nginx معمولاً کمتر از ۲ میلی‌ثانیه تأخیر به هر درخواست اضافه می‌کند.

برای حفظ تجربه تعاملی هوش مصنوعی، پیکربندی پروکسی باید بافرینگ را غیرفعال کند. تنظیم proxy_buffering off و chunked_transfer_encoding off تضمین می‌کند که توکن‌ها (Token) به محض تولید برای کلاینت ارسال شوند. بدون این تنظیمات، کلاینت‌ها پاسخ‌ها را به جای توکن-به-توکن، در دسته‌های بزرگ دریافت می‌کنند. این اتفاق باعث شکست انتقال‌های Server-Sent Events (SSE) می‌شود که توسط اکثر کتابخانه‌های هوش مصنوعی استفاده می‌شوند و باعث ایجاد پرش‌های محسوس در تأخیر می‌گردد.

جزئیات پیکربندی محیط عملیاتی

یک استقرار استاندارد برای هوش مصنوعی نیازمند تنظیمات دقیق برای پایداری و امنیت است:

• سخت‌سازی TLS: استفاده از ssl_protocols TLSv1.3 و مجموعه‌های رمز مدرن مانند ECDHE-ECDSA-AES256-GCM-SHA384 و ECDHE-RSA-AES256-GCM-SHA384. همچنین اجرای Strict-Transport-Security (HSTS) با max-age برابر با 63072000 برای اجبار به استفاده از HTTPS. برای بهینه‌سازی دست‌دادن‌ها، از ssl_session_cache shared:TLS_AI:10m و ssl_session_timeout یک روزه استفاده کنید.
• تنظیم زمان‌های انتظار (Timeout): به دلیل کند بودن استنتاج، مقدار proxy_read_timeout و proxy_send_timeout باید به ۳۰۰ ثانیه افزایش یابد تا ارتباط در طول تولید پاسخ‌های طولانی قطع نشود. مقدار proxy_connect_timeout را برای دست‌دادن‌های اولیه به ۱۰ ثانیه تنظیم کنید.
• محافظت از نقاط انتهایی: استفاده از بلوک‌های location برای بازگرداندن صریح خطای 403 Forbidden برای مسیرهای مدیریتی مثل /api/pull ، /api/create و /api/delete تا از تغییرات خارجی در کتابخانه مدل‌ها جلوگیری شود.
• بهینه‌سازی اتصال: استفاده از keepalive 32 در بلوک upstream برای حفظ اتصالات پایدار به هسته مدل. برای خط لوله‌های تولید بازیابی‌افزا (RAG) با حجم بالا، این کار تأخیر هر درخواست را از طریق حذف دست‌دادن‌های مکرر TCP، بین ۱۵ تا ۴۰ میلی‌ثانیه کاهش می‌دهد.
• امنیت هدرها: افزودن X-Content-Type-Options "nosniff" و X-Frame-Options "DENY" برای جلوگیری از حملات MIME-sniffing و Clickjacking.

احراز هویت لایه‌ای و اعتماد صفر

جداسازی شبکه تنها گام اول است. معماری «اعتماد صفر» (Zero Trust) ایجاب می‌کند هر درخواست، حتی آن‌هایی که از طریق لوپ‌بک محلی می‌رسند، احراز هویت شوند. این رویکرد در لایه‌های پیچیده‌تر، مانند پیاده‌سازی مرزهای Zero-Trust برای عامل‌های هوش مصنوعی در معماری MCP نیز برای جلوگیری از دسترسی‌های غیرمجاز به ابزارها به کار می‌رود. Nginx اجازه می‌دهد ترکیبی از کلیدهای API و mTLS را پیاده کنیم.

با استفاده از ماژول auth_request در Nginx، می‌توان تأیید کلیدها را به یک سرویس اعتبارسنجی سبک سپرد. این سرویس می‌تواند یک اسکریپت ساده پایتون روی پورت ۹۰۰۰ باشد که کلیدهای API هش‌شده (با استفاده از SHA-256) را در مقابل یک پایگاه داده امن یا فایل JSON بررسی می‌کند. این اسکریپت از کتابخانه‌های hashlib و hmac برای تأیید کلیدها استفاده می‌کند. اگر کلید موجود نباشد یا نامعتبر باشد، پروکسی یک خطای JSON 401 Unauthorized بازمی‌گرداند: {"error": "unauthorized", "message": "Valid API key required"}.

برای ارتباطات سرویس-به-سرویس، mTLS (TLS متقابل) تضمین قوی‌تری نسبت به کلیدهای API ارائه می‌دهد. Nginx می‌تواند گواهینامه‌های کلاینت را که توسط یک CA داخلی امضا شده‌اند، با استفاده از ssl_client_certificate اعتبارسنجی کند. با تنظیم ssl_verify_client optional یا on ، پروکسی می‌تواند هر سرویسی را که نتواند هویت خود را از طریق یک گواهینامه معتبر ثابت کند، رد کند. برای نقاط انتهایی داخلی، می‌توان از بررسی $ssl_client_verify != SUCCESS استفاده کرد تا در صورت نبود گواهینامه، خطای 403 بازگردانده شود و تضمین گردد که فقط بک‌اندهای داخلی مجاز به دسترسی به موتور استنتاج هستند.

تقویت در سطح شبکه

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

در لینوکس، می‌توان nftables یا iptables را طوری تنظیم کرد که فقط کاربر Nginx (مثلاً www-data) اجازه دسترسی به پورت هسته هوش مصنوعی را داشته باشد. یک پیکربندی استاندارد nftables ابتدا قوانین قبلی را پاک کرده و یک جدول خاص به نام ai_isolation برای فیلتر ترافیک ورودی ایجاد می‌کند. این جدول شامل زنجیره‌ای است که اتصالات برقرار شده (established) و مرتبط (related) را مجاز می‌کند، تمام ترافیک لوپ‌بک (iif "lo") را می‌پذیرد و SSH را برای مدیریت باز می‌گذارد، در حالی که دسترسی خارجی مستقیم به پورت‌های استنتاج را مسدود می‌کند.

این پشته جامع — از اتصال Localhost و پایان‌دهی TLS در Nginx تا احراز هویت لایه‌ای و فایروال — ابزار یک پژوهشگر را به یک استقرار آماده برای محیط عملیاتی تبدیل می‌کند. این تغییر در رویکرد، صنعت را از ذهنیت «اول راحتی» در استقرار مدل‌های زبانی دور کرده و با هسته‌های AI مانند پایگاه‌های داده با ارزش بالا برخورد می‌کند که نیازمند کنترل سخت‌گیرانه محیطی هستند.

برای توسعه‌دهندگان، این بدان معنای است که هزینه میزبانی شخصی دیگر فقط توان محاسباتی نیست، بلکه سربار عملیاتی مدیریت یک پروکسی امنیتی است. اما در مقابل، کنترل کامل بر محل ذخیره داده‌ها و مالکیت معنوی مدل به دست می‌آید. برای سخت‌تر کردن این پشته، پیاده‌سازی محدودیت نرخ (Rate Limiting) در لایه Nginx را بررسی کنید تا از حملات تخلیه منابع GPU توسط کاربران احراز هویت شده جلوگیری شود.

گام بعدی شما

• بررسی وضعیت اتصال سرورهای خود با دستور netstat -tulpn برای اطمینان از عدم گوش دادن روی 0.0.0.0.
• پیاده‌سازی لایه Nginx با غیرفعال کردن proxy_buffering برای پشتیبانی از استریم توکن‌ها.
• تنظیم قوانین nftables برای محدود کردن دسترسی به پورت مدل فقط برای کاربر وب‌سرور.