Ломбард: журнал залогов и паспортные данные — требования к хранению и свой сервер

MAATRIX

Если вы держите ломбард, у вас уже есть база данных серьёзнее, чем у большинства малого бизнеса. В каждой квитанции на кассе — паспортные данные клиента, история его залогов, оценка изделия и подпись. Это не «клиентская база» для рассылок — это персональные данные в самой чувствительной их части, помноженные на то, что сама деятельность ломбарда прямо предполагает их фиксацию в журнале. Разберём, что именно там хранится, почему это зона ответственности, а не техническая мелочь, и почему свой сервер под контролем ломбарда справляется с этой задачей лучше, чем облачная CRM общего назначения.

Что на самом деле лежит в журнале залогов

Журнал залоговых операций — это не таблица с email и телефонами для рассылки акций. Посмотрите, что реально попадает в одну запись при оформлении залогового билета:

• ФИО, дата и место рождения клиента;
• серия и номер паспорта, кем и когда выдан, код подразделения;
• адрес регистрации, иногда фактический адрес проживания;
• контактный телефон;
• описание предмета залога — от модели телефона до пробы и веса ювелирного изделия;
• сумма оценки, сумма займа, ставка, срок;
• подпись клиента — на бумаге или в виде скана/фото;
• нередко — фотокопия самого паспорта, разворот с фото и пропиской.

По отдельности часть этих полей не выглядит критично. Но паспортные данные вместе с адресом, суммой займа и фотографией документа — это готовый комплект для мошенничества с чужим именем: оформление кредитов, регистрация фирм-однодневок, доступ к госуслугам. Утечка такой базы бьёт не по абстрактной «репутации», а по конкретным людям, которые к вам просто заложили телефон или кольцо.

Таблица ниже — грубая прикидка, что именно в записи наиболее чувствительно и что произойдёт при утечке именно этого поля.

Именно фотокопия паспорта — самое опасное поле в этом списке, потому что она снимает необходимость «угадывать» остальные данные: всё уже на одной картинке.

Почему ломбард — не просто магазин с базой клиентов

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

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

Из этого следует практический вывод: вопрос «где и как хранить журнал» — это не только вопрос IT-удобства, но и часть репутации и устойчивости бизнеса перед проверяющими органами и перед самими клиентами, которые доверяют вам документ, удостоверяющий личность.

Где сейчас чаще всего хранят такой журнал — и что не так

На практике встречаются три сценария, и у каждого свои слабые места.

Бумажный журнал. Юридически привычен, но физически уязвим: пожар, залив, кража папки с кассы — и данные утеряны безвозвратно или, хуже, оказались у постороннего. Поиск по такому журналу — это пролистывание вручную, что на практике означает, что при проверке или при споре с клиентом найти нужную запись за прошлый год — отдельная задача на полдня.

Excel/Word на офисном компьютере. Быстро становится узким местом: файл можно скопировать на флешку за пять секунд, разослать по почте по ошибке не тому адресату, случайно затереть форматированием. Как правило, никакого разграничения доступа: любой, кто сидит за этим компьютером или имеет пароль от него, видит весь журнал целиком, включая фото паспортов клиентов пятилетней давности.

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

Почему сторонний облачный сервис — не лучший вариант именно для этих данных

Дело не в том, что облако — это плохо в принципе. Универсальный облачный сервис (обычная CRM, таблица в общем документообороте, чат для поддержки) спроектирован для сотен разных сценариев использования сразу, и данные ломбарда с паспортными сканами — лишь один из многих типов информации, которые через него проходят. Отсюда несколько конкретных проблем:

• Вы не выбираете соседей. В мультитенантной SaaS-системе ваши данные физически находятся на тех же серверах, что и данные тысяч других клиентов сервиса. Изоляция обеспечивается программно, и её надёжность можно оценить только по репутации поставщика, а не проверить самим.
• Доступ у сотрудников провайдера. Служба поддержки и инженеры сервиса технически могут получить доступ к базе для диагностики проблемы. Это не злой умысел, а устройство любой SaaS-платформы — но для журнала с паспортными данными это лишний круг людей, способных увидеть скан паспорта клиента.
• Вы не знаете точно, где физически лежат бэкапы. Оферта обычно не детализирует географию хранения резервных копий, а это важно и для локализации данных, и для понимания, чьи законы применимы.
• Один инцидент — это инцидент у всех клиентов сразу. При утечке у платформы под удар попадают базы всех арендаторов одновременно, а не только ваша.
• Саппорт-переписка как канал утечки. Когда что-то не работает, в поддержку часто уходит скриншот записи «для примера» — с реальным паспортом реального клиента, отправленным в чужую систему тикетов.

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

Свой сервер как ответственная точка хранения

Альтернатива — не «облако вообще», а конкретный сервер (VPS или выделенный), полностью под контролем ломбарда: вы решаете, где физически расположен дата-центр, кто и как получает доступ, как шифруются данные на диске, как и куда уходят резервные копии.

Базовая архитектура для журнала залогов выглядит так:

• База данных (например, PostgreSQL) с разграничением ролей: кассир видит и создаёт записи, но не может массово выгружать всю базу; администратор имеет более широкий доступ, но каждое его действие фиксируется отдельно.
• Приложение — либо готовая учётная система для ломбардов, установленная на вашем сервере, либо собственная простая CRM/веб-форма поверх базы, доступная только через VPN, а не напрямую из интернета.
• Шифрование диска, чтобы физический доступ к серверу (кража оборудования у хостера, некорректная утилизация старого диска) не превращался в готовую утечку данных в открытом виде. Подробнее о том, что именно защищает шифрование диска и от каких сценариев оно не спасает, — в статье про шифрование дисков.
• Отдельно зашифрованные резервные копии, которые физически лежат не на той же машине, что и рабочая база — иначе один сбой диска убивает и данные, и бэкап одновременно.
• Журнал доступа (аудит-лог) — отдельная таблица, куда пишется, кто, когда и какую запись клиента открывал или редактировал. Это то, чего почти никогда нет в готовой облачной CRM «из коробки», но что легко сделать на своей базе одним триггером.

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

Что касается географии: где именно должен физически находиться такой сервер для российского ломбарда, работающего с российскими клиентами, — вопрос, который стоит уточнить у юриста применительно к вашей ситуации, потому что здесь пересекаются требования по локализации персональных данных и специфика конкретного бизнеса. Общий разбор того, что означает требование локализации баз с персональными данными, — в статье локализация баз ПДн: что это означает, а более широкий обзор — где закон разрешает держать сервер с персональными данными — в статье 152-ФЗ: где законно держать сервер с персональными данными.

Практическая настройка: минимальный рабочий контур

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

1. Шифрование диска на этапе установки ОС. Для Linux-сервера это обычно LUKS поверх раздела с данными:

cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 lombard_data
mkfs.ext4 /dev/mapper/lombard_data
mount /dev/mapper/lombard_data /var/lib/postgresql/data

Ключ шифрования должен храниться отдельно от сервера — не в текстовом файле рядом с базой.

2. Роли в базе данных вместо одного общего пользователя. Пример для PostgreSQL:

CREATE ROLE cashier LOGIN PASSWORD 'сложный_пароль';
GRANT SELECT, INSERT ON pledge_journal TO cashier;
REVOKE DELETE, TRUNCATE ON pledge_journal FROM cashier;

CREATE ROLE auditor LOGIN PASSWORD 'другой_сложный_пароль';
GRANT SELECT ON pledge_journal TO auditor;

Кассир может создавать записи и просматривать нужное, но не может массово удалить или выгрузить журнал целиком. Аудитор видит всё для проверки, но ничего не меняет.

3. Доступ к панели управления только через VPN. Административная часть системы не должна торчать наружу в интернет с формой логина, доступной кому угодно. WireGuard поднимается быстро и даёт каждому сотруднику отдельный ключ, который можно отозвать при увольнении:

[Interface]
PrivateKey = <ключ_сервера>
Address = 10.20.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <ключ_сотрудника>
AllowedIPs = 10.20.0.2/32

4. Резервное копирование с шифрованием и выносом копии. Простой вариант — pg_dump плюс шифрование архива перед выгрузкой на второй сервер или в отдельное хранилище:

pg_dump lombard_db | gpg --encrypt -r backup@lombard.local > backup_$(date +%F).sql.gpg

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

5. Логирование действий на уровне приложения. Простейший вариант — триггер в базе, который при любом SELECT/UPDATE записи клиента добавляет строку в таблицу аудита: кто, когда, какую запись. Это отвечает на вопрос «кто вообще открывал дело этого клиента» — вопрос, который рано или поздно задаст либо сам клиент, либо проверяющий.

Типичные ошибки и грабли

На практике почти все проблемы с хранением журнала залогов происходят не из-за отсутствия технологий, а из-за нескольких повторяющихся привычек:

• Фотографии паспортов лежат обычными файлами в открытой папке. Часто это папка на рабочем столе или в общей сетевой шаре, доступная всем сотрудникам без исключения, а иногда — с прямой ссылкой, которую можно переслать.
• Один общий пароль администратора на всех. Когда у всех кассиров один и тот же логин «admin», невозможно потом установить, кто именно смотрел или менял конкретную запись — а значит, невозможно и разбираться в спорной ситуации.
• Бэкап хранится на личном облачном диске сотрудника. «Чтобы не потерять» — база с паспортными данными клиентов оказывается на личном Google Диске или Яндекс.Диске конкретного человека, вне какого-либо контроля компании, и остаётся там даже после его увольнения.
• Нет политики удаления старых данных. Записи по давно закрытым и выкупленным залогам продолжают копиться годами без какой-либо необходимости — это просто увеличивает объём данных, которые можно потерять или у которых можно похитить, без встречной пользы для бизнеса.
• Подрядчику выдают полный root без ограничений и без журналирования. Разовая задача «поправить сервер» превращается в постоянный, никем не отслеживаемый доступ к базе с паспортными данными клиентов.
• Бэкап никогда не проверяли на восстановление. Скрипт исправно создаёт файл каждую ночь, но никто не пробовал развернуть его на чистой машине — и в момент реального сбоя выясняется, что архив битый или зашифрован ключом, который потерян.

Каждая из этих проблем решается не сложной технологией, а простой дисциплиной: разделить роли, шифровать данные и бэкапы, ограничить доступ и время от времени проверять, что всё это реально работает.

Частые вопросы