ایمنسازی لینوکس در مقیاس سازمانی مجموعهای از تنظیمات پراکنده نیست؛ تصمیمی است که باید قابل دفاع، قابل ممیزی و قابل تکرار باشد. بدون مرجع مشترک، امنیت به تجربه و سلیقهٔ مدیر سیستم وابسته میشود و با جابهجایی افراد یا افزایش فشار عملیاتی، انسجام خود را از دست میدهد.
استانداردها فاصلهٔ میان «احساس امنیت» و «امنیت قابل اثبات» را پر میکنند. آنها زبان مشترکی میان تیم فنی، مدیر، ممیز و نهاد ناظر میسازند: چه چیزی الزام است، کدام ریسک پذیرفته شده، انحراف با چه توجیهی باقی مانده و مسئول تصمیم چه کسی است.
سه نوع مرجع را با هم اشتباه نگیریم
مراجع امنیتی مرتبط با لینوکس را میتوان در سه دسته دید:
- فنی–اجرایی: به پیکربندی، کاهش سطح حمله، دسترسی، سرویس و لاگ میپردازد و پاسخ میدهد سامانه چگونه باید سختسازی شود.
- ممیزی و بنچمارک: خط پایهٔ قابل سنجش میسازد و نشان میدهد وضعیت فعلی تا چه اندازه با مرجع منطبق است.
- حاکمیتی و رگولاتوری: نقشها، فرآیند پذیرش ریسک، مستندسازی و پاسخگویی را تعریف میکند.
این سه دسته رقیب نیستند. کنترل فنی بدون معیار ممیزی قابل سنجش نیست و بدون پشتوانهٔ حاکمیتی به اقدام مقطعی تبدیل میشود. از سوی دیگر، سیاست حاکمیتی بدون مکانیزم فنی، سندی صوری است که در سامانه enforce نمیشود.
STIG و CIS یک مأموریت ندارند
| ویژگی | DISA STIG | CIS Benchmarks |
|---|---|---|
| نقطهٔ آغاز | محیط مأموریتمحور و تهدید پیشرفته | خط پایهٔ قابل استفاده برای دامنهٔ وسیع سازمانها |
| جهتگیری | حداکثرسازی سختگیری و کاهش امکان سوءاستفاده | توازن میان امنیت، کارایی و قابلیت اجرا |
| ساختار | Rule، شدت، روش Check و دستور Fix | توصیهٔ قابل سنجش با پروفایل و سطح اجرا |
| مناسب برای | سامانههای حساس، طبقهبندیشده یا با پیامد شکست بالا | سرورها و ایستگاههای کاری عمومی تا سازمانی |
| هزینهٔ اجرا | بالا؛ نیازمند آزمون، استثنا و انضباط عملیاتی | پایینتر و مناسبتر برای خط پایهٔ گسترده |
| خطر استفادهٔ کورکورانه | اختلال در مأموریت یا پیچیدگی غیرضروری | ایجاد حس کاذب کفایت در محیطهای پرریسک |
STIG برای بدترین سناریو و مهاجم توانمند طراحی شده است. هر قاعده معمولاً شدت، روش بررسی و روش اصلاح مشخص دارد. این دقت، ممیزی و خودکارسازی را آسانتر میکند، اما اعمال کامل آن روی هر سامانهای درست نیست. محدودسازیای که برای سرور حساس لازم است، ممکن است ایستگاه توسعه یا سامانهٔ عملیاتی را از کار بیندازد.
CIS تلاش میکند خط پایهای قابل دفاع و قابل اجرا برای دامنهٔ وسیعتری ارائه کند. Level 1 معمولاً حداقل سختگیری با اثر عملیاتی محدودتر است و Level 2 کنترلهای بیشتری برای محیط پرریسک دارد. با این حال، حتی Level 2 نیز جای مدل تهدید مأموریتمحور را نمیگیرد.
بنابراین انتخاب مرجع باید پس از دستهبندی کاربری و ریسک سامانه انجام شود. اینکه یک اسکنر «۱۰۰ درصد CIS» گزارش کند، چیزی دربارهٔ تناسب آن خط پایه با مأموریت مشخص نمیگوید.
چکلیست امنیت نیست
چکلیست برای تکرار و ممیزی ضروری است، اما اگر از زمینه جدا شود، سه خطا میسازد. نخست، سازمان به عدد انطباق بهجای کاهش ریسک پاداش میدهد. دوم، کنترلهای ناسازگار با مأموریت یا غیرفعال میشوند یا بدون ثبت استثنا دور زده میشوند. سوم، تیم تصور میکند موارد خارج از چکلیست فاقد اهمیتاند.
هر بند باید به چهار پرسش پاسخ دهد:
- کدام تهدید یا ریسک را کاهش میدهد؟
- در کدام کاربری و با چه شدت لازم است؟
- چه اثر عملیاتی یا تعارضی ایجاد میکند؟
- اگر اعمال نشد، چه کسی استثنا را تا چه زمانی پذیرفته است؟
در این نگاه، امتیاز انطباق خروجی فرعی است. خروجی اصلی، شواهدی است که نشان میدهد کنترل مناسب، در جای مناسب و با مالک تصمیم مشخص اعمال شده است.
لایههای کنترل در سیستمعامل
کنترلهای استاندارد را میتوان در چهار لایه دید:
| لایه | نقش امنیتی | نمونهٔ تصمیم |
|---|---|---|
| کرنل و سیستمعامل | کنترل رفتار پایه، حافظه، ماژولها و فراخوانیهای سیستم | چه ماژول و قابلیت کرنل مجاز است؟ |
| فضای کاربر | مهار برنامهها، ابزارها و حسابهای محلی | چه بسته و ابزار مدیریتی باید نصب باشد؟ |
| سرویسها و daemonها | کاهش سطح تماس با شبکه و اجرای کماختیار | کدام سرویس فعال و با چه حسابی اجرا شود؟ |
| سیاست و دسترسی | ترجمهٔ مسئولیت سازمانی به اختیار فنی | چه نقشی مجاز است کدام عمل را انجام دهد؟ |
هسته میتواند سوءاستفادهٔ ساختاری را دشوار کند، اما پاسخگویی مدیریتی ایجاد نمیکند. سیاست دسترسی میتواند اختیار را تعریف کند، اما اگر سرویس با root و بدون محدودیت کرنل اجرا شود، سیاست روی کاغذ باقی میماند. امنیت از رفتوبرگشت میان تصمیم بالادستی و enforceشدن در لایههای پایین ساخته میشود.
RBAC یک کنترل حاکمیتی است
RBAC پیش از آنکه ویژگی فنی باشد، پاسخ به این پرسش است: چه کسی، به دلیل کدام وظیفه، با چه سطح اختیار و تحت مسئولیت چه نقشی به منبع دسترسی دارد؟ نقش معادل نام کاربر یا گروه لینوکسی نیست؛ نمایندهٔ وظیفه، اختیار و پاسخگویی سازمانی است.
اگر چند گروه ساخته شوند اما نسبت آنها با مسئولیت واقعی روشن نباشد، RBAC پیاده نشده است. اگر فرد با تغییر سمت همچنان دسترسی قبلی را نگه دارد، نقش فقط برچسب بوده است. اگر دسترسی اضطراری دائمی شود یا استفاده از آن ممیزی نشود، تفکیک وظایف شکست خورده است.
RBAC در بالاترین لایهٔ معماری قرار دارد، اما خودش عمل فنی را enforce نمیکند. تصمیم «اپراتور فقط وضعیت سرویس را ببیند و مدیر تغییر را تأیید کند» باید با sudo policy، PAM، گروهها، مجوز فایل، API، ابزار مدیریت و ثبت لاگ اجرا شود. قابلیت ردیابی از نقش سازمانی تا مجوز فنی، معیار بلوغ است.
SELinux و AppArmor کنترل نیستند؛ مکانیزماند
عبارت «SELinux داریم» هدف امنیتی را توضیح نمیدهد. SELinux و AppArmor سازوکارهای Mandatory Access Control هستند که میتوانند رفتار فرآیند را فراتر از مجوز سنتی کاربر/گروه محدود کنند. آنها ابزار اجرای سیاستاند، نه خود سیاست.
کنترل میگوید «سرویس وب حتی پس از نفوذ نباید فایل پشتیبان یا سوکت مدیریتی را بخواند». مکانیزم مشخص میکند این محدودیت با type enforcement در SELinux، پروفایل AppArmor، namespace، seccomp یا ترکیبی از آنها چگونه اجرا شود.
این تفکیک چند فایده دارد. سازمان به یک ابزار خاص قفل نمیشود، ممیز میتواند نتیجه را بسنجد و تیم فنی میتواند با توجه به توزیع و کاربری، مکانیزم مناسب را انتخاب کند. در میزبان کانتینر، همین کنترل ممکن است همزمان به LSM، seccomp، capability و سیاست runtime نیاز داشته باشد.
استثنا نشانهٔ ضعف نیست؛ استثنای بیمالک ضعف است
هیچ خط پایهای بدون استثنا بر همهٔ سامانهها اعمال نمیشود. سامانهٔ صنعتی شاید نتواند الگوریتم یا timeout مورد توصیه را بپذیرد؛ برنامهٔ قدیمی ممکن است با یک سیاست MAC ناسازگار باشد. بلوغ در انکار این تعارض نیست؛ در ثبت و ادارهٔ آن است.
استثنای دفاعپذیر باید شامل کنترل مرجع، دلیل فنی و مأموریتی، دامنهٔ سامانهها، ریسک باقیمانده، کنترل جبرانی، مالک پذیرش، تاریخ پایان و شرط بازبینی باشد. استثنایی که پایان و صاحب ندارد، عملاً تغییر غیررسمی خط پایه است.
این منطق دربارهٔ سیستمهای Legacy اهمیت بیشتری دارد. اجرای اسکن و گزارش قرمز، تصمیم را حل نمیکند. باید مشخص شود دارایی قابل اصلاح است، باید منزوی شود یا اساساً به نقطهای رسیده که مهاجرت ظاهری ریسک آن را حذف نمیکند.
استاندارد نقطهٔ پایان امنیت نیست؛ راهی برای تبدیل تصمیم به زبان مشترک، کنترل قابل اجرا و شواهد قابل ممیزی است. هرجا نام ابزار جای هدف کنترل را بگیرد یا درصد انطباق جای مدل تهدید بنشیند، استاندارد به آیین اداری تبدیل شده است.