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) SDLC-дегі PbD процесі (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 ашық/мақсаттар саясаты; пайплайндардағы 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 - ағуды тұрақты бағалау, ε баптау, шу/клип.
Синтетикалық деректер - тұлғаларды қалпына келтірудің жоқтығын тексерумен ғана.

12) Сәулет схемалары (паттерндер)

12. 1 «Екі контурлы» сәйкестендіргіш архитектурасы

A контуры (PDS - Personal Data Store): нақты сәйкестендіруші деректер (ИДР), қол жеткізу - қатаң шектелген, кілттер/шифрлау/аудит.
B контуры (Operational): токендері бар бизнес-деректер; лимиттері мен аудиті бар токендер брокері арқылы байланыстар.

12. 2 Келісім шинасы (Consent Service)

Келісімдер мен тарихтың нұсқаларын сақтайтын орталықтандырылған сервис.
SDK: 'can _ use (category, purpose)' - ұшуда шешеді; бәрі ойланып жатыр.

12. 3 Ретенция саясаты код ретінде

YAML конфигурациясы: мән → өріс → TTL → аяқталған кездегі әрекет (анонимдеу/жою/қиыстыру).
Жоспарлаушы job's орындайды, есептілік 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) - операциялар тізілімі: мақсаты, құқықтық негізі, деректер/субъектілер санаттары, беру, сақтау мерзімдері, шаралары.
Саясат: жекешелiк, куки, өнiмдегi ақпараттық хабарламалар (түсiнiктi тiлде).
Персоналды оқыту және жыл сайынғы ревю.

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 шифрлау»
• «Аудит және өзгермейтін журналдар»
• «Сұрау салуларға қол қою және тексеру»
• «Кілттерді басқару және ротация»