anonym.legal

By · Last updated 2026-06-05

กลับไปที่บล็อกเทคนิค

GDPR ในบันทึกแอป: การปฏิบัติตาม JSON PII

บันทึกแอปพลิเคชันมีที่อยู่อีเมลลูกค้า IP และหมายเลขบัญชีที่ GDPR มาตรา 5(1)(e) กำหนดให้จัดการ นี่คือวิธีปฏิบัติตามโดยไม่ทำลายการดีบักและการสังเกตการณ์

June 5, 20266 อ่านประมาณ
API logsGDPR complianceJSON anonymizationobservabilitystorage limitation

ความเสี่ยง GDPR ที่เงียบอยู่ในสแต็กบันทึกของคุณ

อัปเดตสำหรับปี 2026

ทีมส่วนใหญ่ตรวจสอบฐานข้อมูลของตนสำหรับข้อมูลส่วนบุคคล น้อยกว่าทำเช่นเดียวกันสำหรับระบบบันทึกของตน

GDPR มาตรา 5(1)(e) จำกัดระยะเวลาที่คุณสามารถจัดเก็บข้อมูลส่วนบุคคล สำหรับฐานข้อมูล ทีมตั้งนโยบายและรันงานลบ สำหรับไฟล์บันทึก กฎนั้นง่ายกว่า: เก็บทุกอย่างไว้ 90 วันสำหรับการดีบัก

ปัญหา? บันทึกเหล่านั้นมีข้อมูลส่วนบุคคล รายการคำขอมีอีเมลผู้ใช้ การจับข้อผิดพลาดมีค่าอินพุตดิบ รายการเข้าถึงมีที่อยู่ IP แต่ละรายการนับเป็นข้อมูลส่วนบุคคลภายใต้ GDPR ทีมของคุณต้องการฐานทางกฎหมายและแผนการเก็บรักษาสำหรับแต่ละรายการ

สิ่งที่ลงเอยในไฟล์บันทึกของคุณ

การบันทึกแอปเว็บมาตรฐานดึง PII ในวงกว้าง

บันทึกการเข้าถึง (nginx/Apache):

  • ที่อยู่ IP — ข้อมูลส่วนบุคคลตามคำแนะนำ EDPB
  • สตริง user-agent — อาจเปิดใช้งาน device fingerprinting
  • โทเค็นเซสชัน — ถ้าเขียนไปยังเอาต์พุต

บันทึกแอป (JSON มีโครงสร้าง):

  • รหัสผู้ใช้และที่อยู่อีเมล
  • ข้อผิดพลาดอินพุต — มักมีค่าที่ไม่ถูกต้องดิบ ซึ่งอาจเป็นข้อมูลผู้ใช้จริง
  • เหตุการณ์ธุรกิจ — รหัสคำสั่งที่เชื่อมโยงกับบัญชีลูกค้า
  • คำค้นหา — อาจมีชื่อหรือที่อยู่

บันทึก API gateway:

  • ส่วนหัว auth — จับได้บางส่วนในการตั้งค่าบางอย่าง
  • พารามิเตอร์ query — อาจมีรหัสผู้ใช้ ชื่อ หรืออีเมล
  • เนื้อหาคำขอและการตอบสนอง — มีอยู่ในการตั้งค่าระดับดีบัก

บันทึกการตรวจสอบฐานข้อมูล:

  • คำสั่ง SQL พร้อมส่วนคำสั่ง WHERE เช่น email = 'user@example.com'
  • ค่าส่วนบุคคลตรงๆ ในพารามิเตอร์ query

สิ่งนี้ไม่ได้ทำโดยตั้งใจ มันเป็นผลข้างเคียงของการบันทึกที่สร้างขึ้นสำหรับการดีบัก ไม่ใช่ GDPR

คำแนะนำ EDPB เกี่ยวกับที่อยู่ IP

คณะกรรมการคุ้มครองข้อมูลยุโรป (EDPB) ระบุว่าที่อยู่ IP เป็นข้อมูลส่วนบุคคล ISP สามารถเชื่อมโยงกับสมาชิก ภายในองค์กร สามารถระบุผู้ใช้เฉพาะได้

ผลกระทบนั้นตรงไปตรงมา บันทึกการเข้าถึงที่มีที่อยู่ IP เป็นบันทึกส่วนบุคคล การเก็บ nginx output ไว้ 12 เดือนหมายถึงการเก็บข้อมูลส่วนบุคคลไว้ 12 เดือน ซึ่งต้องการฐานทางกฎหมายภายใต้มาตรา 6 และต้องการระยะเวลาการเก็บรักษาที่ตรงกับวัตถุประสงค์ที่ระบุ

ทีมส่วนใหญ่ข้ามขั้นตอนนี้ "เราเก็บรายการไว้ 90 วันเพราะฝ่ายความปลอดภัยบอกว่าต้องทำ" เป็นกฎหัวแม่มือ มันไม่ใช่การตรวจสอบ GDPR มาตรา 5(1)(e)

วิธีบรรลุการปฏิบัติตามกฎหมาย

เส้นทางปฏิบัติสำหรับทีมส่วนใหญ่ไม่ใช่การลดหน้าต่างการเก็บรักษา เหตุผลด้านการดำเนินงานและความปลอดภัยสำหรับหน้าต่างที่ยาวกว่าเป็นเรื่องจริง เส้นทางที่ดีกว่าคือการปิดบังบันทึกก่อนการจัดเก็บระยะยาว

โมเดลแบบแบ่งชั้นใช้งานได้ดี

0-7 วัน: บันทึกดิบเต็มสำหรับการดีบักใช้งาน เจ็ดวันสั้นพอสำหรับทีมส่วนใหญ่

7-90 วัน: บันทึกที่ปิดบังสำหรับการวิเคราะห์แนวโน้มและการตรวจสอบความปลอดภัย ที่อยู่ IP ถูกแทนที่ อีเมลผู้ใช้กลายเป็นโทเค็นที่เสถียร หมายเลขบัญชีถูกปิดบัง ฟิลด์สำคัญ — เวลาประทับ รหัสข้อผิดพลาด เวลาแฝง endpoint — เก็บไว้ตามเดิม

90+ วัน (ถ้าจำเป็น): เฉพาะเอาต์พุตที่รวมแล้ว จำนวนเหตุการณ์ อัตราข้อผิดพลาด ช่วงเวลาแฝง ไม่มีบันทึกระดับผู้ใช้เหลืออยู่

ข้อมูลส่วนบุคคลหยุดที่เจ็ดวัน เอาต์พุตที่รวมแล้วสามารถดำเนินต่อไปได้โดยไม่เปิดเผยใคร

รักษาโครงสร้างไว้สำหรับการตรวจสอบ

การปิดบังที่ดีรักษาโครงสร้าง JSON ไว้ มันสลับเฉพาะเนื้อหา สิ่งนี้รักษาเอาต์พุตให้มีประโยชน์สำหรับการดีบักและการแจ้งเตือน

รักษาตามเดิม:

  • คีย์ JSON และการซ้อนกัน
  • เวลาประทับและลำดับเวลา
  • ประเภทข้อผิดพลาดและรหัสสถานะ HTTP
  • วิธี HTTP เส้นทาง และค่าเวลาแฝง
  • ประเภทเหตุการณ์ธุรกิจ

แทนที่ออก:

  • ที่อยู่อีเมล → โทเค็นที่เสถียรต่อต้นฉบับ (เช่น user1@example.com)
  • ที่อยู่ IP → ช่วง RFC 5737 (192.0.2.x)
  • หมายเลขบัญชี → ACCT_XXXXX
  • หมายเลขโทรศัพท์ → +XX XXX XXX XXXX
  • ชื่อในข้อความข้อผิดพลาด → [PERSON]

โทเค็นที่เสถียรรักษาการติดตามให้มีประโยชน์ การติดตามสำหรับ user1@example.com ใน 40 รายการทำงานเหมือนต้นฉบับ

สามวิธีในการรวมเข้ากับระบบ

สามรูปแบบครอบคลุมทีมวิศวกรรมส่วนใหญ่

ตัวเลือก 1 — การปิดบังในไพพ์ไลน์: Fluentd หรือ Logstash สกัดกั้นแต่ละบรรทัดก่อนส่งต่อ ขั้นตอนการปิดบังทำงาน inline Elastic หรือ Datadog ได้รับเฉพาะบันทึกที่สะอาด ไม่จำเป็นต้องเปลี่ยนรหัสแอป

ตัวเลือก 2 — ชุดรายคืน: บันทึกดิบลงในที่จัดเก็บในเครื่อง งานรายคืนปิดบังเอาต์พุตของวันก่อนและลบเวอร์ชันดิบ บันทึกที่ปิดบังไปยังที่จัดเก็บระยะยาว เอาต์พุตดิบเก็บไว้เจ็ดวันเท่านั้น

ตัวเลือก 3 — การปิดบังก่อนการแชร์: บันทึกดิบอยู่ภายในพร้อมการควบคุมการเข้าถึงที่เข้มงวด ก่อนแชร์กับผู้ทดสอบเจาะระบบหรือผู้รับเหมาภายนอก รันรอบการปิดบัง ฝ่ายภายนอกเสมอได้รับเวอร์ชันที่สะอาด

สำหรับเอกสาร GDPR การปิดบังเป็น "มาตรการทางเทคนิค" ภายใต้มาตรา 32 บันทึกเครื่องมือ การตั้งค่า และนโยบายการเก็บรักษาของคุณใน Records of Processing Activities (RoPA) ภายใต้มาตรา 30

แหล่งข้อมูล

พร้อมที่จะปกป้องข้อมูลของคุณหรือยัง?

เริ่มทำให้ PII เป็นนิรนามด้วยประเภทเอนทิตีมากกว่า 285 ประเภทใน 48 ภาษา.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.