الأمان
أمان تقدر تتأكد منه في الكود
أوروسفينكس بتتعامل مع ذهب حقيقي وفلوس حقيقية. الأمان مبني على عزل بيانات على مستوى الصف في بوستجرس، سجل مراجعة لكل تعديل، ويب هوكس موقعة، وعمليات لا تتكرر.
سجل الادّعاءات — ٠١
كل ادّعاء جنبه الآلية واسم الملف اللي بينفذه.
| الادّعاء | الآلية | راجعه في |
|---|---|---|
| عزل المحلات | سياسات RLS في بوستجرس على كل جدول | scripts/wave-12/lint/rls-tenant-filter.mjs |
| سجل مراجعة | حالة قبل وبعد لكل تعديل | utils/audit.ts |
| ويب هوكس موقّعة | HMAC v1 بختم زمني ورقم استخدام مرة واحدة | services/webhook-outbox.ts |
| ترحيل بيع محمي من التكرار | X-Idempotency-Key · pg_advisory_xact_lock | middleware/idempotency.ts |
| صلاحيات على الخادم | بتتطبق على الخادم مع كل طلب | auth/assert-permission.ts |
| PIN محمي على الكاشير | تجزيء scrypt مع قفل بعد محاولات | routers/user.ts |
| مفاتيح API بصلاحيات | محفوظة كهاش، تظهر مرة واحدة | auth/api-key-verify.ts |
| استرجاع لأي لحظة | نسخ احتياطية مستمرة لقاعدة البيانات | workers/backup-scheduler.ts |
| حدود استخدام | مفعّلة دائمًا في الإنتاج | middleware/rate-limit.ts |
المستندات — ٠٢
مستند أ — عزل بيانات المحلات
كل محل يعمل داخل حدود سياسة RLS الخاصة به في بوستجرس. دور التطبيق لا يتجاوز RLS. أي عملية بين المحلات تمر عبر دوال SECURITY DEFINER ضيقة موثقة في الترحيلات.
- سياسات RLS على كل جدول مرتبط بالمحلات
- سياق المحل مربوط بكل طلب عبر app.current_tenant_id
- دور قاعدة البيانات الخاص بالتطبيق ليس لديه BYPASSRLS
- العمليات العابرة محصورة في دالة واحدة قابلة للمراجعة
ALTER TABLE sales.sales
ENABLE ROW LEVEL SECURITY;
ALTER TABLE sales.sales
FORCE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON sales.sales
USING (tenant_id = NULLIF(current_setting(
'app.current_tenant_id', true), '')::uuid);مستند ب — سجل المراجعة
كل تعديل أو نقل حالة أو حذف يسجل الحالة قبل التعديل. أعطال المصادقة وقفل PIN ودوران المفاتيح وعمليات الطوارئ تسجل كأحداث أمان بدرجة خطورة.
- سجل غير قابل للتعديل على التعديلات
- تصفية حسب المستخدم والإجراء والكيان والفرع
- أحداث أمان بدرجة خطورة للمراجعة
- قابل للتصدير للمراجعات الداخلية والخارجية
{
"action_type": "UPDATE",
"entity_type": "inventory.item",
"entity_id": "IT-04129",
"actor_role": "manager",
- "before": { "price_making": 120.00 },
+ "after": { "price_making": 135.00 },
"trace_id": "01a7f2…"
}مستند ج — إشعارات موقّعة
مفاتيح API بصلاحيات محددة محفوظة كهاش. ويب هوكس بغلاف HMAC v1 بختم زمني ورقم استخدام مرة واحدة. تسليم عبر صندوق صادر مع إعادة محاولة.
- غلاف HMAC v1 على كل تسليم
- مفاتيح API مهاش، تظهر مرة واحدة
POST /your-endpoint HTTP/1.1
X-Webhook-Topic: sale.completed
X-Webhook-Event-Id: 0197f3a2-4bd1…
X-Webhook-Timestamp: 1767014402
X-Webhook-Nonce: 5b2fc0e1a94d…
X-Webhook-Signature-V1: 9c41d8f2e6…
v1 = HMAC_SHA256(secret,
timestamp + "." + nonce + "." + body)مستند د — الاسترجاع
نسخ احتياطية مستمرة لبوستجرس مع استرجاع لأي لحظة. إقفال الوردية يطلق نسخة منطقية إضافية. نسخ محلية مشفّرة اختيارية يكتبها وكيل المحل.
PITRworkers/backup-scheduler.tsBACKUP_RETENTION_DAYSمستند هـ — انضباط الكاونتر
الواجهة تعكس الصلاحيات لكنها لا تقررها. كل عملية tRPC تتحقق من الدور والاستحقاق قبل القراءة أو الكتابة.
- أدوار: مدير، مشرف، كاشير، مشاهد، وأدوار مخصصة
- تحقق صلاحيات على كل تعديل
- إجراءات الطوارئ تسجل حدث أمان
- تسجيل تجاوز الاستحقاق عند إيقاف التطبيق
pin_hash = scrypt(pin, salt, 64)
stored = "9f2c…31c8:a41b…77e0" -- salt:derived
compare = crypto.timingSafeEqual(a, b)
legacy = sha256 -> scrypt -- dual-read upgradeمستند و — حدود النظام
بيانات المحل وراء RLS في بوستجرس. كل تعديل بيتطبق على الخادم وبيتسجل في سجل المراجعة. دور التطبيق ما يملكش BYPASSRLS. الويب هوكس موقّعة بـ HMAC v1 بختم زمني ورقم استخدام مرة واحدة.
طلبات البيانات — ٠٣
النظام فيه مسارات جاهزة لطلبات حذف وتصدير البيانات، بتتنفذ تحت عزل كل محل لوحده.
تطلب إيه في المعاينة — ٠٤
اطلب مننا نغيّر سعر ونوريك سطر السجل قبل وبعد.
اسأل قاعدة البيانات بترجّع إيه من بيانات محل تاني: ولا حاجة.
اطلب تشوف إشعار ويب هوك وتتحقق من توقيعه بنفسك.
تواصل معنا — ٠٥
تحب جولة كاملة في الأمان؟
هنشرح بالتفصيل عزل المحلات، سجل المراجعة، توقيع الويب هوكس، والضوابط التشغيلية.