GDPR-biztos adatcsatorna: PII anonymizálása tárolás előtt
2026-ra frissítve
Megcímkézte a PII-oszlopokat a dbt-ben. Beállított dinamikus maszkolást a Snowflake-ben. GDPR-megfelelőnek érzi magát.
A forrástartalom még mindig maszkolatlanul kerül az adattárházba. A maszkolás lekérdezés közben fut. A maszkolatlan tartalom a nyers sémában marad. Mindenki, aki hozzáfér a nyers sémához, olvashatja. A dbt-modelljei a maszkolási szabályok létrehozása előtt futottak. A régi betöltött táblák soha nem lettek maszkolva.
A „van maszkolási szabályunk” és az „a csatornánk biztonságos” közötti szakadékban történnek a GDPR-jogsértések.
Tekintse meg a megfelelőségi áttekintőnket, ahol részletezzük, hogyan támogatja az anonym.legal a GDPR-t.
Hogyan teszi ki az ELT-csatorna a PII-t?
A kivonat-betöltés-átalakítás (ELT) minta ma már norma. Először betölti a forrásadatokat az adattárházba. Az átalakítások később következnek. A lépések a következők:
- Kivonatolás: A forrásrendszerek minden mezőt exportálnak. Salesforce CRM, Stripe-kifizetések, Intercom-support — minden kimegy.
- Betöltés: A forrásadatok az adattárház betöltési sémájába kerülnek. A Snowflake, a BigQuery és a Redshift mind ugyanúgy működik. Minden PII-mező bekerül.
- Átalakítás: A dbt-modellek megtisztítják és összekapcsolják az adatokat az analitikához.
A betöltési réteg teljes személyes adatokat tartalmaz. Neveket, e-mail-címeket, telefonszámokat, fizetési adatokat, support-jegy szövegeket. Sok csapatnál a mérnökök és az elemzők hozzáférnek a nyers sémához. Bármikor lekérdezhetik ezeket a táblákat.
A Snowflake-ben a címkéken alapuló maszkolás segít lekérdezés közben. De csak a megfelelően beállított downstream modellekre. Nem maszkolja a régi betöltött táblákat. Nem blokkolja a közvetlen sémalekérdezéseket. Minden modellt és irányítópultot fel kell címkézni. Ez a teher a séma növekedésével együtt nő.
Anonymizálás betöltés előtt
A PII anonymizálása a csatorna szintjén megszünteti a nyers réteg kockázatát. Tegyük meg, mielőtt a tartalom az adattárházba kerül.
ETL-megközelítés (betöltés előtti anonymizálás):
- Kivonatolás a forrásrendszerekből
- Átfuttatás egy anonymizálási lépésen
- Tiszta kimenet betöltése az adattárházba
Az adattárház soha nem kap maszkolatlan PII-t. A betöltési séma csak tiszta tartalmat tartalmaz. A downstream modellek, az irányítópultok és a közvetlen lekérdezések mind tiszta kimenettel dolgoznak.
Két fő út áll rendelkezésre.
1. lehetőség — API-integráció:
Webhookokkal vagy streamelt exportokkal rendelkező rendszereknél irányítsa a bejegyzéseket először az anonym.legal API-n keresztül. Az Intercomból kilépő support-jegyek az adattárház előtt az API-n mennek keresztül. A Stripe-exportok ugyanígy.
POST /api/anonymize
{
"text": "Kovács János ügyfél (kovacs@example.com) jelezte...",
"entities": ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER"],
"method": "replace"
}
2. lehetőség — Kötegelt előfeldolgozás:
Napi vagy heti CSV/JSON-fájlexportoknál futtassa a fájlokon a kötegelt feldolgozást betöltés előtt.
Airflow DAG-struktúra:
extract_task >> anonymize_batch_task >> load_to_warehouse_task
Az anonymizálási feladat feltölti a fájlokat, és visszakapja a tiszta verziókat. A betöltési feladat a többit kezeli.
Az adatfolyam és az alfeldolgozókra vonatkozó részletekért tekintse meg a biztonsági eljárások oldalát.
Mit csinálnak és mit nem csinálnak a dbt-oszlopcímkék?
A dbt lehetővé teszi a PII-oszlopok címkézését:
models:
- name: stg_customers
columns:
- name: email
tags: ['pii', 'email']
- name: full_name
tags: ['pii', 'personal_data']
A címkék lehetővé teszik:
- A PII helyének dokumentálását
- Downstream maszkolási szabályok aktiválását (adattárházi szintű beállítást igényel)
- A lineáris nyomon követését olyan eszközökkel, mint a Secoda
A címkék nem teszik a következőket:
- Nem maszkolják a betöltött táblákat a nyers sémában
- Nem blokkolják a közvetlen táblalekérdezéseket
- Nem anonymizálják az adatokat betöltéskor
- Nem maszkolják visszamenőleg a régi adatokat
A dbt-oszlopcímkék irányítási eszközök. Megmutatják, hol van a PII. Nem alkalmazzák azokat a „megfelelő technikai intézkedéseket”, amelyeket a GDPR 32. cikke megkövetel.
A Snowflake-maszkolás korlátai
A Snowflake dinamikus maszkolása lekérdezéskor elrejti az oszloptartalmat a felhasználók elől. Ez erős kontroll az éles környezetben. De egyértelmű korlátai vannak.
Főbb korlátok:
- Minden új oszlophoz explicit szabályzat szükséges
- A sémaváltozások addig maszkolatlanul hagyhatnak új oszlopokat, amíg nem frissíti a szabályokat
- A SYSADMIN és ACCOUNTADMIN szerepek megkerülhetik a maszkolást
- Az importálási feladatok gyakran magas jogosultságokkal futnak, amelyek kihagyják a maszkolást
- A szabályok bevezetése előtt betöltött régi adatok szöveges formában tárolódnak — a szabályok olvasáskor futnak, nem íráskor
A lekérdezéskori maszkolás nem elegendő. Az adatoknak már tárolás előtt tisztának kell lenniük.
Megfelelőségi dokumentáció
A GDPR elszámoltathatósági szabálya bizonyítékot követel. A szavak nem elegendők. A mérnöki csapatok számára ez írásos nyilvántartásokat jelent.
Adatkezelési tevékenységek nyilvántartása (ROPA): Dokumentálja, hogy az ügyféladatokat az analitikai adattárházba való betöltés előtt anonymizálják. Az anonymizálási lépés adatkezelési tevékenységnek minősül a GDPR alapján.
Technikai biztosítékok feljegyzései: Jegyezze le, hogy a csatorna milyen entitástípusokat céloz meg. Jegyezze fel az alkalmazott anonymizálási módszert. A kötegelt futási naplók ezt ingyenesen biztosítják.
Adat-lineáris nyomon követése: A Secoda vagy a dbt beépített lineáris nyomon követése megmutathatja, hogy a forrástáblák egy anonymizálási lépésen mennek keresztül az analitikai modellekhez való eljutás előtt. Ez az auditnapló.
Szállítói nyilvántartás: Az anonymizálási szolgáltatás alfeldolgozó. Az adatfeldolgozói megállapodásukat és adatvédelmi szabályzatukat be kell venni a szállítói nyilvántartásba.
Megvalósítási lépések
Egy dbt és Snowflake csatornához:
1. lépés: Vizsgálja meg a nyers réteget
Derítse ki, mely táblák tartalmaznak személyes adatokat. Lekérdezheti a dbt-oszlopcímkéit vagy a katalógusát a PII-vel jelölt táblák után.
2. lépés: Határozza meg az anonymizálási hatókört
Minden forrástáblánál döntse el, mely oszlopok tartalmaznak PII-t. Majd döntse el, melyeknek kell anonymizálást és melyeknek pszeudoanonymizálást alkalmazni. Support-jegy törzse: anonymizálás. Rendelésazonosító: pszeudoanonymizálás a join-kulcsok megőrzéséhez. Időbélyeg: megtartás az idősorozat-elemzéshez.
3. lépés: Válasszon megvalósítási utat
Kis csapat kötegelt exportokkal: kötegelt fájlfeldolgozást használjon betöltés előtt. Rendelkezésre álló mérnöki csapat: API-integrációt építsen az Airflowba vagy a Prefectbe.
4. lépés: Tesztelés és ellenőrzés
Futtasson anonymizálást egy mintán az élesítés előtt. Ellenőrizze, hogy a dbt-modellek még működnek-e. Egyes modellek e-mailre joinolnak. Ezeknek konzisztens helyettesítési értékekre van szükségük. A pszeudoanonymizálás megőrzi a join-kulcsokat. A redakció megtöri azokat.
5. lépés: A régi nyers táblák kezelése
Az anonymizálás bevezetése előtt betöltött tartalmakat utólagos feldolgozás szükséges. Exportáljon, anonymizáljon, töltse be újra. Ez egyszeri feladat táblánként.
Összefoglalás
A címkéken alapuló maszkolás megmutatja, hol van a PII. Nem akadályozza meg, hogy a séma-hozzáféréssel rendelkező felhasználók elolvassák. A valódi GDPR-megfelelőséghez a PII-nek tisztának kell lennie, mielőtt az adattárházba kerül. Ez teszi a betöltési réteget ugyanolyan biztonságossá, mint a termelési réteget.
Ez nehezebb, mint az oszlopcímkézés. De ez az, amit a „megfelelő technikai intézkedések” valójában jelent.