الأمان في أرقام٣٦٠
كيف نحمي بيانات التجار والزوّار.
فيما يلي وصف بلغة واضحة لضوابط الأمان المطبَّقة فعليًّا في منصَّتنا — مأخوذ من الشيفرة البرمجيَّة، لا من الطموحات. ونفصل بين ما نملكه اليوم وما هو مُدرج في خارطة الطريق، لتتّخذ قرارك عن معرفة.
1. المصادقة والتحكّم في الوصول
- تجزئة كلمات المرور بخوارزميَّة bcrypt (معامل التكلفة 12) — لا تُحفظ كلمات المرور نصًّا صريحًا أبدًا، ولا يمكن عكس تجزئتها.
- مصادقة الجلسات عبر JWT، برموز وصول صالحة 15 دقيقة ورموز تجديد صالحة 7 أيام. وتُحفظ الرموز في ملفات تعريف ارتباط من نوع HttpOnly و Secure، فلا يمكن لـJavaScript في المتصفّح قراءتها أبدًا.
- قفل الحساب بعد تكرار محاولات تسجيل الدخول الفاشلة (بحدّ قابل للضبط).
- تحقّق اختياري بخطوتين (TOTP) لحسابات المسؤولين.
- تحكّم في الوصول قائم على الأدوار: المالك / المسؤول / المحرّر / المُشاهد، ويُطبَّق على كلّ مسار يتطلّب المصادقة عبر برمجيَّات وسيطة (middleware).
- تسجيل دخول موحَّد (SSO) بين المنصَّات عبر رموز JWT قصيرة العمر (60 ثانية) مع حماية من إعادة الإرسال — يُستخدم في لوحات تحكم التجار المضمَّنة على سلة وزد و Shopify و WordPress.
2. تشفير البيانات
- تُشفَّر جميع الرموز الحسّاسة الخاصَّة بالأطراف الخارجيَّة (رموز وصول OAuth، والمفاتيح السرّيَّة لواجهات API، وأسرار توقيع webhook) أثناء التخزين بمعيار AES-256-GCM. ولا تُحفظ مفاتيح التشفير إلّا في متغيّرات البيئة — لا في الشيفرة البرمجيَّة ولا في قاعدة البيانات أبدًا.
- فرض TLS 1.2 أو أحدث على كلّ نقطة نهاية خارجيَّة، وترويسات HSTS مضبوطة بقيمة max-age مدَّتها سنة واحدة.
- يُتحقَّق من مفاتيح API بمقارنتها بتجزئة SHA-256، فلا حاجة إلى المفتاح نفسه لمصادقة أيّ طلب.
- تُجزَّأ كلمات المرور لمرَّة واحدة في بوّابة طلبات البيانات (DSAR) قبل حفظها.
- تستخدم حقول Mongoose الحسّاسة الإعداد `select: false` افتراضيًّا — فلا تُعاد في الاستعلامات الافتراضيَّة أبدًا، وتتطلّب طلبًا صريحًا لإرجاعها.
3. تحصين الشبكة والتطبيق
- تطبّق البرمجيَّة الوسيطة Helmet سياسة أمان محتوى (Content Security Policy) صارمة، و X-Frame-Options، و Referrer-Policy، و Cross-Origin-Resource-Policy على كلّ استجابة.
- حماية من CSRF على كلّ نقطة نهاية تُغيّر الحالة، عبر رموز بنمط double-submit cookie.
- فرض قائمة سماح لـCORS — دون أيّ أصول مفتوحة (wildcard) على المسارات التي تتطلّب المصادقة.
- تحديد معدَّل الطلبات على كلّ نقطة نهاية عامَّة (لكلّ عنوان IP ولكلّ مفتاح API)، وفرض حدود الباقة على المسارات التي تتطلّب المصادقة.
- تعمل أداة فحص ملفات تعريف الارتباط داخل متصفّح Chromium معزول بلا واجهة (headless)، مع حماية من SSRF تحظر نطاقات IP الداخليَّة (10.x، 192.168.x، 169.254.x) قبل إرسال أيّ طلب HTTP.
- يحمل كلّ طلب معرّف X-Request-Id فريدًا، يمكن تتبّعه من البداية إلى النهاية عبر السجلات.
4. تقليل البيانات والاحتفاظ بها
- لا تُحفظ عناوين البريد الإلكتروني أو أرقام الهواتف بصيغتها الأصليَّة مع الأحداث المتتبَّعة — بل قيمها المُجزّأة بخوارزميَّة SHA-256 فقط، وتُستخدم لمطابقة الهويَّات.
- تحفظ أداة فحص ملفات تعريف الارتباط البيانات الوصفيَّة للملفات، ولا تحفظ أبدًا قيم الملفات من نطاقات الأطراف الخارجيَّة.
- تُحذف سجلات تدقيق قرارات التوجيه تلقائيًّا بعد 90 يومًا عبر فهارس TTL في MongoDB.
- حذف مبدئي لبيانات المستخدم: يضبط الحذف الحقل `deletedAt`، ثمّ تمحو مهمَّة مجدولة البيانات بعد انقضاء مدَّة الاحتفاظ النظاميَّة.
- لا يجلب الاسترجاع التلقائي لطلبات الوصول إلى البيانات الشخصيَّة (DSAR) إلّا البيانات الموجودة لدينا فعلًا، ولا نجمّع البيانات الشخصيَّة للزوّار أو نحتفظ بها بما يتجاوز ما سجّله التاجر صراحةً.
5. الموثوقيَّة والتشغيل
- طوابير BullMQ مدعومة بـRedis لتوصيل الأحداث، وإرسال webhooks، وتقييم الشرائح. وتنتقل المهامّ الفاشلة إلى طابور المهامّ المتعثّرة (dead-letter queue) لفحصها — فلا يضيع شيء بصمت.
- قواطع دائرة (circuit breakers) على التكاملات الصادرة: نقطة النهاية التي تفشل 5 مرّات متتالية تتوقّف 60 ثانية، ثمّ تُختبر بمحاولة واحدة — لحمايتنا وحماية المنصَّة المستقبِلة معًا.
- مقاييس Prometheus متاحة على /metrics: زمن استجابة الطلبات، وأطوال الطوابير، وعمر أقدم مهمَّة، وحالة قواطع الدائرة. ويعرض /health حالة كلّ مكوّن (قاعدة البيانات، و Redis، و Stripe) لأدوات مراقبة التشغيل.
- يستخدم توصيل webhooks توقيعات HMAC-SHA256 ليتمكّن المستقبِلون من التحقّق من صحَّتها. وتُعاد محاولة التوصيل الفاشل بفواصل زمنيَّة تتضاعف تدريجيًّا لمدَّة تصل إلى 24 ساعة.
- عزل البيئات: تستخدم بيئات الإنتاج / الاختبار المرحلي (staging) / التطوير قواعد بيانات، ونسخ Redis، وحسابات Stripe منفصلة.
6. التدقيق والمساءلة
- يُسجَّل كلّ إجراء إداري (إنشاء عميل، أو تحديث الإعدادات، أو مزامنة شريحة، أو حذف نطاق، أو تعديل قاعدة توجيه) في سجلّ تدقيق غير قابل للتعديل، مع منفّذ الإجراء، ونوعه، والمورد المعني، ووقته.
- تُسجَّل إجراءات أعضاء فرق الوكالات باسم عضو الفريق وباسم العميل الذي كان "يعمل بصفته" معًا — لتتبّع كامل للوصول المفوَّض.
- تُحفظ قرارات التوجيه (أيّ حدث أُرسل إلى أيّ منصَّة، وبأيّ حالة موافقة) في مجموعة RoutingDecision — ما يوفّر لكلّ حدث سجلّ تدقيق للامتثال قابلًا للإثبات.
- يمكن للمسؤولين الاستعلام في سجلات التدقيق، مع إمكانيَّة تصديرها بصيغة CSV.
- تُحفظ سجلات تدقيق إجراءات المشغّلين طوال عمر الحساب ولمدَّة خمس سنوات بعده، بما يتوافق مع المادَّة 33 من اللائحة التنفيذيَّة لنظام حماية البيانات الشخصيَّة في المملكة العربيَّة السعوديَّة (حفظ السجلات طوال مدَّة المعالجة ولمدَّة خمس سنوات من انتهائها). وترتبط مدَّة الاحتفاظ بإغلاق الحساب لا بعمر السجلّ — فتحديد مدَّة انتهاء ثابتة سيحذف السجلات الأولى لحساب لا يزال قائمًا بينما المعالجة التي توثّقها ما زالت جارية.
قيد التنفيذ / ضمن خارطة الطريق
ما يلي لم يُطبَّق بعد، ونصفه بصراحة كذلك. ونذكره هنا بدلًا من ادّعائه قبل أوانه.
SOC 2 Type II
قيد التنفيذ. صُمّمت الضوابط ومعظمها يعمل فعلًا، وتبدأ فترة التدقيق الرسمي حين نبلغ عدد العملاء الذي يبرّرها.
ISO 27001
ضمن خارطة الطريق. تتداخل مجموعة ضوابطه إلى حدّ كبير مع ما سيغطّيه SOC 2، وسيليه ISO 27001 بعد صدور تقرير SOC 2.
اختبارات الاختراق
نخطّط لاختبارات اختراق سنويَّة تُجريها جهة خارجيَّة. وستكون النتائج وتقارير الإصلاح متاحة عند الطلب بموجب اتفاقية معالجة البيانات (DPA).
الإبلاغ عن ثغرة أو طلب اتفاقية معالجة البيانات
هل تشتبه في مشكلة أمنيَّة؟ راسلنا على admin@arqam360.com. نردّ خلال يوم عمل واحد. ونتّبع مبدأ الإفصاح المنسَّق — لذا نرجو منحنا مهلة معقولة قبل الإفصاح العلني.
تحتاج إلى اتفاقية معالجة البيانات (DPA)؟ راسلنا على admin@arqam360.com — نوفّر البنود التعاقديَّة القياسيَّة للاتحاد الأوروبي (SCCs) / ما يعادلها في دول مجلس التعاون الخليجي.
نحدّث هذه الصفحة كلّما تغيّرت الضوابط التي تصفها. آخر مراجعة: 2026-04.