اصل کلیدی برای امنیت داده‌های SaaS

در حالی که نمی‌توان از شکاف‌های امنیتی که اخیراً توسط Okta فاش شده است به طور کامل جلوگیری کرد، اصل کمینه سازی مجوز (PoLP  ) یک سبک سازی ساده اما قدرتمند است که می‌تواند شدت حوادث را به طور چشمگیری کاهش دهد. با این حال، یک رویکرد قوی PoLP تنها در صورتی می‌تواند اجرا شود که ابزارها و محصولاتی که استفاده می‌کنیم، از قابلیت‌های مورد نیاز پشتیبانی کنند. شکاف ایمنی گسترده‌ای که گزارش شده است، فرصتی عالی برای نگاهی دقیق‌تر است. نگاهی دقیق‌تر به آن‌چه که محصولات SaaS می‌بایست برای حفظ امنیت مشتریان و کاربران خود در سال 2022 انجام دهند.

صبر کن! چی شد؟

Okta در اواخر ژانویه با نفوذ گروه هکرهای Lapsus$ مواجه شد. این نفوذ تا یک هفته کشف نشده بود و در نهایت در 22 مارس عمومی شد. لینک ضعیفی که Lapsus$ از آن سوء استفاده کرده بود، از قرار معلوم متعلق به Sitel’s Sykes Enterprises ، یک فروشنده پشتیبان مشتری شخص ثالث بود.

مهاجمان به یک لپ‌تاپ متعلق به یک مهندس پشتیبانی از Sitel دسترسی پیدا کردند. پس از آن Lapsus$ یک جلسه پروتکل ریموت دسکتاپ (RDP  ) را با Okta شروع کرد. در حالی که به گفته Okta، مهاجمان به لطف احراز هویت چندعاملی ( MFA ) موفق به تصاحب حساب کاربری نشدند، این شرکت اذعان کرد که ممکن است بیش از 300 مشتری تحت تأثیر قرار گرفته باشند و برخی از داده‌های کاربران توسط هکرها جمع‌آوری شده است.

بر خلاف گروه‌های هک سنتی که از آسیب‌پذیری‌ها در کد یا پیکربندی‌های نادرست سوء استفاده می‌کنند، رویکرد ترجیحی Lapsus$ رشوه دادن به خودی‌های شرکت یا اشخاص ثالثی است که اجازه دسترسی دارند. با تاکتیک‌های نامتعارف مانند این، و همچنین وجود خطر همیشگی مهندسی اجتماعی و اشتباهات ساده انسانی، برای هیچ سازمانی امکان پذیر نیست که ایمنی خود را 100 درصد حفظ کند. به همین دلال بسیار مهم است اقداماتی را انجام دهیم که «شعاع انفجار» را از یک شکاف به حداقل برساند. این دقیقاً جایی است که PoLP وارد عمل می‌شود.

دیدگاه اصل کمینه سازی مجوز در SaaS

PoLP بهترین روشی است که شدت حملات احتمالی را با محدود کردن مجوزهای یک کاربر معین به پایین‌ترین سطح لازم برای انجام کارهایشان، به حداقل می‌رساند.

این رویکرد تضمین می‌کند که حتی در صورت دسترسی مهاجم، این به طور خودکار به آن‌ها یک قدرت خداگونه مانند یک SuperUser نمی‌دهد. در نتیجه مهاجم نمی‌تواند داده‌های کاربران را استخراج یا دستکاری کند. قابلیت‌هایی که مهاجم می‌توواند قفل آن را باز کند، با توجه به نیازهای شغلی کارمندی که از حسابش استفاده می‌شود، محدود است. وقتی PoLP به درستی اجرا شود، اکثر حساب‌های کارمندی دارای محدودیت‌های سخت‌گیرانه خواهند بود. بنابراین اکثر شکاف‌های امنیتی منجر به آسیب کمی می‌شوند.

Okta در پست خود در مورد این حادثه اظهار داشت که برنامه‌ای که مهاجمان به آن دسترسی پیدا کرده اند، «با حداقل مجوز ساخته شده است.» در حالی که جزئیات در مورد قابلیت‌های اعظا شده به یک مهندس پشتیبانی شخص ثالث، سوالاتی را در مورد این ادعا مطرح می‌کند، ارجاع به PoLP کار درستی است. زیرا این رویکرد برای کاهش این نوع از حملات کلیدی است.

تعداد فزاینده افراد با حق ویژه کاربری

رابطه Okta-Sitel غیر عادی نیست. ابتکارات تحول دیجیتال، پذیرش تعداد زیادی از ابزارهای SaaS را تسریع کرده است. همچنین یکپارچگی بین پلتفرم‌ها را افزایش داده و باعث برون‌سپاری خدمات به فروشندگان خارجی شده است. اجازه دسترسی اشخاص ثالث به حساب‌های محصولات SaaS برای بسیاری از شرکت‌ها رواج یافته است. اما به دلیل ماهیت خدمات ارائه شده، اغلب به فروشندگان شخص ثالث اجازه دسترسی به تعداد زیادی از حساب‌های مشتریان داده می‌شود. اگر یک فروشنده پشتیبان هک شود، و از PoLP پیروی نشده باشد، تأثیر آن می‌تواند بسیار زیاد باشد.

تغییر دیدگاه شرکت شما به سمت PoLP ، مستلزم مشارکت کل سازمان است. مانند همه تلاش‌هایی که برای تحول انجام می‌شود، این تغییر نیز شامل افراد، فرآیند‌ها و ابزارها می‌شود. اما محصولات SaaS امروزه اغلب فاقد قابلیت‌هایی هستند که برای پشتیبانی از افراد و فرآیندها در پذیرش PoLP لازم است.

نُرم فعلی یک تفکیک نقش حداقلی را ارائه می‌کند. اکثر برنامه‌ها امروزه فقط یک نقش سوپرادمین دارند. نقشی که می‌تواند هر عملی را در محصول انجام دهد. پیشرفته‌ترها نیز فقط نقش read-only را در مراحل بعدی تکامل خود اضافه می‌کنند. اما این کارها برای جلوگیری از عواقب مخربی که یک کارمند بی‌وجدان یا یک لپ‌تاپ در جای نادرست ایجاد می‌کند، کافی نیست.

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

موارد مورد نیاز محصول SaaS برای PoLP

اصول PoLP زیر باید در هر برنامه مدرن پیاده سازی شود:

حداقل مجوز برای کاربران جدید

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

مجوزهای دانه‌ای ( Granular permissions ) برای حداکثر کنترل

داشتن تنها دو نقشِ ادمین و  read-only، کارها را بیش از حد ساده می‌کند. واقعیت این است که اکثر کاربران به سطحی از دسترسی در میان این دو گزینه قرار دارند. که منجر به دسترسی همه افراد به دسترسی ادمین می‌شود. توانایی کنترل دقیق بر مجوزهای اعطایی به کاربران، برای پویاتر شدن رویکرد PoLP ضروری است.

دسترسی موقت برای امنیت دائمی

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

خدمات حسابرسی به صورت مستمر

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

UX بی‌اصطکاک برای مدیریت مجوز

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

RBAC : یک نیاز کلیدی برای سازمان‌های بزرگ

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

برای شرکت‌هایی با این اندازه، کنترل دسترسی مبتنی بر نقش ( RBAC )، یک قابلیت حیاتی در برنامه‌های SaaS است. RBAC به شما امکان می‌دهد نقش‌هایی را در یک محصول تعریف کنید که با عملکردهای درون سازمانی مطابقت دارد. به هر نقش، مجوزهای لازم برای عملکرد خود در محصول اعطا می‌شود و به کاربران، با توجه به عملکردشان نقش‌هایی خواهند داشت.

اصل امن‌ترین در SaaS

با تغییر ماهیت تهدیدها و سطح رو به رشد حملات، ناشی از روندهایی که در طول زمان تقویت می‌شوند، شکاف‌های امنیتی اجتناب ناپذیر هستند. بنابراین، کسب و کارها باید به سمت رویکردی حرکت کنند که استراتژی‌های کاهش را در اولویت قرار دهد. اصل کمترین مجوز در این امر نقش اساس دارد. محصولات SaaS امروزه اغلب در ارائه قابلیت‌های اصلی برای PoLP کوتاهی می‌کنند. به عنوان سازندگان و مصرف‌کنندگان SaaS ، برای ایمن نگه‌داشتن حساب‌های کاربرانمان باید بهتر عمل کنیم. و همچنین در ایمن نگه داشتن حساب کاربرانمان، از خود توقع بیشتری داشته باشیم.

منبع: venturebeat      نویسنده: ساگی رودین، مدیر عامل و یکی از بنیانگذاران Frontegg