جلسه مشاوره امنیت شبکه اگر بدون اطلاعات شروع شود، معمولا به حرفهای کلی میرسد. مشاور چند توصیه عمومی میدهد، تیم فنی هم چند مشکل پراکنده میگوید، اما آخر جلسه تصمیم دقیق شکل نمیگیرد. برای اینکه جلسه واقعا خروجی داشته باشد، باید قبل از آن چند دسته اطلاعات آماده شود. لازم نیست همه چیز کامل و بینقص باشد، ولی باید تصویر کافی از شبکه، سرویسهای مهم، دسترسیها و درد اصلی سازمان وجود داشته باشد.
هدف جلسه مشاوره این نیست که همان لحظه همه چیز حل شود. هدف این است که مشکل درست تعریف شود، مسیر بررسی مشخص شود، ریسکهای فوری جدا شوند و معلوم شود کدام کارها باید در فاز اول انجام شوند. اگر اطلاعات پایه آماده نباشد، بخش زیادی از زمان صرف کشف چیزهایی میشود که تیم داخلی از قبل میتوانست آماده کند.
نقشه شبکه، حتی اگر ساده باشد
اولین چیزی که به جلسه کمک میکند، نقشه شبکه است. لازم نیست دیاگرام رسمی و بسیار تمیز باشد. یک نقشه ساده که نشان دهد اینترنت از کجا وارد میشود، فایروال کجاست، سوئیچهای اصلی کداماند، سرورها در چه بخشی هستند، شعب چطور وصل میشوند و کاربران از چه مسیرهایی به سرویسها میرسند، برای شروع بسیار ارزشمند است. اگر شبکه چند دیتاسنتر، چند لینک یا چند فایروال دارد، مسیرهای اصلی باید جداگانه مشخص شوند.
در نقشه بهتر است فقط تجهیزات دیده نشوند؛ مسیر سرویس هم مهم است. مثلا اگر کاربران شعبه به ERP وصل میشوند، مسیرشان از کدام VPN، کدام فایروال، کدام VLAN و کدام سرور عبور میکند. همین مسیرها در زمان طراحی کنترل امنیتی مهمتر از مدل دقیق هر دستگاه هستند.
لیست سرویسهای حیاتی
همه سرویسها حساسیت یکسان ندارند. قبل از جلسه باید مشخص باشد سرویسهای حیاتی سازمان کداماند: مالی، اتوماسیون، ایمیل، فایل سرور، دیتابیس، CRM، پنل مشتریان، وبسایت، VPN، سرویسهای ابری یا هر سامانهای که قطعی آن روی کار اثر مستقیم دارد. برای هر سرویس بهتر است owner، آدرس، پورتهای مهم، کاربران اصلی و حساسیت قطعی نوشته شود.
این لیست کمک میکند مشاوره امنیت شبکه از همان اول روی داراییهای مهم متمرکز شود. اگر سرویس مالی از چند مسیر باز باشد، اگر پنل مدیریتی روی اینترنت باشد، اگر دیتابیس از subnetهای زیاد reachable باشد یا اگر backup از شبکه اصلی جدا نباشد، اینها موضوعاتی هستند که باید زود دیده شوند.
دسترسیهای مدیریتی و کاربران ممتاز
یکی از بخشهای مهم جلسه، دسترسی ادمینهاست. باید بدانیم چه کسانی به فایروال، سوئیچ، روتر، سرور، مجازیساز، پنلها و سرویسهای ابری دسترسی دارند. آیا احراز هویت مرکزی وجود دارد؟ آیا MFA فعال است؟ آیا اکانت مشترک استفاده میشود؟ آیا لاگ ورود و اجرای دستورها ثبت میشود؟ آیا دسترسی افرادی که از تیم جدا شدهاند حذف شده است؟
در خیلی از شبکهها، ریسک اصلی نه از یک آسیبپذیری عجیب، بلکه از یک دسترسی قدیمی یا بیصاحب میآید. اگر این اطلاعات آماده باشد، جلسه خیلی سریعتر به تصمیمهای عملی میرسد: محدودسازی مسیر مدیریت، تفکیک نقشها، راهاندازی TACACS یا RADIUS، فعالسازی لاگ، تعریف حساب اضطراری و حذف دسترسیهای اضافه.
وضعیت فایروال و policyها
اگر قرار است درباره امنیت شبکه تصمیم بگیریم، وضعیت فایروال باید روشن باشد. لازم است بدانیم چند فایروال داریم، چه برندهایی استفاده میشود، HA فعال است یا نه، آخرین backup کی گرفته شده، ruleها آخرین بار کی بازبینی شدهاند، ruleهای any-any وجود دارد یا نه، NATها مستند هستند یا نه و لاگ برای deny و allowهای حساس ذخیره میشود یا خیر.
لازم نیست کل configuration از قبل برای همه ارسال شود، اما داشتن خروجیهای خلاصه خیلی کمک میکند. مثلا لیست ruleهای پرخطر، ruleهای بدون توضیح، address objectهای قدیمی، service objectهای عمومی، ruleهای بدون لاگ و NATهایی که معلوم نیست هنوز استفاده میشوند یا نه. برای کارهای فایروالی، صفحه پیادهسازی فایروال سازمانی هم مسیر بحث را روشنتر میکند.
لاگ، مانیتورینگ و رخدادهای قبلی
اگر در گذشته رخداد امنیتی، قطعی، حمله، اسکن شدید، لاگ مشکوک، brute force، آلودگی سیستم یا دسترسی غیرعادی داشتهاید، باید قبل از جلسه جمعآوری شود. حتی اگر رخداد کامل تحلیل نشده باشد، زمان، سرویس درگیر، نشانهها و اقدامهایی که انجام شده مهم است. این اطلاعات نشان میدهد مشکل فقط فرضی نیست و کدام بخشها بیشتر در معرض ریسک هستند.
وضعیت لاگ هم مهم است. باید بدانیم لاگها کجا ذخیره میشوند، چقدر نگهداری میشوند، چه کسی آنها را میبیند، alert داریم یا نه، زمان تجهیزات sync است یا نه و در صورت رخداد، امکان دنبال کردن مسیر حمله وجود دارد یا خیر. نبود لاگ کافی باعث میشود بعد از هر مشکل، فقط حدس بزنیم.
محدودیتهای اجرایی و حساسیت قطعی
مشاوره خوب باید با واقعیت عملیات سازمان هماهنگ باشد. اگر سرویسها ۲۴ ساعته هستند، اگر فقط آخر هفته امکان تغییر وجود دارد، اگر تیم داخلی کوچک است، اگر بعضی تجهیزات قدیمی هستند یا اگر دسترسی به vendor محدود است، باید از اول گفته شود. راهکاری که روی کاغذ عالی است ولی در محیط شما قابل اجرا نیست، به درد پروژه نمیخورد.
- ساعتهای مجاز برای تغییرات حساس
- سرویسهایی که قطعی کوتاه هم برایشان قابل قبول نیست
- تجهیزاتی که backup سالم از آنها وجود ندارد
- تیمهایی که باید قبل از تغییر هماهنگ شوند
- محدودیتهای قرارداد، لایسنس یا دسترسی به vendor
- مسیر برگشت برای تغییرات مهم
سوالهایی که بهتر است قبل از جلسه جوابشان روشن باشد
قبل از جلسه چند سوال را صریح جواب بدهید. الان بزرگترین نگرانی شما چیست؟ قطعی سرویس، نفوذ، دسترسی زیاد کاربران، وضعیت فایروال، امنیت شعب، نبود لاگ، ضعف VPN یا قدیمی بودن تجهیزات؟ خروجی مورد انتظار چیست؟ گزارش ریسک میخواهید، طراحی جدید میخواهید، اصلاح فایروال میخواهید، برنامه هاردنینگ میخواهید یا همراهی در اجرا؟ وقتی هدف روشن باشد، جلسه به جای بحث پراکنده، روی مسیر تصمیمگیری جلو میرود.
اگر هنوز نمیدانید مشکل اصلی کجاست، اشکالی ندارد. همان هم یک ورودی مهم است. در این حالت جلسه باید با ارزیابی اولیه شروع شود و بعد بر اساس شواهد تصمیم گرفته شود. اما اگر از اول همه چیز را در حد «شبکه را امنتر کنیم» نگه داریم، نتیجه هم عمومی و غیرقابل اجرا میشود.
بعد از جلسه باید چه چیزی بگیرید؟
خروجی جلسه مشاوره امنیت شبکه باید مشخص باشد: مسئلههای اصلی، ریسکهای فوری، اطلاعات ناقص، مسیر بررسی بعدی، اولویتهای اجرایی و تخمین منطقی از زمان و حساسیت تغییرات. اگر جلسه فقط به چند توصیه کلی ختم شود، ارزش عملی کمی دارد. بهتر است حتی یک فهرست کوتاه ولی دقیق داشته باشید که تیم فنی بداند از فردا باید چه کاری انجام دهد.
برای شروع منظمتر، صفحه مشاوره امنیت شبکه را ببینید. اگر از مرحله مشاوره عبور کردهاید و میخواهید ساختار امنیتی را طراحی یا اصلاح کنید، مطلب طراحی و هاردنینگ امنیت شبکه ادامه طبیعی همین مسیر است.
جمعبندی
جلسه مشاوره امنیت شبکه وقتی مفید است که اطلاعات پایه آماده باشد: نقشه شبکه، سرویسهای حیاتی، دسترسیهای مدیریتی، وضعیت فایروال، لاگها، رخدادهای قبلی و محدودیتهای اجرایی. با همین آمادگی ساده، جلسه از حرفهای کلی فاصله میگیرد و به تصمیمهای قابل اجرا میرسد. امنیت شبکه با شناخت دقیق شروع میشود، نه با حدس و توصیه عمومی.
