هاردنینگ تجهیزات شبکه اگر به یک لیست عمومی از تنظیمات تبدیل شود، هم فهم آن سخت میشود و هم اجرای آن پرریسک. یک روش عملیتر این است که کنترلها را به سه بخش تقسیم کنیم: management plane، control plane و data plane. این تفکیک کمک میکند بدانیم هر تغییر دقیقاً کدام سطح از دستگاه را امنتر میکند و چه ریسکی برای سرویس ایجاد میکند.
Management Plane؛ اولویت اول
management plane یعنی مسیرهایی که ادمین از طریق آنها دستگاه را مدیریت میکند: SSH، HTTPS، SNMP، API، console server، AAA، syslog و backup config. بیشتر سازمانها اگر همین بخش را درست کنند، بخش بزرگی از ریسک فوری کم میشود. مدیریت از اینترنت، رمز مشترک، نبود لاگ ورود، SNMP قدیمی و backup نامطمئن از خطاهای پرتکرار هستند.
- دسترسی مدیریتی فقط از شبکه مدیریت یا IPهای مشخص مجاز باشد.
- حساب مشترک حذف شود و احراز هویت مرکزی یا MFA در صورت امکان استفاده شود.
- لاگ ورود، تغییر config و خطاهای مدیریتی به محل امن ارسال شود.
- backup config رمزگذاریشده و قابل بازیابی باشد، نه فقط یک فایل قدیمی.
Control Plane؛ محافظت از مغز تصمیمگیری
control plane جایی است که دستگاه درباره routing، neighborها، ARP، STP، routing protocol و پیامهای کنترلی تصمیم میگیرد. حمله یا خطا در این بخش میتواند CPU دستگاه را درگیر کند یا مسیر شبکه را بههم بزند. کنترلهای این بخش باید با احتیاط اجرا شوند، چون یک فیلتر اشتباه روی control plane میتواند همسایگی routing یا مدیریت شبکه را قطع کند.
برای روترها و سوئیچها، محدود کردن پروتکلهای غیرضروری، کنترل neighborها، محافظت از routing protocol، rate limit پیامهای حساس و مانیتور CPU مهم است. در فایروالها، control plane شامل سرویسهای مدیریتی، routing daemon، HA و بعضی پردازشهای inspection هم میشود.
Data Plane؛ جایی که ترافیک واقعی عبور میکند
data plane همان مسیر عبور ترافیک کاربران و سرویسهاست. ACL، security policy، segmentation، NAT، inspection و QoS در این سطح دیده میشوند. خطای رایج این است که برای hardening سریع، ruleها را زیاد محدود کنیم بدون اینکه وابستگی سرویسها را بشناسیم. data plane باید با لاگ، hit count، مالک سرویس و تست مرحلهای اصلاح شود.
چرا این تفکیک به نگهداری کمک میکند؟
وقتی تغییرها با این سه سطح دستهبندی شوند، گزارش هاردنینگ خواناتر میشود. تیم میفهمد کدام تغییر دسترسی ادمین را امن کرده، کدام تغییر از routing محافظت کرده و کدام تغییر روی عبور ترافیک اثر گذاشته است. این تفکیک برای rollback هم مفید است؛ چون دقیقتر میدانیم مشکل بعد از تغییر از کدام سطح شروع شده است.
اتصال به مسیر خدمات
برای برنامهریزی مرحلهای، مطلب هاردنینگ شبکه را از کجا شروع کنیم؟ مسیر اولویتبندی را توضیح میدهد. اگر هدف طراحی کاملتر در سطح سازمان است، صفحه طراحی امنیت شبکه و هاردنینگ زیرساخت سازمانی مسیر خدماتی همین خوشه است.
ترتیب پیشنهادی اجرا
در بیشتر شبکهها، بهتر است از management plane شروع شود، چون هم ریسک زیادی کم میکند و هم معمولاً اثر مستقیم روی ترافیک کاربران ندارد. بعد از آن میتوان control plane را با احتیاط بررسی کرد و در نهایت سراغ data plane رفت؛ جایی که تغییرها بیشتر به سرویسها وابستهاند و تست دقیقتری میخواهند.
برای هر سطح، یک baseline قبل از تغییر لازم است. مثلاً قبل از محدود کردن دسترسی مدیریتی باید بدانیم چه IPهایی واقعاً برای مدیریت استفاده میشوند. قبل از کنترل routing باید neighborهای سالم و مسیرهای فعلی مشخص باشند. قبل از محدود کردن data plane باید سرویسهای وابسته و owner آنها شناخته شوند.
خطای رایج
خطای رایج این است که همه hardeningها را در یک window اجرا کنیم. وقتی چندین سطح همزمان تغییر کند، اگر مشکل ایجاد شود معلوم نیست خطا از management بوده، control یا data. تغییر مرحلهای عیبیابی را سادهتر و ریسک قطعی را کمتر میکند.
