إدارة الامتثال Compliance مع CISO Assistant على سيرفرك

لنفرض أن لديك شركة ناشئة في الرياض من اثني عشر موظفاً تبني منصة لحجز مواعيد العيادات، وأن مستشفى حكومياً وقع معها عقداً فيه ملحق يقول إن على الشركة الالتزام بمتطلبات الضوابط الأساسية للأمن السيبراني ECC-2:2024 التي تنطبق على خدمتها، وتقديم تقييم ذاتي كل ربع سنة. فتح مدير التقنية ملف Excel، وكتب فيه 108 صفوف بأرقام الضوابط، وأضاف عموداً للحالة وعموداً للملاحظات وعموداً لروابط الأدلة في المجلد المشترك. في الأسبوع الأول كان الملف ممتازاً، وبعد شهرين أصبح في البريد ثلاث نسخ منه بأسماء مثل «ECC-final» و«ECC-final-2» و«ECC-final-مراجعة»، ونصف روابط الأدلة يشير إلى ملفات نقلها أحد الزملاء إلى مجلد آخر، وعندما سأل المستشفى «ما الذي تغير منذ التقييم الماضي؟» لم يستطع أحد أن يجيب دون أن يقارن النسخ صفاً صفاً.

وهذه القصة تتكرر في كل جهة تبدأ الامتثال Compliance بجدول، وليست المشكلة في Excel نفسه، وإنما في أن الجدول لا يعرف شيئاً عن العلاقات: الضابط الواحد في المؤسسة، مثل التحقق متعدد العوامل MFA للمديرين، يجيب عن متطلب في ECC ومتطلب في ISO/IEC 27001 ومتطلب في عقد عميل آخر، والدليل الواحد يثبت أكثر من ضابط، وخطة المعالجة لها مالك وتاريخ. ولهذا ظهرت أدوات الحوكمة والمخاطر والامتثال GRC، وأشهرها مفتوح المصدر اليوم CISO Assistant. وقد شرحنا المصطلحات في مصطلحات GRC، وخريطة الضوابط وأدواتها التقنية في تحقيق ضوابط ECC بأدوات مفتوحة المصدر، أما في هذا المقال فسوف نشغل CISO Assistant على سيرفرنا، ونحمل فيه نص ECC-2:2024، ونقيم منصة الحجز، ونربط الضوابط بالأدلة، ونصدر النتيجة، ونذكر كل مشكلة واجهناها في الطريق.

دليلمصطلحات GRC للمبتدئين بمثال من شركة صغيرةما الذي يعنيه GRC فعلاً، وما الكلمات التي يستخدمها المدقق، وكيف تثبت له أن ضوابطك تعمل كما تقول.دليلتحقيق ضوابط ECC بأدوات مفتوحة المصدر Open Sourceخريطة تربط كل ضابط فرعي في الضوابط الأساسية ECC بالأداة مفتوحة المصدر التي تحققه وبالمقال الذي شرحها، مع إثبات ضابطين بمخرج حقيقي.دليلأطر الأمن السيبراني Frameworks: أيها تحتاج مؤسستك؟الفرق بين ECC وISO 27001 وNIST CSF وSOC 2 في الإلزام وطريقة الإثبات وما تحصل عليه، وأربعة أسئلة تحدد بها ما تحتاجه مؤسستك.

وسوف نناقش في هذا المقال ما يلي:

• لماذا لا يكفي جدول Excel عندما يكبر الامتثال، وما الذي تضيفه أداة GRC بالضبط.
• ما هو CISO Assistant، ومن يطوره، وما الفرق بين النسخة المجتمعية Community والنسخة التجارية Pro، وكم تكلف.
• الكائنات الخمسة التي يقوم عليها: المكتبة والنطاق والتدقيق والضابط المطبق والدليل.
• ما الذي يعمل عند التشغيل بـ Docker Compose، وكم يستهلك من الذاكرة والقرص بالأرقام.
• التثبيت خطوة خطوة، والمشكلات الثلاث التي واجهناها: أول تشغيل استغرق 59 دقيقة، ومنفذ لا يجيب، وصفحة تعطي خطأ 500.
• تحميل مكتبة ECC-2:2024، ولماذا تظهر فيها 176 متطلباً وليس 108.
• إنشاء التدقيق، وتقييم المتطلبات، وربطها بالضوابط المطبقة والأدلة، وخطة العمل.
• التصدير إلى CSV وExcel وWord وتقرير HTML، وقراءة المخرج سطراً سطراً.
• الأتمتة عبر الـ API، والنسخ الاحتياطي، والواجهة العربية، وقائمة تحقق قبل أن تعتمد الأداة.

لماذا لا يكفي جدول Excel؟

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

• أكثر من إطار: بعد المستشفى الحكومي جاء عميل من القطاع الخاص يطلب ISO/IEC 27001، فأصبح عند الشركة جدولان فيهما الضوابط نفسها بأرقام مختلفة، وكل تحديث يجب أن يتكرر مرتين، وقد بينا في مقال الأطر كيف يقابل الضابط الواحد أرقاماً في أربع وثائق.
• أكثر من شخص: مسؤول الأمن يقيم، والمطور يرفع الدليل، والمدير يعتمد، والجدول لا يعرف من غير ماذا ولا متى.
• الأدلة خارج الجدول: الرابط في الخلية لا يمنع حذف الملف أو نقله، ولا يقول لك إن الدليل عمره ثمانية أشهر وصار قديماً.
• الأسئلة التي تحتاج تجميعاً: «كم متطلباً غير ملتزم في المكون الثاني؟» و«ما الضوابط التي لم تبدأ وموعدها هذا الشهر؟» أسئلة تحتاج في الجدول فلاتر وصيغاً يكتبها شخص واحد ولا يفهمها غيره.
• تغير الإطار نفسه: عندما أصدرت الهيئة الوطنية للأمن السيبراني ECC-2:2024 بعد ECC-1:2018 تغيرت أرقام وأضيفت بنود، والجدول لا يعرف أي صف يقابل أي صف.

وأداة GRC في جوهرها قاعدة بيانات تعرف هذه العلاقات: الإطار متطلبات، والمتطلب يقيم في تدقيق على نطاق محدد، والتقييم يشير إلى ضوابط مطبقة، والضابط المطبق له أدلة ومالك وحالة وتاريخ، والربط بين الأطر جداول جاهزة. وكل ما تراه في واجهتها من لوحات ونسب مئوية هو استعلامات على هذه العلاقات. وقد يتساءل البعض: هل نحتاج أداة لشركة من اثني عشر شخصاً؟ والإجابة أنك لا تحتاجها في الشهر الأول، وتحتاجها عندما يصبح عندك إطاران أو عميلان يطلبان أدلة، أو عندما يصبح سؤال «ما الذي تغير منذ آخر تقييم؟» سؤالاً لا يجيب عنه أحد بثقة.

ما هو CISO Assistant؟

CISO Assistant أداة GRC تطورها شركة intuitem الفرنسية، والكود في مستودع ciso-assistant-community على GitHub، وعند كتابة المقال كان للمستودع أكثر من 4,500 نجمة، وآخر إصدار هو v4.1.5 بتاريخ 24 أكتوبر 2026، وقبله v4.1.4 في اليوم نفسه وv4.1.3 قبل أسبوع، أي أن المشروع يصدر نسخاً متقاربة جداً، وهذا جيد للإصلاحات، ومزعج إذا لم تثبت رقم الإصدار في ملف التشغيل، كما سوف نفعل.

والترخيص يحتاج قراءة دقيقة، فبحسب ملف الترخيص كل ما في المستودع خارج مجلد enterprise مرخص بـ AGPLv3، والـ Images المنشورة تحت ghcr.io/intuitem/ciso-assistant-community/ مرخصة بـ AGPLv3 أيضاً، أما مجلد enterprise والـ Images المنشورة مباشرة تحت ghcr.io/intuitem/ فتحت ترخيص تجاري يحتاج عقداً. ولذلك انتبه للمسار الذي تسحب منه الـ Image، فالأول مفتوح المصدر والثاني ليس كذلك. وترخيص AGPLv3 يعني أنك تستطيع تشغيله داخل جهتك وتعديله بحرية، وإذا قدمت نسخة معدلة منه خدمة لغيرك عبر الشبكة فعليك أن تتيح لهم كود التعديلات، وقد شرحنا هذا الفرق في تراخيص المصادر المفتوحة.

النسخة المجتمعية Community والنسخة Pro وأسعارها

تقول صفحة المقارنة بين النسختين إن Pro ليست منتجاً مختلفاً، وإنما النسخة المجتمعية نفسها مع ميزات ودعم فوقها. والنسخة المجتمعية فيها ما يحتاجه فريق صغير: تقييم المخاطر، وإدارة الامتثال بعدة أطر، وتخصيص الأطر، وإدارة الأصول، وتحليل أثر الأعمال BIA، وإدارة الأدلة والوثائق، والحوادث، ووحدة الأطراف الخارجية TPRM، والمهام والتذكير، والمستخدمين والصلاحيات، والدخول الموحد SSO عبر SAML، والتصدير، والـ API. أما Pro فتضيف أشياء تحتاجها الجهات الأكبر، منها التسلسل الهرمي متعدد المستويات للنطاقات، والصلاحيات الدقيقة، وSCIM، والحقول المخصصة، وتصدير نطاق كامل واستيراده، وسجل التدقيق Audit Log لكل تغيير، وقوالب Word مخصصة، والتكامل مع Jira وServiceNow، وإرسال سجل التدقيق إلى SIEM.

والأسعار كما في صفحة الأسعار بتاريخ 25 أكتوبر 2026، وكلها دون الضرائب:

والقرار لشركة منصة الحجز واضح: النسخة المجتمعية على سيرفر داخل المملكة، لأن الأدلة نفسها قد تحتوي معلومات حساسة عن البنية، ونقلها إلى SaaS في الخارج يضيف سؤالاً لا تحتاجه، كما ناقشنا في حماية البيانات الشخصية للخدمات المستضافة.

المكتبات: 362 ملفاً، منها ضوابط الهيئة

قيمة أداة GRC الحقيقية في محتواها، فكتابة 176 متطلباً بنصوصها يدوياً عمل أيام. وفي الإصدار v4.1.5 يحتوي مجلد المكتبات في المستودع على 362 ملف YAML، منها 63 ملف ربط Mapping بين أطر، مثل الربط بين NIST CSF 2.0 وISO/IEC 27001:2022، وبين SOC 2 وISO/IEC 27001:2022. والمهم لنا أن فيها مكتبة ECC-2:2024 التي يذكر رأسها أنها من حزمة المجتمع Packager: community، وأن مصدرها هو ملف الهيئة الإنجليزي نفسه، وتاريخ نشرها في المكتبة 23 يونيو 2026. وفيها أيضاً مكتبة لنظام حماية البيانات الشخصية باسم pdpl-ksa، ومكتبة لإطار البنك المركزي السعودي sama-csf-1.0، ومكتبة لضوابط الحوسبة السحابية.

ولا توجد في الإصدار نفسه ملفات ربط بين ECC-2:2024 وISO/IEC 27001، فإذا أردت أن تستفيد من ميزة الربط بين الأطر لـ ECC فعليك أن تبني الربط بنفسك، أو أن تعتمد على الضوابط المطبقة المشتركة كما سوف نفعل.

الكائنات الخمسة التي تحتاج أن تفهمها

أكثر ما يربك من يفتح الأداة أول مرة كثرة القوائم، لكن العمل اليومي يدور حول خمسة كائنات فقط، والشكل التالي يبينها بالترتيب الذي سوف نعمل به في التجربة:

1. المكتبة Library: ملف YAML فيه الإطار بمتطلباته، يكون في الأداة «مخزناً» Stored حتى تحمله Load فيصبح إطاراً Framework قابلاً للاستخدام. والفصل بين الحالتين مقصود، فالأداة تأتي بمئات المكتبات ولا تريد أن تملأ قاعدة البيانات بما لا تستخدمه.
2. النطاق Domain والمحيط Perimeter: النطاق مجلد يجمع كل ما يخص جهة أو وحدة، والمحيط هو الشيء الذي نقيمه داخله، مثل «منصة الحجز وسيرفراتها». وتحديد المحيط بدقة هو نفسه تحديد نطاق العمل Scope الذي يسأل عنه كل مدقق.
3. التدقيق Audit: نسخة من الإطار مطبقة على محيط واحد في وقت محدد، ولكل متطلب فيها تقييم Requirement Assessment بنتيجة وحالة. وفي الواجهة العربية يسمى «التدقيقات»، وفي الـ API اسمه compliance-assessments.
4. الضابط المطبق Applied Control: ما تفعله الجهة فعلاً، مثل «مزامنة الوقت مع time.saso.gov.sa»، بمالك وحالة وتاريخ وتكلفة. وهذا هو الكائن الذي يربط الأطر، فالضابط المطبق الواحد يمكن أن يشير إليه متطلب في ECC ومتطلب في ISO في تدقيقين مختلفين.
5. الدليل Evidence: ملف أو رابط يثبت أن الضابط المطبق يعمل، مثل مخرج chronyc sources بتاريخ.

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

المتطلبات: ماذا يعمل وكم يستهلك؟

ملف docker-compose.yml في المستودع يشغل خمس خدمات افتراضياً، وخدمة سادسة اختيارية لبروتوكول MCP لمن يريد ربط مساعد ذكاء اصطناعي، والشكل التالي يبينها مع الذاكرة التي قسناها لكل منها بعد تحميل مكتبة ECC:

• caddy: الـ Reverse Proxy الذي يستقبل HTTPS بشهادة من سلطة شهادات داخلية، ويوجه /api/* إلى backend والباقي إلى frontend.
• frontend: الواجهة المكتوبة بـ SvelteKit وتعمل على Node.js، وهي ليست ملفات ثابتة فقط، وإنما سيرفر يجلب البيانات من الـ API قبل أن يرسل الصفحة، وهذا مهم عندما نصل إلى خطأ 500.
• backend: تطبيق Django مع gunicorn، وفيه كل المنطق والـ API، وقاعدة البيانات الافتراضية SQLite في مجلد ./db.
• huey: عامل المهام في الخلفية Background Worker، يستخدم صورة backend نفسها بأمر تشغيل مختلف.
• qdrant: قاعدة بيانات متجهات Vector Database لميزات البحث الدلالي والذكاء الاصطناعي.

وقسنا في التجربة أحجام الـ Images فكانت 3.7 GB لـ backend و2.11 GB لـ frontend و288 MB لـ qdrant، وبلغ مجلد قاعدة البيانات 171 MB بعد أول تشغيل، معظمها المكتبات المخزنة. وبالتالي فالسيرفر المناسب لفريق صغير فيه 4 GB من الذاكرة على الأقل و20 GB من القرص، وهذا أقل مما تحتاجه أغلب أدوات المراقبة التي شرحناها في المرحلة السابقة.

التثبيت خطوة خطوة

المستودع فيه سكربت docker-compose.sh يسحب الـ Images ويشغلها وينشئ المستخدم الأول، لكننا سوف نفعل خطواته يدوياً حتى نفهم كل خطوة، ونغير شيئين في ملف Compose الأصلي: نثبت رقم الإصدار بدل latest، ونحذف pull_policy: always الذي يسحب آخر نسخة عند كل تشغيل، والسبب أن أداة امتثال تتغير نسختها دون قرار منك تفسد فكرة التدقيق نفسها. أولاً ننزل الملف من الإصدار المحدد:

mkdir ciso-assistant && cd ciso-assistant
curl -sL -o docker-compose.yml \
  https://raw.githubusercontent.com/intuitem/ciso-assistant-community/v4.1.5/docker-compose.yml
sed -i -e 's/:latest/:v4.1.5/' -e '/pull_policy: always/d' docker-compose.yml
grep -n "image:" docker-compose.yml

والمخرج سوف يكون كما يلي:

4:    image: ghcr.io/intuitem/ciso-assistant-community/backend:v4.1.5
36:    image: ghcr.io/intuitem/ciso-assistant-community/backend:v4.1.5
75:    image: ghcr.io/intuitem/ciso-assistant-community/frontend:v4.1.5
90:    image: qdrant/qdrant:v1.19.1
101:    image: ghcr.io/intuitem/ciso-assistant-community/mcp:v4.1.5
133:    image: caddy:2.11.4

في المخرج أعلاه لاحظ التالي:

• backend وhuey يستخدمان الـ Image نفسها، فالفرق في أمر التشغيل فقط.
• كل الـ Images تحت المسار ciso-assistant-community، أي النسخة المجتمعية بترخيص AGPLv3.
• خدمة mcp في السطر 101 عليها Profile اسمه mcp، فلا تعمل إلا إذا طلبتها، ولن نحتاجها.

بعد ذلك ننشئ مجلد قاعدة البيانات ونشغل الخدمات:

mkdir -p db
docker compose up -d

ثم ننتظر حتى يصبح backend بحالة healthy، وننشئ المستخدم الأول بأمر Django نفسه الذي يستخدمه السكربت، مع كلمة مرور قوية:

docker compose exec -e [email protected] \
  -e DJANGO_SUPERUSER_PASSWORD="$(openssl rand -base64 18)" \
  backend python manage.py createsuperuser --noinput

وآخر سطر في المخرج سوف يكون Superuser created successfully.، ولاحظ أن كلمة المرور في هذا الأمر لا تظهر لك، فإما أن تحفظها في متغير قبل الأمر، أو أن تستخدم الأمر التفاعلي دون --noinput وتكتبها بنفسك. وبعد ذلك تفتح https://localhost:8443 وتقبل الشهادة الداخلية، أو تضع الأداة خلف الـ Reverse Proxy الذي تستخدمه بشهادة حقيقية كما شرحنا في تثبيت Caddy.

ثلاث مشكلات واجهناها، وما تعلمناه منها

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

المشكلة الأولى: أول تشغيل استغرق 59 دقيقة

يقول ملف الإعداد في المستودع إن أول تهيئة قد تستغرق حتى دقيقتين. وفي تجربتنا بدأ backend الساعة 20:18:55 بتوقيت UTC، وأصبح healthy الساعة 21:18:12، أي بعد نحو 59 دقيقة. وعندما قرأنا السجل وجدنا أن الوقت ذهب في مرحلتين: الأولى تطبيق 404 من ترحيلات قاعدة البيانات Migrations واستغرقت نحو 33 دقيقة، والثانية تخزين 362 مكتبة في قاعدة البيانات واحدة بعد الأخرى، وكان السجل يطبع لكل منها سطراً مثل التالي:

[info     ] Successfully stored library    [library.management.commands.storelibraries] ciso_assistant_url=https://localhost:18891 filename=PosixPath('/code/library/libraries/3cf-v2.yaml') library=<StoredLibrary: 3CF-v2 - Cadre de Conformité Cyber France (3CF) pour l'aviation civile - v2>

والفرق الكبير عن الدقيقتين له سببان في بيئتنا: الأول أن قاعدة البيانات SQLite في مجلد ./db المربوط Bind Mount من قرص Windows عبر Docker Desktop، وكل كتابة صغيرة فيه تعبر طبقة مشاركة الملفات بين Windows والآلة الافتراضية، وSQLite يكتب كثيراً أثناء الترحيلات. والثاني أن الجهاز كان يشغل في الوقت نفسه مختبرات أخرى ثقيلة. وبالتالي لا تحكم على الأداة من سرعتها على جهاز مكتبك، وشغلها للاستخدام الحقيقي على سيرفر Linux، فهناك يكون المجلد على نظام الملفات نفسه.

والنتيجة الجانبية لهذا البطء أهم من البطء نفسه: فحص الصحة Health Check في ملف Compose ينتظر 150 ثانية ثم يحاول 30 مرة كل 10 ثوان، أي نحو سبع دقائق ونصف، وبعدها يعلن أن backend unhealthy، فيرفض Compose تشغيل الخدمات التي تعتمد عليه، وكان آخر سطر في مخرج docker compose up -d كما يلي:

dependency failed to start: container scg-ca-backend is unhealthy

وظلت frontend وhuey وcaddy بحالة Created دون تشغيل، مع أن backend نفسه كان يعمل ويكمل الترحيلات. والحل بسيط عندما تفهم السبب: انتظر حتى ينتهي backend ويصبح healthy، فحالة الصحة تعود سليمة عندما ينجح أول فحص، ثم شغل docker compose up -d مرة ثانية فتعمل البقية. ولا تقم بحذف المجلد db وإعادة المحاولة كما يفعل كثيرون، لأنك بذلك تبدأ الترحيلات من الصفر.

المشكلة الثانية: غيرنا المنفذ فلم يجب شيء

الملف الأصلي ينشر الأداة على https://localhost:8443، ولأن المنفذ مستخدم عندنا غيرناه إلى منفذ آخر في سطر ports، وغيرنا المتغير CISO_ASSISTANT_URL إلى العنوان الجديد، فأعطى curl الرمز 000، أي أن الاتصال لم يتم أصلاً. والسبب في أمر تشغيل caddy نفسه، فهو يكتب ملف Caddyfile من المتغير، وCISO_ASSISTANT_URL يحمل المنفذ، فيستمع caddy داخل الـ Container على المنفذ الجديد، بينما سطر ports ما زال يوجه إلى 8443. والقاعدة: إذا غيرت المنفذ فغيره في ثلاثة أماكن معاً، المتغير في backend وhuey، والعنوان المكشوف في frontend PUBLIC_BACKEND_API_EXPOSED_URL، وسطر ports بحيث يكون المنفذ داخل الـ Container هو نفسه المنفذ في العنوان. وبعد التصحيح أعطى الطلب نفسه 302 إلى صفحة الدخول، وأعطى /api/build/ الرد التالي:

{"detail":"Authentication credentials were not provided."}

وهذا الرد علامة جيدة رغم أنه رفض، لأنه يعني أن الطلب وصل إلى Django مروراً بـ caddy، وأن الـ API تطلب المصادقة كما يجب.

المشكلة الثالثة: صفحة التدقيق تعطي خطأ 500

بعد أن أنشأنا التدقيق وفتحنا صفحته الرئيسية ظهر «Error 500 Internal Error»، بينما صفحة الجدول وخطة العمل للتدقيق نفسه تعمل. وفي سجل frontend وجدنا TypeError: fetch failed وسببه SocketError: other side closed، أي أن backend أغلق الاتصال، وفي سجل backend وجدنا السبب:

[CRITICAL] WORKER TIMEOUT (pid:4213)
[ERROR] Worker (pid:4213) was sent SIGKILL! Perhaps out of memory?

وgunicorn يقتل العامل Worker الذي يتجاوز مهلته، والرسالة تقترح نفاد الذاكرة، لكن الذاكرة لم تكن المشكلة، فـ backend كان يستهلك أقل من 1 GiB، وإنما الصفحة الرئيسية للتدقيق تحسب الإحصاءات على كل المتطلبات الـ 232، وهذا على SQLite البطيء في بيئتنا تجاوز المهلة. وهذا هو الدرس الثالث: SQLite مناسب لتجربة أو لفريق صغير على قرص سريع، أما للاستخدام الفعلي فاستخدم PostgreSQL، وأداة make_config.py في مجلد config في المستودع تولد ملف Compose بقاعدة PostgreSQL مع caddy أو Traefik أو BunkerWeb، وقد شرحنا سبب تفضيل PostgreSQL في PostgreSQL لكل شيء.

تحميل مكتبة ECC-2:2024

من القائمة نذهب إلى المكتبات Libraries، ونبحث عن ECC، فتظهر نتيجتان للضوابط الأساسية: ecc-1 للإصدار الأول وecc-2-2024 للإصدار الحالي، فنختار الثاني ونضغط تحميل. واستغرق التحميل في تجربتنا 41 ثانية، ثم ظهر الإطار في صفحة الأطر Frameworks كما يلي:

والوصف في الصورة يقول 4 مكونات و28 مكوناً فرعياً و108 ضوابط، وهو مطابق لنص الهيئة. لكن عندما أنشأنا التدقيق كان عدد المتطلبات القابلة للتقييم 176، والعدد الكلي 232، فمن أين جاء الفرق؟ والإجابة في طريقة بناء المكتبة: كل مكون أساسي (4) وكل مكون فرعي (28) عقدة للتنظيم لا تقيم، والضابط الذي له ضوابط فرعية، مثل 2-2-3 الذي تحته 2-2-3-1 إلى 2-2-3-5، عقدة لا تقيم أيضاً، ويقيم كل ضابط فرعي وحده، وفي النص 24 ضابطاً من هذا النوع. والحساب: 108 ضوابط ناقص 24 ضابطاً له فروع يساوي 84، وزائد 92 ضابطاً فرعياً يساوي 176، وزائد العقد 4 و28 و24 يساوي 232. وهذا التصميم أدق من الجدول الذي كتبه مدير التقنية في القصة، فالضابط 2-2-3 في الجدول صف واحد، بينما هو في الحقيقة خمسة متطلبات قد تلتزم ببعضها ولا تلتزم ببعض.

إنشاء التدقيق وتقييم المتطلبات

قبل التدقيق ننشئ النطاق والمحيط: نطاق باسم الشركة، ومحيط باسم «Booking platform» ووصفه «منصة الحجز وسيرفراتها». ولاحظ أن كتابة المحيط بهذه الدقة مهمة، فإذا قال المحيط «الشركة كلها» فإن 4-2 الخاص بالحوسبة السحابية ينطبق على كل شيء، وإذا قال «منصة الحجز على سيرفرات الشركة» أصبح بعضه لا ينطبق. ثم ننشئ التدقيق باسم «ECC-2:2024 self-assessment Q4 2026» على هذا المحيط وبإطار ECC، فتنشئ الأداة تقييماً لكل متطلب بنتيجة «لم يقيم» Not assessed.

وفي المقال السابق أثبتنا ضابطين بمخرج حقيقي، وفي هذه التجربة نقيم ستة متطلبات تمثل الحالات كلها، والشكل التالي هو وضع الجدول Table Mode بعد التقييم:

والتقييمات الستة كما يلي، مع سبب كل نتيجة:

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

• النتيجة Result: هل الجهة ملتزمة بالمتطلب؟ وقيمها: لم يقيم، وغير ملتزم، وملتزم جزئياً، وملتزم، ولا ينطبق.
• الحالة Status: أين وصل العمل على تقييم هذا المتطلب؟ وقيمها: للقيام به To do، وقيد التقدم، وقيد المراجعة، وتم Done. فالمتطلب قد تكون نتيجته «غير ملتزم» وحالته «تم»، أي أننا انتهينا من تقييمه ووجدناه غير ملتزم.
• النتيجة الموسعة Extended result: لغة المدقق في التصنيف، مثل عدم مطابقة كبرى Major Nonconformity أو صغرى، وملاحظة، وفرصة للتحسين، وممارسة جيدة، وهي مفيدة عندما يستخدم التدقيق الداخلي الأداة نفسها.

وأيضاً لاحظ أن «لا ينطبق» ليست زراً تضغطه لتتخلص من متطلب صعب، فقد ذكرنا في مقال ECC أن الوثيقة تقبل عدم الانطباق بشرط وجود سبب حقيقي، لذلك اكتب السبب في حقل الملاحظة Observation تحت المتطلب، لأن المقيم سوف يسأل عنه.

الضوابط المطبقة والأدلة وخطة العمل

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

• AC-TIME-01 مزامنة الوقت مع time.saso.gov.sa، بحالة نشط Active، ودليله مخرج chronyc sources -v بتاريخ 25 أكتوبر 2026.
• AC-LOG-05 الاحتفاظ بسجلات Loki 8760 ساعة، بحالة نشط، ودليله مخرج /config.
• AC-LOG-03 Wazuh على كل السيرفرات الحساسة، بحالة قيد التقدم.
• AC-IAM-02 MFA لكل مدير في مزود الهوية، بحالة قيد التقدم.
• AC-BCK-03 اختبار استعادة ربع سنوي بمحضر موقع، بحالة للقيام به To do.

وكل هذه الضوابط تظهر معاً في خطة العمل Action Plan للتدقيق، والشكل التالي يبينها:

وفي الصورة لاحظ عمود «Matching requirements»، فهو العلاقة التي لا يعرفها الجدول: الضابط AC-IAM-02 يجيب عن 2-2-3-2، وإذا حملنا لاحقاً ISO/IEC 27001 وأنشأنا تدقيقاً عليه، فسوف نربط الضابط نفسه بالضابط 8.5 في الملحق Annex A، ويظهر في خطتي العمل معاً، وعندما ينتهي العمل عليه تتغير حالته في المكانين. والأعمدة الأخرى، مثل الأولوية والمالك وتاريخ الإنجاز ETA والجهد والتكلفة، فارغة عندنا، وفي الاستخدام الحقيقي هي ما يجعل خطة العمل خطة فعلاً، فالضابط الذي لا مالك له ولا تاريخ ليس خطة، وإنما أمنية.

والأداة فيها واجهة عربية، وقد بدلنا اللغة من قائمة المستخدم أسفل الشريط الجانبي فظهرت الصفحة نفسها كما يلي:

ولاحظ أن الترجمة تشمل القوائم والعناوين، أما أسماء الضوابط ونصوص المتطلبات فتبقى باللغة التي كتبت بها في المكتبة أو أدخلتها أنت، ومكتبة ECC-2:2024 في الأداة إنجليزية. وعددنا مفاتيح الترجمة في ملفات الواجهة للإصدار v4.1.5 فوجدنا 6,360 مفتاحاً في الملف العربي من أصل 7,339 في الملف الإنجليزي، أي نحو 87%، لذلك سوف تظهر لك بعض العبارات بالإنجليزية في الشاشات الأقل استخداماً.

التصدير: ماذا تعطي للمستشفى؟

العميل في القصة يريد تقييماً ذاتياً كل ربع سنة، والأداة تعطي أكثر من صيغة، فجربنا خمسة طلبات من الـ API نفسها التي تستخدمها أزرار التصدير في الواجهة، وكانت النتائج كما يلي:

والطلب الواحد منها يبدو كما يلي، والمتغير T هو رمز الدخول Access Token الذي سوف نشرح كيف تحصل عليه في قسم الـ API:

A=2c9a6a8e-2492-4aac-a4e9-8023d72941d9   # the audit id from its URL
curl -sk -H "Authorization: Token $T" -o action_plan.csv \
  "https://localhost:8443/api/compliance-assessments/$A/action_plan_csv/"
cat action_plan.csv

والمخرج سوف يكون كما يلي:

Name,Description,Category,CSF Function,Priority,Status,ETA,Expiry date,Effort,Impact,Cost,Covered requirements,Associated evidences,Evidence attachments
Quarterly restore test with signed record,,,,,To do,,,,,0.00,2-9-3-3,,
Wazuh on all critical servers,,,,,In progress,,,,,0.00,2-12-3-3,,
Central time sync with time.saso.gov.sa (chrony),,,,,Active,,,,,0.00,2-3-3-4,"chronyc sources -v, all servers, 2026-10-25",
Loki retention 8760h (12 months),,,,,Active,,,,,0.00,2-12-3-5,"Loki /config retention_period: 1y, 2026-10-25",
MFA for every administrator in the identity provider,,,,,In progress,,,,,0.00,2-2-3-2,,

في المخرج أعلاه لاحظ التالي:

• السطر الأول عناوين الأعمدة، ومنها «CSF Function»، أي أن الأداة تسمح بتصنيف كل ضابط بوظائف NIST CSF الست حتى لو كان التدقيق على ECC.
• كل سطر بعده ضابط مطبق واحد، وعمود «Covered requirements» يذكر رقم المتطلب في ECC، وعمود «Associated evidences» يذكر اسم الدليل، وهذان العمودان هما ما يحتاجه المستشفى ليعرف أين الدليل لكل متطلب.
• الضوابط غير المكتملة تظهر بحالتها To do وIn progress، وهذه هي خطة المعالجة التي يطلبها العميل مع التقييم.
• عمود Cost بقيمة 0.00 لأننا لم ندخل تكاليف، وعندما تدخلها تحسب الأداة ميزانية خطة العمل.
• الملف يبدأ بعلامة ترتيب البايتات BOM لـ UTF-8، لذلك يفتح في Excel بالعربية دون أن تظهر رموز غريبة إذا كتبت أسماء الضوابط بالعربية.

أما طلب global_score فأعاد "implementation_score":-1 و"scoring_enabled":false، والسبب أن التدقيق يعمل بنتائج نوعية فقط، أي ملتزم وغير ملتزم، وإذا أردت درجة رقمية فعليك تفعيل التقييم بالدرجات Scoring عند إنشاء التدقيق. والتقرير الأكثر فائدة للقراءة كان ملف export، وهو صفحة HTML واحدة فيها كل المتطلبات بحالاتها ونصوصها، تفتح في أي متصفح دون الأداة، والشكل التالي جزء منها:

ولاحظ في التقرير أن شريط التقدم يقول 97%، وهي نسبة المتطلبات التي لم تقيم بعد وليس نسبة الالتزام، وهذا يربك القارئ الذي لا يعرف الأداة، لذلك أرفق مع أي تقرير ترسله ملخصاً من صفحة واحدة بالأرقام التي تهم القارئ: كم ملتزماً وكم غير ملتزم، وما الخطة للأخيرة.

الأتمتة عبر الـ API

كل ما فعلناه في الواجهة متاح في الـ API، وهذا ما يجعل الأداة جزءاً من برنامج امتثال حقيقي، فالأدلة يجب أن تصل إليها آلياً من الأنظمة كما سوف نشرح في مقال جمع الأدلة. والدخول يمر بمكتبة django-allauth، والطلب التالي يعطيك رمز الدخول:

curl -sk -X POST https://localhost:8443/api/_allauth/app/v1/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"[email protected]","password":"..."}' > login.json

والرد JSON فيه "status": 200، وتحت meta ثلاثة مفاتيح هي is_authenticated وsession_token وaccess_token، والأخير هو الذي ترسله في ترويسة Authorization: Token مع كل طلب. وقد كتبنا عميلاً صغيراً بـ Python بالمكتبة القياسية فقط، واستخدمناه لتحميل المكتبة وإنشاء النطاق والمحيط والتدقيق والضوابط والأدلة:

# Minimal CISO Assistant API client: python ca.py METHOD PATH [json-body]
import json, ssl, sys, urllib.request, os
BASE = os.environ.get("CA_URL", "https://localhost:8443/api")
TOKEN = os.environ["CA_TOKEN"]
ctx = ssl.create_default_context(); ctx.check_hostname = False; ctx.verify_mode = ssl.CERT_NONE   # lab: Caddy internal CA
def call(method, path, body=None, raw=False):
    req = urllib.request.Request(BASE + path, method=method, data=json.dumps(body).encode() if body is not None else None,
                                 headers={"Authorization": f"Token {TOKEN}", "Content-Type": "application/json"})
    with urllib.request.urlopen(req, context=ctx, timeout=600) as r:
        data = r.read()
        return data if raw else (json.loads(data) if data else {})
if __name__ == "__main__":
    out = call(sys.argv[1], sys.argv[2], json.loads(sys.argv[3]) if len(sys.argv) > 3 else None)
    sys.stdout.buffer.write(json.dumps(out, ensure_ascii=False, indent=1).encode("utf8"))

وبه حملنا المكتبة بطلب واحد إلى معرفها في المكتبات المخزنة، وكان الرد {"status": "success"} بعد 41 ثانية:

python ca.py GET "/stored-libraries/?search=ecc"
python ca.py POST /stored-libraries/dcdf42a5-91ad-48ed-ade5-7148adf673bd/import/

ثم غيرنا نتيجة المتطلب بطلب PATCH إلى /requirement-assessments/<id>/ فيه النتيجة والحالة وقائمة الضوابط والأدلة، مثل {"result": "compliant", "status": "done", "applied_controls": [...], "evidences": [...]}. ولاحظ أمرين قبل أن تبني أتمتتك على هذا: الأول أن ضبط verify_mode = CERT_NONE مقبول في المختبر فقط لأن caddy يستخدم شهادة داخلية، وفي الإنتاج ضع الأداة خلف شهادة حقيقية أو ثق بشهادة سلطة caddy الداخلية. والثاني أن رمز الدخول هنا لمستخدم المدير نفسه، وللأتمتة الدائمة أنشئ حساب خدمة Service Account برمز وصول شخصي Personal Access Token بصلاحيات محدودة، والمسارات لذلك موجودة في الـ API باسم auth-tokens وservice-accounts.

النسخ الاحتياطي والتحديث

في النسخة المجتمعية مع SQLite كل البيانات في مجلد ./db، والأدلة المرفوعة كملفات تحفظ معها، لذلك أبسط نسخة احتياطية سليمة أن توقف الخدمتين اللتين تكتبان فيه، ثم تنسخه، ثم تعيدهما:

docker compose stop backend huey
tar -czf db-backup-$(date +%F).tgz db
docker compose start backend huey

وفي تجربتنا كان حجم المجلد 171 MB وأصبح الأرشيف المضغوط 23 MB. والسبب في الإيقاف أن نسخ ملف SQLite أثناء الكتابة فيه قد يعطيك نسخة غير متسقة لا تفتح. وفي الأداة نفسها مسار للنسخ الاحتياطي من الواجهة اسمه serdes/dump-db، لكنه في بيئتنا البطيئة تجاوز مهلة gunicorn البالغة 120 ثانية وأعاد خطأ 500، فاعتمدنا على نسخ المجلد. وإذا انتقلت إلى PostgreSQL فاستخدم pg_dump كما شرحنا في استعادة PostgreSQL لنقطة زمنية، وطبق على النسخة قاعدة 3-2-1 كما في النسخ الاحتياطي بقاعدة 3-2-1، فأداة الامتثال التي تفقد أدلتها تفقد سبب وجودها.

أما التحديث فلأن الإصدارات متقاربة جداً، لا تقم بالتحديث تلقائياً. خذ نسخة احتياطية، ثم غير رقم الإصدار في الملف إلى الإصدار الجديد بعد قراءة ملاحظاته، ثم شغل docker compose up -d، وانتظر الترحيلات الجديدة حتى يصبح backend سليماً. وتذكر أن تحديث مكتبة إطار، مثل نسخة جديدة من ECC، لا يغير التدقيقات القديمة تلقائياً، وفي الأداة قائمة للمكتبات التي لها تحديث «Update available»، والقرار في ترحيل التدقيق إلى النسخة الجديدة قرارك.

ماذا يحدث إذا...؟

• ماذا يحدث إذا حذفت المجلد db لتبدأ من جديد؟ تبدأ الترحيلات وتخزين المكتبات من الصفر، وفي بيئتنا كان هذا يعني ساعة كاملة، فلا تفعل ذلك لتصلح مشكلة لا علاقة لها بقاعدة البيانات.
• ماذا يحدث إذا أوقفت backend وأعدته؟ أوقفناه وأعدناه بعد النسخ الاحتياطي، فلم تتكرر الترحيلات لأنها مطبقة، وعاد backend بحالة healthy بعد نحو ثماني دقائق، من 22:52:55 إلى 23:00:40، وهذا أقل كثيراً من الساعة الأولى لكنه ليس لحظياً، فخطط نافذة الصيانة على هذا الأساس.
• ماذا يحدث إذا قيمت متطلباً «لا ينطبق» دون سبب؟ الأداة تقبله، والمقيم لا يقبله، لذلك اجعل كتابة السبب في الملاحظة قاعدة في فريقك.
• ماذا يحدث إذا ربطت الدليل بالمتطلب مباشرة وليس بالضابط المطبق؟ الأداة تسمح بذلك، لكنك تخسر إعادة استخدام الدليل في الأطر الأخرى، وهذا بالضبط ما كان يفعله جدول Excel.

قبل أن تضع فيها أدلة حقيقية: تأمين الأداة نفسها

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

• لا تنشرها على الإنترنت: الأداة يستخدمها عدد محدود من الناس، فاجعل الوصول إليها عبر الشبكة الخاصة الافتراضية VPN أو بوابة دخول، كما شرحنا في شبكة خاصة مع WireGuard، والسبب أن كل صفحة دخول مكشوفة هدف لتخمين كلمات المرور.
• الدخول الموحد SSO: تذكر صفحة المقارنة أن الدخول الموحد عبر SAML موجود في النسخة المجتمعية، فاربطها بمزود الهوية الذي تستخدمه، مثل authentik، حتى يغلق حساب الموظف المغادر في كل الأدوات معاً، وهذا نفسه ما يطلبه 1-9-5 في ECC.
• التحقق متعدد العوامل: الواجهة فيها مسار للتحقق الثاني بعد كلمة المرور، فإذا لم تستخدم SSO ففعله لكل مستخدم، وابدأ بحساب المدير الذي أنشأته بالأمر في التثبيت.
• الأدوار: في رد الـ API الذي رأيناه للتدقيق حقل اسمه field_visibility يحدد ما يراه المدقق Auditor وما يراه المجيب Respondent في كل حقل، أي أن الأداة مصممة ليجيب صاحب الضابط عن متطلباته دون أن يرى كل شيء، فاستخدم هذا بدل أن تعطي الجميع صلاحية المدير.
• الأدلة كروابط أم ملفات؟ في التجربة استخدمنا روابط إلى مخزن أدلة منفصل، والسبب أن الدليل الذي يحتوي إعدادات سيرفر أو قائمة مستخدمين يجب أن يحفظ حيث تتحكم في الوصول إليه وتحتفظ به المدة المطلوبة، والأداة تشير إليه. وإذا رفعت الملفات داخل الأداة فتذكر أنها أصبحت جزءاً من نسختها الاحتياطية ومن نطاق حمايتها.

وإلى جانب الامتثال، في النسخة المجتمعية وحدة لتقييم المخاطر Risk Assessment بمصفوفات مخاطر جاهزة من المكتبات، وتستطيع أن تربط سيناريو المخاطرة بالضوابط المطبقة نفسها التي ربطناها بالمتطلبات، فيصبح الضابط AC-IAM-02 مثلاً معالجة لمخاطرة «سرقة حساب مدير» ودليلاً على 2-2-3-2 في الوقت نفسه. وقد اخترنا أن نشرح سجل المخاطر بأداة مخصصة له في المقال التالي، لأن أداة واحدة لكل شيء ليست دائماً الأنسب، وسوف نقارن هناك بين الطريقتين.

كيف تعمل الأداة في فريق حقيقي؟

الأداة لا تصنع برنامج امتثال وحدها، وفي شركة منصة الحجز وزعنا العمل كما يلي، وهو توزيع يناسب أغلب الفرق الصغيرة:

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

وقد ربطت المادة 1-8 في ECC المراجعة الدورية بإدارة الأمن السيبراني والتدقيق المستقل وعرض النتائج على اللجنة الإشرافية، والأداة تسهل الأولى والثالثة، أما الاستقلالية فقرار تنظيمي، وسوف نعود إلى ذلك في مقال الاستعداد للتدقيق.

قائمة تحقق قبل أن تعتمد الأداة

الخلاصة

• جدول Excel يكفي لإطار واحد وشخص واحد، وعندما يصبح عندك أكثر من إطار أو أكثر من شخص تحتاج أداة تعرف العلاقات بين المتطلبات والضوابط والأدلة.
• CISO Assistant مفتوح المصدر بترخيص AGPLv3، ونسخته المجتمعية فيها ما يحتاجه فريق صغير، والنسخة Pro تبدأ من 39 يورو للمساهم شهرياً.
• يحتاج نحو 1.8 GiB من الذاكرة و6 GB للـ Images، وفيه 362 مكتبة منها ECC-2:2024 بـ 176 متطلباً قابلاً للتقييم.
• أول تشغيل في بيئتنا استغرق 59 دقيقة بسبب SQLite على مشاركة ملفات Docker Desktop، والدرس أن تشغله على Linux وبقاعدة PostgreSQL للاستخدام الحقيقي.
• الضابط المطبق هو قلب الأداة: يربط الأطر، ويحمل الأدلة، ويظهر في خطة العمل بمالكه وحالته.
• التصدير إلى CSV وExcel وWord وHTML يعطي العميل والمدقق ما يطلبه، والـ API تجعل وصول الأدلة آلياً.

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

دليلسجل المخاطر Risk Register مع SimpleRisk على سيرفركنبني سجل مخاطر حقيقياً بنموذج الهيئة ثم بأداة SimpleRisk، ونرى لماذا أعطت الأداة كل المخاطر مستوى واحداً، وكيف تكتب منهجية تعطي الأرقام معناها.دليلجمع أدلة الامتثال Evidence تلقائياً بدل لقطات الشاشةنبني جامع أدلة صغيراً يقرأ إعدادات السيرفرات عبر SSH ويحفظها بالهاش، ثم نجربه على تغيير مفاجئ ودليل معدل وجامع فقد صلاحيته بصمت.دليلISO 27001 بأدوات مفتوحة المصدر من المخاطر إلى التدقيقكيف تبني شركة صغيرة نظام ISO/IEC 27001 على ما بنته لضوابط ECC، من النطاق وسجل المخاطر إلى بيان قابلية التطبيق والتدقيق الداخلي.

سجل التحديثات

أكتوبر 2026: كتابة المقال وتجربة CISO Assistant Community v4.1.5 على Docker Desktop، مع مكتبة ECC-2:2024 وتدقيق تجريبي وتصدير خطة العمل والتقارير.