Skip to main content

DSAR self-service portalı uçtan uca

Devotel Orbit, ilgili kişi taleplerini iki intake yolu üzerinden kabul eder: operatörlerinizin bir kişi adına file yapması ve ilgili kişinin kendi başvurduğu public portal. Tek bir kuyruk ikisini besler. Bu rehber portal yolunu link yayınlamadan yerine getirilmesine kadar izler ve operatör-file ile nasıl birleştiğini gösterir. DSAR referansı (EN) endpoint yüzeyini ve public e-posta/telefon claim durum makinasını belgeler; bu sayfa üzerinden çalıştığınız runbook’tur.
Buradaki her kontrol tenant’a aittir: siz linki yayınlarsınız, siz kuyruğu yürütürsünüz, siz karar verir ve yerine getirirsiniz. Orbit portalı barındırır, iki faktörlü OTP ile kimlik kanıtı sağlar ve yasal süreleri takip eder — cevap verme yasal yükümlülüğü sizde, veri sorumlusunda, kalır. Yükümlülüklerinizi hukuk danışmanınızla netleştirin.

1. İki intake yolu, tek kuyruk

Operatör-file. Ekibiniz POST /compliance/dsar ile ya da Settings → Compliance → DSAR içindeki Create DSAR diyaloğu ile talebi file eder. Bu yoldan file edilen talep verification_status: pending olarak başlar — operatör kimlik incelemesini onaylamadan veya reddetmeden export ya da silme workeri dokunmaz. Bu yol şu an uygundur: tanıdığınız kişiler (oturum açık bir müşteri, workspace’inizdeki bir contact) ve public form taşıyamayacağı haklar (correction, limit-sensitive-PI, non-discrimination). Public self-service portal. İlgili kişi talebini barındırılan public sayfa üzerinden kendisi file eder — hesap yok, API anahtarı yok, oturum yok. Sayfa kimliği kuyruğa herhangi bir şey girmeden önce iki faktörlü e-posta + SMS OTP ile doğrular, böylece bir portal file önceden doğrulanmış olarak gelir ve export/silme workeri hemen başlar. İkisini de çalıştırın. Portal tüketici hacmini sıfır operasyon dokunuşa götürür; operatör-file portalın çevreleyemediği uç dosyalarını kapsar. İki yolun da talebi aynı Settings → Compliance → DSAR listesine ve aynı GET /compliance/dsar yanıtına düşer — tek kuyruk, tek SLA bannerı, tek audit zinciri.

2. Portal turu

Linki yayınla

Portalı gizlilik politikanız, site footer’ınız veya üründeki privacy center’da “Gizlilik talebi gönder” linki olarak yayınlayın:
<locale> her Orbit web sayfasının taşıdığı aynı locale prefix’idir (en, fr, de, …). Sayfa iki adımlı identifier formunu Cloudflare Turnstile bot kontrolünün ardında render eder: kişi e-posta ve telefonunu (E.164) girer, bir talep türü seçer ve kimlik kanıtı başlar.

Gönderici e-posta önkoşulu

Portal doğrulama kodlarının hangi adreslerden gönderileceğini link canlıya çıkmadan önce kararlaştırın — göndericisi ayarlanmamış bir portal public’te kapalı kalır. İki platform-seviye gönderici API ortamınızda bir kez yapılandırılır: SMS gönderici yoksa ve platform fallback yoksa, telefon adımı 503 döner ve portal “geçici olarak kullanılamıyor” mesajı gösterir; e-posta teslim anahtarı yoksa e-posta adımı da aynı şekilde düşer. Üretimde ilk adım ayrıca bir Turnstile token ister — Cloudflare dashboard’undan (Turnstile → Add site) alınan DEVOTEL_TURNSTILE_SECRET_KEY API’de ve NEXT_PUBLIC_DEVOTEL_TURNSTILE_SITE_KEY web dağıtımında ayarlanır. SMS doğrulama kodları Devotel softswitch üzerinden platform OTP’si olarak gider — tenant’a faturalanan trafik değildir.

İlgili kişi ne görür

Kişi beş adımlı bir claim tamamlar; iki kanıt yerleşene kadar kuyruğa hiçbir şey girmez:
  1. Begin — e-posta, telefon (E.164), talep türü. E-posta OTP’si hemen gönderilir.
  2. Verify email — 6 haneli e-posta kodu (10 dakikalık TTL, 3 deneme, 60 saniye yeniden-gönder soğutması).
  3. Send phone code — aynı telefona SMS OTP (gönderiler arasında 60 saniye soğutma).
  4. Verify phone — 6 haneli SMS kodu.
  5. Submit — talep kuyruğunuza ancak iki kanıt birden ile gelir. Tüm claim’in uçtan uca TTL’i 30 dakikadır.
Kişinin seçtiği dost türler operatör enumuna mapplenir: Identifier’ler workspace’inizde hiçbir contact’a uymuyorsa, submit adımı yine aynı şekilde döner — portal asla bir contact’in var olup olmadığını açıklamaz — ve audit satırı platform ölçeğinde yazılır ki forensic iz eşleşme olmayan durumda da yaşasın.

Jurisdiction SLA saatine mapplenir

Kişi talebinin düştüğü jurisdiction’ı seçer; bu seçim hem satırın taşıyacağı yasal saati hem de kuyruğun tutabileceği request_type değerlerini belirler: Eşleştirmeyi doğru yapmak önemli: opt_out_sale ve limit_sensitive_pi için GDPR eşleniği yoktur ve operatörün default jurisdiction’ı gdpr’dir — Kaliforniyalı tüketicilerde açıkça ayarlayın. Portal opt_out file’ının jurisdiction’ını tam da GDPR varsayılanı aksi halde geçersiz olacağı için CCPA/CPRA’ya varsayılar. Kişinin yanlış seçimi düzeltilebilir: kuyruktan jurisdiction’ı yeniden sınıflandırın, SLA rozeti yeniden yerine oturur.

3. Bir file sonrası operatörler ne görür

Bir contact’a uyan portal file’i Settings → Compliance → DSAR’da operatör-file’larıyla yan yana düşer. OTP kimliği zaten kanıtladığı için verification_status: verified olarak gelir — onay/red geçidi onu bloklamaz.
  • Durum ve deadline. Satır normal yaşam döngüsü durumunu ve jurisdiction penceresine yerleşmiş Day X of N SLA rozetini taşır; herhangi bir ihlal workspace seviyesindeki SLA bannerını yakar. GET /compliance/dsar/sla aynı resmi API üzerinden verir.
  • Silme sınıfı file’lar. “delete” seçen bir kişi Erasure requests (Art. 17) sekmesinin portal bölümünde, SLA rozeti yanında, varsayılan 7 günlük cooling-off penceresinin önünde görünür.
  • Yerine getirme. Bir access ya da portability file’ı signed export_url ile Completed’a ulaşır; Download decrypted aksiyonu operatör için plaintext export’u derler. Bir silme, yürütüldükten sonra Proof of deletion sertifikasını ve bağlı hedeflerinize Propagate’i sunar.
  • Audit zinciri. Begin, iki doğrulama ve submit; hashlenmiş (asla ham değil) identifier’lar, kaynak IP ve user agent ile satırlar yazar — bir regülatör kimliğin nasıl kurulduğunu sorduğunda evidence binder (EN) içinden çektiği kayıt budur.

4. Orbit ne yapmaz

Portal, intake ve kimlik kanıtı makinesidir; yasal kararlar sizde kalır:
  • Orbit geçerliğe asla karar vermez. Bir talebi yasal gerekçelerle asla kabul etmez veya reddetmez. Verification pending satırları sizin onay/red kararınızı bekler; verified satırlar yerine getirilir çünkü siz izin verirsiniz, platform claim’i yargıladığı için değil.
  • Orbit operatör hükmünü asla otomatik yerine getirmez. Operatör-file bir talepte verification_status: pending iken export üretilmez, hiçbir şey silinmez. Bir portal file’ı geçidi yalnızca OTP’si kimliği zaten kanıtladığı için atlar.
  • Silme, cooling-off pozisyonunuza saygı duyar. 7 günlük varsayılan (tenant başına override edilebilir) size imhadan önce reddetme, tutma veya muaf tutma penceresi verir.
  • Hangi kanunun uygulandığını söylemek hâlâ hukuk danışmanınızın işi. Orbit SLA saatini, kişinin seçtiği ve sizin onayladığınız jurisdiction’a bağlar.
  • Portal tüketici dostu haklar alt kümesini yüzeyler — operatör-only bir hakka (correction, limit-sensitive-PI, non-discrimination) ihtiyacı olan kişi ekibiniz üzerinden file eder.

Portal claim döngüsü — çalıştırılabilir istek örnekleri

Portalın altı kimliksiz verb’i /api/v1/compliance/public/dsar altında yaşar (tam yüzey: DSAR referansı (EN)). Bu, portal sayfasının çalıştırdığı zincirin aynısıdır ve uçtan uca script’lenebilir — linki yayınlamadan önce bir dağıtımı smoke-test etmek veya bir regülatöre kimlik kanıtı yolunu göstermek için kullanışlıdır. API anahtarı yoktur: OTP çifti kanıtın kendisidir, bu yüzden herhangi bir operatör anahtarı public çağrıyı zayıflatır.

1. Claim’i başlat

202
claim_id’yi saklayın — sonraki her adım ona referans verir. Yanlış e-posta formatı, E.164 dışı telefon veya hatalı Turnstile token 422 VALIDATION_ERROR döner; IP-başına ve e-posta-başına geçitler Retry-After header’ı ile 429 döner. Begin adımı çift bir contact’le eşleşsin ya da eşleşmesin aynı şekilde cevap verir — çağıranlar contact ikililerinizi enumerate edemez.

2. E-posta kodunu doğrula

200
Yanlış veya bayat bir kod, portal sayfasının gösterdiği envelope’in aynısını döner:
422
Süresi dolmuş kod, kullanılmış kod ve üçüncü başarısız deneme, her biri kendi 422 mesajını döner (“Code expired. Please request a new one.”, “Too many attempts. Please start over.”) — POST /api/v1/compliance/public/dsar/resend-email 60 saniyelik cooldown sonrasında taze bir e-posta kodu verir.

3. Telefon kodunu gönder ve doğrula

60 saniyelik SMS cooldown içinde yeniden gönderim Retry-After ile 429 döner. Ardından:
200

4. İki kanıt yerleşikken submit et

201
queued: true, çiftin bir workspace contact’iyle eşleştiği ve talebin kuyruğunuza girdiği anlamına gelir; queued: false eşleşmeme durumudur — aynı şekil, yani bir çağıran ayırt edemez. İki kanıt geçmeden submit ederseniz “Both verification steps must complete before submission.” ile 422 alırsınız. dsar_pub_… referansı audit satırı id’sidir; evidence binder (EN)‘ın çektiği identifier’ın aynısı.

5. Operatör kuyruğunda geri oku

Operatör tarafı owner/admin API anahtarı veya aynı seviyede bir dashboard oturumu ister:
200
Dost kişi verb’inin operatör enumuna çoktan mapplenmiş (access → know) ve verification_status: verified olduğuna dikkat — sizi bekleyen bir intake geçidi yok. Yasal deadline, SLA payload’unun işidir:
200
sla_deadline_at, dashboard’un Day X of 30 rozetinin yerleştiği mutlak vade tarihidir; breach_count > 0 workspace banner’ını yakan değerdir. Bunların hiçbiri talebi yerine getirmez — kuyruk, hüküm ve yerine getirme hâlâ sizindir; bu döngü yalnızca kişinin iddia ettiği kişi olduğunu kanıtlar ve file’ını doğru saate düşürür.

5. Uçtan uca örnek — bir GDPR access talebi

Berlin’de bir müşteriniz gizlilik politikanızı açar, portal linkine dokunur ve tuttuğunuz her şeyi ister. Sıra:
  1. Begin. E-postasını ve E.164 telefonunu (+4915…) girer, access seçer ve Turnstile kontrolünü geçer. Portal bir claim id döndürür; e-posta OTP’si zaten yoldadır.
  2. Verify email. 6 haneli kodu (10 dakikalık TTL, en fazla 3 deneme) okur ve ilk faktörü geçer.
  3. Send phone code, Verify phone. İkinci faktör SMS ile tekrarlar — gönderimler arasında 60 saniye soğutma — ve her iki kanıt da artık yerleşiktir.
  4. Submit. Portal talebi file eder. E-posta ve telefonu workspace’inizdeki bir contact ile eşleştiği için satır gdpr altında know olarak kuyruklanır ve dsar_pub_… referansı döner.
  5. Kuyruğunuzda. Satır Day 1 of 30 gösterir — verification_status: verified — ve export workeri zaten üzerindedir. Ekibiniz triage’e hiç dokunmaz.
  6. Yerine getir. Worker export’u derler ve satırı export_url ile Completed işaretler. Bir operatör indirme linkini teslim eder (operatör-only plaintext kopyası Download decrypted ile bir tık).
  7. SLA çizgisinin üzerinde. Satır 30 günlük GDPR penceresi dolmuşken açık kalırsa, workspace SLA bannerı onu işaretler — ve intake sırasında yanlış jurisdiction seçilmişse, kuyruk yeniden sınıflandırması saati geriye dönük düzeltir.
Kişinin ilk form gönderiminden kuyruğa düşen talebe süre: iki OTP gidiş-dönüşü. Operatör dokunuşları: sıfır.

İlgili referanslar