گوگل کلاد با انتشار یک نقشه راه امنیتی جدید، نحوه محافظت از بارهای کاری هوش مصنوعی روی موتور کوبرنیتیز گوگل (GKE) را تشریح کرده است. این سند که توسط گلن مسنجر و شانون کولاراتنا از تیم امنیت GKE تدوین شده، بر این فرض استوار است که سرعت گذار پروژه‌های هوش مصنوعی از فاز نمونه اولیه به تولید، مدل‌های امنیتی سنتی را پشت سر گذاشته و نیازمند رویکردی چندلایه است.

این نقشه راه با هدف مدیران ارشد امنیت اطلاعات و تیم‌های مهندسی پلتفرم، یک معماری سه‌لایه‌ای شامل زیرساخت، یکپارچگی مدل و امنیت برنامه پیشنهاد می‌دهد. مسنجر، مدیر محصول گروه در تیم امنیت GKE، تأکید می‌کند که تیم‌ها باید وزن‌های اختصاصی مدل را محافظت کنند، در برابر تهدیدات جدیدی مانند تزریق پرامپت مقاومت کنند و انطباق نظارتی سخت‌گیرانه را اعمال نمایند — همه این‌ها بدون ایجاد اصطکاک در مسیر توسعه‌دهندگان هوش مصنوعی.

معماری امنیتی سه‌لایه گوگل کلود برای بارهای کاری هوش مصنوعی

لایه زیرساخت: رمزگذاری سخت‌افزاری و مدیریت هویت

در سطح زیرساخت، نقشه راه گوگل استفاده از Confidential GKE Nodes را پیشنهاد می‌کند که رمزگذاری حافظه در سطح سخت‌افزار را به شتاب‌دهنده‌هایی نظیر GPUهای انویدیا H100 و TPUها تعمیم می‌دهد. ترکیب این قابلیت با Workload Identity Federation به پادهای استنتاج اجازه می‌دهد وزن‌های مدل را از Cloud Storage بدون نیاز به کلیدهای پایدار و طولانی‌مدت دریافت کنند. در کنار این موارد، VPC Service Controls به مدیران امکان می‌دهد یک محیط امنیتی (Perimeter) در اطراف داده‌های نظارت‌شده ایجاد کنند و از نشت اطلاعات جلوگیری نمایند.

«شما نمی‌توانید یک بار کاری هوش مصنوعی امن روی یک خوشه ناامن داشته باشید.»

— تیم GKE گوگل کلود، امن‌سازی هوش مصنوعی در مقیاس سازمانی

لایه مدل: صورت‌های مواد هوش مصنوعی

گوگل اشاره می‌کند که صورت‌های مواد نرم‌افزاری سنتی (SBOM) مصنوعات اختصاصی هوش مصنوعی مانند مجموعه‌داده‌ها و چارچوب‌ها را پوشش نمی‌دهند. به همین دلیل، این نقشه راه k8s-aibom را معرفی می‌کند؛ یک کنترلر متن‌باز کوبرنیتیز که به‌طور خودکار صورت‌های مواد هوش مصنوعی (AIBOM) تولید می‌کند و شفافیت کاملی در خصوص اجزای مدل فراهم می‌سازد.

کنترلر k8s-aibom برای تولید خودکار صورت‌های مواد هوش مصنوعی

لایه برنامه: دفاع در برابر تزریق پرامپت

در لایه برنامه، Model Armor پرامپت‌ها و پاسخ‌ها را برای شناسایی تلاش‌های تزریق، نشت داده‌های حساس و محتوای مضر بازرسی می‌کند. همچنین GKE Sandbox که بر پایه فناوری ایزوله‌سازی gVisor ساخته شده، برای مهار عامل‌های هوش مصنوعی که کدهای تولیدشده را اجرا می‌کنند یا ابزارهای نامعتبر را فراخوانی می‌کنند توصیه می‌شود. این ترکیب، یک محیط اجرایی ایزوله فراهم می‌کند که خطر نفوذ از طریق کدهای مخرب تولیدشده توسط مدل را به حداقل می‌رساند.

استقرار سه‌مرحله‌ای: Deploy، Operate، Govern

گوگل یک استقرار مرحله‌ای را با سه فاز پیشنهاد می‌دهد:

  • Deploy (استقرار): اعمال کنترل‌های پایه مانند فعال‌سازی Workload Identity و اجرای بارهای کاری حساس روی Confidential Nodes.
  • Operate (عملیات): سخت‌سازی محیط تولید از طریق سیاست‌های تصویر امضاشده و تجمیع لاگ‌ها برای نظارت پیوسته.
  • Govern (حاکمیت): اعمال حفاظ‌های گسترده سازمانی و پاسخ خودکار به حوادث امنیتی.

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

رقابت در حوزه راهنمایی‌های امنیتی هوش مصنوعی

گوگل تنها بازیگر این زمینه نیست. آمازون وب سرویسز (AWS) نیز با چارچوب امنیت هوش مصنوعی خود رویکردی لایه‌ای مشابه اتخاذ کرده و آن را با ابتکار متن‌بازی به نام AI on EKS ترکیب کرده است که طرح‌های Terraform برای استقرار بارهای کاری هوش مصنوعی روی سرویس کوبرنیتیز مدیریت‌شده آمازون ارائه می‌دهد.

AWS همچنین تشخیص تهدیدات Amazon GuardDuty را به خوشه‌های EKS گسترش داده و از یک عامل مدیریت‌شده eBPF برای شناسایی سرقت اعتبار و پوسته‌های معکوس مستقیماً روی صفحه داده کوبرنیتیز استفاده می‌کند — مطلبی که InfoQ در ژوئن ۲۰۲۵ به آن پرداخته بود.

نقد ابزارهای بومی از زبان ARMO

با این حال، شرکت امنیتی ARMO نقد مفصلی منتشر کرده و نشان داده است که ابزارهای بومی AWS در نقاط خاصی برای تهدیدات هوش مصنوعی کارایی خود را از دست می‌دهند. یوسی بن نعیم، معاون مدیریت محصول در ARMO، در راهنمایی درباره امن‌سازی عامل‌های هوش مصنوعی روی EKS می‌نویسد:

«ابزارهای بومی AWS هویت، رمزگذاری و لاگ‌برداری صفحه کنترل را به‌خوبی مدیریت می‌کنند، اما در مرز بار کاری متوقف می‌شوند و یک نقطه کور دقیقاً در جایی که تهدیدات هوش مصنوعی عاملیت‌دار رخ می‌دهد به جا می‌گذارند: در داخل کانتینرهای شما، در زمان اجرا، جایی که عامل‌ها تصمیمات مستقلی درباره فراخوانی ابزارها و دسترسی به داده‌ها می‌گیرند.»

استدلال محوری بن نعیم این است که ابزارهای هویت و ممیزی مانند IAM Roles for Service Accounts و CloudTrail logging به سؤالات «چه کسی» و «چه زمانی» پاسخ می‌دهند، اما توانایی نظارت بر رفتار عامل‌های هوش مصنوعی در زمان اجرا را ندارند. این دقیقاً همان نقطه‌ای است که خطرات نوظهور مانند دسترسی غیرمجاز عامل‌ها به ابزارهای خارجی، ارسال داده‌های حساس به سرویس‌های شخص ثالث و اجرای کدهای مخرب تولیدشده توسط مدل شکل می‌گیرد.

تلاش هم‌زمان گوگل و آمازون برای ارائه چارچوب‌های امنیتی اختصاصی هوش مصنوعی نشانگر یک تحول بنیادین در نگاه صنعت به امنیت ابری است؛ جایی که مرز بین امنیت زیرساخت و امنیت مدل‌های هوش مصنوعی به‌تدریج محو می‌شود و پلتفرم‌های مدیریت‌شده باید لایه‌های حفاظتی را به‌صورت یکپارچه ارائه دهند. پرسش کلیدی این است که آیا این چارچوب‌های لایه‌ای می‌توانند با سرعت رشد تهدیدات عاملیت‌دار همگام بمانند، یا تیم‌های امنیتی همچنان به ابزارهای تخصصی زمان اجرا نیاز خواهند داشت.