رویدادی که امنیت ابری را تغییر داد
بهروزرسانی برای ۲۰۲۶
نقض ۲۰۲۲ LastPass اصلاً درباره مدیران رمز عبور نیست. درباره اعتماد است. شرکتها به یک ارائهدهنده ابری با دادههایشان اعتماد کردند. آن اعتماد شکست. علت نقصهای پنهان بود، نه بیاحتیاطی.
LastPass یک طراحی zero-knowledge فروخت. در عمل، zero-knowledge نبود. ۲۵ میلیون کاربر والتهای رمزگذاریشدهشان دزدیده شد. حمله اول بار در اوت ۲۰۲۲ فاش شد. LastPass چندین بار افشاگریهایش را بازنگری کرد. محدوده کامل تا اواخر ۲۰۲۲ مشخص شد.
برای شرکتهایی در بهداشت، مالی، و حقوق، این یک خبر دور نبود. این بخشها در صورت نشت داده با مسئولیت واقعی مواجه میشوند. پرونده LastPass نشانه اولیه یک مشکل گستردهتر بود.
دو نقص که حمله را ممکن کردند
بررسی پس از رویداد دو ضعف کلیدی پیدا کرد.
تنظیم ضعیف کلید. LastPass از PBKDF2 برای استخراج کلید استفاده کرد. حسابهای جدیدتر ۱۰۰٬۱۰۰ تکرار داشتند. OWASP ۶۰۰٬۰۰۰ را توصیه میکند. بعضی حسابهای قدیمی تا ۱ تکرار داشتند. تکرارهای کمتر حملات brute-force را سریع و ارزان میکنند. مهاجمانی که فایلهای والت داشتند میتوانستند رمزهای عبور اصلی را با سرعت بالا آزمایش کنند.
متادیتای متن خالص. محتوای والت رمزگذاری شده بود. اما متادیتا رمزگذاری نشده بود. URLها، نامهای کاربری، و نام سرویسها همه در دادههای دزدیدهشده قابل مشاهده بودند. مهاجمان میتوانستند ببینند هر کاربر با کدام سرویسها حساب داشت. این، فیشینگ هدفمند و پر کردن اعتبارنامه را ممکن کرد. نیازی به شکستن والت نبود.
این پرونده نشان میدهد چرا باید دو سوال را جداگانه پرسید. «آیا طراحی zero-knowledge است؟» یک سوال است. «آیا ساخت درست است؟» سوال متفاوتی است.
Okta در ۲۰۲۳: یک حمله متفاوت، همان نتیجه
در اکتبر ۲۰۲۳، Okta یک رویداد امنیتی گزارش کرد. یک اعتبارنامه دزدیدهشده به یک مهاجم دسترسی به سیستم پشتیبانی مشتریان آن را داد. حمله ۶۰۰٬۰۰۰+ سابقه پشتیبانی را فاش کرد. اینها شامل پروندههایی بود که مشتریان در طول جلسات پشتیبانی آپلود کرده بودند.
Okta یک پلتفرم امنیت هویت است. مشکل یک نقص طراحی نبود. یک شکست کنترل دسترسی بود. ورود یک مهندس پشتیبانی دزدیده شد. مهاجم از آن برای دسترسی به دادههای حساس استفاده کرد.
LastPass و Okta دو مسیر اصلی به سازش فروشنده را نشان میدهند:
- شکستهای طراحی — ادعاهای zero-knowledge که درست ساخته نشدند
- شکستهای کنترل دسترسی — اعتبارنامههای معتبر که برای دسترسی به دادههایی که نباید به آنها دسترسی داشتند استفاده شدند
طراحی zero-knowledge از نوع اول جلوگیری میکند. یک مهاجم با اعتبارنامه پشتیبانی معتبر را متوقف نمیکند. اما آن مهاجم را از خواندن دادههای مشتری مسدود میکند. فروشنده هرگز محتوای قابل رمزگشایی نگه نمیدارد. مروری بر امنیت و انطباق ما را برای نحوه اعمال این موضوع در ابزارهای PII ببینید.
رویدادهای امنیتی SaaS در دو سال ۳۰۰٪ افزایش یافتند
Obsidian Security افزایش ۳۰۰٪ در رویدادهای امنیتی پلتفرم SaaS از ۲۰۲۲ تا ۲۰۲۴ پیدا کرد.
این یک افزایش ۳۰۰٪ در مهارت مهاجم نیست. دو نیرو آن را هدایت کرد. استفاده از SaaS سریع رشد کرد. مهاجمان داده را دنبال کردند. یک سازش فروشنده میتواند داده دهها مشتری را بهیکباره فاش کند. آن سود، حملات فروشنده را بر حملات تکشرکتی ترجیح میدهد.
شرکتهایی که فرض میکردند پلتفرمهای ابری امن هستند باید این دیدگاه را بهروز کنند. فروشندگان SaaS اکنون اهداف اصلی هستند.
سوالاتی که از هر ارائهدهنده ابری باید پرسید
برای تیمهای خرید و امنیت، این چکلیست حوزههای اصلی را پوشش میدهد.
تنظیم رمزگذاری:
- الگوریتم استخراج کلید، تعداد تکرار، و تنظیمات حافظه را بخواهید.
- تأیید کنید تعداد تکرارها حداقلهای OWASP را برآورده میکنند. آن ۶۰۰٬۰۰۰ PBKDF2-SHA256 یا معادل Argon2id است.
- تأیید کنید استخراج کلید روی دستگاه شما اجرا میشود، نه روی سرورهای فروشنده.
افشای متادیتا:
- بپرسید چه متادیتایی در کنار محتوای رمزگذاریشده بهصورت متن خالص ذخیره شده.
- یک مدل داده بخواهید. باید نشان دهد کدام فیلدها رمزگذاری شدهاند و کدامها در یک حمله قابل مشاهده هستند.
دسترسی پشتیبانی:
- بپرسید آیا کارمندان پشتیبانی میتوانند به دادههای مشتری دسترسی داشته باشند.
- تأیید کنید سیستمهای پشتیبانی نمیتوانند به متن خالص مشتری دسترسی داشته باشند.
تاریخچه رویدادها:
- تمام رویدادهای امنیتی قبلی، شامل آنهایی که زیر آستانه افشای عمومی هستند، را بخواهید.
- بسنجید که افشاگریهای قبلی چقدر کامل و صادقانه بودهاند.
رویداد LastPass یک شکست ساخت و یک شکست اعتماد بود. فروشندگانی که پاسخهای مشخص دارند، بررسی ریسک واقعی را ممکن میکنند. فروشندگانی با ادعاهای مبهم، ریسک را پنهان میکنند. آن ریسک اغلب فقط پس از یک حمله آشکار میشود. مرور انطباق ما را برای راهنمایی ارزیابی فروشنده ببینید.
anonym.legal از معماری zero-knowledge برای ناشناسسازی PII استفاده میکند. استخراج کلید از طریق Argon2id در مرورگر یا اپلیکیشن دسکتاپ شما اجرا میشود. رمزگذاری قبل از خروج داده از دستگاه شما اتفاق میافتد. سرورها فقط متن رمزگذاریشدهای ذخیره میکنند که نمیتوانند رمزگشایی کنند. بیشتر بدانید.