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

8.1 النظرة العامة والغرض

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

يتم الحفاظ على نظام إدارة أمن المعلومات (ISMS) لدى المزوّد من قبل قسم تقنية المعلومات، وهو مواءم مع ISO/IEC 27001:2022. ويتناول هذا الفصل الضوابط التقنية للأمن التي تكمل تدابير الخصوصية الموصوفة في الفصل 7 (حماية البيانات والخصوصية) وتدابير الأمن الداعمة للتشغيل الموصوفة في الفصل 4 (دعم الخدمة والعمليات).

تدمج DANAOS Web Enterprise آليات أمنية في كل طبقة من طبقات حزمة التطبيق، بدءاً من طبقة العرض (متصفح الويب) مروراً بطبقة التطبيق (خادم التطبيقات) وصولاً إلى طبقة البيانات (خادم قاعدة البيانات)، بما يضمن تطبيق السرية والسلامة والتوافر (مثلث C.I.A.) من طرف إلى طرف داخل البيئة السيادية الخاصة المخصصة لكل عميل.

8.2 النطاق

يغطي هذا الفصل ما يلي:

• (a) أمن تطبيق المنصة: المصادقة، والتفويض، وإدارة الجلسات، والتحقق من المدخلات، وممارسات الترميز الآمن المدمجة ضمن إطار DANAOS Web Framework.
• (b) أمن البنية التحتية: تقسيم الشبكة، وإعدادات الجدار الناري، واكتشاف التطفل، والحماية من هجمات DDoS، وضوابط Web Application Firewall (WAF) المطبقة على البيئة السيادية المستضافة على Azure الخاصة بكل عميل.
• (c) أمن قاعدة البيانات: التحكم في الوصول، والتشفير (أثناء التخزين وأثناء النقل)، وتسجيل التدقيق، وإدارة الامتيازات، ومراقبة الاتصالات لحالات قاعدة بيانات SQL Server.
• (d) الأمن التشغيلي: إدارة الثغرات، واختبار الاختراق، وإدارة التصحيحات، وتتبع التغييرات، والاستجابة للحوادث الأمنية (حوادث البيانات غير الشخصية؛ أما خروقات البيانات الشخصية فتحكمها §7.15).
• (e) أمن الشيفرة المصدرية: حماية الملكية الفكرية، ودورة حياة التطوير الآمن، والتحكم بالإصدارات القائم على Git، وممارسات مراجعة الشيفرة التي تحكم قاعدة الشيفرة الخاصة بالمزوّد.
• (f) التزامات السرية: تعهدات سرية متبادلة، وتصنيف المعلومات، وقيود الإفصاح، وأحكام استمرار السريان.

8.3 معايير وأطر الأمان

يُبنى برنامج الأمان لدى المزوّد على المعايير والأطر والإرشادات التالية:

ISO/IEC 27001:2022 NIST CSF 2.0 OWASP Top 10 (2021) CIS Azure Foundations Benchmark NIST SP 800-63B-4 Azure Well-Architected Framework

8.4 أمن التطبيق

تتضمن منصة DANAOS ProjectVIEW ERP آليات الأمان التالية على طبقة التطبيق لضمان سرية النظام وسلامته. تُفرض هذه الضوابط على كل بيئة لدى العميل، ويمكن لمسؤولي نظام العميل ضبطها عبر وحدة STY ‏(إدارة المستخدمين والأدوار).

8.4.1 ضوابط المصادقة

8.4.2 التفويض والتحكم في الوصول

تفرض وحدة إدارة المستخدمين والأدوار (STY) في المنصة ضوابط وصول دقيقة قائمة على الأدوار (RBAC) على مستويات متعددة:

• (a) على مستوى الوحدة: يُمنح المستخدمون أو يُحرمون من الوصول إلى وحدات كاملة (مثل PV_07 HRMS– Payroll، وPV_08 Accounting) بناءً على تعيين دورهم.
• (b) على مستوى الوظيفة: داخل الوحدة الواحدة، تُمنح الأذونات بشكل مستقل للوظائف الفردية (مثل إنشاء أمر شراء، اعتماد فاتورة، عرض الراتب).
• (c) على مستوى الحقل: يمكن إخفاء الحقول الحساسة داخل السجل (مثل مبلغ الراتب، والحساب البنكي، والهوية الوطنية) أو جعلها للقراءة فقط لأدوار محددة.
• (d) على مستوى السجل: تقيد أمان مستوى الصفوف إمكانية الرؤية بناءً على الهيكل التنظيمي (مثلًا، يرى مديرو المشاريع فقط المشاريع المعيّنة لهم؛ ويرى المديرون الإقليميون منطقتهم فقط).
• (e) فصل المهام: يمنع اكتشاف الأدوار المتعارضة أن يحمل مستخدم واحد أدوارًا تُنشئ تعارضات في فصل المهام (مثل منشئ طلب الشراء وصاحب سلطة الاعتماد). وتُنبّه وحدة STY المسؤولين إلى التعارضات المكتشفة وتفرض قيودًا قائمة على السياسة.
• (f) معرّفات مستخدمين فريدة: يُخصَّص لكل حساب مستخدم معرّف فريد. وتُحظر الحسابات المشتركة/العامة. ويمكن تتبع جميع الإجراءات إلى مستخدم فردي عبر سجل التدقيق.
• (g) الوصول البعيد المقيد: يتحكم مسؤولو النظام في الوصول البعيد لكل مستخدم عبر وحدة تحكم المسؤول؛ ويمكن السماح به أو سحبه في أي وقت.

8.4.3 أمان الجلسات

• (a) رموز الجلسة: تُنشأ رموز جلسة عشوائية تشفيريًا عند المصادقة. وتُربط الرموز بعنوان IP الخاص بالمستخدم وسلسلة وكيل المستخدم لمنع اختطاف الجلسة.
• (b) إبطال الجلسة: تُبطل الجلسات عند: تغيير كلمة المرور، أو تعليق الحساب، أو تسجيل الخروج الصريح، أو انتهاء مهلة الخمول.
• (c) التحكم في الجلسات المتزامنة: حدود قابلة للتكوين لعدد الجلسات النشطة المتزامنة لكل حساب مستخدم. الافتراضي: جلسة نشطة واحدة لكل مستخدم (سياسة آخر تسجيل دخول هو المعتمد).

8.4.4 التحقق من صحة المدخلات وترميز المخرجات

• (a) التحقق من جهة الخادم: تُتحقق جميع المدخلات المقدمة من المستخدم على جهة الخادم باستخدام التحقق القائم على القائمة البيضاء. ويُعد التحقق من جهة العميل تحسينًا في سهولة الاستخدام فقط، وليس أبدًا ضابطًا أمنيًا.
• (b) الاستعلامات المعلَّمة: تستخدم جميع تفاعلات قاعدة البيانات استعلامات معلّمة (تصريحات مُعدة مسبقًا) لمنع حقن SQL. ويُحظر إنشاء SQL ديناميكيًا من مدخلات المستخدم وفق معيار الترميز الآمن لدى المزوّد.
• (c) ترميز المخرجات: تُرمَّز جميع البيانات المعروضة في المتصفح بحسب السياق (ترميز HTML وJavaScript وURL وCSS حسب الاقتضاء) لمنع البرمجة النصية عبر المواقع (XSS).
• (d) سياسة أمان المحتوى (CSP): تتضمن رؤوس استجابة HTTP سياسة أمان محتوى صارمة للتخفيف من هجمات XSS وهجمات حقن البيانات.

8.5 أمان البنية التحتية

يُنشر مثيل ProjectVIEW ERP الخاص بكل عميل داخل بيئة سيادية خاصة مخصصة على Microsoft Azure. وتُطبَّق ضوابط أمان البنية التحتية الموضحة أدناه لكل مستأجر، وهي متوافقة مع معيار CIS Azure Foundations Benchmark ومع ركيزة الأمان في Azure Well-Architected.

8.5.1 أمان الشبكة

• (a) مجموعات أمان الشبكة (NSGs): تُحمى كل آلة افتراضية بواسطة NSGs التي توفر وظيفة جدار حماية حالته محفوظة مع قواعد سماح/منع صريحة. السياسة الافتراضية: منع جميع الاتصالات الواردة؛ والسماح فقط بمنافذ الخدمة المطلوبة.
• (b) جدار حماية تطبيقات الويب (WAF): يُنشر Azure WAF أمام طبقة التطبيق للحماية من تهديدات OWASP Top 10، بما في ذلك حقن SQL، وXSS، وCSRF، وهجمات تهريب الطلبات.
• (c) الحماية من DDoS: يتم تفعيل Azure DDoS Protection Standard لجميع بيئات العملاء، بما يوفر التخفيف من هجمات الحجم والبروتوكول وطبقة التطبيق مع الاكتشاف التلقائي والمعالجة المضمّنة.
• (d) تقسيم الشبكة: تُنشر طبقة البيانات وطبقة التطبيق وطبقة الإدارة في شبكات فرعية منفصلة مع التحكم في حركة المرور بين الطبقات عبر قواعد NSG. ولا يمكن الوصول إلى شبكة قاعدة البيانات مباشرة من الإنترنت.
• (e) VPN والاتصال الخاص: عندما يتطلب العميل اتصال موقع إلى موقع (مثل التكامل مع Active Directory المحلية)، يتم توفير Azure VPN Gateway أو ExpressRoute مع تشفير IPSec/IKEv2.
• (f) أمان DNS: تُستخدم مناطق Azure Private DNS لمنع تسريب البيانات القائم على DNS. وتُحمى سجلات DNS العامة باستخدام DNSSEC حيث يدعم ذلك المسجل.

8.5.2 أمان الحوسبة

• (a) تقسية نظام التشغيل: تعمل جميع الآلات الافتراضية بنظام Microsoft Windows Server 2022، بعد تقسيته وفق CIS Windows Server 2022 Benchmark. وتُعطّل الخدمات والمنافذ والميزات غير الضرورية.
• (b) إدارة التصحيحات: تُطبَّق التصحيحات الأمنية خلال: (i) اثنتين وسبعين (72) ساعة لثغرات Critical/High CVEs؛ (ii) ثلاثين (30) يومًا تقويميًا لثغرات Medium CVEs؛ (iii) نافذة الصيانة التالية لثغرات Low CVEs. وتُختبر التصحيحات في بيئة Staging قبل نشرها في الإنتاج.
• (c) مكافحة البرمجيات الخبيثة: يتم تفعيل حماية الأجهزة الطرفية السحابية الأصلية (Microsoft Defender for Cloud) على جميع الآلات الافتراضية مع الفحص الفوري، والتحليل السلوكي، والمعالجة التلقائية.
• (d) كشف التسلل القائم على المضيف: يراقب Azure Security Centre سلامة الملفات، وتنفيذ العمليات المشبوهة، واستدعاءات النظام الشاذة على جميع الآلات الافتراضية.

8.5.3 إدارة الهوية والأسرار

• (a) Azure Key Vault: تُخزن جميع المفاتيح التشفيرية والشهادات وسلاسل الاتصال وبيانات اعتماد الخدمة في Azure Key Vault مع التحكم في الوصول بواسطة Azure RBAC وسياسات الوصول إلى Key Vault.
• (b) الهويات المُدارة: تُستخدم هويات Azure المُدارة للمصادقة بين الخدمات حيثما أمكن، مما يلغي الحاجة إلى تخزين بيانات الاعتماد في إعدادات التطبيق.
• (c) تدوير الأسرار: تُفرض سياسات تدوير أسرار آلية لجميع بيانات اعتماد حسابات الخدمة ومفاتيح واجهات برمجة التطبيقات API. الحد الأقصى لفترة التدوير: تسعون (90) يومًا تقويميًا.

8.6 أمان قاعدة البيانات

تعمل طبقة البيانات في المنصة على Microsoft SQL Server 2022 (Standard or Enterprise Edition) المنشور على Microsoft Windows Server 2022. وتُطبَّق ضوابط الأمان الخاصة بقاعدة البيانات التالية، بما يتماشى مع CIS SQL Server 2022 Benchmark:

8.6.1 الوصول والمصادقة

• (a) مصادقة قاعدة البيانات: يستخدم SQL Server وضع مصادقة Windows Authentication ‏(متكاملًا مع Active Directory) كطريقة المصادقة الأساسية. ويتم تعطيل المصادقة ذات النمط المختلط ما لم تكن مطلوبة وموافقًا عليها صراحةً من العميل.
• (b) كلمات مرور التطبيق: تستخدم بيانات اعتماد قاعدة البيانات على مستوى التطبيق كلمات مرور قوية متوافقة مع سياسة تكوين كلمات المرور، وتُدوّر وفق جدول تدوير الأسرار (§8.5.3).
• (c) الحسابات الافتراضية: تؤمَّن جميع حسابات النظام الافتراضية (مثل ‘sa’) بصورة صحيحة من قِبل مسؤول قاعدة البيانات DBA: تُغيَّر كلمات المرور الافتراضية فور التزويد؛ وتُعطّل الحسابات الافتراضية غير الضرورية أو تُحذف.
• (d) التحكم في الاتصالات: تُتحكم الاتصالات إلى مثيلات قاعدة البيانات وتُراقب. ولا يجوز إنشاء الاتصالات إلا من قِبل خدمات طبقة التطبيق المصرح بها وموظفي DBA المعينين. وتُخزن سلاسل الاتصال في Azure Key Vault (§8.5.3).
• (e) إمكانية الاتصال: تقيّد ضوابط مستوى الشبكة إمكانية الاتصال بقاعدة البيانات على شبكة فرعية لطبقة التطبيق ونقاط نهاية الإدارة المصرح بها فقط. ويُحظر الاتصال المباشر من الإنترنت بقاعدة البيانات.

8.6.2 إدارة الصلاحيات

• (a) أقل الصلاحيات والأدوار: تُزود حسابات مستخدمي قاعدة البيانات بأقل الصلاحيات والأدوار اللازمة لوظيفتها. ويُفرض مبدأ أقل الصلاحيات ويُراجع دوريًا.
• (b) الصلاحيات النظامية: تُزال جميع الصلاحيات «النظامية» من حسابات المستخدمين ما لم تكن مطلوبة وموافقًا عليها صراحةً. وتتطلب العمليات ذات الصلاحيات حساب DBA منفصلًا ومخصصًا مع MFA.
• (c) فصل المهام: تُفصل صلاحيات إدارة قاعدة البيانات عن صلاحيات تطوير التطبيقات. ولا يملك المطورون وصولًا إلى قاعدة بيانات الإنتاج.
• (d) مراجعة الصلاحيات: مراجعة ربع سنوية لتعيينات صلاحيات قاعدة البيانات؛ وتُسحب الصلاحيات غير المستخدمة أو المفرطة. وتوثق نتائج المراجعة وتكون متاحة للتدقيق (§7.11).

8.6.3 التشفير

• (a) التشفير الشفاف للبيانات (TDE): يتم تفعيل TDE على جميع مثيلات قواعد البيانات في الإنتاج وStaging، بما يشفر ملفات البيانات وملفات السجل وtempdb باستخدام تشفير AES-256. وتُنسخ شهادات TDE احتياطيًا وتُخزن في Azure Key Vault.
• (b) تشفير النسخ الاحتياطية: تُشفر جميع النسخ الاحتياطية لقاعدة البيانات (الكاملة، والتفاضلية، وسجل المعاملات) باستخدام AES-256 مع مفاتيح تشفير خاصة بالعميل تُدار عبر Azure Key Vault.
• (c) التشفير على مستوى العمود: حيثما تتطلب سياسة تصنيف البيانات لدى العميل ذلك، يتوفر التشفير على مستوى العمود (Always Encrypted) للحقول عالية الحساسية (مثل الأرقام الوطنية وأرقام الحسابات البنكية).

8.6.4 التدقيق والسجلّات

• (a) سجل التدقيق: يلتقط SQL Server Audit: (i) جميع عمليات DDL ‏(تغييرات المخطط)؛ (ii) نشاط المستخدمين ذوي الصلاحيات؛ (iii) محاولات المصادقة الفاشلة؛ (iv) عمليات تصدير البيانات والنسخ الجماعي؛ (v) تغييرات الأذونات. وتُكتب سجلات التدقيق في مخزن مقاوم للعبث.
• (b) الاحتفاظ بالسجلات: تُحتفظ سجلات تدقيق قاعدة البيانات لمدة لا تقل عن اثني عشر (12) شهرًا على الخط المباشر وأربعة وعشرين (24) شهرًا في التخزين الأرشيفي. ويحقق الاحتفاظ المتطلبات التنظيمية بموجب GDPR وUAE PDPL والمعايير القطاعية المعمول بها.
• (c) تتبع التغييرات: يتم تفعيل SQL Server Change Tracking وChange Data Capture ‏(CDC) لتوفير جرد كامل لتعديلات البيانات لأغراض الامتثال والتدقيق.
• (d) الوصول البعيد لمسؤول قاعدة البيانات DBA: يُقيد إدارة قاعدة البيانات عن بُعد على أفراد محددين بالاسم عبر قنوات مشفرة مع مصادقة متعددة العوامل. وتُسجل جميع جلسات DBA مع سجل تدقيق كامل على مستوى الأوامر (§7.8.3).

8.7 إدارة الثغرات

يُشغّل المزوّد برنامجًا مستمرًا لإدارة الثغرات متوافقًا مع وظيفتي NIST CSF Identify ‏(ID.RA) وProtect ‏(PR.IP):

8.7.1 جدول التقييم

8.7.2 جداول زمن المعالجة

الثغرات من نوع Zero-day: بالنسبة للثغرات من نوع Zero-day المستغلة فعليًا والتي تؤثر في حزمة تقنيات المنصة، يلتزم المزوّد بتطبيق إجراءات تخفيف طارئة (مثل قواعد WAF، والعزل الشبكي، والترقيع الافتراضي) خلال أربع وعشرين (24) ساعة، على أن يلي ذلك تصحيح دائم وفق اتفاقية مستوى الخدمة الخاصة بالمعالجة الحرجة.

8.8 المراقبة الأمنية والاستجابة للحوادث

8.8.1 المراقبة

يدير المزوّد قدرة مراقبة أمنية على مدار الساعة طوال أيام الأسبوع باستخدام المكونات التالية:

• (a) SIEM: يجمع نظام إدارة معلومات وأحداث الأمن السحابي الأصلي (Microsoft Sentinel) السجلات من جميع طبقات البنية التحتية والتطبيقات وقاعدة البيانات. وتحدد قواعد الارتباط وكشفات التعلم الآلي الأنماط الشاذة.
• (b) AIOps: توفر أدوات العمليات المدعومة بالذكاء الاصطناعي كشفًا تنبؤيًا للشذوذ في مقاييس الأداء وأنماط المصادقة وأحجام الوصول إلى البيانات، مما يتيح الاكتشاف المبكر للانحرافات ذات الصلة الأمنية قبل أن تتصاعد إلى حوادث.
• (c) معلومات التهديدات: يدمج SIEM موجزات معلومات التهديدات الآنية (Microsoft Threat Intelligence، ومؤشرات الاختراق IOC الخاصة بالقطاع) لاكتشاف أنماط الهجوم والمؤشرات المعروفة للاختراق.
• (d) تحليلات سلوك المستخدم والكيان (UEBA): تُنشأ ملفات سلوك أساسية للمستخدمين والحسابات الخدمية. وتؤدي الانحرافات (مثل مواقع تسجيل الدخول الشاذة، وأنماط الوصول غير المعتادة إلى البيانات، ومحاولات رفع الامتيازات) إلى تنبيهات تلقائية.

8.8.2 الاستجابة للحوادث الأمنية

تُدار الحوادث الأمنية التي لا تتضمن بيانات شخصية بموجب هذا القسم. وتخضع حالات خرق البيانات الشخصية للبند §7.15. وعندما يُصنَّف حادث لاحقًا على أنه يتضمن بيانات شخصية، تنطبق إجراءات الإخطار بالخرق في §7.15 إضافة إلى التدابير أدناه.

8.8.3 إخطار العميل

يُخطر المزوّد العميلَ بالحوادث الأمنية التي: (i) تؤدي إلى وصول فعلي أو مشتبه به غير مصرح به إلى بيانات العميل؛ (ii) تؤثر بصورة جوهرية في توافر المنصة أو سلامتها؛ أو

• (iii) تنطوي على تدخل جهات إنفاذ القانون المرتبط ببيئة العميل. ويكون الإخطار ضمن الجداول الزمنية المتوافقة مع شدة الحادث واتفاقيات مستوى خدمة الإخطار بالخرق المحددة في §7.15.1.

8.9 دورة حياة التطوير الآمن (SDLC)

يتبع المزوّد دورة SDLC آمنة متوافقة مع نموذج نضج ضمان البرمجيات الخاص بـ OWASP ‏(SAMM) ودورة تطوير الأمان من Microsoft ‏(SDL):

• (a) نمذجة التهديدات: تخضع الميزات الجديدة والتغييرات المهمة لنمذجة التهديدات أثناء التصميم. وتُستخدم منهجية STRIDE لتحديد التهديدات؛ ويُستخدم DREAD لترتيب المخاطر حسب الأولوية.
• (b) معايير الترميز الآمن: يتبع المطورون معيار الترميز الآمن لدى المزوّد (المستند إلى OWASP Secure Coding Practices) ويغطي التحقق من المدخلات، وترميز المخرجات، والمصادقة، وإدارة الجلسات، ومعالجة الأخطاء، والتشفير.
• (c) الاختبار الأمني الثابت للتطبيقات (SAST): يُشغَّل SAST الآلي مع كل التزامات الشفرة. وتمنع نتائج الشدة العالية/الحرجة عملية البناء حتى يتم حلها.
• (d) الاختبار الأمني الديناميكي للتطبيقات (DAST): يُنفَّذ DAST على بيئة Staging قبل كل نشر في الإنتاج. ويستهدف الفحص ضوابط OWASP Top 10 ومستوى ASVS 2.
• (e) تحليل مكوّنات البرمجيات (SCA): يتم فحص جميع التبعيات التابعة لجهات خارجية بحثاً عن الثغرات المعروفة (CVEs) والامتثال للترخيص في كل عملية بناء. تُحظر المكوّنات التي تحتوي على CVEs حرجة/عالية غير مصححة.
• (f) مراجعة الشفرة: تتطلب جميع التغييرات على شفرة الإنتاج مراجعة الأقران والموافقة قبل دمجها في فرع Master. أما التغييرات الحساسة أمنياً، مثل المصادقة والتشفير ومنطق التحكم في الوصول، فتتطلب مراجعة من مسؤول أمن معيّن.
• (g) التحكم في الإصدارات: نظام تحكم في الإصدارات قائم على Git مع نموذج الفروع Master/Client/Working (§4.7). تُوقّع جميع عمليات الالتزام رقمياً ويمكن تتبعها إلى المطورين الأفراد. ويُحظر فرض الدفع إلى Master.

8.10 حماية الشفرة المصدرية

تشكل الشفرة المصدرية للمورّد ملكية فكرية خاصة وتخضع للحمايات التالية:

• (a) تقييد الوصول: لا يمكن الوصول إلى مستودعات الشفرة المصدرية إلا لموظفي تطوير المورّد المخولين. ولا يملك موظفو العميل حق الوصول إلى الشفرة المصدرية ما لم يتم إبرام اتفاق منفصل لحفظ الشفرة المصدرية لدى طرف ثالث.
• (b) حفظ الشفرة المصدرية لدى طرف ثالث: بناءً على طلب العميل، يبرم المورّد اتفاقية لحفظ الشفرة المصدرية لدى جهة إيداع طرف ثالث ذات سمعة جيدة. وتشمل شروط الإفراج عادةً: إعسار المورّد، أو خرقاً جوهرياً لهذا الإطار، أو إيقاف المنصة دون منتج بديل مناسب.
• (c) معمارية العميل الخفيف: تعمل المنصة كتطبيق ويب عميل خفيف. ولا يتم توزيع أي شفرة مصدرية خاصة أو ملفات ثنائية مترجمة أو منطق تطبيق إلى أجهزة العميل. وتتم جميع معالجة التطبيق على جانب الخادم ضمن البيئة السيادية الخاصة بالعميل.
• (d) الإخفاء: يتم تصغير JavaScript وCSS المقدمين إلى المتصفح وإخفاؤهما. ولا يتم إتاحة خرائط المصدر في بيئات الإنتاج.
• (e) لا التزام بمصدر مفتوح: يضمن المورّد أن استخدام مكوّنات مفتوحة المصدر لا ينشئ التزاماً بالكشف عن الشفرة المصدرية الخاصة به، على سبيل المثال في حالات تلوث رخصة copyleft. ويتم التحقق من جميع مكوّنات المصدر المفتوح من حيث توافق الترخيص قبل اعتمادها.

8.11 التزامات السرية

8.11.1 تصنيف المعلومات

تُصنَّف جميع المعلومات المتبادلة بين الطرفين وفقاً للنظام التالي:

8.11.2 التزامات السرية المتبادلة

يتعهد كل طرف للطرف الآخر بأنه:

• (a) يحافظ على سرية جميع المعلومات السرية الخاصة بالطرف المفصح، وألا يفصح عنها لأي طرف ثالث دون موافقة خطية مسبقة من الطرف المفصح.
• (b) يستخدم المعلومات السرية فقط لغرض تنفيذ التزاماته أو ممارسة حقوقه بموجب هذا الإطار.
• (c) يقصر الإفصاح عن المعلومات السرية على موظفيه أو وكلائه أو معالجيه الفرعيين الذين يحتاجون إلى معرفة المعلومات لأغراض هذا الإطار والذين يلتزمون بالتزامات سرية لا تقل تقييداً عما يرد هنا.
• (d) يطبق نفس درجة العناية لحماية المعلومات السرية الخاصة بالطرف المفصح كما يطبقها على معلوماته السرية، على ألا تقل في أي حال عن العناية المعقولة.
• (e) يخطر الطرف المفصح فوراً بأي إفصاح أو استخدام فعلي أو مشتبه به غير مصرح به للمعلومات السرية.

8.11.3 الاستثناءات

لا تنطبق التزامات السرية على المعلومات التي:

• (a) تكون متاحة للعامة أو تصبح كذلك دون أي خطأ من جانب الطرف المستلم.
• (b) كانت معروفة بالفعل للطرف المستلم وقت الإفصاح، كما تثبت السجلات المكتوبة.
• (c) يتم تطويرها بشكل مستقل من قبل الطرف المستلم دون الرجوع إلى المعلومات السرية.
• (d) يتم الحصول عليها قانونياً من طرف ثالث دون أي قيود على الإفصاح.
• (e) يقتضي القانون أو اللوائح أو أمر المحكمة المعمول بها الإفصاح عنها، شريطة أن يقدم الطرف المستلم إشعاراً كتابياً فورياً إلى الطرف المفصح (إلى الحد المسموح به قانوناً) ويتعاون في أي مسعى للحصول على معاملة وقائية.

8.11.4 الاستمرار

تظل التزامات السرية المنصوص عليها في هذا القسم سارية بعد إنهاء أو انتهاء هذا الإطار لمدة خمس (5) سنوات، باستثناء الأسرار التجارية، التي تتم حمايتها طالما بقيت أسراراً تجارية بموجب القانون الواجب التطبيق.

8.12 إزالة الوصول

8.12.1 إزالة الوصول إلى الأنظمة

عندما يتغير دور موظف لدى المورّد أو تنتهي خدمته، تتم إزالة جميع أذونات الوصول إلى الأنظمة خلال:

• (a) إنهاء غير طوعي أو وجود مخاوف أمنية: إلغاء فوري (خلال ساعة واحدة) لجميع بيانات اعتماد النظام، وإتاحة VPN، وأذونات Key Vault، والوصول إلى المنشآت المادية.
• (b) مغادرة مخططة: تُلغى صلاحية الوصول في آخر يوم عمل. وتُعاد جميع الأجهزة المملوكة للمورّد وتُمسح بياناتها.
• (c) تغيير الدور: يتم تعديل الوصول خلال يوم عمل واحد (1) بما يعكس متطلبات الصلاحيات للدور الجديد. وتزال الصلاحيات الزائدة من الدور السابق.

8.12.2 إزالة الوصول إلى التطبيق

عندما يتغير دور مستخدم نهائي لدى العميل أو يغادر مؤسسة العميل:

• (a) مسؤولية العميل: يكون مسؤول نظام العميل (أو Champion) مسؤولاً عن تعطيل حسابات المستخدمين أو تعديلها داخل وحدة STY.
• (b) دعم المورّد: عندما يحتاج العميل إلى مساعدة من المورّد، على سبيل المثال إلغاء التفعيل الجماعي أو الإغلاق الطارئ، فيُرفع طلب خدمة من الفئة P2 (§4.3) ويُعالج ضمن اتفاقية مستوى الخدمة المعمول بها.
• (c) اكتشاف الحسابات الخاملة: تُعلِّم المنصة الحسابات التي لا يظهر لها أي نشاط تسجيل دخول لأكثر من تسعين (90) يوماً تقويمياً. وتُبلَّغ الحسابات المعلمة إلى مسؤول العميل للمراجعة واحتمال التعطيل.

8.13 سجل العمليات

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

8.14 مخطط سير العمليات

يوضح المخطط التالي دورة حياة أمن المعلومات من تقييم المخاطر مروراً بالمراقبة المستمرة والاستجابة للحوادث.

① تقييم مخاطر ISMS → ② معمارية الأمن والضوابط → ③ التطوير والنشر الآمن

▼

④ إدارة الثغرات → ⑤ المراقبة المستمرة (SIEM / AIOps) → ⑥ التحكم في الوصول والمراجعات

▼

⑦ اكتشاف الحوادث والاستجابة لها → ⑧ مراجعة ما بعد الحادث والتحسين → ⑨ تدقيق الامتثال وإصدار الشهادات

حلقة مستمرة: تعود المرحلة ⑨ (التدقيق وإصدار الشهادات) لتغذي المرحلة ① (تقييم المخاطر) عبر دورة التحسين المستمر لنظام إدارة أمن المعلومات (خطط-نفذ-تحقق-اعمل). وتعمل المراحل ④–⑦ بصورة مستمرة مع عمليات فحص آلية أسبوعية ومراقبة SIEM في الوقت الفعلي. وتوفر اختبارات الاختراق السنوية وعمليات تدقيق الاعتماد ضماناً مستقلاً.