راه‌اندازی Time-based Rules در Cisco ASA و Firepower برای کنترل زمان‌بندی دسترسی

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

در Cisco ASA و همچنین در Cisco Secure Firewall امکان تعریف Ruleهای مبتنی بر زمان وجود دارد. این قابلیت اجازه می‌دهد یک Policy فقط در بازه زمانی مشخص فعال باشد و خارج از آن بازه به‌صورت خودکار غیرفعال شود. در این مقاله به‌صورت مهندسی بررسی می‌کنیم چگونه Time-based Ruleها را طراحی، پیاده‌سازی و عیب‌یابی کنیم و چه اشتباهاتی در پروژه‌های واقعی رخ می‌دهد.

اهمیت طراحی صحیح Time-based Policy در معماری امنیت

کنترل دسترسی مبتنی بر زمان اگر درست طراحی نشود، به‌جای افزایش امنیت می‌تواند باعث پیچیدگی، خطای عملیاتی و حتی ایجاد حفره شود. بسیاری از سازمان‌ها Time-based Rule را به‌عنوان یک قابلیت ساده می‌بینند، در حالی که در عمل این قابلیت مستقیماً با منطق Stateful فایروال، ترتیب پردازش Ruleها و مدیریت Session درگیر است. در Cisco ASA و همچنین در Cisco Secure Firewall این موضوع کاملاً مشهود است.

اولین نکته این است که Time-based Policy فقط روی ایجاد Session جدید اثر دارد. یعنی فایروال در لحظه‌ای که Packet اول یک Flow جدید وارد می‌شود، بررسی می‌کند آیا Rule زمان‌بندی‌شده فعال است یا نه. اگر فعال باشد، Session ایجاد می‌شود و تا پایان عمر خود معتبر خواهد بود، حتی اگر چند دقیقه بعد بازه زمانی منقضی شود. این رفتار کاملاً منطقی است، زیرا فایروال Stateful است، اما اگر در طراحی دیده نشود، باعث برداشت اشتباه از عملکرد سیستم می‌شود.

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

موضوع مهم بعدی، تعامل Time-based Rule با ترتیب Policy است. اگر یک Rule زمان‌بندی‌شده بالای یک Rule عمومی Allow قرار گیرد، پس از پایان بازه زمانی، Rule اول غیرفعال می‌شود و ترافیک ممکن است با Rule پایین‌تر Match شود. در چنین حالتی، عملاً محدودسازی زمانی بی‌اثر خواهد بود. بنابراین طراحی صحیح به این معناست که همیشه یک Deny صریح در جای مناسب قرار گیرد تا پس از پایان زمان مجاز، مسیر جایگزین ناخواسته‌ای باقی نماند.

همچنین باید به معماری کلی دسترسی توجه کرد. اگر دسترسی به یک منبع از چند مسیر امکان‌پذیر باشد، مانند مسیر مستقیم اینترنت و مسیر VPN، تعریف Time-based Rule فقط روی یکی از این مسیرها کافی نیست. در یکی از سازمان‌ها، دسترسی یک شعبه باید فقط در شیفت شب فعال می‌بود. Rule زمان‌بندی‌شده روی Interface اصلی اعمال شده بود، اما همان شعبه از طریق VPN ثانویه همچنان دسترسی داشت. تحلیل کامل مسیرهای Routing و VPN نشان داد که محدودسازی باید در هر دو نقطه اعمال شود.

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

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

پیاده‌سازی Time-based Rule در Cisco ASA

در Cisco ASA پیاده‌سازی Time-based Rule در ظاهر ساده است، اما اگر منطق ترتیب پردازش و رفتار Stateful سیستم در نظر گرفته نشود، می‌تواند نتیجه‌ای متفاوت از انتظار ایجاد کند. فرآیند به‌صورت کلی شامل تعریف Time Range و سپس الصاق آن به یک ACE در Access-List است، اما اهمیت موضوع در جزئیات آن نهفته است.

ابتدا باید Time Range با دقت تعریف شود. این Time Range می‌تواند شامل بازه‌های تکرارشونده مانند ساعات اداری در روزهای هفته یا یک بازه مطلق با تاریخ شروع و پایان مشخص باشد. در محیط‌های عملیاتی، معمولاً از بازه‌های تکرارشونده استفاده می‌شود، اما در پروژه‌های موقتی مانند دسترسی پیمانکار، بازه مطلق کاربرد بیشتری دارد. نکته مهم این است که ساعت سیستم ASA باید دقیق و همگام با NTP باشد، زیرا کوچک‌ترین اختلاف زمانی می‌تواند باعث فعال یا غیرفعال شدن Rule در زمان اشتباه شود.

پس از تعریف Time Range، این Object به یک ACE متصل می‌شود. در این مرحله، ترتیب Rule در ACL اهمیت حیاتی دارد. ASA Policy را به‌صورت Top-Down بررسی می‌کند. اگر یک Rule زمان‌بندی‌شده بالاتر از یک Rule عمومی Allow قرار گیرد، در زمان فعال بودن درست عمل می‌کند، اما پس از پایان بازه زمانی، چون ACE دیگر Match نمی‌شود، ترافیک ممکن است با Rule عمومی پایین‌تر Match گردد. این سناریو در پروژه‌های واقعی بسیار رایج است و باعث می‌شود مهندس تصور کند Time-based Policy کار نمی‌کند، در حالی که مشکل در طراحی ترتیب ACL است.

در یکی از سازمان‌ها، دسترسی یک Subnet به اینترنت باید فقط بین ساعت ۸ تا ۱۶ مجاز می‌بود. Time Range تعریف و به ACE مربوطه متصل شد. اما پایین‌تر از آن یک Rule عمومی برای Allow اینترنت وجود داشت که قبلاً برای همه کاربران تعریف شده بود. نتیجه این شد که خارج از ساعات اداری، Rule اول غیرفعال شد و ترافیک با Rule عمومی Match گردید. راه‌حل این بود که یک Deny صریح پس از Rule زمان‌بندی‌شده اضافه شود تا در صورت عدم Match، مسیر جایگزین وجود نداشته باشد.

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

در سناریوهای پیچیده‌تر مانند Multi-ISP یا Policy Routing، باید دقت شود که Time-based ACE روی Interface صحیح اعمال شده باشد. اگر ترافیک از مسیر دیگری خارج شود که ACL متفاوتی دارد، محدودسازی زمانی ممکن است دور زده شود. بنابراین پیش از پیاده‌سازی، باید مسیرهای Routing و NAT نیز تحلیل شوند.

همچنین باید به تعامل Time-based Rule با NAT توجه داشت. اگر NAT به‌گونه‌ای تعریف شده باشد که ترافیک قبل از رسیدن به ACE تغییر آدرس دهد، ACE باید بر اساس آدرس صحیح تعریف شود. در غیر این صورت، ممکن است Time-based Rule هرگز Match نشود. استفاده از ابزارهایی مانند packet-tracer در ASA می‌تواند کمک کند تا دقیقاً مشخص شود آیا ACE زمان‌بندی‌شده در مسیر پردازش Match می‌شود یا خیر.

پیاده‌سازی Time-based Access Control در Cisco Secure Firewall

در Cisco Secure Firewall مدیریت Time-based Ruleها معمولاً از طریق FMC انجام می‌شود. در این محیط، ابتدا یک Time Range Object تعریف می‌شود و سپس در Access Control Policy به‌عنوان شرط استفاده می‌گردد.

مزیت معماری FMC این است که می‌توان Time Range را به‌صورت مرکزی مدیریت کرد و در چندین Rule استفاده نمود. همچنین امکان تعریف Scheduleهای پیچیده‌تر مانند بازه‌های متعدد در هفته وجود دارد.

در پروژه‌ای با چندین شعبه، لازم بود دسترسی برخی کاربران به دیتاسنتر فقط در شیفت شب فعال باشد. با تعریف Time Range مرکزی و اعمال آن روی Rule مربوطه، نیاز به تغییر دستی Policy در هر شیفت حذف شد و مدیریت ساده‌تر گردید.

نکته مهم در Secure Firewall این است که پس از تغییر یا فعال شدن Time-based Rule، Policy باید Deploy شود. اگر Deploy انجام نشود، تغییرات اعمال نخواهد شد. این موضوع در محیط‌های عملیاتی شلوغ گاهی فراموش می‌شود.

تعامل Time-based Rule با NAT و VPN

در سناریوهای پیچیده، Time-based Rule ممکن است فقط روی ACL اعمال شود، اما NAT یا VPN همچنان فعال باشند. این موضوع می‌تواند باعث رفتارهای غیرمنتظره شود.

برای مثال، اگر یک Subnet از طریق VPN به سایت دیگر متصل باشد و Time-based Rule فقط در ACL داخلی تعریف شده باشد، ممکن است ترافیک از مسیر VPN عبور کند و کنترل زمانی دور زده شود. بنابراین طراحی باید جامع باشد و تمام مسیرهای دسترسی بررسی شوند.

در پروژه‌ای که شامل چند Site-to-Site VPN بود، محدودسازی زمانی فقط روی یک Interface اعمال شده بود و ترافیک از مسیر دیگری عبور می‌کرد. تحلیل کامل مسیرهای Routing و VPN باعث شد Policy به‌صورت صحیح در تمام نقاط اعمال شود.

ملاحظات مربوط به NTP و دقت زمان سیستم

یکی از نکات حیاتی که اغلب نادیده گرفته می‌شود، همگام‌سازی زمان سیستم است. اگر ساعت فایروال دقیق نباشد، Time-based Rule در زمان اشتباه فعال یا غیرفعال می‌شود.

در هر دو پلتفرم ASA و Secure Firewall، تنظیم NTP Server قابل انجام است. در یکی از سازمان‌ها، اختلاف چند دقیقه‌ای ساعت باعث شد Rule محدودسازی زودتر از موعد فعال شود و کاربران دچار قطعی غیرمنتظره شوند. فعال‌سازی NTP و همگام‌سازی با سرور داخلی این مشکل را برطرف کرد.

عیب‌یابی Time-based Rule

در ASA می‌توان با بررسی Clock سیستم و استفاده از دستور show access-list وضعیت Match Rule را بررسی کرد. اگر Rule زمان‌بندی‌شده خارج از بازه زمانی باشد، Hit Count آن افزایش نمی‌یابد.

در Secure Firewall نیز بررسی Hit Count در FMC و مشاهده Timestamp Eventها کمک می‌کند بفهمیم آیا Rule در بازه زمانی مورد نظر فعال بوده یا خیر.

همچنین باید در نظر داشت که Sessionهای فعال ممکن است پس از پایان بازه زمانی همچنان برقرار باشند. در سناریوهای حساس، پاک‌سازی دستی Session یا کاهش Timeout توصیه می‌شود.

سناریوی عملی کامل

در یک سازمان آموزشی، دسترسی دانشجویان به اینترنت باید فقط در ساعات مشخص فعال می‌بود. ابتدا Time-based Rule در ASA تعریف شد، اما به دلیل وجود Rule عمومی پایین‌تر، محدودسازی بی‌اثر بود. پس از بازطراحی ACL و قرار دادن Rule Deny پس از پایان زمان مجاز، کنترل کامل برقرار شد.

در مرحله بعد، Sessionهای فعال نیز پس از پایان زمان مجاز پاک‌سازی شدند تا دسترسی کاملاً قطع شود. این سناریو نشان داد که Time-based Control فقط یک تنظیم ساده نیست، بلکه بخشی از طراحی کامل Policy است.

جمع‌بندی مهندسی

Time-based Rule در Cisco ASA و Cisco Secure Firewall ابزار قدرتمندی برای کنترل دسترسی مبتنی بر زمان است، اما اگر بدون توجه به ترتیب Ruleها، Sessionهای فعال، NAT و VPN پیاده‌سازی شود، می‌تواند رفتار غیرمنتظره ایجاد کند.

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

وینو سرور؛ مرجع تخصصی طراحی Policyهای زمان‌بندی‌شده در فایروال‌های سیسکو

پیاده‌سازی Time-based Policy در محیط‌های Enterprise نیازمند شناخت عمیق تعامل ACL، NAT، VPN و Session Management است. بسیاری از مشکلات زمانی رخ می‌دهد که این تعاملات دیده نشوند.

وینو سرور با تجربه عملی در طراحی و بازبینی Policyهای پیشرفته در Cisco Secure Firewall و Cisco ASA می‌تواند ساختار دسترسی سازمان شما را به‌صورت مهندسی و زمان‌بندی‌شده طراحی کند. اگر هدف شما کنترل دقیق دسترسی بدون مداخله دستی و ریسک عملیاتی است، وینو سرور می‌تواند مرجع تخصصی شما در این مسیر باشد.