By · Last updated 2026-06-05

Rudi kwa BlogKitaalamu

GDPR katika Kumbukumbu za Programu: Uzingatiaji wa PII ya JSON

Kumbukumbu za programu zina anwani za barua pepe za wateja, IP, na nambari za akaunti ambazo Kifungu cha 5(1)(e) cha GDPR kinahitaji kusimamia. Hapa kuna jinsi ya kufanya timu za uhandisi zikidhi kanuni bila kuathiri utatuzi.

June 5, 20266 dakika kusoma
API logsGDPR complianceJSON anonymizationobservabilitystorage limitation

Hatari ya Kimya ya GDPR katika Mfumo Wako wa Kumbukumbu

Imesasishwa kwa mwaka 2026

Timu nyingi hukagua hifadhidata zao kwa habari za kibinafsi. Wachache hufanya vivyo hivyo kwa mfumo wao wa kumbukumbu.

Kifungu cha 5(1)(e) cha GDPR kinapunguza muda gani unaweza kuhifadhi habari za kibinafsi. Kwa hifadhidata, timu huweka sera na kuendesha kazi za kufuta. Kwa faili za kumbukumbu, kanuni ni rahisi zaidi: hifadhi kila kitu kwa siku 90 kwa utatuzi.

Tatizo? Rekodi hizo zina habari za kibinafsi. Ingizo za ombi zinashikilia barua pepe za watumiaji. Unakili wa makosa unashikilia thamani za kawaida za ingizo. Ingizo za ufikiaji zinashikilia anwani za IP. Kila moja ya hizi inahesabiwa kama habari za kibinafsi chini ya GDPR. Timu yako inahitaji msingi wa kisheria na mpango wa uhifadhi kwa kila moja.

Kinachokwisha katika Faili Zako za Kumbukumbu

Ukaguzi wa kawaida wa programu ya wavuti hukusanya aina nyingi za PII.

Rekodi za ufikiaji (nginx/Apache):

  • Anwani za IP — habari za kibinafsi kulingana na mwongozo wa EDPB
  • Mifuatano ya wakala wa mtumiaji — inaweza kuwezesha alama za vidole vya kifaa
  • Tokeni za kipindi — ikiwa zimeandikwa katika matokeo

Rekodi za programu (JSON iliyopangwa):

  • Vitambulisho vya watumiaji na anwani za barua pepe
  • Makosa ya ingizo — mara nyingi yanajumuisha thamani batali ya kawaida, ambayo inaweza kuwa habari halisi za mtumiaji
  • Matukio ya biashara — vitambulisho vya agizo vilivyounganishwa na akaunti za wateja
  • Maswali ya utafutaji — yanaweza kuwa na majina au anwani

Rekodi za lango la API:

  • Vichwa vya uthibitisho — vilivyonakiliwa kwa sehemu katika baadhi ya mipangilio
  • Vigezo vya hoja — vinaweza kubeba vitambulisho, majina, au barua pepe za watumiaji
  • Miili ya ombi na jibu — ipo katika mipangilio ya kiwango cha utatuzi

Ingizo za ukaguzi wa hifadhidata:

  • Maswali ya SQL yenye vifungu kama `email = 'user@example.com'`
  • Thamani za kibinafsi za kawaida katika vigezo vya hoja

Hii haikufanywa kwa makusudi. Ni athari ya upande wa ukaguzi uliojengwa kwa utatuzi, si GDPR.

Mwongozo wa EDPB kuhusu Anwani za IP

Bodi ya Ulinzi wa Data ya Ulaya inasema anwani za IP ni habari za kibinafsi. ISP zinaweza kuziunganisha na watumiaji. Ndani ya shirika, zinaweza kutambua watumiaji maalum.

Athari ni ya moja kwa moja. Rekodi za ufikiaji zenye anwani za IP ni rekodi za kibinafsi. Kuhifadhi matokeo ya nginx kwa miezi 12 kunamaanisha kuhifadhi habari za kibinafsi kwa miezi 12. Hiyo inahitaji msingi wa kisheria chini ya Kifungu cha 6. Pia inahitaji kipindi cha uhifadhi kulingana na madhumuni yako yaliyotajwa.

Timu nyingi huacha hatua hii. "Tunahifadhi ingizo kwa siku 90 kwa sababu usalama unasema hivyo" ni kanuni ya kidole. Si ukaguzi wa Kifungu cha 5(1)(e) cha GDPR. Angalia muhtasari wetu wa Uzingatiaji wa Kisheria jinsi hii inavyoendana na programu pana.

Jinsi ya Kufikia Uzingatiaji

Njia ya vitendo kwa timu nyingi si kupunguza muda wa uhifadhi. Sababu za uendeshaji na usalama za muda mrefu zaidi ni za kweli. Njia bora ni kufunika rekodi kabla ya uhifadhi wa muda mrefu.

Mfano wa tabaka unafanya kazi vizuri.

Siku 0–7: Rekodi kamili za kawaida kwa utatuzi wa kazi. Siku saba ni mfupi wa kutosha kwa timu nyingi.

Siku 7–90: Rekodi zilizofunikwa kwa uchambuzi wa mwenendo na ukaguzi wa usalama. Anwani za IP zimebadilishwa. Barua pepe za watumiaji zinakuwa tokeni thabiti. Nambari za akaunti zimefunikwa. Sehemu muhimu — alama za muda, misimbo ya makosa, latency, mwisho wa njia — zimehifadhiwa kama zilivyo.

Siku 90+ (ikiwa zinahitajika): Matokeo ya mkusanyiko tu. Idadi ya matukio, viwango vya makosa, anuwai za latency. Hakuna rekodi za kiwango cha mtumiaji zinazobaki.

Habari za kibinafsi zinasimama baada ya siku saba. Matokeo ya mkusanyiko yanaweza kuendelea bila kumfunua mtu yeyote. Angalia Usalama na Uzingatiaji kwa maelezo zaidi.

Hifadhi Muundo Ukiwa Mzima kwa Ufuatiliaji

Ufunikaji mzuri hudumisha muundo wa JSON ukiwa mzima. Hubadilisha maudhui tu. Hii hudumisha matokeo kuwa na manufaa kwa utatuzi na arifa.

Zimehifadhiwa kama zilivyo:

  • Funguo za JSON na upachikaji
  • Alama za muda na mpangilio wa muda
  • Aina za makosa na misimbo ya hali ya HTTP
  • Mbinu za HTTP, njia, na thamani za latency
  • Aina za matukio ya biashara

Zimebadilishwa:

  • Anwani za barua pepe → tokeni thabiti kwa kila asili (mfano `user1@example.com`)
  • Anwani za IP → anuwai za RFC 5737 (`192.0.2.x`)
  • Nambari za akaunti → `ACCT_XXXXX`
  • Nambari za simu → `+XX XXX XXX XXXX`
  • Majina katika maandishi ya makosa → `[MTU]`

Tokeni thabiti huhifadhi njia zikiwa na manufaa. Njia ya `user1@example.com` katika ingizo 40 inafanya kazi sawa na ya asili. Metriki za mkusanyiko — viwango vya makosa, latency, throughput — hazihitaji habari za kibinafsi kabisa. Angalia Glosari kwa maneno kufanya jina bandia na kufuta majina.

Njia Tatu za Kuunganisha Hili

Mifumo mitatu inashughulikia timu nyingi za uhandisi.

Chaguo la 1 — Ufunikaji wa mfululizo: Fluentd au Logstash inakomesha kila mstari kabla ya kuutuma mbele. Hatua ya ufunikaji inafanya kazi ndani. Elastic au Datadog inapokea rekodi zilizosafishwa tu. Hakuna mabadiliko ya msimbo wa programu yanayohitajika.

Chaguo la 2 — Kundi la usiku: Rekodi za kawaida hushuka katika hifadhi ya ndani. Kazi ya usiku hufunika matokeo ya siku iliyopita na kufuta toleo la kawaida. Rekodi zilizofunikwa zinaenda kwa uhifadhi wa muda mrefu. Matokeo ya kawaida huhifadhiwa kwa siku saba tu.

Chaguo la 3 — Ufunikaji wa kabla ya kushiriki: Rekodi za kawaida zinabaki za ndani na udhibiti mkali wa ufikiaji. Kabla ya kushiriki na wataalamu wa majaribio ya kalamu au wakandarasi wa nje, endesha ufunikaji. Wahusika wa nje daima wapate matoleo safi.

Kwa nyaraka za GDPR, ufunikaji ni "hatua ya kiufundi" chini ya Kifungu cha 32. Rekodi zana, mipangilio yake, na sera yako ya uhifadhi katika Rekodi zako za Shughuli za Usindikaji (RoPA) chini ya Kifungu cha 30. Angalia Maswali Yanayoulizwa Mara Kwa Mara yetu kwa maswali ya kawaida ya RoPA.

Unataka mfano halisi? Angalia utafiti wa kesi kwa maelezo ya utekelezaji wa vitendo. Pia unaweza kukagua bei yetu ili kuona mpango unaojumuisha mifululizo ya ufunikaji iliyojengwa ndani.

Vyanzo

Tayari kulinda data yako?

Anza kuanonymisha PII na aina 285+ za vitu katika lugha 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.