بهینه‌سازی Policy در ESET Endpoint Security

پاسخ کوتاه: Policy خوب در ESET یعنی «حداقل دسترسی لازم با کمترین Exception». یک Policy واحد برای کل سازمان معمولاً یا بیش از حد آزاد است یا برای بعضی واحدها اختلال ایجاد می‌کند. مسیر امن‌تر این است که Baseline مشترک بسازید، سپس فقط تفاوت‌های واقعی واحدها را با Policyهای محدود و قابل ردیابی اضافه کنید.

Policy را بر اساس Role و Risk طراحی کنید

در ESET PROTECT می‌توان تنظیمات یک Endpoint را به Policy تبدیل و روی گروه‌های دیگر اعمال کرد. این قابلیت مفید است، اما تبدیل Configuration یک سیستم به «استاندارد سازمان» بدون بازبینی می‌تواند تنظیمات محلی یا Exceptionهای قدیمی را تکثیر کند. Baseline باید مستقل از یک دستگاه خاص تعریف شود.

Firewall: از Learning برای Production دائمی استفاده نکنید

مستندات ESET درباره Filtering Mode هشدار می‌دهد که Learning Mode برای محیط کنترل‌شده و مدت محدود مناسب است، چون Ruleها را بر اساس رفتار مشاهده‌شده ایجاد می‌کند و ذاتاً حالت امن دائمی نیست. برای محیط سازمانی، ابتدا ارتباطات لازم را در Pilot شناسایی کنید و سپس به Automatic with Exceptions یا Policy-based متناسب با سطح کنترل موردنیاز برسید.

قبل از تغییر Firewall چه چیزهایی ثبت شود؟

• Subnetها و VPNهایی که باید Trusted باشند.
• ارتباطات مدیریتی مانند RDP و ابزارهای Remote Support.
• Applicationهای داخلی با Port یا Destination خاص.
• مسیر برگشت سریع Policy در صورت قطع ارتباط.

ESET به‌طور مشخص توصیه می‌کند Trusted Zone و IP Setها پیش از استقرار گسترده تعریف شوند تا تغییر Policy باعث قطع Connectivity نشود.

Web Control: دسته‌بندی را با نیاز کسب‌وکار شروع کنید

Web Control باید ریسک و الزامات سازمان را هدف بگیرد، نه اینکه صرفاً فهرست بزرگی از سایت‌ها را مسدود کند. دسته‌هایی که Legal، Security یا Productivity Risk دارند می‌توانند در Policy قرار گیرند، اما Exception باید محدود به URL/Group لازم باشد. گزارش Blockهای پرتکرار کمک می‌کند بفهمید Policy اشتباه است یا رفتار کاربر نیاز به اصلاح دارد.

Device Control: برای هر واحد یک سطح ریسک تعریف کنید

نیاز واحد مالی، واحد فنی و تیم پشتیبانی یکسان نیست. برای USB یا دستگاه‌های جانبی بهتر است حالت Read-only، Allow by Device/Group یا Block کامل بر اساس Use Case انتخاب شود. Exception دائمی و بدون Owner به مرور Policy را بی‌اثر می‌کند.

Exclusion باید چهار مشخصه داشته باشد

• Scope محدود: فقط Process، Path یا Object واقعاً لازم.
• دلیل: Ticket یا Change Request مشخص.
• Owner: فرد یا تیم مسئول.
• Expiry/Review: تاریخ بازبینی برای حذف Exceptionهای قدیمی.

اگر برای رفع هر False Positive یک Folder کامل Exclude شود، سطح حفاظت به‌تدریج کاهش می‌یابد. ابتدا Detection و رفتار Application را بررسی کنید و فقط در صورت ضرورت Exception حداقلی بسازید.

مدل Rollout پیشنهادی

1. Baseline را روی گروه آزمایش شامل چند Role متفاوت اعمال کنید.
2. حداقل یک چرخه کاری کامل سازمان را در Pilot پوشش دهید.
3. Blocked Communication، Detection، User Complaint و Performance را ثبت کنید.
4. Exceptionهای لازم را با Scope محدود اضافه کنید.
5. Policy را مرحله‌ای روی گروه‌های بزرگ‌تر اعمال کنید.
6. بعد از هر مرحله، Override و Policy Conflict را بررسی کنید.

چه KPIهایی نشان می‌دهند Policy بهتر شده است؟

تعداد Exceptionهای فعال، Exceptionهای بدون Owner، Blockهای تکراری، Deviceهای خارج از Policy، تعداد Policyهای Overlap و زمان لازم برای رفع یک Conflict معیارهای بهتری از «تعداد Rule» هستند.

برای شناخت محصول به صفحه ESET Endpoint Security و برای معماری Endpoint سازمانی به راهکار امنیت Endpoint مراجعه کنید.

منابع رسمی

• ESET — Convert endpoint configuration to policy
• ESET — Firewall filtering modes
• ESET — Firewall zones and profiles
• ESET — Web Control in ESET PROTECT

آخرین بازبینی: 2026-09-23

پرسش‌های متداول

آیا Policy-based Firewall همیشه امن‌ترین انتخاب است؟

کنترل آن سخت‌گیرانه‌تر است، اما اگر Ruleهای لازم کامل نباشند می‌تواند سرویس‌های کاری را قطع کند. باید پس از Pilot و شناخت ارتباطات ضروری استفاده شود.

چند Policy برای سازمان مناسب است؟

عدد ثابت وجود ندارد. هدف باید کمترین تعداد Policy باشد که تفاوت‌های واقعی Role و Risk را پوشش دهد، بدون ایجاد Override و Conflict غیرقابل مدیریت.