Паспортные данные. Что с ними происходит — 24.12.25 09:43

Паспортные данные — это персональная информация. Она нужна, чтобы идентифицировать человеке.

Но как их хранить, что с ними делать, кому давать доступ?

Это очень часто становится развилкой в организации хранения данных.

Об этом ниже.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0.
Его я веду с нуля подписчиков.
Разбор частых ошибок и задачи по накопительной сумме уже в канале.
Присоединяйся!

Паспорт — это не просто набор цифр.
Это ключ к человеку: по нему можно понять, кто он, где живёт, какие услуги получал и что с ним происходило в системе.

Именно поэтому вокруг паспортных данных всегда много вопросов:

• Можно ли хранить паспорт в базе данных?

• Почему иногда по паспорту делают JOIN?

• Почему в одних системах паспорт виден полностью, а в других — нет?

Паспорт это не просто набор цифр.
Это ключ к человеку: по нему можно понять, кто он, где живёт, какие услуги получал и что с ним происходило в системе.

Именно поэтому вокруг паспортных данных всегда много вопросов:

• Можно ли хранить паспорт в базе данных?

• Почему иногда по паспорту делают JOIN?

• Почему в одних системах паспорт виден полностью, а в других — нет?

В идеальном мире паспортные данные:

1. Хранятся в базе данных
   Да, это важно сразу проговорить —
   👉 паспорт всё равно лежит в БД, иначе с ним просто невозможно работать.

2. Но не в открытом виде
   Это значит:

   • не просто текстом 1234 567890

   • не так, чтобы любой сотрудник мог его посмотреть запросом

3. Доступны только тем, кому действительно нужно
   Например:

   • пользователю в личном кабинете

   • сотруднику KYC / поддержки

   • системе проверки документов

В реальных системах ID клиента — не всегда надёжен.

Пример из жизни:

• человек зарегистрировался в системе

• потом пришёл снова, но:

  • с другим номером телефона

  • с другой почтой

  • через другой канал (офис / сайт / партнёр)

В итоге в базе:

• два разных client_id

• но один и тот же паспорт

👉 И это прямой сигнал:
это один и тот же человек

Поэтому в некоторых случаях:

• делают объединение (JOIN) по паспорту

• чтобы понять, что записи относятся к одному человеку

Это особенно важно:

• в банках

• в финтехе

• в государственных системах

• в CDI (системах, которые собирают данные о клиентах из разных источников)

Тогда почему паспорт нельзя просто зашифровать и забыть?

Потому что с паспортом делают проверки и сравнения.

Например:

• «Этот паспорт уже есть в системе?»

• «Этот человек уже проходил идентификацию?»

• «Это новый клиент или старый?»

Если просто заменить паспорт на набор звёздочек: **** ****** — с ним не возможно напрямую работать

Поэтому часто используют подход:

• паспорт хранится в защищённом виде

• но система всё равно может:

  • сравнивать

  • находить совпадения

  • связывать записи

Когда паспорт виден в явном виде

Да, такие случаи есть. И они нормальны, если соблюдены условия.

1️⃣ Личные кабинеты пользователей

Пользователь:

• сам вводит паспорт

• сам его видит

• сам может исправить ошибку

Это допустимо, потому что:

• это его данные

• он дал согласие

• доступ есть только у него

2️⃣ Банковские и финтех-системы

Сотрудники:

• видят паспорт полностью

• но не напрямую из базы

• а через интерфейс системы

Важно:

• каждый просмотр логируется (записывается)

• есть роли доступа

• нельзя просто «посмотреть ради интереса»

3️⃣ CDI и KYC-системы

Это системы, которые:

• собирают данные о клиенте из разных источников

• проверяют документы

• подтверждают личность

Здесь паспорт:

• часто нужен целиком

• иначе невозможно выполнить проверку

Почему аналитики обычно не видят паспорт

Потому что:

• аналитике не нужен сам паспорт

• аналитике нужен идентификатор человека

Поэтому в аналитических базах:

• паспорт заменяют на client_id

• или на специальный технический ключ

👉 Это снижает риск утечек и ошибок.

В некоторых слоях хранения данных, паспорт хранится в виде хэша. Но надо помнить, что хэш ≠ шифрование

Хэширование — это дорога в одну сторону.
Есть еще метод шифрования и при его использование можно восстановить данные, если есть ключ.

Хэш не подходит, если паспорт нужно:

• показать пользователю

• передать в другую систему

• проверить вручную

Хэш не подходит, если паспорт нужно:

• показать пользователю

• передать в другую систему

• проверить вручную

Но тогда где хранится настоящий паспорт?

В реальных системах обычно два уровня хранения:

1️⃣ Паспорт в зашифрованном виде

• хранится в БД

• может быть расшифрован

• доступ есть только:

  • у сервиса

  • у строго ограниченного круга ролей

Это нужно, когда:

• пользователь открывает личный кабинет

• сотрудник банка смотрит данные

• идёт проверка документа

2️⃣ Хэш паспорта — для связей и аналитики

• используется для:

  • поиска дублей

  • объединения клиентов

  • JOIN между системами

• никогда не раскрывается наружу

👉 Аналитик работает с хэшом
👉 Операционная система — с зашифрованным паспортом

Почему нельзя хранить только хэш?

Потому что тогда:

• нельзя показать паспорт пользователю

• нельзя исправить ошибку

• нельзя передать данные в гос-сервис

• нельзя провести ручную проверку

Хэш отвечает только на вопрос:

«Совпадает или нет?»

Но не отвечает на вопрос:

«А что именно там написано?»

Можно ли «достать паспорт из хэша»?

Нет.
И если кто-то говорит, что «у нас хэшируется, но при необходимости мы восстанавливаем» —
👉 значит это не хэш, а шифрование.

В моем канале На связи: SQL все простыми словами и с конкретными примерами.
Подписывайся!

Источник