Страховой агент держит полисы клиентов: персональные данные не в чужом облаке

MAATRIX

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

Что именно хранит агент и почему это чувствительные данные

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

• ФИО, дату рождения, паспортные данные — нужны для оформления полиса;
• телефон, email, иногда адрес проживания;
• данные о собственности или транспорте — то, что страхуется;
• историю обращений: какие полисы куплены, когда продлевались, что забыл клиент указать;
• историю страховых случаев — а это уже сведения деликатного характера: ДТП, ущерб имуществу, а для страхования жизни и здоровья — фактически медицинские данные;
• иногда реквизиты для расчёта выплат.

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

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

Почему общая облачная таблица — плохое хранилище для базы клиентов

Google Таблицы, Excel в общей папке, заметки в Telegram или в блокноте на телефоне — у всех этих вариантов одна общая проблема: вы не контролируете, что происходит с данными за пределами экрана, который видите сами. Разберём по пунктам, что именно не устраивает в таком хранении.

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

Копии расползаются бесконтрольно. Таблицу выгрузили в Excel для отчёта, отправили в мессенджере коллеге, кто-то скачал её на личный ноутбук «поработать вечером». Через полгода вы уже не знаете, сколько копий базы существует и где они лежат. С полноценным сервером таких бесконтрольных копий не появляется — данные остаются в одном месте, а не размножаются при каждой пересылке.

Нет истории изменений и следов действий. В большинстве бытовых схем хранения вы не увидите, кто и когда открывал карточку конкретного клиента, кто менял номер телефона на неверный. Если возникнет спорная ситуация с клиентом («вы же говорили, что...»), доказать что-либо по логам практически нечем.

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

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

Свой сервер: что меняется на практике

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

Практически это означает три вещи.

Во-первых, данные хранятся в одном определённом месте — на конкретном сервере, в конкретной стране, а не «где-то в облаке провайдера, у которого дата-центры раскиданы по миру и меняются без предупреждения». Вы сами выбираете локацию — например, сервер в Великобритании, США или России, — и это осознанный выбор, а не то, что решил за вас сервис.

Во-вторых, доступ выдаёте персонально и точечно: конкретному человеку — конкретный уровень прав, а не общий пароль от таблицы на всех. Отозвать доступ — значит удалить одну учётную запись, а не менять пароль для всех сразу.

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

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

Как это устроить: практическая схема

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

Сервер с закрытым доступом только по ключу. Отключаете вход по паролю, настраиваете вход по SSH-ключу:

# на сервере: запрещаем вход по паролю
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Firewall, закрывающий всё лишнее. Открыт только SSH (желательно с нестандартного порта) и, если нужно, порт веб-интерфейса — и только по VPN, а не всему интернету:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow from 10.8.0.0/24 to any port 443
sudo ufw enable

Хранилище данных вместо таблицы. Вариантов два, в зависимости от того, сколько у вас клиентов и насколько вам нужна гибкость:

• Если база — это по сути карточки клиентов с файлами (сканы полисов, документов), удобно поставить Nextcloud: у него есть структурированные папки, права доступа на уровне пользователя и версии файлов. Мы подробно разбирали установку в статье про настройку Nextcloud на VPS.
• Если нужна именно база с полями (клиент, полис, дата, статус, история случаев) и поиском по ней, есть смысл смотреть в сторону лёгкой CRM или базы данных на PostgreSQL — принцип тот же, что и в схеме с собственной CRM для риелтора: своя система вместо чужого облачного сервиса, куда данные клиентов передаются третьей стороне.

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

sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup open /dev/sdb1 clientdata
sudo mkfs.ext4 /dev/mapper/clientdata
sudo mount /dev/mapper/clientdata /srv/clients

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

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

Доступ команды и помощников без общего пароля на всё

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

Практический подход:

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

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

Резервные копии и потеря устройства

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

Разумная схема для базы клиентов агента:

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

Инструмент вроде BorgBackup хорошо подходит для такой задачи — он умеет шифровать архив и делать инкрементальные копии, чтобы не гонять каждый день весь объём данных заново:

borg init --encryption=repokey-blake2 /mnt/backup/clients-repo
borg create --stats --progress \
  /mnt/backup/clients-repo::clients-$(date +%Y-%m-%d) \
  /srv/clients

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

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

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