Tagasi BlogisseTehniline

GDPR-turvaline andmetoru: anonüümiseeri enne salvestamist

dbt veergude sildid ei tähenda GDPR-vastavust. Töötlemata kliendiandmed jõuavad Snowflake'i laohoosse maskeerimata enne sildi-põhiste poliitikate rakendumist.

May 29, 20268 min lugemist
data pipelinedbtSnowflakedata warehouseELT anonymizationGDPR engineering

GDPR-turvaline andmetoru: anonüümiseeri isikuandmed enne salvestamist

Uuendatud 2026. aastaks

Sa märgistasid dbt-s oma isikuandmete veerud. Seadsid Snowflake'is dünaamilise maskeerimise üles. Tunned end GDPR-nõuetele vastavana.

Sinu lähtesisu jõuab ikkagi laohoosse maskeerimata. Maskeerimine toimub päringute ajal. Maskeerimata sisu istub sinu toorandmete skeemis. Igaüks, kellel on juurdepääs toorandmete skeemile, saab seda lugeda. Sinu dbt-mudelid käivitusid enne maskeerimispoliitikate olemasolu. Vana sisestatud tabeleid pole kunagi maskeeritud.

Lõhe "meil on maskeerimispoliitikad" ja "meie andmetoru on turvaline" vahel on koht, kus GDPR-rikkumised juhtuvad.

Vaata meie vastavuse ülevaadet, kuidas anonym.legal toetab GDPR-i.

Kuidas ELT-torustikud paljastavad isikuandmeid

Eraldamise-laadimise-transformatsiooni (ELT) muster on nüüd norm. See laadib lähteandmed kõigepealt laohoosse. Transformatsioonid tulevad hiljem. Sammud näevad välja nii:

  1. Eraldamine: Lähtesüsteemid ekspordivad kõik väljad. Salesforce CRM, Stripe maksed, Intercom tugi - kõik väljutatakse.
  2. Laadimine: Lähteandmed jõuavad laohoosse sisestamise skeemi. Snowflake, BigQuery, Redshift töötavad kõik samamoodi. Iga isikuandmete väli on kaasatud.
  3. Transformatsioon: dbt-mudelid puhastavad ja ühendavad andmed analüütika jaoks.

Sisestamise kiht hoiab täielikku isiklikku teavet. Nimed, e-posti aadressid, telefoninumbrid, makseandmed, tugipileti tekst. Paljudes meeskondades on inseneridel ja analüütikutel juurdepääs toorandmete skeemile. Nad saavad neid tabeleid igal ajal pärida.

Snowflake'i sildi-põhine maskeerimine aitab päringute ajal. Kuid ainult nõuetekohaselt seadistatud allavoolu mudelite jaoks. See ei maskeeri vanu sisestatud tabeleid. See ei blokeeri otseseid skeemi päringuid. Iga mudel ja armatuurlaud tuleb märgistada. See koormus kasvab skeemi kasvades.

Anonüümiseeri enne laadimist

Isikuandmete anonüümiseerimine torustiku tasemel eemaldab toorandmete kihi riski. Tee seda enne, kui sisu jõuab laohoosse.

ETL-lähenemine (eellaadimise anonüümiseerimine):

  1. Eraldamine lähtesüsteemidest
  2. Käivitamine läbi anonüümiseerimise sammu
  3. Laadi puhas väljund laohoosse

Laohoon ei saa kunagi maskeerimata isikuandmeid. Sisestamise skeem hoiab ainult puhast sisu. Allavoolu mudelid, armatuurlauad ja otsesed päringud töötavad kõik puhta väljundiga.

Sul on kaks peamist teed.

Valik 1 - API-integratsioon:

Süsteemide jaoks, millel on webhook-id või voogedastuse ekspordid, suuna kirjed esmalt läbi anonym.legal API. Intercomist lahkuvad tugipileted läbivad API enne laohoosse jõudmist. Stripe ekspordid teevad sama.

POST /api/anonymize
{
  "text": "Klient John Smith (john@example.com) teatas...",
  "entities": ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER"],
  "method": "replace"
}

Valik 2 - Pakk-eeltöötlus:

Igapäevaste või iganädalaste CSV/JSON-faili eksportide jaoks käivita failid läbi pakktöötluse enne laadimist.

Airflow DAG struktuur:

extract_task >> anonymize_batch_task >> load_to_warehouse_task

Anonüümiseerimise ülesanne laadib failid üles ja saab tagasi puhta versiooni. Laadimisülesanne käsitleb ülejäänut.

Vaata meie turvapraktikate lehekülge alamtöötleja ja andmevoogude üksikasjade saamiseks.

Mida dbt veergude sildid teevad ja ei tee

dbt lubab sul isikuandmete veerge märgistada:

models:
  - name: stg_customers
    columns:
      - name: email
        tags: ['pii', 'email']
      - name: full_name
        tags: ['pii', 'personal_data']

Sildid võimaldavad sul:

  • Dokumenteerida, kus isikuandmed asuvad
  • Käivitada allavoolu maskeerimispoliitikaid (nõuab laohoonetaseme seadistust)
  • Jälgida linae selliste tööriistadega nagu Secoda

Sildid ei tee järgmist:

  • Ei maskeeri sisestatud tabeleid toorandmete skeemis
  • Ei blokeeri otseseid tabeli päringuid
  • Ei anonüümiseeri andmeid laadimise ajal
  • Ei maskeeri vanu andmeid tagasiulatuvalt

dbt veergude sildid on juhtimistööriistad. Need näitavad sulle, kus isikuandmed asuvad. Need ei rakenda "asjakohaseid tehnilisi meetmeid", mida GDPR artikkel 32 nõuab.

Snowflake'i maskeerimise lünk

Snowflake'i dünaamiline maskeerimine peidab veeru sisu kasutajatelt päringute ajal. See on tootmiseks tugev kontroll. Kuid sellel on selged piirangud.

Peamised piirangud:

  • Iga uus veerg vajab selgesõnalist poliitikat
  • Skeemi muudatused võivad jätta uued veerud maskeerimata, kuni poliitikad uuendatakse
  • SYSADMIN ja ACCOUNTADMIN rollid saavad maskeerimise mööda minna
  • Imporditööd käivituvad sageli kõrge privileegiga, mis jätab maskeerimise vahele
  • Vanad andmed, mis on laaditud enne poliitikate seadistamist, on salvestatud lihttekstina - poliitikad töötavad lugemise ajal, mitte kirjutamise ajal

Päringute ajal maskeerimine ei ole piisav. Andmed peavad olema puhtad enne salvestamist.

Vastavuse dokumentatsioon

GDPR-i aruandekohustuse reegel nõuab tõendeid. Sõnadest ei piisa. Insenerimeeskondade jaoks tähendab see kirjalikke andmeid.

Töötlemistoimingute register (ROPA): Dokumenteeri, et kliendiandmed anonüümiseeritakse enne laadimist analüütikalattu. Anonüümiseerimise samm on töötlemistoiminguid GDPR-i alusel.

Tehniliste kaitsemeetmete märkmed: Kirjuta üles, milliseid olemitüüpe sinu torustik sihtib. Märgi kasutatav anonüümiseerimismeetod. Pakettide käivitamise loge saad tasuta.

Andmete linae: Secoda või dbt-sisene linae võib näidata, et lähtetabelid läbivad anonüümiseerimise sammu enne analüütikamudeliteni jõudmist. See on sinu auditijälg.

Tarnijate register: Anonüümiseerimisteenus on alamtöötleja. Nende andmetöötlusleping ja privaatsuspoliitika peavad olema sinu tarnijate registris.

Rakendamise sammud

dbt ja Snowflake'i torustiku jaoks:

Samm 1: Auditeeri oma toorandmete kiht

Leia, millised tabelid hoiavad isiklikku teavet. Päri oma dbt veergude silte või oma kataloogi isikuandmetega märgistatud tabelite jaoks.

Samm 2: Sea anonüümiseerimise ulatus

Iga lähtetabeli jaoks otsusta, millised veerud hoiavad isikuandmeid. Seejärel otsusta, millised vajavad anonüümiseerimist ja millised pseudonüümiseerimist. Tugipileti sisu: anonüümiseeri. Tellimuse ID: pseudonüümiseeri, et säilitada liitmise võtmed. Ajatempel: hoia muutumatuna ajaseeria analüüsi jaoks.

Samm 3: Vali rakendamise tee

Väike meeskond pakktöötluse ekspordiga: kasuta pakk-failitöötlust enne laadimist. Insenerimeeskond saadaval: ehita API-integratsioon Airflow'sse või Prefect'i.

Samm 4: Testi ja valideeri

Käivita anonüümiseerimine prooviandmetel enne esiletoomist. Kontrolli, kas dbt mudelid töötavad ikka. Mõned mudelid liidavad e-posti alusel. Need vajavad järjekindlaid asendusväärtusi. Pseudonüümiseerimine hoiab liitmise võtmeid. Redakteerimine katkestab need.

Samm 5: Käitle vanu toorandmete tabeleid

Enne anonüümiseerimist laaditud sisu vajab tagasiulatuvat töötlemist. Ekspordi, anonüümiseeri, laadi uuesti. See on ühekordne ülesanne tabeli kohta.

Kokkuvõte

Sildi-põhine maskeerimine näitab sulle, kus isikuandmed asuvad. See ei takista skeemi juurdepääsuga kasutajaid neid lugemast. Tõelise GDPR-vastavuse saavutamiseks peavad isikuandmed olema puhtad enne laohoosse jõudmist. See muudab sisestamise kihi sama turvaliseks kui tootmise kihi.

See on raskem kui veergude märgistamine. Kuid see on see, mida "asjakohased tehnilised meetmed" tegelikult tähendavad.

Allikad

Kas olete valmis oma andmeid kaitsma?

Alustage PII anonüümitamist 273 üksustüübi abil 48 keeles.