Тревел-агент хранит сканы паспортов клиентов: как не нарушить закон

MAATRIX

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

Что не так с хранением сканов паспортов в почте и общих папках

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

На практике это выливается в конкретные дыры:

• Ссылка расшаривается шире, чем нужно. «Доступ по ссылке» удобен: не нужно приглашать по email, файл открывается у любого, кому переслали ссылку. Ровно поэтому её так легко переслать не туда — коллеге, который уже не работает, в общий чат группы, случайно вставить в письмо не тому получателю.
• Нет разделения по клиентам. В одной папке «Паспорта 2026» лежат сканы десятков разных людей. Если доступ к папке получает случайный человек — утекают не отдельные файлы, а вся база разом.
• Почта — не хранилище, а транспорт. Письмо с вложенным сканом остаётся в ящике годами, дублируется в отправленных, попадает в автоматические бэкапы почтового сервиса, индексируется поиском. Через три года агент уже не помнит, что там лежит, а скан — лежит.
• Личные аккаунты сотрудников. Если менеджер сохраняет скан к себе в личный Google Drive «чтобы было под рукой», данные клиента формально уходят за периметр компании — и агентство теряет контроль над тем, где они хранятся и что с ними происходит после увольнения этого человека.
• Мессенджеры как рабочий канал. WhatsApp и Telegram — самый частый способ, которым клиент присылает скан паспорта. Файл оседает в кэше телефона менеджера, синхронизируется в облако мессенджера, остаётся в чате бессрочно.

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

Почему сканы паспортов — это не просто файлы

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

У тревел-агента таких файлов особенно много и особенно разнообразных:

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

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

Что меняется, если данные лежат на своём сервере

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

Ключевые отличия от обезличенного облачного сервиса общего назначения:

• Один периметр, а не десять. Вместо Google Drive у одного менеджера, Dropbox у другого и почты у третьего — одно хранилище с единым списком пользователей и единой политикой доступа.
• Права по клиенту и по сотруднику. Менеджер видит сканы только своих клиентов (или своего направления), а не архив всего агентства. Это резко снижает ущерб от компрометации одной учётной записи.
• Данные физически не покидают выбранную юрисдикцию. Вы сами выбираете дата-центр — это снимает вопрос «а где вообще физически лежат данные наших клиентов», который в бесплатных облаках часто вообще не имеет внятного ответа.
• Полный журнал действий. Кто, когда и какой файл открыл, скачал, удалил — видно в логах, а не восстанавливается по памяти после инцидента.
• Управляемые сроки хранения. Скан, который был нужен только для оформления визы, можно и нужно удалять по истечении разумного срока — на своём сервере это настраиваемое правило, а не ручная уборка, до которой никогда не доходят руки.
• Никакой third-party индексации. Бесплатные облачные сервисы зарабатывают в том числе на анализе данных пользователей для собственных нужд (реклама, обучение сервисов). У своего сервера такого стороннего интереса к содержимому попросту нет.

Это не значит, что свой сервер автоматически безопаснее любого облака при любых настройках — если оставить его с паролем admin/admin и открытым портом наружу, будет хуже, чем в Google Drive с двухфакторной аутентификацией. Ответственность и контроль требуют, чтобы сервер был настроен грамотно. Но именно это агентство и получает — контроль, а не иллюзию контроля.

Минимальный рабочий контур: что разворачивать

Для тревел-агентства не нужен сложный корпоративный контур с отдельным DLP и SIEM — нужна разумная связка из нескольких проверенных компонентов на одном сервере.

1. Файловое хранилище с управлением доступом. Самый практичный вариант для команды из нескольких менеджеров — Nextcloud: у каждого сотрудника свой логин, у каждой папки — свои права, есть встроенный журнал действий и поддержка двухфакторной аутентификации.

Структура папок, которая снимает большинство вопросов на старте:

/clients
  /2026-08-ivanov-turция
    passport_ivanov.pdf
    passport_ivanova.pdf
    birth_cert_ivanov_child.pdf
  /2026-08-petrova-oae
    passport_petrova.pdf
/archive
  /2025
  /2024

Права на /clients/* выдаются только менеджеру, который ведёт эту заявку, и руководителю. Общий доступ «всем сотрудникам» на всю папку /clients — это то, от чего вы уходите.

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

3. Двухфакторная аутентификация для входа. Пароль сотрудника может утечь — так происходит регулярно, независимо от того, насколько сложный пароль вы просили придумать. 2FA закрывает именно этот сценарий: без второго фактора (приложение-аутентификатор на телефоне) вход не пройдёт, даже если пароль известен третьему лицу.

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

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

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

Для агентства из 3–7 человек этот контур разворачивается на бюджетном VPS за один рабочий день, если делать это не в первый раз, и за два-три дня — если настраивать впервые и разбираться по ходу. Отдельный сервер под саму задачу (а не «ещё одна папка на общем корпоративном диске, где лежит вообще всё подряд») — это осознанное разделение: сбой или инцидент с рабочей почтой или CRM не затрагивает архив документов клиентов.

Организационная часть: без неё техника не спасает

Технический контур закрывает половину задачи. Вторая половина — правила, по которым команда реально работает, а не то, что написано в регламенте и никем не соблюдается.

• Кто и зачем получает скан. Прежде чем запрашивать у клиента документ, стоит держать в голове простой вопрос: этот скан действительно нужен для оформления именно этой брони, визы или страховки — или запрашивается «на всякий случай», потому что так проще менеджеру? Второе — источник лишнего риска без реальной пользы.
• Куда скан попадает первым делом. Если клиент по привычке присылает документ в WhatsApp, задача менеджера — сразу перенести файл в хранилище и удалить его из переписки, а не оставить лежать в чате «до момента, когда понадобится ещё раз».
• Сколько хранить после завершения поездки. Для большинства случаев смысла держать скан годами после того, как тур закрыт, нет — кроме ситуаций, когда это прямо требуется для отчётности перед туроператором или страховой в течение оговорённого срока. Разумный подход — определить срок (например, для своего агентства) и настроить автоматическое перемещение старых файлов в архив с более узким доступом либо их удаление.
• Что происходит при увольнении сотрудника. Учётная запись отключается в день увольнения, а не «когда вспомнят». На своём сервере это одна операция администратора; в личных облачных аккаунтах бывших сотрудников проконтролировать это в принципе невозможно.
• Кто отвечает за сервер технически. У небольшого агентства редко есть штатный админ — но должен быть один ответственный человек (даже если это внешний подрядчик на почасовой основе), который следит за обновлениями системы и панели, а не оставляет сервер работать «как есть» годами.
• Простое человеческое правило: не пересылать скан клиента третьим лицам мессенджером «для уточнения», если можно дать точечный, временный доступ к конкретному файлу через хранилище.

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

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