فرانک چو، پژوهشگر امنیتی، دریافت که tl;dv — سرویس یادداشت‌برداری جلسات مبتنی بر هوش مصنوعی که به Zoom و Teams متصل می‌شود — ۱۸۱,۸۷۴ متن پیاده‌سازی شده از جلسات خصوصی را به دلیل نبود یک قانون امنیتی واحد در Firebase لو داده است؛ این نقص به هر کاربر وارد شده به سیستم اجازه می‌داد تا کل مجموعه سوابق را بخواند. این نقض امنیتی ۸۴,۳۱۲ کاربر در ۳۵,۰۰۳ دامنه را تحت تأثیر قرار داده است که یادآور این نکته است که یک لغزش کوچک در پیکربندی می‌تواند محرمانه ترین گفتگوهای شرکتی را در معرض خطر قرار دهد.

نحوه وقوع نشت اطلاعات

tl;dv یادداشت‌ها را در پایگاه داده Firestore گوگل Firebase ذخیره می‌کند. در Firestore، توسعه‌دهندگان قوانین امنیتی را می‌نویسند که تعیین می‌کند چه کسی می‌تواند هر سند را بخواند یا در آن بنویسد. بیشتر مجموعه‌های (collections) tl;dv به درستی محدود شده بودند، اما در مجموعه meetings قانونی برای بررسی هویت درخواست‌کننده وجود نداشت. نتیجه ساده بود: به محض اینکه کاربری وارد اپلیکیشن می‌شد، API فهرستی از تمام اسناد جلسات ذخیره شده توسط این سرویس را بازمی‌گرداند.

هیچ اکسپلویت پیچیده‌ای در کار نبود، هیچ محموله مخربی (malicious payload) وجود نداشت و مدل هوش مصنوعی زیرساختی نیز مورد حمله قرار نگرفته بود. این آسیب‌پذیری یک غفلت کلاسیک در کنترل دسترسی بود — یک خط کد مفقود که باید می‌گفت: «فقط مالک یا شرکت‌کنندگان دعوت‌شده مجاز به مشاهده این جلسه هستند». به دلیل نبود این قانون، هر کاربر احراز هویت شده می‌توانست بدون توجه به وضعیت دعوت، تمام متن‌های پیاده‌سازی شده را فهرست کرده و دانلود کند.

چرا این موضوع اهمیت دارد

متن‌های پیاده‌سازی شده از جلسات اغلب شامل رایزنی‌های هیئت مدیره، نقشه‌های راه محصول، مشاوره‌های حقوقی و مذاکرات فروش است. وقتی این کلمات به صورت عمومی قابل خواندن می‌شوند، رقبا می‌توانند بینش‌های استراتژیک را استخراج کنند، وکلا ممکن است مجبور به بازنگری در تعهدات محرمانگی شوند و کارمندان اعتماد خود را به ابزارهایی که به آن‌ها متکی هستند از دست می‌دهند. صدها هزار رکورد، این اتفاق را به یک شکست سیستماتیک تبدیل می‌کند که می‌تواند هر سازمانی را که بدون بررسی دقیق مدل مجوزدهی tl;dv را پذیرفته است، تحت تأثیر قرار دهد.

تأخیر در پاسخگویی

چو در ماه ژانویه این قانون مفقود شده را به تیم tl;dv گزارش کرد. اصلاح این مشکل — یعنی افزودن محدودیت خواندن مناسب و بازنشر مجموعه قوانین — تا ماه اوت اعمال نشد. یک بازه زمانی شش ماهه بین کشف و رفع مشکل، برای آسیب‌پذیری‌ای که دسترسی خواندن بدون محدودیت به داده‌های حساس را فراهم می‌کند، به طرز غیرمعمولی طولانی است. این تأخیر نشان‌دهنده شکاف‌هایی در فرآیند مدیریت آسیب‌پذیری شرکت، از مرحله اولویت‌بندی تا استقرار وصله (patch) است.

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

این حادثه اغلب به عنوان یک «ریسک هوش مصنوعی» قاب‌بندی می‌شود، اما علت اصلی یک اشتباه سنتی در کنترل دسترسی است. عوامل هوش مصنوعی — چه جلسات را پیاده‌سازی کنند، چه ایمیل‌ها را پیش‌نویس کنند یا اسناد را خلاصه کنند — با امتیازات حساب سرویس (service-account) اجرا می‌شوند که به آن‌ها اجازه می‌دهد به همان داده‌هایی دسترسی داشته باشند که یک کاربر انسانی دارد. وقتی این امتیازات بیش از حد گسترده باشند، هوش مصنوعی می‌تواند به همان راحتیِ هر سرویس بک‌اِند دیگر، به مجرایی برای نشت داده‌ها تبدیل شود.

اقداماتی که سازمان‌ها می‌توانند امروز انجام دهند

  • بازرسی منطق احراز اختیار (Authorization) – تأیید کنید که هر مجموعه پایگاه داده، نقطه پایانی API یا باکت ذخیره‌سازی ابری که توسط یک ابزار هوش مصنوعی استفاده می‌شود، بررسی‌های «اصل حداقل سطح دسترسی» را اعمال می‌کند. به دنبال قوانین مفقود یا بیش از حد مجاز، مانند موردی که در tl;dv رخ داد، باشید.
  • محدود کردن دامنه ضبط – عامل یادداشت‌بردار را طوری پیکربندی کنید که فقط جلساتی را ثبت کند که شما صراحتاً اجازه داده‌اید. تنظیمات پیش‌فرضِ «ضبط فعال»، سطح حمله را گسترده می‌کند؛ مدل‌های «انتخاب فعال» (opt-in) میزان قرارگیری در معرض خطر را محدود نگه می‌دارند.
  • با عوامل هوش مصنوعی مانند حساب‌های سرویس برخورد کنید – هر یکپارچه‌سازی هوش مصنوعی شخص ثالث را فهرست کنید، به آن یک هویت اختصاصی اختصاص دهید و تنها مجوزهایی را که برای انجام وظیفه خود نیاز دارد به آن بدهید. حساب‌های استفاده نشده را به طور منظم بازبینی و لغو کنید.
  • قوانین امنیتی را تحت فشار آزمایش کنید – تست‌های خودکاری اجرا کنید که سعی می‌کنند داده‌ها را از مجموعه‌ها بدون اعتبارنامه‌های مناسب بخوانند. این بررسی‌ها را در خط لوله‌های CI/CD بگنجانید تا یک قانون مفقود شده قبل از استقرار شناسایی شود.
  • تسریع در پاسخگویی به حوادث – جداول زمانی مشخصی برای تأیید، اولویت‌بندی و وصله کردن آسیب‌پذیری‌های گزارش شده تعیین کنید. یک دوره اصلاح شش ماهه، همان‌طور که در اینجا دیده شد، یک شکست فرآیندی است که می‌تواند تأثیر یک باگ ساده را چندین برابر کند.

آنچه باید در آینده زیر نظر داشت

سازمان‌هایی که برای یادداشت‌برداری جلسات، خلاصه‌سازی تماس‌ها یا پیاده‌سازی بلادرنگ به دستیاران هوش مصنوعی متکی هستند، باید پیکربندی‌های اشتباه مشابه را در سایر سرویس‌های ابری‌بومی (cloud-native) پیش‌بینی کنند. با ادغام بیشتر عوامل هوش مصنوعی در جریان‌های کاری روزمره، مرز بین «ریسک هوش مصنوعی» و «ریسک امنیتی سنتی» کمرنگ می‌شود. بازبینی مجوزها را زیر نظر داشته باشید، از فروشندگان خواستار بازرسی‌های شفاف قوانین امنیتی باشید و برای چرخه‌های اصلاح سریع فشار بیاورید تا از وقوع حادثه بعدی «یک قانون مفقود شده» و نشت گنجینه‌ای دیگر از گفتگوهای محرمانه جلوگیری شود.

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