anonym.legal

By · Last updated 2026-05-29

Terug na BlogTegnies

GDPR Pyplyn: Anonimiseer Voor Stoor

dbt kolommerkers is nie GDPR-nakoming nie. Rou kliendata land in jou Snowflake-pakhuis ongemaskeer voordat merkergebaseerde beleide geld.

May 29, 20268 min lees
data pipelinedbtSnowflakedata warehouseELT anonymizationGDPR engineering

GDPR-Veilige Pyplyn: Anonimiseer PII Voor Stoor

Opgedateer vir 2026

Jy het jou PII-kolomme in dbt gemerk. Jy het dinamiese maskering in Snowflake opgestel. Jy voel GDPR-voldoenend.

Jou broninhoud land steeds ongemaskeer in die pakhuis. Maskering loop tydens navraag. Die ongemaskeerde inhoud sit in jou ru-skema. Enigiemand met ru-skema-toegang kan dit lees. Jou dbt-modelle het geloop voor maskeringsbeleid bestaan het. Ou ingevoerde tabelle is nooit gemaskeer nie.

Die gaping tussen "ons het maskeringsbeleid" en "ons pyplyn is veilig" is waar GDPR-oortredings gebeur.

Sien ons nakomingsoorsig vir hoe anonym.legal GDPR ondersteun.

Hoe ELT-Pyplelyne PII Blootstel

Die Uitvoer-Laai-Transformeer (ELT) patroon is nou die norm. Dit laai brondata eers in die pakhuis. Transformasies kom later. Die stappe lyk soos volg:

  1. Uitvoer: Bronstelsels voer alle velde uit. Salesforce CRM, Stripe-betalings, Intercom-ondersteuning - alles gaan uit.
  2. Laai: Brondata land in die pakhuis-inseerskema. Snowflake, BigQuery, Redshift werk almal dieselfde manier. Elke PII-veld is ingesluit.
  3. Transformeer: dbt-modelle reinig en verbind die data vir ontleding.

Die inseerskema hou volledige persoonlike inligting. Name, e-posadresse, telefoonnommers, betalingsbesonderhede, ondersteuning-tiketteks. In baie spanne het ingenieurs en ontleders ru-skema-toegang. Hulle kan hierdie tabelle te eniger tyd navraag doen.

Merker-gebaseerde maskering in Snowflake help tydens navraag. Maar slegs vir behoorlik opgesigte stroomaf-modelle. Dit maskeer nie ou ingevoerde tabelle nie. Dit blokkeer nie direkte skema-navrae nie. Elke model en panel moet gemerk word. Daardie las groei soos die skema groei.

Anonimiseer Voor Laai

Anonimisering van PII op die pyplyn-vlak verwyder ru-laag-risiko. Doen dit voor inhoud in die pakhuis land.

ETL-benadering (voor-laai anonimisering):

  1. Uitvoer uit bronstelsels
  2. Deur 'n anonimiseringstap laat loop
  3. Skoon uitvoer in die pakhuis laai

Die pakhuis ontvang nooit ongemaskeerde PII nie. Die inseerskema hou slegs skoon inhoud. Stroomaf-modelle, panele en direkte navrae werk almal met skoon uitvoer.

Jy het twee hoofpaaie.

Opsie 1 - API-integrasie:

Vir stelsels met webhooks of stroomuitvoere, roeteer inskrywings eers deur die anonym.legal API. Ondersteuningskaartjies wat Intercom verlaat, gaan deur die API voor die pakhuis. Stripe-uitvoere doen dieselfde.

POST /api/anonymize
{
  "text": "Klant Jan Smith (jan@voorbeeld.com) het gerapporteer...",
  "entities": ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER"],
  "method": "replace"
}

Opsie 2 - Lot-voorverwerking:

Vir daaglikse of weeklikse CSV/JSON-leeruitvoere, laat leers deur lotverwerking voor laai.

Airflow DAG-struktuur:

extract_task >> anonymize_batch_task >> load_to_warehouse_task

Die anonimiseer-taak laai leers op en kry skoon weergawes terug. Die laai-taak hanteer die res.

Sien ons sekuriteitspraktyke bladsy vir sub-verwerker en datavloeisbesonderhede.

Wat dbt Kolommerkers Doen en Nie Doen Nie

dbt laat jou toe om PII-kolomme te merk:

models:
  - name: stg_klante
    columns:
      - name: epos
        tags: ['pii', 'email']
      - name: volle_naam
        tags: ['pii', 'personal_data']

Merkers laat jou toe om:

  • Te dokumenteer waar PII bly
  • Stroomaf maskeringsbeleid te aktiveer (vereis pakhuis-vlak opstelling)
  • Afstamming met gereedskap soos Secoda te spoor

Merkers doen nie:

  • Ingevoerde tabelle in die ru-skema maskeer nie
  • Direkte tabelnavrae blokkeer nie
  • Data tydens laai anonimiseer nie
  • Ou data met terugwerkende krag maskeer nie

dbt kolommerkers is 'n bestuurshulpmiddel. Hulle wys jou waar PII is. Hulle pas nie die "toepaslike tegniese maatreels" toe wat GDPR Artikel 32 vereis nie.

Die Snowflake Maskeringgaping

Snowflake se dinamiese maskering verberg kolominhoud van gebruikers tydens navraag. Dit is 'n sterk beheer vir produksiegebruik. Maar dit het duidelike beperkings.

Sleutelbeperkings:

  • Elke nuwe kolom benodig 'n uitdruklike beleid
  • Skema-veranderinge kan nuwe kolomme ongemaskeerd laat totdat jy beleide opdateer
  • SYSADMIN en ACCOUNTADMIN-rolle kan maskering omseil
  • Invoertake loop dikwels met hoe voorregte wat maskering omseil
  • Ou data wat voor beleide gelaai is, word in gewone vorm gestoor - beleide loop by lees, nie by skryf nie

Maskering tydens navraag is nie genoeg nie. Data moet skoon wees voor dit gestoor word.

Nakoming-Dokumentasie

GDPR se aanspreeklikheidsreel vereis bewys. Woorde is nie genoeg nie. Vir ingenieursspanne beteken dit geskrewe rekords.

Rekords van Verwerkingsaktiwiteite (ROPA): Dokumenteer dat kliendata geanonimiseer word voor dit na die ontledingspakhuis laai. Die anonimiseringstap is 'n verwerkingsaktiwiteit onder GDPR.

Tegniese beveiliging-aantekeninge: Skryf neer watter entiteitstipes jou pyplyn teiken. Let op die anonimiseringsmetode wat gebruik is. Lot-loglêers gee jou dit gratis.

Data-afstamming: Secoda of dbt se ingeboude afstamming kan wys dat bronstabelle deur 'n anonimiseringstap vloei voor hulle ontledingsmodelle bereik. Dit is jou ouditspoor.

Verkopersregister: Die anonimiseringsdiens is 'n sub-verwerker. Hulle DPA en privaatheidsbeleid moet in jou verkopersregister wees.

Implementeringsstappe

Vir 'n dbt en Snowflake pyplyn:

Stap 1: Ouditeer jou ru-laag

Vind watter tabelle persoonlike inligting hou. Navraag jou dbt-kolommerkers of jou katalogus vir PII-gemerkde tabelle.

Stap 2: Stel die anonimiseringsomvang

Vir elke brontabel, besluit watter kolomme PII hou. Besluit dan watter anonimisering nodig het en watter pseudonimisering. Ondersteuningskaartjie-liggaam: anonimiseer. Bestelling-ID: pseudonimiseer om verbindings-sleutels intact te hou. Tydstempel: hou soos dit vir tydreeks-ontleding.

Stap 3: Kies 'n implementeringspad

Klein span met lotuitvoere: gebruik lot-leerverwerking voor laai. Ingenieurspan beskikbaar: bou API-integrasie in Airflow of Prefect.

Stap 4: Toets en valideer

Laat anonimisering op 'n monster loop voor dit leef gaan. Kontroleer dat dbt-modelle steeds werk. Sommige modelle verbind op e-pos. Hierdie benodig konsekwente vervangingswaardes. Pseudonimisering hou verbindings-sleutels. Redaksie breek hulle.

Stap 5: Hanteer ou ru-tabelle

Inhoud wat gelaai is voor anonimisering in plek was, benodig met terugwerkende krag verwerking. Uitvoer, anonimiseer, herlaai. Dit is 'n eenmalige taak per tabel.

Gevolgtrekking

Merkergebaseerde maskering wys jou waar PII bly. Dit keer nie gebruikers met skema-toegang van lees nie. Vir werklike GDPR-nakoming moet PII skoon wees voordat dit die pakhuis bereik. Dit maak die inseerskema so veilig soos die produksielaag.

Dit is moeiliker as kolommerkers. Maar dit is wat "toepaslike tegniese maatreels" werklik beteken.

Bronne

Gereed om u data te beskerm?

Begin om PII te anonimiseer met 285+ entiteitstipes in 48 tale.

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.