GH GambleHub

Prywatność według projektu: zasady projektowania

1) Dlaczego jest potrzebny (cel i obszar)

PbD gwarantuje, że prywatność jest domyślnie wbudowana w produkt, a nie „wklejana” na górze. W przypadku iGaming zmniejsza ryzyko regulacyjne (RODO/ePrywatność/prawa lokalne), chroni podatnych na zagrożenia użytkowników, zwiększa zaufanie i zmniejsza koszty incydentów. Zasięg: web/mobile, KYC/AML/RG, płatności, marketing/CRM, analytics/DWH, logs/AWP, partners/vendors.

2) Siedem zasad (i jak wyładować je w operacjach)

1. Proaktywność, niereaktywność

Modelowanie zagrożeń (LINDDUN/STRIDE) na etapie odkrywania.
Kryteria akceptacji prywatności w szablonach Jira/PR.

2. Domyślna prywatność

Wszystkie przełączniki marketingowe/personalizacyjne są wyłączone, dopóki nie dojdzie do porozumienia.
Zbierz tylko „ściśle niezbędne” identyfikatory domyślne.

3. Prywatność jest wbudowana w projekt

PII jest przechowywany w obwodzie regionalnym (rezydencja danych), płaszczyźnie sterowania - bez PII.
Tokenizacja/aliasing kluczy w wydarzeniach serwisowych.

4. Pełna funkcjonalność (win-win)

Tryby „anonimowej analizy” i „personalizacji za zgodą”.
Równe UX bez dyskryminacji tych, którzy odmówili śledzenia.

5. Bezpieczeństwo przez cykl życia

Szyfrowanie podczas odpoczynku/tranzytu; BYOK/HYOK; segmentacja sieci; tajne zarządzanie.
Dzienniki WORM do dowodu i audytu.

6. Przejrzystość

Krótka polityka i „streszczenie” kluczowych warunków; panel prywatności w profilu.
Zgłaszanie: kto/co/kiedy/dlaczego uzyskał dostęp do danych.

7. Orientacja użytkownika

Proste teksty, brak ciemnych wzorów, dostępność WCAG AA +.
Łatwe wycofanie zgody i wygodne kanały DSAR.

3) Role i RACI

DPO/Head of Compliance - polityka PbD, DPIA/TRA, kontrola ryzyka. A)

Bezpieczeństwo/Infra Lead - kryptografia, dostęp, dzienniki, sprzedawcy. (R)

Produkt/UX - wymagania dotyczące prywatności w funkcjach, brak ciemnych wzorów. (R)

Inżynieria/Architektura - tokenizacja, najemca/izolacja regionalna, umowy API. (R)

Dane/Analityka - rurociągi de-PII, PET, agregacja. (R)

Podstawy prawne, teksty i lokalizacje. (C)

Marketing/CRM - zgoda/tłumienie, uczciwe komunikaty. (R)

Audyt wewnętrzny - próbki artefaktu, CAPA. (C)

4) Klasyfikacja i taksonomia danych

PII basic: pełna nazwa, e-mail, telefon, adres, data urodzenia, IP/ID urządzenia.
Wrażliwe PII: biometria (selfie/żywotność), dokumenty KYC, szczegóły płatności, statusy RG/SE.
Pokoje operacyjne: wydarzenia gry, dzienniki/trasy (domyślnie wolne od PII).
Marketing/Analityka: Pliki cookie/SDK (za zgodą).

Zasady: minimalizacja, oddzielne przechowywanie, wyraźny cel i trwałość.

5) Cykl życia danych

1. Zbieranie - tylko wymagane pola; CIW/zgoda; kontrole wieku.
2. Transmisja - TLS 1. 2 +/mTLS, podpis haka, routing regionalny.
3. Przechowywanie - szyfrowanie, tokenizacja, rotacja klucza, izolacja rynku.
4. Zastosowanie - RBAC/ABAC, need-to-know, PET dla analityki.
5. Wymiana - DPA/SCC, minimalne zestawy, skontrolowane kanały.
6. Zatrzymanie/usunięcie - określenie według kategorii; Kaskada usuwa zadania krypto usuwania archiwów.
7. Sprawozdawczość/audyt - dzienniki dostępu i eksportu, artefakty DPIA/DSAR.

6) DPIA/TRA (jak to zrobić krótko)

Wyzwalacze: nowe kategorie PII, kategorie specjalne, nowi dostawcy, transmisje transgraniczne, wysokie ryzyko związane z RG/biometrią.
Szablon DPIA: cel → kategoria danych → podstawa prawna → przepływy/mapa → ryzyka → środki (tech/org) → ryzyko rezydualne → decyzja.
Artefakty: schemat przepływu, lista pól, tabela ryzyka, protokół zatwierdzenia.

7) Wzory architektoniczne PbD

Lokator/izolacja regionalna: fizyczna/logiczna segregacja baz danych, kluczy i tajemnic.
Control vs Data Plane: global control - no PII; PII tylko lokalnie.
De-PII Pipeline: przed eksportem do DWH - hash/sól, okrawanie, k-anonimowość/kohortacja.
Tokenizacja Gateway: żetony zamiast podstawowych identyfikatorów w autobusie serwisowym.
Krawędź bez PII: pamięć podręczna CDN/edge - tylko zawartość publiczna.
Fail-Closed: Nieznane 'player _ region' → Operacje PII nie są dozwolone.

8) Środki i normy techniczne

Szyfrowanie: AES-256/GCM w spoczynku; TLS 1. 2+/1. 3; PFS.
Klucze: KMS, BYOK/HYOK, rotacja, dostęp przez role HSM, dziennik kluczowych operacji.
Dostęp: RBAC/ABAC, dostęp JIT, oddzielne role administratora i audytu.
Dzienniki: immutable (WORM), łańcuchy hash, przechowywanie w regionie.
DevSecOps: sekrety w skarbcu, SAST/DAST, linter PII, testy prywatności w CI.
Dane testowe: domyślna syntetyka; jeżeli ponowne dane są wyrejestrowane i krótkotrwałe.

9) Technologie zwiększające prywatność (PET)

Aliasing: zastąpienie identyfikatora tokenami; mapa klucza jest przechowywana oddzielnie.
Anonimizacja: kruszywa, k- anonimnost/α -dywersyfikacja, bining/kohorty.
Prywatność różnicowa: hałas na raporty, „budżet prywatności”.
Sfederowana analiza: modele lokalne, tylko wagi/agregaty eksportowe.
Maskowanie/edycja: usunąć EXIF, pola szlifowania w dokumentach KYC.

10) UX bez ciemnych wzorów

Równa widoczność „Odrzuć wszystkie „/” Zaakceptuj wszystkie „/” Dostosuj „.
Jasne teksty docelowe i przykłady wykorzystania danych.
Nie personalizacja nie upośledza podstawowych doświadczeń.
Panel prywatności w 1-2 kliknięcia z każdego miejsca; AA + dostępność.

11) Sprzedawcy i przekazywanie danych

Rejestr dostawcy: jurysdykcja DC, podwykonawcy, certyfikacja, regiony magazynowania, DPA/SCC/IDTA.
Polityka „minimum set”: tylko wymagane pola, bez bezpłatnego eksportu.
Powiadomienie i rewizja przy zmianie lokalizacji/sub-procesorów.

12) Dane i zdarzenia (minimalny model)


data_asset{id, category{KYC    PCI    RG    CRM    LOG    ANON}, region, owner, retention_days, lawful_basis, pii{yes/no}}
processing_event{id, actor, purpose, lawful_basis, started_at, ended_at, records_count, export{yes/no, basis_id}}
access_log{id, subject_id_hash, actor, action{read/write/export/delete}, ts_utc, reason, ticket_id}
erasure_job{id, subject_id_hash, scope, started_at, completed_at, evidence_id}

13) KPI/KRI i deska rozdzielcza PbD

Indeks minimalizacji PII (średnia liczba pól PII na funkcję).
Zasięg rezydencji (% rekordów we właściwym regionie).
Wskaźnik uzasadnienia wywozu.
DSAR SLA (mediana wydajności/dokładności).
Tag Łamanie ognia.
Wynik audytu (% przypadków z pełnym pakietem artefaktów).
Incydenty/ustalenia.

14) Listy kontrolne

A. Przed projektowaniem

  • Cele i podstawy prawne przetwarzania są określone.
  • Mapa danych i lista pól oznaczone PII/wrażliwe.
  • DPIA/TRA wykonane; przyjmuje się ryzyko rezydualne.
  • Rozważany jest „tryb anonimowy” lub tryb z minimalną ilością danych.

B. Budowanie/uwalnianie

  • Sekrety w menedżerze, klawisze/szyfrowanie skonfigurowane.
  • Dzienniki bez PII; włączone są wydarzenia i audyt.
  • Aktywna jest regionalna polityka w zakresie tras i zatrzymywania.
  • Testy: bramki zgody, odmowa domyślnie dla tagów, ścieżka usunięcia.

C. W operacjach

  • Kwartalne przeglądy dostępu i wywozu.
  • Monitorowanie naruszeń prawa pożarniczego i wniosków transgranicznych.
  • DSAR/usunięcia są przeprowadzane na czas; artefakty są zachowane.

15) Szablony (szybkie wkładki)

A) Szablon DPIA (krótki)

💡 Cel: ____
Kategorie danych: ____ (PII: tak/nie)
Powód: ____
Strumienie/Lokalizacje: ____
Ryzyko/wpływ: ____
Środki: te (szyfrowanie/żetony/izolacja), org (RBAC/szkolenie)
Ryzyko rezydualne: Decyzja ____: zatwierdzenie/recykling

B) Polityka minimalizacji pól

💡 Ważne pola dla {funkcja} są [...]. Każde nowe pole wymaga aktualizacji DPIA i przeglądu prawnego.

C) Klauzula z dostawcą (zobowiązanie PbD)

💡 Dostawca wdraża Privacy by Design/Domyślnie, przechowuje dane w {region}, wykorzystuje szyfrowanie w czasie odpoczynku/tranzytu, udostępnia dzienniki dostępu, powiadamia o zmianie sub-procesorów i lokalizacji ≥ 30 dni.

D) Odpowiedź DSAR (prędkość migawki)

💡 Przekazaliśmy informacje o Państwa danych, celach przetwarzania i źródłach. Usunięcie jest kaskadowe; potwierdzenie jest załączone (dowód #...).

16) Częste błędy i jak ich uniknąć

Kolekcja "na wszelki wypadek. "→ Polityka minimalizacji + przegląd kodu systemów.
Surowe dzienniki z PII w APM. → Maskowanie/edycja na agencie, lokalne magazyny.
Globalny DWH z PII. → Tylko kruszywa De-PII/pseudonimy.
Brak artefaktów DPIA/zgody. → Repozytorium WORM, automatyczne migawki interfejsu użytkownika/tekstów.
Nieznani sprzedawcy/SDK. → Kwartalny rejestr, zakaz „szary” połączeń.

17) 30-dniowy plan realizacji

Tydzień 1

1. Zatwierdzanie zasad PbD i szablonów DPIA/TRA.
2. Zbuduj mapę danych/strumieni według stref kluczowych (KYC/PCI/RG/CRM/Logs).
3. podkreślenie obwodów regionalnych (UE/UK/...); Zdefiniuj kluczowy model (BYOK/HYOK).

Tydzień 2

4) Włączyć rurociągi tokenizacyjne/de-PII i domyślnie odmówić dla tagów.
5) Konfiguracja dzienników WORM (dostęp/eksport/zgoda/usunięcie).
6) Aktualizacja umów z dostawcami (DPA/SCC, lokalizacje, podwykonawcy).

Tydzień 3

7) Wdrożenie testów prywatności w CI (linter PII, mocowanie ekranu CMP, erasure-E2E).
8) Zwolnienie panelu ochrony prywatności w profilu; poprawić teksty i lokalizacje.
9) Zespoły pociągów (Product/Eng/Data/CS/Legal).

Tydzień 4

10) Przeprowadzić przegląd DPIA najwyższej funkcji, zamknąć CAPA.
11) Uruchom deskę rozdzielczą KPI/KRI (Residency, Export, DSAR SLA).
12) Plan v1. 1: diff. prywatność dla raportów, federowane rurociągi.

18) Sekcje wzajemnie powiązane

RODO: Zarządzanie zgodą użytkownika/Pliki cookie i polityka CMP

Lokalizacja danych według jurysdykcji

Weryfikacja wieku i filtry wiekowe

AML/KYC i składowanie artefaktów

Zgodność Tablica rozdzielcza i sprawozdania z monitorowania/regulacji

Listy kontrolne audytu wewnętrznego/zewnętrznego i audytu

Szyfrowanie BCP/DRP/Rest & In Transit

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Telegram
@Gamble_GC
Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.