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

Проблема: GDPR как головная боль

С 25 мая 2018 года в Евросоюзе действует General Data Protection Regulation (GDPR) — самый строгий в мире закон о защите персональных данных. Штрафы за нарушение — до 20 миллионов евро или 4% глобального годового оборота компании.

Для технических систем GDPR создаёт фундаментальные проблемы:

• Право на забвение (ст. 17) — пользователь может потребовать удалить все свои данные
• Право на доступ (ст. 15) — пользователь может запросить копию всех своих данных
• Право на перенос (ст. 20) — пользователь может забрать свои данные в читаемом формате
• Минимизация данных (ст. 5) — хранить только то, что действительно нужно
• Privacy by Design (ст. 25) — защита данных должна быть встроена в архитектуру

Для традиционных баз данных (PostgreSQL, MongoDB, даже Redis) выполнение этих требований — это инженерный ад. Нужно строить сложные системы удаления, журналирования, экспорта данных. А в блокчейнах это вообще технически невозможно — данные в блокчейне неизменны.

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

Согласно GDPR Art. 4(1), персональные данные — это любая информация, относящаяся к идентифицированному или идентифицируемому физическому лицу.

К персональным данным относятся:

• Имя, фамилия, отчество
• Email, телефон, адрес
• IP-адрес (в большинстве трактовок)
• Cookie-идентификаторы
• Биометрические данные
• Номера документов
• Фотографии, голос
• Локация
• Финансовая история

Ключевое слово: «идентифицируемому». Если по данным можно прямо или косвенно определить человека — это персональные данные. Если нельзя — не персональные.

Что MEMORIA хранит на сервере

Давайте посмотрим, что реально находится в памяти сервера MEMORIA для каждого пользователя. Вот структура UserArena (2048 байт):

type UserArena struct {
    // Двойной буфер для состояния (ping/pong)
    ping    [128]byte  // ArenaHotSlot
    pong    [128]byte  // ArenaHotSlot
    
    // Кольцевой буфер последних 10 транзакций
    txBuf   [640]byte  // 10 × 64 байта
    
    // Криптографические ключи
    userKey [32]byte   // BLAKE3 хэш от PeerID
    // ...
    
    // Идентификатор
    peerID  [20]byte   // 20-значное число
    
    // ...
}Go

А вот структура ArenaHotSlot (128 байт), которая содержит само состояние:

type ArenaHotSlot struct {
    Balance      int64     // Баланс (число)
    LastActive   uint32    // Timestamp (число)
    LastClaim    uint32    // Timestamp (число)
    LastSnapshot uint32    // Timestamp (число)
    LastTransfer uint32    // Timestamp (число)
    Flags        uint16    // Флаги (число)
    Epoch        uint16    // Эпоха (число)
    TxOffset     uint32    // Смещение (число)
    _            [224]byte // Padding
}Go

А вот структура транзакции (64 байта):

type TransferRecord struct {
    FromPeer  [20]byte       // Числовой ID
    ToPeer    [20]byte       // Числовой ID
    Amount    int64          // Сумма (число)
    Timestamp uint32         // Время (число)
    ReqID     [8]byte        // ID запроса (число)
    Status    TransferStatus // Статус (число)
    _         [3]byte        // Padding
}Go

Что такое PeerID?

PeerID — это 20-значное число, например 00000000001234567890. Он генерируется из xxhash от time.Now().UnixNano() при регистрации:

func (w *Worker) generateRegistrationOnFly(ipStr string, nowSec int64) ([20]byte, []byte, bool) {
    hash := xxhash.Sum64String(fmt.Sprintf("%d", time.Now().UnixNano()))
    newIDStr := fmt.Sprintf("%020d", hash%10000000000000000000)
    // ...
}Go

PeerID не связан с:

• Email пользователя
• Телефоном пользователя
• IP-адресом (IP не сохраняется)
• Реальным именем
• Другими аккаунтами пользователя

Это просто случайное число. Сам по себе PeerID не является персональным данным, потому что по нему невозможно идентифицировать человека.

Что такое UserKey?

UserKey — это BLAKE3-хэш от PeerID с мастер-ключом:

h := blake3.New(32, snapshotKey[:])
h.Write(peerID[:])
copy(userKey[:], h.Sum(nil))Go

Из хэша невозможно восстановить исходные данные. Это односторонняя функция. UserKey — это криптографический идентификатор, а не персональные данные.

Архитектура Shared Responsibility

Ключевая идея MEMORIA — разделение ответственности между сервером и клиентом:

Что хранит клиент (на устройстве пользователя):

• Свой последний снапшот с криптографической подписью
• Свой PeerID
• Свой приватный ключ для подписи транзакций
• Историю своих транзакций (если пользователь её ведёт)

Что хранит сервер:

• Текущий баланс (число)
• Последние 10 транзакций (в кольцевом буфере)
• Timestamps последней активности
• Криптографические ключи (хэши)

Разбор статей GDPR

Давайте пройдёмся по ключевым статьям GDPR и посмотрим, как MEMORIA им соответствует:

Статья 5 — Принципы обработки данных

Статья 17 — Право на забвение

Это самая сложная статья для технических систем. Пользователь может потребовать удалить все свои данные. Как это работает в MEMORIA?

1. Пользователь удаляет свой снапшот с устройства
2. Без снапшота пользователь не может подключиться к серверу
3. Сервер не видит активности пользователя
4. Через 7 дней (TTL = 7 дней) arena автоматически удаляется
5. Все данные пользователя исчезают из памяти сервера

const ARENA_TTL = 7 * 24 * time.Hour

func startTTLManager() {
    ticker := time.NewTicker(TTL_CHECK_INTERVAL)
    defer ticker.Stop()
    for !shutdown.Load() {
        <-ticker.C
        cutoff := time.Now().Add(-ARENA_TTL).Unix()
        // ...
        if lastActive < cutoff && balance == 0 && arena.txCount == 0 {
            // Удаляем arena из памяти
            shard.arenas[localIdx] = nil
        }
    }
}Go

Статья 20 — Право на перенос данных

Пользователь может запросить свои данные в машиночитаемом формате. В MEMORIA это тривиально:

• Снапшот — это 128-байтовый бинарный файл
• Пользователь уже хранит его локально
• Может экспортировать в любой момент
• Может импортировать на другом устройстве
• Может передать другому провайдеру (если тот поддерживает протокол)

Это полная реализация права на перенос данных — без дополнительных инженерных усилий.

Статья 25 — Privacy by Design

Это самая важная статья для нас. Она требует, чтобы защита данных была встроена в архитектуру системы, а не добавлена как «заплатка».

MEMORIA реализует Privacy by Design на каждом уровне:

1. Протокол — бинарный, без метаданных
2. Идентификация — числовой PeerID, не связанный с личностью
3. Хранение — только состояния, без истории
4. Клиент — хранит свои данные сам
5. Удаление — автоматическое через TTL
6. Криптография — BLAKE3 для верификации, не для идентификации

Право на забвение: технический разбор

Давайте детально разберём, что происходит, когда пользователь требует удалить свои данные:

Сценарий 1: Пользователь удаляет приложение

Сценарий 2: Пользователь требует удаление явно

Если пользователь отправляет запрос на удаление (например, через поддержку), сервер может:

1. Найти arena по PeerID (если пользователь его предоставил)
2. Обнулить баланс
3. Очистить ring buffer
4. Пометить arena как неактивную
5. TTL manager удалит её в следующем цикле

Или ещё проще — пользователь просто перестаёт пользоваться сервисом, и через 7 дней всё удаляется автоматически.

Сравнение с традиционными системами

CCPA, 152-ФЗ и другие законы

GDPR — не единственный закон о защите данных. Рассмотрим другие юрисдикции:

CCPA (Калифорния, США)

California Consumer Privacy Act даёт жителям Калифорнии похожие права:

• Право знать, какие данные собираются
• Право на удаление
• Право на отказ от продажи данных

MEMORIA соответствует CCPA по тем же причинам, что и GDPR: на сервере нет персональных данных в юридическом смысле.

152-ФЗ (Россия)

Федеральный закон «О персональных данных» требует:

• Согласия на обработку ПДн
• Хранения данных на территории РФ
• Возможности удаления по запросу

Поскольку MEMORIA не обрабатывает персональные данные (только числовые идентификаторы и состояния), закон формально не применяется. Но даже если бы применялся — архитектура соответствует всем требованиям.

LGPD (Бразилия)

Бразильский General Data Protection Law очень похож на GDPR. MEMORIA соответствует ему по тем же принципам.

PIPEDA (Канада)

Personal Information Protection and Electronic Documents Act — канадский аналог. Те же принципы, то же соответствие.

Честные ограничения

Мы должны быть честными: архитектура MEMORIA не идеальна с точки зрения GDPR. Вот реальные ограничения:

1. IP-адреса в логах

Хотя MEMORIA не хранит IP-адреса в памяти, они могут попадать в логи операционной системы или сетевого оборудования. Это нужно учитывать и настраивать логирование соответствующим образом.

2. Аналитика и метрики

Если разработчики собирают анонимную аналитику (количество пользователей, объём транзакций), это может считаться обработкой данных в некоторых трактовках. Нужно явно анонимизировать такие данные.

3. Связь PeerID с личностью

Если пользователь сам связывает свой PeerID с личностью (например, публикует его в соцсетях), PeerID может стать персональным данными косвенно. Это вне контроля архитектуры.

4. Юридическая неопределённость

Законы о защите данных не успевают за технологиями. То, что сегодня считается «не персональными данными», завтра может быть переклассифицировано судебным решением. Нужно следить за правоприменительной практикой.

5. Трансграничные переводы

Если сервер находится в одной юрисдикции, а пользователи в другой — могут применяться требования о трансграничной передаче данных. MEMORIA решает это тем, что данные не передаются в юридическом смысле — передаются только криптографические состояния.

Выводы

Давайте подведём итог. MEMORIA не «обходит» законы о защите данных. Она делает нечто более фундаментальное — устраняет саму проблему на уровне архитектуры.

Ключевые принципы архитектуры MEMORIA:

1. Data Minimization — только 2KB на пользователя, только числа
2. Purpose Limitation — одна цель: обработка состояния
3. Storage Limitation — ring buffer + TTL = автоматическое удаление
4. Shared Responsibility — клиент хранит свои данные сам
5. Privacy by Default — приватность включена по умолчанию, без настроек

В следующей статье (которая станет первой в цикле о бизнес-применении) мы разберём, как MEMORIA может быть интегрирована в существующие продукты — от мобильных игр до платёжных систем — и какой экономический эффект это даёт.