GDPR за софтуерни разработчици | Какво наистина трябва да имплементирате

GDPR е в сила от 2018 г., но повечето ръководства за разработчици все още се фокусират върху правната теория. Това ръководство е различно. Покрива техническите изисквания, кода, който трябва да напишете, и архитектурните решения, които правят съответствието практично вместо болезнено.

Ако вашият софтуер съхранява, обработва или докосва лични данни на хора в ЕС, това се отнася за вас. Няма значение къде е базирана компанията ви.

Преглед на GDPR за разработчици

Пропуснете 99-те члена. Ето какво означава GDPR за вашата кодова база:

1. Събирайте само това, от което се нуждаете. Не съхранявайте данни “за всеки случай”.
2. Кажете на потребителите какво правите с данните им. И вземете разрешението им, когато е необходимо.
3. Позволете на потребителите да получат достъп, да експортират и да изтрият данните си. Нужни са ви API крайни точки за това.
4. Пазете данните в безопасност. Криптиране, контрол на достъпа, одитни логове.
5. Докладвайте пробиви бързо. Имате 72 часа да уведомите властите след откриване на пробив.
6. Документирайте всичко. Вашите обработващи дейности, мерките ви за сигурност, потоците на данни.

Това е практическото резюме. Останалата част от ръководството ви показва как да имплементирате всяко изискване.

7-те ключови технически изисквания

1. Управление на съгласието

Съгласието трябва да бъде свободно дадено, конкретно, информирано и недвусмислено. Предварително отбелязаните полета не се считат. Обединеното съгласие (“съгласете се с всичко”) не се счита. Оттеглянето трябва да бъде толкова лесно, колкото даването на съгласие.

Какво да изградите

Системата за съгласие се нуждае от три компонента:

• Хранилище за записи на съгласие. За всеки потребител проследявайте с какво са се съгласили, кога и как.
• Механизъм за проверка на съгласие. Преди да обработите данни за конкретна цел, проверете дали потребителят има активно съгласие.
• Механизъм за оттегляне. Позволете на потребителите да оттеглят съгласието си чрез вашия интерфейс и спрете обработката незабавно.

Схема на базата данни

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);

Съхранявайте пълната история. Никога не изтривайте и не презаписвайте записи за съгласие. Когато потребител оттегли съгласието си, вмъкнете нов ред с granted = false и задайте revoked_at. Това ви дава одитна пътека.

Middleware за проверка на съгласие

Ето Express middleware, който проверява съгласието преди обработка на заявка:

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. Достъп до данни и експорт (Право на достъп)

Потребителите имат право да поискат копие на всички лични данни, които съхранявате за тях. Трябва да го предоставите в общоупотребяван, машинно четим формат. JSON или CSV работят добре.

Какво да изградите

Крайна точка, която събира всички лични данни за потребител от всяка таблица и услуга, и ги пакетира в файл за изтегляне.

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);
});

Тази крайна точка трябва да покрие всяка таблица, съдържаща потребителски данни. Одитирайте схемата си обстойно. Пропусната таблица означава непълен експорт, което е нарушение на съответствието.

3. Право на изтриване (Право да бъдеш забравен)

Потребителите могат да поискат да изтриете всичките им лични данни. Трябва да се съобразите, освен ако нямате законово задължение да ги запазите (като данъчни записи или предотвратяване на измами).

Какво да изградите

Крайна точка за изтриване, която премахва или анонимизира потребителски данни от всички таблици. Това е по-трудно, отколкото звучи, заради ограниченията на външните ключове и данните, от които зависят други системи.

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

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

    // Anonymize data that must be retained for business records
    await client.query(
      `UPDATE orders
       SET customer_name = 'deleted', customer_email = 'deleted'
       WHERE user_id = $1`,
      [userId]
    );

    // Delete data that can be fully removed
    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]);

    // Anonymize the user record instead of deleting
    // This preserves referential integrity
    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");

    // Trigger deletion in external systems
    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();
  }
});

Ключови решения:

• Изтриване срещу анонимизация. Записи, нужни за счетоводство (поръчки, фактури), трябва да бъдат анонимизирани. Изтрийте всичко останало.
• Външни системи. Данни, изпратени до услуги на трети страни, трябва да бъдат изтрити и там.
• Срокове. GDPR казва “без ненужно забавяне”. Завършете изтриването в рамките на 30 дни. За повечето системи го направете незабавно.

4. Минимизиране на данните

Събирайте и съхранявайте само данните, от които наистина се нуждаете за заявена цел. Ако искате телефонен номер, но никога не се обаждате на потребителите, не трябва да го събирате.

Практически правила

• Одитирайте всяко поле във формуляра. За всяко поле попитайте: “Коя конкретна функция спира да работи, ако премахнем това?” Ако отговорът е “нищо”, премахнете го.
• Задайте периоди на съхранение. Не пазете данни завинаги. Определете колко дълго е необходим всеки тип данни, след което ги изтрийте автоматично.
• Минимизирайте логването. Премахнете личните данни от записите в лога. Логвайте потребителски идентификатори, не имена или имейли.

-- Automatic data retention with PostgreSQL
-- Run this as a scheduled job (e.g., 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. Криптиране

GDPR изисква “подходящи технически мерки” за защита на личните данни. Криптирането е най-важното.

В покой

• Криптирайте диска на базата данни. Всички големи облачни доставчици го поддържат. Активирайте го и проверете.
• За силно чувствителни полета (ЕГН, здравни данни), добавете криптиране на ниво приложение отгоре.
• Криптирайте архивите. Некриптиран архив е пробив, чакащ да се случи.

В транзит

• TLS навсякъде. Всяка връзка между услуги, бази данни и потребители. Без изключения.
• Наложете HTTPS. Пренасочете HTTP. Задайте HSTS заглавки.
• Използвайте TLS за връзки с базата данни. PostgreSQL поддържа това нативно.

// PostgreSQL connection with TLS
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. Уведомление за пробив

Ако лични данни бъдат компрометирани, трябва да уведомите съответния орган за защита на данните в рамките на 72 часа. Ако пробивът представлява висок риск за лицата, трябва да уведомите и засегнатите потребители.

Какво да изградите

• Одитно логване. Проследявайте всеки достъп до лични данни. Кой е имал достъп, кога и откъде.
• Откриване на аномалии. Алармирайте при необичайни модели на достъп (масов експорт на данни, достъп от нови IP адреси, достъп извън работно време).
• План за реагиране при инциденти. Документирайте кой какво прави, когато бъде открит пробив. Това не е код. Това е контролен списък, който екипът ви практикува.

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. Поверителност по дизайн

GDPR казва, че поверителността трябва да бъде вградена в системите от самото начало, а не прикрепена отпосле. На практика това означава поверителността да бъде по подразбиране.

• По подразбиране частно. Новите функции трябва да събират минимални данни и да изискват съгласие за всичко извън основната функция.
• Настройките по подразбиране да бъдат най-поверителната опция. Потребителите, които никога не докосват настройките си, трябва да имат най-висока защита на поверителността.
• Разделяне на отговорностите. Не смесвайте данни за анализи с функционални данни. Не използвайте повторно токени за удостоверяване за проследяване.

Анонимизация срещу псевдонимизация

Това не е едно и също нещо и разликата е важна.

• Псевдонимизация замества идентифициращата информация с обратим токен. Пример: хеширане на имейл адреси. Ако имате хеш функцията и оригиналния имейл, можете да реидентифицирате лицето. GDPR все още се прилага, защото реидентификацията е възможна.
• Анонимизация премахва идентифициращата информация завинаги. Пример: агрегирани анализи (“1 247 потребители посетиха страницата с цени”) без начин да идентифицирате кои потребители. GDPR не се прилага за наистина анонимизирани данни.

Истинската анонимизация е трудна. Ако вашият “анонимен” набор от данни включва времеви печат, град и тип устройство, тази комбинация може уникално да идентифицира някого. Бъдете консервативни.

Съгласие за бисквитки

Ако вашият уебсайт използва бисквитки отвъд строго необходимите, имате нужда от съгласие, преди да ги зададете.

Изисква съгласие: бисквитки за анализи, рекламни пиксели, джаджи за социални медии, всеки скрипт за проследяване от трета страна.

Не изисква съгласие: сесийни бисквитки, бисквитки за количка, CSRF токени, самата бисквитка за предпочитание за съгласие.

Банерът за съгласие трябва да блокира несъществените бисквитки, докато не бъде дадено съгласие, да предлага детайлни избори и да направи “отхвърляне на всички” толкова лесно, колкото “приемане на всички”. Не изграждайте това от нулата. Инструменти като Cookiebot се справят със сложността. Ключовото правило: никакви скриптове за проследяване не се стартират преди да бъде дадено съгласие.

Обработващи данни от трети страни

Всяка услуга от трета страна, обработваща данните на потребителите ви, е “обработващ данни” по GDPR. Вие носите отговорност за тяхното съответствие.

Какво да проверите

Преди да интегрирате услуга от трета страна, която докосва лични данни:

1. Имат ли DPA? Споразумение за обработка на данни е задължително. Повечето SaaS доставчици публикуват своите публично.
2. Къде съхраняват данни? Ако извън ЕС, проверете правната основа за трансфера.
3. До какви данни имат достъп? Минимизирайте това, което изпращате. Ако услугата се нуждае само от имейл, не изпращайте пълния профил.
4. Можете ли да изтриете данни от техните системи? Заявките за изтриване от потребители трябва да се разпространяват навсякъде.
5. Как обработват пробиви? Тяхното DPA трябва да определя срокове за уведомяване.

Чести обработващи данни от трети страни за преглед

• Имейл услуги (Resend, SendGrid, Mailchimp)
• Анализи (Google Analytics, Mixpanel, Amplitude)
• Проследяване на грешки (Sentry, Bugsnag)
• Обработка на плащания (Stripe, Adyen)
• Облачен хостинг (AWS, Google Cloud, Vercel)
• Инструменти за клиентска поддръжка (Intercom, Zendesk)
• AI API-та (OpenAI, Anthropic, Google AI)

Поддържайте списък на всички обработващи. Преглеждайте го на тримесечие.

Политики за съхранение на данни

Не пазете лични данни по-дълго от необходимото. Определете периоди на съхранение за всеки тип данни.

Тип данни	Препоръчително съхранение	Причина
Данни за потребителски акаунт	До поискване на изтриване	Необходими за услугата
Логове на сесии	90 дни	Сигурност и отстраняване на грешки
Логове на потребителска активност	1-2 години	Продуктови анализи
Тикети за поддръжка	3 години	Качество на услугата
Финансови записи	7 години	Данъчни/правни задължения
Токени за нулиране на парола	24 часа	Сигурност
Неуспешни опити за вход	90 дни	Мониторинг на сигурността

Имплементирайте автоматични задачи за почистване. Не разчитайте някой да помни да пусне скрипт.

GDPR контролен списък за разработчици

Използвайте го като отправна точка при изграждане или одит на система.

Събиране на данни

• Всяко поле във формуляр има заявена цел
• Не се събират ненужни данни
• Политиката за поверителност е свързана от всяка точка за събиране на данни
• Съгласието е събрано преди обработката (когато е необходимо)
• Записите за съгласие се съхраняват с времеви печати

Съхранение на данни

• Криптирането на базата данни в покой е активирано
• TLS е наложен за всички връзки
• Чувствителните полета имат криптиране на ниво приложение
• Архивите са криптирани
• Достъпът до продуктивни данни е ограничен и логван

Права на потребителите

• Крайна точка за експорт на данни съществува и покрива всички таблици
• Крайна точка за изтриване на акаунт съществува и обработва всички данни
• Потребителите могат да видят и оттеглят съгласието в настройките си
• Изтриването се разпространява до услугите на трети страни
• На всички заявки за права на потребители се отговаря в рамките на 30 дни

Бисквитки и проследяване

• Банер за съгласие за бисквитки е имплементиран
• Несъществените бисквитки са блокирани преди съгласие
• Изборите за съгласие са детайлни (не всичко или нищо)
• “Отхвърляне на всички” е толкова видимо, колкото “Приемане на всички”

Трети страни

• Всички обработващи данни са документирани
• DPA са подписани с всеки обработващ
• Данните, изпращани на трети страни, са минимизирани
• Изтриването на данни от трети страни е възможно

Сигурност

• Одитните логове проследяват достъпа до лични данни
• Алармирането за аномалии е конфигурирано
• Планът за реагиране при инциденти е документиран
• Процесът за уведомяване при пробив е дефиниран (72-часов краен срок)

Съхранение

• Периодите на съхранение са дефинирани за всички типове данни
• Автоматичните задачи за почистване са планирани
• Изтеклите данни наистина се изтриват (проверете това)

Заключителни мисли

GDPR съответствието не е еднократен проект. Това е набор от практики, вплетени в начина, по който изграждате софтуер. Техническата работа е директна: съхранение на съгласие, експорт на данни, крайни точки за изтриване, криптиране, одитно логване. Стандартно инженерство.

Трудната част е да бъдете обстойни. Лесно е да забравите за този лог файл, за онова събитие за анализи или за интеграцията от трета страна, съхраняваща потребителски имейли. Одитирайте редовно. Тествайте крайната си точка за изтриване. Проверявайте дали експортите ви са пълни. Вградете поверителността в процеса си от самото начало.

---

Нуждаете се от помощ за изграждане на GDPR-съвместим софтуер или одит на съществуващите ви системи? Свържете се с нас. Ние изграждаме приложения с фокус върху поверителността за европейски бизнеси и компании, обслужващи потребители от ЕС.