فرض کنید یکی از کاربران سازمان برای سادهتر شدن کار روزانه، یک افزونه مرورگر برای ترجمه، مدیریت تبها، گرفتن Screenshot یا اتصال به یک سرویس ابری نصب میکند. افزونه ظاهراً مفید است؛ اما در لحظه نصب مجوزهایی مثل «خواندن و تغییر دادههای وبسایتهایی که باز میکنید» درخواست میکند. اگر همان کاربر به CRM، سامانه مالی، ایمیل سازمانی یا پنلهای مدیریتی دسترسی داشته باشد، دیگر با یک ابزار ساده طرف نیستیم؛ با یک جزء نرمافزاری روبهرو هستیم که داخل مرورگر و در کنار دادههای حساس سازمان اجرا میشود.
برای همین مدیریت افزونههای مرورگر در محیط سازمانی نباید به این سؤال محدود شود که «این Extension از Chrome Web Store نصب شده یا نه؟». سؤالهای مهمتر اینها هستند: چه کسی آن را نصب کرده؟ چه Permissionهایی دارد؟ روی چه سایتهایی اجرا میشود؟ آیا واقعاً برای کار لازم است؟ اگر نسخه یا Publisher آن تغییر کرد چه کسی متوجه میشود؟ و اگر یک افزونه پرریسک پیدا شد، چطور میتوان آن را روی صدها Endpoint بهصورت مرکزی Block یا حذف کرد؟
ManageEngine Browser Security Plus برای همین نقطه طراحی شده است: ایجاد دید متمرکز روی Browserها و Add-onها، کنترل نصب Extension و Plugin، اعمال Policyهای امنیتی، مدیریت Compliance و محدود کردن سطح دسترسی مرورگر در شبکه سازمانی. در این راهنما تمرکز ما روی یکی از کاربردیترین بخشهای محصول است: Extension Management با مدل Allowlist-first.
اگر ابتدا میخواهید با تصویر کلی محصول آشنا شوید، مطلب Browser Security Plus چیست؟ نقطه شروع مناسبی است. این نوشته روی طراحی عملی Policy برای Chrome، Edge و مرورگرهای Chromium-based تمرکز دارد و با مقاله معرفی محصول رقابت نمیکند.
چرا افزونه مرورگر باید مثل نرمافزار سازمانی مدیریت شود؟
در بسیاری از سازمانها نصب نرمافزار روی Windows محدود است، اما نصب Extension داخل Browser آزاد مانده است. همین تفاوت میتواند یک شکاف کنترلی ایجاد کند. کاربر ممکن است نتواند یک فایل EXE نصب کند، ولی بتواند افزونهای را نصب کند که به Tabها، History، Clipboard، Downloadها، Formها یا محتوای صفحات دسترسی دارد.
Microsoft در راهنمای سازمانی Edge توصیه میکند سازمانها فقط به Allowlist و Blocklist اسمی اکتفا نکنند و Permissionهای موردنیاز Extension و سایتهایی که افزونه اجازه دسترسی به آنها دارد را هم در تصمیمگیری لحاظ کنند. Google Chrome Enterprise نیز امکان Block/Allow، Force Install و کنترل Extensionها از طریق Policy را در محیطهای مدیریتشده ارائه میکند.
این یعنی Extension Governance باید بخشی از Endpoint Security باشد، نه یک تنظیم فرعی مرورگر.
Browser Security Plus در مدیریت Extension چه دیدی ایجاد میکند؟
بر اساس مستندات فعلی ManageEngine، Browser Security Plus امکان شناسایی Browserهای موجود در شبکه، مشاهده Add-onها و Extensionها، کنترل نصب آنها، Block کردن Add-onهای نامطلوب و اعمال Policy روی Browserهای مختلف را فراهم میکند. Add-on Management در محصول برای Chrome، Microsoft Edge، Firefox، Ulaa و تعدادی از مرورگرهای Chromium-based قابل استفاده است؛ با این حال پوشش دقیق هر قابلیت بین Browserها یکسان نیست و قبل از Rollout باید جدول Feature Support نسخه فعلی محصول بررسی شود.
مزیت اصلی این است که مدیر امنیت بهجای جستوجوی دستی روی هر سیستم، یک Inventory مرکزی از وضعیت Browser و Add-onها دارد و میتواند Policy را در سطح گروههای Endpoint اعمال کند.
مدل Allowlist-first چیست؟
در مدل سنتی، همه Extensionها مجازند مگر اینکه یکی از آنها بعداً به Blocklist اضافه شود. این روش برای محیطهای کوچک ساده است، اما در سازمان بزرگ یک مشکل بنیادی دارد: تیم امنیت فقط چیزهایی را Block میکند که از قبل میشناسد.
در مدل Allowlist-first منطق برعکس است:
بهصورت پیشفرض نصب Extension آزاد نیست؛ فقط افزونههایی که سازمان ارزیابی و تأیید کرده مجاز هستند.
Google Chrome Enterprise این الگو را با حالت «Block all apps, admin manages allowlist» پشتیبانی میکند. ManageEngine نیز در Browser Security Plus اجازه میدهد نصب Extension توسط User محدود شود و Extensionهای مورد اعتماد در Allowlist قرار گیرند.
| مدل | مزیت | ریسک | مناسب برای |
|---|---|---|---|
| Allow all + Blocklist | کمترین اصطکاک برای کاربر | Extension ناشناخته تا زمان شناسایی مجاز میماند | محیط کمریسک یا Pilot |
| Block all + Allowlist | کنترل قوی و قابل Audit | نیازمند فرآیند درخواست و بررسی Extension | مالی، بانکی، درمانی، زیرساخت حیاتی |
| Permission-based | مقیاسپذیرتر از بررسی اسمی | نیازمند شناخت Permissionها | سازمانهای بزرگ |
| Force Install | نصب اجباری ابزارهای سازمانی | اشتباه در انتخاب Extension روی همه Endpointها اثر میگذارد | Password Manager، DLP، SSO یا ابزارهای رسمی |
چرا Blocklist بهتنهایی کافی نیست؟
Blocklist برای پاسخ سریع به Extension شناختهشده خطرناک مفید است، اما اگر تنها کنترل سازمان باشد، همیشه یک قدم عقب میماند. روزانه Extensionهای جدید منتشر میشوند و نام، Publisher یا حتی مالک یک Extension میتواند تغییر کند.
در مقابل، Allowlist سازمان را مجبور میکند یک سؤال ساده بپرسد: «آیا این Extension دلیل کاری مشخص و Owner مشخص دارد؟»
این تغییر نگاه مهم است. در امنیت Endpoint هدف این نیست که همه ابزارها ممنوع شوند؛ هدف این است که هر جزء نرمافزاری که به داده سازمان دسترسی دارد، دلیل و مالک مشخص داشته باشد.
مرحله اول: قبل از Block کردن، Inventory بگیرید
اولین اقدام درست در Browser Security Plus حذف گسترده Extensionها نیست. ابتدا باید بدانید الان چه چیزی در سازمان نصب شده است.
Inventory اولیه بهتر است حداقل این اطلاعات را پوشش دهد:
- نام Extension
- Extension ID
- Browser مربوط
- نسخه
- تعداد Endpointهای دارای Extension
- Publisher یا Source
- Permissionهای درخواستی
- کاربران یا گروههای استفادهکننده
- ضرورت کسبوکاری
- وضعیت Allow / Block / Review
بدون این مرحله، ممکن است تیم امنیت Extensionی را حذف کند که یک فرآیند عملیاتی مهم به آن وابسته است یا برعکس، Extension پرریسکی را فقط به دلیل شناختهشده بودن نام آن تأیید کند.
مرحله دوم: Extensionها را براساس ریسک طبقهبندی کنید
همه Extensionها سطح ریسک یکسانی ندارند. یک افزونه تغییر Theme مرورگر با افزونهای که میتواند محتوای همه صفحات را بخواند یا Downloadها را مدیریت کند یکسان نیست.
برای شروع میتوانید یک مدل ساده سهسطحی تعریف کنید:
| سطح | نمونه وضعیت | اقدام پیشنهادی |
|---|---|---|
| کمریسک | Permission محدود، نیاز کاری مشخص، Publisher معتبر | Allow با بازبینی دورهای |
| متوسط | Permission گسترده ولی نیاز کسبوکاری واقعی | Allow محدود به گروه مشخص + Monitoring |
| پرریسک | نیاز نامشخص، Permission وسیع، Source نامطمئن یا Extension قدیمی | Block یا قرنطینه تا بررسی |
در Browser Security Plus میتوان از Add-on Management برای کنترل Installation و مدیریت Extensionهای مورداعتماد استفاده کرد. مستندات ManageEngine همچنین امکان جستوجو و Blacklist کردن Permissionهای مشخص را در Policyهای Chrome Extension Management توضیح میدهند.
Permission-based Control؛ از اسم Extension فراتر بروید
فرض کنید Extension A و Extension B هر دو ابزار Productivity هستند. نام و Rating هر دو قابل قبول است، اما Extension A فقط به تب فعال دسترسی دارد و Extension B اجازه خواندن و تغییر دادهها روی همه سایتها را درخواست میکند.
اگر تصمیم فقط براساس نام یا محبوبیت باشد، این تفاوت دیده نمیشود.
مدل Permission-based به شما اجازه میدهد یک Rule سازمانی تعریف کنید. برای مثال:
- Extensionهایی که USB Access میخواهند نیازمند بررسی Security باشند.
- Extensionهایی با دسترسی به همه URLها فقط برای گروههای مشخص مجاز باشند.
- Extensionهای نصبشده خارج از Store رسمی Block شوند.
- Extensionهای دارای دسترسی حساس فقط در صورت Business Owner مشخص Allow شوند.
Microsoft نیز در راهنمای Enterprise Edge، مدیریت Extension براساس Permission و Site Access را برای سازمانهای بزرگ مقیاسپذیرتر از Allowlist/Blocklist صرف معرفی میکند.
Force Install را فقط برای Extensionهای واقعاً ضروری استفاده کنید
Force Install قابلیت مهمی است؛ چون میتوانید Extension ضروری را بدون دخالت User روی Endpointها نصب کنید. مثالهای رایج:
- Password Manager سازمانی
- SSO Extension
- Extension امنیتی یا DLP
- ابزار رسمی CRM یا ERP
- افزونه ارتباط با Service Desk یا ابزار داخلی سازمان
اما Force Install باید با احتیاط استفاده شود. وقتی یک Extension بهصورت اجباری روی هزار سیستم Deploy میشود، هر مشکل Compatibility یا Security آن هم با همان مقیاس منتشر میشود.
بهتر است Rollout بهصورت Ring انجام شود:
- تیم IT و Security
- Pilot Group محدود
- یک واحد کسبوکار
- بخش بزرگتر
- کل سازمان
یک Policy واحد برای همه کاربران نسازید
کار یک Developer، حسابدار، کارشناس SOC و کاربر Call Center یکسان نیست. اگر Allowlist مشترک برای همه تعریف شود، یا بیش از حد سختگیرانه میشود یا بیش از حد باز.
مدل بهتر، Policy مبتنی بر نقش است:
| گروه | Policy نمونه |
|---|---|
| Finance | Allowlist محدود، ممنوعیت Extensionهای ناشناس، کنترل Download و Upload |
| Developers | Extensionهای توسعه مجاز، ولی Permissionهای حساس نیازمند Approval |
| Executives | کمترین تعداد Extension و سختگیری بیشتر روی Data Access |
| Help Desk | Allow ابزارهای پشتیبانی موردنیاز، Block نصب شخصی |
| Kiosk/Shared Device | حداقل Extension و Browser Lockdown در صورت نیاز |
Browser Security Plus Policyها را در سطح Endpointها و گروهها اعمال میکند و همین موضوع امکان طراحی چند Policy بهجای یک Policy عمومی را فراهم میکند.
Chrome و Edge را جداگانه بررسی کنید
Chrome و Edge هر دو بر Chromium متکی هستند، اما Policy، Store، Enterprise Management و جزئیات Extension Governance آنها کاملاً یکسان نیست. Microsoft Edge امکان Allow، Block و Force کردن Extension را در Management Service و Group Policy ارائه میکند. Chrome Enterprise نیز حالتهای مشابه را از طریق Admin Console و Policyهای Enterprise فراهم میکند.
Browser Security Plus این مدیریت را از یک Console مرکزی سادهتر میکند، اما هنگام طراحی Policy باید تفاوت Browserها را در نظر بگیرید؛ بهویژه وقتی سازمان ترکیبی از Chrome، Edge، Firefox و Browserهای Chromium دیگر دارد.
Extensionهای خارج از Store رسمی چه وضعیتی داشته باشند؟
برای بیشتر کاربران سازمانی، Extension خارج از Store رسمی باید یک Exception باشد، نه حالت عادی. Google Chrome Enterprise Policyهایی برای محدود کردن External Extensionها دارد و Browser Security Plus نیز در مستندات Compliance خود توصیه میکند نصب Extensionهای غیر Web Store محدود شود.
اگر سازمان Extension داخلی دارد، بهتر است فرآیند مشخصی برای آن تعریف شود:
- مالک فنی مشخص
- Repository و Source Code کنترلشده
- Code Review
- Versioning
- Signing در صورت امکان
- Change Management
- Rollback Plan
- فهرست Endpointهای مجاز
Extension Review باید دورهای باشد، نه فقط هنگام نصب
تأیید امروز به معنی تأیید دائمی نیست. Extension ممکن است Update شود، Permission جدید درخواست کند، Publisher آن تغییر کند یا دیگر برای کسبوکار لازم نباشد.
یک چرخه Review سهماهه یا ششماهه برای Extensionهای Allow شده میتواند این موارد را بررسی کند:
- آیا هنوز استفاده میشود؟
- آیا Owner همان فرد یا تیم است؟
- آیا Permissionها تغییر کردهاند؟
- آیا نسخه قدیمی روی بخشی از Endpointها باقی مانده؟
- آیا Extension مشابه و کمریسکتری وجود دارد؟
- آیا Extension باید از Allowlist حذف شود؟
Browser Security Plus و Compliance
Browser Security Plus فقط Extension Manager نیست. محصول میتواند Browser Configuration، Web Filter، Restriction، Compliance، Download/File Activity Restriction و سایر کنترلهای Browser Security را هم در کنار Add-on Management ارائه کند.
از دید Governance، این موضوع مهم است چون Extension Policy را میتوان به بخشی از Baseline امنیتی Endpoint تبدیل کرد. مثلاً در کنار کنترل Extension میتوان بررسی کرد Browserهای مدیریتشده نسخه مناسب دارند، تنظیمات حساس بهدرستی اعمال شده و سیستمها با Policy سازمان منطبق هستند.
اگر سازمان شما از چارچوبهای کنترلی استفاده میکند، مطلب کنترلهای امنیتی CIS چیست؟ میتواند برای طراحی Baseline کلی Endpoint و Browser مفید باشد.
ارتباط Browser Security Plus با Endpoint Central
در معماری فعلی ManageEngine، Browser Security از داخل اکوسیستم Endpoint Central نیز قابل استفاده است. طبق FAQ رسمی فعلی ManageEngine، ماژول Browser Security در Security Edition در دسترس است و برای بعضی Editionهای Professional، UEM و Enterprise بهصورت Add-on ارائه میشود. همچنین صفحه Browser Security Plus هنوز مدل Standalone با Free Edition برای تعداد محدودی Computer و Professional Edition را معرفی میکند.
به همین دلیل قبل از خرید باید مشخص شود سازمان Browser Security را مستقل میخواهد یا بهعنوان بخشی از معماری مدیریت Endpoint. اگر Endpoint Central از قبل در سازمان وجود دارد، بررسی Edition فعلی و Add-onهای موجود میتواند از خرید اشتباه جلوگیری کند.
برای بررسی محصول اصلی میتوانید صفحه Endpoint Central مدانت را ببینید و برای مدل محاسبه License نیز راهنمای لایسنس Endpoint Central را مطالعه کنید.
یک معماری پیشنهادی برای سازمان متوسط
فرض کنیم سازمان ۸۰۰ Endpoint دارد و بیشتر کاربران از Chrome و Edge استفاده میکنند.
معماری Policy میتواند اینطور باشد:
- Discovery: شناسایی همه Browserها و Add-onها.
- Baseline: تهیه فهرست Extensionهای ضروری و پرکاربرد.
- Risk Review: بررسی Permission و Business Need.
- Allowlist: تأیید Extensionهای مجاز.
- Default Deny: بستن نصب آزاد برای گروههای حساس.
- Request Workflow: تعریف مسیر درخواست Extension جدید.
- Pilot: اعمال روی ۳۰ تا ۵۰ Endpoint.
- Phased Deployment: گسترش مرحلهای.
- Compliance Monitoring: شناسایی Endpointهای خارج از Policy.
- Periodic Review: حذف Extensionهای بلااستفاده یا پرریسک.
فرآیند درخواست Extension جدید را فراموش نکنید
اگر نصب Extension را میبندید اما هیچ مسیر رسمی برای درخواست ابزار جدید ایجاد نمیکنید، کاربران بهدنبال راه دور زدن Policy میروند یا تیم IT به گلوگاه تبدیل میشود.
فرآیند درخواست میتواند بسیار ساده باشد:
| فیلد | نمونه |
|---|---|
| نام Extension | Example CRM Helper |
| Store URL / ID | شناسه رسمی Extension |
| Business Justification | اتصال مرورگر به CRM واحد فروش |
| کاربران نیازمند | Sales Team |
| مدت نیاز | دائمی / موقت |
| Owner | مدیر فروش |
| Security Review | تأیید / رد / نیاز به تست |
اگر سازمان ServiceDesk Plus دارد، همین درخواست میتواند به یک Service Catalog Item تبدیل شود تا Approval، تاریخچه و Audit Trail هم داشته باشد.
چه KPIهایی برای Extension Governance مفیدند؟
فقط تعداد Extensionهای Block شده معیار موفقیت نیست. KPIهای بهتر عبارتاند از:
- تعداد Extensionهای نصبشده به ازای هر Endpoint
- درصد Endpointهای دارای Extension غیرمجاز
- تعداد Extensionهای بدون Business Owner
- تعداد Extensionهای قدیمی یا نیازمند Review
- میانگین زمان بررسی درخواست Extension جدید
- درصد Extensionهای Force-installed که روی همه Endpointهای هدف سالم هستند
- تعداد Exceptionهای منقضیشده
- درصد Compliance گروههای حساس
اشتباهات رایج در Rollout
Block کردن همه Extensionها در روز اول
این روش احتمال اختلال کسبوکار را بالا میبرد. ابتدا Inventory و Pilot لازم است.
اعتماد صرف به Rating و Store
وجود Extension در Store رسمی بهتنهایی Business Approval محسوب نمیشود. Permission و نیاز کاری باید بررسی شود.
Allowlist بدون Owner
اگر معلوم نباشد چه تیمی مسئول Extension است، چند ماه بعد کسی نمیداند چرا هنوز مجاز است.
یک Policy برای تمام واحدها
نیاز توسعهدهنده با کاربر Finance یکسان نیست. Policy باید مبتنی بر Role باشد.
عدم بازبینی بعد از Update
Extension یک نرمافزار زنده است. Update میتواند رفتار یا Permission را تغییر دهد.
Checklist پیشنهادی برای شروع
- Inventory همه Browserها و Extensionها را بگیرید.
- Extensionهای ضروری کسبوکار را مشخص کنید.
- برای هر Extension یک Owner تعیین کنید.
- Permissionهای حساس را تعریف کنید.
- برای واحدهای حساس Allowlist-first اجرا کنید.
- نصب Extension خارج از Store رسمی را محدود کنید.
- Force Install را فقط برای ابزارهای ضروری بهکار ببرید.
- Policy را ابتدا روی Pilot Group تست کنید.
- فرآیند درخواست Extension جدید تعریف کنید.
- Compliance را دورهای اندازهگیری کنید.
- Extensionهای بلااستفاده را از Allowlist حذف کنید.
- تفاوت قابلیتها بین Chrome، Edge و سایر Browserها را قبل از Rollout بررسی کنید.
Browser Security Plus را چه زمانی جداگانه بررسی کنیم؟
اگر مسئله اصلی سازمان فقط Patch و Inventory سیستمعامل نیست و Browser به نقطه اصلی دسترسی به SaaS، CRM، ERP و سامانههای تحت وب تبدیل شده، Browser Security ارزش بررسی مستقل دارد. این موضوع در سازمانهایی که کاربران اجازه نصب Add-on دارند، داده حساس در Browser جابهجا میشود یا چند Browser مختلف در شبکه استفاده میشود اهمیت بیشتری پیدا میکند.
برای سازمانی که Endpoint Central را از قبل دارد، بهتر است ابتدا Edition فعلی و امکان افزودن Browser Security بررسی شود. برای سازمانی که فقط به مدیریت Browser نیاز دارد، مدل Standalone Browser Security Plus هم میتواند بررسی شود. انتخاب درست باید براساس تعداد Endpoint، Browserهای مورد استفاده، سطح کنترل موردنیاز، Compliance و معماری فعلی Endpoint Management انجام شود.
سخن پایانی
Extension مرورگر یک ابزار کوچک کنار Address Bar نیست؛ در بسیاری از موارد بخشی از زنجیره نرمافزاری کاربر است و میتواند در همان فضایی اجرا شود که دادههای سازمانی نمایش داده میشوند. به همین دلیل، مدیریت Extension باید همان نظم و Governanceای را داشته باشد که برای نرمافزارهای Endpoint در نظر میگیریم.
Browser Security Plus کمک میکند از مدل واکنشی «هر وقت Extension خطرناک پیدا شد Blockش کنیم» به مدل کنترلشدهتری برسیم: ابتدا Inventory، سپس ارزیابی Permission و Business Need، بعد Allowlist، Rollout مرحلهای و در نهایت Review دورهای.
اگر قصد دارید Browser Security Plus یا ماژول Browser Security در Endpoint Central را برای تعداد واقعی Endpointهای سازمان ارزیابی کنید، مدانت میتواند در انتخاب Edition، طراحی Policy، پیادهسازی، آموزش و پشتیبانی کمک کند. برای برآورد License و محصولات ManageEngine به صفحه استعلام لایسنس ManageEngine مراجعه کنید یا از طریق تماس با مدانت سناریوی فعلی Browser و Endpoint سازمان را مطرح کنید.
منابع
- ManageEngine Browser Security Plus Features
- ManageEngine Chrome Extensions Management
- ManageEngine Browser Security FAQ
- Google Chrome Enterprise – Managing Extensions
- Microsoft Edge – Manage Extensions in the Enterprise
