ده دسته رویدادی که خریدار سازمانی حتماً سراغشون رو میگیره
خلاصهٔ کاملتر
به نوشتهٔ نویسندهٔ WorkOS، بیشتر تیمهای B2B SaaS از راه سخت میفهمن چی باید تو لاگ ممیزی باشه: یه پرسشنامهٔ امنیتی با یه درخواست مشخص برمیگرده، مهندسی با عجله یه نوع رویداد دیگه اضافه میکنه و معامله یه هفته عقب میافته. فهرستی که ارائه میده تلاشیه برای جلو افتادن از اون لحظه — ده دستهای که وقتی شرکتی بیشتر از چند مشتری سازمانی داشته باشه، تقریباً همیشه پیش میآن.
اول احراز هویت، هم موفق و هم ناموفق. ثبت ورودهای موفق آسونه؛ چیزی که جا میمونه تلاشهای ناموفقه که برای بررسی حادثه مهمترن: چند شکست پشتسرهم روی یه حساب، یه IP که به کلی حساب میزنه، یا ورود موفقی که با الگوی مکانی همیشگی کاربر جور در نمیآد. روش ورود (رمز، SSO، لینک جادویی) هم باید ثبت بشه.
دوم ثبتنام، چالش و بازنشانی MFA. بازنشانی MFA یکی از باارزشترین رویدادهاییه که مهاجم میتونه راه بندازه، چون معمولاً درست قبل از تصاحب حسابه. سوم چرخهٔ عمر نشست و توکن: صدور، تازهسازی و ابطال، بههمراه اینکه چی باعث ابطال شده. این همون دستهایه که به سؤال «آیا واقعاً میتونین همین الان دسترسی این آدم رو قطع کنین؟» جواب میده.
چهارم تغییر نقش و مجوز. هر بار که نقش کسی عوض میشه باید ثبت بشه کی تغییرش داد، قبلش چی بود و بعدش چی شد. به گفتهٔ نویسنده این همون دستهایه که تو نسخهٔ اول لاگ ممیزی بیشتر از همه کلاً غایبه و در عین حال اولین چیزیه که بازبین امنیتی میخواد، چون نگرانی اصلیاش تشدید سطح دسترسیه. پنجم تأمین و حذف حساب از راه دایرکتوری: هر ساخت، بهروزرسانی، غیرفعالسازی و حذف SCIM باید رویداد جدا باشه، نه اینکه توی یه سطل عمومی «کاربر تغییر کرد» گم بشه.
ششم چرخهٔ عمر کلید API و اعتبارنامهٔ سرویس: ساخت، دامنهٔ دسترسی، آخرین استفاده، چرخش و ابطال. کلیدی که هیچوقت چرخونده نشده تقریباً تو هر ممیزی بهعنوان یافته ثبت میشه. هفتم خروجیگرفتن و دسترسی انبوه به داده: سیگنال مهم خود اکسپورت نیست، ترکیب حجم و مقصده — اکسپورت کوچک به یه اینتگریشن شناختهشده روتینه، ولی اکسپورت بزرگ به مقصد یه ایمیل شخصی همون الگوییه که هر ابزار DLP دنبالشه.
هشتم جعل هویت و دسترسی پشتیبانی. اگه تیم پشتیبانی یا مهندسی میتونه بهجای کاربرِ مشتری وارد بشه، این باید نوع رویداد جدا داشته باشه و برای خود مشتری هم دیدنی باشه؛ چون از دید بازبین امنیتی دقیقاً شبیه تصاحب حسابه مگه اینکه شفاف برچسب بخوره. نهم تغییر پیکربندی امنیتی: روشن و خاموشکردن اجبار MFA، ویرایش فهرست IP مجاز، تغییر اتصال SSO و سیاست رمز. اینها کمتکرارن و دقیقاً به همین دلیل نباید لای لاگ عمومی تنظیمات دفن بشن — خاموششدن بیسروصدای یه کنترل معمولاً ریشهٔ واقعی حادثهست.
دهم فعالیت غیرانسانی و خودکار: حسابهای سرویس، وبهوکها، جابهای زمانبندیشده و بهطور فزاینده ایجنتهای هوش مصنوعی که بهنیابت از کاربر عمل میکنن. نویسنده میگه این دسته سریعترین رشد رو تو سال گذشته داشته و همونجاییه که لاگهای موجود براش ساخته نشدن، چون باید بین آدمی که مجوز داده و هویت خودکاری که کار رو انجام داده تمایز گذاشت — و هر دو باید ثبت بشن، بهعلاوهٔ دامنهای که براش مجاز بوده.
نیمهٔ دوم ماجرا نگهداریه. بهعنوان یه خط پایهٔ تقریبی: رویدادهای احراز هویت حدود یه سال، رویدادهای مدیریتی و تغییر نقش دو سال، و هر چیزی که به جعل هویت، بازنشانی MFA یا دادهٔ تحت مقررات مربوطه بیشتر از اینها. توصیهاش اینه که نگهداری رو از همون اول تو اسکیما بسازین. حرف پایانیاش هم اینه که سختترین بخش خودِ فراخوان لاگ نیست، بلکه زیرساخت اطرافشه: ذخیرهسازی مقاوم در برابر دستکاری و جدا از دیتابیس اپلیکیشن، و راهی برای رسوندن رکوردها به SIEM مشتری بدون تیکت پشتیبانی.
نکات کلیدی:
- ورود ناموفق بهاندازهٔ ورود موفق مهمه؛ روش ورود هم باید ثبت بشه
- تغییر نقش و مجوز بیشترین غیبت رو داره و اولین چیزیه که پرسیده میشه
- سیگنال اکسپورت داده تو ترکیب حجم و مقصده، نه خود اکسپورت
- جعل هویت پشتیبانی باید رویداد جدا و برای مشتری قابلمشاهده باشه
- فعالیت ایجنتها و سرویسها باید هم کاربر مجوزدهنده و هم هویت اجراکننده رو ثبت کنه
