> ## 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).
Эта страница — о том, что есть сегодня и чем это станет.

<Note>
  Основу этого сценария вы собираете сами из механизмов, которые в Veriqa уже есть; чего пока нет,
  перечислено ниже. Мы работаем над тем, чтобы упростить его реализацию в продукте.
</Note>

## Что 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.