در شبکههای امروزی، تصمیمگیری امنیتی فقط بر اساس IP و Port دیگر کافی نیست. بسیاری از اپلیکیشنها از پورتهای مشترک مانند 443 استفاده میکنند و تشخیص آنها فقط با Layer 4 امکانپذیر نیست. اینجاست که کنترل مبتنی بر Application در Cisco Firepower Threat Defense اهمیت پیدا میکند. در این رویکرد، فایروال ترافیک را در لایه Application تحلیل میکند و بر اساس نوع اپلیکیشن واقعی تصمیم Allow، Block یا Monitor میگیرد، نه صرفاً بر اساس شماره پورت.
در این مقاله، نحوه طراحی Policyهای مبتنی بر Application در محیط عملیاتی را بررسی میکنیم؛ از درک معماری گرفته تا سناریوی واقعی و نکات بهینهسازی.
برای طراحی درست Policy مبتنی بر Application، باید بدانید تشخیص اپلیکیشن در Firepower دقیقاً چگونه انجام میشود و در کجای زنجیره پردازش ترافیک قرار دارد. در Cisco Firepower Threat Defense، قابلیت Application Visibility and Control یا بهاختصار AVC بخشی از موتور تحلیل لایه 7 است که در چارچوب Access Control Policy اجرا میشود. این یعنی تشخیص اپلیکیشن جدا از فایروال نیست، بلکه در همان مسیر تصمیمگیری امنیتی اتفاق میافتد.
وقتی یک Session از شبکه عبور میکند، ابتدا مراحل پایه مانند Route Lookup و NAT انجام میشود. سپس Access Control Policy بررسی میشود تا مشخص شود ترافیک اصولاً مجاز است یا خیر. اگر Rule مربوطه اجازه تحلیل لایه Application را بدهد، موتور شناسایی اپلیکیشن وارد عمل میشود. این موتور با استفاده از چندین روش، اپلیکیشن واقعی را تشخیص میدهد؛ نه فقط بر اساس پورت، بلکه بر اساس Signatureهای رفتاری، الگوهای پروتکل و حتی ویژگیهای خاص هر سرویس.
برای مثال، دو سرویس مختلف ممکن است هر دو از پورت 443 استفاده کنند. در مدل سنتی، هر دو به عنوان HTTPS شناخته میشوند. اما در AVC، سیستم میتواند تشخیص دهد که یکی Microsoft Teams است، دیگری Dropbox و سومی یک اپلیکیشن ناشناس که از HTTPS برای تونلسازی استفاده میکند. این سطح از تشخیص به کمک پایگاه داده اپلیکیشنها و Signatureهایی انجام میشود که به صورت دورهای بهروزرسانی میشوند.
نکته مهم این است که تشخیص اپلیکیشن معمولاً در مراحل ابتدایی Session کامل نمیشود. در بسیاری از موارد، سیستم ابتدا Session را به صورت موقت Allow میکند تا اطلاعات کافی برای شناسایی اپلیکیشن جمعآوری شود. سپس اگر اپلیکیشن شناساییشده با Policy مغایرت داشته باشد، میتواند Session را Reset یا Block کند. به همین دلیل طراحی Ruleهای مبتنی بر Application باید با درک رفتار Session-Based انجام شود، نه Packet-Based.
Application Detection همچنین میتواند با سایر قابلیتها ترکیب شود. برای مثال میتوانید یک Rule تعریف کنید که اپلیکیشن خاصی Allow باشد، اما همزمان Intrusion Policy نیز فعال باشد تا رفتار مخرب احتمالی در همان اپلیکیشن شناسایی شود. این ترکیب باعث میشود تصمیمگیری امنیتی فقط مبتنی بر نام اپلیکیشن نباشد، بلکه رفتار آن نیز بررسی شود.
از منظر مدیریتی، تمام دستهبندی اپلیکیشنها، تعریف Ruleها و گزارشگیری از طریق Cisco Firepower Management Center انجام میشود. در FMC میتوانید اپلیکیشنها را بر اساس دستهبندیهایی مانند Collaboration، Streaming، File Sharing یا High Risk Applications فیلتر کنید و در Policy استفاده نمایید. همچنین میتوانید ببینید کدام اپلیکیشنها بیشترین مصرف پهنای باند را دارند و چه کاربرانی از آنها استفاده میکنند.
موضوع مهم دیگر، مدیریت اپلیکیشنهای Encrypted است. در بسیاری از موارد، حتی بدون SSL Decryption نیز امکان تشخیص اپلیکیشن در سطح SNI یا الگوهای اولیه وجود دارد. اما برای تحلیل عمیقتر، بهویژه در مواردی که اپلیکیشن رفتار خود را پنهان میکند، فعالسازی SSL Inspection میتواند دقت تشخیص را افزایش دهد. البته این موضوع باید با در نظر گرفتن ظرفیت سختافزار و سیاستهای حریم خصوصی سازمان انجام شود.
در معماریهای سنتی، سیاستهای امنیتی بر اساس IP آدرس، Port و Protocol نوشته میشدند. این مدل زمانی مؤثر بود که هر سرویس روی پورت مشخص و قابل پیشبینی اجرا میشد. اما امروز تقریباً همه اپلیکیشنها از پورتهای عمومی مانند 80 و 443 استفاده میکنند و حتی بسیاری از آنها از تکنیکهای رمزنگاری و تونلسازی برای عبور از کنترلهای ساده استفاده میکنند. در چنین شرایطی، اگر فقط بر اساس پورت تصمیم بگیرید، عملاً کنترل واقعی روی رفتار کاربران ندارید.
در Cisco Firepower Threat Defense، طراحی Policy مبتنی بر Application به شما اجازه میدهد تصمیم امنیتی را بر اساس «ماهیت واقعی ترافیک» بگیرید، نه صرفاً ظاهر آن. این تغییر نگاه از Layer 4 به Layer 7، یک جهش معماری محسوب میشود.
اولین دلیل اهمیت این رویکرد، کاهش سطح حمله است. وقتی فقط پورت 443 را Allow میکنید، در واقع هزاران سرویس مختلف را همزمان مجاز کردهاید. اما وقتی فقط اپلیکیشنهای مشخص مانند Microsoft 365 یا سرویسهای موردنیاز سازمان را Allow میکنید، بقیه اپلیکیشنها حتی اگر از همان پورت استفاده کنند، مسدود خواهند شد. این کار احتمال سوءاستفاده از سرویسهای عمومی را به شکل محسوسی کاهش میدهد.
دومین دلیل، اجرای دقیقتر سیاستهای سازمانی است. بسیاری از سازمانها سیاستهایی درباره استفاده از شبکههای اجتماعی، سرویسهای اشتراک فایل یا ابزارهای Remote Access دارند. اگر کنترل مبتنی بر Application نداشته باشید، مجبور میشوید کل پورت یا حتی کل دامنهای را مسدود کنید که ممکن است کاربردهای مشروع نیز داشته باشد. اما با کنترل مبتنی بر اپلیکیشن، میتوانید دقیقاً همان سرویس یا قابلیت خاص را مدیریت کنید.
سومین موضوع، مدیریت پهنای باند و منابع است. در بسیاری از شبکهها، مصرف غیرضروری پهنای باند ناشی از Streaming، دانلود فایلهای حجیم یا استفاده از ابزارهای غیرکاری است. با شناسایی اپلیکیشنها میتوان این مصرف را بهصورت هدفمند کنترل کرد، بدون اینکه سرویسهای حیاتی کسبوکار تحت تأثیر قرار گیرند.
چهارمین دلیل اهمیت این طراحی، افزایش دید امنیتی است. وقتی Application Visibility فعال باشد، در Cisco Firepower Management Center میتوانید دقیقاً ببینید کاربران از چه اپلیکیشنهایی استفاده میکنند، چه اپلیکیشنهای ناشناختهای در شبکه فعال هستند و کدام سرویسها بیشترین ریسک را دارند. این دادهها فقط برای Block کردن نیستند، بلکه برای تصمیمگیری استراتژیک درباره امنیت و حتی سیاستهای IT ارزشمندند.
پنجمین نکته، مقابله با تکنیکهای دور زدن امنیت است. برخی اپلیکیشنهای مخرب یا ابزارهای تونلسازی سعی میکنند خود را به شکل ترافیک عادی HTTPS نشان دهند. کنترل مبتنی بر Application میتواند این رفتار را شناسایی کند و آن را در دسته اپلیکیشنهای پرریسک یا ناشناس قرار دهد، حتی اگر از پورت مجاز استفاده کند.
قبل از نوشتن Ruleهای سختگیرانه، باید بدانید کاربران واقعاً از چه اپلیکیشنهایی استفاده میکنند. در FMC وارد بخش Analysis و سپس Applications شوید. این گزارشها نشان میدهند کدام اپلیکیشنها بیشترین مصرف را دارند و چه اپلیکیشنهای ناشناختهای در شبکه فعال هستند.
در پروژههای واقعی، این مرحله بسیار حیاتی است. اگر بدون تحلیل اولیه شروع به Block کردن اپلیکیشنها کنید، ممکن است سرویسهای حیاتی کسبوکار را ناخواسته قطع کنید.
در طراحی Policy مبتنی بر Application، ترتیب Ruleها اهمیت حیاتی دارد. ابتدا باید Ruleهای خاص و محدودکننده تعریف شوند و سپس Ruleهای عمومیتر.
برای مثال:
Rule اول: Allow اپلیکیشنهای حیاتی سازمان مانند Microsoft 365
Rule دوم: Allow اپلیکیشنهای مجاز عمومی
Rule سوم: Block اپلیکیشنهای پرریسک یا ناشناس
Rule آخر: Default Deny یا Monitor
در هر Rule میتوانید شرط Application را فعال کرده و اپلیکیشنهای مشخص را انتخاب کنید.
کنترل مبتنی بر اپلیکیشن زمانی مؤثرتر میشود که با Intrusion Policy ترکیب شود. برای مثال میتوانید اجازه دهید اپلیکیشن Dropbox اجرا شود، اما همزمان Intrusion Policy فعال باشد تا در صورت تلاش برای Exploit یا رفتار مشکوک، ترافیک مسدود شود.
این ترکیب یک دفاع چندلایه ایجاد میکند. اپلیکیشن مجاز است، اما رفتار مخرب آن قابل شناسایی و کنترل خواهد بود.
در بسیاری از شبکهها، بخشی از ترافیک به عنوان Unknown Application شناخته میشود. این موضوع میتواند ناشی از اپلیکیشن جدید، نسخه بهروزرسانیشده یا حتی تونلسازی ترافیک باشد.
بهتر است Unknown Applicationها ابتدا در حالت Monitor قرار گیرند و پس از تحلیل، تصمیم درباره Allow یا Block آنها گرفته شود. Block کامل Unknown بدون تحلیل میتواند باعث اختلال در برخی سرویسها شود.
فرض کنید یک سازمان متوسط با حدود ۲۵۰ کاربر دارید که اینترنت مرکزی از طریق یک دستگاه Cisco Firepower Threat Defense تأمین میشود و مدیریت آن در Cisco Firepower Management Center انجام میگیرد. کاربران شامل واحدهای مالی، منابع انسانی، IT و بازاریابی هستند و همه از یک Subnet مشترک به اینترنت دسترسی دارند.
گزارشهای اولیه Application در FMC نشان میدهد بیشترین مصرف پهنای باند مربوط به Streaming Media، سرویسهای اشتراک فایل عمومی و چند اپلیکیشن Remote Access غیرمجاز است. در عین حال، سرویسهای Collaboration مانند Microsoft Teams و ابزارهای Cloud سازمانی برای عملیات روزانه حیاتی هستند.
در این سناریو، هدف این نیست که همه اپلیکیشنهای غیرضروری یکباره Block شوند. رویکرد مهندسی این است که ابتدا وضعیت فعلی بهدقت تحلیل شود. برای این کار، یک Rule کلی Allow با Logging فعال برای ترافیک inside به outside تعریف میشود تا گزارش Application بهمدت دو تا سه هفته جمعآوری شود. در این بازه، تیم امنیت بررسی میکند کدام اپلیکیشنها واقعاً موردنیاز کسبوکار هستند و کدامها صرفاً مصرف غیرضروری ایجاد میکنند.
پس از تحلیل دادهها، ساختار Policy به شکل لایهبندی طراحی میشود. در بالاترین سطح، Rule اول برای Allow اپلیکیشنهای حیاتی سازمان مانند Microsoft 365، Teams و سرویسهای مالی تعریف میشود. Rule دوم مربوط به اپلیکیشنهای عمومی اما کمریسک است که Allow میشوند اما Logging آنها فعال باقی میماند. Rule سوم اپلیکیشنهای پرریسک مانند برخی ابزارهای Anonymous Proxy یا File Sharing عمومی را Block میکند. در نهایت یک Rule Default برای Monitor کردن Unknown Applicationها تعریف میشود.
برای واحد بازاریابی که نیاز به دسترسی به شبکههای اجتماعی دارد، یک Rule جداگانه مبتنی بر User یا Network Object تعریف میشود تا فقط گروه Marketing بتواند اپلیکیشنهای Social Media را استفاده کند. سایر کاربران در صورت تلاش برای دسترسی، با Block مواجه میشوند.
در ادامه، مصرف پهنای باند بررسی میشود. مشخص میشود اپلیکیشنهای Streaming بیشترین فشار را در ساعات کاری ایجاد میکنند. بنابراین یک Rule زمانبندیشده تعریف میشود که اپلیکیشنهای Streaming Media از ساعت ۸ تا ۱۶ Block و خارج از آن باز باشند. این کار بدون قطع کامل دسترسی، سیاست سازمانی را اعمال میکند.
پس از Deploy، تیم IT بهصورت روزانه Eventها را در FMC بررسی میکند. در هفتههای اول ممکن است برخی False Positiveها یا اپلیکیشنهای مشروع در دسته Unknown دیده شوند. در این مرحله Tuning انجام میشود؛ یعنی اپلیکیشنهای موردنیاز به لیست Allow اضافه و موارد پرریسک به Block منتقل میشوند.
پس از یک ماه، ساختار Policy پایدار میشود. مصرف پهنای باند کنترل شده، اپلیکیشنهای پرریسک مسدود شدهاند و کاربران همچنان به سرویسهای حیاتی دسترسی دارند. مهمتر از همه، تیم امنیت دید دقیقی از رفتار اپلیکیشنها در شبکه دارد.
Ruleهای مبتنی بر Application باید تا حد امکان ساده و لایهبندیشده باشند. از تعریف Ruleهای متعدد با همپوشانی زیاد خودداری کنید.
همیشه Logging را برای Ruleهای مهم فعال کنید تا بتوانید رفتار واقعی شبکه را تحلیل کنید.
بهروزرسانی منظم Signatureهای اپلیکیشن اهمیت دارد، زیرا اپلیکیشنها بهطور مداوم تغییر میکنند.
در محیطهای پرترافیک، فعالسازی بیش از حد تحلیل عمیق میتواند مصرف CPU را افزایش دهد. بنابراین باید تعادل بین امنیت و کارایی رعایت شود.
طراحی Policyهای امنیتی مبتنی بر Application در Cisco Firepower یک گام مهم در حرکت از امنیت سنتی مبتنی بر پورت به امنیت مبتنی بر Context است. این رویکرد امکان کنترل دقیقتر، کاهش ریسک و اجرای سیاستهای سازمانی هوشمندانه را فراهم میکند.
اگر این Policyها بدون تحلیل اولیه طراحی شوند، ممکن است باعث اختلال شوند. اما اگر با رویکرد مرحلهای شامل تحلیل، طراحی، Deploy و Tuning اجرا شوند، به یک ابزار قدرتمند در مدیریت امنیت شبکه تبدیل خواهند شد.
طراحی Policy مبتنی بر Application نیازمند درک دقیق رفتار ترافیک سازمان، شناخت اپلیکیشنها و تجربه عملی در Tuning و بهینهسازی است. بسیاری از چالشها پس از Deploy و در مرحله تحلیل رفتار واقعی شبکه ظاهر میشوند.
وینو سرور به عنوان مرجع تخصصی در حوزه Cisco Firepower و طراحی Policyهای پیشرفته امنیتی، با رویکردی مبتنی بر تجربه پروژههای عملی، به شما کمک میکند Policyهای مبتنی بر Application را بهصورت دقیق، پایدار و متناسب با نیاز کسبوکار پیادهسازی کنید. اگر هدف شما حرکت به سمت امنیت هوشمند و Context-Aware است، وینو سرور میتواند نقطه اتکای تخصصی شما در این مسیر باشد.
وینو سرور، اولین استارتاپ ارائه تجهیزات و سیستم های سخت افزاری، به صورت مستقیم از تولید کننده به مصرف کننده است. همواره تلاش مجموعه بر این اصل استوار بوده است تا مشتریان بتوانند بهترین سیستم را برای پروژه خود انتخاب کرده و با مناسبترین قیمت، آن را تهیه کنند. تیم وینو سرور، همواره سعی میکند تا جامعترین خدمات را به مشتریان ارائه دهد تا خرید را برای شما به کاری لذتبخش و آسان تبدیل کند.
مطلع شدن از پست های جدید
میخواهم اولین نفری باشم که از مقالههایی که در وینو سرور منتشر میشود، آگاه شوم.
