أتمتة إنشاء مستخدمين جدد بصلاحيات محددة على السيرفرات لفرق العمل

إدارة حسابات المستخدمين على الخوادم لم تعد مهمة تشغيلية بسيطة، خصوصاً عندما يكبر الفريق وتتنوع البيئات بين development وstaging وproduction. إنشاء المستخدمين يدوياً يستهلك وقتاً، ويؤدي إلى تفاوت في الصلاحيات، وأحياناً يفتح ثغرات خطيرة بسبب نسيان تقييد الوصول أو إضافة مفاتيح غير موثقة.

لهذا السبب تعتمد فرق ما هو DevOps؟ ولماذا تدفع الشركات ثروات لمهندسي الأتمتة السحابية؟ على أتمتة دورة حياة المستخدم: من لحظة انضمامه للفريق، إلى منحه أقل صلاحيات لازمة، وحتى إلغاء وصوله عند المغادرة. الفكرة ليست فقط إنشاء حساب عبر أمر useradd، بل بناء نظام متكرر وقابل للتدقيق.

لماذا الأتمتة أفضل من الإدارة اليدوية؟

عندما تُدار الحسابات يدوياً، يصبح كل مسؤول أنظمة مصدراً مختلفاً للحقيقة. أحدهم يضيف المستخدم إلى مجموعة sudo، وآخر يرفع مفتاح SSH بشكل مباشر، وثالث ينسى حذف الحساب بعد انتهاء المشروع. النتيجة هي بيئة غير متسقة يصعب تدقيقها.

أما الأتمتة فتمنحك مزايا عملية واضحة:

• توحيد الصلاحيات بين كل الخوادم.
• تطبيق مبدأ الحد الأدنى من الامتيازات Least Privilege.
• تسجيل كل تعديل داخل مستودع Git للمراجعة والتتبع.
• ربط إنشاء الحسابات مع خطوط CI/CD لاعتماد التغييرات بعد التحقق.
• تسريع ضم الموظفين الجدد Onboarding وتقليل الأخطاء البشرية.

التصميم الصحيح: صلاحيات حسب الأدوار وليس حسب الأشخاص

أفضل ممارسة هنا هي بناء نموذج RBAC، أي منح الصلاحيات بناءً على الدور الوظيفي. بدلاً من سؤال “ماذا يحتاج أحمد؟” اسأل “ماذا يحتاج دور backend-developer؟”.

يمكن تقسيم المستخدمين مثلاً إلى مجموعات كالتالي:

• devops: صلاحية إدارة الخدمات والسجلات وبعض أوامر sudo.
• developers: وصول محدود لقراءة السجلات وتشغيل أوامر النشر غير الحساسة.
• auditors: قراءة فقط دون أي صلاحيات تنفيذية.

لا تمنح أي مستخدم صلاحية sudo الشامل بشكل افتراضي. الأفضل هو تقييد الأوامر المسموحة داخل ملف sudoers لكل مجموعة، لأن الحساب المفرط الصلاحيات هو أسرع طريق إلى اختراق أو توقف كارثي للخدمة.

استخدام Ansible لأتمتة إنشاء الحسابات

إذا كنت قد قرأت ما هو Ansible؟ وكيف تتحكم في 100 سيرفر Linux من حاسوبك المكتبي؟ فستعرف أنه خيار ممتاز لإدارة المستخدمين بشكل مركزي. ويمكن دمجه بسهولة مع كتابة ملفات الجرد (Inventory) لتعريف وتصنيف الخوادم لتوزيع الصلاحيات حسب نوع الخادم.

الخطوة الأولى هي تعريف المستخدمين ومجموعاتهم ومفاتيحهم العامة داخل متغيرات منظمة:

users:
  - name: ali
    groups:
      - developers
    shell: /bin/bash
    ssh_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleAliKey ali@laptop"

  - name: sara
    groups:
      - devops
    shell: /bin/bash
    ssh_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleSaraKey sara@laptop"

  - name: nour
    groups:
      - auditors
    shell: /bin/bash
    ssh_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleNourKey nour@laptop"

بعدها نكتب playbook ينشئ المجموعات والحسابات ويرفع مفاتيح SSH تلقائياً:

- name: Provision team users
  hosts: all
  become: true

  vars_files:
    - users.yml

  tasks:
    - name: Ensure groups exist
      group:
        name: "{{ item }}"
        state: present
      loop:
        - developers
        - devops
        - auditors

    - name: Create users
      user:
        name: "{{ item.name }}"
        shell: "{{ item.shell }}"
        groups: "{{ item.groups | join(',') }}"
        append: true
        create_home: true
        state: present
      loop: "{{ users }}"

    - name: Add authorized keys
      authorized_key:
        user: "{{ item.name }}"
        key: "{{ item.ssh_key }}"
        state: present
      loop: "{{ users }}"

هذا الأسلوب يحقق ما يسمى idempotency، أي أن تشغيل الأتمتة أكثر من مرة لا يكرر الحسابات ولا يفسد الحالة الحالية، بل يطبق الوضع المطلوب فقط.

تقييد أوامر sudo بدقة

بدلاً من إعطاء مجموعة devops صلاحية كاملة، يمكن السماح بأوامر تشغيل خدمات معينة فقط:

echo "%devops ALL=(ALL) NOPASSWD:/bin/systemctl restart nginx,/bin/systemctl status nginx,/usr/bin/journalctl" > /etc/sudoers.d/devops-limited
chmod 440 /etc/sudoers.d/devops-limited
visudo -cf /etc/sudoers.d/devops-limited

يمكن أيضاً أتمتة هذا الملف عبر Ansible باستخدام قالب template لضمان اتساق الصلاحيات على جميع العقد.

ربط إدارة المستخدمين مع Git وCI/CD

القوة الحقيقية تظهر عندما تصبح بيانات المستخدمين جزءاً من مستودع البنية التحتية. يرسل مسؤول الفريق Pull Request لإضافة مستخدم جديد، ثم يتم فحص التغيير والموافقة عليه قبل التطبيق. هذا ينسجم مع ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟ ومع مفهوم الحوكمة التشغيلية الحديثة.

مثلاً يمكن إنشاء مسار عمل عبر مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow) لتشغيل فحص بنية ملفات المستخدمين ثم تطبيق playbook بعد الموافقة:

name: Provision Users

on:
  push:
    branches:
      - main

jobs:
  ansible:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Install Ansible
        run: |
          python3 -m pip install ansible

      - name: Run playbook
        env:
          ANSIBLE_HOST_KEY_CHECKING: "False"
        run: |
          ansible-playbook -i inventory.ini provision-users.yml

ولحماية المفاتيح وبيانات الدخول لا بد من استخدام إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة بدلاً من حفظ أي بيانات حساسة داخل المستودع مباشرة.

لا تجعل إضافة المستخدمين إلى الخوادم الإنتاجية مرتبطة بأي push عشوائي. يجب وجود مراجعة بشرية، وتفعيل حماية الفروع بالاستفادة من حماية الفروع (Branch Protection) ومنع رفع الأكواد الخاطئة للنسخة الحية لأن خطأ واحداً في الصلاحيات قد يفتح الوصول إلى كامل البنية التحتية.

سحب الوصول وإدارة مغادرة الموظفين

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

يمكن تعديل تعريف المستخدمين بإضافة حالة الحساب:

users:
  - name: ali
    state: present
  - name: old_user
    state: absent

ثم تحديث المهمة في Ansible لتدعم الحذف المنظم. بهذه الطريقة يصبح سحب الوصول قابلاً للتكرار والتوثيق، بدلاً من الاعتماد على الذاكرة البشرية.

أفضل الممارسات المعمارية والأمنية

• استخدم مفاتيح SSH Keys بدلاً من كلمات المرور، ويمكنك الرجوع إلى إعداد الاتصال الآمن (SSH Keys) بدون كلمات مرور بين جهازك والخوادم.
• قسّم الخوادم داخل inventory حسب البيئة والحساسية الوظيفية.
• طبّق سجلات تدقيق audit logs لكل عملية دخول أو تنفيذ أوامر عالية الامتياز.
• ادمج إدارة المستخدمين مع أتمتة جدار الحماية عبر أتمتة إعداد جدار الحماية (UFW) وتأمين عدة سيرفرات Linux بضغطة واحدة لحصر الوصول من شبكات العمل الموثوقة فقط.
• اختبر التغييرات أولاً على بيئة staging قبل تطبيقها على production.

الخلاصة

أتمتة إنشاء المستخدمين بصلاحيات محددة ليست رفاهية تشغيلية، بل طبقة أساسية من الحوكمة والأمن وقابلية التوسع. عندما تُدار الحسابات ككود عبر Ansible وتخضع للمراجعة داخل Git وتنفذ عبر CI/CD، فإنك تقلل الفوضى، وتسرّع ضم أعضاء الفريق، وتحاصر الأخطاء الأمنية قبل أن تتحول إلى حوادث إنتاجية.

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