الموقف الأمني التقني

تشفير البيانات

• تشفير في حالة السكون. تُحفَظ بيانات العملاء في Supabase Postgres، الذي يُشفِّر وحدة تخزين قاعدة البيانات في حالة السكون باستخدام AES-256.
• تشفير أثناء النقل. يُفرَض TLS 1.3 على كل نقطة نهاية عامة (موقع التسويق، والتطبيق، وواجهة API). وتُرفَض إصدارات TLS الأقدم عند حافة Cloudflare.
• النسخ الاحتياطية. نسخٌ احتياطية يومية تلقائية عبر Supabase، مُشفَّرة في حالة السكون بالمنظومة المفتاحية ذاتها (key envelope) المستخدمة لقاعدة البيانات الحيّة.

المصادقة

• المزود. Supabase Auth (GoTrue)، يعمل على مشروع Supabase الخاص بنا. وتُجزَّأ كلمات المرور (hash) بخوارزمية bcrypt قبل التخزين؛ ولا تُحفَظ أي كلمة مرور قَطّ كنصٍّ صريح.
• قواعد كلمة السر. بحدٍّ أدنى 8 محارف، ويجب أن تتضمّن حرفاً واحداً ورقماً واحداً على الأقل. والحماية من كلمات المرور الشائعة عبر فحص k-anonymity من Have I Been Pwned مُفعّلة.
• الجلسات. رمز الوصول (access token) هو JWT صالحٌ لمدة ساعة. ويُدوَّر رمز التجديد (refresh token) عند الاستخدام — إذ يمكن استخدامه مرة واحدة فقط، ما يحدّ من نطاق الضرر عند تسرّب الرمز.
• OAuth على مصادر البيانات. يتّصل كل تكامل مع طرفٍ ثالث (AppsFlyer، Google Ads، Meta Ads، RevenueCat، Stripe، Iyzico) عبر OAuth. ولا نرى كلمات مرور حسابات مصادرك ولا نخزّنها ولا نسجّلها قَطّ.

التفويض

• Row Level Security على كل جدول. Supabase RLS مُفعَّل عبر المخطّط (schema) بأكمله. ولا يوجد جدول يستطيع فيه مستخدمٌ مُصادَقٌ عليه قراءة أو كتابة صفٍّ لا يخصّ مؤسسته.
• سياسات بنطاق المنظمة. تُطابِق سياسات RLS قيمة `organization_id` في كل عملية قراءة وكتابة. ويحمل JWT الخاص بالمستخدم قيمة `organization_id` الخاصة به؛ وتفرض قاعدة البيانات ذلك.
• لا تجاوز لصلاحية service-role من JWT المستخدم النهائي. مفتاح service-role محفوظٌ فقط في workers موثوقة على جانب الخادم، ولا يُكشَف قَطّ للمتصفح أو لأي JWT صادرٍ للمستخدم. ولا تستطيع طلبات المستخدم النهائي التصعيد إلى صلاحية service-role.

مفاتيح API والأسرار

• التخزين. تُخزَّن جميع مفاتيح API الخاصة بأطرافٍ ثالثة (Anthropic، Google Ads، Meta Ads، AppsFlyer، RevenueCat، Stripe، Iyzico) في environment variables — عبر secret bindings في Cloudflare Workers لواجهة التسويق، وفي مخزن الأسرار الخلفي (backend secret store) الخاص بنا للتطبيق.
• لا سجلّات. لا تُكتَب مفاتيح API قَطّ في سجلّات التطبيق، ولا تُدرَج في رسائل الأخطاء، ولا تُضمَّن في الـURLs.
• التدوير. تُدوَّر المفاتيح دورياً. وأي تعرّضٍ مُشتبهٍ به يستدعي تدويراً فورياً خارج الدورة المعتادة.

موقع البيانات

تُخزَّن بيانات العملاء افتراضياً في منطقة الاتحاد الأوروبي لدى Supabase (فرانكفورت). وللعملاء الحسّاسين تجاه PDPL (السعودية والإمارات) ممّن يحتاجون التخزين داخل المنطقة، يمكننا تهيئة مشروع Supabase في المنطقة المناسبة عند الطلب — وذلك جزءٌ من إجراءات تهيئة باقة Enterprise.

ولا ننقل بيانات العملاء بين المناطق دون مُلحقٍ صريح لاتفاقية معالجة البيانات يُسمّي المنطقة الجديدة.

تسجيل التدقيق

تُسجَّل كل عملية تجري داخل Madar وتمسّ بيانات العميل في سجلّ تدقيق (audit log). وتحمل الأثرَ ثلاثة جداول:

• `agent_activities` — كل إجراءٍ يقوم به أحد عملاء الذكاء الاصطناعي (Oracle، Forge، Sentinel، Curator، Scout، Drafter): user_id، organization_id، اسم العميل، الخطوة، المعاملات، النتيجة، timestamp.
• `audits` — كل فحصٍ شُغِّل، ومَن طلبه، وما مصادر البيانات التي استُوعبت، وما النتائج التي نتجت، ومتى.
• `briefings` — كل مُلخَّصٍ أسبوعي وشهري يُولَّد، ومَن استلمه، ومتى سُلِّم.

يمكننا توفير هذه الجداول لمؤسستك لمراجعة الامتثال عند الطلب. ولا نحذف سجلّات التدقيق بناءً على طلب العميل — إذ تُحفَظ طوال عمر الحساب إضافةً إلى نافذة الاحتفاظ القانونية المطلوبة.

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

هل اكتشفت شيئاً؟ راسِلنا على security@madarai.co بأكبر قدرٍ من التفاصيل يمكنك مشاركته — الـURL المتأثر، وخطوات إعادة الإظهار، والأثر الذي لاحظته.

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

ما لم نُنجزه بعد

لا تنفع ادّعاءات الأمن إلا إذا كانت صادقةً بشأن ما ينقص. وهذه هي القائمة الصريحة:

• لا اعتماد SOC 2. نعمل على SOC 2 Type II مع مدقّقٍ خارجي؛ ولا ندّعي الحصول على الاعتماد قبل توقيع التقرير. طالِع /trust لمعرفة الحالة الراهنة.
• لا اختبار اختراق من طرف ثالث. مُخطَّطٌ للربع الثالث من 2026، حين يصبح النظام متعدد العملاء مستقراً بما يكفي ليختبر pen-test سطح هجومٍ حقيقياً لا هدفاً متحرّكاً.
• لا برنامج bug bounty. مُخطَّطٌ بعد بلوغ 50 عميلاً، حين تتوفّر لدينا مساحة سطحٍ كافية وإيراداتٌ كافية لتمويل مكافآتٍ يأخذها الباحثون على محمل الجدّ. وحتى ذلك الحين، يظل الإبلاغ عن الثغرات عبر security@madarai.co هو السبيل الوحيد.
• لا نظام ISMS رسمي ولا توافق مع ISO 27001. ليس على خارطة الطريق قبل SOC 2. ولا ندّعي أي اعتمادٍ لم نكسبه.

إذا كانت أيٌّ من هذه الفجوات عائقاً أمام مراجعتك الأمنية، فتحدّث إلينا — إذ يمكننا عادةً مشاركة تفاصيل أكثر تحت اتفاقية عدم إفصاح (NDA) ممّا هو منشورٌ هنا.