وقتی محیط ایزوله از کار می‌افتد: چرا مهار مدل‌های هوش مصنوعی به یکی از ارکان جدید امنیت سازمانی تبدیل می‌شود
نویسنده: سری‌کانت آر. پی |
OpenAI محیط آموزش مدل‌های پیشرفته هوش مصنوعی خود را ایمن‌تر کرده است. این شرکت در مرحله یادگیری تقویتی، دسترسی به اینترنت را محدود کرد، جداسازی میان محیط‌های محاسباتی را تقویت کرد و سپس مجموعه‌ای از عامل‌های پیشرفته هوش مصنوعی را به کار گرفت تا بررسی کند آیا این تدابیر در برابر حمله‌ای هدفمند دوام می‌آورند یا خیر.
نتیجه نشان داد که این تدابیر به‌طور کامل کافی نیستند. آزمایش‌ها ضعف‌هایی را آشکار کردند که کنترل‌های امنیتی متعارف نتوانسته بودند به‌طور کامل برطرف کنند.
OpenAI در گزارشی که ۲۳ اکتبر ۲۰۲۶ منتشر کرد، توضیح داد عامل‌های تیم قرمز این شرکت آسیب‌پذیری‌های نرم‌افزاری ناشناخته و پیکربندی‌های نادرست زیرساختی را کشف کرده‌اند. این ضعف‌ها، از جمله، امکان خروج از مرزهای ماشین مجازی، سوءاستفاده از سرویس‌هایی با اتصال محدود به شبکه‌های بیرونی و برقراری ارتباط میان محیط‌هایی را فراهم می‌کردند که قرار بود از یکدیگر جدا باشند؛ آن هم از طریق منابع محاسباتی مشترک.
OpenAI این آسیب‌پذیری‌ها را برطرف کرد، محدودیت‌های شبکه را افزایش داد و سازوکارهای نظارتی و توقف خودکار را تقویت کرد. این شرکت همچنین با ارائه‌دهندگان خدمات ابری و نگه‌دارندگان پروژه‌های متن‌باز همکاری کرد تا شکاف‌های امنیتی زیرساخت گسترده‌تر خود را ببندد. در جریان این اقدامات، آموزش و ارزیابی توانمندترین مدل‌های شرکت موقتاً متوقف شده بود. پس از انجام بررسی‌های امنیتی و اقدامات تکمیلی، آموزش یادگیری تقویتی و استنتاج داخلی در اول اکتبر از سر گرفته شد.
یکی از تصمیم‌های این شرکت اهمیت ویژه‌ای دارد: OpenAI محیطی آفلاین متشکل از محتوای وب نمایه‌سازی‌شده و ذخیره‌شده در حافظه نهان ایجاد کرد تا مدل‌ها بتوانند وظایفی مانند مرور وب، جست‌وجو و انجام کارهای مبتنی بر وب را بدون اتصال به وب‌سایت‌های زنده تمرین کنند. اکنون اجراهای یادگیری تقویتی مدل‌های پیشرفته این شرکت از همین روش استفاده می‌کنند. هدف آن است که قابلیت‌های کاربردی مدل‌ها حفظ شود و در عین حال احتمال اثرگذاری آن‌ها بر سامانه‌های خارج از محیط مجاز کاهش یابد.
همه این اقدامات بر یک اصل اساسی استوارند: محدودیت‌های اعمال‌شده بر یک عامل هوش مصنوعی باید حتی زمانی پابرجا بمانند که عامل فعالانه برای دور زدن آن‌ها تلاش می‌کند.
این اصل فراتر از پژوهش درباره مدل‌های پیشرفته است و به حوزه‌ای اشاره دارد که مدیران فناوری سازمان‌ها بیش از پیش باید با آن آشنا شوند: مهار مدل‌های هوش مصنوعی.
چرا مهار مدل‌ها به یک حوزه تخصصی مستقل تبدیل شده است؟
امنیت سازمانی از مدت‌ها پیش بر حفاظت از شبکه‌ها، مدیریت هویت و دسترسی، رفع آسیب‌پذیری‌ها و جداسازی بارهای کاری متمرکز بوده است. این کنترل‌ها همچنان ضروری‌اند، اما عامل‌های توانمند هوش مصنوعی مسئله متفاوتی ایجاد می‌کنند.
یک عامل هوش مصنوعی لازم نیست منتظر بماند تا مهاجمی از یک ضعف امنیتی سوءاستفاده کند. این عامل می‌تواند محیط خود را بررسی کند، کد اجرا کند، روش‌های جایگزین را بیازماید و برای رسیدن به هدفی مشخص، چند ضعف کوچک را به یکدیگر پیوند دهد. اگر با محدودیتی مواجه شود، ممکن است به‌صورت نظام‌مند مسیرهای دیگری را بررسی کند. هنگامی که مدل با اهداف تعیین‌شده همسو نیست، به خطر افتاده است یا هدفی ناخواسته را دنبال می‌کند، توانایی استدلال و اقدام آن می‌تواند یک نقص نرم‌افزاری معمولی را به مسئله‌ای امنیتی با ابعادی بسیار گسترده‌تر تبدیل کند.
بنابراین، مهار مدل باید فراتر از کنترل دسترسی متعارف باشد. پرسش دیگر فقط این نیست که آیا عامل اجازه انجام کاری را دارد یا خیر. تیم‌های امنیتی باید بررسی کنند که آیا عامل می‌تواند از محیط اجرای خود خارج شود، امتیازهای بیشتری به دست آورد، به سامانه‌های غیرمجاز دسترسی پیدا کند یا از کانال‌هایی ارتباط برقرار کند که مدیران هرگز تأیید نکرده‌اند.
مهار مدل، جداسازی زیرساخت، امنیت شبکه، کنترل هویت، نظارت و مداخله خودکار را در کنار یکدیگر قرار می‌دهد تا پیامدهای چنین رفتارهایی محدود شود. این رویکرد فرض نمی‌کند که همه مدل‌ها برای فرار از محدودیت‌ها تلاش خواهند کرد؛ بلکه چنین احتمالی را سناریویی می‌داند که باید آن را آزمایش کرد.
تجربه OpenAI چهار نمونه مشخص از این رویکرد را نشان می‌دهد.
۱. اگر محیط ایزوله شکست بخورد، سایر لایه‌های زیرساخت باید مقاومت کنند
محیط سندباکس دسترسی‌ها و قابلیت‌های اجرایی یک برنامه را محدود می‌کند. ماشین مجازی نیز با جدا کردن محیط اجرا از میزبان، لایه حفاظتی دیگری به وجود می‌آورد.
عامل‌های تیم قرمز OpenAI راه‌هایی برای زنجیره‌کردن آسیب‌پذیری‌های نرم‌افزاری و خروج از محیط ماشین مجازی پیدا کردند. این شرکت اعلام کرد که اصلاحاتی را در مؤلفه‌هایی از جمله Kata Containers، gVisor و Moby/Docker انجام داده است. درس این اتفاق آشناست: معماری‌هایی که به یک مرز امنیتی واحد متکی‌اند، در صورت شکسته‌شدن آن مرز ممکن است به نفوذگر توانایی‌هایی بدهند که هرگز قرار نبوده در اختیارش قرار گیرد.
برای نمونه، تصور کنید یک عامل سازمانی کد منبع را تحلیل می‌کند و اسکریپت‌ها را در محیطی موقت اجرا می‌کند. اگر این عامل راهی برای خروج از محیط پیدا کند، پیامدهای آن به اتفاقات بعدی بستگی دارد. آیا می‌تواند به سیستم‌عامل میزبان دسترسی پیدا کند؟ اعتبارنامه‌ها را بخواند؟ به بار کاری دیگری دسترسی داشته باشد؟ یا از اتصال شبکه میزبان برای برقراری ارتباط با یک سرور خارجی استفاده کند؟
رویکرد متعارف بر جلوگیری از خروج اولیه تمرکز می‌کند. اما رویکرد مبتنی بر مهار، احتمال وقوع این خروج را نیز در نظر می‌گیرد و می‌پرسد آیا کنترل‌های مستقل همچنان می‌توانند مانع دسترسی‌های بعدی شوند. OpenAI به همین دلیل از ترکیبی از کانتینرهای محدودشده، ماشین‌های مجازی، جداسازی از طریق هایپروایزر، محدودیت‌های شبکه، کنترل‌های امنیت ابری و سامانه‌های نظارتی استفاده می‌کند.
پیام این تجربه برای معماران سازمانی روشن است: خروج از سندباکس باید یک رویداد امنیتی جدی تلقی شود، اما نباید به‌طور خودکار به معنای به‌خطر افتادن کل زیرساخت باشد.
۲. یک اتصال مجاز می‌تواند به دروازه‌ای ناخواسته تبدیل شود
OpenAI همچنین بررسی کرد که اگر یک عامل کنترل ماشین میزبان را به دست بگیرد و بخواهد به اینترنت زنده متصل شود، چه اتفاقی خواهد افتاد.
اتصال به شبکه‌های خارجی محدود شده بود، اما برخی ارتباط‌ها برای خدماتی مانند جمع‌آوری شاخص‌های عملکرد، ثبت گزارش‌ها و مدیریت احراز هویت همچنان ضروری بودند. عامل‌های تیم قرمز در تعدادی از این سرویس‌ها ضعف‌هایی پیدا کردند که مسیرهای محدودی برای خروج از محیط ایجاد می‌کردند. در یک مورد، عامل از اتصالی که فایروال اجازه آن را داده بود دوباره استفاده کرد تا به نقطه پایانی مسدودشده احراز هویت در یک سرویس جمع‌آوری شاخص‌ها دسترسی پیدا کند و سپس آن نقطه پایانی را وادار کند نشانی اینترنتی‌ای را دریافت کند که مدل ارائه کرده بود. آزمایش‌های دیگر نیز پیکربندی‌های نادرست مرتبط با سامانه نام دامنه (DNS)، کنترل‌های فایروال و سرویس‌های قادر به دریافت نشانی‌های اینترنتی خارجی را آشکار کردند.
خود اتصال مجاز، به‌تنهایی، مشکل نبود. خطر از نحوه تعامل آن اتصال با سرویس پشت آن و سطح دسترسی‌های موجود برای عامل ناشی می‌شد.
همین الگو ممکن است در یک بانک، شرکت بیمه یا کارخانه نیز تکرار شود. عاملی که مجاز است اطلاعات را از یک سامانه نظارت داخلی دریافت کند، ممکن است با سامانه‌ای در ارتباط باشد که خود توانایی ارسال درخواست به سرویس‌های دیگر را دارد. اگر عامل بتواند این درخواست‌ها را دست‌کاری کند یا از نقصی در سامانه سوءاستفاده کند، ممکن است از یک سرویس مورد اعتماد برای دسترسی به منابعی استفاده کند که مجوز دسترسی مستقیم به آن‌ها را ندارد.
ازاین‌رو، مهار مؤثر مستلزم بررسی مسیرهای غیرمستقیم دسترسی است، نه صرفاً اتصال‌های مستقیم شبکه. مدیران ارشد فناوری اطلاعات (CIO) و مدیران ارشد امنیت اطلاعات (CISO) باید بپرسند کدام سرویس‌ها می‌توانند از طرف یک عامل اقدام کنند، آیا این سرویس‌ها درخواست‌ها را به‌درستی اعتبارسنجی می‌کنند و آیا یک بار کاری به‌خطر افتاده می‌تواند اتصال تأییدشده را به دروازه‌ای ناخواسته تبدیل کند. همین پرسش‌ها درباره سامانه‌های هویت، ابزارهای مشاهده‌پذیری، سرویس‌های پردازش اسناد و رابط‌های برنامه‌نویسی داخلی (API) نیز صدق می‌کنند.
۳. دو عامل ایزوله ممکن است همچنان راهی برای ارتباط پیدا کنند
شاید شگفت‌انگیزترین یافته، امکان برقراری ارتباط میان عامل‌هایی بود که قرار نبود هیچ اطلاعاتی را با یکدیگر مبادله کنند.
در یکی از آزمایش‌ها، به عامل‌هایی که در ماشین‌های مجازی جداگانه اجرا می‌شدند دستور داده شد بدون استفاده از اتصال شبکه یا فایل‌های مشترکِ قابل‌نوشتن، اسرار ساختگی را با یکدیگر مبادله کنند. آن‌ها با سوءاستفاده از زمان‌بندی حافظه نهان پردازنده موفق شدند. حافظه نهان پردازنده داده‌هایی را که اخیراً به آن‌ها دسترسی پیدا شده نگه می‌دارد تا بازیابی‌شان سریع‌تر از خواندن آن‌ها از حافظه اصلی باشد. یکی از عامل‌ها با تغییر رفتار حافظه نهان، سیگنالی ارسال کرد و عامل دیگر با اندازه‌گیری تفاوت‌های زمانی آن سیگنال را رمزگشایی کرد. OpenAI همچنین از کانال‌های احتمالی دیگری مرتبط با فضای ذخیره‌سازی مشترک، فعالیت پردازنده و حافظه نهان گواهی‌های TLS نام برد.
این روش‌ها «کانال‌های پنهان» نام دارند؛ یعنی اطلاعات می‌توانند از طریق منابع مشترک منتقل شوند، حتی اگر ارتباطات متعارف مسدود شده باشند.
سازمانی را در نظر بگیرید که چند عامل را در محیط‌های جداگانه اجرا می‌کند. یک عامل به داده‌های مالی محرمانه رسیدگی می‌کند و عامل دیگری به ابزارها یا منابع خارجی متفاوتی دسترسی دارد. قوانین شبکه و مجوزهای فایل مانع ارتباط مستقیم آن‌ها می‌شوند، اما اگر این عامل‌ها سخت‌افزار یا سرویس‌های زیربنایی مشترکی داشته باشند، ممکن است همین منابع مسیر پیش‌بینی‌نشده‌ای برای انتقال اطلاعات فراهم کنند.
وجود چنین کانال‌هایی به این معنا نیست که همه محیط‌های محاسباتی مشترک ناامن‌اند. بهره‌برداری از این مسیرها ممکن است دشوار باشد و ظرفیت انتقال اطلاعات آن‌ها نیز محدود بماند. بااین‌حال، این یافته نشان می‌دهد که نمی‌توان ایزوله‌بودن یک محیط را صرفاً با تأیید مسدودبودن ترافیک شبکه و اشتراک‌گذاری فایل‌ها ارزیابی کرد. برای بارهای کاری حساس، ممکن است جداسازی قوی‌تر، محدودکردن منابع مشترک و آزمایش‌هایی برای شناسایی کانال‌های جانبی ضروری باشد. سطح حفاظت باید متناسب با حساسیت داده‌ها و هزینه احتمالی نقض امنیت تعیین شود.
۴. هوش مصنوعی می‌تواند امنیت را در مقیاسی فراتر از روش‌های سنتی آزمایش کند
OpenAI به اصلاح ضعف‌های شناخته‌شده بسنده نکرد. این شرکت مجموعه‌هایی از عامل‌های مبتنی بر مدل‌های پیشرفته را برای یافتن آسیب‌پذیری‌های بیشتر به کار گرفت و سه هدف برای آن‌ها تعیین کرد: دسترسی به اینترنت زنده، عبور از مرزهای امنیتی داخلی و برقراری ارتباط میان محیط‌هایی که باید ایزوله می‌ماندند.
این شرکت سناریوهایی را نیز آزمایش کرد که در آن‌ها فرض می‌شد لایه‌های امنیتی داخلی شکست خورده‌اند. با سپردن کنترل یک ماشین میزبان به عامل‌ها، OpenAI توانست بررسی کند که آیا حفاظت‌های شبکه و فضای ابری همچنان مانع دسترسی غیرمجاز به اینترنت می‌شوند یا خیر. این آزمایش‌ها روی نسخه‌هایی مستقل و اختصاصی از زیرساخت پژوهشی اجرا شدند و سامانه‌های نظارتی و کنترل‌های خودکاری داشتند که هر فعالیت خارج از محدوده مجاز را متوقف می‌کردند.
OpenAI اعلام کرد که برای این تمرین‌ها صدها میلیارد توکن مصرف کرده است. با پیشرفت آزمایش‌ها، تعداد یافته‌های احتمالی با اولویت بالا به‌طور چشمگیری کاهش یافت؛ هرچند شرکت هشدار داد که مدل‌های آینده ممکن است آسیب‌پذیری‌هایی را کشف کنند که امروز هنوز ناشناخته‌اند.
این رویکرد نشان می‌دهد هوش مصنوعی چگونه می‌تواند اطمینان از امنیت سامانه‌ها را تقویت کند. ابزارهای اسکن آسیب‌پذیری در شناسایی دسته‌های شناخته‌شده ضعف عملکرد خوبی دارند. متخصصان آزمون نفوذ نیز می‌توانند مسیرهای پیچیده حمله را بررسی کنند، اما زمان آن‌ها محدود است. عامل‌های هوش مصنوعی قادرند روش‌های متعددی را بیازمایند، روابط میان سرویس‌ها را بررسی کنند و بارها آزمایش کنند که آیا می‌توان ضعف‌های مختلف را به یکدیگر پیوند داد یا خیر.
البته هیچ‌یک از این قابلیت‌ها جای متخصصان باتجربه امنیت را نمی‌گیرد. یافته‌ها همچنان باید بازتولید، اولویت‌بندی و راستی‌آزمایی شوند و عامل‌های آزمایش‌کننده نیز باید از سامانه‌های عملیاتی واقعی دور نگه داشته شوند. بااین‌حال، این روش زمینه را برای آزمایش‌های مستمرتر در برابر راهبردهای حمله‌ای فراهم می‌کند که روزبه‌روز پیچیده‌تر می‌شوند.
پنج اولویت برای مدیران ارشد فناوری اطلاعات
مهار مدل یک محصول یا گزینه قابل‌تنظیم در نرم‌افزار نیست؛ بلکه رویکردی معماری است که بر این فرض استوار است که عامل هوش مصنوعی ممکن است برای انجام اقداماتی خارج از محدوده تعیین‌شده خود تلاش کند. پنج اولویت اصلی در این زمینه عبارت‌اند از:
- برای هر عامل، مرز امنیتی مشخصی تعریف کنید. تعیین کنید عامل به کدام داده‌ها، ابزارها، سرویس‌ها و سامانه‌ها دسترسی دارد. از اعطای مجوزهای گسترده صرفاً به این دلیل که ساخت گردش کار را آسان‌تر می‌کنند، خودداری کنید.
- برای شکست کنترل‌های منفرد آماده باشید. سندباکس‌کردن برنامه‌ها، مجازی‌سازی، محدودیت‌های هویتی، بخش‌بندی شبکه و سیاست‌های امنیت ابری را با یکدیگر ترکیب کنید و سپس آزمایش کنید که آیا نفوذ به یک لایه می‌تواند سایر لایه‌ها را نیز در معرض خطر قرار دهد یا خیر.
- دسترسی مستقیم به اینترنت زنده را محدود کنید. تنها زمانی اتصال خارجی بدهید که انجام وظیفه به آن نیاز داشته باشد. در صورت امکان، از منابع داده کنترل‌شده، محتوای ذخیره‌شده در حافظه نهان یا دروازه‌های تأییدشده استفاده کنید و مسیرهای غیرمستقیم از طریق سرویس‌های داخلی را نیز اعتبارسنجی کنید.
- رفتارها را زیر نظر بگیرید و امکان مداخله داشته باشید. تلاش برای عبور از مرزهای امنیتی، بررسی سرویس‌های غیرمجاز یا سوءاستفاده از قابلیت‌های پیش‌بینی‌نشده را شناسایی کنید. اطمینان یابید که هشدارهای جدی می‌توانند به توقف سریع یا خاموش‌کردن عامل منجر شوند و این سازوکارها را در شرایط نامطلوب نیز آزمایش کنید.
- آزمایش‌های تیم قرمز را به فرایندی مستمر تبدیل کنید. هر زمان مدل‌ها، ابزارها، مجوزها، نرم‌افزارها یا زیرساخت تغییر می‌کنند، تدابیر مهار را دوباره ارزیابی کنید. از آزمایش‌های کنترل‌شده و کمک‌گرفته از هوش مصنوعی برای یافتن ضعف‌ها پیش از بهره‌برداری از آن‌ها در محیط عملیاتی استفاده کنید.
این اقدامات باید بخشی از حاکمیت هوش مصنوعی در سازمان، بازبینی‌های امنیت ابری و فرایندهای توسعه نرم‌افزار باشند و نباید صرفاً بر عهده تیم‌هایی گذاشته شوند که روی مدل‌ها آزمایش انجام می‌دهند.
محدود کردن پیامدهای شکست
اقدامات OpenAI از تغییری گسترده‌تر در شیوه نگرش سازمان‌ها به امنیت هوش مصنوعی حکایت دارد. هدف این نیست که فرض کنیم همه مدل‌ها رفتاری مخرب خواهند داشت یا ادعا کنیم هر معماری امنیتی می‌تواند تمام آسیب‌پذیری‌ها را از بین ببرد. هدف آن است که توانایی‌های یک مدل هرگز به‌طور خودکار به اختیار نامحدود تبدیل نشوند.
عاملی که می‌تواند کد بنویسد، نباید خودبه‌خود کنترل میزبان اجراکننده آن کد را نیز در اختیار بگیرد. عاملی که به یک سرویس داخلی دسترسی دارد، نباید بتواند بدون محدودیت از آن سرویس به‌عنوان دروازه‌ای برای ورود به سامانه‌های خارجی استفاده کند. همچنین، نباید صرفاً به دلیل مسدودبودن ارتباطات شبکه فرض کرد دو عامل که قرار است مستقل از یکدیگر فعالیت کنند، کاملاً ایزوله هستند.
برای مدیران ارشد فناوری اطلاعات، این تحول به معنای تغییر در فلسفه طراحی است: به‌جای تمرکز صرف بر حفاظت از کنترل‌های منفرد، باید نشان داد که کل سامانه حتی در صورت شکست برخی از این کنترل‌ها نیز ایمن باقی می‌ماند. هرچه سازمان‌ها از هوش مصنوعی مکالمه‌محور به سوی عامل‌هایی حرکت کنند که کد اجرا می‌کنند، داده‌ها را تغییر می‌دهند و برنامه‌های کسب‌وکار را به کار می‌اندازند، اهمیت این تفاوت بیشتر خواهد شد.
در مرحله بعدی امنیت هوش مصنوعی سازمانی، معیار ارزیابی تنها کارهایی نخواهد بود که سازمان‌ها به عامل‌های خود اجازه انجامشان را می‌دهند؛ بلکه مشخص خواهد کرد این عامل‌ها هنگام تلاش برای عبور از محدودیت‌ها، همچنان از انجام چه کارهایی ناتوان می‌مانند.