Страхование

Доля страховых организаций в утечках из компаний финансового сектора России за январь–октябрь 2025 года превысила 20% — максимум за последние четыре года, при том что у банков этот показатель снижается.

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

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

Главное

1. Требования. Положение Банка России № 757-П распространяется на всех субъектов страхового дела: страховые организации, страховых брокеров и общества взаимного страхования (ОВС). Уровень защиты зависит от суммы активов за последние шесть месяцев: свыше 20 млрд руб. — стандартный, остальные — минимальный.
2. Три риска. Агентская сеть (агенты, брокеры, подрядчики работают вне периметра), данные о здоровье в ДМС и страховании жизни (ст. 10 152-ФЗ), передача данных в АИС страхования.
3. Что нужно от менеджера паролей. Временный доступ для внешних пользователей, ролевая модель и типы сейфов, журнал аудита с экспортом в SIEM, клиентское шифрование zero-knowledge, сервисные аккаунты и API, офлайн-доступ.
4. Как Пассворк отвечает этим требованиям. Одно решение для паролей сотрудников и секретов интеграций, с общей ролевой моделью и журналом аудита. Сертификат ФСТЭК (4-й уровень доверия), запись в реестре российского ПО.

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

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

Рост виден в цифрах. В 2025 году число утечек из страховых компаний выросло примерно на 40% по сравнению с 2024 годом: по минимальным оценкам, речь идёт о 10–15 случаях среди крупнейших страховщиков, и это без учёта инцидентов, которые не стали публичными. По предварительным оценкам ГК InfoWatch, персональные данные присутствовали в 100% утечек из страховых организаций за 2025 год.

В части утечек данных 2023–2025 годов среди крупных российских страховых организаций в открытый доступ попадали логины и хеши паролей — сами учётные данные для входа, которые потом используют для подбора доступа к другим системам того же человека.

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

Кто из страховых организаций обязан защищать информацию по 757-П и что это значит на практике

Положение Банка России № 757-П обязывает защищать информацию всех субъектов страхового дела: страховых организаций, страховых брокеров и общества взаимного страхования (ОВС). Уровень защиты определяет один параметр. Это сумма активов организации за последние шесть месяцев. Оба уровня опираются на ГОСТ Р 57580.1-2017.

Два уровня защиты для страхового сегмента

757-П распространяется на все некредитные финансовые организации (НФО), от страховщиков до форекс-дилеров и управляющих компаний. Страховой сегмент при этом имеет собственные категории и пороги по активам. Применять к нему общий шаблон для всех НФО нельзя: от категории зависят и уровень защиты, и состав обязательных мер.

Что требует закон и что требует положение

Закон РФ № 4015-1 «Об организации страхового дела в Российской Федерации» обязывает страховщиков обеспечивать сохранность, конфиденциальность и целостность информации, используемой в страховой деятельности. Положение № 757-П детализирует эту обязанность: задаёт технические требования и уровни защиты.

Оба документа определяют уровень защиты, а не конкретные инструменты, и выбор средств остаётся за организацией. Но ГОСТ Р 57580.1 требует управлять учётными записями, применять парольную политику и вести аудит доступа. В таблицах Excel это не выполнить: в них нет истории действий и разграничения прав на уровне записи, а доступ нельзя быстро отозвать. Эти меры закрывают централизованным хранилищем учётных данных с ролевой моделью и журналом аудита.

Оценка соответствия и ответственность

Оценку соответствия проводят ежегодно, не позднее 10-го рабочего дня календарного года. За нарушения предусмотрена ответственность по ст. 13.12 КоАП РФ: штраф от 10 000 до 30 000 руб., приостановка деятельности на срок до трёх месяцев, изъятие несертифицированных средств защиты информации.

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

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

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

Три типовых риска внешнего доступа

• Компрометация учётной записи агента через слабый или переиспользованный пароль, который агент применяет в нескольких порталах разных страховщиков одновременно.
• Утечка через подрядчика, который получил доступ к клиентской базе для разовой задачи и сохранил его дольше, чем было нужно.
• Фишинг, нацеленный на распределённую агентскую сеть, где нет единого ИБ-периметра и сложно быстро довести предупреждение до каждого агента.

Почему парольной политики недостаточно

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

Как устроить внешний доступ

1. Временная или одноразовая ссылка на запись. Она действует ограниченное время или ограниченное число раз.
2. Групповые права вместо персональных. Доступ привязан к роли и группе, а не к человеку.
3. Отзыв доступа одним действием. При завершении сотрудничества права снимаются сразу во всех местах.
4. Журнал аудита. Каждое обращение к записи фиксируется, и ИБ-служба видит, кто и когда с ней работал.

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

Данные о здоровье клиентов в ДМС и страховании жизни: повышенные требования к доступу

Сведения о состоянии здоровья относятся к специальной категории персональных данных. Для их обработки ст. 10 Федерального закона № 152-ФЗ «О персональных данных» устанавливает повышенные требования к защите и отдельное согласие субъекта. Поэтому доступ к таким данным в страховой компании нужно ограничивать строже, чем к остальной клиентской базе.

Почему это касается ДМС и страхования жизни

Компании, которые работают с добровольным медицинским страхованием (ДМС) и страхованием жизни, обрабатывают специальную категорию персональных данных в каждом страховом случае. Диагнозы, обращения к врачу и результаты обследований входят в материалы дела и хранятся рядом с финансовыми данными клиента, поэтому требования ст. 10 152-ФЗ применяются к ним постоянно.

Доступ к такой базе должен быть уже, чем к обычной клиентской CRM. Сотрудник, который оформляет полисы ОСАГО или КАСКО, не должен видеть медицинскую историю клиента по ДМС.

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

Как это реализовать

1. Отдельный сейф. Данные ДМС и страхования жизни хранятся в собственном сейфе, а не в общем разделе с клиентскими записями.
2. Отдельный администратор. У сейфа свой администратор, который управляет составом доступа.
3. Доступ по роли. Права получают только сотрудники, которым работа с такими данными нужна по должности.
4. Клиентское шифрование нулевого знания (zero-knowledge). Данные шифруются на устройстве сотрудника, и сервер не может их прочитать.

Передача данных в АИС страхования: ещё одна точка, которую нужно защищать

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

Масштаб системы

Объём данных в АИС страхования в 2025 году вырос в 1,3 раза и составил 84,6 млн договоров. Система хранит сведения о более чем 120 млн полисов ОСАГО, 30 млн договоров КАСКО и ДСАГО и 20 млн договоров страхования жилья (CNews).

Как устроено хранение таких данных

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

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

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

Как защитить

Такую интеграцию защищают сервисные учётные записи с тремя свойствами:

• Собственные права. Доступ ограничен задачами интеграции.
• История использования. Журнал показывает, кто и когда получал учётные данные.
• Ротация без остановки интеграции. Ключ меняют централизованно, а система подхватывает новое значение.

Что обязательно должно быть у менеджера паролей для страховой компании

Менеджеру паролей для страховой компании нужны шесть функций: временный доступ для внешних пользователей, ролевая модель с типами сейфов, журнал аудита с экспортом в SIEM, клиентское шифрование zero-knowledge, сервисные аккаунты с API и офлайн-доступ.

Шесть обязательных функций

Какие риски закрывают эти функции

• Агентская сеть. Временный и одноразовый доступ.
• Данные о здоровье. Типы сейфов с обязательными администраторами и ролевая модель.
• Интеграция с АИС страхования. Сервисные аккаунты и API.

Журнал аудита и шифрование нужны любой компании, независимо от размера. ГОСТ Р 57580.1 предъявляет требования к защите информации и при минимальном, и при стандартном уровне защиты.

Журнал аудита и SIEM на оценке соответствия

На ежегодной оценке соответствия 757-П службе ИБ не нужно вручную собирать историю выдачи и отзыва доступа к каждой учётной записи. Журнал экспортируется в SIEM, и отчёт за нужный период выгружается готовым.

Офлайн-доступ для розничной сети

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

С чего начать внедрение

Порядок действий описан в пошаговом руководстве по внедрению менеджера паролей: от аудита текущего состояния паролей до распределения ролей и подключения интеграций.

Как Пассворк закрывает три сценария страховой компании

Пассворк — российский корпоративный менеджер паролей и секретов с размещением на сервере заказчика или в облаке. Он объединяет два решения в одном продукте: управление паролями сотрудников и управление секретами для интеграций и автоматизации (API-ключи, токены, учётные данные баз данных, сертификаты). Для страховой компании Пассворк закрывает все три сценария: доступ агентов и подрядчиков, защиту учётных данных к системам с данными о здоровье и интеграцию с АИС страхования.

Доступ агентов и подрядчиков

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

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

Данные о здоровье в ДМС и страховании жизни

Типы сейфов с обязательными администраторами разделяют доступ к данным ДМС и страхования жизни и остальной клиентской базе: сейф получает список сотрудников, которым доступ нужен по роли, и администратора, который контролирует состав этого списка.

Ролевая модель (RBAC) опирается на роли и группы: сотрудник попадает в нужную группу один раз и получает доступ ко всем сейфам, связанным с его задачами, без настройки прав на каждую запись. Роли определяют доступ пользователей к управлению и администрированию. Клиентское шифрование нулевого знания (zero-knowledge) выполняется на устройстве сотрудника до отправки на сервер, сервер хранит только шифротекст.

Интеграция и передача данных регулятору

Для интеграции с внешними системами Пассворк предлагает сервисные аккаунты со своими правами вместо одного общего пароля на нескольких сотрудников. Несколько токенов одного аккаунта можно выдать под разные интеграции и ротировать их по отдельности, не останавливая сам процесс передачи данных. Секреты доступны через REST API, CLI и Python SDK, поэтому скрипты и CI/CD-конвейеры получают их из хранилища, а не из конфигурационных файлов.

Офлайн-доступ

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

Сертификация

Пассворк сертифицирован ФСТЭК (№ 5063, 4-й уровень доверия), включён в реестр российского программного обеспечения (запись № 6147) и имеет лицензии ФСТЭК и ФСБ на работу с криптографией.

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

Три риска определяют выбор менеджера паролей для страховой компании

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

Каждый сценарий предъявляет своё требование. Агентам и подрядчикам нужна выдача и отзыв доступа без передачи постоянного пароля. Данным ДМС и страхования жизни нужно разделение прав и отдельный администратор. Интеграциям нужны секреты с собственными правами и ротацией без остановки передачи данных. Инструмент, который сильнее в одном сценарии и слабее в другом, оставляет незакрытым риск, ради которого его выбирали.

Пассворк рассчитан на все три сценария сразу. Временные и одноразовые ссылки закрывают доступ агентов и подрядчиков. Типы сейфов с обязательными администраторами отделяют учётные данные к системам с данными ДМС от остальной клиентской базы. Сервисные аккаунты и токены заменяют общий пароль интеграции. Пароли сотрудников и секреты интеграций живут в одном продукте, под общей ролевой моделью и единым журналом аудита

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

Вопросы о менеджере паролей для страховых организаций

Обязателен ли менеджер паролей по 757-П для страховой компании?

Положение Банка России № 757-П не называет менеджер паролей напрямую. Оно требует обеспечить уровень защиты информации по ГОСТ Р 57580.1-2017, который включает контроль учётных данных, парольную политику и аудит доступа. Без централизованного управления паролями эти требования трудно выполнить и ещё труднее подтвердить на ежегодной оценке соответствия, которую проводят не позднее 10-го рабочего дня года.

Чем требования к страховым брокерам отличаются от требований к самим страховым организациям?

По Положению № 757-П страховые брокеры и общества взаимного страхования подпадают под минимальный уровень защиты информации — так же, как и страховые с активами менее 20 млрд руб. за последние 6 месяцев. Стандартный, более строгий уровень действует для страховых организаций, чьи активы превышают этот порог. Набор технических мер при этом опирается на один и тот же ГОСТ Р 57580.1-2017.

Нужно ли по-другому защищать данные о здоровье клиентов в ДМС?

Да. Статья 10 Федерального закона № 152-ФЗ относит сведения о состоянии здоровья к специальной категории персональных данных с повышенными требованиями к защите и отдельным согласием на обработку. В ДМС и страховании жизни эти данные хранятся как часть страхового случая. На практике это означает разграничение доступа по типам сейфов и ролям вместо общего доступа всех сотрудников к базе ДМС.

Как передать доступ агенту без риска, что пароль останется у него после увольнения?

Через временный или одноразовый доступ к записи вместо выдачи постоянного пароля. Доступ формируется на ограниченный срок или число обращений и отзывается централизованно одним действием, без смены пароля для остальных пользователей записи. После отзыва ссылка просто перестаёт работать, независимо от того, успел агент сохранить её где-то ещё.

Менеджер паролей для медицины: защита данных и 152-ФЗ

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

Блог ПассворкаИлья Шелыгин

Теневой ИИ: как сотрудники сливают данные в нейросети

Сотрудник вставляет строку подключения к базе в ChatGPT, чтобы разобраться с ошибкой. Через месяц туда же уходит клиентская база и финансовый отчёт. Разбираем, как теневой ИИ проникает в компании и что делать раньше звонка из Роскомнадзора.

Блог ПассворкаИлья Шелыгин

Кейс-стади: МТС Банк и Пассворк

Как МТС Банк объединил управление паролями в единой системе с помощью Пассворка и повысил уровень безопасности.

Блог ПассворкаАнастасия Лебедева