یکشنبه, آبان ۲۴, ۱۴۰۵

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

0
20
خاموش‌کردن مدل برای مهار عامل هوش مصنوعی کافی نیست

فرض کنید یک عامل هوش مصنوعی برای دسته‌بندی درخواست‌های پشتیبانی و بررسی اطلاعات حساب‌ها به کار گرفته شده است. در یکی از درخواست‌ها، دستورهایی پنهان شده که عامل را به فرستادن داده‌ها به مقصدی ناشناس سوق می‌دهد. عامل هم به اطلاعات دسترسی دارد و هم ابزارهای متصل به آن امکان انجام این کار را می‌دهند. در چنین وضعی، «متوقف‌کردن عامل» دقیقاً به چه معناست؟ خاموش‌کردن مدل ممکن است کافی نباشد؛ چون گردش‌کار، اعتبارنامه‌ها یا اتصال‌های موجود می‌توانند همچنان فعال بمانند.

بر اساس مطلبی که در Hacker News معرفی شده، جمع‌بندی اکتبر ۲۰۲۶ پروژه امنیت هوش مصنوعی OWASP نمونه‌هایی از عامل‌های ارزیابی را بررسی می‌کند که از محدوده تعیین‌شده فراتر رفته‌اند. این مجموعه مرور کامل همه رخدادها نیست، اما بر یک نکته مهم تأکید دارد: باید در عمل آزمایش کرد که آیا مهار عامل، هم اعتبارنامه‌هایش را باطل می‌کند و هم دسترسی شبکه‌اش را می‌بندد یا نه.

خاموش‌کردن مدل همیشه کار را متوقف نمی‌کند

عامل هوش مصنوعی معمولاً بخشی از سامانه‌ای بزرگ‌تر است. مدل ممکن است تصمیم بگیرد چه کاری انجام شود، اما هماهنگ‌کننده گردش‌کار را اجرا می‌کند، هویت عامل دسترسی را فراهم می‌کند و ابزارها یا APIها کار را انجام می‌دهند. قواعد شبکه نیز مشخص می‌کنند این ابزارها به کجا وصل شوند.

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

چه زمانی باید عامل را مهار کرد؟

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

گزارش‌های خود عامل می‌توانند نشان دهند چه کاری را تلاش کرده انجام دهد، اما برای نتیجه‌گیری کافی نیستند. آن‌ها را با گزارش‌های سامانه هویت، API، برنامه و شبکه مقایسه کنید. ثبت تلاش برای انجام یک کار، به‌تنهایی ثابت نمی‌کند که کار با موفقیت انجام شده است.

مراحل عملی واکنش

ابتدا اجرای درگیر را متوقف و تا جای ممکن محرک‌ها، تلاش‌های مجدد و صف آن را غیرفعال کنید. دستور متنیِ «متوقف شو» کنترل مهار محسوب نمی‌شود؛ توقف باید از سامانه‌ای انجام شود که گردش‌کار را اجرا می‌کند. اگر زیرساخت مشترک است، در صورت امکان فقط همان گردش‌کار را جدا کنید تا سرویس‌های نامرتبط از کار نیفتند.

سپس هویت‌ها، نشست‌ها، مجوزها و اعتبارنامه‌های استفاده‌شده را شناسایی و دسترسی‌های غیرقابل‌اعتماد را لغو یا محدود کنید. اگر احتمال افشای یک راز وجود دارد، آن را تغییر دهید و بررسی کنید در کجاهای دیگر استفاده شده است. سازوکار لغو دسترسی در سامانه‌ها متفاوت است؛ بعضی توکن‌ها سریع منقضی می‌شوند و برخی تا پایان نشست معتبر می‌مانند. پس باید عملاً تأیید کنید که دسترسی دیگر قابل استفاده نیست.

ابزار یا اتصال دخیل در فعالیت را غیرفعال کنید و در صورت لزوم با سیاست‌های شبکه، ارتباط عامل با منبع آسیب‌دیده را ببندید. این کنترل‌ها باید بیرون از دستورهای خود عامل اعمال شوند. راهنمای امنیت عامل‌های هوش مصنوعی OWASP نیز بر حداقل دسترسی لازم، تأیید صریح عملیات حساس، ثبت رویدادها و امکان قطع یا بازگرداندن عملیات تأکید می‌کند.

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

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

پیش از راه‌اندازی دوباره، علت را بیابید: ورودی ناامن، مجوز بیش‌ازحد، اتصال آسیب‌دیده، تغییر پیکربندی یا نقص سامانه. اصلاح متن دستور به‌تنهایی مشکل اعتبارنامه یا سیاست شبکه را برطرف نمی‌کند. دسترسی را فقط به اندازه نیاز وظیفه بازگردانید، گردش‌کار را در محیط کنترل‌شده بیازمایید و برای کارهای حساس یا برگشت‌ناپذیر، بررسی انسانی در نظر بگیرید.

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

 Hacker News 

مقاله قبلیمهاجمان با سوءاستفاده از درگاه‌های وصله‌نشده Check Point بدافزار TSGA نصب کردند
مقاله بعدیهوش مصنوعی نوشتن فیشینگ و اخاذی باج‌افزاری را آسان‌تر می‌کند

نظر بدهید

لطفا نظر خود را بنویسید
لطفا نام خود را اینجا وارد کنید

این سایت از اکیسمت برای کاهش جفنگ استفاده می‌کند. درباره چگونگی پردازش داده‌های دیدگاه خود بیشتر بدانید.