افشای اطلاعات رانندگان اوبر؛ زنگ خطر امنیت تأمین‌کنندگان
امنیت اطلاعات یک شرکت، به دیوارهای شبکه داخلی آن محدود نیست. وقتی مجموعه‌ای برای پردازش داده، خدمات هوش مصنوعی یا زیرساخت نرم‌افزاری از پیمانکار بیرونی استفاده می‌کند، بخشی از ریسک را نیز با همان شرکت به اشتراک می‌گذارد. گزارش ۱۳ نوامبر ۲۰۲۶ تک‌کرانچ درباره نشت اطلاعات رانندگان اوبر نمونه روشنی از این مسئله است: اوبر تأیید کرده داده‌های برخی رانندگان پس از رخداد امنیتی در یک ارائه‌دهنده فناوری طرف قرارداد در معرض دسترسی غیرمجاز قرار گرفته است.
جزئیات تأییدشده رخداد
طبق اطلاعیه‌هایی که در اختیار نهادهای ایالتی آمریکا قرار گرفته، تأمین‌کننده در ۹ اکتبر وقوع رخداد را به اوبر اطلاع داده بود. روایت ارائه‌شده حاکی از آن است که مهاجمان به اعتبارنامه‌های داخلی دست یافته و سپس از آنها برای دسترسی به داده‌های مرتبط با اوبر استفاده کرده‌اند. تک‌کرانچ نام تأمین‌کننده را Fireworks AI اعلام کرده و به اظهارات سخنگوی اوبر استناد کرده است. این شرکت خدمات دسترسی و اجرای مدل‌های هوش مصنوعی را برای توسعه‌دهندگان عرضه می‌کند.
در گزارش، تعداد افراد آسیب‌دیده برای همه حوزه‌ها یک رقم نهایی و یکپارچه اعلام نشده است. از جمله در پرونده‌های دیده‌شده، ارقام جداگانه‌ای برای ایالت‌هایی مانند ماساچوست، کارولینای جنوبی و رودآیلند آمده است. از جمع ساده گزارش‌های ایالتی نمی‌توان بدون کنترل هم‌پوشانی، تعداد نهایی همه افراد را نتیجه گرفت. جزئیات داده‌های سرقت‌شده نیز باید به متن اطلاعیه و گروه کاربران مربوط محدود شود.
چرا یک شرکت ثالث به داده حساس دسترسی دارد؟
در معماری خدمات مدرن، تأمین‌کننده ممکن است برای پردازش سفارش، پشتیبانی، هوش مصنوعی، تحلیل داده یا نگهداری سرویس به برخی اطلاعات مشتری نیاز داشته باشد. مشکل زمانی آغاز می‌شود که میزان دسترسی با هدف همکاری تناسب نداشته باشد، داده بیش از حد نگهداری شود یا نظارت بر حساب‌ها و توکن‌های دسترسی ناکافی باشد. «شرکت ثالث» لزوماً کم‌امنیت‌تر از شرکت اصلی نیست، اما هر اتصال جدید سطح حمله و تعداد نقاط کنترل را افزایش می‌دهد.
خدمات هوش مصنوعی این پرسش را پررنگ‌تر می‌کنند. داده‌ای که برای خلاصه‌سازی، جست‌وجو یا مدل‌سازی به یک API فرستاده می‌شود ممکن است حاوی شناسه شخصی، متن محرمانه یا اطلاعات عملیاتی باشد. تیم خریدار باید دقیق بداند چه داده‌ای منتقل می‌شود، چه مدت در سامانه طرف مقابل باقی می‌ماند، چه کسی امکان دسترسی دارد و در صورت بروز حادثه مسئول اطلاع‌رسانی کدام طرف است.
مسئله اصلی: اعتبارنامه و مجوز
در گزارش اوبر، سرقت اعتبارنامه‌ها بخشی از روایت رخداد است. این موضوع یادآور می‌شود که رمز عبور و کلید API، خودِ دارایی حساس‌اند. اگر کلیدی مجوز گسترده و طول عمر نامحدود داشته باشد، افشای آن می‌تواند به داده‌هایی بیشتر از نیاز واقعی مهاجم دسترسی بدهد. راهکار دفاعی شامل تفکیک حساب‌های سرویس، محدودکردن دسترسی به حداقل لازم، چرخش کلیدها، ثبت لاگ، تشخیص رفتار غیرمعمول و بازبینی دوره‌ای مجوزهاست.
البته این توصیه‌های عمومی به معنی اثبات نبودن هر یک از کنترل‌ها در سامانه اوبر یا Fireworks نیست. بدون گزارش فنی کامل نمی‌توان دانست دقیقاً کدام سیاست ناکافی بوده است. تحلیل حرفه‌ای بین «شیوه احتمالی سوءاستفاده» و «نقطه ضعف اثبات‌شده سازمان» تفاوت قائل می‌شود.
چه چیزی را در قرارداد تأمین‌کننده باید بررسی کرد؟
پیش از واگذاری پردازش داده، شرکت باید طبقه‌بندی اطلاعات و هدف انتقال را تعریف کند. اگر داده هویتی حساس لازم نیست، نسخه حذف‌شده یا ناشناس‌شده ارسال شود. قرارداد باید درباره نگهداری و حذف داده، دسترسی پیمانکاران فرعی، زمان اطلاع‌رسانی حادثه، قابلیت ممیزی، محل پردازش و بازگشت داده در پایان همکاری شفاف باشد. داشتن گواهی امنیتی یک امتیاز است، اما جای بررسی واقعی دامنه گواهی و کنترل‌های جاری را نمی‌گیرد.
همچنین در رخداد باید بتوان مشخص کرد کدام افراد آسیب دیده‌اند، چه نوع داده‌ای در معرض خطر بوده، چه کلیدهایی باید باطل شوند و چه اطلاعاتی باید به نهادهای مسئول یا اشخاص مرتبط اعلام شود. ناتوانی در پاسخ به این پرسش‌ها می‌تواند هزینه عملیاتی و اعتباری حادثه را افزایش دهد.
اقدامات عملی برای مدیران ایرانی
بخش قابل توجهی از شرکت‌های ایرانی از سرویس‌های ابری، پیامک، پرداخت، پشتیبانی مشتری، CRM و اخیراً مدل‌های هوش مصنوعی بیرونی استفاده می‌کنند. حتی اگر به دلیل محدودیت دسترسی یا قیمت، انتخاب تأمین‌کننده محدود باشد، اصل حداقل‌سازی اطلاعات قابل اجراست. جدول دارایی‌های داده و ارائه‌دهندگان بیرونی تهیه کنید؛ برای هر مورد مالک سازمانی و مجوز اتصال مشخص کنید؛ حساب‌های قدیمی را حذف کنید؛ کلیدهای مشترک میان پروژه‌ها را تفکیک کنید و نسخه خروجی ضروری از داده‌ها را به‌صورت امن حفظ کنید.
اگر داده هویتی افراد مانند تصویر مدرک یا شماره شناسایی در سامانه نگهداری می‌شود، مدت لازم نگهداری را بازنگری کنید. ریسک نشت هر داده‌ای یکسان نیست. افشای یک نشانی ایمیل کاری با افشای مجموعه اطلاعات مجوز رانندگی اثر متفاوتی دارد. فرایند پاسخگویی نیز باید متناسب با حساسیت داده طراحی شود.
پرسش از هیئت‌مدیره و مدیر فناوری
به‌جای پرسیدن اینکه «آیا تأمین‌کننده امن است؟» باید پرسید «اگر فردا تأمین‌کننده دچار نفوذ شد، دقیقاً کدام اطلاعات ما در اختیار اوست و ظرف چه زمانی می‌توانیم دسترسی را قطع کنیم؟» پاسخ به این سؤال باید از نقشه داده، قرارداد و آزمایش قطع دسترسی به‌دست آید. رخداد اوبر نشان می‌دهد شهرت یک شرکت بزرگ، زنجیره تأمینش را از تهدید مصون نمی‌کند.
جمع‌بندی این است که اعتماد به خدمات فناوری نیازمند کنترل پیوسته است. امنیت طرف ثالث نه با یک فرم اولیه خرید خاتمه می‌یابد، نه با یک عبارت کلی درباره محرمانگی. سازمانی که داده کمتر انتقال می‌دهد، مجوز دقیق‌تری صادر می‌کند و امکان لغو فوری دسترسی را می‌آزماید، در برابر حوادث مشابه آماده‌تر است.
منبع و تاریخ: TechCrunch، ۱۳ نوامبر ۲۰۲۶، با استناد به اطلاعیه‌های ایالتی و اظهارات شرکت‌ها؛ رخداد اولیه در اکتبر گزارش شده است.
نظرات کاربران
ثبت دیدگاه در نسخه آزمایشی فعال نیست.