طلبات الوصول إلى بيانات صاحب البيانات (DSAR)
طلب الوصول إلى بيانات صاحب البيانات (يُسمّى أيضًا طلب الخصوصية أو طلب حقوق المستهلك) هو الآلية الرسمية التي يستخدمها الشخص لممارسة حقوقه على البيانات الشخصية التي تحتفظ بها عنه — حق الوصول، والحذف، والتصحيح، والنقل، وإلغاء الاشتراك في بيع تلك البيانات. تمنحك معظم قوانين الخصوصية موعدًا نهائيًا صارمًا للرد (30 يومًا بموجب GDPR و45 يومًا بموجب CCPA/CPRA). تمنحك Orbit مسارَين للاستقبال ومسارًا واحدًا للتنفيذ:- DSAR المقدَّم من المشغّل — يقدّم فريق الدعم أو الامتثال لديك الطلب نيابةً عن عميل عبر واجهة API المعرَّفة أو لوحة التحكم.
- البوابة العامة للخدمة الذاتية — يقدّم صاحب البيانات طلبه بنفسه عبر مسار عام غير متطلِّب للمصادقة يثبت هويته برمز OTP لعامِلَين عبر البريد الإلكتروني + SMS قبل إضافة أي شيء إلى قائمة الانتظار.
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.
دورة حياة الحالة
ينتقل الطلب عبر:received → processing → completed
مع فروع نهائية failed وexpired وcancelled. تُتعقَّب حالة
التحقق الفرعية باستقلالية: pending → verified (يتابع العامل)
أو 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 مشترَكة للتصدير والإزلة حتى
لا تفوّت موعدًا نهائيًا قانونيًا أبدًا:
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 تُهيَّأ بمتغيّرين بيئيّين.إيواء رابط البوابة
انشر البوابة العامة تحت سياسة خصوصيتك كرابط «تقديم طلب خصوصية». لأن المسار يتحقّق ذاتيًا عبر OTP، فإن الطلبات التي تصل عبره قد أُثبِتت هويتها بالفعل — تهبط في قائمة انتظار المشغّل جاهزة للتنفيذ، وتظهر فيGET /compliance/dsar بجانب الطلبات المقدَّمة من المشغّل.
مراجع ذات صلة
- تجميع وضعية GDPR كاملة — موضع استقبال DSAR في المسار الكامل.
- إدارة الموافقة — سجّل وابحث عن حالة الموافقة التي قد يطلب منك DSAR احترامها.
- قوائم إلغاء الاشتراك والكبح —
كيف تسري نتائج
delete/opt_outإلى الكبح. - موافقة تسجيل المكالمات — معالجة التسجيلات التي يشير إليها طلب الوصول.
- مرجع API → الامتثال — مخططات الطلب/الرد الكاملة (مُعاد إنشاؤها من API الحيّ).