Qwizin — معمارية الأمن

الحالة: مسودة v0.1 · التاريخ: 2026-07-20 يرتبط بـ: QAS-SEC-*، QAS-INT-*، QAS-CMP-*، R-03…R-07، CON-10 (MoM NFR-1) وثيقة مرافقة: عرض وقت التشغيل (التدفقات) · DevOps (تحصين الـ cluster)

ملاحظة على النطاق. تغطي هذه الوثيقة أمن التطبيق والبيانات. أما تحصين Kubernetes وسلسلة التوريد فمكانه الغوص العميق في DevOps §5. والالتزامات التنظيمية في المخاطر §A — وتبقى غير مُتحقَّق منها بانتظار استشارة قانونية سعودية.

1. حدود الثقة (trust boundaries)#

flowchart TB
    subgraph UNTRUSTED["🔴 Untrusted"]
        MOB["📱 Mobile client<br/><i>attacker-controlled</i>"]
        ANON["🌐 Anonymous internet"]
        UPLOAD["📎 Uploaded files<br/><i>from unverified parties</i>"]
    end

    subgraph SEMI["🟠 Semi-trusted"]
        AUTH["Authenticated user<br/><i>may attack other tenants</i>"]
        EMP["Employee<br/><i>may attack employer/colleagues</i>"]
        EXTW["External webhooks<br/><i>spoofable</i>"]
    end

    subgraph TRUSTED["🟢 Trusted — inside the boundary"]
        API["API tier"]
        WORK["Workers"]
        DB[("PostgreSQL + RLS")]
        OBJ[("Object Storage")]
    end

    subgraph PRIV["🔵 Privileged"]
        ADM["🛡️ Admin portal<br/><i>highest-value target</i>"]
    end

    MOB & ANON -->|"TB-1: TLS · WAF · rate limit<br/>authn · input validation"| API
    AUTH -->|"TB-2: authz · tenant scope · RLS"| API
    EMP -->|"TB-3: employer/colleague isolation"| API
    UPLOAD -->|"TB-4: quarantine · magic bytes · AV"| OBJ
    EXTW -->|"TB-5: signature verify · idempotency"| API
    ADM -->|"TB-6: MFA · separate origin · full audit"| API
    API --> DB & OBJ
    WORK -->|"TB-7: re-establish tenant context"| DB

    style UNTRUSTED fill:#fde8e8,stroke:#c94a4a
    style SEMI fill:#fff4e5,stroke:#d98c1f
    style TRUSTED fill:#e8f5e9,stroke:#2d8659
    style PRIV fill:#e8f0fe,stroke:#1168bd

TB-3 وTB-7 هما الحدّان اللذان تغفل عنهما الفرق روتينيًا. TB-3 لأن «المستأجر» يُنمذَج كمحور واحد مسطّح بينما هما في الحقيقة محوران. وTB-7 لأن المهام ليس لها request، فكل آلية أمان مرتبطة بنطاق الطلب تتبخّر بصمت.

2. عزل المستأجرين (tenant isolation) — الضابط الأعلى أولوية#

QAS-SEC-01 · R-05 · تفصيل الآلية في Flow 6

2.1 لماذا يفشل التحديد على مستوى التطبيق وحده#

التصميم المُغري هو فحص عند كل endpoint: $employee->company_id === $user->company_id. وهو يفشل بنيويًا — فهو صحيح فقط إذا تذكّره كل مطوّر عند كل endpoint، إلى الأبد. أول فحص مَنسي هو اختراق، وسيُنسى، ولا شيء يُظهر هذا الإغفال. لا رسالة خطأ، لا انهيار، فقط الشركة A تقرأ سجلات موظفي الشركة B.

الـ global scope في Eloquent أفضل، لكنه يظل قابلًا للتجاوز عبر withoutGlobalScopes()، والاستعلامات الخام، وDB::table()، وبعض مسارات العلاقات، وأي شخص لا يعلم بوجوده أصلًا.

2.2 خمس طبقات، مرتّبة بحسب تأخّر كل منها في الالتقاط#

FORCE ROW LEVEL SECURITY مهم: بدونه يتجاوز مالك الجدول السياسات، ومالك الجدول عادةً هو دور التطبيق نفسه.

الطبقتان 1 و5 تصمدان أمام تغيّر فريق العمل. أما الطبقات 2–4 فتجعل الصواب سهلًا.

2.3 ⚠ نمطا فشل RLS#

كلاهما حالة تكون فيها السياسة مكتوبة بشكل صحيح ومع ذلك تتسرّب البيانات.

flowchart TB
    subgraph F1["Failure 1 — connection reuse"]
        R1["Request A<br/>company=1"] --> C1["Pooled connection<br/>SET app.company_id = 1"]
        C1 --> R2["Request B<br/>company=2"]
        R2 --> LEAK1["🚨 GUC still = 1<br/>Company 2 sees Company 1's data"]
    end

    subgraph F2["Failure 2 — queued job"]
        J1["Job dequeued"] --> J2["No HTTP request<br/>→ no GUC set"]
        J2 --> LEAK2["🚨 Unscoped query<br/>or silent empty result"]
    end

    style LEAK1 fill:#fde8e8,stroke:#c94a4a
    style LEAK2 fill:#fde8e8,stroke:#c94a4a

هذا سبب رئيسي لتأجيل Laravel Octane. فالـ workers الدائمة في Octane تجعل نمط الفشل الأول أكثر احتمالًا بكثير، مقايِضةً أعلى سمة جودة في النظام مقابل أداء لا يحتاجه حجم الإطلاق.

2.4 محور العزل الثاني#

يُدخل ACT-EMP بُعدًا للعزل يتجاوز شركة↔شركة:

• يجب ألا يقرأ الموظف درجات تقييم زميله
• وصول مسؤول الشركة إلى سجلات الموظفين ينبغي أن يكون محدَّد النطاق ومُدقَّقًا، لا مطلقًا
• شهادات الموظف الشخصية يُحتجّ بأنها ملكه هو لا ملك صاحب العمل (OQ-07)

لا تُنمذِج هذا كحدّ مستأجر واحد مسطّح. التحديد على مستوى الشركة ضروري وغير كافٍ.

3. الهوية والمصادقة#

التدفق في Flow 1.

3.1 استراتيجية الرموز (tokens)#

قيد مُتحقَّق منه: Laravel Sanctum لا يملك آلية refresh token أصلية. فهو يوفّر انتهاء صلاحية الرموز (إعداد expiration، صلاحية لكل رمز، sanctum:prune-expired) والإبطال بحذف الصف — أما التدوير وكشف إعادة الاستخدام فيجب بناؤهما.

كشف إعادة الاستخدام هو أعلى ضوابط المصادقة قيمةً على الإطلاق. فهو يحوّل سرقة الرمز من وصول صامت دائم إلى حادث مكتشَف.

ليس JWT عديم الحالة (stateless): الإبطال هنا متطلب وظيفي — رفض شركة يجب أن يقطع الوصول عن موظفيها فورًا. والرموز عديمة الحالة تجعل ذلك صعبًا.

3.2 تسجيل الدخول عبر Google#

تحقّق من ID token على الخادم: التوقيع مقابل JWKS الخاصة بـ Google، إضافةً إلى aud وiss وexp والـ nonce. لا تثق أبدًا ببريد إلكتروني أو ملف تعريف يرسله العميل.

⚠️ الاختطاف المسبق عبر ربط الحسابات (account-linking pre-hijacking). الربط التلقائي لتسجيل دخول Google بحساب قائم عبر مطابقة البريد الإلكتروني قابل للاستغلال إذا لم يُتحقَّق من ذلك البريد قط: يسجّل المهاجم بالبريد الإلكتروني للضحية، ثم يسجّل الضحية لاحقًا الدخول عبر Google، فيندمج الحسابان في وصول يتحكم فيه المهاجم. اشترط التحقق من بريد الحساب القائم قبل الربط.

3.3 OTP / الرسائل النصية#

⚠️ غير مُتحقَّق منه: متطلبات تسجيل مُعرّف المُرسِل (sender ID) في السعودية لدى الجهة المنظِّمة للاتصالات. تأكّد قبل اختيار مزوّد.

3.4 معمارية التخويل#

ثلاثة اهتمامات منفصلة يجب ألا تتشارك آلية واحدة:

flowchart LR
    REQ["Request"] --> S1{"1. Account state<br/><i>precondition</i>"}
    S1 -->|"not approved"| ALLOW{"On the explicit<br/>allowlist?"}
    ALLOW -->|No| DENY1["❌ 403 + machine-readable state"]
    ALLOW -->|Yes| S2
    S1 -->|"approved"| S2{"2. Capability<br/><i>may this role ever?</i>"}
    S2 -->|No| DENY2["❌ 403"]
    S2 -->|Yes| S3{"3. Resource policy<br/><i>this record, now?</i>"}
    S3 -->|No| DENY3["❌ 404 for cross-tenant"]
    S3 -->|Yes| OK["✅ Proceed"]

    style DENY3 fill:#fff4e5,stroke:#d98c1f

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

⚠️ مزالق مُوثَّقة في إطار العمل — الثلاثة حقيقية والثلاثة سهلة الوقوع فيها:

1. خطّاف before عام يُرجع false يُعطّل كل policy في التطبيق. فأي قيمة غير null تُعامَل كنتيجة التخويل النهائية، وتُقصِر كل ما بعدها — بما في ذلك قدرة المسؤول على مراجعة الحسابات المعلّقة. يجب أن يُرجع null في المسار الطبيعي. احصر الخطّاف العام في ترقية صلاحيات الـ super-admin فقط.
2. مساعدات التخويل السطرية (inline) تتخطى خطّافات before/after كليًا. وأي استدعاء منها يفلت بصمت من فحص حالة الحساب العام. امنعها خارج خدمة الصلاحيات (capability service).
3. دالة before() الخاصة بالـ policy لا تُستدعى إذا لم تكن الـ policy تحوي دالة مطابقة للصلاحية. ولذلك فإن نهج الـ base policy له نقطة عمياء تجاه الصلاحيات التي لا تُنفّذها الـ policy المُحدَّدة.

أرجِع 404 لا 403 عند محاولات استكشاف موارد عابرة للمستأجرين — فالـ 403 يؤكد وجود المورد ويُمكّن هجوم التعداد.

4. مسار رفع المستندات#

TB-4 · QAS-SEC-02، QAS-SEC-03 · R-07 · التدفق في Flow 2

التهديد الذي يُعرِّف هذا الـ pipeline: الـ onboarding يقبل ملفات عشوائية من أطراف غير مُتحقَّق منها — بحكم التعريف، لأن التحقق هو الغاية من الرفع أصلًا. وحمولة stored XSS تُقدَّم من نفس الأصل (same-origin) تُنفَّذ ضد جلسة المسؤول المُراجِع، وهي أعلى الجلسات صلاحيةً في النظام.

flowchart LR
    U["Upload"] --> V1["Size · count · declared type"]
    V1 --> V2["🔍 <b>Magic-byte inspection</b><br/><i>never extension or client MIME</i>"]
    V2 --> V3["Server-generated filename<br/><i>never the user's</i>"]
    V3 --> Q[("🔒 Quarantine bucket<br/>encrypted · no admin read")]
    Q --> AV["ClamAV<br/><i>separate Deployment</i>"]
    AV -->|"infected"| REJ["❌ Rejected<br/>admin never sees it"]
    AV -->|"clean"| PROM[("✅ Documents bucket")]
    PROM --> SIGN["Signed URL, TTL ≤ 5 min<br/>issued AFTER authz"]
    SIGN --> SEP["Separate domain<br/>Content-Disposition: attachment<br/>X-Content-Type-Options: nosniff"]

    style Q fill:#fde8e8,stroke:#c94a4a
    style REJ fill:#fde8e8,stroke:#c94a4a
    style PROM fill:#e8f5e9,stroke:#2d8659

يعمل ClamAV كـ Deployment منفصل، لا كـ sidecar داخل كل pod — فقاعدة بيانات التواقيع بحجم ~1 GB وستُستنسخ لولا ذلك داخل كل pod تطبيقي.

التشفير عند التخزين — على مستوى التطبيق، فوق تشفير التخزين#

موصى به للمستندات القانونية تحديدًا. فالتشفير على مستوى التخزين يحمي فقط من السرقة المادية للوسائط. وهو لا يحمي من بيانات اعتماد تطبيق مخترقة، أو bucket مُهيّأ خطأً، أو مشغّل مُفرَط الصلاحيات.

استخدم التشفير المغلَّف (envelope encryption)، لا مُشفِّر النصوص في إطار العمل — فتلك الواجهة تُحمِّل الملفات كاملةً في الذاكرة وهي خاطئة لملفات PDF بحجم عدة ميغابايت:

per-file random DEK → stream-encrypt AES-256-GCM
DEK wrapped by a KMS-held KEK → stored alongside the object

المفاتيح لكل ملف تعزل نطاق الضرر؛ ولا يعبر حدود الـ KMS سوى 32 بايت، ما يتجنب الكمون والتكلفة لكل بايت.

اذكر التكلفة بصراحة: تكامل KMS، وأدوات تدوير المفاتيح، ومهمة إعادة التغليف، وعناية دقيقة بنظافة الـ DEK في الذاكرة (لا يُسجَّل أبدًا، ولا يُحفظ مفكوك التشفير)، وفقدان دائم للبيانات إذا فشلت عهدة المفاتيح. ارصد ميزانية النضج التشغيلي، لا ميزانية الكود وحده.

5. التكاملات الخارجية#

TB-5

التسوية ليست اختيارية. فالـ webhooks عرضة للفقد. والفوترة مبنية على مدة الجلسة — وSessionEnded مفقود يعني خطأ في الفوترة أو جلسة مدفوعة مفتوحة إلى أجل غير مسمّى. يجب أن تقارن مهمة مجدولة حالة المزوّد بالحالة المحلية وتُغلق الجلسات اليتيمة.

6. بوابة المسؤول (Admin Portal)#

TB-6 — الهدف الأعلى قيمةً في النظام. يستطيع مسؤول المنصة اعتماد الحسابات، وقراءة المستندات القانونية لكل مستأجر، ولمس المدفوعات. حساب مسؤول واحد مخترَق ≈ اختراق المنصة.

تغييرات بيانات الـ payout تستحق فقرة خاصة بها. الاستيلاء على الحساب ← إعادة توجيه الـ payouts هو احتيال الـ marketplace الكلاسيكي. المطلوب: step-up MFA، ونافذة تأخير قبل سريان التغيير، وإشعار خارج القناة (out-of-band) إلى قناة التواصل السابقة — بما يمنح المالك الشرعي فرصة للتدخل.

7. سلامة التقييمات والشهادات#

QAS-INT-01/02/03 · R-06 · التدفق في Flow 4

لماذا يُصنَّف هذا كاهتمام أمني لا كاهتمام صحّة بيانات: هذه الشهادات تُقرّ بكفاءة في سلامة الغذاء. والشهادة المزوّرة تنقل خطرًا واقعيًا إلى روّاد المطاعم وتدمّر ادّعاء القيمة المركزي للمنصة.

7.1 سرية مفتاح الإجابات#

القاعدة مطلقة: الإجابة الصحيحة لا تغادر الخادم أبدًا — لا كعَلَم (flag)، ولا في البيانات الوصفية، ولا قابلةً للاستنتاج من ترتيب الخيارات أو ترتيب مفاتيح الكائن.

اختبار عقد (contract test) في CI يتحقق من غياب حقول الصحة من مخطط التسليم.

7.2 سلامة الدرجات#

7.3 مقاومة العبث في الشهادات — ثلاث طبقات مستقلة#

flowchart LR
    C["Certificate PDF"] --> L1["1️⃣ Signed QR payload<br/><i>cert id · holder · course ·<br/>issue · expiry + signature</i><br/><b>→ offline verification</b>"]
    C --> L2["2️⃣ Public verification endpoint<br/><i>/verify/{ULID}</i><br/><b>→ revocation + current status</b>"]
    C --> L3["3️⃣ Digitally signed PDF (PAdES)<br/><i>requires a trust service provider</i><br/><b>→ strongest for third parties</b>"]

كل طبقة تهزم مهاجمًا مختلفًا:

1. حمولة QR موقَّعة. الشهادة المزوّرة بصريًا تفشل في فحص التوقيع حتى بدون أي اتصال بالشبكة — وهو أمر مهم لمفتش بلدية داخل مطبخ. استخدم مفتاح توقيع مخصصًا، لا مفتاح التطبيق.
2. نقطة نهاية تحقق عامة. استخدم ULID أو رمزًا عشوائيًا بطول 128 بت، ولا تستخدم أبدًا رقم شهادة تسلسليًا — فالمعرّفات التسلسلية تتيح لأي شخص تعداد مجموعة الشهادات بأكملها. اكشف الحد الأدنى من البيانات الشخصية (PII): الدورة، تاريخا الإصدار والانتهاء، صالحة/مُبطَلة، وعلى الأكثر جزء من اسم حاملها. وصفحة عامة تُرجع الاسم الكامل مع رقم الهوية الوطنية هي خرق لـ PDPL بفعل ذاتي. وحدِّد معدل الطلبات عليها.
3. توقيع PAdES. ⚠️ غير مُتحقَّق مما إذا كان الحصول على شهادة توقيع موثوقة سعوديًا ممكنًا — ويستحق البحث، لأن التوقيع الموثوق محليًا يحمل وزنًا أكبر لدى الجهات التنظيمية السعودية.

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

8. سجل التدقيق#

QAS-CMP-02

ما يجب تسجيله#

أحداث المصادقة (النجاح، الفشل، MFA، تغيير بيانات الاعتماد) · كل حالات رفض التخويل (إشارة الهجوم) · رفع/اعتماد/رفض المستندات مع هوية المُراجِع · محاولات التقييم وتصحيحات الدرجات · إصدار الشهادات وإبطالها · كل الأحداث المالية · تغييرات بيانات الـ payout · انتحال هوية المستخدم من قبل المسؤول · تغييرات الأدوار · كل تصدير أو قراءة جماعية للبيانات الشخصية (ذات صلة بـ PDPL).

السلامة#

تخلق سير عمل الاعتماد والمعاملات المالية خطر الإنكار (repudiation)، ولذلك فإن جدول سجل عادي قابل للتعديل غير كافٍ — فأي شخص يملك صلاحية الكتابة على قاعدة البيانات يستطيع إعادة كتابة التاريخ.

استخدم سجلًا إلحاقيًا فقط بسلسلة تجزئة (hash-chained ledger):

chain_hash(n) = SHA256( chain_hash(n-1) || payload_hash(n) )

مع نقاط تفتيش موقَّعة (signed checkpoints) دوريًا تُثبِّت رأس السلسلة.

وكمّله بحماية على مستوى قاعدة البيانات: اسحب صلاحيتي UPDATE وDELETE على جدول التدقيق من دور التطبيق، وأرسل السجلات إلى تخزين خارجي يُكتب مرة واحدة (write-once).

نظافة البيانات الشخصية#

احجب البيانات في طبقة التسجيل، لا بانضباط المطوّرين.

⚠️ تعارض في مدد الاحتفاظ. الاحتفاظ بسجل التدقيق (≥ 7 سنوات للتوافق المالي) يتعارض مع مبدأ تقليل البيانات وحقوق المحو في PDPL. احسم هذا عمدًا مع مستشار قانوني ووثّقه في سجل أنشطة المعالجة — لا تَرتجل عند وصول طلب حذف.

9. نموذج التهديدات STRIDE#

أعلى التهديدات خطورةً بحسب الحد.

الأربعة التي تُعالَج أولًا: BOLA العابر للمستأجرين · IDOR على المستندات · الرفع الخبيث · اختراق المسؤول. كل واحد منها قادر بمفرده على كشف بيانات كل عميل.

10. أولوية التنفيذ#

مرتّبة بحسب تخفيض المخاطر لكل ساعة عمل، لا بحسب الطرافة التقنية.

الأسبوع 1 — أعلى نسبة، وأقل خطر تعطيل#

1. APP_DEBUG=false / APP_ENV=production مُتحقَّق منهما بفحص آلي
2. تأكيد أن تدفق الدفع مُستضاف/بإعادة توجيه بحيث لا تلمس بيانات البطاقات بنية Qwizin التحتية أبدًا
3. إخراج الأسرار النصية من إدارة الإصدارات؛ فحص الأسرار في CI؛ وتدوير أي سرّ سبق إيداعه
4. التصحيح على الخادم حصرًا؛ موارد API صريحة بقوائم سماح للحقول
5. تغيير كلمة المرور ← إبطال كل عائلات الرموز

الشهر 1 — بنيوي#

6. سياسات RLS جنبًا إلى جنب مع أول migration محدَّد بالمستأجر — فتركيبها لاحقًا على جدول مليء بالبيانات يستلزم نافذة صيانة
7. TenantContext الذي يرمي استثناءً؛ متغير جلسة بنطاق المعاملة + إعادة ضبط في terminating middleware
8. إعادة تأسيس سياق المستأجر في كل مهمة في الطابور، مع رمي استثناء عند غيابه
9. حزمة اختبارات CI هجومية للوصول العابر للمستأجرين — الضابط الذي يحفظ سلامتك فعليًا مع مرور الوقت
10. مسار الرفع: quarantine ← AV ← ترقية؛ نطاق منفصل؛ magic bytes
11. تدوير رمز التحديث مع كشف إعادة الاستخدام
12. MFA للمسؤول + أصل منفصل + تغطية تدقيق
13. تشفير مغلَّف على مستوى التطبيق للمستندات القانونية

الربع 1 — العمق#

14. سجل تدقيق بسلسلة تجزئة مع نقاط تفتيش موقَّعة
15. QR موقَّع للشهادة + نقطة نهاية تحقق عامة + إبطال
16. مصادقة step-up على تغييرات الـ payout، مع تأخير وإشعار خارج القناة
17. حجب البيانات في طبقة التسجيل؛ تقارير استثناءات مُنظَّفة
18. جرد البيانات الشخصية — مطلوب حتى يكون QAS-CMP-01 قابلًا للتحقق أصلًا

بخصوص جرد البيانات الشخصية: الجزء الصعب في طلب صاحب البيانات ليس الحذف، بل الحصر. فبمجرد أن تنتشر البيانات داخل فهرس بحث، و projection للتقارير، و pipeline للسجلات، يصبح سؤال «اعثر على كل شيء عن هذا الشخص» بلا إجابة دون جرد يُصان كأصل من الدرجة الأولى. ابنِه بينما النظام لا يزال صغيرًا.

11. حيث يلزم مستشار قانوني، لا بحث#

⚠️ هذه ليست أسئلة هندسية. التفصيل في المخاطر §A.

1. ترخيص ساما SAMA (R-01) — قبل بناء الـ payouts
2. الفوترة الإلكترونية ZATCA (R-02) — النطاق، ومسألة مورّد السجل (supplier-of-record) في الـ marketplace
3. الواجبات التشغيلية لـ PDPL (R-03) — مُهَل الإبلاغ عن الخروقات، ومواعيد الاستجابة لطلبات أصحاب البيانات، وعتبة تعيين مسؤول حماية البيانات (DPO)، وتعارض مدد الاحتفاظ مع الاحتفاظ بسجل التدقيق، والأساس النظامي لـ وصول صاحب العمل إلى سجلات تدريب الموظفين، وما إذا كانت الاستشارات المسجَّلة تُعدّ بيانات صحية حساسة

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