مسئلهٔ شبکهٔ مسطح
در شبکهٔ مسطح، همهٔ دستگاه‌ها در یک حوزهٔ پخش قرار دارند و می‌توانند یکدیگر را مستقیماً ببینند. این آرایش ساده است و تا وقتی چیزی خراب نشود، هیچ مشکلی نشان نمی‌دهد.
اثر آن در لحظهٔ رویداد آشکار می‌شود. یک ایستگاه کاری که فایل آلوده‌ای را اجرا کرده، در شبکهٔ مسطح می‌تواند مستقیماً سراغ سرور فایل، سرور پایگاه داده، سامانهٔ پشتیبان‌گیری و رابط مدیریتی سوئیچ‌ها برود. دسترسی شبکه‌ای آن تفاوتی با دسترسی شبکه‌ای میزِ کارشناس شبکه ندارد.
بخش‌بندی این وضعیت را عوض نمی‌کند که آلودگی رخ می‌دهد؛ عوض می‌کند که آلودگی تا کجا پیش می‌رود.
از کجا شروع کنیم
خطای رایج، شروع از بخش‌بندی دقیق بر پایهٔ دپارتمان است: شبکهٔ مالی، شبکهٔ فروش، شبکهٔ تولید. این کار زحمت زیادی دارد و بهرهٔ امنیتی کمی، چون تهدید جدی از حرکت میان دپارتمان‌ها نمی‌آید.
ترتیبی که بیشترین بهره را در اولین گام می‌دهد، تفکیک بر پایهٔ نقش دستگاه است:
- شبکهٔ مدیریت: رابط مدیریتی سوئیچ‌ها، فایروال، میزبان‌های مجازی‌سازی و ذخیره‌ساز. هیچ ایستگاه کاری معمولی نباید به این بخش دسترسی داشته باشد.
- شبکهٔ سرور: سرویس‌های داخلی. دسترسی ایستگاه کاری به آن باید محدود به درگاه‌های سرویس باشد، نه دسترسی کامل.
- شبکهٔ ایستگاه‌های کاری: جایی که کاربر و مرورگر و ایمیل زندگی می‌کنند — یعنی جایی که احتمال آلودگی بیشترین است.
- شبکهٔ تلفن: ترافیک صدا، که هم به اولویت‌بندی نیاز دارد و هم دستگاه‌هایش به‌روزرسانی متفاوتی دارند.
- شبکهٔ مهمان و دستگاه‌های شخصی: بدون هیچ مسیری به بخش‌های بالا.
تنها همین پنج بخش، مسیر حرکت مهاجم از ایستگاه کاری به رابط مدیریتی زیرساخت را قطع می‌کند — که مؤثرترین قدم اول است.
سیاست عبور، نقطهٔ اصلی کار است
ساختن بخش‌ها کار فنی سرراستی است. چیزی که طرح را موفق یا ناموفق می‌کند، سیاست عبور میان بخش‌هاست. سیاستی که همهٔ ترافیک میان بخش‌ها را اجازه دهد، بخش‌بندی را به یک تمرین صرفاً آدرس‌دهی تبدیل می‌کند.
از منع پیش‌فرض شروع کنید، اما مرحله‌ای
هدف نهایی منع پیش‌فرض و اجازهٔ موردی است. اما اعمال یک‌بارهٔ آن روی شبکهٔ عملیاتی، کار سازمان را متوقف می‌کند. روش عملی این است: نخست سیاست را در حالت ثبت بدون منع اجرا کنید، چند هفته ترافیک واقعی را ببینید، فهرست اجازه‌های لازم را از دل همان داده بسازید، و بعد منع را فعال کنید.
سیاست را با نام سرویس بنویسید، نه با نشانی
قاعده‌ای که می‌گوید «از گروه ایستگاه‌های کاری به گروه سرورهای برنامه، روی درگاه سرویس پایگاه داده» سال‌ها خوانا می‌ماند. قاعده‌ای که با نشانی‌های خام نوشته شده، شش ماه بعد قابل بازخوانی نیست و در زمان تغییر، حذف نمی‌شود چون کسی نمی‌داند برای چه بوده.
برای استثناها انقضا بگذارید
هر طرحی استثنا پیدا می‌کند: پیمانکاری که دسترسی موقت می‌خواهد، سامانهٔ قدیمی که با قاعدهٔ عمومی کار نمی‌کند. استثنای بدون تاریخ انقضا، به قاعدهٔ دائمی تبدیل می‌شود. ثبت تاریخ و دلیل هر استثنا، تنها چیزی است که مانع انباشت آن‌ها می‌شود.
آنچه بخش‌بندی حل نمی‌کند
بخش‌بندی، حرکت میان بخش‌ها را کنترل می‌کند؛ حرکت داخل یک بخش را نه. اگر همهٔ ایستگاه‌های کاری در یک بخش باشند، آلودگی همچنان می‌تواند میان آن‌ها پخش شود.
همچنین بخش‌بندی به تنهایی حساب‌های دارای سطح دسترسی بالا را محافظت نمی‌کند. اگر حسابی که روی ایستگاه کاری وارد شده، سطح دسترسی مدیر دامنه داشته باشد، مرز شبکه برای مهاجم مانع تعیین‌کننده‌ای نیست — او از هویت استفاده می‌کند، نه از مسیر شبکه.
به همین دلیل بخش‌بندی را همیشه در کنار تفکیک حساب‌های مدیریتی و پایش متمرکز سیاهه‌ها طراحی می‌کنیم. هر سه با هم کار می‌کنند: بخش‌بندی دامنهٔ حرکت را کوچک می‌کند، تفکیک حساب‌ها ارزش هر دسترسی را کم می‌کند، و پایش امکان دیدن تلاش را فراهم می‌کند.
جمع‌بندی
اگر فقط یک قدم می‌توانید بردارید، رابط‌های مدیریتی زیرساخت را از شبکهٔ ایستگاه‌های کاری جدا کنید. این یک تغییر، پرتکرارترین مسیر حرکت مهاجم در شبکهٔ سازمانی را می‌بندد و به تغییر در ایستگاه‌های کاری نیازی ندارد.
نوشته‌های دیگر
- پایش چه چیزی را باید اندازه بگیرد؟داشبوردی پر از نمودار سبز، در لحظهای که کاربر می‌گوید سامانه کار نمی‌کند، نشانهٔ پایش خوب نیست؛ نشانهٔ این است که چیز درستی اندازهگیری نمی‌شود.
- پنج تصمیم اولیه در اکتیو دایرکتوری که بعداً گران تمام میشونداکتیو دایرکتوری را می‌شود در یک بعدازظهر راه انداخت. پنج تصمیمی که در همان بعدازظهر گرفته می‌شود، سال‌ها با سازمان می‌ماند.