GDPR fejlesztőknek | Amit ténylegesen implementálnia kell

A GDPR 2018 óta hatályban van, de a legtöbb fejlesztői útmutató még mindig a jogi elméletre összpontosít. Ez az útmutató más. A technikai követelményeket, a megírandó kódot és az építészeti döntéseket tárgyalja, amelyek a megfelelőséget gyakorlativá teszik a fájdalmas helyett.

Ha az Ön szoftvere tárolja, feldolgozza vagy érinti az EU-ban élő személyek személyes adatait, ez Önre vonatkozik. Nem számít, hol van a vállalata székhelye.

GDPR áttekintés fejlesztőknek

Hagyja ki a 99 cikkelyt. Íme, mit jelent a GDPR a kódbázisa számára:

1. Csak azt gyűjtse, amire szüksége van. Ne tároljon adatokat „csak a biztonság kedvéért”.
2. Tájékoztassa a felhasználókat, mit csinál az adataikkal. És kérjen engedélyt, amikor szükséges.
3. Hagyja, hogy a felhasználók hozzáférjenek, exportálják és töröljék az adataikat. Ehhez API végpontokra van szüksége.
4. Tartsa biztonságban az adatokat. Titkosítás, hozzáférés-szabályozás, audit naplók.
5. Gyorsan jelentse a biztonsági incidenseket. 72 órája van értesíteni a hatóságokat a biztonsági incidens felfedezése után.
6. Dokumentáljon mindent. A feldolgozási tevékenységeit, a biztonsági intézkedéseit, az adatfolyamatait.

Ez a gyakorlati összefoglaló. Az útmutató hátralévő része bemutatja, hogyan implementálja az egyes követelményeket.

A 7 kulcsfontosságú technikai követelmény

1. Hozzájárulás-kezelés

A hozzájárulásnak szabadon adottnak, konkrétnak, tájékozottnak és egyértelműnek kell lennie. Az előre bejelölt jelölőnégyzetek nem számítanak. A csomagolt hozzájárulás („mindennel egyetértek”) nem számít. A visszavonásnak olyan egyszerűnek kell lennie, mint a megadásnak.

Mit kell építenie

Egy hozzájárulási rendszernek három komponensre van szüksége:

• Hozzájárulási rekord tár. Minden felhasználóhoz nyomon követi, mihez járult hozzá, mikor és hogyan.
• Hozzájárulás-ellenőrző mechanizmus. Mielőtt adatokat dolgozna fel egy adott célra, ellenőrizze, hogy a felhasználó rendelkezik-e aktív hozzájárulással.
• Visszavonási mechanizmus. Hagyja, hogy a felhasználók visszavonják a hozzájárulásukat a felhasználói felületen, és azonnal állítsa le a feldolgozást.

Adatbázis séma

CREATE TABLE user_consents (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id),
  consent_type VARCHAR(100) NOT NULL,
  granted BOOLEAN NOT NULL,
  granted_at TIMESTAMPTZ,
  revoked_at TIMESTAMPTZ,
  ip_address INET,
  user_agent TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_user_consents_lookup
  ON user_consents (user_id, consent_type, granted);

Tárolja a teljes előzményt. Soha ne törölje vagy írja felül a hozzájárulási rekordokat. Amikor egy felhasználó visszavonja a hozzájárulását, szúrjon be egy új sort granted = false értékkel és állítsa be a revoked_at mezőt. Ez audit nyomvonalat ad.

Hozzájárulás-ellenőrző middleware

Íme egy Express middleware, amely ellenőrzi a hozzájárulást egy kérés feldolgozása előtt:

import { Request, Response, NextFunction } from "express";
import { db } from "./database";

interface ConsentRequirement {
  type: string;
  required: boolean;
}

function requireConsent(consentType: string) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const userId = req.user?.id;

    if (!userId) {
      return res.status(401).json({ error: "Authentication required" });
    }

    const consent = await db.query(
      `SELECT granted FROM user_consents
       WHERE user_id = $1 AND consent_type = $2
       ORDER BY created_at DESC
       LIMIT 1`,
      [userId, consentType]
    );

    if (!consent.rows[0]?.granted) {
      return res.status(403).json({
        error: "Consent required",
        consentType,
        message: `You must grant "${consentType}" consent to use this feature.`,
        consentUrl: `/settings/privacy`,
      });
    }

    next();
  };
}

// Usage
app.post(
  "/api/newsletter/subscribe",
  requireConsent("marketing_emails"),
  subscribeHandler
);

app.post(
  "/api/analytics/track",
  requireConsent("usage_analytics"),
  trackHandler
);

2. Adathozzáférés és export (hozzáférési jog)

A felhasználóknak joguk van másolatot kérni az összes személyes adatukról, amelyeket Ön tárol róluk. Általánosan használt, géppel olvasható formátumban kell biztosítania. A JSON vagy CSV megfelel.

Mit kell építenie

Egy végpontot, amely összegyűjti az adott felhasználó összes személyes adatát minden táblából és szolgáltatásból, majd letölthető fájlba csomagolja.

interface DataExport {
  exportedAt: string;
  user: {
    profile: Record<string, unknown>;
    activity: Record<string, unknown>[];
    consents: Record<string, unknown>[];
    communications: Record<string, unknown>[];
  };
}

app.get("/api/me/data-export", authenticate, async (req, res) => {
  const userId = req.user.id;

  const [profile, activity, consents, communications] = await Promise.all([
    db.query("SELECT id, email, name, created_at FROM users WHERE id = $1", [
      userId,
    ]),
    db.query(
      "SELECT action, metadata, created_at FROM user_activity WHERE user_id = $1 ORDER BY created_at DESC",
      [userId]
    ),
    db.query(
      "SELECT consent_type, granted, granted_at, revoked_at FROM user_consents WHERE user_id = $1 ORDER BY created_at DESC",
      [userId]
    ),
    db.query(
      "SELECT type, sent_at, subject FROM communications WHERE user_id = $1 ORDER BY sent_at DESC",
      [userId]
    ),
  ]);

  const exportData: DataExport = {
    exportedAt: new Date().toISOString(),
    user: {
      profile: profile.rows[0],
      activity: activity.rows,
      consents: consents.rows,
      communications: communications.rows,
    },
  };

  res.setHeader("Content-Type", "application/json");
  res.setHeader(
    "Content-Disposition",
    `attachment; filename="data-export-${userId}.json"`
  );
  res.json(exportData);
});

Ennek a végpontnak le kell fednie minden felhasználói adatot tartalmazó táblát. Alaposan auditálja a sémáját. Egy hiányzó tábla hiányos exportot jelent, ami megfelelőségi hiba.

3. Törléshez való jog (az elfeledtetéshez való jog)

A felhasználók kérhetik, hogy törölje az összes személyes adatukat. Meg kell felelnie, hacsak nem áll fenn jogi kötelezettsége az adatok megőrzésére (például adónyilvántartások vagy csalás megelőzése).

Mit kell építenie

Egy törlési végpontot, amely eltávolítja vagy anonimizálja a felhasználói adatokat az összes táblában. Ez nehezebb, mint amilyennek hangzik, az idegen kulcs megszorítások és a más rendszerek által függő adatok miatt.

app.delete("/api/me/account", authenticate, async (req, res) => {
  const userId = req.user.id;
  const client = await db.getClient();

  try {
    await client.query("BEGIN");

    // Üzleti nyilvántartásokhoz megőrizendő adatok anonimizálása
    await client.query(
      `UPDATE orders
       SET customer_name = 'deleted', customer_email = 'deleted'
       WHERE user_id = $1`,
      [userId]
    );

    // Teljes mértékben eltávolítható adatok törlése
    await client.query("DELETE FROM user_activity WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM user_consents WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM communications WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM sessions WHERE user_id = $1", [userId]);

    // A felhasználói rekord anonimizálása törlés helyett
    // Ez megőrzi a referenciális integritást
    await client.query(
      `UPDATE users SET
        email = 'deleted-' || id || '@removed.invalid',
        name = 'Deleted User',
        phone = NULL,
        address = NULL,
        deleted_at = NOW()
       WHERE id = $1`,
      [userId]
    );

    await client.query("COMMIT");

    // Törlés kiváltása külső rendszerekben
    await Promise.allSettled([
      emailService.deleteSubscriber(userId),
      analyticsService.deleteUser(userId),
      searchIndex.removeUser(userId),
    ]);

    res.json({ message: "Account and personal data deleted" });
  } catch (error) {
    await client.query("ROLLBACK");
    throw error;
  } finally {
    client.release();
  }
});

Kulcsfontosságú döntések:

• Törlés vs. anonimizálás. A könyveléshez szükséges rekordokat (rendelések, számlák) anonimizálni kell. Minden mást töröljön.
• Külső rendszerek. A harmadik fél szolgáltatásoknak küldött adatokat ott is törölni kell.
• Időzítés. A GDPR „indokolatlan késedelem nélkül” mondja. Végezze el a törlést 30 napon belül. A legtöbb rendszernél tegye azonnalira.

4. Adatminimalizálás

Csak azt az adatot gyűjtse és tárolja, amelyre ténylegesen szüksége van egy meghatározott célra. Ha telefonszámot kér, de soha nem hívja a felhasználókat, nem kellene gyűjtenie.

Gyakorlati szabályok

• Auditáljon minden űrlapmezőt. Minden mezőnél kérdezze meg: „Melyik konkrét funkció romlik el, ha eltávolítjuk ezt?” Ha a válasz semmi, távolítsa el.
• Állítson be megőrzési időszakokat. Ne tartsa meg az adatokat örökké. Határozza meg, mennyi ideig van szükség az egyes adattípusokra, majd automatikusan törölje.
• Minimalizálja a naplózást. Távolítsa el a személyes adatokat a naplóbejegyzésekből. Felhasználói azonosítókat naplózzon, ne neveket vagy e-mail címeket.

-- Automatikus adatmegőrzés PostgreSQL-lel
-- Futtatás ütemezett feladatként (pl. pg_cron)
DELETE FROM user_activity
WHERE created_at < NOW() - INTERVAL '2 years';

DELETE FROM session_logs
WHERE created_at < NOW() - INTERVAL '90 days';

DELETE FROM password_reset_tokens
WHERE created_at < NOW() - INTERVAL '24 hours';

5. Titkosítás

A GDPR „megfelelő technikai intézkedéseket” ír elő a személyes adatok védelmére. A titkosítás a legfontosabb.

Nyugalmi állapotban

• Titkosítsa az adatbázis lemezét. Minden nagyobb felhőszolgáltató támogatja ezt. Engedélyezze és ellenőrizze.
• Rendkívül érzékeny mezőkhöz (TAJ-szám, egészségügyi adatok) adjon hozzá alkalmazásszintű titkosítást is.
• Titkosítsa a biztonsági mentéseket. A titkosítatlan biztonsági mentés egy bekövetkező incidens.

Átvitel közben

• TLS mindenhol. Minden szolgáltatások, adatbázisok és felhasználók közötti kapcsolatnál. Nincs kivétel.
• Kényszerítse a HTTPS-t. Irányítsa át a HTTP-t. Állítson be HSTS fejléceket.
• Használjon TLS-t az adatbázis-kapcsolatokhoz. A PostgreSQL natívan támogatja ezt.

// PostgreSQL kapcsolat TLS-sel
import { Pool } from "pg";

const pool = new Pool({
  host: process.env.DB_HOST,
  port: 5432,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  ssl: {
    rejectUnauthorized: true,
    ca: fs.readFileSync("/path/to/server-ca.pem").toString(),
  },
});

6. Biztonsági incidens bejelentés

Ha személyes adatok kompromittálódnak, 72 órán belül értesítenie kell az illetékes adatvédelmi hatóságot. Ha a biztonsági incidens magas kockázatot jelent az érintettekre, az érintett felhasználókat is értesítenie kell.

Mit kell építenie

• Audit naplózás. Kövesse nyomon a személyes adatokhoz való minden hozzáférést. Ki fért hozzá, mikor és honnan.
• Anomália-észlelés. Riasztás szokatlan hozzáférési mintáknál (tömeges adatexportok, hozzáférés új IP-kről, munkaidőn kívüli hozzáférés).
• Incidenskezelési terv. Dokumentálja, ki mit csinál, amikor biztonsági incidenst észlelnek. Ez nem kód. Ez egy ellenőrzőlista, amelyet a csapata gyakorol.

CREATE TABLE data_access_log (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL,
  accessed_by UUID NOT NULL,
  access_type VARCHAR(50) NOT NULL,
  resource_type VARCHAR(100) NOT NULL,
  resource_id UUID,
  ip_address INET,
  user_agent TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_data_access_log_user
  ON data_access_log (user_id, created_at);

CREATE INDEX idx_data_access_log_accessor
  ON data_access_log (accessed_by, created_at);

7. Beépített adatvédelem

A GDPR kimondja, hogy az adatvédelmet a rendszerekbe a kezdetektől kell beépíteni, nem utólag rácsavarozni. A gyakorlatban ez azt jelenti, hogy az adatvédelem legyen az alapértelmezés.

• Alapértelmezetten privát. Az új funkcióknak minimális adatot kell gyűjteniük, és az alapfunkción túli bármihez opt-in-t igényelniük.
• A beállítások alapértelmezetten a legprivátabb opcióra. Azoknak a felhasználóknak, akik soha nem nyúlnak a beállításaikhoz, a legmagasabb adatvédelmi szintet kell élvezniük.
• Szétválasztott felelősségek. Ne keverje az analitikai adatokat a funkcionális adatokkal. Ne használja újra az auth tokeneket követésre.

Anonimizálás vs. pszeudonimizálás

Ezek nem ugyanazok, és a különbség számít.

• Pszeudonimizálás az azonosító információt visszafordítható tokennel helyettesíti. Példa: e-mail címek hash-elése. Ha rendelkezik a hash függvénnyel és az eredeti e-maillel, újra azonosíthatja a személyt. A GDPR továbbra is vonatkozik rá, mert az újra-azonosítás lehetséges.
• Anonimizálás véglegesen eltávolítja az azonosító információt. Példa: összesített analitika („1 247 felhasználó látogatta meg az árazás oldalt”) anélkül, hogy azonosítható lenne, melyik felhasználók. A GDPR nem vonatkozik a valóban anonimizált adatokra.

A valódi anonimizálás nehéz. Ha az „anonim” adatkészlete tartalmaz időbélyeget, várost és eszköztípust, ez a kombináció egyedileg azonosíthat valakit. Legyen konzervatív.

Cookie hozzájárulás

Ha a weboldala a feltétlenül szükségesnél több cookie-t használ, hozzájárulásra van szüksége a beállításuk előtt.

Hozzájárulást igényel: analitikai cookie-k, hirdetési pixelek, közösségi média widgetek, bármilyen harmadik féltől származó követő script.

Nem igényel hozzájárulást: munkamenet cookie-k, bevásárlókosár cookie-k, CSRF tokenek, maga a cookie hozzájárulási preferencia cookie.

A hozzájárulási bannernek blokkolnia kell a nem alapvető cookie-kat a hozzájárulás megadásáig, részletes választásokat kell kínálnia, és az „összes elutasítása” ugyanolyan egyszerűnek kell lennie, mint az „összes elfogadása”. Ne építse ezt nulláról. Az olyan eszközök, mint a Cookiebot kezelik a komplexitást. Az alapszabály: egyetlen követő script sem fut a hozzájárulás megadása előtt.

Harmadik féltől származó adatfeldolgozók

Minden harmadik fél szolgáltatás, amely a felhasználóinak adatait kezeli, „adatfeldolgozó” a GDPR értelmében. Ön felelős az ő megfelelőségükért.

Mit kell ellenőriznie

Mielőtt bármilyen harmadik fél szolgáltatást integrálna, amely személyes adatokat kezel:

1. Van DPA-juk? Az adatfeldolgozási megállapodás kötelező. A legtöbb SaaS szolgáltató nyilvánosan közzéteszi.
2. Hol tárolják az adatokat? Ha az EU-n kívül, ellenőrizze az átvitel jogalapját.
3. Milyen adatokhoz férnek hozzá? Minimalizálja, amit küld. Ha a szolgáltatásnak csak e-mailre van szüksége, ne küldje el a teljes profilt.
4. Tudja törölni az adatokat a rendszereikből? A felhasználói törlési kéréseknek mindenhová el kell jutniuk.
5. Hogyan kezelik a biztonsági incidenseket? A DPA-juknak meg kell határoznia az értesítési időkereteket.

Gyakori áttekintendő harmadik fél feldolgozók

• E-mail szolgáltatások (Resend, SendGrid, Mailchimp)
• Analitika (Google Analytics, Mixpanel, Amplitude)
• Hibakövetés (Sentry, Bugsnag)
• Fizetésfeldolgozás (Stripe, Adyen)
• Felhő hosting (AWS, Google Cloud, Vercel)
• Ügyfélszolgálati eszközök (Intercom, Zendesk)
• AI API-k (OpenAI, Anthropic, Google AI)

Tartson fenn listát az összes feldolgozóról. Negyedévente tekintse át.

Adatmegőrzési irányelvek

Ne tartsa meg a személyes adatokat a szükségesnél tovább. Határozzon meg megőrzési időszakokat minden adattípushoz.

Adattípus	Ajánlott megőrzés	Ok
Felhasználói fiókadatok	Törlés kéréséig	A szolgáltatáshoz szükséges
Munkamenet naplók	90 nap	Biztonság és hibakeresés
Felhasználói tevékenység naplók	1-2 év	Termék analitika
Support jegyek	3 év	Szolgáltatás minősége
Pénzügyi nyilvántartások	7 év	Adó/jogi kötelezettségek
Jelszó-visszaállítási tokenek	24 óra	Biztonság
Sikertelen bejelentkezési kísérletek	90 nap	Biztonsági monitorozás

Implementáljon automatizált tisztítási feladatokat. Ne hagyatkozzon arra, hogy valaki emlékszik futtatni egy scriptet.

GDPR ellenőrzőlista fejlesztőknek

Használja ezt kiindulópontként egy rendszer felépítésekor vagy auditálásakor.

Adatgyűjtés

• Minden űrlapmezőnek van meghatározott célja
• Nem gyűjt szükségtelen adatokat
• Az adatvédelmi irányelv minden adatgyűjtési pontról elérhető
• A hozzájárulást a feldolgozás előtt begyűjti (ahol szükséges)
• A hozzájárulási rekordok időbélyeggel vannak tárolva

Adattárolás

• Az adatbázis nyugalmi titkosítása engedélyezve van
• A TLS minden kapcsolathoz kényszerítve van
• Az érzékeny mezőknél alkalmazásszintű titkosítás van
• A biztonsági mentések titkosítva vannak
• A produkciós adatokhoz való hozzáférés korlátozott és naplózott

Felhasználói jogok

• Az adatexport végpont létezik és lefedi az összes táblát
• A fióktörlési végpont létezik és kezeli az összes adatot
• A felhasználók megtekinthetik és visszavonhatják a hozzájárulást a beállításaikban
• A törlés eljut a harmadik fél szolgáltatásokhoz
• Minden felhasználói jogi kérésre 30 napon belül válaszolnak

Cookie-k és követés

• A cookie hozzájárulási banner implementálva van
• A nem alapvető cookie-k blokkolva vannak a hozzájárulás előtt
• A hozzájárulási választások részletesek (nem mindent-vagy-semmit)
• Az „összes elutasítása” ugyanolyan hangsúlyos, mint az „összes elfogadása”

Harmadik felek

• Az összes adatfeldolgozó dokumentálva van
• Minden feldolgozóval DPA van aláírva
• A harmadik feleknek küldött adatok minimalizálva vannak
• A harmadik felektől való adattörlés lehetséges

Biztonság

• Az audit naplók nyomon követik a személyes adatokhoz való hozzáférést
• Az anomália riasztás konfigurálva van
• Az incidenskezelési terv dokumentálva van
• A biztonsági incidens bejelentési folyamat meghatározott (72 órás határidő)

Megőrzés

• A megőrzési időszakok meg vannak határozva minden adattípushoz
• Az automatizált tisztítási feladatok ütemezve vannak
• A lejárt adatok ténylegesen törlődnek (ellenőrizze)

Záró gondolatok

A GDPR-megfelelőség nem egyszeri projekt. Gyakorlatok halmaza, amelyek beépülnek abba, ahogyan szoftvert épít. A technikai munka egyértelmű: hozzájárulás tárolás, adatexport, törlési végpontok, titkosítás, audit naplózás. Standard mérnöki munka.

A nehéz rész az alaposság. Könnyű megfeledkezni arról a naplófájlról, arról az analitikai eseményről, vagy arról a harmadik fél integrációról, amely felhasználói e-maileket tárol. Rendszeresen auditáljon. Tesztelje a törlési végpontját. Ellenőrizze, hogy az exportjai teljesek. Építse be az adatvédelmet a folyamataiba a kezdetektől.

---

Segítségre van szüksége GDPR-megfelelő szoftver felépítéséhez vagy meglévő rendszerei auditálásához? Lépjen kapcsolatba velünk. Adatvédelem-központú alkalmazásokat építünk európai vállalkozásoknak és EU felhasználókat kiszolgáló vállalatoknak.