ابزارهای هوش مصنوعی پنهان در شرکت‌ها؛ چرا فهرست نرم‌افزارهای نصب‌شده کافی نیست؟

قابلیت AI Visibility and Control بیت‌دیفندر در GravityZone به سازمان‌ها کمک می‌کند ابزارهای هوش مصنوعی پنهان را شناسایی کنند، ریسک‌های امنیتی آن‌ها را بسنجند و دسترسی‌ها را بهتر مدیریت کنند.

نویسنده:

محمدعلی کریمی

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

شرکت بیت‌دیفندر با قابلیت GravityZone AI Visibility and Control (AIVC) تلاش می‌کند این شکاف را در محیط‌های سازمانی کاهش دهد. این قابلیت ابزارهای هوش مصنوعی شناسایی‌شده روی نقاط پایانی تحت مدیریت را فهرست می‌کند، یافته‌های مرتبط با ریسک را نمایش می‌دهد و اطلاعات لازم را برای تصمیم‌گیری تیم امنیت فراهم می‌سازد. بر اساس مستندات رسمی، این قابلیت برای نقاط پایانی ویندوزی پشتیبانی‌شده ارائه شده و به مجوز واجد شرایط و فعال‌بودن مؤلفه مدیریت ریسک نیاز دارد. اهمیت این موضوع برای سازمان‌ها صرفاً در تعداد ابزارهای هوش مصنوعی نیست؛ مسئله اصلی این است که هر ابزار به چه منابعی دسترسی دارد، چگونه پیکربندی شده و آیا استفاده از آن با سیاست‌های امنیتی سازمان سازگار است یا خیر.

هوش مصنوعی پنهان چیست و چرا اهمیت دارد؟

اصطلاح «هوش مصنوعی پنهان» یا Shadow AI به استفاده از ابزارها و خدمات هوش مصنوعی بدون اطلاع کافی یا تأیید رسمی سازمان اشاره دارد. این وضعیت ممکن است زمانی ایجاد شود که کارمند برای انجام سریع‌تر وظایف خود از سرویسی استفاده کند که واحد فناوری اطلاعات هنوز آن را ارزیابی نکرده است.

چهار نمونه از این وضعیت اهمیت ویژه‌ای دارند:

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

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

ابزارهای سنتی مدیریت دارایی نرم‌افزاری معمولاً برای شناسایی برنامه‌های نصب‌شده و مدیریت وضعیت آن‌ها طراحی شده‌اند. اما استفاده از هوش مصنوعی می‌تواند از مسیرهایی انجام شود که در این فهرست‌ها به‌سادگی دیده نمی‌شوند. برای مثال، استفاده از یک دستیار در مرورگر ممکن است به نصب برنامه مستقل نیاز نداشته باشد. افزونه‌ای در محیط توسعه نیز می‌تواند بخشی از فعالیت‌های برنامه‌نویس باشد، بدون آنکه مانند یک نرم‌افزار معمولی در فهرست برنامه‌های نصب‌شده ظاهر شود. در نمونه‌ای پیچیده‌تر، اتصال یک مدل به منابع سازمانی از طریق Model Context Protocol (MCP) ممکن است به یک تنظیم یا پیکربندی نیاز داشته باشد، نه یک نصب‌کننده مستقل. MCP سازوکاری برای ارتباط مدل‌های هوش مصنوعی با ابزارها و منابع خارجی است. میزان خطر این ارتباط به عواملی مانند نوع منبع، سطح دسترسی و مجوزهای اعطاشده بستگی دارد. اتصال صرفاً خواندنی به یک گزارش، از نظر پیامدهای احتمالی با اتصالی که امکان تغییر داده‌های عملیاتی را دارد یکسان نیست. به همین دلیل، شمارش ابزارها به‌تنهایی برای ارزیابی ریسک کافی نیست؛ سازمان باید بداند هر ابزار به چه چیزی دسترسی دارد و چه عملیاتی می‌تواند انجام دهد.

بیت‌دیفندر AIVC چگونه کار می‌کند؟

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

این محصول دو نمای اصلی دارد که پاسخ‌گوی دو پرسش متفاوت هستند.

نمای AI Services؛ چه ابزارهایی در سازمان وجود دارند؟

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

نمای AI Findings؛ کدام ریسک باید زودتر بررسی شود؟

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

نقش عامل‌های هوش مصنوعی و سرورهای MCP در سطح حمله

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

چند پرسش کلیدی در این ارزیابی عبارت‌اند از:

آیا اتصال صرفاً امکان مشاهده اطلاعات را دارد یا می‌تواند آن‌ها را تغییر دهد؟
آیا دسترسی به یک منبع مشخص محدود شده یا منابع بیشتری در دسترس هستند؟
آیا اعتبارنامه‌ها و مجوزها متناسب با وظیفه ابزار هستند؟
آیا سازمان می‌داند این اتصال روی کدام رایانه‌ها فعال است؟
آیا امکان بررسی و لغو دسترسی در صورت تغییر نیاز سازمان وجود دارد؟

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

آیا AIVC اطلاعات کاربران را می‌خواند؟

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

شناسایی ابزار با مسدودسازی آن تفاوت دارد

یکی از نکات مهم در معرفی AIVC این است که این قابلیت به‌تنهایی ابزارها را مسدود نمی‌کند، نرم‌افزارها را حذف نمی‌کند و مجوزهای برنامه‌ها را تغییر نمی‌دهد.

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

در عمل، این فرایند سه مرحله دارد:

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

2. ارزیابی: بررسی شود هر ابزار چه دسترسی‌هایی دارد، آیا استفاده از آن تأیید شده و چه یافته‌های امنیتی به آن مربوط است.

3. اقدام: بر اساس سیاست سازمان، دسترسی محدود شود، ابزار بررسی بیشتری دریافت کند یا استفاده از آن مجاز شناخته شود.

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

برای مدیران فناوری اطلاعات

1. فهرست ابزارهای مجاز را تهیه کنید. نام سرویس‌ها، افزونه‌ها، مدل‌های محلی و ابزارهای متصل به منابع سازمانی را در یک فهرست قابل بازبینی ثبت کنید.

2. دسترسی‌ها را بررسی کنید. به‌ویژه در ابزارهای برنامه‌نویسی و عامل‌هایی که به مخازن کد، پایگاه‌های داده یا سامانه‌های داخلی متصل هستند، مجوزهای غیرضروری را شناسایی کنید.

3. ابزارهای تأییدنشده را جداگانه ارزیابی کنید. نبود هشدار فنی به معنای تأیید سازمانی نیست؛ وضعیت مجازبودن باید مستقلاً مشخص شود.

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

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

برای کارکنان و برنامه‌نویسان

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

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

مستندات رسمی نشان می‌دهد AIVC برای نقاط پایانی ویندوزی پشتیبانی‌شده طراحی شده و استفاده از آن به مجوز واجد شرایط و مؤلفه مدیریت ریسک نیاز دارد. فعال‌کردن قابلیت نیز به‌خودی‌خود تضمین نمی‌کند که همه ابزارهای موجود در سازمان شناسایی شوند؛ محدوده پوشش باید با سیستم‌عامل‌ها، عامل‌های نصب‌شده و شرایط پشتیبانی محصول تطبیق داده شود.همچنین، مقاله مورد بررسی در The Hacker News یک معرفی محصول است. ارقام مطرح‌شده در آن درباره تعداد عامل‌ها و مهارت‌های قابل شناسایی باید به‌عنوان ادعاهای منتشرشده در همان معرفی در نظر گرفته شوند، نه نتایج یک ارزیابی مستقل عملکرد. برای تصمیم‌گیری درباره خرید یا استقرار، سازمان باید شرایط مجوز، سازگاری با زیرساخت فعلی، کیفیت شناسایی در محیط واقعی، نحوه مدیریت داده‌ها و میزان نیاز به تنظیمات تکمیلی را بررسی کند.

جمع‌بندی

مدیریت امنیت هوش مصنوعی در سازمان‌ها تنها به مسدودکردن چند وب‌سایت یا تهیه فهرست برنامه‌های نصب‌شده محدود نمی‌شود. افزونه‌های توسعه، مدل‌های محلی و اتصال‌دهنده‌های هوش مصنوعی می‌توانند مسیرهای تازه‌ای برای دسترسی به منابع سازمانی ایجاد کنند و ارزیابی آن‌ها به اطلاعاتی فراتر از نام نرم‌افزار نیاز دارد.

GravityZone AI Visibility and Control رویکردی برای شناسایی ابزارهای هوش مصنوعی و اولویت‌بندی یافته‌های مرتبط با آن‌ها ارائه می‌کند؛ اما تصمیم‌گیری درباره مجازبودن ابزار، اعمال محدودیت و اثبات وقوع نشت اطلاعات همچنان به سیاست‌های سازمان، کنترل‌های تکمیلی و شواهد معتبر وابسته است.

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