Privacy by Design

Privacy by Design (GDPR)

1) Про що це і навіщо

Privacy by Design (PbD) - принцип, згідно з яким приватність закладається в продукт з самого початку: в бізнес-вимоги, архітектуру, код, процеси та експлуатацію. У термінах GDPR це проявляється в «privacy by design і by default» (мінімізація зборів, налаштування за замовчуванням - максимально приватні, прозорість і підзвітність).

• Мінімізувати збір і обробку персональних даних (ПДн).
• Забезпечити законність, прозорість, коректність, обмеження цілей і термінів.
• Знизити ризики (технічні та правові), спростити аудит і доказовість відповідності.

2) Ролі, правові основи та принципи GDPR

2. 1 Ролі

Контролер (Controller): визначає цілі/засоби обробки.
Процесор (Processor): обробляє ПДн від імені контролера за договором DPA.
Суб'єкт даних (Data Subject): фізособа, до якої відносяться ПДн.
DPO (офіцер із захисту даних): на вимогу - незалежний контроль і консультації.

2. 2 Правові підстави (вибираємо і документуємо)

Згода, договір, законний інтерес, правовий обов'язок, життєво важливі інтереси, суспільне завдання. Для кожного - мета, дані, утримання, можливість відкликання (для згоди).

2. 3 Принципи обробки (ст. 5)

Законність, справедливість, прозорість

Обмеження мети

Мінімізація даних

Точність

Обмеження зберігання

Цілісність і конфіденційність

Підзвітність (accountability) - вміння довести відповідність.

3) Процес PbD в SDLC (reference framework)

1. Ініціація: формулювання цілей обробки і правових підстав, призначення owner'ів даних і DPO-пойнта.
2. Картування даних (Data Mapping): джерела → поля → довірча модель → куди течуть → хто читає → де зберігаються → термін.
3. Оцінка ризиків/DPIA: LINDDUN-модель загроз приватності, оцінка впливу, заходи зниження.
4. Архітектурні рішення: вибір схем мінімізації, псевдонімізації, шифрування, розмежування.
5. Вимоги до UX/згоди/повідомлень: зрозумілі тексти, granular consent, налаштування за замовчуванням.
6. Реалізація: приватні дефолти, безпечна телеметрія, логування без секретів/PII.
7. Верифікація: тести приватності, статичний аналіз, приватні unit-тести, протоколи DPIA.
8. Експлуатація: DSAR-процеси, ретенції і видалення, моніторинг інцидентів, рев'ю постачальників.
9. Регулярний перегляд: re-DPIA при зміні цілей/технологій.

4) Інженерні патерни PbD

4. 1 Мінімізація і декомпозиція

Збирати тільки необхідні поля; застосовувати progressive profiling.
Розділяйте ідентифікатор і контент: зберігайте ключ зв'язку окремо (token/reference).

4. 2 Псевдонімізація та анонімізація

Псевдонімізація: зберігайте реальний ідентифікатор окремо; робочий шар бачить токен.
Анонімізація: використовуйте k-анонімність, l-diversity, t-closeness; для аналітики - диференціальна приватність (ε -budget).

4. 3 Контроль доступу і поділ ролей

PoLP, ABAC/RBAC, segregation of duties, окремі контури для адмінів та аналітиків.
Тих. заходи: mTLS, SSO/OIDC, scoped-токени, тимчасові обліки для доступу до ПДн.

4. 4 Шифрування та ізоляція

In Transit: TLS 1. 3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
Окремі ключі на орендаря/датасет; крипто-видалення для «права на забуття».

4. 5 Ретенція і видалення

Явні політики TTL per поле/цілі; auto-purge в пайплайнах; «двофазне» видалення (логічне → фізичне).
Для бекапів - роздільні ключі і короткі вікна зберігання персональних снапшотів.

4. 6 Приватна телеметрія і логування

Типово - без PII; використовувати токени/хешування з сіллю.
Маскування/токенізація чутливих полів на продьюсері.

4. 7 UX приватності та згоди

Granular consent за категоріями (аналітика, маркетинг, персоналізація).
«Приватні дефолти»: все не критичне - вимкнено, поки не погодився.
Чітка опція «Відкликати згоду» і just-in-time повідомлення при новому використанні.

5) DPIA і LINDDUN (коротко)

DPIA (оцінка впливу на захист даних): потрібно при високій ризиковості (масштабний моніторинг, оцінка, нова технологія). Складається з опису обробки, необхідності/пропорційності, оцінки ризиків, заходів зниження.
LINDDUN загрози: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Для кожної загрози - контрзаходи (мінімізація, псевдонімізація, DP, прозорість, управління згодою, аудит).

6) Транскордонні передачі

З'ясувати локації зберігання/доступу постачальників.
Використовувати SCC (стандартні договірні положення) і проводити Transfer Impact Assessment.
Техмери: end-to-end шифрування, клієнтська криптографія для особливо чутливих даних, обмеження віддаленого доступу.

7) Постачальники та процесори (Vendor Management)

DPA/вкладені процесори, технічні та організаційні заходи, субпроцесори - під контроль.
Регулярні рев'ю та аудити; право на інспекцію; план виходу/міграції (data export).

8) Права суб'єктів даних (DSAR)

Доступ, виправлення, видалення, обмеження, переносимість, заперечення, не бути об'єктом AADM (профілювання/автоматизація).
SLA та автоматизація: трекінг запитів, доказ ідентифікації, журнал відповідей.
Технічні хуки в продукті: швидкий пошук та експорт за ідентифікатором; каскадне видалення за ретенціями.

9) Автоматизовані рішення та профілювання (ст. 22)

Якщо рішення зі «значним впливом» приймаються автоматом - забезпечити право на втручання людини, зрозумілість, прозорість ознак.
Log-шлях і версіонування моделей; механізм апеляції.

10) Безпека обробки (ст. 32) та інциденти (ст. 33/34)

Ризик-орієнтовані заходи: шифрування, цілісність, стійкість, плани відновлення (RTO/RPO).
Інциденти з ПДн: процес виявлення → тріаж → оцінка ризику → повідомлення регулятора ≤ 72 годин (де потрібно) і суб'єктів (якщо високий ризик).
Окремий плейбук, контакт-лист DPO/юристів, шаблони повідомлень.

11) Приватність і ML/аналітика

Data Governance наборів: дата-лінійдж, ліцензії/підстави, згоди.
Техніки: диференціальна приватність, federated learning, secure aggregation, мінімізація фічів.
Захист від атак: membership/model inversion - регулярні оцінки витоків, налаштування ε, шум/clip.
Синтетичні дані - тільки з перевіркою відсутності відновлення персон.

12) Архітектурні схеми (патерни)

12. 1 «Двоконтурна» архітектура ідентифікаторів

Контур A (PDS - Personal Data Store): реальні ідентифікуючі дані (РІД), доступ - строго обмежений, ключі/шифрування/аудит.
Контур B (Operational): бізнес-дані з токенами; зв'язку через брокер токенів з лімітами і аудитом.

12. 2 Шина згоди (Consent Service)

Централізований сервіс, що зберігає версії згоди та історію.
SDK: 'can _ use (category, purpose)'- вирішує на льоту; все логується.

12. 3 Політики ретенції як код

Конфігурація YAML: сутність → поля → TTL → дію при закінченні (анонімізація/видалення/огрубіння).
Планувальник виконує job'и, звітність доступна DPO.

13) Міні-рецепти

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) Документація та підзвітність

ROPA (Records of Processing Activities) - реєстр операцій: мета, правова підстава, категорії даних/суб'єктів, передачі, терміни зберігання, заходи.
Політики: приватність, куки, інформаційні повідомлення в продукті (зрозумілою мовою).
Навчання персоналу та щорічні рев'ю.

15) Часті помилки

Збір «про всяк випадок» і зберігання «назавжди».
Згода як єдина підстава, хоча підходить договір/законний інтерес.
«Порожні» банери cookie без реальних перемикачів.
Відсутність картування даних і неготовність до DSAR.
Логи з PII, незахищені бекапи, змішання РІД і операційних даних.
Немає контролю постачальників і транскордонних передач.

16) Чек-листи

• Визначено мету обробки та правову основу; оновлено ROPA.
• Виконано картування даних і DPIA (при необхідності).
• Реалізовані мінімізація, псевдонімізація, шифрування (в дорозі/на спокої).
• Згоди - гранулярні, зі зрозумілим UX; дефолти - приватні.
• Налаштовані політики ретенції як код; видалення/анонімізація перевірені.
• Логи/телеметрія - без PII; маскування включено.
• Підготовлені DSAR-хуки і експорт.
• Проведено навчання команди і затвердження DPO.

• Щоквартальний огляд ретенцій і правових підстав.
• Періодичний аудит процесорів/субпроцесорів.
• Моніторинг інцидентів і готовність до повідомлення ≤ 72 год.
• Перегляд DPIA при змінах процесів/технологій.

Зберігання артефактів відповідності (DPIA, ROPA, звіти тестів).

17) FAQ

В: Чи можна повністю «втекти» від згоди?
ПРО: Іноді - так (договір/законний обов'язок/законний інтерес), але тільки при суворій необхідності і з оцінкою балансу інтересів. Маркетинг і некритична аналітика - найчастіше вимагають згоди.

В: Чи достатньо псевдонімізації?
ПРО: Ні, це все ще персональні дані. Для виходу зі сфери GDPR потрібна надійна анонімізація (що перевіряється на неможливість повторної ідентифікації).

В: Як бути з ML і персоналізацією?
ПРО: Мінімізуйте фічі, використовуйте DP/federated підходи, логуйте рішення, забезпечте право на втручання людини і відмову від профілювання.

В: Що робити при конфлікті бізнесу і приватності?
ПРО: Перепроектувати збір (progressive profiling), переключитися на агрегати/синтетику, переоцінити правову підставу, запропонувати опцію без трекінгу.

• «Менеджмент секретів»
• «Шифрування At Rest»
• «Шифрування In Transit»
• «Аудит і незмінні журнали»
• «Підпис і верифікація запитів»
• «Управління ключами та ротація»