Privacy by Design

Privacy by Design (GDPR)

1) რა არის ეს და რატომ

Privacy by Design (PbD) არის პრინციპი, რომლის თანახმად, კონფიდენციალურობა თავიდანვე იდება პროდუქტში: ბიზნეს მოთხოვნებში, არქიტექტურაში, კოდში, პროცესებსა და ექსპლუატაციაში. GDPR- ის თვალსაზრისით, ეს ვლინდება „პირადი დიზაინის და უსაფრთხოების დაცვაში“ (საფასურის შემცირება, ნაგულისხმევი პარამეტრები - მაქსიმალური პირადი, გამჭვირვალობა და ანგარიშვალდებულება).

• შეამცირეთ პერსონალური მონაცემების შეგროვება და დამუშავება (PDN).
• უზრუნველყოს კანონიერება, გამჭვირვალეობა, სისწორე, მიზნების და ვადების შეზღუდვა.
• შეამცირეთ რისკები (ტექნიკური და სამართლებრივი), გაამარტივეთ აუდიტი და შესაბამისობის დადასტურება.

2) როლები, სამართლებრივი საფუძვლები და პრინციპები GDPR

2. 1 როლები

კონტროლერი: განსაზღვრავს დამუშავების მიზნებს/საშუალებებს.
პროცესორი (პროფესორი): ამუშავებს MPN- ს მაკონტროლებლის სახელით DPA ხელშეკრულებით.
მონაცემთა საგანი (Data Subject): ინდივიდი, რომელიც მოიცავს PDN- ს.
DPO (მონაცემთა დაცვის ოფიცერი): მოთხოვნით - დამოუკიდებელი კონტროლი და კონსულტაციები.

2. 2 იურიდიული საფუძვლები (არჩევა და დოკუმენტაცია)

თანხმობა, ხელშეკრულება, კანონიერი ინტერესი, იურიდიული მოვალეობა, სასიცოცხლო ინტერესები, სოციალური ამოცანა. თითოეულისთვის - მიზანი, მონაცემები, გამართვა, გაწვევის შესაძლებლობა (თანხმობისთვის).

2. 3 დამუშავების პრინციპები (მუხლი 5)

კანონიერება, სამართლიანობა, გამჭვირვალეობა

მიზნის შეზღუდვა

მონაცემთა შემცირება

სიზუსტე

შენახვის შეზღუდვა

მთლიანობა და კონფიდენციალურობა

ანგარიშვალდებულება (ანგარიშვალდებულება) - შესაბამისობის დამტკიცების უნარი.

3) PbD პროცესი SDLC- ში (reference framework)

1. ინიციაცია: დამუშავების მიზნების ფორმულირება და სამართლებრივი საფუძვლები, მონაცემთა owner's და DPO წერტილის დანიშვნა.
2. მონაცემთა რუქა: წყაროები - ველი - ნდობის მოდელი, სადაც მიედინება ის, ვინც კითხულობს, სად ინახება.
3. რისკების შეფასება/DPIA: LINDDUN კონფიდენციალურობის საფრთხეების მოდელი, გავლენის შეფასება, შემცირების ზომები.
4. არქიტექტურული გადაწყვეტილებები: მინიმიზაციის, ფსევდონიმიზაციის, დაშიფვრის, დემარკაციის სქემების არჩევა.
5. მოთხოვნები UX/თანხმობებისთვის/შეტყობინებებისთვის: გასაგები ტექსტები, გრაფიკული კონსენსენტი, ნაგულისხმევი კონფიგურაცია.
6. განხორციელება: პირადი ნაგულისხმევი, უსაფრთხო ტელემეტრია, ლოგიკური საიდუმლოებების გარეშე/PII.
7. გადამოწმება: კონფიდენციალურობის ტესტები, სტატიკური ანალიზი, პირადი unit ტესტები, DPIA პროტოკოლები.
8. ოპერაცია: DSAR პროცესები, რეტენციები და მოცილება, ინციდენტების მონიტორინგი, მომწოდებლების შურისძიება.
9. რეგულარული გადასინჯვა: re-DPIA მიზნების/ტექნოლოგიების შეცვლისას.

4) საინჟინრო ნიმუშები PbD

4. 1 მინიმიზაცია და დაშლა

შეაგროვეთ მხოლოდ საჭირო ველები; გამოიყენეთ პროფესიული პროფესია.
იზიარეთ იდენტიფიკატორი და შინაარსი: შეინახეთ საკომუნიკაციო გასაღები ცალკე (ტოკენი/რეფერენტი).

4. 2 ფსევდონიმიზაცია და ანონიმიზაცია

ფსევდონიმიზაცია: შეინახეთ რეალური იდენტიფიკატორი ცალკე; სამუშაო ფენა ხედავს ნიშანს.
ანონიმიზაცია: გამოიყენეთ k- ანონიმურობა, l-diversity, t-closeness; ანალიტიკოსებისთვის - დიფერენციალური კონფიდენციალურობა ().

4. 3 წვდომის კონტროლი და როლების გამიჯვნა

POLP, ABAC/RBAC, duties segregation, ცალკეული კონტურები admins და ანალიტიკოსებისთვის.
ესენი. ზომები: mTLS, SSO/OIDC, scoped ნიშნები, დროებითი გადასახადები MPN- ზე წვდომისთვის.

4. 4 დაშიფვრა და იზოლაცია

In Transit: TLS 1. 3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
ინდივიდუალური გასაღებები მოიჯარეზე/თარიღზე; კრიპტო მოცილება „დავიწყების უფლებისთვის“.

4. 5 რეცენზია და მოცილება

აშკარა პოლიტიკოსები TTL per ველი/მიზნები; auto purge plings; „ორფაზიანი“ მოცილება (ლოგიკური და ფიზიკური).
ზურგჩანთებისთვის - ცალკეული გასაღებები და პერსონალური snapshots- ის შენახვის მოკლე ფანჯრები.

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.
Techmers: end დაშიფვრა, კლიენტის კრიპტოგრაფია განსაკუთრებით მგრძნობიარე მონაცემებისთვის, დისტანციური წვდომის შეზღუდვა.

7) მომწოდებლები და პროცესორები (Vendor Management)

DPA/ინვესტირებული პროცესორები, ტექნიკური და ორგანიზაციული ზომები, ქვე-პროცესორები - კონტროლის ქვეშ.
რეგულარული შურისძიება და აუდიტი; შემოწმების უფლება; გასასვლელი/მიგრაციის გეგმა (მონაცემთა ექსპორტი).

8) მონაცემთა სუბიექტების უფლებები (DSAR)

წვდომა, კორექტირება, მოცილება, შეზღუდვა, ტოლერანტობა, წინააღმდეგობა, არ იყოს AADM ობიექტი (პროფილირება/ავტომატიზაცია).
SLA და ავტომატიზაცია: მოთხოვნის ტრეკინგი, იდენტიფიკაციის მტკიცებულება, პასუხის ჟურნალი.
პროდუქტის ტექნიკური კაკალი: სწრაფი ძებნა და ექსპორტი იდენტიფიკატორის მიხედვით; კასკადის მოცილება რენტგენებით.

9) ავტომატური გადაწყვეტილებები და პროფილირება (22)

თუ „მნიშვნელოვანი გავლენის“ მქონე გადაწყვეტილებები მიიღება ავტომატით - უზრუნველყოს ადამიანის ჩარევის უფლება, ახსნა, ნიშნების გამჭვირვალობა.
ჟურნალი გზა და მოდელების ვერსია; გასაჩივრების მექანიზმი.

10) დამუშავების უსაფრთხოება (32-ე მუხლი) და ინციდენტები (მუხლი 33/34)

რისკზე ორიენტირებული ზომები: დაშიფვრა, მთლიანობა, სტაბილურობა, აღდგენის გეგმები (RTO/RPO).
PDN- სთან ინციდენტები: სამჯერ აღმოჩენის პროცესი - რისკის შეფასება - რეგულატორის შეტყობინება 72 საათის განმავლობაში (სადაც საჭიროა) და სუბიექტები (თუ მაღალი რისკია).
ცალკე ფლეიბუკი, DPO/იურისტების საკონტაქტო სია, შეტყობინებების შაბლონები.

11) კონფიდენციალურობა და ML/ანალიტიკა

მონაცემთა მთავრობის ნაკრები: მონაცემთა ხაზი, ლიცენზია/საფუძვლები, თანხმობა.
ტექნიკა: დიფერენციალური კონფიდენციალურობა, დიფერენციალური შეზღუდვა, საიდუმლოების აღდგენა, ძაფების შემცირება.
თავდასხმებისგან დაცვა: membership/model ინვერსია - გაჟონვის რეგულარული შეფასებები, კონფიგურაცია, ხმაური/clip.
სინთეზური მონაცემები - მხოლოდ პიროვნების აღდგენის არარსებობის შემოწმებით.

12) არქიტექტურული სქემები (ნიმუშები)

12. 1 იდენტიფიკატორის „ორმაგი წრიული“ არქიტექტურა

კონტური A (PDS - პირადი მონაცემთა მაღაზია): რეალური იდენტიფიკაციის მონაცემები (RID), წვდომა მკაცრად შეზღუდულია, გასაღებები/დაშიფვრა/აუდიტი.
კონტური B (ოპერატიული): ბიზნეს მონაცემები ნიშნით; კონტაქტები ტოკენის ბროკერის საშუალებით შეზღუდვებთან და აუდიტთან.

12. 2 თანხმობის ავტობუსი

ცენტრალიზებული სერვისი, რომელიც ინახავს თანხმობის ვერსიებს და ისტორიას.
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 (პროფესიული საქმიანობის ჩანაწერები) - ოპერაციების რეესტრი: მიზანი, იურიდიული საფუძველი, მონაცემთა/საგნების კატეგორიები, გადაცემები, შენახვის დრო, ზომები.
პოლიტიკოსები: კონფიდენციალურობა, ქუქი-ფაილები, პროდუქტის საინფორმაციო შეტყობინებები (გასაგები ენაზე).
პერსონალის ტრენინგი და ყოველწლიური შურისძიება.

15) ხშირი შეცდომები

შეგროვება „მხოლოდ შემთხვევაში“ და შენახვა „სამუდამოდ“.
თანხმობა, როგორც ერთადერთი საფუძველი, თუმცა ხელშეკრულება/კანონიერი ინტერესი შესაფერისია.
Cookie „ცარიელი“ ბანერები რეალური კონცენტრატორების გარეშე.
მონაცემთა რუქის არარსებობა და DSAR მზადყოფნა.
ლოგოები PII- ით, დაუცველი ზურგჩანთები, RID- ის და ოპერაციული მონაცემების ნაზავი.
არ არსებობს მომწოდებლების კონტროლი და ტრანსსასაზღვრო ტრანსპორტი.

16) ჩეკის ფურცლები

• განსაზღვრულია დამუშავების მიზანი და სამართლებრივი საფუძველი; განახლებულია ROPA.
• მონაცემთა რუქა და DPIA (საჭიროების შემთხვევაში).
• ხორციელდება მინიმიზაცია, ფსევდონიმები, დაშიფვრა (გზაზე/დასვენებისთვის).
• თანხმობა - მარცვლოვანი, გასაგები UX; ნაგულისხმევი - პირადი.
• რეტენციული პოლიტიკოსები არიან, როგორც კოდი; შემოწმებულია მოცილება/ანონიმიზაცია.
• ლოგები/ტელემეტრია - PII- ის გარეშე; შენიღბვა ჩართულია.
• მომზადებულია DSAR huks და ექსპორტი.
• მომზადდა გუნდი და დამტკიცდა DPO.

• რეტენციებისა და სამართლებრივი საფუძვლების კვარტალური მიმოხილვა.
• პროცესორების/ქვე-პროცესორების პერიოდული აუდიტი.
• ინციდენტების მონიტორინგი და შეტყობინებების მზადყოფნა 72:
• DPIA- ს გადასინჯვა პროცესების/ტექნოლოგიების ცვლილებებში.
• შესაბამისობის არტეფაქტების შენახვა (DPIA, ROPA, ტესტების მოხსენებები).

17) FAQ

გ: შესაძლებელია თუ არა „სრულად გაქცევა“ შეთანხმებისგან?
ო: ზოგჯერ - დიახ (ხელშეკრულება/კანონიერი მოვალეობა/კანონიერი ინტერესი), მაგრამ მხოლოდ მკაცრი საჭიროების შემთხვევაში და ინტერესთა ბალანსის შეფასებით. მარკეტინგი და არაკრიტიკული ანალიტიკა - ყველაზე ხშირად თანხმობას მოითხოვს.

გ: საკმარისია ფსევდონიზაცია?
ო: არა, ეს ჯერ კიდევ პერსონალური მონაცემებია. GDPR სფეროს გასასვლელად საჭიროა საიმედო ანონიმიზაცია (შემოწმებულია ხელახალი იდენტიფიკაციის შეუძლებლობისთვის).

გ: როგორ მოვიქცეთ ML- ით და პერსონალიზაციით?
O: მინიმუმამდე დაიყვანეთ ფიჩები, გამოიყენეთ DP/federated მიდგომები, შეაფასეთ გადაწყვეტილებები, უზრუნველყეთ ადამიანის ჩარევის უფლება და პროფილის უარყოფა.

გ: რა უნდა გავაკეთოთ ბიზნესისა და კონფიდენციალურობის კონფლიქტის დროს?
O: გადახედეთ შეგროვებას, გადახედეთ დანაყოფებს/სინთეზს, შეაფასეთ იურიდიული საფუძველი, შესთავაზეთ ვარიანტი ტრეკინგის გარეშე.

• საიდუმლო მენეჯმენტი
• „დაშიფვრა At Rest“
• „დაშიფვრა In Transit“
• „აუდიტი და უცვლელი ჟურნალები“
• „მოთხოვნის ხელმოწერა და გადამოწმება“
• „კლავიშების მართვა და როტაცია“