← [Раздел](README.md) · [Главная](../README.md)

# GDPR и персональные данные

## Цель

Разобраться, что считается персональными данными (ПДн), какие принципы задаёт GDPR, как это пересекается с 152-ФЗ в РФ и что должен учитывать DevSecOps при хранении, логировании и деплое сервисов.

## Предварительно

- Понимание базовых сущностей приложения: пользователь, сессия, лог, бэкап.
- Пройден [iso27001-obzor.md](iso27001-obzor.md) — полезен контекст контролей и рисков.

## Время

~50 минут.

## Что такое персональные данные

**Персональные данные** — любая информация, по которой можно **идентифицировать** человека (прямо или вместе с другими данными).

| Пример | ПДн? | Комментарий |
|--------|-----|-------------|
| `ivan@example.com` | Да | Идентификатор |
| IP `203.0.113.42` в логе | Часто да | Может идентифицировать при связке с провайдером |
| `user_id=1847` без связи с ФИО | Зависит | Если по id восстанавливается личность — ПДн |
| Хеш пароля (bcrypt) | Спорно | Обычно относится к категории чувствительных/учётных данных |
| Агрегат «1000 заказов в день» | Нет | Нет идентификации личности |

Для инженера правило: **если сомневаешься — считай ПДн** и применяй минимизацию.

## GDPR в шести принципах (упрощённо)

Регламент ЕС **GDPR** (General Data Protection Regulation) задаёт обработку ПДн граждан ЕС:

1. **Законность, справедливость, прозрачность** — есть правовое основание (договор, согласие).
2. **Ограничение цели** — собрали email для доставки — не для рекламы без основания.
3. **Минимизация данных** — не хранить лишнее «на всякий случай».
4. **Точность** — возможность исправить данные.
5. **Ограничение хранения** — сроки и удаление (retention).
6. **Целостность и конфиденциальность** — шифрование, доступ по ролям, аудит.

Права субъекта: доступ к своим данным, исправление, удаление («право на забвение»), переносимость, возражение против обработки.

## 152-ФЗ (Россия) — параллели

В РФ основной закон — **152-ФЗ «О персональных данных»**. Для DevSecOps схожие практические требования:

- **Локализация** — первичный сбор граждан РФ часто должен храниться в РФ (уточняйте у юристов под ваш кейс).
- **Уведомление Роскомнадзора** / реестр операторов — организационный шаг.
- **Технические меры** — разграничение доступа, журналирование, защита при передаче (TLS).
- **Обработка по поручению** — договор с облаком (DPA).

DevSecOps не подписывает договоры, но **реализует** технические меры из политики.

## DevSecOps-чеклист по ПДн

### Хранение и бэкапы

- Шифрование томов БД и бэкапов (at rest).
- Отдельные namespace / сегменты сети для сервисов с ПДн.
- Retention policy: автоматическое удаление логов старше N дней (например, 90).

### Логирование

```
ПЛОХО:  log.info("User login: ivan@example.com, password=***")
ЛУЧШЕ: log.info("User login success", user_id=hash(id), request_id=uuid)
```

- Не логировать пароли, токены, полные номера карт.
- Маскирование в CI: Gitleaks + кастомные правила на email/phone в тестовых фикстурах.

### Трансграничная передача

Если бэкап или аналитика уходит в регион вне ЕС/РФ — нужны **Standard Contractual Clauses** или иные механизмы (юридический блок). DevSecOps фиксирует **где физически лежат** volume и S3 bucket (labels, inventory).

### Privacy by Design

Встраивать защиту **до продакшена**:

| Этап | Действие |
|------|----------|
| Design | Data map: какие поля ПДн, зачем |
| Dev | Псевдонимизация в staging (fake data) |
| CI | Скан секретов и PII-паттернов в репо |
| Deploy | NetworkPolicy: БД не в интернет |
| Ops | Процедура удаления по запросу пользователя |

## DPIA и Record of Processing

**DPIA** (оценка воздействия на защиту данных) — для рискованной обработки (масштабный мониторинг, биометрия). **RoPA** — реестр операций обработки. DevSecOps поставляет техническое описание: системы, потоки данных, меры защиты.

## Инцидент с утечкой ПДн

GDPR: уведомление надзорного органа **в течение 72 часов** при риске для прав субъектов. Нужны:

- время обнаружения и containment;
- категории данных и примерный объём;
- меры mitigation.

Подготовьте **шаблон** заранее (см. [lab-04](../11-praktikum/lab-04-incident-tabletop.md)).

## Самопроверка

1. Почему IP-адрес в access-log часто считают ПДн?
2. Назовите три принципа GDPR, которые напрямую влияют на настройку логов.
3. Что такое минимизация данных на примере регистрации пользователя?
4. Какие артефакты нужны для ответа на запрос «удалите мои данные»?

## Псевдонимизация и анонимизация

| Метод | Обратимость | Пример |
|-------|-------------|--------|
| Псевдонимизация | Да, с доп. ключом | `user_id=hash(email+salt)` |
| Анонимизация | Нет разумными средствами | Агрегаты без ключей |

В staging используйте **синтетические** данные (Faker), не копию prod «для удобства».

## Типовые ошибки в логах (разбор)

```python
# ПЛОХО — ПДн + учётные данные
logger.info(f"Login failed for {email} with password {pwd}")

# ЛУЧШЕ — событие без ПДн
logger.info("login_failed", extra={"reason": "bad_password", "request_id": rid})

# ПРИЕМЛЕМО с политикой — псевдоним
logger.info("login_failed", extra={"user_id": user.uuid})
```

Политика retention в Loki/ELK: индекс `app-logs` — 30 дней, `audit-security` — 365 дней.

## Чеклист для нового микросервиса

- [ ] Data map: какие поля ПДн, правовое основание.
- [ ] Шифрование TLS между сервисами.
- [ ] Нет ПДн в debug-логах на prod.
- [ ] Процедура удаления пользователя (API + backup rotation).
- [ ] Договор DPA с облаком, если обработка по поручению.

## Дальше

[Доказательства для аудита](audit-evidence.md) — как собирать и показывать выполнение политик по ПДн и ИБ.