Турагентство: паспортные данные туристов в чужой CRM — считаем риск честно

MAATRIX

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

Что именно оседает в CRM турагентства

Если посмотреть на карточку клиента в типичной CRM для турагентства, там накапливается куда больше, чем кажется на первый взгляд:

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

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

Как устроена облачная CRM изнутри

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

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

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

Честно о факторах риска

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

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

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

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

Массовость как фактор привлекательности для атак. База данных облачной CRM, где хранятся записи тысяч компаний одновременно, — более привлекательная цель для злоумышленника, чем локальная база одного турагентства. Взломав один SaaS-сервис, атакующий потенциально получает доступ к данным сотен клиентов сразу. Это не значит, что такой сервис обязательно взломают — но математика привлекательности цели работает именно так.

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

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

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

Когда облачная CRM — разумный выбор

Не нужно бросаться переносить всё на свой сервер после прочтения списка рисков выше. Для многих агентств облачная CRM годами остаётся адекватным решением, и вот почему:

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

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

Альтернатива: свой сервер под CRM турагентства

Если решение — держать паспортные данные туристов под собственным контролем, вариант простой по сути и требующий аккуратности в реализации: разворачиваете CRM с открытым кодом на собственном сервере, а не пользуетесь чужим SaaS.

Практическая разница по сравнению с облачной CRM:

Технически это выглядит так: берёте VPS или выделенный сервер, ставите на него систему для CRM с открытым исходным кодом (например, SuiteCRM — по установке SuiteCRM на Ubuntu 24.04 в блоге есть отдельный пошаговый разбор), настраиваете HTTPS с собственным сертификатом, ограничиваете доступ к админ-панели по IP или через VPN, и включаете регулярное резервное копирование базы данных с шифрованием. Похожий путь для другой отрасли, тоже завязанной на чувствительные данные клиентов, мы разбирали в статье про собственную CRM риелтора на своём сервере.

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

Как перенести CRM турагентства на свой сервер: пошагово

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

1. Оцените объём и структуру данных. Выгрузите текущую базу клиентов из облачной CRM (обычно есть экспорт в CSV или через API) и посмотрите, сколько записей, какие поля используются реально, а какие — балласт с внедрения три года назад.

2. Подберите сервер под нагрузку. Для агентства на 5–20 менеджеров и базу в несколько тысяч клиентских карточек обычно достаточно VPS с 4 ядрами и 8 ГБ оперативной памяти — но точный расчёт зависит от того, храните ли вы сканы документов прямо в CRM (это добавляет требования к дисковому пространству) и сколько одновременных пользователей работает в системе.

3. Разверните и настройте CRM. Установите выбранную систему, перенесите данные через импорт, проверьте, что все обязательные поля (включая поля для паспортных данных) отображаются и заполняются корректно.

4. Настройте шифрование и доступ. База данных с паспортными данными должна быть зашифрована на уровне диска, а доступ к серверу — только по SSH-ключам, без паролей. Административную панель CRM стоит закрыть от внешнего доступа через VPN или белый список IP-адресов офиса.

5. Настройте резервное копирование. Ежедневный бэкап базы данных с шифрованием, хранение копий отдельно от основного сервера — это то, что при облачной CRM делает провайдер, а теперь придётся делать вам. Это не сложнее одного скрипта на cron, но пропустить этот шаг — частая ошибка при самостоятельном переезде.

6. Проведите тестовый период параллельно. Не отключайте старую CRM сразу — дайте команде поработать в новой системе пару недель параллельно со старой, чтобы отловить недостающие поля и привычки менеджеров, завязанные на интерфейс прежнего сервиса.

7. Ограничьте, кто и как выгружает данные. После переезда стоит завести правило: скан паспорта не пересылается в мессенджер «для скорости», а загружается сразу в защищённую карточку CRM. Технический контроль без организационной дисциплины работает наполовину.

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

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