الأمان والتشفير
آخر تحديث: 20 أبريل 2026
مدرهم منصة مبنية للمنشآت السعودية التي تتعامل مع بيانات مالية منظمة — فواتير زاتكا، الرواتب، سجلات العملاء. هذه الصفحة توثّق بالتفصيل كيف نحمي هذه البيانات: ما هو مشفّر، وما ليس مشفّراً بعد. الشفافية أفضل من التسويق.
١. التشفير أثناء التخزين
بيانات الإنتاج تعمل على عنقود PostgreSQL 17 مُدار من DigitalOcean في فرانكفورت. التخزين الكتلي الأساسي مشفّر بـ AES-256 (LUKS) على مستوى المنظّم الافتراضي. النسخ الاحتياطية اليومية مشفّرة بنفس الطريقة ومخزّنة في DigitalOcean Spaces بتشفير AES-256 من جانب الخادم. المفاتيح تُدار من قبل DigitalOcean وتُبدَّل وفق جدولهم الاعتيادي — نحن لا نحتفظ بمفاتيح تشفير الأقراص.
٢. التشفير أثناء النقل
كل طلب إلى modarhem.com يُنهى عند Cloudflare عبر TLS 1.3 (الحد الأدنى TLS 1.2 للعملاء القديمة) مع HSTS مُفعّل. الحركة من Cloudflare إلى الخادم الأصلي تُعاد تشفيرها عبر nginx بشهادة Let's Encrypt. الخدمات الداخلية (API ↔ PostgreSQL، API ↔ Valkey، API ↔ MeiliSearch) تستمع على localhost أو على الواجهة الخاصة للـ VPC ولا تعبر الإنترنت العام إطلاقاً.
٣. تشفير الأسرار على مستوى التطبيق (AES-256-GCM)
الاعتمادات الحساسة والبيانات الشخصية المخزّنة في قاعدة البيانات — مفاتيح TOTP/المصادقة الثنائية، مفاتيح زاتكا الخاصة، رموز الوصول لواتساب الأعمال، مفاتيح API لشبكة البطاقات، أسرار توقيع الـ webhooks، أرقام IBAN البنكية (على الحسابات البنكية، سجلات الرواتب، وملفات الشركاء التابعين)، وأرقام الهوية الوطنية / الإقامة للموظفين — تُغلّف بـ AES-256-GCM قبل الإدخال باستخدام مفتاح مُخزّن في ملف بيئة الخادم (صلاحية 600، خارج شجرة git). كل نص مشفّر يحمل متّجه تهيئة عشوائي بطول 12 بايت ووسم مصادقة بطول 16 بايت. القيم تحمل بادئة "enc:" حتى نستطيع ترحيل أي نص صريح قديم بأمان.
٤. تجزئة كلمات المرور
كلمات مرور المستخدمين لا تُخزّن أبداً. نستخدم Better Auth مع scrypt كخوارزمية تجزئة — ذاكرة كثيفة، بطيئة، ومقاومة لهجمات GPU. الأملاح فردية لكل مستخدم بطول 16 بايت. التجزئة وحدها لا تكشف أي شيء مفيد لمهاجم يحصل على جدول المستخدمين.
٥. بيانات بطاقات الدفع
نحن لا نرى أرقام بطاقات عملائك أبداً. جميع مدفوعات الاشتراك و(عند التفعيل) دفع العملاء تُمرَّر عبر ميسّر، وهو مزوّد خدمة معتمد PCI-DSS Level 1. نخزّن فقط آخر 4 أرقام والعلامة التجارية لعرض الواجهة. لا رقم بطاقة كامل، لا CVV، لا تواريخ انتهاء.
٦. عزل المستأجرين
كل جدول ينتمي لمستأجر يحمل عمود organization_id يُفرَض بواسطة Row-Level Security (RLS) في PostgreSQL بوضع FORCE. كل طلب يُحدّد app.current_organization_id عبر set_config داخل المعاملة الخاصة به؛ والسياسة تُصفّي كل SELECT/INSERT/UPDATE/DELETE مقابل هذه القيمة. التسرّب بين المستأجرين ممنوع على مستوى قاعدة البيانات، لا على مستوى التطبيق — بحيث أن أي خطأ في كود التطبيق لا يستطيع كشف بيانات مستأجر آخر.
٧. التحكم بالصلاحيات والمصادقة الثنائية
المنظمات لديها 32 دوراً مدمجاً تتراوح من مشاهد (مستوى 1) إلى مالك (مستوى 10)، مع تجاوزات لكل وحدة وإجراء وتجاوزات دقيقة لكل مستخدم. العمليات الحساسة — تغيير الخطة، الإلغاء، تعديل مصفوفة الصلاحيات، تعديل فترة الاحتفاظ، تغيير الإعفاء الضريبي، إعداد واتساب — تتطلب إعادة مصادقة عبر تحدي TOTP قبل إتمامها. تفعيل المصادقة الثنائية متاح لكل مستخدم، ويستطيع مالك المنظمة جعله إلزامياً.
٨. أمان الجلسات
الجلسات تعمل عبر كوكيز HTTP-only + Secure + SameSite=Lax موقّعة بسر على جانب الخادم. تنتهي الجلسات بعد 30 يوماً من عدم النشاط ويمكن إلغاؤها من صفحة إعدادات المستخدم. لا نُصدر رموز تجديد طويلة العمر للمتصفحات.
٩. سجل التدقيق
كل عملية كتابة تغيّر حالة ذات علاقة بالأعمال — إصدار فاتورة، تسجيل دفعة، دعوة مستخدم، تغيير صلاحية، تعديل خطة — تُكتب صفاً غير قابل للتعديل في audit_log مع المُنفِّذ، عنوان IP، القيم القديمة، والقيم الجديدة. فترة الاحتفاظ الافتراضية 84 شهراً (بالتوافق مع زاتكا). يمكن للتجار تعديل فترة الاحتفاظ في الإعدادات، مع اشتراط المصادقة الثنائية ومهلة 30 يوماً قبل أي حذف. عامل شهري يُطبّق حدّ الاحتفاظ مع كتابة سجل تدقيقي لكل منظمة، بحيث أن فعل الاحتفاظ نفسه قابل للتدقيق.
١٠. الحدود الحالية — فجوة الشفافية
نحن صريحون حول ما ليس مشفّراً بعد على مستوى التطبيق. بيانات العملاء والموردين المعروضة — الأسماء، أرقام الهاتف، عناوين البريد الإلكتروني، عناوين الفوترة — تبقى كنص صريح لأنها تُبحث وتُفلتر وتُضمّ وتُطبع على الفواتير باستمرار. تشفيرها سيكسر التدفقات الأساسية أو يتطلب تشفيراً حتمياً (والذي يكشف التطابق). هذه البيانات محمية بالتشفير على القرص، وبـ TLS أثناء النقل، وبـ RLS. إذا احتجت عزلاً أقوى لعميل معيّن (مثل حامل عقد سرية)، نوصي باستخدام اسم عرض مستعار والاحتفاظ بالهوية الحقيقية خارج النظام. نفضّل توثيق المقايضة بدل التظاهر بأنها غير موجودة.
١١. الاستجابة للحوادث
إذا اكتشفنا حادثاً أمنياً يؤثر على بياناتك، سنُخطرك عبر البريد الإلكتروني خلال 72 ساعة من التأكيد. إذا كنت تعتقد أنك اكتشفت ثغرة، راسلنا على [email protected] — نقرأ كل تقرير، ونرد خلال يومي عمل، ونقدّر الإفصاح المسؤول.
١٢. التوافق التنظيمي
مدرهم مبني ليتوافق مع نظام حماية البيانات الشخصية في المملكة العربية السعودية (PDPL — مرسوم ملكي م/19) ومتطلبات الفوترة الإلكترونية المرحلة الثانية من زاتكا. يشمل ذلك تصدير بيانات الشخص المعني (حزمة تصدير كل شيء في صفحة الإعدادات)، والتحكم بفترة الاحتفاظ، وسجلات التدقيق، والاستضافة داخل المملكة. نحن لا ننقل البيانات الشخصية خارج المملكة إلا إلى المعالجين الفرعيين المُحدّدين في سياسة الخصوصية.
أسئلة حول وضعنا الأمني؟ راسلنا على [email protected]. للاستفسارات العامة حول الخصوصية، راجع سياسة الخصوصية.