إدارة المستخدمين والصلاحيات: البوابة الأولى لأمن السيرفرات

[Kryv!on]

"لماذا يملك موظف التسويق صلاحية الوصول لقاعدة بيانات العملاء؟"

سؤال بسيط طرحه أحد مديري الأمن في شركة ناشئة بعد اكتشاف تسريب لآلاف السجلات. الجواب كان مؤلماً: "لأننا لم نفكر في الأمر يوماً."

هذه الجملة "لم نفكر في الأمر" هي السبب الأول في معظم اختراقات السيرفرات التي لا تبدأ بثغرة تقنية معقدة،
بل بتساهل في إدارة من يفعل ماذا داخل بيئتك الرقمية.

في عالم يتسارع فيه كل شيء، من السهل أن نركز فرق العمليات والتطوير على السرعة: نشر الخدمات،
فتح المنافذ، إعطاء الصلاحيات بسخاء حتى "لا يتوقف أحد".
لكن هذا المنطق رغم جاذبيته في المدى القصير يبني قصراً من الرمل. وعندما يأتي الريح (وهي آتية دائماً)،
فإنها لا تهدم الجدران فحسب، بل تُسقط الثقة بأكملها.

لماذا تبدأ الحماية من هنا؟

لنتخيّل سيرفرك كمبنى إداري. لديك غرف خاصة بالمحاسبة، أخرى للهندسة، ومخازن للوثائق السرية.
لن يخطر ببال أحد أن يعطي مفتاح المخزن لكل موظف جديد "لأنه ربما سيحتاجه يوماً". لكن في عالم السيرفرات، يحدث هذا يومياً.

إدارة المستخدمين والصلاحيات ليست مجرد "إعدادات تقنية" تُترك لأمر useradd أو نقرات في لوحة التحكم.
هي سياسة أمنية تعكس فهمنا لطبيعة عملنا، ومدى وعينا بأن الخطر لا يأتي دائماً من الخارج.
في كثير من الأحيان، يأتي من الداخل: من حساب مهمل، من مفتاح SSH تركناه لمطور في حاسوبه القديم،
أو من صلاحية root أُعطيت لشخص لم يعد يعمل معك منذ سنة.

المبدأ الذهبي: الامتياز الأدنى (Least Privilege)

قبل أن نتكلم عن الأوامر والأدوات، دعونا نتفق على مبدأ لا يتجزأ:
كل مستخدم، كل خدمة، كل سكربت يجب أن يملك فقط ما يحتاجه لإنجاز مهمته لا أكثر ولا أقل.

هذا المبدأ يبدو واضحاً، لكن تطبيقه يتطلب شجاعة إدارية. يتطلب أن تقول "لا" لزميل يطلب صلاحية وصول شاملة "للتسهيل".
يتطلب أن تبني عمليات تستغرق دقيقتين إضافيتين بدلاً من ثانية واحدة غير آمنة.
هذه الدقيقتان قد توفران لك شهراً من التحقيقات القضائية لاحقاً.

بناء هوية موثوقة: إدارة دورة حياة المستخدمين

1. من يدخل؟ وكيف؟

لا يكفي أن نعرف من يملك حساباً، بل يجب أن نعرف لماذا يملكه.
عند إنشاء أي حساب جديد سواء لموظف، متعاقد، أو خدمة تطبيقية لنسأل أنفسنا أولا:

01- ما هي الحد الأدنى من الموارد التي يحتاجها؟
02- هل هذا الوصول دائم أم مؤقت؟
03- ما هي آلية إلغاء الحساب عند انتهاء الحاجة؟

الحسابات الخدمية (Service Accounts) تحتاج عناية خاصة.
تلك الحسابات التي تُنشأ ليقوم بها تطبيقك بمهمة محددة يجب أن تكون مقيّدة بشدة.
لا يجب إستخدام حساب الجذرroot لتشغيل تطبيق الويب. و لا نعطِي قاعدة البيانات صلاحية الكتابة على ملفات النظام.
كلما عزلت الخدمة، قلّت مساحة الضرر عند استهدافها.

2. التجميع الذكي (Group-Based Management)

إدارة الصلاحيات على مستوى الفرد مستنزفة وعرضة للخطأ.
الحل هو التفكير في "الأدوار" لا "الأشخاص".

أنشئ مجموعات تعكس بنية عملك الفعلية:
1- web-developers : الوصول لملفات المشاريع فقط.
2- db-admins: الوصول لخوادم قواعد البيانات.
3- backup-operators: صلاحية القراءة اللازمة للنسخ الاحتياطي.

عندما ينضم شخص جديد، تُضافه لمجموعة. عندما ينتقل لقسم آخر، تُنقل عضويته.
عندما يرحل، تُلغى. هذه البساطة تقلل الأخطاء البشرية وتجعل المراجعة الدورية ممكنة.

3. السياسات وكلمة المرور: الخط الأول

لا تُترك كلمات المرور لإبداع المستخدمين. فرض سياسة صارمة:
1- طول لا يقل عن 12 حرفاً، مع تنوع في الأحرف.
2- تغيير دوري إذا لزم الأمر، لكن الأهم: عدم إعادة الاستخدام.
3- تفعيل المصادقة متعددة العوامل (MFA) في كل مكان ممكن. لا تكتفي بها كـ "خيار"، اجعلها إلزامية.

لكن هنا يجب علينا الحذر: السياسة الصارمة التي تُرهق المستخدم ستدفعهم لإيجاد طرق للالتفاف حولها
كتابة كلمات المرور على ورقات ملصقة على الشاشة. التوازن هنا فنٌ إداري.

الصلاحيات: فن التوزيع لا التكديس

نموذج RBAC: الأدوار بوضوح

نموذج التحكم بالوصول المعتمد على الأدوار (Role-Based Access Control) هو المعيار في البيئات المتوسطة والكبيرة.
الفكرة: نعرف الأدوار (مثل: مطور، مدير قاعدة بيانات، مراقب)، ونربط كل دور بمجموعة صلاحيات، ثم تُسند الأدوار للمستخدمين.

هذا يُبقي خريطة الصلاحيات منظمة. عندما تريد معرفة "من يستطيع الوصول لسيرفر الإنتاج؟"،
فهنا لا نبحث في قائمة طويلة من المستخدمين، بل تنظر في قائمة الأدوار.

إستخدام sudo بذكاء، لا بسخاء

في بيئات Linux، أداة sudo هي سيف ذو حدين. الاستخدام الخاطئ لها يُحوّل كل مستخدم عادي إلى خطر محتمل.

• لا تُعطِ sudo بدون تحديد الأوامر المسموح بها. استخدم /etc/sudoers لتحديد بدقة: "هذا المستخدم يستطيع إعادة تشغيل خدمة الويب فقط".
• راجع سجلات sudo بانتظام. الأمر ausearch -m USER_START أو مراجعة /var/log/auth.log يمكن أن تكشف محاولات تسلل مبكرة.
• تجنب إضافة مستخدمين لمجموعة wheel أو sudo بشكل افتراضي. اجعلها استثناءً يُبرَّر.

قوائم التحكم بالوصول (ACLs)

في بعض الأحيان، نموذج المالك المجموعة الآخرين (UGO) في Linux غير كافٍ. هنا تلعب ACLs دورها. مع setfacl
وgetfacl، يمكنك منح صلاحيات دقيقة لمستخدم محدد على ملف محدد دون تغيير هيكل المجموعات.

لكن ها يجب الحذر مجددا: الاستخدام المفرط لـ ACLs يُعقّد المراجعة.
إذا وجدت نفسك تُضيف ACLs لكل ملف، فربما هناك خلل في تصميم هيكل المجموعات لديك.

أفضل الممارسات التي يجب أن تكون عادةً

1. المراجعة الدورية: فحص المستخدمين النائمين

كل ثلاثة أشهر على الأقل، شغّل أمراً بسيطاً:

lastlog | grep "Never"

لكن لا نكتفِ بذلك. راجع قائمة المستخدمين النشطين:
هل كل هؤلاء لا يزالون يعملون معنا؟ هل الحسابات الخدمية لا تزال مستخدمة؟ الحساب النائم هو باب موارب للمهاجم.

2. فصل البيئات

لا نستخدم نفس بيانات الاعتماد (credentials) لبيئة التطوير وبيئة الإنتاج.
ولا نعطِ نفس المستخدمين صلاحيات الوصول لكليهما. هذا الفصل ليس "إزعاجاً تقنياً"،
بل حاجز وقائي إذا اخترق مطور بيئة التطوير (وهي عادةً أقل حماية)، فإنه لا يملك مفاتيح الإنتاج.

3. تدوير الأسرار (Secrets Rotation)

مفاتيح SSH، كلمات مرور قواعد البيانات، رموز API كلها أسرار يجب أن تتغير. لا نتظر الاختراق لتغييرها.
بنِ آلية تدوير دورية. أدوات مثل HashiCorp Vault أو AWS Secrets Manager
أو حتى حلول مفتوحة المصدر مثل Mozilla SOPS يمكن أن تُسهّل هذه العملية.

4. تسجيل ومراقبة الوصول

كل محاولة دخول فاشلة، كل أمر sudo ناجح، كل تغيير في ملفات التكوين يجب أن يُسجل في مكان مركزي.
ليس للتخزين، بل للتحليل. لنستخدم أدوات مثل auditd، OSSEC، أو Wazuh
لاكتشاف الأنماط الغريبة: هل هذا المستخدم يدخل في وقت غير عادته؟
هل هناك محاولات متكررة من IP غريب؟

الأدوات التي تُسهّل الحياة

لا يجب أن نعيد اختراع العجلة. هناك أدوات مُختبرة:

1- FreeIPA / Red Hat IDM: لإدارة مركزية للهويات في بيئات Linux.
2- Active Directory / Azure AD: للبيئات المختلطة أو المعتمدة على Microsoft.
3- Ansible / Puppet / Chef: لأتمتة إنشاء المستخدمين وتوزيع الصلاحيات بشكل متسق عبر مئات السيرفرات.
4- OpenLDAP: للبيئات التي تفضل الحلول مفتوحة المصدر والمرنة.
5- PAM (Pluggable Authentication Modules): للتحكم الدقيق في كيفية ومتى يمكن للمستخدمين المصادقة.

لنختر ما يناسب بيئتنا، لكن لا نكثر من الأدوات.
أحياناً، بيئة صغيرة تستفيد أكثر من ssh-keygen وsudoers مدارَين بعناية، من شبكة معقدة من الأدوات لا أحد يفهمها.

فالأمن ثقافة قبل أن يكون تقنية لأن إدارة المستخدمين والصلاحيات ليست مهمة تُنجز مرة واحدة ثم تُنسى.
هي عادة يجب أن تتكرر يومياً. هي قرار إداري بأن "السهولة" ليست أولوية مطلقة، وأن "السرعة" يجب ألا تأتي على حساب "الرؤية".

في نهاية المطاف، لن يُقيّم أمن سيرفراتتنا بقوة جدار النار فحسب،
بل بمدى دقة معرفتنا بـمن يفعل ماذا، ومتى، ولماذا.
وهذه المعرفة لا تأتي من الأدوات، بل من وعينا بأن كل حساب مهما بدا بريئاً هو باب.
وباب مغلق بإحكام خيرٌ دائماً من باب مفتوح "للتسهيل".

فالحماية لا تبدأ بجدار عالٍ، بل بسؤال بسيط: هل هذا الشخص حقاً يحتاج أن يكون هنا؟
أي إستفسار يمكن ترك سؤلك في رد أسفل الموضوع و أكون سعيد للتحاور
المصدر: dev-point.net​