Privacy by Design

Privacy by Design (GDPR)

1) Nima haqida va nima uchun

Privacy by Design (PbD) - printsip, unga ko’ra maxfiylik mahsulotga boshidanoq: biznes talablari, arxitektura, kod, jarayonlar va ekspluatatsiyaga qo’yiladi. GDPR atamalarida bu «privacy by design va by default» da namoyon bo’ladi (yig’imlarni minimallashtirish, andoza sozlash - maksimal shaxsiy, shaffoflik va hisobdorlik).

• Shaxsiy ma’lumotlarni yig’ish va qayta ishlashni minimallashtirish.
• Maqsadlar va muddatlarning qonuniyligi, shaffofligi, to’g "riligi, cheklanishini ta’minlash.
• Xavflarni (texnik va huquqiy) kamaytirish, auditni soddalashtirish va muvofiqlikni isbotlash.

2) GDPRning roli, huquqiy asoslari va tamoyillari

2. 1 Rollar

Controller: ishlov berish maqsadlarini/vositalarini aniqlaydi.
Protsessor (Processor): DPA shartnomasi boʻyicha nazorat qiluvchi nomidan PDni qayta ishlaydi.
Ma’lumotlar subyekti (Data Subject): PDn tegishli bo’lgan jismoniy shaxs.
DPO (ma’lumotlarni himoya qilish ofitseri): talab bo’yicha - mustaqil nazorat va maslahatlar.

2. 2 Huquqiy asoslar (tanlaymiz va hujjatlashtiramiz)

Rozilik, shartnoma, qonuniy manfaatlar, huquqiy majburiyat, hayotiy muhim manfaatlar, ijtimoiy vazifa. Har bir kishi uchun - maqsad, ma’lumotlar, ushlab qolish, chaqirib olish imkoniyati (rozilik uchun).

2. 3 Qayta ishlash prinsiplari (5-modda)

Qonuniylik, adolat, shaffoflik

Maqsadni cheklash

Maʼlumotlarni minimallashtirish

Aniqlik

Saqlashni cheklash

Yaxlitlik va maxfiylik

Hisobdorlik (accountability) - muvofiqlikni isbotlash qobiliyati.

3) SDLCdagi PbD jarayoni (reference framework)

1. Tashabbus: qayta ishlash maqsadlari va huquqiy asoslarni ifodalash, ma’lumotlar owner’lari va DPO-punktni tayinlash.
2. Ma’lumotlarni xaritalash (Data Mapping): manbalar → maydonlar → ishonchli model → qayerga oqadi → kim o’qiydi → qayerda saqlanadi → muddat.
3. Xavflarni baholash/DPIA: LINDDUN - maxfiylik tahdidlari modeli, ta’sirni baholash, kamaytirish choralari.
4. Arxitektura yechimlari: minimallashtirish, taxalluslashtirish, shifrlash, chegaralash sxemalarini tanlash.
5. UX/kelishuv/xabarnoma talablari: tushunarli matnlar, granular consent, andoza moslamalar.
6. Amalga oshirish: shaxsiy defoltlar, xavfsiz telemetriya, maxfiyliksiz logografiya/PII.
7. Verifikatsiya: maxfiylik testlari, statik tahlil, shaxsiy unit-testlar, DPIA protokollari.
8. Ekspluatatsiya: DSAR-jarayonlar, retensiyalar va olib tashlash, hodisalar monitoringi, yetkazib beruvchilarning revyusi.
9. Maqsadlar/texnologiyalar o’zgarganda re-DPIAni muntazam qayta ko’rib chiqish.

4) PbD muhandislik patternlari

4. 1 Minimallashtirish va dekompozitsiya

Faqat zarur maydonlarni yig’ish; progressiv profilingni qo’llash.
Identifikator va kontentni ajrating: aloqa kalitini alohida saqlang (token/reference).

4. 2 Taxalluslashtirish va anonimlashtirish

Taxalluslashtirish: haqiqiy identifikatorni alohida saqlang; ish qatlami tokenni koʻradi.
Anonimlashtirish: k-anonimlik, l-diversity, t-closeness; tahlilchilar uchun - differensial maxfiylik (ε -budget).

4. 3 Foydalanishni nazorat qilish va rollarni ajratish

PoLP, ABAC/RBAC, segregation of duties, ma’murlar va tahlilchilar uchun alohida konturlar.
Tech. chora-tadbirlar: mTLS, SSO/OIDC, scoped-tokenlar, PDndan foydalanish uchun vaqtinchalik hisobga olish.

4. 4 Shifrlash va izolyatsiya qilish

In Transit: TLS 1. 3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
Ijarachiga alohida kalitlar/sana; «unutish huquqi» uchun kripto-olib tashlash.

4. 5 Retensiya va olib tashlash

Aniq siyosatlar TTL per maydoni/maqsadlari; payplaynlarda auto-purge; «ikki fazali» olib tashlash (mantiqiy → jismoniy).
Bekaplar uchun - alohida kalitlar va shaxsiy snapshotlarni saqlashning qisqa oynalari.

4. 6. Xususiy telemetriya va logografiya

Andoza - PIIsiz; tuz bilan xeshlash tokenlaridan foydalanish.
Prodyuserda sezgir maydonlarni maskalash/tokenlash.

4. 7 UX Maxfiylik va rozilik

Granular consent toifalari bo’yicha (tahlil, marketing, shaxsiylashtirish).
«Shaxsiy defoltlar»: hamma narsa muhim emas - rozilik berilgunga qadar o’chirilgan.
Yangi foydalanishda «Rozilikni qaytarib olish» va just-in-time xabarnomalarining aniq varianti.

5) DPIA va LINDDUN (qisqacha)

DPIA (ma’lumotlarni himoya qilishga ta’sirni baholash): yuqori xavflilikda (keng ko’lamli monitoring, baholash, yangi texnologiya) talab etiladi. Ishlov berish tavsifidan, zaruriyat/mutanosiblikdan, tavakkalchiliklarni baholashdan, kamaytirish choralaridan iborat.
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Har bir tahdid uchun - qarshi choralar (minimallashtirish, taxalluslashtirish, DP, shaffoflik, kelishuvlarni boshqarish, audit).

6) Transchegaraviy o’tkazmalar

Yetkazib beruvchilarning saqlash/foydalanish joylarini aniqlash.
SCC (standart shartnoma qoidalari) dan foydalanish va Transfer Impact Assessment.
Texnik chora-tadbirlar: end-to-end shifrlash, alohida sezgir ma’lumotlar uchun mijozlar kriptografiyasi, masofadan turib foydalanishni cheklash.

7) Etkazib beruvchilar va protsessorlar (Vendor Management)

DPA/qo’yilgan protsessorlar, texnik va tashkiliy chora-tadbirlar, subprotsessorlar - nazorat ostida.
Muntazam revyu va auditlar; inspeksiya huquqi; chiqish/migratsiya rejasi (data export).

8) Ma’lumotlar subyektlarining huquqlari (DSAR)

Kirish, tuzatish, olib tashlash, cheklash, chidamlilik, e’tiroz bildirish, AADM obyekti bo’lmaslik (profillash/avtomatlashtirish).
SLA va avtomatlashtirish: so’rovlar trekingi, identifikatsiya isboti, javoblar jurnali.
Mahsulotdagi texnik xuklar: identifikator bo’yicha tezkor qidirish va eksport qilish; reteniyalar bo’yicha kaskadli olib tashlash.

9) Avtomatlashtirilgan yechimlar va profillash (22-modda)

Agar «sezilarli ta’sir ko’rsatadigan» qarorlar avtomatik tarzda qabul qilinsa, inson aralashuviga, tushunarliligiga, belgilarining shaffofligiga bo’lgan huquqni ta’minlash.
Log-yo’l va modellarni versiyalash; apellatsiya mexanizmi.

10) Ishlov berish xavfsizligi (32-modda) va noxush hodisalar (33/34-modda)

Tavakkalchilikka yo’naltirilgan chora-tadbirlar: shifrlash, yaxlitlik, barqarorlik, tiklash rejalari (RTO/RPO).
PD bilan bog’liq noxush hodisalar: aniqlash jarayoni → triaj → xavfni baholash → regulyatorni xabardor qilish ≤ 72 soat (talab qilinadigan joylarda) va subyektlar (agar xavf yuqori bo’lsa).
Alohida pleybuk, DPO/yuristlar aloqa varaqasi, bildirishnoma shablonlari.

11) Maxfiylik va ML/tahlil

Data Governance to’plamlari: data-linedj, litsenziyalar/asoslar, rozilik.
Texnikalar: differensial maxfiylik, federated learning, secure aggregation, fichlarni minimallashtirish.
Hujumlardan himoya qilish: membership/model inversion - oqishni muntazam baholash, ε sozlash, shovqin/klip.
Sintetik ma’lumotlar - faqat shaxslarni tiklashning yo’qligini tekshirish bilan.

12) Arxitektura sxemalari (patternlar)

12. 1 «Ikki konturli» identifikator arxitekturasi

A konturi (PDS - Personal Data Store): real identifikatsiya ma’lumotlari (ID), kirish qat’iy cheklangan, kalitlar/shifrlash/audit.
Kontur B (Operational): tokenlar bilan biznes ma’lumotlar; tokenlar brokeri orqali limitlar va audit bilan aloqalar.

12. 2 Rozilik shinasi (Consent Service)

Kelishuvlar va tarixni saqlaydigan markazlashtirilgan xizmat.
SDK:’can _ use (category, purpose)’- uchishda hal qiladi; hamma narsa noto’g’ri.

12. 3 Retensiya siyosati kod sifatida

YAML konfiguratsiyasi: mohiyat → maydon → TTL → amal tugaganda (anonimlashtirish/olib tashlash/kesish).
Rejalashtiruvchi job’larni bajaradi, hisobot DPO tomonidan mavjud.

13) Mini-retseptlar

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) Hujjatlar va hisobdorlik

ROPA (Records of Processing Activities) - operatsiyalar reyestri: maqsad, huquqiy asos, ma’lumotlar/subyektlar toifalari, uzatish, saqlash muddatlari, chora-tadbirlar.
Siyosatlar: maxfiylik, kukilar, mahsulotdagi axborot xabarnomalari (tushunarli tilda).
Xodimlarni o’qitish va har yili revyu.

15) Tez-tez xatolar

«Har qanday holatda» yigʻish va «abadiy» saqlash.
Rozilik yagona asos sifatida, garchi shartnoma/qonuniy manfaat mos kelsa ham.
Haqiqiy kalitsiz «boʻsh» cookie bannerlar.
Ma’lumotlarni xaritalashning yo’qligi va DSARga tayyor emasligi.
PII loglari, himoyalanmagan bekaplar, IDR va operatsion ma’lumotlarni aralashtirish.
Yetkazib beruvchilar va transchegaraviy uzatmalar nazorati mavjud emas.

16) Chek varaqlari

• Qayta ishlashning maqsadi va huquqiy asoslari aniqlandi; ROPA yangilandi.
• Maʼlumotlar va DPIA xaritasi bajarildi (zarurat boʻlganda).
• Minimallashtirish, taxalluslashtirish, shifrlash (yo’lda/tinchlikda) amalga oshirildi.
• Rozilik - granulyar, tushunarli UX bilan; defoltlar - shaxsiy.
• Retensiya siyosati kod sifatida sozlangan; olib tashlash/anonimlashtirish tekshirildi.
• Logi/telemetriya - PIIsiz; maskalash yoqilgan.
• DSAR-xuklar va eksport tayyorlandi.
• Jamoa o’qitildi va DPO tasdiqlandi.

• Retensiyalar va huquqiy asoslarning har choraklik sharhi.
• Protsessorlar/subprotsessorlarning davriy auditi.
• Hodisalar monitoringi va xabardor qilishga tayyorlik ≤ 72 soat.
• Jarayonlar/texnologiyalar o’zgarganda DPIAni qayta ko’rib chiqish.
• Muvofiqlik artefaktlarini saqlash (DPIA, ROPA, test hisobotlari).

17) FAQ

V: Roziliklardan butunlay qochish mumkinmi?
O: Ba’zan - ha (shartnoma/qonuniy majburiyat/qonuniy manfaat), lekin faqat qat’iy zarurat bo’lganda va manfaatlar balansini baholagan holda. Marketing va tanqidiy bo’lmagan tahlillar ko’pincha rozilikni talab qiladi.

V: Taxallus yetarlimi?
O: Yo’q, bu hali ham shaxsiy ma’lumotlar. GDPR sohasidan chiqish uchun ishonchli anonimlashtirish kerak (qayta identifikatsiyalash mumkin emasligi tekshiriladi).

S: ML va shaxsiylashtirish haqida nima deyish mumkin?
O: Fichlarni minimallashtiring, DP/federated yondashuvlardan foydalaning, qarorlarni logotiplashtiring, inson aralashuvi va profillashdan bosh tortish huquqini ta’minlang.

V: Biznes va maxfiylik to’qnashuvida nima qilish kerak?
A: Yig’imni qayta loyihalash (progressive profiling), agregatlar/sintetikaga o’tish, huquqiy asosni qayta baholash, trekingsiz variantni taklif qilish.

• «Sirlar menejmenti»
• «At Rest shifrlash»
• «In Transit shifrlash»
• «Audit va o’zgarmas jurnallar»
• «So’rovlarning imzosi va verifikatsiyasi»
• «Kalitlarni boshqarish va rotatsiya»