> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Устойчивость к утечке персональных данных

> Связка «личность ↔ точка достижимости» — самое токсичное в базе коннектора. Что Veriqa хранит сегодня, каким спроектирован режим и чего он не даёт.

Любой коннектор между приложением и мессенджером обязан ответить на вопрос, какая учётная запись в
мессенджере принадлежит этому пользователю, — и обычный ответ хранится в базе столько же, сколько
живёт сама учётная запись. Почему эта колонка токсичнее пароля — на странице
[«Устойчивость к утечке персональных данных»](https://veriqa.app/whats-next/leak-resilience).
Здесь — что есть сегодня и чем это станет.

## Что Veriqa хранит сегодня

Начнём с текущего состояния: именно на нём вы принимаете решение о рисках.

**Идентификатор канала и профиль хранятся в открытом виде.** Ключ канальной идентичности — пара
«тип канала + идентификатор пользователя в нём», рядом лежит профиль: отображаемое имя, имя и
фамилия, username, адрес почты, телефон, аватар, локаль. Производных форм на пути хранения нет,
срока жизни у записи тоже. Это ровно то поведение, которое есть у любого коннектора, — но знать
его лучше заранее.

**Маскирование сегодня закрывает только журналы.** Аудит и логи по контракту не пишут ни токенов,
ни неприкрытых идентичностей, и это работает. Основного хранилища эта норма не касается.

**И оговорка, на которой держится решение о рисках: из коробки этого хранилища нет.** Veriqa не
поставляет реализации порта, который сохранял бы канальную идентичность, и не регистрирует ни
одной — штатная установка держит профиль ровно те минуты, что живёт транзакция. Всё описанное
выше начинает действовать с момента, когда вы зарегистрировали собственную реализацию. Полный
инвентарь — что где лежит, сколько живёт и что зашифровано — в
[Безопасности и обработке данных](/docs/ru/guides/data-handling).

<Note>
  Шифрование, которое в продукте уже есть, относится к **секретам провайдеров каналов**, а не к
  идентификаторам пользователей. Рекомендации по укреплению закрывают секреты и соединение с базой
  — не идентификаторы.
</Note>

## Каким спроектирован режим

Режим спроектирован как решение интегратора — режим уровня тенанта, который включают осознанно, а
не умолчание, меняющее поведение для всех. Он сводится к четырём свойствам, и они связаны между
собой.

**Производное значение вместо нативного идентификатора.** В записи лежит односторонний хеш на
секрете, а не сам идентификатор. Один и тот же человек всегда даёт одно и то же значение — учётная
запись узнаётся при каждом входе, — но обратно в telegram id или адрес почты значение не
разворачивается.

**Секрет живёт не рядом с данными.** Он в KMS или секрет-сторе, включая self-hosted-развёртывания,
без послаблений. Это не совет по укреплению, а условие работоспособности: пространство возможных
входов мало настолько, что перебирается целиком, и секрет в том же снимке, что и база, позволил бы
атакующему просто пересчитать функцию самому. Там, где секрет-стора нет, режим спроектирован **не
включаться**, а не деградировать до чего-то послабее.

**У разных интеграторов — разные значения.** Тенант входит в вычисление, поэтому один и тот же
человек превращается в разное значение в базе каждого интегратора. Две утёкшие базы не
склеиваются между собой и не склеиваются с купленной маркетинговой базой.

**А где сценарий позволяет — вообще никакого значения.** Если пользователь всегда приходит из
канала сам, идентификатор приезжает с каждым подтверждением, и между транзакциями хранить нечего.
Сильнейшая форма свойства — не «хорошо зашифровано», а «не записано вовсе».

## Чем за это платят

Оба следствия вытекают из самого свойства, а не оговаривают его:

* **Найти пользователя по его telegram id или адресу почты станет нельзя.** Ровно за это и платят.
* **Сценарию, который сам инициирует подтверждение в канал**, нативный идентификатор всё-таки
  нужен обратно. Там он спроектирован жить зашифрованным на ключе того же сервиса — обратимо, в
  отличие от хеша: сильнее хранения в открытом виде, слабее режима, который не хранит ничего.

## Чего это не делает

<Warning>
  **Данные не выводятся из-под GDPR и национального законодательства о персональных данных.**
  Псевдонимизация там — мера защиты (GDPR ст. 4(5) и ст. 32(1)(a)), а не анонимизация: данные
  остаются персональными, и обязанности оператора никуда не деваются. Меняется то, сколько
  остаётся терять.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.