خطر ساکت GDPR در پشته گزارش شما
به‌روز شده برای سال ۲۰۲۶
اکثر تیم‌ها پایگاه داده خود را برای اطلاعات شخصی بررسی می‌کنند. کمتری همین کار را برای سیستم گزارش خود انجام می‌دهند.
ماده ۵(۱)(e) GDPR محدودیت مدت ذخیره اطلاعات شخصی را تعیین می‌کند. برای پایگاه‌های داده، تیم‌ها سیاست‌ها تعیین می‌کنند و وظایف حذف را اجرا می‌کنند. برای فایل‌های گزارش، قانون ساده‌تر است: همه چیز را برای ۹۰ روز برای اشکال‌زدایی نگه دارید.
مشکل؟ آن رکوردها اطلاعات شخصی دارند. ورودی‌های درخواست ایمیل کاربران دارند. گرفتارهای خطا مقادیر ورودی خام دارند. ورودی‌های دسترسی آدرس‌های IP دارند. هر کدام از اینها تحت GDPR به عنوان اطلاعات شخصی محسوب می‌شوند. تیم شما به یک پایه قانونی و یک برنامه نگهداری برای هر کدام نیاز دارد.
چه چیزی در فایل‌های گزارش شما قرار می‌گیرد
گزارش استاندارد برنامه وب طیف گسترده‌ای از PII را می‌کشد.
رکوردهای دسترسی (nginx/Apache):
- آدرس‌های IP — اطلاعات شخصی طبق راهنمایی EDPB
- رشته‌های user-agent — ممکن است اثر انگشت دستگاه را فعال کنند
- توکن‌های نشست — اگر در خروجی نوشته شوند
رکوردهای برنامه (JSON ساختاریافته):
- شناسه‌های کاربر و آدرس‌های ایمیل
- خطاهای ورودی — اغلب شامل مقدار نامعتبر خام هستند، که ممکن است اطلاعات کاربر واقعی باشد
- رویدادهای کسب‌وکار — شناسه‌های سفارش مرتبط به حساب‌های مشتری
- کوئری‌های جستجو — ممکن است نام یا آدرس داشته باشند
رکوردهای دروازه API:
- سرآیندهای احراز هویت — در برخی تنظیمات جزئاً گرفته می‌شوند
- پارامترهای کوئری — ممکن است شناسه، نام، یا ایمیل کاربر داشته باشند
- بدنه‌های درخواست و پاسخ — در تنظیمات سطح debug موجود هستند
ورودی‌های حسابرسی پایگاه داده:
- کوئری‌های SQL با بندهای WHERE مانند
email = 'user@example.com' - مقادیر شخصی تحت الفظی در پارامترهای کوئری
این عمداً انجام نمی‌شود. این یک اثر جانبی گزارش‌گیری ساخته‌شده برای اشکال‌زدایی است، نه GDPR.
راهنمایی EDPB درباره آدرس‌های IP
هیئت حفاظت داده اروپا می‌گوید آدرس‌های IP اطلاعات شخصی هستند. ISPها می‌توانند آن‌ها را به مشترکین مرتبط کنند. درون یک سازمان، می‌توانند کاربران خاص را شناسایی کنند.
تأثیر مستقیم است. رکوردهای دسترسی با آدرس‌های IP رکوردهای شخصی هستند. نگه‌داشتن خروجی nginx به مدت ۱۲ ماه یعنی نگه‌داشتن اطلاعات شخصی برای ۱۲ ماه. این به یک پایه قانونی تحت ماده ۶ نیاز دارد. همچنین نیاز دارد که دوره نگهداری با هدف بیان‌شده شما تطابق داشته باشد.
اکثر تیم‌ها این مرحله را نادیده می‌گیرند. «ما ورودی‌ها را برای ۹۰ روز نگه می‌داریم چون امنیت می‌گوید» یک قانون سرانگشتی است. این یک بررسی ماده ۵(۱)(e) GDPR نیست. برای اینکه این در یک برنامه گسترده‌تر چطور جا می‌گیرد مروری بر انطباق حقوقی ما را ببینید.
چطور به انطباق برسید
مسیر عملی برای اکثر تیم‌ها این نیست که پنجره‌های نگهداری را کوتاه کنند. دلایل عملیاتی و امنیتی برای پنجره‌های طولانی‌تر واقعی هستند. مسیر بهتر ماسک کردن رکوردها قبل از ذخیره‌سازی طولانی‌مدت است.
یک مدل ردیف‌بندی‌شده به خوبی کار می‌کند.
۰–۷ روز: رکوردهای خام کامل برای اشکال‌زدایی فعال. هفت روز برای اکثر تیم‌ها کافی است.
۷–۹۰ روز: رکوردهای ماسک‌شده برای تحلیل روند و بررسی امنیتی. آدرس‌های IP جابجا می‌شوند. ایمیل‌های کاربر به توکن‌های پایدار تبدیل می‌شوند. شماره حساب‌ها ماسک می‌شوند. فیلدهای کلیدی — مُهرهای زمانی، کدهای خطا، تأخیر، نقاط پایانی — همان‌طور باقی می‌مانند.
۹۰+ روز (در صورت نیاز): فقط خروجی تجمیع‌شده. تعداد رویدادها، نرخ‌های خطا، دامنه‌های تأخیر. هیچ رکورد سطح کاربری باقی نمی‌ماند.
اطلاعات شخصی در هفت روز متوقف می‌شود. خروجی تجمیع‌شده می‌تواند بدون افشای هیچ کس ادامه یابد. برای جزئیات بیشتر امنیت و انطباق را ببینید.
ساختار را برای نظارت دست نخورده نگه دارید
ماسک‌گذاری خوب ساختار JSON را دست نخورده نگه می‌دارد. فقط محتوا را جابجا می‌کند. این خروجی را برای اشکال‌زدایی و هشدارها مفید نگه می‌دارد.
همان‌طور نگه داشته می‌شود:
- کلیدهای JSON و تودرتوبودن
- مُهرهای زمانی و ترتیب زمانی
- انواع خطا و کدهای وضعیت HTTP
- روش‌های HTTP، مسیرها، و مقادیر تأخیر
- انواع رویداد کسب‌وکار
جابجا می‌شود:
- آدرس‌های ایمیل → توکن پایدار برای هر اصلی (مثلاً
user1@example.com) - آدرس‌های IP → دامنه‌های RFC 5737 (
192.0.2.x) - شماره حساب →
ACCT_XXXXX - شماره تلفن →
+XX XXX XXX XXXX - نام‌ها در متن خطا →
[PERSON]
توکن‌های پایدار ردپاها را مفید نگه می‌دارند. یک ردپا برای user1@example.com در ۴۰ ورودی به همان شکل اصلی کار می‌کند. معیارهای تجمیع‌شده — نرخ‌های خطا، تأخیر، توان عملیاتی — اصلاً به اطلاعات شخصی نیاز ندارند. برای اصطلاحات مستعارسازی و ناشناس‌سازی واژه‌نامه را ببینید.
سه روش برای ادغام این
سه الگو اکثر تیم‌های مهندسی را پوشش می‌دهند.
گزینه ۱ — ماسک‌گذاری خط لوله: Fluentd یا Logstash هر خط را قبل از ارسال آن رهگیری می‌کند. یک مرحله ماسک‌گذاری به صورت داخلی اجرا می‌شود. Elastic یا Datadog فقط رکوردهای پاک‌شده دریافت می‌کنند. هیچ تغییر کد برنامه لازم نیست.
گزینه ۲ — دسته شبانه: رکوردهای خام در ذخیره‌سازی محلی فرود می‌آیند. یک وظیفه شبانه خروجی روز قبل را ماسک می‌کند و نسخه خام را حذف می‌کند. رکوردهای ماسک‌شده به ذخیره‌سازی طولانی‌مدت می‌روند. خروجی خام فقط هفت روز نگه داشته می‌شود.
گزینه ۳ — ماسک‌گذاری قبل از اشتراک‌گذاری: رکوردهای خام با کنترل‌های دسترسی سخت داخلی می‌مانند. قبل از اشتراک‌گذاری با تسترهای نفوذ یا پیمانکاران خارجی، یک عبور ماسک‌گذاری اجرا کنید. طرف‌های خارجی همیشه نسخه‌های تمیز دریافت می‌کنند.
برای اسناد GDPR، ماسک‌گذاری یک «اقدام فنی» تحت ماده ۳۲ است. ابزار، تنظیمات آن، و سیاست نگهداری خود را در رکوردهای پردازش فعالیت‌ها (RoPA) تحت ماده ۳۰ ثبت کنید. برای سوالات رایج RoPA FAQ ما را ببینید.
می‌خواهید یک مثال دنیای واقعی ببینید؟ برای جزئیات پیاده‌سازی مشخص مطالعات موردی را بررسی کنید. همچنین می‌توانید قیمت‌گذاری ما را مرور کنید تا ببینید کدام طرح شامل خطوط لوله ماسک‌گذاری داخلی است.