جداسازی مرورگر به شکلی آرام به پیش‌فرض امنیت وب سازمانی تبدیل می‌شود

اشتراک‌گذاری:
جداسازی مرورگر به شکلی آرام به پیش‌فرض امنیت وب سازمانی تبدیل می‌شود

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

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

مرورگر اکنون ریسک سازمانی زیادی را حمل می‌کند

برای بسیاری از تیم‌های امنیتی، این تغییر با یک مشاهده ساده آغاز می‌شود: بیشتر حملات مدرن مبتنی بر کاربر یا در مرورگر شروع می‌شوند یا در آن پایان می‌یابند. صفحات فیشینگ اعتبارنامه‌ها را در مرورگر جمع‌آوری می‌کنند. تبلیغات مخرب و بارگیری‌های drive-by از طریق مرورگر وارد می‌شوند. فناوری اطلاعات سایه با ورود فردی به یک برنامه SaaS تأییدنشده در مرورگر آغاز می‌شود. حتی وقتی طعمه اولیه از طریق ایمیل یا چت وارد می‌شود، مسیر واقعی به خطر افتادن اغلب از یک نشست وب می‌گذرد.

این موضوع اهمیت دارد زیرا مدل سنتی مبتنی بر نقطه پایانی تحت فشار است. EDR ضروری است، اما ذاتاً واکنشی عمل می‌کند. Secure Web Gatewayها کمک می‌کنند، اما فیلتر URL و بررسی‌های شهرت هر صفحه مخربی را نمی‌گیرند، به‌ویژه وقتی مهاجمان دامنه‌های جدید را راه‌اندازی می‌کنند یا سایت‌های قانونی را به خطر می‌اندازند. آموزش آگاهی امنیتی همچنان ارزش دارد، اما هیچ تیم جدی‌ای باور ندارد که آموزش به تنهایی جلوی کمپین‌های حرفه‌ای سرقت اعتبارنامه را می‌گیرد.

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

چرا این مدل اکنون نسبت به پنج سال پیش منطقی‌تر است

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

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

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

اعتماد صفر زمان‌بندی را بهتر کرد

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

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

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

تاب‌آوری در برابر فیشینگ محرک واقعی است

فروشندگان اغلب جداسازی مرورگر را به عنوان یک پلتفرم گسترده امنیت وب بازاریابی می‌کنند، اما قوی‌ترین استدلال سازمانی همچنان تاب‌آوری در برابر فیشینگ است. مهاجمان زمانی که یک صفحه جعلی ورود به مایکروسافت ۳۶۵ کار می‌کند، به بهره‌برداری از هسته نیاز ندارند. آنها بلافاصله به باج‌افزار نیاز ندارند اگر بتوانند یک Session Cookie را بدزدند، به صندوق پستی دسترسی پیدا کنند و به صورت جانبی از طریق SaaS حرکت کنند.

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

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

همچنین به یک لایه کنترل داده تبدیل می‌شود

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

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

جداسازی مرورگر امروز در کجا بهتر عمل می‌کند

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

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

خریداران قبل از استقرار چه باید بپرسند

تیم‌های امنیتی باید از شعارهای کلیشه‌ای «وب بد را مسدود کنید» فراتر رفته و سوالات دقیق‌تری بپرسند. محصول چقدر با برنامه‌های مدرن SaaS کار می‌کند؟ تأثیر تأخیر بر مرور روزمره چقدر است؟ آیا سیاست‌ها می‌توانند بر اساس برنامه، گروه کاربری و سطح اعتماد دستگاه متفاوت باشند؟ آیا سیستم به طور شفاف با ارائه‌دهندگان هویت، کنترل‌های DLP و ابزارهای Secure Service Edge یکپارچه می‌شود؟

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

نکات عملی

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

جداسازی مرورگر به روشی که ابزارهای امنیتی هوش مصنوعی هیجان‌انگیز هستند هیجان‌انگیز نیست. شاید دقیقاً به همین دلیل در حال گسترش است. این مشکل پیش پا افتاده اما رو به رشد سازمانی را حل می‌کند: کارهای حساس زیادی در جایی انجام می‌شود که هرگز برای قابل اعتماد بودن به صورت پیش‌فرض طراحی نشده بود. تغییر آرام این است که سازمان‌های بیشتری تصمیم می‌گیرند دیگر نیازی به اعتماد بسیار زیاد به آن ندارند.

اشتراک‌گذاری:
جداسازی مرورگر به شکلی آرام به پیش‌فرض امنیت وب سازمانی تبدیل می‌شود | AIO APEX