SSL Decryption در Cisco Firepower؛ کجا فعال کنیم و کجا نه؟
بخش بزرگی از ترافیک امروز رمزنگاریشده است. اگر فایروال فقط آدرس، پورت و بخشی از metadata را ببیند، بخش مهمی از تهدیدها داخل HTTPS از دیدش پنهان میماند. SSL Decryption در Cisco Firepower برای همین طراحی شده: ترافیک رمزنگاریشده در مسیرهای مشخص باز شود تا سیستم بتواند intrusion، malware و رفتارهای ناخواسته را دقیقتر بررسی کند.
اما SSL Decryption از آن قابلیتهایی نیست که با یک rule عمومی روی کل شبکه روشن شود. هم از نظر فنی حساس است، هم از نظر تجربه کاربر، حریم خصوصی، ظرفیت دستگاه و خطای عملیاتی. طراحی درست یعنی بدانیم چه چیزی باید decrypt شود، چه چیزی نباید decrypt شود، certificate trust چطور مدیریت میشود و اگر سایتی یا اپلیکیشنی مشکل داشت، مسیر rollback چیست.
همه ترافیک نباید decrypt شود
اشتباه خطرناک این است که SSL Decryption را به چشم یک کلید روشن/خاموش ببینیم. ترافیک بانکی، سلامت، سرویسهای حساس شخصی، برخی اپلیکیشنهای موبایل، certificate pinning و مسیرهای قانونی/حریم خصوصی باید با دقت جدا شوند. در خیلی از شبکهها، decrypt کردن کورکورانه هم از نظر عملیاتی دردسر درست میکند، هم از نظر سیاست داخلی سازمان قابل دفاع نیست.
بهتر است scope را از مسیرهای پرریسک شروع کنیم: کاربران سازمان به اینترنت، سرویسهایی که قبلاً رخداد داشتهاند، دستهبندیهای پرخطر، یا segmentهایی که ریسک بیشتری دارند. در مقابل، سرویسهای حساس و مواردی که عملاً با decryption سازگار نیستند باید از ابتدا در exception list باشند.
Certificate trust نقطه شکست اصلی است
برای Decrypt – Resign، کلاینتها باید به CA داخلی که Firepower برای امضای مجدد certificate استفاده میکند اعتماد داشته باشند. اگر این بخش درست انجام نشود، کاربران با خطای certificate روبهرو میشوند و پروژه خیلی سریع شکست میخورد. این موضوع فقط نصب یک certificate نیست؛ باید روش توزیع، سیستمعاملها، مرورگرها، دستگاههای خارج از دامین و endpointهای خاص هم دیده شوند.
قبل از اجرای گسترده، روی یک گروه کوچک تست کنید. بررسی کنید مرورگرها، ابزارهای توسعه، اپلیکیشنهای سازمانی، سرویسهای cloud و agentهای امنیتی چه رفتاری نشان میدهند. هر exception باید دلیل داشته باشد و بعداً قابل بازبینی باشد، نه اینکه هر خطایی سریع به bypass دائمی تبدیل شود.
Performance را واقعی بسنجید
SSL Decryption مصرف پردازشی دارد. عددهای دیتاشیت هم همیشه با ترافیک واقعی سازمان یکی نیستند. نوع cipher، حجم sessionهای جدید، درصد ترافیک decrypt شده، فعال بودن IPS و malware inspection و مدل دستگاه همه روی ظرفیت اثر میگذارند. اگر قبل از اجرا baseline نداشته باشید، بعد از اجرای decryption نمیدانید افت performance از کجاست.
قبل از rollout، throughput واقعی، latency، CPU، memory، تعداد connectionها و رفتار peak hour را ثبت کنید. بعد decryption را مرحلهای فعال کنید و همان شاخصها را دوباره ببینید. اگر قرار است هم IPS و هم malware inspection روی ترافیک decrypt شده اعمال شود، سنجش باید با همین ترکیب انجام شود.
Ruleها باید خوانا و قابل دفاع باشند
SSL Policy شلوغ خیلی زود به نقطه مبهم تبدیل میشود. ruleها باید بر اساس intent مرتب شوند: چه ترافیکی decrypt میشود، چه ترافیکی bypass میشود، چه مواردی به خاطر privacy استثنا شدهاند، و چه مواردی به خاطر ناسازگاری فنی. نام ruleها، توضیح کوتاه و log مناسب کمک میکند بعداً کسی مجبور نشود از روی حدس policy را تغییر دهد.
در سازمانهای متوسط و بزرگ بهتر است تغییرات SSL Policy با change record انجام شود. چون یک exception کوچک میتواند دید امنیتی را روی یک دسته ترافیک مهم حذف کند. برعکس، یک decrypt اشتباه هم میتواند اپلیکیشن حیاتی را از کار بیندازد.
مسیر اجرای کمریسک
- اول هدف decryption را مشخص کنید: تهدید، malware، کنترل policy یا visibility.
- لیست ترافیکهای ممنوع یا حساس برای decryption را از ابتدا جدا کنید.
- CA و trust chain را روی گروه کوچک تست کنید.
- روی یک segment محدود pilot بگیرید و performance را بسنجید.
- exceptionها را مستند کنید و دورهای بازبینی کنید.
- بعد از هر deploy، خطاهای certificate و رخدادهای FMC را بررسی کنید.
SSL Decryption اگر درست طراحی شود، کیفیت IPS و malware inspection را بالا میبرد. اگر عجولانه اجرا شود، تبدیل به پروژهای میشود که همه میخواهند خاموشش کنند. برای همین بهتر است کنار تنظیم IPS در Cisco Firepower و طراحی امنیت شبکه و هاردنینگ زیرساخت دیده شود.
بکدور FIRESTARTER روی Cisco ASA/FTD؛ بعد از Patch هم تمام نمیشود
طراحی NAT در Cisco Firepower؛ وقتی Ruleها بعد از چند ماه غیرقابل فهم میشوند