Изграждане на GDPR-безопасен тръбопровод за данни: Анонимизиране на PII, преди да достигне до вашето хранилище за данни
Маркирахте колоните си с PII в dbt. Вашата политика за динамично маскиране на данни е конфигурирана в Snowflake. Чувствате се съвместими със GDPR.
Вашите необработени данни все още попадат в склада без маска. Правилата за маскиране се прилагат по време на заявка — но необработените, немаскирани данни съществуват във вашия необработен слой, достъпни за всеки с достъп до необработена схема. Вашите dbt модели са се изпълнявали, преди вашите правила за маскиране да бъдат въведени, а историческите необработени данни никога не са били маскирани.
Пропастта между „имаме правила за маскиране“ и „данните ни действително са защитени“ е мястото, където се случват нарушения на GDPR.
Как ELT тръбопроводите създават излагане на PII
Моделът Extract-Load-Transform (ELT) — доминиращ в съвременното инженерство на данни — първо зарежда необработени данни в склада, след което ги трансформира:
- Извличане: Изходните системни данни (Salesforce CRM, плащания Stripe, поддръжка на интерком) се извличат с всички полета
- Зареждане: Необработени данни, заредени в необработена схема на склада — Snowflake, BigQuery, Redshift — включително всички PII полета
- Трансформиране: dbt моделите се изпълняват за почистване, обединяване и агрегиране на данни за използване при анализи
Необработеният слой съдържа немаскирани, пълни лични данни: имена на клиенти, имейл адреси, телефонни номера, информация за плащане, съдържание на билети за поддръжка. Всеки, който има достъп до необработената схема – и в много организации, това е широк набор от инженери и анализатори на данни – може да я направи директно запитване.
Динамично маскиране, базирано на тагове, в Snowflake помага при заявка за правилно конфигурирани модели надолу по веригата. Но не маскира със задна дата необработените данни. Не защитава срещу директни необработени заявки за схема. Изисква всеки модел надолу по веригата и табло за управление да бъдат правилно маркирани - тежест за поддръжка, която расте със сложността на схемата.
Подходът за анонимизиране на ниво конвейер
Анонимизирането на PII на ниво тръбопровод - преди данните да се приземят в склада - елиминира излагането на необработен слой:
ETL подход (анонимизиране преди зареждане):
- Извлечете данни от изходните системи
- Преминете през стъпката на анонимизиране
- Заредете анонимизирани данни в склада
Складът никога не получава необработен PII. Необработената схема съдържа анонимизирани данни. Моделите надолу по веригата, таблата за управление и директните заявки работят с анонимизирани данни.
Това изисква или:
- Анонимизация, интегрирана в стъпката за извличане (ниво на API)
- Анонимизиране като етап на тръбопровод между извличане и зареждане
Опция за внедряване — API интеграция: За системи с изходящи уебкукички или поточно експортиране, пренасочете данните през anonym.legal API, преди да се приземите в склада. Билети за поддръжка на клиенти, напускащи Intercom → API за анонимизиране → склад. Записи за плащания в Stripe → API за анонимизиране → склад.
POST /api/anonymize
{
"text": "Customer John Smith (john@example.com) reported...",
"entities": ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER"],
"method": "replace"
}
Опция за внедряване — Пакетна предварителна обработка: За пакетно заредени данни (ежедневни/седмични експорти от изходни системи), изпълнете експортираните CSV/JSON файлове чрез пакетна обработка, преди да ги заредите в склада.
DAG структура на въздушния поток:
extract_task >> anonymize_batch_task >> load_to_warehouse_task
Anonymize_batch_task качва извлечени файлове за групова обработка и извлича анонимизирани версии. Задачата за зареждане зарежда анонимизираните файлове.
dbt Етикети на колона: Какво правят и какво не правят
dbt поддържа маркиране на PII колони:
models:
- name: stg_customers
columns:
- name: email
tags: ['pii', 'email']
- name: full_name
tags: ['pii', 'personal_data']
Това позволява:
- Документиране на местоположенията на PII
- Задействане на политики за маскиране надолу по веригата (изисква конфигурация на ниво склад)
- Проследяване на родословие (secoda и подобни инструменти могат да проследяват маркирани колони чрез модели надолу по веригата)
Това не позволява:
- Маскиране на необработените данни в необработената схема
- Защита срещу директни заявки на необработени таблици
- Автоматично анонимизиране при зареждане
- Ретроактивно маскиране на исторически данни
dbt колонните етикети са инструмент за документиране и управление. Те са ценни за разбирането къде съществува PII във вашия модел на данни. Те не прилагат „подходящите технически мерки“, които член 32 от GDPR изисква за защита на данните.
Пропускът в маскирането на динамични данни на Snowflake
Динамичното маскиране на данни на Snowflake прилага правила за маскиране към колони, скривайки данните от потребителите без привилегия за демаскиране по време на заявка. Това е мощен контрол за случаи на производствена употреба.
Ограниченията:
- Маскирането се прилага за колоните, върху които е конфигурирано - всяка колона, добавена след първоначалната конфигурация, изисква изрично прилагане на правила
- Развитието на схемата (нови колони, преименувани колони) може да създаде демаскирани колони с PII, докато политиките не бъдат актуализирани
- Потребителите с ролята SYSADMIN или ACCOUNTADMIN обикновено могат да заобиколят маскирането
- Процесите на импортиране на необработени данни често се изпълняват с повишени привилегии, които заобикалят маскирането
- Историческите данни, заредени преди прилагането на политиките, се съхраняват без маска (политиките се прилагат по време на четене, а не по време на съхранение)
За истинска защита маскирането по време на заявка е недостатъчно. Данните трябва да бъдат анонимизирани преди съхранение.
Документация за съответствие за тръбопроводи за анализ
Принципът на отчетност на GDPR изисква демонстриране на съответствие, а не просто заявяване. За екипите за инженеринг на данни това означава:
Записи за дейности по обработка (ROPA): Документирайте, че клиентските данни са анонимизирани преди зареждане в склада за анализи. Стъпката на анонимизиране във вашия конвейер е дейност по обработка под GDPR.
Документация за техническа защита: Конфигурацията за анонимизиране (кой тип обект, кой метод), използвана във вашия конвейер. Обработката на метаданни от пакетни изпълнения осигурява това автоматично.
Потекло на данни: Инструменти като Secoda или вграденото потекло на dbt могат да покажат, че изходните системни данни преминават през стъпка на анонимизиране, преди да достигнат до аналитични модели. Тази линия е вашата одитна пътека за съответствие.
Документация на подпроцесора: Услугата за анонимизиране е подпроцесор. Техните DPA и политика за поверителност трябва да бъдат документирани във вашия регистър на доставчици.
Практическо ръководство за внедряване
За базиран на dbt тръбопровод със Snowflake:
Стъпка 1: Одит на излагането на необработен слой Идентифицирайте кои таблици във вашата необработена схема съдържат лични данни. Изпратете запитване към вашите dbt тагове на колони или към вашия каталог с данни за таблици с PII етикети.
Стъпка 2: Идентифицирайте обхвата на анонимизирането За всяка необработена таблица: кои колони съдържат PII? Кое трябва да бъде анонимизирано или поддържано? (Тяло на билета за поддръжка на клиенти: анонимизиране. Идент. № на поръчка: псевдонимизиране с последователна замяна за разрешаване на обект. Времево клеймо: запазване за анализ на времеви серии.)
Стъпка 3: Изберете подход за внедряване Малък екип, пакетно заредени данни: обработка на пакетен файл преди зареждане Ресурси за инженеринг на данни: API интеграция в Airflow/Prefect тръбопровод
Стъпка 4: Тествайте и валидирайте Стартирайте анонимизация на извадка от необработени данни преди внедряването на продукцията. Уверете се, че dbt моделите надолу по веригата все още функционират правилно с анонимизиран вход. Някои модели може да използват имейл адреси за присъединяване — те трябва да използват последователни заместващи стойности (псевдонимизацията запазва ключовете за присъединяване, редактирането ги нарушава).
Стъпка 5: Обработка на исторически данни Съществуващите необработени данни (заредени преди прилагането на анонимизирането) изискват обработка със задна дата. Експортиране, анонимизиране, презареждане. Това е еднократна операция за историческа таблица.
Заключение
Базираното на тагове маскиране е инструмент за управление, а не контрол на сигурността. Той ви казва къде е вашият PII; това не пречи вашата PII да бъде изложена на потребители с достъп до необработена схема. За истинско съответствие на GDPR в тръбопроводите за данни, PII трябва да бъде анонимизиран, преди да се приземи в склада - което прави необработения слой толкова безопасен, колкото и производствения.
Това е по-сложно изпълнение от маркирането на колони, но това всъщност изисква „подходящите технически мерки“.
Източници:
- [Voi Engineering: Поверителност на личните данни в Snowflake] (https://medium.com/voi-engineering/pii-data-privacy-in-snowflake-b523d38b02ff)
- [Secoda: Поверителност на данните за dbt тръбопроводи] (https://www.secoda.co/glossary/data-privacy-for-dbt)
- dbt документация: метаданни на ниво колона
- [GDPR Член 32: Технически и организационни мерки] (https://gdpr-info.eu/art-32-gdpr/)