۱. نام دامنه
رایج‌ترین اشتباهی که اصلاح آن از همه سخت‌تر است، انتخاب نام دامنهٔ داخلی است. استفاده از یک نام غیرقابل ثبت (مثل .local) یا استفاده از همان نام دامنهٔ عمومی سازمان، هر دو مشکل‌ساز می‌شوند — یکی در گواهی‌های امنیتی و سرویس‌های جدید، دیگری در تفکیک نام داخلی و خارجی.
انتخاب پیشنهادی ما یک زیردامنهٔ اختصاصی از دامنهٔ ثبت‌شدهٔ سازمان است، مثل corp.example.com. این انتخاب هم مالکیت نام را تضمین می‌کند، هم مرز داخلی و خارجی را روشن نگه می‌دارد.
۲. ساختار واحدهای سازمانی
واحدهای سازمانی (OU) اغلب بر پایهٔ چارت سازمانی ساخته می‌شوند: یک واحد برای مالی، یکی برای فروش، یکی برای تولید. این ساختار شهودی است، اما هدف اصلی واحد سازمانی را نادیده می‌گیرد.
واحد سازمانی در عمل دو کار می‌کند: محل اعمال سیاست گروه است، و محل تفویض اختیار مدیریتی. ساختاری که با چارت سازمانی ساخته شود، با هر تغییر سازمانی به هم می‌خورد — و چارت سازمانی بیشتر از سیاست‌های فناوری اطلاعات تغییر می‌کند.
ساختار پایدارتر، تفکیک بر پایهٔ نوع شیء و نیاز سیاستی است: کاربران جدا از رایانه‌ها، سرورها جدا از ایستگاه‌های کاری، و زیرمجموعه‌ها فقط آنجا که سیاست متفاوتی لازم است. عضویت در گروه، نه محل در درخت، جایی است که تفاوت دپارتمان‌ها بیان می‌شود.
۳. مدل حساب‌های مدیریتی
در بسیاری از دامنه‌هایی که بررسی می‌کنیم، کارشناسان فناوری اطلاعات با حسابی کار می‌کنند که هم‌زمان حساب روزمرهٔ آن‌ها و حساب مدیریتی دامنه است. همین حساب ایمیل می‌خواند، مرورگر باز می‌کند و فایل دریافتی را اجرا می‌کند.
این وضعیت، سطح دسترسی مدیر دامنه را به سطح امنیت یک نشست معمولی مرورگر تنزل می‌دهد. تفکیک حساب‌ها پیچیده نیست و باید از ابتدا برقرار باشد:
- حساب روزمره، بدون هیچ سطح دسترسی مدیریتی
- حساب مدیریت ایستگاه‌های کاری، برای کار پشتیبانی
- حساب مدیریت سرورها، جدا از دو مورد بالا
- حساب مدیریت دامنه، که تنها برای تغییرات سطح دامنه استفاده می‌شود و در ایستگاه کاری معمولی وارد نمی‌شود
افزودن این تفکیک به یک دامنهٔ ده‌سالهٔ عملیاتی، کاری است که باید با احتیاط و مرحله‌ای انجام شود؛ برقرار کردن آن در روز اول، تقریباً بی‌هزینه است.
۴. طرح سیاست گروه
سیاست گروه (Group Policy) ابزار قدرتمندی است و به همین دلیل، سریع از کنترل خارج می‌شود. الگوی رایج خرابی این است: برای هر درخواست یک سیاست جدید ساخته می‌شود، سیاست‌های قدیمی حذف نمی‌شوند و پس از چند سال هیچ‌کس نمی‌داند یک تنظیم مشخص از کدام سیاست می‌آید.
دو قاعدهٔ ساده بیشتر این بی‌نظمی را جلو می‌گیرد: نام‌گذاری سیاست‌ها بر پایهٔ کارکرد و دامنهٔ اعمال (نه بر پایهٔ تاریخ یا نام درخواست‌کننده)، و نگه‌داشتن یک مستند کوتاه که بگوید هر سیاست چه می‌کند و چرا ساخته شده.
همچنین پرهیز از فیلترکردن پیچیدهٔ امنیتی روی سیاست‌ها کمک می‌کند. اگر تعیین اینکه یک سیاست روی کدام کاربر اعمال می‌شود نیازمند بررسی چند لایه فیلتر باشد، عیب‌یابی آن در آینده به حدس تبدیل خواهد شد.
۵. طرح نام‌گذاری
نام‌گذاری تصمیمی است که کوچک به نظر می‌رسد و در عملیات روزمره بیشترین اثر را دارد. نام ماشین، نام گروه و نام حساب سرویس، هرکدام باید از یک الگوی قابل حدس بیایند.
الگوی خوب سه ویژگی دارد: از نام می‌شود نوع و نقش شیء را فهمید، مرتب‌سازی الفبایی شیءهای مرتبط را کنار هم می‌گذارد، و الگو برای موارد جدید قابل تعمیم است. نام‌هایی که اطلاعات زودگذر در خود دارند — نام مالک فعلی، شمارهٔ پروژه، سال خرید — به سرعت گمراه‌کننده می‌شوند.
برای گروه‌ها، تفکیک گروه‌های نقش از گروه‌های دسترسی ارزش ویژه‌ای دارد: گروه نقش بیانگر «این فرد چه کسی است» و گروه دسترسی بیانگر «به چه چیزی اجازه دارد». عضویت گروه نقش در گروه دسترسی، مدلی می‌سازد که سال‌ها بعد هم قابل بازخوانی است.
اگر دامنه از قبل وجود دارد
بیشتر سازمان‌هایی که با آن‌ها کار می‌کنیم دامنهٔ موجود دارند، نه دامنهٔ خالی. در این حالت بازطراحی کامل معمولاً توجیه ندارد؛ اصلاح مرحله‌ای دارد.
ترتیبی که در عمل کمترین ریسک را دارد: نخست تفکیک حساب‌های مدیریتی، چون بیشترین بهرهٔ امنیتی را با کمترین اثر روی کاربر می‌دهد؛ سپس مستندسازی وضعیت فعلی سیاست‌ها؛ سپس تمیزکاری سیاست‌های بی‌اثر؛ و در پایان، اگر لازم بود، بازسازی ساختار واحدهای سازمانی. تغییر نام دامنه تنها در صورتی توجیه دارد که مانع یک نیاز مشخص و فعلی باشد.
جمع‌بندی
از این پنج تصمیم، دو موردِ تفکیک حساب‌های مدیریتی و طرح نام‌گذاری را می‌توان در هر دامنهٔ موجودی هم با ریسک کم اصلاح کرد و بیشترین بازده را دارند. سه مورد دیگر را اگر در روز اول درست بگیرید، دیگر لازم نیست به آن‌ها فکر کنید.
نوشته‌های دیگر
- پایش چه چیزی را باید اندازه بگیرد؟داشبوردی پر از نمودار سبز، در لحظهای که کاربر میگوید سامانه کار نمیکند، نشانهٔ پایش خوب نیست؛ نشانهٔ این است که چیز درستی اندازهگیری نمی‌شود.
- از شبکهٔ مسطح به بخشهای کنترلشدهدر شبکهٔ مسطح، یک ایستگاه کاری آلوده بهاندازهٔ یک مدیر شبکه دسترسی دارد. بخشبندی، دامنهٔ خرابی را کوچک می‌کند — به شرط آنکه از جای درستی شروع شود.