إنتقل إلى المحتوى الرئيسي

التشفير

هذه الصفحة تشرح المبادئ الأمنية الحالية لحماية البيانات في شام باص. المرجع التنفيذي النهائي يبقى في الكود، الترحيلات، وإعدادات النشر الفعلية.

ما الذي نحميه؟​

  • البيانات أثناء النقل بين العميل والخادم
  • الجلسات والرموز الحساسة
  • البيانات المخزنة محلياً على الموبايل
  • البيانات التشغيلية والإدارية داخل قاعدة البيانات

أثناء النقل​

HTTPS / TLS​

كل القنوات المنشورة يجب أن تعمل عبر HTTPS. أي مثال إعداد هنا هو مثال مفاهيمي فقط، وليس نسخة تشغيل جاهزة.

HSTS​

يجب تفعيل HSTS على النطاقات المنشورة عندما تكون البيئة جاهزة لذلك.

موبايل وCertificate Pinning​

يدعم مسار الجوال تمرير بصمات الشهادات عبر إعدادات البناء الرسمية عندما يكون ذلك مطلوباً. لا تُخزن البصمات الحقيقية في الوثائق.

أثناء التخزين​

قاعدة البيانات​

تعتمد المنصة على Supabase/PostgreSQL مع:

  • تشفير على مستوى التخزين
  • نسخ احتياطية محمية
  • اتصالات مشفرة
  • سياسات RLS لعزل الشركات والبيانات

التخزين المحلي في الجوال​

الرموز والبيانات الحساسة يجب أن تستخدم التخزين الآمن المناسب للنظام، مثل:

  • iOS Keychain
  • Android Keystore / Encrypted Shared Preferences

التخزين المحلي في Flutter Web​

تستخدم نسختا العميل والسائق flutter_secure_storage مع Web Crypto ومفتاح عام خاص بكل تطبيق على أصل HTTPS. تحفظ مفاتيح Hive المشفرة بصورة origin-bound وتعيد استخدامها بعد إعادة التحميل؛ لا تخزن المنصة المفتاح كنص صريح ولا تولّد مفتاح جلسة جديداً ثم تحذف IndexedDB عند كل زيارة.

لكل تطبيق namespace ويب إصداري مستقل (shambus_customer_web_v2_ وshambus_driver_web_v2_). لا يغيّر ذلك أسماء صناديق iOS أو Android، ويعزل بقايا صيغة الويب القديمة التي لم يعد مفتاحها المؤقت متاحاً من دون انتظار حذف قد تحجبه نافذة متصفح أقدم.

الاعتمادات وكلمات المرور​

العملاء​

المسار الأساسي للعملاء هو OTP عبر الهاتف، وليس كلمة مرور تقليدية للمستخدم النهائي.

الشركة والإدارة​

لوحات التشغيل والإدارة تستخدم اعتماداً قائماً على البريد الإلكتروني وكلمة المرور مع ضوابط إضافية بحسب السطح، مثل 2FA للحسابات الإدارية عند الحاجة.

أسرار TOTP للمشرف والسائق​

لا يخزن العمود totp_secret مفتاح Base32 بصورته الصريحة. تغلف مسارات التسجيل الجديدة السر بصيغة إصدارية totp:v1 باستخدام AES-256-GCM، مع IV عشوائي ووسم مصادقة وربط التشفير بمعرف المشرف أو السائق كـ associated data. يمنع الربط نقل ciphertext من حساب إلى حساب آخر.

  • يستخدم runtime المتغير TOTP_ENCRYPTION_KEY عند وجوده، وإلا يستخدم ENCRYPTION_MASTER_KEY؛ يجب ألا يقل المفتاح الفعلي عن 32 محرفاً في الإنتاج.
  • يقبل مسار القراءة أسرار Base32 القديمة مؤقتاً فقط لتوفير نشر متوافق، ثم يشغل النشر backfill-encrypt-totp-secrets.mjs بعد ترقية تطبيقي العميل والإدارة.
  • الـ backfill قابل لإعادة التشغيل ويحدث الصف بشرط بقاء القيمة القديمة نفسها، حتى لا يكتب فوق تسجيل 2FA متزامن.
  • يحتفظ seed الداخلي بالصيغة totp:v1 في التشغيلات اللاحقة ولا يعيدها إلى نص صريح. رموز الاسترداد تبقى HMAC hashes ولا تحفظ بصورتها القابلة للاستخدام.

الأسرار​

أمثلة الأسماء المسموح توثيقها:

JWT_SECRET=<managed-secret>
ENCRYPTION_MASTER_KEY=<managed-secret>
TOTP_ENCRYPTION_KEY=<optional-dedicated-managed-secret>
SUPABASE_SERVICE_ROLE_KEY=<managed-secret>
TWILIO_AUTH_TOKEN=<managed-secret>

لا يجوز وضع القيم الفعلية داخل هذه الوثائق.

البيانات الحساسة​

نوع البياناتالمبدأ
أرقام الهواتفتعامل كبيانات حساسة وتخضع لحد أدنى من الوصول
تذاكر الدعم والرسائلتحفظ ضمن الضوابط التشغيلية المناسبة
بيانات التحصيل النقديتحفظ وتزامن وفق متطلبات السطح التشغيلي
جلسات المصادقةتدار عبر cookies آمنة أو تخزين آمن محلياً بحسب السطح

Row Level Security​

RLS هي جزء أساسي من عزل البيانات في شام باص، خصوصاً لعزل الشركات متعددة المستأجرين.

ملاحظة

هذه الصفحة لا تعيد نشر سياسات SQL كاملة. المرجع النهائي لسياسات RLS هو سياسات RLS ومجلد الترحيلات.

قواعد عملية​

لا تفعل​

  • لا تنشر مفاتيح حقيقية في الوثائق
  • لا تخزن service-role keys في الواجهة الأمامية
  • لا تفترض أن مثالاً قديماً ما زال يطابق التنفيذ الحالي

افعل​

  • استخدم مدير أسرار في البيئات الرسمية
  • دوّر المفاتيح عند الحاجة
  • راقب السجلات والتنبيهات الأمنية
  • اربط تحديث الوثائق بأي تغيير أمني أو عقدي مهم

علاقة هذه الصفحة بباقي القسم​