قانوني
الموقف التشغيليّ للخصوصيّة
آخر تحديث: 2026-05-17
هذه الوثيقة هي المكمّل التشغيليّ لـ سياسة الخصوصيّة. سياسة الخصوصيّة هي ما يحقّ لنا قانونياً فعله بالبيانات؛ هذه الصفحة هي ما نفعله فعلياً، ما الأدوات التي تفرضه، وكيف نُجيب على "هل نظر موظّفو Amargi في بياناتي" بتفاصيل ملموسة.
إنّها منشورة، قابلة للقراءة من قِبَل العميل، ومُلزِمة لنا. إن خرجنا عن أيّ التزام هنا، فالخروج هو P0: نُصلحه، نُسجّله، نُخبر العملاء المتضرّرين.
الملخّص
- نحن لا نتصفّح محتوى رسائل العملاء. تعرض لوحة إدارة المنصّة (Platform admin) العدّادات والبيانات الوصفيّة فقط. لا يوجد زرّ "اعرض هذه الرسالة".
- وصول المشغّل إلى نصوص الرسائل يحدث فقط عندما يوضّح سجلّ المراجعة السبب: التحقيق في إساءة، تذكرة دعم فتحها العميل، أو أمر قضائي. كلّ مرّة وصول مُسجَّلة.
- لا نبيع البيانات، لا نُشاركها مع طرف ثالث لأغراض إعلانيّة، ولا نُدرّب نماذج على رسائل العملاء أو رسائل عملائهم النهائيّين.
1. هندسة المصادقة (Amargi Hub SSO)
Amargi هي عائلة منتجات (Reach، Mail، Agents، Meet، Escalate). تستخدم جميعها مزوّد هويّة مُشتركاً يُدعى Amargi Hub لتسجيل الدخول. Hub يُخزّن فقط:
- بيانات اعتماد الحساب (البريد الإلكتروني، تجزئة كلمة المرور، أسرار 2FA).
- الجلسات النشطة ورموز التحديث.
- عضويّة المؤسسة والأدوار (مَن يستطيع رؤية ماذا داخل أيّ منتج).
Hub لا يُخزّن أيّ بيانات رسائل WhatsApp، ولا قوائم جهات اتصال، ولا أيّ محتوى يحكمه اتفاق Meta لمزوّدي حلول الأعمال (BSP). كلّ ذلك مملوك ومُعالَج حصرياً من قِبَل Reach. الحدود نظيفة حسب نوع البيانات:
| يعيش في Hub | يعيش في Reach |
|---|---|
| هويّة الحساب (بريد، تجزئة كلمة مرور، 2FA) | حسابات WhatsApp Business (WABAs) |
| الجلسات، رموز التحديث | أرقام الهواتف، تقييمات الجودة، طبقات الرسائل |
| عضويّة المؤسسة، الأدوار | القوالب، الحملات، الجماهير |
| البيانات الوصفيّة لمساحة العمل | المحادثات، الرسائل، جهات الاتصال، سجلّات الموافقة |
| التنقّل بين المنتجات | اشتراكات Webhook، حالة التسليم الصادر |
هذا النمط مماثل لتوكيل Twilio وMessageBird و360dialog وInfobip و"الكيان القانونيّ المؤكَّد لدى Meta للأعمال" هو نفسه بصرف النظر عن المنتج الذي يستخدمه العميل. Hub ليس مُعالِجاً فرعياً (subprocessor) ولا طرفاً ثالثاً: إنّه خدمة مصادقة داخليّة تُشغّلها Amargi Creative — نفس الكيان القانونيّ، نفس الاستضافة، نفس محيط الالتزام.
2. ماذا يرى مشغّل Amargi
لوحة إدارة منصّة Amargi (مجموعة المسارات (platform)، محميّة بمطلب JWT platform_admin) تكشف ما يلي لكل مؤسسة عميل:
| السطح | ما يعرضه |
|---|---|
/platform | عدد المؤسسات، المستخدمين، WABAs، الإيرادات الشهريّة المتكرّرة، عدّادات الرسائل المُجمَّعة (آخر 7 / 30 يوماً)، إحصاءات تسليم الـ outbox + webhook. |
/platform/orgs | اسم المؤسسة، slug، الخطّة، عدد المستخدمين، عدد WABAs، عدد الرسائل في آخر 30 يوماً، تاريخ الإنشاء. |
/platform/orgs/{id} | ما سبق + قائمة المستخدمين بالدور وآخر تسجيل دخول، قائمة WABAs بمعرّف المزوّد والمنطقة وحالة التحقّق، تدفّقات الاستخدام آخر 7 / 30 يوماً، تدفّقات التكلفة آخر 30 يوماً. أدوات تعليق / إلغاء التعليق. |
/platform/users | بريد، اسم، علم تحقّق، علم 2FA، علم مسؤول المنصّة، عدد المؤسسات، آخر تسجيل دخول. |
/platform/wabas | معرّف WABA لدى المزوّد، المؤسسة المالكة، المنطقة، حالة التحقّق، علم التفعيل، عدد الأرقام. |
/platform/phone-numbers | E.164، اسم العرض، المؤسسة المالكة، الحالة، تقييم الجودة، عدد الرسائل في الثانية. |
/platform/templates | اسم القالب، المؤسسة المالكة، اللغة، الفئة، الحالة، سبب الحالة. |
/platform/campaigns | اسم الحملة، المؤسسة المالكة، الحالة، عدد المُرتَّبين / المُرسَلين / المُسلَّمين / الفاشلين. |
/platform/health | عدّادات outbox، عدّادات webhook، تفاصيل جودة الأرقام. |
3. ما لا يراه مشغّل Amargi (في اللوحة)
- نصوص الرسائل، التسميات التوضيحيّة، أسماء ملفّات الوثائق، أحمال أزرار التفاعل. ليست في أيّ DTO يُرجَع للوحة المشغّل.
- نُسَخ المحادثات بين عميل وعملائه النهائيّين.
- أرقام هواتف المستلمين لكلّ رسالة (فقط عدد المستلمين لكلّ حملة).
- قوائم جهات الاتصال، صفات جهات الاتصال، تعريفات الجمهور وراء الأحجام المُجمَّعة.
- نصوص حمولات الـ webhook، فقط عدّادات حالة التسليم.
- تفاصيل بطاقات Stripe، لا تُرى أبداً، تُحفظ عند Stripe.
4. متى يُسمح بوصول المشغّل إلى محتوى الرسائل
ثلاث حالات. كلّها مُسجَّلة.
- التحقيق في إساءة. Meta أشارت إلى WABA لعميل، أو وصلنا بلاغ عن سبام / احتيال / محتوى محظور. يفتح المشغّل أداة الفحص، يُقدّم سبباً يشير إلى حالة الإساءة، ويُراجع الحدّ الأدنى الضروريّ من نصوص الرسائل لتأكيد أو دحض البلاغ. نحن مُلزَمون تعاقدياً بهذا بموجب شروط Meta لـ BSP؛ لا يمكننا الانسحاب.
- تذكرة دعم فتحها العميل معنا. العميل طلب منّا النظر في رسالة س. سجلّ مراجعة المشغّل يُشير إلى رقم التذكرة.
- أمر قانوني، استدعاء، أمر قضائي، أو ما يعادله في أيّ ولاية يُقيم فيها العميل أو عملاؤه النهائيّون. نطلب الأمر مكتوباً، نُحدّد ردّنا حسب نطاق الأمر الفعلي، ونُخطر العميل المتضرّر إلّا حيث يحظر القانون ذلك.
نحن لا نصل إلى محتوى الرسائل لتحليلات المنتج، تدريب النماذج، التسويق، التنقيب عن المبيعات، أو الفضول. القيام بذلك أسباب لإنهاء عمل المشغّل وإخطار العملاء المتضرّرين والجهات التنظيميّة إن لم يُبرَّر الوصول بأثر رجعي.
5. كيف يعمل سجلّ الوصول
كلّ إجراء تحت [PlatformAdmin] يكتب صفّاً في platform.audit_events:
actor_user_id— موظّف Amargi الذي اتّخذ الإجراء.actor_email— مُسجَّل لعرض قابل للقراءة.action— Controller.Method، مثلاً PlatformOrgs.Suspend.target_type, target_id, target_org_id— السجلّ المُتأثّر.ip, user_agent, status_code— سياق الطلب (محاولات الوصول الفاشلة مرئيّة أيضاً).reason— نصّ حرّ. مطلوب للإجراءات الحسّاسة.occurred_at— الطابع الزمنيّ UTC.
السجلّ يُلحَق فقط على طبقة التطبيق (لا توجد مسارات UPDATE أو DELETE في الشيفرة) ومرئيّ للمشغّلين في /platform/audit-log. الوصول الموجَّه للعميل ("أرني كلّ إجراء مشغّل لمس مؤسستي") على خريطة الطريق. نحتفظ بسجلّات المراجعة لمدّة 7 سنوات على الأقلّ.
6. موقف التشفير
موثَّق بالتفصيل لمراجعي Meta وفِرَق المشتريات المؤسسيّة والمدقّقين الأمنيّين.
6.1 أثناء النقل
- الحدّ الأدنى TLS 1.2 على كلّ نقطة نهاية عامّة. TLS 1.3 مفضّل وافتراضيّ على العملاء المدعومين.
- HSTS (max-age=31536000; includeSubDomains; preload) على كلّ نطاق موجَّه للعميل.
- mTLS على حركة المرور الداخليّة بين الخدمات حين تنتشر المنصّة عبر مُضيفين متعدّدين.
- التحقّق من توقيع Webhook (HMAC-SHA256) على كلّ webhook وارد من Meta قبل أيّ منطق عمل.
6.2 في الاستراحة، ضوابط مُتعدّدة الطبقات
نستخدم نهج الدفاع في العمق: ثلاث طبقات مستقلّة تحمي بيانات رسائل العملاء من الشبكة إلى القرص.
- تشفير القرص الكامل على مستوى الجهاز. كلّ مجلّدات Postgres مُشفَّرة في الاستراحة من قِبَل مزوّد السحابة (LUKS-equivalent / KMS-managed AES-256). نُسَخ احتياطيّة قاعدة البيانات (لقطات + WAL archive) مُشفَّرة بمفاتيح المزوّد.
- تشفير مغلَّف على مستوى التطبيق للأسرار. حقول الاعتماد الحسّاسة — رموز وصول WABA، رموز وصول Page، رموز Instagram، أسرار توقيع webhook — تُكتَب عبر IDataProtector من ASP.NET Core. كلّ صفّ من النصّ المُشفَّر يحمل معرّف مفتاح صادر عن التطبيق؛ المفتاح الرئيسي يعيش في خلفيّة الأسرار (AWS Secrets Manager / GCP Secret Manager / HashiCorp Vault) ويُدوَّر كلّ ثلاثة أشهر. تفريغ قاعدة البيانات وحده لا يُنتج رموزاً صالحة للاستخدام.
- pgcrypto متاح للتشفير على مستوى العمود لأجسام الرسائل (اختيار لكل مؤسسة). هذا الطبقة الأقوى، لكنّه يقلّل مرونة الاستعلام (يتوقّف البحث الجزئي) ومُعطَّل افتراضياً. عملاء المؤسسات الذين يحتاجونه يمكنهم تفعيل العلم لمؤسستهم.
6.3 ما لا نفعله عمداً
- مفاتيح يديرها العميل (BYOK / CMK). مُخطَّطة كميزة مؤسسيّة، غير مُتوفِّرة بعد. حتى ذلك الحين، المشغّل (Amargi) داخل حدود الثقة لبيانات الاستراحة وهذه الوثيقة هي الالتزام الذي يحدّ ممّا نفعله بتلك الثقة.
- تشفير كلّ عمود. محادثة WhatsApp هي بطبيعتها سجلّ نصّ عميل/وكيل، تشفير كلّ صفّ يكسر مربّع البحث في الـ inbox. نُشفِّر الأسرار التي إن سُرِّبت تسمح لمهاجم بانتحال هويّة عمل العميل لـ Meta؛ لا نُشفِّر كلّ صفّ نصّ افتراضياً. هذا نفس الموقف الذي يتّخذه كلّ مزوّد حلول WhatsApp Business رئيسي.
6.4 تواتر تدوير المفاتيح
- مفتاح التشفير الرئيسي (مفتاح المغلّف لـ DataProtector): كلّ ثلاثة أشهر.
- أسرار توقيع Webhook: يتحكّم بها العميل، يُوصى بكلّ ثلاثة أشهر.
- رموز وصول WABA: دورة حياة يتحكّم بها Meta؛ نُعيد الحصول عليها عند انتهاء الصلاحيّة عبر مسار تجديد BSP.
- شهادات mTLS الداخليّة: تدوير Let's Encrypt كلّ 90 يوماً.
6.5 كيف يمكن للمراجِع التحقّق
- messaging.wabas.access_token_ref في تفريغ قاعدة بيانات حديث يعرض نصّاً مُشفَّراً، ليس نصّاً عادياً. تأكَّد بفحص أيّ صفّ.
- متغيّر بيئة Reach:Secrets:Mode على الإنتاج يجب أن يُضبط على قيمة غير "passthrough" — aws، gcp، أو vault.
- كلّ مُعالِجات webhook الواردة + الصادرة تنتهي بـ 401 إن كان التوقيع مفقوداً أو فشل مقارنة HMAC ذات الوقت الثابت.
7. عزل المستأجرين
كلّ كيان مملوك من مؤسسة في طبقة المجال يحمل علامة ITenantOwned. فلاتر استعلام EF Core تُضاف تلقائياً إلى كلّ استعلام لتقييد القراءات على المؤسسة النشطة لطلب المُتّصِل. يمنع هذا تسرّب البيانات بين المؤسسات هيكلياً، ليس فقط حسب الاتفاقية، بصرف النظر عمَّن سجَّل الدخول أو عبر أيّ منتج. يكسر الكود الذي يحاول الاستعلام بدون التصفية على المستأجر اختبار وحدة في طبقة المستودعات.
8. إقامة البيانات
تُخزَّن بيانات الإنتاج في منطقة واحدة تُختار لكلّ عميل عند الإعداد. الافتراضي eu-central-1. أيّ تكرار عبر المناطق، إن وُجد، يبقى داخل نفس الولاية القضائيّة القانونيّة.
9. المُعالِجون الفرعيّون
القائمة الكاملة (مع الغرض، الموقع، رابط DPA لكلّ منهم) منشورة في صفحة المُعالِجين الفرعيّين. نُخطر العملاء بمعالجين فرعيّين جدد قبل النفاذ بـ 30 يوماً على الأقلّ.
10. التغييرات على هذه الوثيقة
المراجعة الحاليّة مُلتزمة في المستودع في apps/reach/docs/PRIVACY-POSTURE.md ومنعكسة هنا. سجلّ Git للملف هو سجلّ التغيير الرسمي. التغييرات الجوهريّة تُعلَن للعملاء عبر البريد قبل النفاذ بـ 30 يوماً على الأقلّ.
11. التواصل
أسئلة الخصوصيّة، طلبات الوصول، طلبات الحذف: contact@amargicreative.com. قضايا الأمن: contact@amargicreative.com.