RODO i inżynieria prywatności

RODO (Rozporządzenie 2016/679) nie jest listą życzeń prawników, tylko zbiorem twardych ograniczeń, które muszą znaleźć odzwierciedlenie w schemacie bazy, kontrakcie API i architekturze systemu. Sześć zasad art. 5 ust. 1 to fundament, na którym stoi cała reszta rozporządzenia.

from pydantic import BaseModel, EmailStr

class SignupRequest(BaseModel):
    """Only fields strictly necessary to create an account.
    Marketing consent is a separate, explicit opt-in field, never inferred."""
    email: EmailStr
    password: str
    marketing_consent: bool = False  # must default to False (privacy by default)

class UserProfile(BaseModel):
    """Internal model can hold more, but API responses use a narrower view."""
    id: str
    email: EmailStr
    created_at: str

class UserProfilePublic(BaseModel):
    """Shape returned to other users - excludes email entirely."""
    id: str
    display_name: str

• DTO/schema na granicy API ujawnia tylko pola niezbędne odbiorcy, nawet jeśli model wewnętrzny ma więcej danych.
• Endpoint zwracający profil publiczny nigdy nie serializuje pola email czy numeru telefonu.
• Formularz frontendowy nie ma pola, którego backend nie potrzebuje, redukcja na wejściu jest tańsza niż redakcja na wyjściu.
• Code review pyta wprost: jaki jest cel tego pola i kto go realnie używa za 3 miesiące?

1. 1 Zdefiniuj cel przed projektowaniem schematu Każde pole w modelu danych ma udokumentowany cel biznesowy i podstawę prawną.
2. 2 Zredukuj zakres na granicy API DTO wejściowe/wyjściowe ograniczają pola do potrzebnych danemu operacji.
3. 3 Przypisz właściciela polu wrażliwemu Kto odpowiada za to pole, kto ma dostęp, kiedy jest usuwane.
4. 4 Zweryfikuj w code review Nowe pole to pytanie o cel, podstawę prawną i okres retencji, nie tylko o typ danych.

Każde przetwarzanie danych osobowych musi opierać się na jednej z sześciu podstaw prawnych z art. 6 ust. 1. Brak wybranej podstawy nie oznacza "przetwarzania na zasadach ogólnych", oznacza przetwarzanie niezgodne z prawem od pierwszej linijki kodu.

from dataclasses import dataclass
from datetime import datetime, timezone

@dataclass(frozen=True)
class ConsentRecord:
    """Immutable proof of consent, kept for accountability (Art. 5(2), Art. 7(1))."""
    user_id: str
    purpose: str                 # e.g. "marketing_email", never a bundled "all purposes"
    policy_version: str          # ties consent to the exact text the user saw
    given_at: datetime
    withdrawn_at: datetime | None = None

    def is_active(self) -> bool:
        return self.withdrawn_at is None

def record_consent(user_id: str, purpose: str, policy_version: str) -> ConsentRecord:
    return ConsentRecord(
        user_id=user_id,
        purpose=purpose,
        policy_version=policy_version,
        given_at=datetime.now(timezone.utc),
    )

1. 1 Sprawdź, czy istnieje przepis nakazujący przetwarzanie (obowiązek prawny) zanim sięgniesz po zgodę.
2. 2 Sprawdź, czy dane są niezbędne do wykonania umowy z tą konkretną osobą.
3. 3 Jeśli żadna z twardych podstaw nie pasuje, rozważ prawnie uzasadniony interes i udokumentuj LIA.
4. 4 Zgodę traktuj jako podstawę ostatniego wyboru dla marketingu, ponieważ jest najłatwiejsza do wycofania i najtrudniejsza do utrzymania w audycie.

Art. 25 przenosi RODO z warstwy polityki do warstwy architektury: uwzględnianie ochrony danych w fazie projektowania i domyślna ochrona danych to wymogi wobec systemu, nie deklaracje w dokumencie.

# Migration: new visibility field defaults to the most restrictive setting.
# Privacy by default (Art. 25(2)): the user must opt IN to public visibility,
# never opt out of it.
from django.db import migrations, models

class Migration(migrations.Migration):
    dependencies = [("profiles", "0012_alter_profile")]
    operations = [
        migrations.AddField(
            model_name="profile",
            name="is_public",
            field=models.BooleanField(default=False),  # private until user chooses otherwise
        ),
    ]

• Modelowanie danych: pole wrażliwe ma domyślną wartość najbardziej restrykcyjną, nie "null" interpretowane jako publiczne.
• Warstwa API: endpoint bez jawnie podanych parametrów zwraca minimalny zestaw danych, rozszerzenie wymaga explicit query param.
• Integracje trzecie: nowy webhook czy SDK analityczny przechodzi przegląd danych, zanim trafi na produkcję, nie po.
• Kontrola dostępu: RBAC/ABAC domyślnie odmawia dostępu (deny by default), uprawnienia nadawane wprost, nigdy przez brak reguły.

1. 1 Data flow diagram Zmapuj przepływ danych nowej funkcji: skąd, dokąd, przez kogo, w tym procesorów trzecich.
2. 2 Przegląd minimalizacji Dla każdego pola: czy jest niezbędne do konkretnego celu tej funkcji?
3. 3 Audyt ustawień domyślnych Każdy nowy przełącznik/widoczność: wartość domyślna to najbardziej restrykcyjna.
4. 4 Screening pod DPIA Sprawdź kryteria WP248 (sekcja 7), zdecyduj czy potrzebna pełna DPIA.

"Usuń moje dane" brzmi jak jedno zapytanie DELETE. W realnym systemie to rozgałęziony problem: baza produkcyjna, indeks wyszukiwania, cache, kolejka zdarzeń, hurtownia danych, logi, backupy i procesorzy trzecy, każdy z innym cyklem życia.

from cryptography.fernet import Fernet

class SubjectKeyStore:
    """One encryption key per data subject. "Erasing" a user means deleting
    their key here, not rewriting every backup that contains their ciphertext."""

    def __init__(self) -> None:
        self._keys: dict[str, bytes] = {}

    def key_for(self, user_id: str) -> bytes:
        if user_id not in self._keys:
            self._keys[user_id] = Fernet.generate_key()
        return self._keys[user_id]

    def erase(self, user_id: str) -> None:
        # Deleting the key here makes every ciphertext copy that exists only as
        # bytes elsewhere (a backup, a log, another process) unreadable forever,
        # since nothing can retrieve this key again. Note: key_for() called again
        # for this user_id after erase() would silently mint a brand-new, unrelated
        # key, that is a separate footgun, not an "undo" of the erasure.
        self._keys.pop(user_id, None)

store = SubjectKeyStore()
cipher = Fernet(store.key_for("user-123"))
encrypted = cipher.encrypt(b"sensitive profile data")
store.erase("user-123")
# cipher already captured its own copy of the key bytes at construction time,
# so cipher.decrypt(encrypted) still succeeds here, erase() does not reach into
# live objects. The real guarantee covers ciphertext sitting as bytes elsewhere
# (backups, logs, other processes) that never had a live Fernet built from this key.

• Baza produkcyjna: DELETE lub anonimizacja rekordu.
• Indeks wyszukiwania (Elasticsearch/OpenSearch): osobne zadanie reindeksujące lub usuwające dokument.
• Cache (Redis/Memcached): TTL rozwiązuje część przypadków, ale klucze bez TTL wymagają jawnego czyszczenia.
• Kolejki zdarzeń (Kafka): retencja tematu ograniczona czasowo, event z PII nie powinien żyć w logu zdarzeń w nieskończoność.
• Hurtownia danych/BI: pipeline ETL musi honorować to samo żądanie usunięcia, nie tylko system źródłowy.
• Modele ML: dane treningowe zawierające PII konkretnej osoby to osobny, trudniejszy problem, nie zawsze da się wymazać wpływ na wagi modelu.
• Procesorzy trzecy: administrator musi powiadomić każdego odbiorcę, któremu dane ujawniono, chyba że jest to niemożliwe lub wymaga niewspółmiernie dużego wysiłku (art. 19).

1. 1 Weryfikacja tożsamości żądającego Nie usuwaj danych na podstawie samego emaila bez potwierdzenia, że żąda właściwa osoba.
2. 2 Lokalizacja danych przez ROPA Rejestr czynności przetwarzania (art. 30) wskazuje, gdzie dana kategoria danych w ogóle żyje.
3. 3 Kaskada do procesorów Powiadomienie procesorów zgodnie z umową powierzenia, art. 28 ust. 3 lit. g: obowiązek usunięcia/zwrotu danych po zakończeniu usługi.
4. 4 Log samego usunięcia Fakt i czas wykonania żądania trzeba udokumentować, to dowód rozliczalności, nawet po zniknięciu danych źródłowych.
5. 5 Odpowiedź w terminie Co do zasady miesiąc od żądania (art. 12 ust. 3), przedłużalne o kolejne dwa miesiące przy złożonych lub licznych żądaniach, z uzasadnieniem.

DPIA (Data Protection Impact Assessment, ocena skutków dla ochrony danych) to formalny proces wymagany art. 35 RODO, gdy planowane przetwarzanie może powodować wysokie ryzyko dla praw i wolności osób. Dla inżyniera to bramka w procesie projektowania nowej funkcji, nie dokument tworzony po fakcie.

1. 1 Ocena/scoring cech osobowych, np. profil kredytowy, ocena wydajności pracownika.
2. 2 Zautomatyzowane podejmowanie decyzji ze skutkiem prawnym (art. 22).
3. 3 Systematyczne monitorowanie, np. monitoring pracowników, śledzenie lokalizacji.
4. 4 Dane szczególnych kategorii lub dane o wyrokach skazujących na dużą skalę.
5. 5 Przetwarzanie na dużą skalę: liczba osób, zakres geograficzny, czas trwania.
6. 6 Łączenie lub porównywanie zbiorów danych z różnych źródeł.
7. 7 Dane osób w sytuacji szczególnej podatności: dzieci, pracownicy, pacjenci.
8. 8 Innowacyjne użycie technologii, np. nowy model biometryczny.
9. 9 Przetwarzanie uniemożliwiające osobie wykonanie prawa lub skorzystanie z usługi/umowy.

"""Simple heuristic CI check: flags new fields that look like special-category
data (Art. 9) so they get a linked DPIA before merging, not after launch."""
import subprocess

SENSITIVE_MARKERS = ("health_", "biometric_", "genetic_", "religion_", "orientation_")

def new_fields_in_diff(base_ref: str = "origin/main") -> list[str]:
    diff = subprocess.run(
        ["git", "diff", base_ref, "--unified=0", "--", "*/models.py"],
        capture_output=True, text=True, check=True,
    ).stdout
    return [line for line in diff.splitlines() if line.startswith("+") and
            any(marker in line for marker in SENSITIVE_MARKERS)]

if new_fields_in_diff():
    raise SystemExit(
        "New special-category field detected: link a DPIA ticket before merging (Art. 35)."
    )

1. 1 Opisz przetwarzanie Cel, zakres danych, kategorie osób, odbiorcy, okres przechowywania.
2. 2 Oceń niezbędność i proporcjonalność Czy cel da się osiągnąć mniejszym zakresem danych lub mniej inwazyjną metodą?
3. 3 Oceń ryzyko dla osób Prawdopodobieństwo i dotkliwość skutków dla praw i wolności, nie tylko ryzyko biznesowe/reputacyjne administratora.
4. 4 Zaplanuj środki zaradcze Techniczne: szyfrowanie, pseudonimizacja, kontrola dostępu; organizacyjne: szkolenia, procedury.
5. 5 Skonsultuj z IOD/DPO Inspektor Ochrony Danych opiniuje DPIA przed wdrożeniem (art. 35 ust. 2).
6. 6 Konsultacja z organem nadzorczym Jeśli po środkach zaradczych ryzyko rezydualne pozostaje wysokie, wymagana uprzednia konsultacja z organem nadzorczym (art. 36).

Dwa różne mechanizmy często mylone w praktyce inżynierskiej: anonimizacja wyprowadza dane spod RODO, pseudonimizacja nie. Ta sama pomyłka pojawia się przy transferach danych poza EOG: "zaszyfrowaliśmy więc jest bezpiecznie" nie jest odpowiedzią na pytanie prawne o podstawę transferu.

import hashlib
import hmac
import os

def naive_pseudonymize(email: str) -> str:
    # WRONG: a plain hash of a low-entropy value (email) is reversible via
    # a rainbow table or simple dictionary attack. Still personal data,
    # and easily re-identifiable by anyone, not just the controller.
    return hashlib.sha256(email.encode()).hexdigest()

SECRET_KEY = os.environ["PSEUDONYMIZATION_KEY"].encode()

def proper_pseudonymize(email: str) -> str:
    # Correct: HMAC with a server-side secret kept separate from the output.
    # Re-identification requires the secret key (Art. 4(5) "additional information
    # kept separately"), which is what makes this pseudonymization, not encryption
    # or anonymization, and why the result is STILL personal data under GDPR.
    return hmac.new(SECRET_KEY, email.encode(), hashlib.sha256).hexdigest()

1. 1 Zmapuj przepływy danych poza EOG Który procesor/subprocesor fizycznie przetwarza dane poza Europejskim Obszarem Gospodarczym?
2. 2 Zweryfikuj mechanizm transferu Adekwatność, SCC czy BCR, i czy dokumentacja jest aktualna.
3. 3 Przeprowadź transfer impact assessment Ocena prawa i praktyki kraju odbiorcy pod kątem dostępu władz publicznych do danych.
4. 4 Wdróż środki dodatkowe, jeśli potrzebne Szyfrowanie z kluczem niedostępnym dla odbiorcy, pseudonimizacja przed transferem, minimalizacja zakresu.