دیودهای یک‌طرفه در برابر شبکه‌های کفشی؛ امنیت واقعی در خوشه‌های GPU

قطع کردن کابل‌های اترنت از رکی یک خوشه NVIDIA H100، آن را غیرقابل نفوذ نمی‌کند؛ بلکه فقط مسیر حمله را به بسته‌های پایتون آلوده و وزن‌های مدل‌های دست‌کاری‌شده تغییر می‌دهد. به نقل از گزارش آصف محمد اقبال، مؤسس و مدیرعامل Logic42، رویه رایج «ایزوله‌سازی» (Air-gapping) در صنعت، به‌جای ایجاد یک محیط امن، اغلب منجر به شکل‌گیری جزیره‌ای از نرم‌افزارهای به‌روزنشده و پرخطر می‌شود.

او استدلال می‌کند که ایزولاسیون فیزیکی تنها یک مرز سخت‌افزاری است، نه یک استراتژی جامع امنیتی. بسیاری از بخش‌های حساس — از جمله پیمانکاران دفاعی، بانک‌های ملی، اپراتورهای مخابراتی و ارائه‌دهندگان خدمات بهداشتی — برای استقرار مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تقاضای جداسازی کامل شبکه دارند. مدیران امنیتی معمولاً دستور می‌دهند: «آن را در یک مرکز ایزوله قرار دهید؛ هیچ دسترسی به اینترنت نباشد.»

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

تله زنجیره تأمین

پشته‌های نرم‌افزاری مدرن هوش مصنوعی، گراف‌های وابستگی عظیم و تو در تویی هستند. یک محیط استاندارد که از PyTorch، vLLM و Transformers استفاده می‌کند، معمولاً بیش از ۳۰۰ بسته پایتون، باینری‌های C++ و کرنل‌های کامپایل‌شده CUDA را فراخوانی می‌کند. وقتی این‌ها به‌صورت دستی کپی می‌شوند، سه حالت شکست بحرانی رخ می‌دهد:

• بسته‌های Trojan PyPI: مهاجمان با روش «تایپو-اسکواتینگ» (Typo-squatting)، بسته‌های مخرب (مثل یک نسخه جعلی از triton-cuda-opt) را در PyPI آپلود می‌کنند. مهندسی که اسکریپت آینه آفلاین می‌سازد، ممکن است این بسته را دریافت کند. این بسته مخرب، حافظه NVMe محلی را برای یافتن وزن‌های مدل یا اعتبارنامه‌های پایگاه‌داده اسکن کرده و آن‌ها را در یک بافر مخفی ذخیره می‌کند تا در اولین فرصت که لاگ‌های تشخیصی برای پشتیبانی سازنده صادر شد، خارج شود.
• درهای پشتی در وزن‌های مدل: اگرچه فرمت Safetensors برای جایگزینی فایل‌های pickle طراحی شد — چون pickle اجازه اجرای کدهای دلخواه هنگام بازخوانی را می‌دهد — اما تیم‌ها هنوز نقاط بازرسی (Checkpoints) قدیمی با پسوند .bin یا .pth را وارد می‌کنند. یک فراخوانی ساده torch.load() روی یک چک‌پوینت مخرب PyTorch می‌تواند دستورات شل (Shell) دلخواهی را درون محیط امن اجرا کند. این ریسک‌ها در فرآیندهای بهینه‌سازی مدل نیز وجود دارد؛ برای مثال در تبدیل مدل‌های بزرگ به نسخه‌های متراکم برای محیط‌های بدون ابر، دقت در تأیید سلامت وزن‌های مدل حیاتی است.
• آسیب‌پذیری‌های قدیمی درایور: وصله کردن دستی نرم‌افزارها بسیار دشوار است. برای مثال، وصله‌های حیاتی مانند CVE-2024-0107 که اجازه فرار از کانتینر و ارتقای سطح دسترسی در گره‌های میزبان GPU را می‌داد، در محیط‌های ایزوله به‌دلیل رویه‌های انتقال دستی، ۶ تا ۱۲ ماه تأخیر داشتند.

مقایسه معماری‌های ایزولاسیون

برای درک ریسک، باید سطوح آسیب‌پذیری را مقایسه کرد. یک خوشه ابری استاندارد، دسترسی کامل ورودی/خروجی و وصله‌های خودکار لحظه‌ای دارد، اما در برابر حملات Zero-day RCE و نشت API آسیب‌پذیر است. یک رک ایزوله ساده، در حالی که کاملاً قطع است، به «شبکه کفشی» (Sneakernet یا انتقال با USB) متکی است که بسته‌های تروجان و CVEهای قدیمی CUDA را وارد می‌کند. حالت ایده‌آل، یک «خط لوله دیود سخت‌افزاری» است که از یک دیود داده‌ای برای جریان یک‌طرفه، تأیید رمزنگاری‌شده و وصله‌های خودکار دوهفته‌یک‌بار استفاده می‌کند. این رویکرد برای جلوگیری از ریسک‌های سخت‌افزاری گسترده در لایه‌ی نظارتی که می‌تواند منجر به افشای منابع حیاتی شود، ضروری است.

ساخت خط لوله دیود سخت‌افزاری

شرکت Logic42 برای جلوگیری از فروپاشی عملیاتی، یک «خط لوله دریافت خودکار دیود» را توصیه می‌کند. در این سیستم، داده‌ها از طریق یک سرور میانی (DMZ) منتقل می‌شوند که بسته‌ها و Safetensors را دانلود می‌کند. سپس این مصنوعات تحت اسکن بدافزار استاتیک و اسکن YARA برای باینری‌های C++ و هدرهای تنسور قرار می‌گیرند. هر فایل سپس با استفاده از یک ماژول امنیتی سخت‌افزاری (HSM) داخلی و کلید خصوصی PKI سازمانی امضا می‌شود و از طریق یک لینک نوری یک‌طرفه فیزیکی به یک نمونه داخلی Harbor منتقل می‌گردد. در نهایت، Harbor امضای Cosign را تأیید می‌کند و اجازه می‌دهد Kubernetes آن را دریافت کند.

چهار کنترل اجباری برای این معماری لازم است:

• اجبار به فرمت سخت‌گیرانه: الزام استفاده از فرمت .safetensors برای تمام وزن‌های مدل و مسدود کردن تمام پسوندهای .bin ،.pth و .pkl در مرز ورود.
• امضای رمزنگاری‌شده: استفاده از Cosign یا Sigstore متصل به HSM داخلی برای امضای هر ایمیج کانتینر، بسته پایتون و فایل وزن مدل. کنترل‌کننده پذیرش (Admission Controller) کلاستر کوبرنتیز باید هر ایمیجی را که توسط PKI داخلی امضا نشده، مسدود کند.
• آینه‌سازی محلی موقت: استفاده از نمونه‌های داخلی Artifactory یا Harbor در داخل محیط ایزوله. مهندسان هرگز نباید اجازه داشته باشند فایل‌های خام را مستقیماً روی گره‌های GPU کپی کنند.
• بازرسی باینری: اجرای تحلیل استاتیک خودکار با ابزارهایی مثل Ghidra یا مجموعه‌قوانین YARA روی اشیاء مشترک C++ (فایل‌های .so) درون بسته‌های پایتون پیش از تأیید ورود.

حل مشکل «تماس با خانه»

بسیاری از فریم‌ورک‌های متن‌باز دارای تله‌متری پیش‌فرضی هستند که سعی می‌کنند با سرورهای تحلیل خارجی تماس بگیرند. در یک شبکه قطع‌شده، این تماس‌ها منجر به توقف رشته‌ها (Thread hangs)، افزایش تأخیر یا پر شدن دیسک‌های محلی با لاگ‌های تکراری می‌شود. هنگام استقرار موتورهایی مثل vLLM، Ollama یا HuggingFace TGI، اپراتورها باید پرچم‌های محیطی را در مانیفست‌های استقرار کوبرنتیز تنظیم کنند تا تماس‌های شبکه خروجی متوقف شود:

• تنظیم HF_HUB_OFFLINE=1 و TRANSFORMERS_OFFLINE=1 برای توقف تماس‌های HuggingFace.
• تنظیم VLLM_NO_USAGE_STATS=1 و DO_NOT_TRACK=1 برای غیرفعال کردن تله‌متری vLLM.
• تنظیم NCCL_DEBUG=INFO برای تشخیص مشکلات NVLink بین GPUها در حالت آفلاین.

نظارت در سطح کرنل با eBPF

از آنجایی که سیستم‌های تشخیص نفوذ شبکه (IDS) سنتی بدون ترافیک خارجی بی‌فایده هستند، امنیت باید به سطح کرنل منتقل شود. با استقرار پروب‌های eBPF (فیلتر بسته پکت برکلی گسترش‌یافته) روی گره‌های میزبان (مانند Ubuntu 24.04 LTS)، مدیران می‌توانند هر فراخوانی execve (اجرای فرآیند) و sys_connect (درخواست سوکت) را ردیابی کنند.

اگر یک کانتینر آلوده سعی کند یک زیرفرآیند غیرمنتظره مثل /bin/nc ایجاد کند، فضاهای حافظه را جست‌وجو کند یا یک پورت داخلی را برای اسکن سرورهای ذخیره‌سازی همسایه باز کند، پروب eBPF این ناهنجاری را در میکروثانیه تشخیص می‌دهد. سپس سیستم می‌تواند فوراً PID کانتینر را بکشد و ردپای حسابرسی را در یک خزانه محلی WORM (فقط یک‌بار نوشتنی) ثبت کند.

این تغییر در معماری، تمرکز امنیتی را از «محیط پیرامونی» به «منشأ کد» منتقل می‌کند. اثر مرتبه دوم این تحول، حرکت به سمت «حاکمیت محاسباتی» است؛ جایی که توانایی تأیید تک‌تک بیت‌های داده‌های ورودی، ارزشمندتر از یک دیوار فیزیکی است.

گام بعدی شما

• تمام وزن‌های مدل‌های موجود در محیط تولید را بررسی کنید تا مطمئن شوید هیچ فایل .pth یا .bin تأییدنشده‌ای وارد نشده است.
• پرچم‌های آفلاین vLLM و HuggingFace را در مانیفست‌های استقرار خود فعال کنید تا از توقفات ناگهانی سیستم جلوگیری شود.
• برای نظارت بر رفتارهای مشکوک در محیط‌های ایزوله، استقرار پروب‌های eBPF را در اولویت قرار دهید.

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