Skip to main content

طلبات الوصول إلى بيانات صاحب البيانات (DSAR)

طلب الوصول إلى بيانات صاحب البيانات (يُسمّى أيضًا طلب الخصوصية أو طلب حقوق المستهلك) هو الآلية الرسمية التي يستخدمها الشخص لممارسة حقوقه على البيانات الشخصية التي تحتفظ بها عنه — حق الوصول، والحذف، والتصحيح، والنقل، وإلغاء الاشتراك في بيع تلك البيانات. تمنحك معظم قوانين الخصوصية موعدًا نهائيًا صارمًا للرد (30 يومًا بموجب GDPR و45 يومًا بموجب CCPA/CPRA). تمنحك Orbit مسارَين للاستقبال ومسارًا واحدًا للتنفيذ:
  • DSAR المقدَّم من المشغّل — يقدّم فريق الدعم أو الامتثال لديك الطلب نيابةً عن عميل عبر واجهة API المعرَّفة أو لوحة التحكم.
  • البوابة العامة للخدمة الذاتية — يقدّم صاحب البيانات طلبه بنفسه عبر مسار عام غير متطلِّب للمصادقة يثبت هويته برمز OTP لعامِلَين عبر البريد الإلكتروني + SMS قبل إضافة أي شيء إلى قائمة الانتظار.
تصف هذه الصفحة الضوابط المنصّية لـ Orbit. وهي ليست نصيحة قانونية. تعتمد التزاماتك — القوانين التي تنطبق وما يجب عليك كشفه والمدة المتاحة لك — على مكان إقامة أصحاب البيانات لديك وما تعالجه من بيانات. تأكد لدى مستشار قانوني مؤهّل.
جميع نقاط النهاية أدناه متجذِّرة على https://api.orbit.devotel.io/api/v1/compliance.

الاختصاصات القضائية المدعومة والمواعيد النهائية

يتحكم applicable_jurisdiction على الطلب في الساعة القانونية التي يطبّقها متعقّب SLA في Orbit. ويمكن للمشغّلين إعادة تصنيف الطلب بعد الاستقبال.

أنواع الطلبات

يصف request_type ما يطلبه الصاحب. مجموعة أفعال CCPA/CPRA الكاملة متاحة للمشغّلين؛ وتكشف البوابة العامة مجموعة فرعية أكثر ودية تُعرَض عليها. لطلبات وصول CCPA يمكنك أيضًا إرفاق consumer_categories — فئات CCPA §1798.100(b) التي يسأل عنها الصاحب: identifiers، customer_records، protected_classifications، commercial، biometric، internet_activity، geolocation، sensory، professional، education، inferences، sensitive_pi.

طلبات المقدَّمة من المشغّل

إنشاء طلب

POST /compliance/dsar — يتطلّب مفتاح API لمسؤول أو مالك. قدّم معرّفًا واحدًا على الأقل لصاحب البيانات (contact_id أو subject_email أو subject_phone) بالإضافة إلى requester_email الذي يمُسّى تلقّي المراسلات.
يعيد 202 Accepted:
ملاحظةapplicable_jurisdiction يفترض gdpr فقط للحقوق الموجودة بموجب GDPR. نوعا الطلب opt_out_sale وlimit_sensitive_pi خاصّان بـ CCPA/CPRA ولا يقابلهما مقابل في GDPR، لذا يجب ضبط applicable_jurisdiction صراحةً على ccpa أو cpra لهما. إغفاله (أو ترك الافتراضي gdpr) يُرفَض بـ 422 VALIDATION_ERROR.

دورة حياة الحالة

ينتقل الطلب عبر: receivedprocessingcompleted مع فروع نهائية failed وexpired وcancelled. تُتعقَّب حالة التحقق الفرعية باستقلالية: pendingverified (يتابع العامل) أو rejected (يتوقّف العامل). تفترض صفوف GDPR/المُقدَّمة من المسؤول not_required.

التحقق من الهوية أو رفضها

تتطلب الطلبات عالية الضمان (الحذف، وإلغاء الاشتراك، والحدّ من الحسّاسة) قرار مشغّل قبل أن يستمر التنفيذ:
decision هو verified أو rejected؛ وnotes اختياري (≤ 2048 حرفًا). يعيد verification_status الجديد وverified_at.

إلغاء طلب

POST /compliance/dsar/{id}/cancel يسحب طلبًا جاريًا (GDPR المادة 7(3)). يعمل فقط ما دام الطلب received أو processing؛ والطلب النهائي يعيد 409 Conflict.

إدراج الطلبات وقراءتها

  • GET /compliance/dsar — قائمة مُرَحَّلة. الاستعلام: page (≥ 1) وpage_size (≤ 100، الافتراضي 25) ومُرشِّح status اختياري.
  • GET /compliance/dsar/{id} — جلب طلب واحد. يتضمّن الرد export_url الموقَّع (وexport_expires_at) بمجرد أن يُنتَج تصدير الوصول/النقل، بالإضافة إلى tables_exported التي تصف عدد الصفوف لكل جدول.

طلبات الإزالة

تُتعقَّب عمليات إزالة GDPR المادة 17 كمورد مستقل حتى تتمكن من التدقيق والتدخل قبل إتلاف البيانات:
  • GET /compliance/dsar/erasure-requests — القائمة. الاستعلام: status (pending، cancelled، executing، executed، failed) وlimit (≤ 500).
  • POST /compliance/dsar/erasure-requests/{id}/cancel — إلغاء إزالة معلَّقة قبل تنفيذها. reason اختياري (≤ 500 حرفًا). يعيد 409 إذا كانت تنفَّذ أو اكتملت.

لوحة SLA

GET /compliance/dsar/sla يعيد لقطة SLA مشترَكة للتصدير والإزلة حتى لا تفوّت موعدًا نهائيًا قانونيًا أبدًا:
مستويات الخطورة تتناسب طَرديًا مع نافذة SLA الخاصة بكل اختصاص قضائي — مُثبَّتة عتبات الأيام إلى حالة GDPR الـ30 يومًا وتُضرَب بالنسبة slaDays / 30، حتى يتحوّل الطلب دائمًا إلى كهرماني وأحمر عند النسبة ذاتها من موعده النهائي. escalation_due ينفّز 5 أيام قبل الموعد النهائي القانوني (slaDays − 5). بالنسبة لـ GDPR (sla_days: 30): أخضر (< 20 يومًا مُنقضت)، وكهرماني (20–25)، وأحمر (26–30)، وأحمر + خرق (> 30)؛ escalation_due عند يوم 25. بالنسبة لـ CCPA/CPRA (sla_days: 45) تعطي النسب ذاتها أخضر (< 30) وكهرماني (30–38) وأحمر (39–45) وأحمر + خرق (> 45)؛ escalation_due عند يوم 40. اقرأ دائمًا حدود المستوى مقابل sla_days المعادة لذلك الطلب، لا الأرقام الثابتة 20/25/30.

البوابة العامة للخدمة الذاتية

يتيح المسار العام لصاحب البيانات تقديم طلب دون حساب. الهوية تُثبَت بـ OTP لعامِلَين — رمز بريد إلكتروني ورمز SMS — قبل إضافة أي طلب إلى قائمة الانتظار. تعيش نقاط النهاية تحت /compliance/public/dsar وهي غير متطلِّبة للمصادقة، لكنها مُحَصَّنة بـ Cloudflare Turnstile وحدود المعدّل لكل IP ولكل مُعرِّف، وشكل الرد المناسِك للخصوصية لا يكشف أبدًا إن تُطابَقت ثنائية البريد/الهاتف جهة اتصال حقيقية.
رموز التحقق عبر SMS تُسلَّم عبر softswitch من Devotel (مسار SMS الصادر الوحيد للمنصّة). وهي OTP منصّية، لا حركة قابلة للفوترة من المستأجر، ولا تحمل أي دوام لإيصالات التسليم.

نظرة عامة على المسار

1

البدء

POST /compliance/public/dsar/begin مع email وphone (E.164) وrequest_type (access | delete | portability | opt_out) وturnstile_token من Cloudflare (مطلوب في الإنتاج). يعيد claim_id غير شفّاف وemail_sent: true وexpires_in: 600. يُرسَل OTP البريد فورًا.
2

التحقق من البريد

POST /compliance/public/dsar/verify-email مع claim_id والرمز code المكوّن من 6 أرقام. يعيد الحالة email_verified والخطوة التالية phone_send. تنتهي صلاحية الرموز بعد 10 دقائق؛ حد أقصى 3 محاولات. POST …/resend-email (مع claim_id + email) يصدر رمزًا جديدًا، خاضعًا لتأخير 60 ثانية.
3

إرسال رمز الهاتف

POST /compliance/public/dsar/send-phone مع claim_id وphone الذي يُطابق المُعطى عند البدء. يرسل OTP عبر SMS (expires_in: 600). ينطبق تأخير 60 ثانية بين الإرسالات؛ المحاولة المبكرة تعيد 429 مع Retry-After.
4

التحقق من الهاتف

POST /compliance/public/dsar/verify-phone مع claim_id والرمز code المكوّن من 6 أرقام. يعيد الحالة phone_verified والخطوة التالية submit.
5

الإرسال

POST /compliance/public/dsar/submit مع claim_id. يستمرّ بصفّ تدقيق و — فقط إذا تُطابَقت البريد والهاتف المُتحقَّق بجهة اتصال في مستأجرك — يُضيف DSAR حقيقيًا إلى قائمة الانتظار (مُسبَقًا verification_status: verified، لأن OTP أثبت الهوية بالفعل). يعيد reference_id (مثل dsar_pub_…) وقيمة queued منطقية.

تهيئة مرسِلي إثبات الهوية

يُرسَل الرمزان OTP من مرسِلَين على مستوى المنصّة تهيّئهما مرة واحدة في بيئة API لديك. اضبطهما قبل نشر البوابة — مرسِل SMS غير مضبوط بدون بديل يجعل خطوة الهاتف تفشل إغلاقًا (fail-closed). إذا كان DEVOTEL_DSAR_PROOF_SMS_FROM وDEVOTEL_PLATFORM_DEFAULT_FROM كلاهما غير مضبوط، فإن خطوة send-phone تفشل إغلاقًا بـ 503 — تعود البوابة برسالة «غير متاحة مؤقتًا» ويُبثّ الفشل تحت مقياس dsar.proof.sms_send_failed حتى يطفو في لوحاتك بدل تخطّي العامل الثاني صامتًا. بالمثل، خطوة البريد تعود بـ 503 عندما تكون DEVOTEL_RESEND_API_KEY غير مضبوطة. هيّئ كلا المرسِلَين قبل أن تربط البوابة علنًا.

دفاعات إساءة الاستخدام

شكل الرد مطابق سواء تُطابَقت المُعرِّفات جهة اتصال حقيقية أم لا — البوابة لا تؤكّد ولا تنفي أبدًا أن شخصًا ما في قاعدة بياناتك. عندما يكون Redis غير متاح، تتفشّى بوّابات الحدّ من المعدّل فتحًا (fail-open) للحفاظ على التوافر.

تمكين حماية Turnstile

بوّابة Turnstile تُهيَّأ بمتغيّرين بيئيّين.
البوّابة فاشلة فتحًا (fail-open) عندما تكون DEVOTEL_TURNSTILE_SECRET_KEY غير مضبوطة: begin يقبل الطلبات بدون رمز ويُسجّل تحذيرًا واحدًا. اضبط السرّ في الإنتاج، وإلا تصبح البوابة غير محمية بـ Turnstile حتى مع بقاء كل دفاع إساءة آخر أعلاه مطبّقًا. ولّد كلا المفتاحين في لوحة تحكم Cloudflare (Turnstile → Add site) واضبطهما على نشر API وWeb على التوالي.

إيواء رابط البوابة

انشر البوابة العامة تحت سياسة خصوصيتك كرابط «تقديم طلب خصوصية». لأن المسار يتحقّق ذاتيًا عبر OTP، فإن الطلبات التي تصل عبره قد أُثبِتت هويتها بالفعل — تهبط في قائمة انتظار المشغّل جاهزة للتنفيذ، وتظهر في GET /compliance/dsar بجانب الطلبات المقدَّمة من المشغّل.

مراجع ذات صلة