قبل از مشاوره امنیت شبکه چه Scopeی باید مشخص شود؟

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

در پروژه‌های سازمانی، scope باید قبل از شروع کار با زبان ساده نوشته شود: کدام سایت‌ها، کدام شعبه‌ها، کدام دیتاسنتر، کدام فایروال‌ها، کدام سرویس‌های اینترنتی، کدام VLANها، کدام سرورها و کدام تیم‌ها داخل بررسی هستند. اگر این مرز روشن نباشد، هم هزینه اشتباه تخمین زده می‌شود و هم انتظارات دو طرف با هم نمی‌خواند.

اول دارایی‌ها و مرز شبکه را مشخص کنید

اولین خروجی مفید، فهرست دارایی‌های مهم است. منظور فقط تعداد روتر و سوئیچ نیست. باید بدانیم کدام سرویس‌ها برای کسب‌وکار حیاتی‌اند، کدام مسیرها به اینترنت وصل‌اند، کدام سامانه‌ها داده حساس دارند، و کدام دسترسی‌ها اگر اشتباه تنظیم شوند باعث incident جدی می‌شوند. این نگاه با چارچوب‌هایی مثل NIST CSF و CIS Controls هم‌راستا است: قبل از محافظت، باید دارایی و ریسک را بشناسیم.

• لینک‌های اینترنت، VPN، ارتباط شعب و مسیرهای دیتاسنتر مشخص شود.
• فهرست فایروال‌ها، روترها، سوئیچ‌های core، load balancer و WAF جمع‌آوری شود.
• سرویس‌های حساس مثل ERP، ایمیل، پنل مشتریان، AD و سامانه‌های مالی جدا علامت‌گذاری شوند.
• مالک فنی و مالک کسب‌وکاری هر بخش مشخص باشد تا تصمیم‌ها معطل نماند.

دسترسی مدیریتی را از همان ابتدا وارد scope کنید

خیلی از ضعف‌های امنیت شبکه از تنظیمات پیچیده شروع نمی‌شود؛ از دسترسی مدیریتی شلخته شروع می‌شود. اگر مشخص نباشد چه کسی به کنسول فایروال، سوئیچ، کنترلر وایرلس یا پنل مجازی‌سازی دسترسی دارد، هر پیشنهاد امنیتی روی زمین سست اجرا می‌شود. در scope مشاوره باید دسترسی admin، روش احراز هویت، لاگ ورود، backup config و مسیر اضطراری تغییرات هم بررسی شود.

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

خروجی مشاوره باید قابل اجرا باشد

گزارش خوب نباید فقط فهرست ضعف‌ها باشد. باید مشخص کند کدام ریسک فوری است، کدام تغییر نیاز به downtime دارد، کدام مورد با تنظیم ساده حل می‌شود، و کدام تصمیم باید در سطح مدیریت گرفته شود. خروجی بهتر است به چند سطح تقسیم شود: quick win، اصلاحات ضروری، اصلاحات معماری، و مواردی که نیاز به خرید یا تغییر زیرساخت دارند.

• هر یافته باید اثر، اولویت، مالک و پیشنهاد اصلاح داشته باشد.
• تغییرهای پرریسک باید plan و rollback داشته باشند.
• توصیه‌ها باید با وضعیت واقعی تجهیزات و تیم نگهداری سازگار باشند.
• لینک بین یافته‌ها و صفحات خدمات/اجرا باید طبیعی و قابل پیگیری باشد.

این مطلب به کدام مسیر عربیان وصل است؟

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

چه چیزهایی را از scope بیرون بگذاریم؟

scope خوب فقط چیزهایی را که داخل پروژه هستند مشخص نمی‌کند؛ مرزهای بیرون پروژه را هم روشن می‌کند. اگر قرار نیست تست نفوذ انجام شود، باید نوشته شود. اگر بررسی کد اپلیکیشن، ارزیابی تجهیزات صنعتی، یا تغییر معماری دیتاسنتر خارج از این فاز است، بهتر است از ابتدا مشخص باشد. این شفافیت جلوی توقع اشتباه را می‌گیرد و اجازه می‌دهد فاز اول روی ریسک‌های فوری‌تر متمرکز بماند.

در پروژه‌های بهتر، scope به فازهای کوچک‌تر تقسیم می‌شود: فاز شناخت و مستندسازی، فاز quick win، فاز اصلاحات حساس، و فاز طراحی بلندمدت. این روش برای سازمانی که شبکه فعال دارد کم‌ریسک‌تر از تغییرهای سنگین و هم‌زمان است.