DSAR بدون دردسر: حق دسترسی و حذف داده در ردیاب
مادههای 15 و 17 منتظر آنالیتیکس نمیمانند. اینجا میبینید چطور نقطههای پایانی دسترسی و حذف داده را طوری طراحی کنید که گزارشهای تجمیعیتان خراب نشود — و ما خودمان چه چیزی ساختیم.
این مطلب یک پژوهش در حوزه حریم خصوصی است، نه مشاوره حقوقی. برای دیدن متن کامل سلب مسئولیت، به پانوشت مراجعه کنید.
خلاصه مطلب
- مادههای 15 و 17 شامل آنالیتیکس وب هم میشوند — شناسههای مستعار مانند IP درهمسازیشده، شناسههای کوکی و امضای بازدیدکننده BLAKE3-HMAC طبق رویهی Breyer، IAB Europe و رأی دادگاه تجدیدنظر بروکسل در 14 مه 2025 همچنان داده شخصی به شمار میآیند.
- سه نقطه پایانی ساخته شده است —
POST /api/privacy/opt-out،GET /api/privacy/access،POST /api/privacy/erase— هر سه در برابر CSRF محافظتشده، با محدودیت نرخ و ثبت در گزارش حسابرسی. - جدولهای تجمیعی پس از حذف داده باقی میمانند چون پیشتر تا جایی تجمیع شدهاند که دیگر هیچ فردی قابل شناسایی نیست — طرحوارههای HyperLogLog از نوع
uniqCombined64فقط شمارش هستند، نه رکورد، و سهم تکتک افراد را نمیتوان از آنها بازگرداند. - 8 رویداد حسابرسی حریم خصوصی شواهد پاسخگویی ماده 28(3)(h) را بهشکل ساختاریافته تولید میکنند — این رویدادها انصراف، دسترسی، حذف، رضایت دادهشده/پسگرفتهشده و بازدید صفحههای حقوقی را پوشش میدهند.
- تمرکز اجرایی EDPB در 2025 روی حق حذف داده در چارچوب هماهنگ بود؛ تمرکز EDPB در 2026 به سمت تعهدات شفافیت میرود. هر دو با همان معماریای که در این مطلب آمده همخوانی دارند.
چرا آنالیتیکس فراموششدهترین سطح DSAR است
بیشتر گردشکارهای پاسخ به درخواست دسترسی صاحب داده (DSAR) در GDPR حول سیستمهایی ساخته شدهاند که داده شخصی آشکارا در آنها زندگی میکند — CRM، تیکتهای پشتیبانی، تاریخچه سفارشها و فهرستهای ایمیلمارکتینگ. لایهی آنالیتیکس وب معمولاً در آخر به ذهن میرسد و وقتی هم مطرح میشود، اولین واکنش گرداننده اغلب این است: «آنجا داده شخصی نیست، ما که IPها را درهمسازی کردهایم.» اما این برداشت هم از نظر قانون اشتباه است و هم روزبهروز از نظر معماری بیشتر اشتباه میشود.
پیشنویس رهنمودهای 01/2025 EDPB درباره مستعارسازی — که بهعنوان پیشنویس در صد و یکمین نشست عمومی در 16 ژانویه 2025 تصویب شد، تا 28 فوریه 2025 برای مشورت عمومی باز ماند و تا مه 2026 هنوز در دست تدوین است — روشن میکند که داده مستعارسازیشده، از جمله IPهای درهمسازیشده، شناسههای کوکی، امضای بازدیدکننده BLAKE3/HMAC و رشتههای TC، تا وقتی بازشناسایی با ابزارهای در دسترس کنترلگر یا هر شخص ثالثی بهطور معقول محتمل باشد، همچنان داده شخصی است. رأی IAB Europe دیوان دادگستری اتحادیه اروپا (C-604/22، 7 مارس 2024) که با رأی دادگاه تجدیدنظر بروکسل در 14 مه 2025 (پرونده 2022/AR/292) تأیید شد، این موضوع را از رشتههای TC فراتر میبرد و به هر شناسهای که با یک IP جفت شده باشد تعمیم میدهد. Breyer (C-582/14، 19 اکتبر 2016) خیلی پیشتر تکلیف پرسش گرداننده–IP را روشن کرده بود.
بهزبان ساده، یعنی: آنالیتیکس وبی که IP، کوکیهای درهمسازیشده، امضای بازدیدکننده BLAKE3-HMAC یا هر شناسهای بهازای هر بازدیدکننده را پردازش میکند، در معنای GDPR در حال پردازش داده شخصی است. بنابراین ماده 15 (حق دسترسی) و ماده 17 (حق حذف داده) اعمال میشوند. ماده 28(3)(e) از پردازشگر — اگر پردازشگری در کار باشد — میخواهد که کنترلگر را در پاسخ به این درخواستها یاری کند. مهلت اطلاعرسانی نقض داده در ماده 33 هم شامل نقضهایی میشود که این شناسهها را درگیر میکنند.
آنچه در ادامه میآید، راهنمای عملی گرداننده است. کالبدشکافی یک DSAR آنالیتیکس، سه نقطه پایانیای که Statnive Live ارائه میدهد، رد حسابرسی لازم، اینکه چطور گزارشهای تجمیعی پس از حذف داده باقی میمانند، یک دفترچه راهنمای DSAR که برای توسعهدهنده دوستداشتنی است و یک نمونه کد عملی.
کالبدشکافی یک DSAR آنالیتیکس
یک DSAR علیه لایهی آنالیتیکس وب شبیه یک DSAR علیه CRM نیست. اینجا نه آدرس ایمیلی هست، نه نام مشتریای، نه کلید اصلی آشکاری. صاحب داده تماس میگیرد و در عمل میگوید: «من گاهی به سایت شما سر میزنم. چه چیزی از من دارید و لطفاً آن را حذف کنید.»
گرداننده واقعاً چه چیزی در اختیار دارد؟
برای یک لایهی آنالیتیکس اولشخص و بدون کوکی مانند Statnive Live در حالت consent-free، پاسخ این است: یک امضای مستعار با دامنه روزانه که از IP بازدیدکننده، User-Agent، دامنه سایت و یک نمک چرخشی روزانه ساخته میشود و در پایان روز نابود میشود. این معماری بهتفصیل در راهنمای آنالیتیکس بدون رضایت اتحادیه اروپا 2026 شرح داده شده است. امضای هر روز تا وقتی نمک در 00:00 به وقت UTC روز بعد چرخش کند، در جدول رویدادهای خام وجود دارد؛ پس از چرخش، چون نمکی که آن را ساخته دیگر نیست، امضا عملاً برگشتناپذیر میشود. گزارشهای تجمیعی آن امضا را پیش از چرخش نمک به شمارش تبدیل میکنند، بنابراین شناسهی هر بازدیدکننده اصلاً در جدولهای تجمیعی حضور ندارد — فقط شمارش بازدیدکنندگان یکتا در هر روز، صفحه یا منبع.
برای یک استقرار Statnive Live از نوع consent-required یا hybrid که در آن رضایت داده شده، علاوه بر این یک شناسه کوکی (یک UUID خام) به مرورگر فرستاده میشود. سرور SHA-256(master_secret || site_id || cookieID) را با پیشوند h: بهعنوان کلید پایداری ذخیره میکند. تداوم بازدیدکننده در طول چند روز، بهجای نمک چرخشی روزانه، با شناسه کوکی درهمسازیشده حفظ میشود.
سه نتیجه از این موضوع به دست میآید:
- دسترسی ماده 15. صاحب داده میتواند چیزی برای جستوجو به گرداننده بدهد — معمولاً شناسه کوکی از مرورگرش (اگر در نشست فعلیاش موجود باشد) یا توصیفی از بازدیدش (تاریخ، صفحه، زمان تقریبی، IP از یک شبکه شناختهشده). گرداننده میتواند رویدادهای منطبق را برگرداند.
- حذف داده ماده 17. گرداننده میتواند همان رویدادها را پیدا کند و حذف کند. هر رکوردی که گرداننده بتواند شناسایی کند، همان رکوردی است که میتواند حذف کند.
- آنچه قابل شناسایی نیست، نه قابل حذف است و نه قابل نگهداری. نابودی نمک روزانه در 00:00 به وقت UTC، حذفی خودکار و همزمان از توان بازشناسایی بینروزی است. امضای نشست-روز-1 یک بازدیدکننده، بهمحض نابودی نمک روز 1، برای همیشه از امضای نشست-روز-2 او جدا میشود؛ درخواست ماده 17 که در روز 2 به دست گرداننده میرسد نمیتواند حذف رکوردهای روز 1 را بخواهد، چون این رکوردها قابل مکانیابی نیستند — اما این هم اشکالی ندارد، چون دیگر قابل بازشناسایی نیستند.
این معماری طوری طراحی شده که نگهداری پایدارِ دادهی قابل شناسایی کم بماند. چرخش نمک، بخش بزرگی از کار دادهکمینگی ماده 5(1)(c) GDPR را بهرایگان انجام میدهد. درخواستهای DSAR علیه یک لایهی آنالیتیکس با این معماری ذاتاً کمحجمتر از درخواستهای DSAR علیه CRM هستند — بیشتر بازدیدکنندگان بهمحض چرخش نمک، اصلاً هیچ رکوردی بهازای هر بازدیدکننده باقی نمیگذارند.
سه نقطه پایانی
Statnive Live بهطور پیشفرض سه نقطه پایانی حریم خصوصی ارائه میدهد. هر سه در برابر CSRF محافظتشدهاند، محدودیت نرخ دارند و رویدادهای حسابرسی ساختاریافته تولید میکنند.
POST /api/privacy/opt-out
نقطه پایانی حق اعتراض ماده 21. بازدیدکننده این را از دکمهای در سیاست حریم خصوصی گرداننده فرا میخواند. سرور این انصراف را بهشکل یک کوکی اکیداًضروری که بیانگر انتخاب کاربر است ثبت میکند (طبق ePrivacy § 25(2)(ii) / TDDDG / و نظایر ملی آن مجاز است، چون ترجیح صریحاًدرخواستشدهی کاربر برای این سرویس را پیاده میکند). درخواستهای دریافت بعدی از همان مرورگر، پیش از آنکه امضای بازدیدکننده محاسبه شود، در لایهی دریافت کنار گذاشته میشوند.
از سوی دیگر، انصراف را میتوان سمت سرور هم پایدار کرد؛ یعنی با یک فهرست سرکوب که بر پایهی امضای درهمسازیشدهی بازدیدکننده کلیدگذاری شده و TTL مناسبی دارد — این انتخاب در دست گرداننده است.
این نقطه پایانی رویداد حسابرسی privacy.opt_out_received را همراه با زمان، شناسه سایت و درهمسازیای از امضای بازدیدکننده تولید میکند تا با گزارش حسابرسی ارجاع متقابل بخورد.
GET /api/privacy/access
نقطه پایانی حق دسترسی ماده 15. بازدیدکننده این موارد را فراهم میکند:
- شناسه کوکیای که هماکنون در مرورگرش ذخیره است (اگر وجود داشته باشد)، یا
- یک شناسه از پیشاشتراکگذاشتهشدهی امضاشده (برای گردانندگانی که با درگاه DSAR خودشان یکپارچه میشوند)، یا
- توصیفی از بازدیدش که آنقدر دقیق باشد که گرداننده بتواند آن را مکانیابی کند (تاریخ، صفحه، زمان تقریبی، شبکهی منبع).
این نقطه پایانی رویدادهای موجود در پرونده را برمیگرداند. پاسخ یک شیء JSON است شامل رویدادهای خامی که با جستوجو منطبقاند، بهعلاوهی فرادادهی برگرفته از گزارش تجمیعی که به بازدیدکننده مربوط میشود (اینکه بازدیدش در کدام سطلهای تجمیعی سهم داشته، بدون آنکه دیگر بازدیدکنندگان همان سطل افشا شوند). رویداد حسابرسی: privacy.dsar_access_requested.
POST /api/privacy/erase
نقطه پایانی حق حذف داده ماده 17. جستوجو همان جستوجوی ماده 15 است. این نقطه پایانی، جدولهای بکاند ذخیرهسازی را بهشکل پویا برمیشمارد — با دروننگری system.tables روی ClickHouse — و سطرهای منطبق را از هر جدولی که ستون visitor_signature یا cookie_id_hash دارد حذف میکند. این برشماری پویا عمدی است: اگر در آینده جدولی به طرحواره اضافه شود که شناسه بازدیدکنندهای داشته باشد اما به مسیر حذف افزوده نشده باشد، بهحالت بسته شکست میخورد؛ چون آزمون یکپارچگیای که برشماری پویا را بررسی میکند، هر جدولی را که طرحواره میشناسد پوشش میدهد.
گزارشهای تجمیعی حذف نمیشوند. دلیلش — که دلیلی منطبق با GDPR هم هست — در بخش بعدی آمده است. رویداد حسابرسی: privacy.dsar_erase_requested.
هر سه نقطه پایانی، درخواستهای میانمبدأ امضانشده را رد میکنند، به یک توکن CSRF برگرفته از نشست گرداننده نیاز دارند و برای جلوگیری از سوءاستفاده، نرخ را بهازای هر IP و هر زوج (IP, site_id) محدود میکنند. گزارش حسابرسی جدا از دیتابیس آنالیتیکس است و طبق سیاست نگهداری گزارش حسابرسی گرداننده نگهداری میشود — معمولاً طولانیتر از پنجرهی 25 ماههی گزارش تجمیعی آنالیتیکس.
چرا گزارشهای تجمیعی پس از حذف باقی میمانند — و چرا این درست است
شهودیتریننقطهضعفِ طراحی DSAR آنالیتیکس، بقای جدولهای تجمیعی پس از یک درخواست حذف ماده 17 است. اولین واکنش معمولاً این است: اگر کاربر میخواهد حذف شود، حتماً باید همهی دادههای مربوط به او برود، از جمله شمارشهایی که در آنها سهم داشته؟
پاسخ به این بستگی دارد که جدول تجمیعی واقعاً چه چیزی در خود دارد. یک سطر در hourly_visitors برای مثال این را ثبت میکند: site_id=X، hour=Y، unique_visitors=4271. این سطر نه امضای بازدیدکننده را در خود دارد، نه IP بازدیدکننده را و نه هیچ شناسهای بهازای هر بازدیدکننده. آنچه دارد یک طرحوارهی HyperLogLog از نوع uniqCombined64 است — یک ساختار دادهی احتمالاتی که بدون ذخیرهی مقادیر تکتک، برآوردهای دقیقی از تعداد یکتاها میدهد. طرحوارهی uniqCombined64 یک شمارش است، نه سابقهای از اینکه چه کسی. سهم بازدیدکننده در این شمارش را نمیتوان از طرحواره بازگرداند.
این موضع استاندارد EDPB درباره دادهی تجمیعی است: همینکه داده تا فراتر از نقطهی قابلیت شناسایی تجمیع شد — فراتر از جایی که بتوان سهم هر فردی را بازسازی کرد — دیگر داده شخصی نیست. توصیهی صفحه 16 CNIL مبنی بر تجمیع تا نزدیکترین مضرب 10 هم بر همین اصل استوار است. تحلیل ناشناسسازی گارانتهی ایتالیا در پروندهی Caffeina Media هم بر این میچرخد که آیا بازشناسایی بهطور معقول محتمل است یا نه؛ برای یک شمارش تجمیعی که از طرحواره HyperLogLog به دست آمده، این بازشناسایی محتمل نیست.
اثر عملیاش این است: یک درخواست حذف ماده 17، سطرهای رویداد خام را حذف میکند (سطرهایی که امضای هر بازدیدکننده، موقعیت جغرافیایی برگرفته از IP، ارجاعدهندهی فقط-میزبان و صفحه را در خود دارند) اما جدولهای تجمیعی را دستنخورده باقی میگذارد. پیشخوانهای گرداننده همچنان ترافیک تاریخی آن صفحه را نشان میدهند، اما هیچ سطری در پیشخوان قابل ردیابی به صاحب دادهای که حذف را خواسته نیست.
در سیاست حریم خصوصی گرداننده این موضوع چنین توصیف میشود: «تا فراتر از نقطهی قابلیت شناسایی تجمیع شده.» همین عبارت درست است — نه ادعای بیش از حد «ناشناس»، نه ادعای کمتر از حد «هنوز داده شخصی». گزارشهای تجمیعی، حالت پایدار و منطبق با GDPR برای نگهداری آنالیتیکس هستند.
سقف 25 ماهه روی TTL گزارش تجمیعی (750 روز، از طریق مهاجرت 011_rollup_ttl.sql) در هر حال اعمال میشود. حتی شمارشهای تجمیعی هم بر اساس بازهی زمانی صفحه 16 CNIL خودکار منقضی میشوند.
رد حسابرسی — 8 رویداد حریم خصوصی
Statnive Live هشت رویداد حسابرسی ساختاریافته تولید میکند که سطح حریم خصوصی و حقوقی را پوشش میدهند. این رویدادها شواهد پاسخگویی ماده 28(3)(h) برای حسابرسیای هستند که DPO گرداننده، حسابرس کنترلگر یا یک مرجع حفاظت داده انجام میدهد:
| رویداد | محرک | هدف |
|---|---|---|
privacy.opt_out_received | POST /api/privacy/opt-out | ثبت اعتراض ماده 21 |
privacy.dsar_access_requested | GET /api/privacy/access | آغاز درخواست ماده 15 |
privacy.dsar_erase_requested | POST /api/privacy/erase | آغاز درخواست ماده 17 |
privacy.consent_given | statnive.acceptConsent() | اعطای رضایت در حالت consent-required / hybrid |
privacy.consent_withdrawn | statnive.withdrawConsent() | پسگرفتن رضایت |
legal.lia_viewed | GET /legal/lia | ارائهی صفحه LIA گرداننده |
legal.dpa_viewed | GET /legal/dpa | ارائهی صفحه DPA ماده 28 |
legal.privacy_policy_viewed | GET /legal/privacy-policy/{lang} | ارائهی صفحه سیاست حریم خصوصی |
هر رویداد یک JSON ساختاریافته است که زمان، شناسه سایت، شناسه درخواست و اثر انگشت مربوط را در خود دارد. گزارش حسابرسی جدا از دیتابیس آنالیتیکس است — نه تجمیع میشود، نه روی TTL 25 ماهه آنالیتیکس منقضی میشود، و طبق سیاست گزارش حسابرسی گرداننده نگهداری میشود (معمولاً طولانیتر و اغلب بهطور نامحدود برای شواهد انطباق).
رد حسابرسی همان چیزی است که گرداننده هنگام بازرسی به یک تنظیمگر تحویل میدهد. سیاست حریم خصوصی، موضع روبهعموم است؛ رویدادهای حسابرسی، شواهد همزمانی هستند که نشان میدهند آن موضع واقعاً پیاده شده است. بستهی پاسخ به بازرسی CNIL معمولاً شامل این موارد است: (الف) LIA، (ب) سیاست حریم خصوصی، (ج) گزارش حسابرسی برای بازهی بازرسی، و (د) خروجی نقطه پایانی حسابرسی رویداد (بررسی سقف 3 رویدادی برای استقرارهای فرانسوی). Statnive Live هر چهار مورد را بهشکل آماده تولید میکند.
دفترچه راهنمای DSAR برای گردانندگان
یک دفترچه راهنمای عملی برای مدیریت یک DSAR علیه یک استقرار Statnive Live:
گام 1: درخواست را شناسایی کنید. صاحب داده تماس میگیرد، معمولاً با ایمیل به نشانی DSAR منتشرشدهی کنترلگر. درخواست باید آنقدر دقیق باشد که گرداننده بتواند داده را مکانیابی کند — معمولاً یعنی شناسه کوکیای که هماکنون در مرورگر بازدیدکننده است (و بازدیدکننده میتواند آن را با DevTools ببیند) یا توصیفی از بازدید که آنقدر دقیق باشد که پنجرهی رویداد را مشخص کند.
گام 2: هویت درخواستکننده را تأیید کنید. ماده 12(6) GDPR به کنترلگر اجازه میدهد وقتی برای تأیید هویت صاحب داده بهطور معقول لازم باشد، شناسایی بیشتری بخواهد. برای درخواستهای آنالیتیکس، اثبات معمولاً این است: در اختیار داشتن شناسه کوکی (بازدیدکننده یک اسکرینشات از DevTools میفرستد که کوکی را نشان میدهد) یا در اختیار داشتن IPای که بازدیدکننده از آن بازدید کرده (ورود احرازشده از همان IP، یا یک چالش بازخوانی). گرداننده نباید بیش از آنچه برای تأیید درخواست لازم است شناسایی بخواهد.
گام 3: پرسوجوی دسترسی را اجرا کنید. گرداننده GET /api/privacy/access را با شناسهی جستوجو فرا میخواند. پاسخ، رویدادهای منطبق است. اگر درخواست یک درخواست دسترسی ماده 15 باشد، همین پاسخی است که باید برای صاحب داده فرستاده شود — با قالب CSV، JSON یا PDF، هرطور که درگاه DSAR گرداننده ترجیح میدهد.
گام 4: حذف را اجرا کنید (اگر خواسته شده باشد). گرداننده POST /api/privacy/erase را با همان شناسهی جستوجو فرا میخواند. این نقطه پایانی، سطرهای منطبق را از هر جدولی که شناسه بازدیدکننده دارد حذف میکند؛ جدولهای تجمیعی دستنخورده باقی میمانند (طبق بخش پیشین). نقطه پایانی، شمار سطرهای حذفشده در هر جدول را برمیگرداند.
گام 5: به صاحب داده تأیید بدهید. ماده 12(3) GDPR تا یک ماه فرصت پاسخ میدهد که برای درخواستهای پیچیده تا دو ماه دیگر هم تمدیدپذیر است. پاسخ گرداننده باید:
- تأیید کند که داده مکانیابی شد و (اگر حذف خواسته شده بود) حذف گردید.
- توضیح دهد چه چیزی نگهداری شد — یعنی تجمیعهای گزارش — و چرا داده شخصی نیستند.
- نگهداری گزارش حسابرسی گرداننده را یادآور شود (این واقعیت که خودِ درخواست DSAR ثبت شده است).
گام 6: پاسخ را در گزارش حسابرسی ثبت کنید. رویدادهای حسابرسی Statnive Live بهطور خودکار هنگامی که گرداننده نقطههای پایانی API را فرا خواند تولید شدند. گرداننده باید پاسخ ارسالی به صاحب داده را در سیستم گستردهتر مدیریت DSAR خود هم ثبت کند (معمولاً سیستم پشتیبانی یا DPMS).
کل این دفترچه راهنما در یک چکلیست نیمصفحهای جا میشود. بیشتر گردانندگانی که برای نخستینبار آن را پیاده میکنند نگراناند که DSAR آنالیتیکس سخت باشد؛ اما در عمل، معماری طوری طراحی شده که داده یا در یک پنجرهی کوچک و خوشتعریف وجود دارد یا اصلاً وجود ندارد. حجم کم است، پرسوجوها محدودند و شکل پاسخ استاندارد است.
یک نمونه یکپارچهسازی عملی
برای گردانندگانی که درگاه DSAR خودشان را با Statnive Live یکپارچه میکنند، الگوی زیر سرتاسری کار میکند:
// Triggered from a DSAR portal after identity verification
async function handleAccessRequest(verifiedRequest) {
const response = await fetch(
`https://app.statnive.live/api/privacy/access?site_id=${SITE_ID}&cookie_id=${verifiedRequest.cookieId}`,
{
method: 'GET',
headers: {
'X-Statnive-CSRF': await getCsrfToken(),
'X-Statnive-Operator-Key': OPERATOR_API_KEY,
},
}
);
if (!response.ok) {
throw new Error(`DSAR access failed: ${response.status}`);
}
const { events, rollup_metadata } = await response.json();
return { events, rollup_metadata };
}
async function handleErasureRequest(verifiedRequest) {
const response = await fetch(
`https://app.statnive.live/api/privacy/erase`,
{
method: 'POST',
headers: {
'X-Statnive-CSRF': await getCsrfToken(),
'X-Statnive-Operator-Key': OPERATOR_API_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({
site_id: SITE_ID,
cookie_id: verifiedRequest.cookieId,
}),
}
);
if (!response.ok) {
throw new Error(`DSAR erasure failed: ${response.status}`);
}
const { rows_deleted_by_table } = await response.json();
return { rows_deleted_by_table };
}کلید گرداننده طبق سیاست چرخش راز گرداننده چرخانده میشود. توکن CSRF بهعنوان بخشی از جریان استاندارد احراز هویت مدیریتی Statnive Live از نشست گرداننده ساخته میشود.
یک استقرار خودمیزبان چه چیزی را تغییر میدهد
برای گردانندگانی که Statnive Live را بهشکل یک استقرار خودمیزبان اجرا میکنند — یعنی نسخهی اجرایی روی زیرساخت خودِ گرداننده — تحلیل کنترلگر/پردازشگر تغییر میکند. در این حالت Statnive اصلاً پردازشگرِ داده آنالیتیکس گرداننده نیست؛ خودِ گرداننده تنها کنترلگر است. هیچ DPAای میان Statnive و گرداننده برای امضا وجود ندارد، چون چیزی نیست که Statnive پردازشگر آن باشد.
نقطههای پایانی DSAR روی نسخهی اجرایی خودمیزبان دقیقاً مثل استقرار میزبانیشدهی Statnive Live SaaS کار میکنند. رویدادهای حسابرسی به مقصد گزارشی که گرداننده انتخاب کرده تولید میشوند (stdout / stderr در استقرارهای کانتینری، syslog روی میزبانهای سنتی، یا یک جدول حسابرسی اختصاصی در راهاندازیهای خودمیزبان). همان نمونه یکپارچهسازی بالا، به همان شکل در برابر نقطه پایانی خودِ گرداننده کار میکند.
اما این تفاوت هست: پاسخ کنترلگر به یک درخواست ماده 15 از سوی صاحب دادهی شخص ثالث، فقط پاسخ خودِ کنترلگر است. هیچ زیرپردازشگر Statniveای برای کمک نیست؛ تیم IT گرداننده، همان پاسخدهندهی DSAR گرداننده است.
این یکی از بدهبستانهایی است که در مطلب خودمیزبان در برابر SaaS خصوصی اروپا پوشش داده شده است. برای گردانندگانی که سیاست سختگیرانهی «هیچ شخص ثالثی به داده دست نزند» دارند (صنایع تنظیمشده، محیطهای جداگانه از شبکه)، شکل خودمیزبان پاسخ تمیز است؛ برای گردانندگانی که سیاست سختگیرانهی «توافق پردازشگرِ امضاشده» دارند (پرسشنامههای فروشنده ISO 27001، تدارکات بزرگ)، شکل SaaS همراه با یک DPA ماده 28 پاسخ تمیز است. معماری DSAR در هر دو حالت به یک شکل کار میکند.
این کار چه چیزی به گرداننده میدهد
نتیجهی عملی:
- یک بستهی پاسخ DSAR تمیز که برای هر درخواست ماده 15 / 17 علیه لایهی آنالیتیکس آماده است. سه نقطه پایانی، هشت رویداد حسابرسی، یک دفترچه راهنما و یک نمونه یکپارچهسازی.
- یک پاسخ قابلدفاع دربارهی بقای گزارش تجمیعی. عبارت «تا فراتر از نقطهی قابلیت شناسایی تجمیع شده» موضعِ همسو با EDPB است؛ TTL 25 ماههی گزارش تجمیعی در هر حال اعمال میشود.
- یک رد پاسخگویی که به یاری حسابرسی ماده 28(3)(h) برای رابطههای پردازشگری و به اصل گستردهتر پاسخگویی ماده 5(2) برای سوابق خودِ کنترلگر نگاشت میشود.
- سازگاری روبهجلو با انتظارات حقوق صاحب داده در ماده 88a Digital Omnibus. متن کنونی، تعهدات ماهوی مادههای 15 و 17 را تغییر نمیدهد؛ نقطههای پایانی DSAR بدون تغییر کار میکنند.
اما این کار این موارد را نمیدهد: راهی برای نگهداری دادهی خام بهازای هر بازدیدکننده فراتر از پنجرهی 25 ماههی گزارش تجمیعی، چون نابودی نمک آن را ناممکن میکند. راهی برای «برگرداندن» یک درخواست حذف، چون حذفها برگشتناپذیرند. راهی برای رد کردن گزارش حسابرسی برای درخواستهای «داخلی»، چون درخواست داخلیای وجود ندارد — هر فراخوانی به این سه نقطه پایانی یک رویداد تولید میکند.
چه کنید و از چه بگذرید
| انجام دهید | انجام ندهید |
|---|---|
| شناسههای درهمسازیشدهی بازدیدکننده را داده شخصی کمخطر بدانید؛ مادههای 15، 17 و 21 را در برابرشان رعایت کنید. | شناسههای درهمسازیشده را «ناشناس» بازاریابی نکنید — «مستعار» واژهی حقوقی درست است؛ دادگاه بروکسل در 14 مه 2025 آن را تأیید کرد. |
سه نقطه پایانی حریم خصوصی (/api/privacy/opt-out، /api/privacy/access، /api/privacy/erase) را با محافظت CSRF، محدودیت نرخ و ثبت در گزارش حسابرسی سیمکشی کنید. | یک پاسخدهندهی DSAR یکبارمصرف که گزارش حسابرسی را دور میزند نسازید — پاسخگویی ماده 28(3)(h) همان بستهی شواهدی است که هنگام بازرسی به آن نیاز دارید. |
| بقای جدول تجمیعی ذیل ماده 17 را بهصورت «تا فراتر از نقطهی قابلیت شناسایی تجمیع شده» توصیف کنید — نه ادعای بیش از حد «ناشناس»، نه ادعای کمتر از حد «داده شخصی». | در پاسخ به یک درخواست ماده 17، سطرهای جدول تجمیعی را حذف نکنید — اینها شمارشهای تجمیعیاند، نه رکورد بهازای هر بازدیدکننده، و بدون هیچ سودی از نظر GDPR، دید ترافیک تاریخی را از دست میدهید. |
| هویت درخواستکننده را طبق ماده 12(6) GDPR تأیید کنید — معمولاً با در اختیار داشتن شناسه کوکی یا یک چالش بازخوانی — پیش از اجرای پرسوجوی دسترسی / حذف. | بیش از آنچه لازم است شناسایی نخواهید؛ رهنمود حق دسترسی 01/2022 EDPB صریح است که زیادهروی، خودِ این حق را از بین میبرد. |
| دفترچه راهنما را مستند کنید و هر رویداد حسابرسی حریم خصوصی را ثبت کنید — تمرکز CEF در 2025 EDPB حق حذف بود، تمرکز CEF در 2026 EDPB شفافیت است. | مدیریت DSAR را کار عملیاتی یکبارمصرف نپندارید — اجرای هماهنگ DPA فعال است و یک رد حسابرسی همزمان همان پاسخ درست است. |
جمعبندی
حق دسترسی و حق حذف داده ذیل مادههای 15 و 17 GDPR شامل آنالیتیکس وب هم میشوند. رهنمودهای 01/2025 EDPB، آرای Breyer و IAB Europe دیوان دادگستری اتحادیه اروپا و موضع یکدست تنظیمگران ملی، همه همین را میگویند. تصمیم معماری این است که چه باید کرد — و پاسخ این است: پنجرهی دادهی هر بازدیدکننده را کوچک کنید (چرخش نمک روزانه)، پنجرهی گزارش تجمیعی را محدود کنید (TTL 25 ماهه)، سه نقطه پایانی (انصراف، دسترسی، حذف) را در دسترس بگذارید، هشت رویداد حسابرسی تولید کنید و موضع را در سیاست حریم خصوصی مستند کنید.
Statnive Live این سطح را بهطور پیشفرض ارائه میدهد. گردانندگان در برابر آن یکپارچه میشوند؛ گزارش حسابرسی شواهد همزمان را ثبت میکند؛ و جدولهای تجمیعی پس از حذف باقی میمانند، چون پیشتر تا فراتر از قابلیت شناسایی تجمیع شدهاند. دردسر DSAR، وقتی هم که سر میرسد، رویهای است — یک مهلت یکماهه، یک گام تأیید، یک فراخوان API، یک ایمیل تأیید — نه معماری.
برای چارچوب گستردهتر حریم خصوصی، به راهنمای آنالیتیکس بدون رضایت اتحادیه اروپا 2026 نگاه کنید. برای اینکه چرا نمک چرخشی روزانه معماری را ذاتاً کمینه میکند، به نقشهی کشوربهکشور سر بزنید. برای اینکه چطور همین رویدادهای حسابرسی، یکپارچهسازی GPC و حالت ترکیبی را تأمین میکنند، به مطلب پیوندشده مراجعه کنید. سطح DSAR، بافت پیونددهندهی هر چهار مورد است.
این مطلب یک پژوهش در حوزه حریم خصوصی است، نه مشاوره حقوقی. نقطههای پایانی DSAR که توصیف شد، ویژگیهایی از نوع در-دسترس-بودن فنی هستند. درستی حقوقی هر پاسخ به یک درخواست ماده 15 / 17 / 21، ذیل ماده 12 GDPR و قانون ملی مربوط، بر عهدهی کنترلگر است. هر مشتری Statnive همچنان کنترلگر داده میماند و مسئول پیکربندی و DPIA خودش است. پیش از انتشار، با مشاور حقوقی واجد صلاحیت در حوزه قضایی خود ارجاع متقابل بگیرید.
وضعیت ارجاعهای مقرراتی تا 13 مه 2026: مادههای 12، 15، 17، 21، 28(3)(e)، 28(3)(h) و 33 GDPR؛ رهنمودهای 01/2022 EDPB درباره حق دسترسی (نسخه نهایی مصوب مارس 2023)؛ رأی C-582/14 Breyer دیوان دادگستری اتحادیه اروپا در 19 اکتبر 2016 (ECLI:EU:C:2016:779)؛ رأی C-604/22 IAB Europe دیوان دادگستری اتحادیه اروپا در 7 مارس 2024؛ رأی دادگاه تجدیدنظر بروکسل در 14 مه 2025 در پرونده 2022/AR/292 (تأییدکنندهی رویهی IAB Europe / رشته TC)؛ پیشنویس رهنمودهای 01/2025 EDPB درباره مستعارسازی (بهعنوان پیشنویس در صد و یکمین نشست عمومی در 16 ژانویه 2025 تصویب شد؛ مشورت عمومی تا 28 فوریه 2025؛ نسخه نهایی تا مه 2026 هنوز منتشر نشده؛ تیم سریع EDPB تکمیل آن را برای تابستان 2026 هدف گرفته است)؛ رهنمودهای 1/2024 EDPB درباره منفعت مشروع در 8 اکتبر 2024؛ تمرکز چارچوب اجرای هماهنگ 2025 EDPB: حق حذف داده (ماده 17)؛ تمرکز چارچوب اجرای هماهنگ 2026 EDPB: شفافیت و تعهدات اطلاعرسانی (مادههای 13/14)؛ دستورالعمل ePrivacy 2002/58/EC (لازمالاجرا) و نظایر آن در کشورهای عضو از جمله § 25 TDDDG (آلمان) و ماده 82 قانون 78-17 (فرانسه).