منهج الأمان، لا شهادات مُدَّعاة

الأمان بالتصميم

الأمان جزء من تصميم كل نظام منذ اللحظة الأولى، لا طبقة تُضاف في النهاية. كل قرار معماري يُقيَّم من زاوية: من يملك الوصول، وماذا يمكنه فعله، وكيف يُسجَّل ذلك.

أقل الصلاحيات الكافية

كل مستخدم وكل تكامل تقني يحصل على أضيق نطاق صلاحيات يكفي لأداء دوره، لا أكثر. هذا ينطبق على المستخدمين البشريين وعلى صلاحيات التطبيقات المسجَّلة (application permissions) على حدٍّ سواء.

التحكم بالصلاحيات والفصل بين المهام

التحكم بالصلاحيات حسب الدور (RBAC) والفصل بين مهام الإنشاء والاعتماد (Maker/Checker) مبدآن أساسيان في كل نظام نبنيه، لا إضافة اختيارية.

قابلية التدقيق

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

الأسرار والتشفير

• الأسرار (مفاتيح الوصول، بيانات الاعتماد) تُقرأ من بيئة الخادم وقت التنفيذ فقط، ولا تظهر أبدًا في كود العميل أو المستودع البرمجي أو السجلات.
• التشفير يُطبَّق حيث يكون مناسبًا فنيًا للسياق (النقل والتخزين)، حسب متطلبات كل مشروع وبيئته.

التكامل الآمن والتحقق من المدخلات

كل مدخل من الزائر أو من نظام خارجي يُتحقَّق منه ويُطهَّر قبل معالجته — طول النص، الصيغة، والمحتوى — لمنع حقن الأوامر أو تلاعب الرؤوس (header injection) أو أي إدخال غير متوقَّع.

انضباط السجلات وفصل البيئات

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

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

التبعيات البرمجية (dependencies) تُراجَع بشكل دوري، ورؤوس الأمان (security headers) الأساسية مفعَّلة على المستوى الإنتاجي، مع خطة تدريجية ومختبَرة للانتقال من سياسات الإبلاغ فقط إلى سياسات مُلزَمة حيث ينطبق ذلك.

الاعتمادات البشرية

القرارات الحساسة — تقييد حساب، اعتماد استثناء، تغيير سقف — تمر عبر اعتماد بشري وفق السياسة المعتمدة للجهة، لا عبر تنفيذ آلي صامت.

بلاغات أمنية

للإبلاغ عن ثغرة أو مخاوف أمنية متعلقة بالموقع أو الحلول، يرجى التواصل عبر Mohanad.Alhassan@pas.qa. لا نطالب بأي بيانات حساسة أو سرية ضمن هذا البلاغ.