الأمان

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

وصف عملي لضوابط الأمان اللي بنشغّلها فعليًا اليوم — بدون ادّعاء شهادات، وبالتفاصيل اللي بيحتاجها مسؤول تقني عم يقيّمنا.

آخر تحديث: 15.09.2026

1. نظرة عامة

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

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

كيف بنعالج البيانات ولمين بنكون معالج أو متحكم، موضّح بـسياسة الخصوصية واتفاقية معالجة البيانات.

2. البنية التحتية

  • Vercel — استضافة التطبيق، الحوسبة بدون خوادم، شبكة الحافة، وجدولة المهام الدورية.
  • Neon — قاعدة PostgreSQL مُدارة. في قاعدة إنتاج واحدة على فرع واحد؛ ما في نسخ متفرقة من بياناتك ببيئات جانبية.
  • Cloudflare R2 — تخزين الملفات: مرفقات المحادثات، الرفوعات، والنسخ الاحتياطية الليلية لقاعدة البيانات.
  • Upstash — Redis لتحديد المعدل والأقفال والكاش القصير، وQStash كطابور مهام لإرسال الحملات والمزامنات. رسائل الطابور بتحمل معرّفات فقط، مو نصوص الرسائل.
  • GitHub Actions — بيشغّل مهمة النسخ الاحتياطي الليلية: pg_dump كل يوم الساعة 03:30 UTC إلى حاوية R2 خاصة فينا، والنسخ بتنحفظ 30 يوم وبعدها بتنحذف.

القائمة الكاملة للمزوّدين مع الغرض والموقع الجغرافي موجودة بصفحة المعالجين الفرعيين. المزوّدين بالولايات المتحدة والاتحاد الأوروبي؛ ما بندّعي مدينة مركز بيانات محددة.

3. التشفير

  • أثناء النقل: كل الاتصالات عبر TLS/HTTPS، مع HSTS عشان المتصفح ما يرجع لاتصال غير مشفّر حتى لو حاول.
  • عند التخزين: كل عمود سرّي — مفاتيح API للذكاء الاصطناعي، توكنات منصات المتاجر، بيانات اعتماد واتساب وMeta وX، وأسرار المصادقة الثنائية — بينشفّر بـAES-256-GCM قبل ما يوصل لقاعدة البيانات.
  • القيم المفكوكة ما بتنسجّل بأي log، وما بتنبعت للمتصفح أبدًا، وما بتطلع بتصدير الحساب (التصدير بيستثني بيانات الاعتماد المشفّرة صراحة).
  • كلمات المرور: مخزّنة كـ bcrypt hash. ما بنقدر نقرأ كلمة مرورك، وإعادة التعيين بتصير فقط عبر رابط بتوكن.
  • بيانات البطاقة: ما بتمر علينا أصلًا. Stripe بيحتفظ فيها، وإحنا بنخزّن حالة الاشتراك، آخر 4 أرقام، ونوع البطاقة فقط.

4. عزل بيانات كل تاجر

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

  • كل استعلام على قاعدة البيانات مقيّد بمعرّف مؤسستك ومتجرك. ما في مسار "عام" بيقرأ العملاء أو المحادثات أو الطلبات بدون هالقيد.
  • المتجر النشط (اللي بتختاره من اللوحة) بيتم التحقق منه من جديد على الخادم بكل طلب مقابل عضويتك الفعلية. قيمة الكوكي لحالها ما بتعطيك أي وصول.
  • الصلاحيات ما بتنقرأ من العميل أبدًا. أي شي بيبعته المتصفح عن دورك أو صلاحياتك بينتجاهل؛ الخادم بيقرر من سجل العضوية.
  • أدوات الوكيل كلها مقيّدة بالمتجر. أدوات الاسترجاع والإلغاء بتتحقق إنه الطلب فعلًا تابع للعميل اللي عم يطلب، واستئناف السلة المتروكة بيشتغل على سلة العميل نفسه فقط.
  • ما في تعلّم متقاطع: بيانات تاجر ما بتأثر أبدًا على وكيل تاجر تاني.

5. المصادقة

  • تسجيل الدخول بالبريد وكلمة المرور (bcrypt)، أو بحساب Google — وبهالحالة لازم يكون بريد حساب Google موثّقًا، وبينربط بنفس الحساب عندنا عبر البريد.
  • مصادقة ثنائية (TOTP) اختيارية مع رموز احتياطية بتستخدم مرة واحدة. بتفعّلها من /dashboard/settings/security. أسرار المصادقة الثنائية مخزّنة مشفّرة.
  • محاولات تسجيل الدخول ومحاولات رموز المصادقة الثنائية محدودة المعدل؛ التخمين المتكرر بينحجب.
  • الجلسات عبارة عن JWT بكوكي جلسة. الكوكيز اللي بنستخدمها كلها ضرورية للتشغيل ومذكورة بصفحة الكوكيز.
  • إعادة تعيين كلمة المرور، توثيق البريد، ودعوات الفريق كلها بتصير عبر روابط بتوكن.

6. الصلاحيات والتحكم بالوصول

  • الصلاحيات مبنية على RBAC بصيغة resource:action. كل مسار حساس بيفحص صلاحية محددة، وإذا الصلاحية مش ممنوحة صراحة الفحص بيرفض (fails closed) — ما في افتراض بالسماح.
  • المستويات القديمة (مالك، مدير، عضو) بتترجم لمجموعات صلاحيات، وبتقدر تعطي أعضاء فريقك أقل صلاحية بتكفيهم.
  • العضوية لازم تكون نشطة. العضو الموقوف ما بيقدر ينفّذ أي شي حتى لو كانت جلسته لسا صالحة.
  • الدعوات بتصير برابط بتوكن، ومالك المؤسسة هو اللي بيتحكم بمين جوّا.
  • أي تغيير بالصلاحيات بينسجّل بسجل التدقيق مع القيمة قبل وبعد.

7. أمان التطبيق

  • سياسة أمان المحتوى (CSP) مفروضة فعليًا، مو بوضع التقرير فقط، وX-Frame-Options: DENY عشان ما تنعرض اللوحة داخل iframe بأي موقع تاني (حماية من clickjacking).
  • التحقق من المدخلات: كل مدخل لأي API بيتحقق منه بمخطط Zod قبل ما يوصل لمنطق العمل.
  • الرفوعات: بتتحقق بقائمة MIME مسموحة، والامتداد، وفحص البايتات الفعلية للملف. المسموح: صور jpeg/png/gif/webp وملفات PDF.
  • توقيعات الـwebhooks: كل webhook داخل من Salla وZid وShopify وMeta (واتساب، إنستغرام، ماسنجر) وX وStripe وResend بيتحقق من توقيعه بـHMAC-SHA256 بمقارنة ثابتة الزمن. الطلب بدون توقيع أو بتوقيع مش مطابق بينرفض قبل أي معالجة.
  • رسائل طابور المهام (QStash) موقّعة ومتحقق منها؛ ما حدا بيقدر يحقن مهمة من برّا.
  • الحماية من حقن التعليمات (prompt injection): أي نص مصدره خارجي — وصف منتج، إجابة بقاعدة المعرفة، رسالة عميل — بينشال منه علامات الحقن، وبينحصر كمحتوى غير موثوق، والنموذج بينوجّه يتعامل معه كبيانات مو كأوامر. وفوق هيك، سقف اللي بيقدر النموذج يعمله محدود بالضوابط بالبند التالي.
  • عملنا مراجعة أمنية داخلية للتبعيات وما قبل الإطلاق. ما بندّعي اختبار اختراق خارجي أو شهادة.

8. ضوابط سلامة الذكاء الاصطناعي

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

  • مستويات استقلالية من 0 (يراقب ويسجّل ملاحظات فقط) إلى 4 (مستقل). الافتراضي المستوى 2: أي إجراء فيه مخاطرة بيروح لطابور موافقة بشرية.
  • سقوف صلبة (أقصى استرجاع تلقائي، أقصى نسبة خصم) بتتغلّب على المستوى: اللي فوق السقف بيروح للموافقة دائمًا. أي أداة بتصرف مال أو بتعطي خصم أو بتغيّر طلب بتمر على هالحارس.
  • اللي بينبعت للمزوّد بكل رد محدود: تعليمات النظام، آخر 12 رسالة بالمحادثة، وأقل سياق بتجيبه الأدوات — مو قاعدة البيانات كلها. الرد مسقوف بـ800 توكن وبحد أقصى 5 جولات أدوات.
  • مزوّدو النماذج (Anthropic، OpenAI، Google) بشروطهم التجارية ما بيدرّبوا على مدخلاتك أو مخرجاتك. وبتقدر تستخدم مفتاحك الخاص.
  • الوكيل المدير (Capi) بيحكي معك أنت فقط داخل اللوحة، وبيقترح بس؛ أي تنفيذ بيحتاج موافقة شخص. ما بيوصل أبدًا لعملائك.

الضبط من /dashboard/ai-agent، والموافقات من /dashboard/ai-agent/actions. التفاصيل الكاملة بصفحة سياسة الذكاء الاصطناعي.

9. المراقبة والسجلات

  • سجل التدقيق: العمليات الحساسة — التصديرات، تغييرات الصلاحيات، إرسال الحملات، الموافقات على إجراءات الوكيل، وتغييرات الإعدادات — بتنسجّل مع القيمة قبل وبعد. بيانات الاعتماد ما بتنسجّل أبدًا. السجل بينحفظ 12 شهر.
  • مراقبة الأخطاء عبر Sentry مع تعطيل إرسال البيانات الشخصية الافتراضية: بينبعت نوع الخطأ والمعرّفات فقط، مو نصوص الرسائل أو محتوى الطلبات.
  • شاشة صحة النظام بتعرض لنا حالة الطوابير والمزامنات والتكاملات عشان نلاحظ الخلل قبل ما توصلنا شكوى.
  • المهام الخلفية كل تشغيل إلها بينسجّل (بينحفظ 30 يوم). اللي بيفشل بعد إعادة المحاولة بيروح لطابور الرسائل الميتة (dead-letter) اللي بنراجعه، والمدخلات المحلولة بتنحفظ 90 يوم.
  • أحداث الـwebhooks الواردة بتنحفظ 30 يوم لأغراض التتبع وحل المشاكل.

10. تحديد المعدل ومكافحة الإساءة

  • محدّد المعدل بيشتغل على Redis، مع Postgres كبديل إذا Redis مش متاح. وإذا ما قدر يوصل لأي منهما، بيرفض بدل ما يسمح — ما بيفشل بوضع مفتوح أبدًا. سجلات الضربات بتنحفظ 7 أيام.
  • أقفال موزّعة بتمنع الإرسال المكرر والمزامنات المتوازية على نفس المتجر.
  • حدود الخطة بتنفرض على الخادم، واستهلاك الذكاء الاصطناعي بينقاس لكل متجر مع سقف إنفاق.
  • تقييم الجودة لرقم واتساب عند Meta بينراقب كل 6 ساعات؛ إذا نزل، الإرسال بيتباطأ أو بيتأجل لحماية رقمك.
  • كل إرسال تسويقي بيمر على بوابة موافقة (مشترك وغير محظور)، مع كشف كلمات إلغاء الاشتراك بالعربي والإنجليزي وروابط إلغاء بالبريد.

11. النسخ الاحتياطي واستمرارية الخدمة

  • نسخة احتياطية كاملة لقاعدة البيانات كل ليلة الساعة 03:30 UTC إلى حاوية R2 خاصة فينا، محفوظة 30 يوم ثم بتنحذف. يعني أي بيانات حذفتها بتغادر النسخ الاحتياطية خلال 30 يوم كحد أقصى.
  • سلسلة بدائل لمزوّدي النماذج: إذا مزوّد تعطّل، بينجرّب المزوّد التالي اللي ضبطته. وإذا كلهم فشلوا، المحادثة بتتحوّل لإنسان — ما بتنترك بصمت.
  • طوابير بإعادة محاولة: الإرسال والمزامنة بتمر عبر QStash مع إعادة محاولة، وطابور رسائل ميتة لكل اللي بيفشل نهائيًا. الإرسال المقيّد بالحدود بيتأجل، مو بينحذف.
  • ما بنقدّم ضمان توفّر تعاقدي (SLA) على الخطط القياسية؛ التفاصيل بـالشروط.

12. وصول فريقنا لبياناتك

  • فريقنا ما بيفتح بيانات متجرك بشكل روتيني. الوصول بيصير فقط بناءً على طلبك (تذكرة دعم) أو للتحقيق بحادثة، وبينسجّل.
  • أقل صلاحية ممكنة: بيانات اعتماد الإنتاج بإيد أقل عدد من الأشخاص، ومحفوظة كمتغيرات بيئة وأسرار CI — أبدًا بملفات متتبعة بمستودع الكود.
  • لأنه الأسرار المفكوكة ما بتظهر لا باللوغات ولا بالواجهة، حتى الموظف اللي عنده وصول ما بيقدر يشوف مفاتيح API أو التوكنات تبعك.

13. الإبلاغ عن الثغرات

إذا لقيت ثغرة أمنية، راسلنا على security@capiagent.com. يفضّل تضمّن:

  • الرابط أو المسار المتأثر، وخطوات إعادة الإنتاج.
  • الأثر المتوقع (شو بيقدر يعمل المهاجم).
  • اسمك إذا بتحب نذكرك بالشكر. لا ترفق بيانات مستخدمين آخرين — إذا وصلت لبيانات مش إلك بالصدفة، وقّف وبلّغنا.

شو بنلتزم فيه: بنأكّد استلام بلاغك خلال 5 أيام عمل كحد أقصى، وبنخليك على اطلاع لحد ما تنحل المشكلة.

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

ما في برنامج مكافآت مدفوع حاليًا. بنشكرك علنًا إذا بدك.

14. الاستجابة للحوادث

  1. التصنيف: بنحدد نطاق الحادثة بسرعة من اللوغات وسجل التدقيق ومراقبة الأخطاء — مين تأثر، وأي بيانات.
  2. الاحتواء: تدوير بيانات الاعتماد المتأثرة، إبطال الجلسات، حجب المصدر، وإيقاف المهمة أو القناة المتأثرة لحد ما ينعالج السبب.
  3. الإبلاغ: إذا تأكّد خرق لبيانات شخصية، بنبلّغ التجار المتأثرين بدون تأخير غير مبرر وخلال 72 ساعة كحد أقصى من التأكيد، عبر بريد الحساب وإشعار باللوحة، بالحقائق المعروفة وقتها: شو صار، أي بيانات، شو عملنا، وشو المطلوب منك. وبنكمّل المعلومات كل ما عرفنا أكثر.
  4. بعد الحادثة: تقرير مكتوب بالسبب الجذري والإجراءات التصحيحية للمتأثرين. وبما إنك المتحكم ببيانات عملائك، بنساعدك إذا احتجت تبلّغ جهتك الرقابية أو عملاءك، حسب اتفاقية معالجة البيانات.

15. المسؤولية المشتركة

إحنا بنأمّن المنصة والبنية التحتية والكود. بس جزء من أمان حسابك بإيدك أنت، وهاي الأشياء اللي بنتوقعها منك:

  • فعّل المصادقة الثنائية لكل أعضاء فريقك، مو بس لحساب المالك.
  • اعطِ الأدوار بمبدأ أقل صلاحية، واحذف اللي بيغادر الفريق فورًا.
  • حافظ على سرية مفاتيح API الخاصة فيك وبيانات دخول منصة متجرك وحساب Meta؛ إذا تسرّب مفتاح، بدّله فورًا.
  • اضبط سقوف الاستقلالية (أقصى خصم، أقصى استرجاع) وقواعد التصعيد قبل ما تشغّل الوكيل على قناة حقيقية، وراجع صفحة الموافقات بانتظام.
  • احصل على موافقة صريحة قبل أي إرسال تسويقي، واحترم إلغاء الاشتراك؛ راجع سياسة الاستخدام المقبول وسياسات القنوات.
  • راجع سجل التدقيق بشكل دوري، وبلّغنا فورًا على security@capiagent.com إذا شكيت بوصول غير مصرّح به.

16. الامتثال

ممارساتنا مبنية لتتوافق مع نظام حماية البيانات الشخصية السعودي (PDPL)، وقانون حماية البيانات الشخصية التركي (KVKK)، واللائحة الأوروبية (GDPR). الالتزامات التعاقدية — الأدوار، المعالجون الفرعيون، النقل الدولي بضمانات زي البنود التعاقدية القياسية، والمساعدة بطلبات أصحاب البيانات — موثّقة بـاتفاقية معالجة البيانات.

بصراحة: ما عندنا شهادة خارجية حاليًا (لا SOC 2 ولا ISO 27001). المراجعات اللي عملناها داخلية. إذا مشترياتك بتحتاج استبيان أمني، ابعته على security@capiagent.com وبنجاوب عليه بالحقائق نفسها المكتوبة هون.

وثائق ذات صلة: الخصوصية، المعالجون الفرعيون، حذف البيانات، كل الوثائق القانونية.

هالصفحة بتوصف ممارساتنا الأمنية الفعلية، وما بتشكّل استشارة قانونية. لأي سؤال أمني أو للإبلاغ عن ثغرة، راسلنا على security@capiagent.com.