Финансы и банки

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

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

Рисков за год стало больше. По данным InfoWatch, в российских финансовых организациях зафиксировано 44 утечки против 29 годом ранее, и рост дали в основном небольшие микрофинансовые организации (МФО) и страховые компании. С 2027 года требования к ним растут: страховые организации переходят на стандартный уровень защиты, а МФО впервые попадают в перечни уровней Положения № 757-П.

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

Нарушения со стороны сотрудников и кража учётных данных дают заметную долю инцидентов в российских финансовых организациях. По данным ГК «Солар» за 2025 год, 30% подтверждённых инцидентов связаны с нарушением сотрудниками политик безопасности, ещё 15% — с кражей учётных данных. В обоих случаях злоумышленнику или нарушителю нужен только действующий доступ.

Цифры за 2025 год

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

Регулятор отвечает на это мерами по управлению учётными записями и регистрации действий работников.

Какие документы Банка России задают требования к защите информации: банки и НФО

ГОСТ Р 57580.1-2017 сам не определяет, кто обязан его применять. Обязанность и уровень защиты устанавливают нормативные акты Банка России. Банки выполняют Положение № 851-П, некредитные финансовые организации (НФО) — Положение № 757-П. Изменения в 757-П из Указания № 7219-У вступают в силу 1 января 2027 года.

Что такое уровень защиты информации

Уровень защиты информации — это набор мер из ГОСТ Р 57580.1-2017, который организация обязана выполнять для своих информационных систем. Уровней три: минимальный (третий), стандартный (второй) и усиленный (первый).

Банки: Положение № 851-П

Положение Банка России от 30.01.2025 № 851-П зарегистрировано Минюстом России 06.03.2025 (№ 81462) и действует с 29.03.2025. Оно распространяется на кредитные организации (КО) и филиалы иностранных банков. Положение № 683-П утратило силу (п. 16 851-П).

Уровень защиты задаёт п. 3.1:

• Усиленный применяют системно значимые КО, КО — операторы услуг платёжной инфраструктуры системно значимых платёжных систем и КО, значимые на рынке платёжных услуг.
• Стандартный применяют остальные КО.
• Минимальный применяют филиалы иностранных банков до 31.12.2026, с 01.01.2027 они переходят на стандартный уровень (п. 15 851-П).

НФО: Положение № 757-П и изменения с 2027 года

Положение № 757-П от 20.04.2021 зарегистрировано Минюстом России 15.06.2021 (№ 63880) и заменило Положение № 684-П (п. 4.5 757-П). Оно распространяется на НФО из перечней пп. 1.4.2–1.4.4: страховые организации, НПФ, профессиональных участников рынка ценных бумаг и другие. МФО войдут в перечень с 01.01.2027.

Указание № 7219-У от 28.10.2025 (зарегистрировано Минюстом России 06.02.2026, № 85262) вступает в силу 01.01.2027. До этой даты действует текущая редакция 757-П. После неё:

• Страховые организации, НПФ и регистраторы входят в перечень стандартного уровня (пп. 1.4.3 в новой редакции).
• МФО входят в перечень минимального уровня (пп. 1.4.4): с 01.01.2027 — большинство МФО, с 01.01.2028 — все, включая МФО предпринимательского финансирования и МФО с государственным или муниципальным учредителем.

Остальные НФО распределены по уровням перечнями пп. 1.4.2–1.4.4.

Банк, совмещающий деятельность с НФО

Если банк совмещает деятельность с НФО и формирует для объектов информационной инфраструктуры один контур безопасности, он применяет наиболее высокий из требуемых уровней защиты (п. 3.1 851-П; п. 4.2 757-П в редакции 7219-У).

Сводка: какой документ и уровень применяются

Чем требования к банкам отличаются от требований к НФО

У банков и НФО общая основа, ГОСТ Р 57580.1-2017, но разные документы, наборы уровней, периодичность внешней оценки и сроки сообщения об инциденте. Банки подчиняются 851-П и проходят оценку не реже раза в два года. У НФО действует 757-П, и сроки зависят от уровня защиты.

Банку нужен журнал, который выдержит проверку раз в два года и обеспечит пятилетнее хранение данных о действиях работников. Страховой компании или НПФ к 2027 году потребуется сопоставимый уровень, хотя многие из них до сих пор работали на минимальном уровне без внешней оценки.

Минимальный уровень НФО отличается от стандартного: об инциденте сообщают в течение 24 часов, а обязанность проводить оценку соответствия по новому п. 1.5 757-П установлена только для усиленного и стандартного уровней.

Что изменится для НФО с 1 января 2027 года

С 1 января 2027 года Указание № 7219-У переводит страховые организации, НПФ и регистраторов на стандартный уровень защиты по ГОСТ Р 57580.1-2017 и включает МФО в Положение № 757-П на минимальном уровне.

Что меняется по существу

• Страховщики, НПФ и регистраторы получают стандартный уровень (пп. 1.4.3 757-П в новой редакции).
• Внешняя оценка. По сообщению Банка России, эти организации не реже раза в три года привлекают сторонних специалистов для проверки уровня защиты и оценивают программное обеспечение и приложения, в том числе клиентские.
• Сообщение об инциденте: 3 часа для усиленного и стандартного уровней, 24 часа для минимального.
• По сообщению Банка России, МФО должны применять антивирусные средства и регистрировать события защиты информации.» Ссылка на пресс-релиз ЦБ.

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

Чек-лист подготовки к 01.01.2027 (5 шагов):

1. Инвентаризация учётных записей. Определите, в каких системах работают сотрудники и у каких записей нет владельца.
2. Отказ от групповых учётных записей. У каждого сотрудника личная запись. Общие доступы выдавайте через права на хранилище, а не пересылкой паролей по почте и в чатах.
3. Ролевая модель. Привяжите права к роли и группе каталога.
4. Журнал аудита с выгрузкой в SIEM. Фиксируйте входы и изменения прав. Срок хранения задаёт политика организации.
5. Многофакторная аутентификация. Сначала для администраторов, затем для всех с доступом к критичным системам.

Что ГОСТ Р 57580.1 требует от управления доступом: учётные записи и пароли

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

Карта мер: от требования ГОСТ Р 57580.1 к функциям менеджера паролей

Менеджер паролей закрывает часть мер процесса «Управление доступом», но не весь стандарт. Регистрация действий работников в автоматизированных банковских системах (п. 5.2.3 851-П) остаётся задачей самих систем: журнал менеджера паролей фиксирует обращения к учётным данным. Машинные секреты (API-ключи, токены) образуют отдельный контур, его разбирает материал об управлении секретами в финансовом секторе.

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

Как выбрать менеджер паролей для банка или НФО: 7 критериев под требования ЦБ

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

Проблемы с парольной политикой массовые. По данным Positive Technologies (результаты пентестов 2024–2025 годов, межотраслевая выборка), у 97% компаний нашли недостатки в её реализации, у 70% из них риск оценили как критический.

Чек-лист выбора менеджера паролей для финансовой организации (7 критериев)

1. Интеграция с AD/LDAP и SSO. Учётная запись, отключённая в каталоге, должна терять доступ к сейфам. Спросите поставщика, через какое время блокировка в Active Directory закрывает доступ.
2. Разделение обязанностей. Администратор системы технически не должен видеть содержимое личных сейфов сотрудников. На пилоте проверьте, может ли администратор прочитать личную запись.
3. Журнал аудита с экспортом в SIEM. Срок хранения журнала задаёт политика организации. Данные о действиях работников в автоматизированных системах банк хранит не менее пяти лет (п. 5.2.5 851-П), поэтому журнал менеджера паролей лучше выгружать во внешнее хранилище. Уточните формат событий и системы-получатели.
4. Шифрование на стороне клиента. ГОСТ или AES-256 и модель нулевого разглашения (zero-knowledge): сервер хранит только шифротекст, взлом сервера не раскрывает пароли. Узнайте, где генерируются ключи и что лежит на сервере.
5. Многофакторная аутентификация для входа. Обязательна для администраторов, на усиленном уровне нужна всем. Проверьте набор факторов: TOTP, ключи доступа, биометрия, вход через SSO.
6. Модель размещения и устойчивость. Собственный сервер в закрытом контуре или облако, отказоустойчивая конфигурация, резервные копии. Защищённость зависит от харденинга сервера: его размещают в защищённом сегменте и ограничивают административный доступ. Поддерживаемые конфигурации и харденинг должны быть описаны в документации.
7. Зрелость поставщика. Сертификат ФСТЭК, лицензии ФСТЭК и ФСБ, запись в реестре российского ПО, безопасная разработка, программа поиска уязвимостей.

Как Пассворк закрывает требования ЦБ к учётным данным в банке и НФО

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

Учётные записи и права

Пассворк подключается к SSO, Active Directory и LDAP: импортирует пользователей и группы, сопоставляет группы каталога с группами Пассворка и отзывает доступ, когда учётную запись отключают в каталоге

• Права. Назначаются через роли, политики сейфов и группы. Для сейфов можно назначить обязательных администраторов.
• Парольная политика. Длина, набор символов и срок действия задаются на уровне сейфа, папки или записи.
• Вход. Доступны двухфакторная аутентификация (TOTP, приложение «Пассворк 2ФА», биометрия, ключи доступа и аппаратные ключи) и SSO.

Эти функции отвечают строкам карты мер про уникальные записи, владельцев доступа, ролевую модель, парольную политику и MFA.

Аудит для оценки соответствия

Журнал хранит историю действий пользователей и изменений. События экспортируются в syslog, Event Viewer и SIEM. Панель безопасности показывает старые, слабые и скомпрометированные пароли с фильтрами по сейфам, папкам и пользователям. Это соответствует мерам по инвентаризации учётных записей и журналам аутентификации.

Доступ для подрядчиков

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

Секреты для приложений и интеграций

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

Хранение и размещение

Коробочная версия устанавливается на сервере заказчика, в том числе в изолированном контуре.

• Шифрование. ГОСТ или AES-256. Клиентское шифрование по модели нулевого разглашения (zero-knowledge) оставляет на сервере только шифротекст.
• Отказоустойчивость. Строится горизонтальным масштабированием серверов приложений и репликацией базы данных.
• Совместимость. Пассворк имеет официальные сертификаты совместимости с российскими платформами: операционными системами (РЕД ОС, Astra Linux, ОС «МСВСфера», ОС «Атлант», Альт Сервер, SelectOS), СУБД (Pangolin DB, Nexign Nord), службами каталогов и администрирования (MultiDirectory, РЕД АДМ), а также с решениями для привилегированного доступа и аутентификации (СКДПУ НТ, Аладдин JMS 4LX). Полный перечень приведён на странице сертификатов совместимости.

Пример из практики: МТС Банк

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

Сертификаты и границы применения

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

Заключение

База у банков и НФО одна, ГОСТ Р 57580.1-2017. Различаются документ, уровень защиты и периодичность внешней оценки. С 2027 года страховые организации, НПФ и регистраторы переходят на стандартный уровень, и разрыв с банками сокращается. Меры управления доступом без единого учёта учётных данных подтвердить трудно.

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

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

Часто задаваемые вопросы

Какое положение ЦБ действует для банков вместо 683-П?

С 29 марта 2025 года требования к защите информации кредитных организаций устанавливает Положение Банка России № 851-П от 30.01.2025. Положение № 683-П утратило силу (п. 16 851-П). Уровень защиты по-прежнему задаётся по ГОСТ Р 57580.1-2017: усиленный или стандартный, в зависимости от типа кредитной организации.

Что меняется для страховых компаний и НПФ с 1 января 2027 года?

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

Как часто банк и НФО проходят оценку соответствия по ГОСТ Р 57580.2?

Банк проходит оценку не реже одного раза в два года с привлечением проверяющей организации, уровень соответствия не ниже четвёртого (пп. 13.2–13.4 851-П). НФО усиленного уровня оценивают соответствие не реже раза в год, стандартного уровня — не реже раза в три года (п. 1.5.3 757-П).

Обязан ли банк использовать менеджер паролей по требованиям ЦБ?

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

Что показать проверяющей организации по учётным данным?

Список пользователей и их прав на записи, матрицу ролей, настройки парольной политики и многофакторной аутентификации, выгрузку журнала за период проверки и отчёт по старым и слабым паролям. Точный набор зависит от методики ГОСТ Р 57580.2-2018 и договорённостей с проверяющей организацией.

Расширенная версия Пассворка: что входит и чем отличается

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

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

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

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

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

Пассворк: как разделить контуры ИБ и бизнеса

ИБ-секреты отличаются от обычных корпоративных доступов: компрометация пароля от SIEM — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

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

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

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

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

Главное

1. Требования. Положение Банка России № 757-П распространяется на всех субъектов страхового дела: страховые организации, страховых брокеров и общества взаимного страхования (ОВС). Уровень защиты зависит от суммы активов за последние шесть месяцев: свыше 20 млрд руб. — стандартный, остальные — минимальный. С 1 января 2027 года, по Указанию Банка России № 7219-У, стандартный уровень станет обязательным для всех страховых организаций независимо от активов.
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-П детализирует эту обязанность: задаёт технические требования и уровни защиты.

Положение № 757-П издано на основании ст. 76.4-1 Федерального закона № 86-ФЗ „О Центральном банке Российской Федерации“ и задаёт технические требования и уровни защиты. Конкретных инструментов положение не называет, выбор средств остаётся за организацией. Но ГОСТ Р 57580.1 требует управлять учётными записями, применять парольную политику и вести аудит доступа. В таблицах Excel это не выполнить: в них нет истории действий и разграничения прав на уровне записи, а доступ нельзя быстро отозвать. Эти меры закрывают централизованным хранилищем учётных данных с ролевой моделью и журналом аудита.

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

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

За нарушение требований к защите информации, установленных законами и нормативными актами, ч. 6 ст. 13.12 КоАП РФ предусматривает штраф для юридических лиц от 50 000 до 100 000 руб. (в редакции закона № 104-ФЗ от 23.05.2025). Кроме того, за несоблюдение требований Банк России вправе применить меры надзорного реагирования.

Что изменится с 1 января 2027 года

С 1 января 2027 года вступает в силу Указание Банка России № 7219-У. Оно включает все страховые организации в перечень организаций стандартного уровня защиты, поэтому порог в 20 млрд руб. активов для них перестанет действовать. Для организаций стандартного уровня это означает:

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

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

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

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

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

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

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

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

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

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

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. С 1 января 2027 года порог по активам для страховых организаций перестаёт действовать: все они переходят на стандартный уровень (Указание № 7219-У).

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

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

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

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

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

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

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

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

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

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

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

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

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

В 2025 году Россия заняла второе место в мире по количеству ставших известными утечек данных. Глобально количество утечек из банков и финансовых организаций сократилось на 44,7%, однако в России выросло в 1,5 раза. По данным отчёта InfoWatch, эта тревожная тенденция подчёркивает, что отечественный финансовый сектор остаётся приоритетной целью для киберпреступников.

Разница видна и в природе инцидентов. В мире на внутренних нарушителей приходится 4,5% утечек в финансовом секторе — в России эта доля почти втрое выше и составляет около 16%. Схожая картина по содержимому утекших данных: более 13% утечек в мире и около 10% в России содержат аутентификационную информацию: логины, пароли и ключи доступа.

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

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

Разбираемся, почему банки, финтех-компании и страховые организации стали приоритетной целью атак, что скрывается за неконтролируемым распространением секретов (secrets sprawl), как устроен жизненный цикл секрета и что требуют российские регуляторы от финансового сектора в 2026 году.

Главное об управлении секретами в финансовом секторе

• В 2025 году Россия заняла второе место в мире по числу известных утечек данных: количество инцидентов в финансовом секторе выросло в 1,5 раза, тогда как глобально сократилось на 44,7%.
• В российском финансовом секторе на внутренних нарушителей приходится около 16% утечек — почти втрое больше среднемирового показателя (4,5%), что делает контроль доступа сотрудников критичным.
• Управление секретами контролирует машинные учётные данные: API-ключи, токены, сертификаты, — тогда как менеджер паролей отвечает за доступ сотрудников к ресурсам. Финансовым организациям нужны оба контура.
• Инфраструктура банка объединяет десятки систем (процессинг, CRM, платёжные шлюзы), и каждая связь защищена отдельным ключом. Один забытый API-ключ платёжного шлюза способен открыть доступ к базе транзакций целиком.
• Неконтролируемое распространение секретов — бесконтрольное распространение секретов по репозиториям, конфигурациям и мессенджерам — превращает забытый ключ в системный риск: 64% секретов, утёкших в 2022 году, остаются действующими в 2026-м.
• Радиус поражения одного скомпрометированного ключа в банковской инфраструктуре может охватить всю цепочку обработки транзакций — от проверки баланса до персональных данных клиентов.
• С 30 мая 2025 года повторное нарушение в обработке персональных данных грозит штрафом до 3% годовой выручки — до 500 млн рублей, что делает управление секретами не только вопросом безопасности, но и финансовым риском.

Что такое управление секретами и чем оно отличается от паролей

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

Разница в архитектуре:

• Менеджер паролей встраивается в рабочий процесс человека: браузерное расширение, мобильное приложение, единое хранилище для команды.
• Система управления секретами встраивается в инфраструктуру: API, CI/CD-пайплайн, оркестратор контейнеров. Она должна выдавать секрет сервису за миллисекунды, без участия человека, и автоматически менять его по расписанию.

Сравнение менеджера паролей и системы управления секретами:

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

Пассворк объединяет управление паролями сотрудников и машинными секретами в одной экосистеме — с общим журналом аудита, едиными правами доступа и API для интеграции с CI/CD. Пассворк включён в реестр отчественного ПО и сертифицирован ФСТЭК. Протестировать можно бесплатно.

Почему финансовый сектор — главная мишень

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

Отраслевая аналитика детализирует, откуда берутся эти уязвимости:

• Рост утечек. В 2025 году число утечек данных из российских финансовых организаций достигло 44 — против 29 годом ранее. Рост на 52% за год (InfoWatch).
• Охота за данными. Каждый пятый инцидент в финансовом секторе — попытка получить доступ к конфиденциальной информации.
• Кража учётных данных. 15% инцидентов — прямая компрометация логинов и паролей сотрудников.
• Инструмент атак. Стилеры — вредоносное программное обеспечение (ВПО) для кражи паролей и токенов из браузеров и приложений — используются в 41% всех атак с применением ВПО на кредитно-финансовую отрасль (Солар, отчёт о кибератаках на кредитно-финансовую отрасль).

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

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

Неконтролируемое распространение секретов: невидимая угроза для финансовых организаций

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

Типичный сценарий выглядит так:

1. Тестирование интеграции. Разработчик финтех-компании тестирует интеграцию с платёжным шлюзом.
2. Ключ в коде. Для скорости вставляет API-ключ прямо в код, а не в защищённое хранилище.
3. Пропущенный шаг. Забывает удалить ключ перед публикацией.
4. Публикация в репозиторий. Сохраняет изменения в репозитории.
5. Ключ остаётся навсегда. Даже после удаления строки из актуальной версии кода ключ доступен в истории репозитория — история версий хранит все прошлые состояния файла.

Масштаб проблемы подтверждают международные данные. По данным отчёта GitGuardian State of Secrets Sprawl (2025), более 90% секретов, случайно опубликованных в публичных репозиториях, остаются валидными и пригодными для использования спустя 5 дней после утечки. Это означает, что даже обнаруженная утечка секрета не гарантирует его немедленной нейтрализации, если процесс отзыва не автоматизирован.

Мировая статистика утечек секретов: отчёт GitGuardian за 2026 год

Для финансовой организации неконтролируемое распространение секретов (secrets sprawl) означает, что каждый репозиторий, каждый CI/CD-пайплайн и каждая переменная окружения — потенциальная точка утечки, независимо от того, насколько защищён периметр. Централизованное хранилище — единственный способ вернуть контроль над рассредоточенными данными.

Жизненный цикл секрета: где возникают уязвимости

Жизненный цикл секрета — это последовательность из семи этапов, от генерации до уничтожения, на каждом из которых секрет может быть скомпрометирован. Понимание этой последовательности показывает, что защита секрета — это процесс, требующий контроля на каждой стадии, а не только в момент хранения. Такой подход к классификации этапов описывает, в частности, OWASP Secrets Management Cheat Sheet.

7 этапов жизненного цикла секрета:

• Генерация. Создание секрета с достаточной энтропией. Слабый или предсказуемый ключ компрометируется ещё до первого использования.
• Хранение. Размещение в централизованном зашифрованном хранилище, а не в открытом файле или переменной окружения без контроля доступа.
• Распределение. Передача секрета сервису или сотруднику только через защищённый канал: API вызов, а не сообщение в мессенджере.
• Контроль доступа. Привязка к идентичности рабочей нагрузки: сервис получает секрет на ограниченное время и только в контексте конкретного окружения (под, контейнер, задача в конвейере).
• Ротация. Плановая или экстренная смена секрета по расписанию либо сразу после подозрения на компрометацию.
• Отзыв. Немедленная инвалидация скомпрометированного секрета без ожидания планового цикла ротации.
• Уничтожение. Безвозвратное удаление секрета после истечения срока действия или завершения его использования.

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

Финансовая организация в условиях кадрового дефицита на рынке ИТ (за 2025 год штат ИТ-специалистов в России вырос на 15,4%, но нехватка кадров всё ещё оценивается в миллионах) активно привлекает подрядчиков и внешних разработчиков. Без автоматизации ротации отзыв доступа при завершении контракта требует ручной проверки всех систем, в которых подрядчик мог оставить след.

Радиус поражения: что происходит, когда один секрет скомпрометирован

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

Рассмотрим типичный сценарий:

1. Компрометация ключа. Скомпрометирован API-ключ одного микросервиса, отвечающего за проверку баланса.
2. Избыточные привилегии. Ключ выдан с избыточными правами — злоумышленник получает доступ не только к функции проверки баланса, но и к базе транзакций целиком.
3. Горизонтальное перемещение. Через доступ к базе транзакций атакующий находит учётные данные другого сервиса.
4. Расширение доступа. Через скомпрометированный сервис атакующий получает доступ к персональным данным клиентов.

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

• Принцип минимальных привилегий. Каждый сервис получает доступ только к тем ресурсам, которые нужны для его конкретной функции, а не ко всей базе данных.
• Регулярная ротация секретов. Короткий срок жизни ключа сокращает окно для атаки. API-токены сервисных аккаунтов в Пассворке можно ротировать через пары access- и refresh-токенов.
• Изоляция секретов друг от друга. Компрометация одного секрета не открывает доступ к остальным. В Пассворке каждый пароль и сейф получают собственный ключ шифрования, вложенные друг в друга по цепочке: ключ пароля → ключ сейфа → приватный ключ пользователя.
• Точечный отзыв без цепной реакции. Администратор аннулирует конкретный секрет, не трогая остальные учётные данные. Сервисные аккаунты Пассворка поддерживают несколько API-токенов — можно отозвать один, не нарушив работу остальных пайплайнов.
• Журнал доступа. Аномалия видна сразу, а не через неделю в постмортеме. Журнал действий Пассворка фиксирует каждое обращение к сейфам и паролям, с экспортом в SIEM для встраивания в существующий мониторинг.

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

Регуляторные требования РФ: что обязан выполнить финансовый сектор

Регулятор в лице Центрального банка и ФСТЭК России предъявляет к финансовым организациям конкретные требования по контролю доступа к учётным данным, которые напрямую касаются управления секретами. Основные документы — ГОСТ Р 57580.1-2017, Положение ЦБ РФ № 851-П и Приказ ФСТЭК России № 21, каждый из которых регулирует свой аспект защиты.

Ключевые нормативные акты для финансового сектора

Что требует каждый документ

ГОСТ Р 57580.1-2017 обязывает выстраивать защиту по одному из трёх уровней (минимальному, стандартному или усиленному) в зависимости от значимости системы. Контроль доступа к учётным данным входит в базовый набор мер для каждого уровня без исключений.

Положение ЦБ РФ № 851-П действует с 29 марта 2025 года — оно заменило ранее действовавшее Положение № 683-П и усилило требования к защите банковской информации, включая порядок применения сертифицированных средств криптографической защиты (СКЗИ).

Приказ ФСТЭК России № 21 определяет организационные и технические меры защиты персональных данных — документ прямо применим к банкам как операторам персональных данных клиентов. Два раздела касаются управления секретами напрямую:

• ИАФ (идентификация и аутентификация) — требует присвоения уникальных идентификаторов учётным записям и управления их жизненным циклом.
• УПД (управление доступом) — требует своевременного отзыва прав при увольнении или смене должности сотрудника.

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

Финансовые последствия несоблюдения

С 30 мая 2025 года в России действуют оборотные штрафы за нарушения в сфере обработки персональных данных. За повторное нарушение штраф для юридических лиц составляет от 1 до 3% годовой выручки — не менее 20 млн и не более 500 млн рублей.

5 практик управления секретами для финансовых организаций

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

• Централизуйте хранение. Замените файлы .env, таблицы Excel и заметки на единое зашифрованное хранилище секретов с контролем доступа. Это первый шаг, который сразу закрывает большую часть проблемы неконтролируемого распространения секретов.
• Автоматизируйте ротацию. Настройте плановую смену секретов по расписанию и немедленную ротацию при подозрении на компрометацию — без ручного вмешательства администратора в каждом отдельном случае.
• Внедрите принцип минимальных привилегий. Каждый сервис и каждый сотрудник должны видеть только те секреты, которые нужны для их конкретной задачи, — это напрямую ограничивает радиус поражения при инциденте.
• Ведите полный аудит. Фиксируйте, кто, когда и откуда обращался к каждому секрету. Журнал аудита — то, что превращает расследование инцидента из недель в часы.
• Интегрируйте управление секретами в DevSecOps. Секреты не должны попадать в код и конфигурации CI/CD — используйте API для их динамической выдачи прямо в момент сборки или деплоя.

Для финансовых организаций, эти пять практик реализует Пассворк — система, включённая в реестр отечественного ПО (№ 6147) и сертифицированная ФСТЭК России. Открытый полнофункциональный API позволяет встроить хранилище в CI/CD-пайплайн и получать секреты программно, без ручной передачи ключей между разработчиками.

Заключение

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

Практический первый шаг — провести инвентаризацию: собрать список всех секретов в инфраструктуре, определить, где они хранятся сейчас, и сравнить результат с требованиями ГОСТ 57580 и Положения 851-П. Разрыв между текущим состоянием и регуляторными требованиями обычно и определяет приоритеты внедрения.

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

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

Для финансовых организаций, которым важно соответствие российскому регулированию, Пассворк предлагает отечественное решение с сертификатом ФСТЭК и включением в реестр отечественного ПО.

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

Частые вопросы об управлении секретами в финансовом секторе

Чем управление секретами отличается от управления паролями?

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

Что такое неконтролируемое распространение секретов (secrets sprawl)?

Неконтролируемое распространение секретов (Secrets sprawl) — бесконтрольное распространение секретов по репозиториям, конфигурационным файлам, переменным окружения и мессенджерам. Организация теряет представление о том, где хранятся секреты и кто имеет к ним доступ, что резко увеличивает поверхность атаки и затрудняет расследование инцидентов при компрометации.

Какие этапы жизненного цикла секрета наиболее уязвимы?

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

Сколько времени скомпрометированный секрет остаётся действующим, если его не отозвать вручную?

По данным отчёта GitGuardian State of Secrets Sprawl (2025), более 90% секретов, случайно опубликованных в публичных репозиториях, остаются валидными спустя пять дней после утечки. Без автоматического отзыва обнаружение инцидента не гарантирует нейтрализации риска — ключ продолжает работать, пока его не аннулируют вручную.

Что произойдёт, если один API-ключ банка будет скомпрометирован?

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

Нужно ли управление секретами небольшим финтех-компаниям?

Да. По данным InfoWatch (2026), рост утечек в 2025 году произошёл в том числе в небольших МФО и страховых компаниях. Злоумышленники нередко атакуют менее защищённые организации как промежуточную точку входа для последующей атаки на более крупных партнёров или клиентов.

Соответствует ли Пассворк требованиям российских регуляторов для финансового сектора?

Да. Пассворк включён в реестр отечественного ПО (№ 6147) и сертифицирован ФСТЭК России, что упрощает соответствие требованиям Приказа № 21 и Положения ЦБ РФ № 851-П. Продукт объединяет пароли сотрудников и машинные секреты в едином хранилище с журналом аудита и API для интеграции с CI/CD.

Интерактивная схема API: сравнение версий и готовые примеры

В документации Пассворка появилась интерактивная схема API. Она показывает структуру запросов, сравнивает версии спецификаций и генерирует готовый код. Инструмент помогает собрать нужный запрос и проверить совместимость скриптов без разворачивания тестового стенда.

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

Постквантовая криптография: угрозы и стандарты — 2026

Квантовые компьютеры ещё не взломали ни одного шифра, но атаки уже идут. Разбираем HNDL-угрозу, глобальные дедлайны регуляторов, российские алгоритмы-кандидаты и первые промышленные пилоты QKD в России.

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

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

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

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

МТС Банк — один из крупнейших цифровых коммерческих банков России, который уже более 30 лет помогает компаниям и частным лицам управлять своими финансами. МТС Банк входит в топ-30 крупнейших банковских учреждений страны по активам и обслуживает более 3,8 миллионов клиентов по всей стране. Банк занимает шестое место в России по величине портфеля кредитных карт и четырнадцатое место по вкладам населения.

Являясь частью экосистемы МТС, Банк активно создаёт и внедряет передовые технологии и цифровые решения. В 2024 году приложение МТС Банка было признано лучшим в RuStore, а само финансовое учреждение получило множество наград — премию СХ WORLD AWARDS за лучший клиентский опыт в премиальном сегменте и FINAWARD за инновационные продукты. Кроме того, банк стал победителем международной премии Eventiada Awards за корпоративный проект в сфере здорового образа жизни сотрудников, демонстрируя заботу не только о клиентах, но и о своей команде.

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

Задача: централизовать управление паролями и исключить риски

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

«У каждого подразделения был свой менеджер паролей, серверный или локальный. Хотели прийти к чему-то общему, чтобы для всего банка это было единственное целевое решение», — команда МТС Банка

Компания искала решение, которое:

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

Банку требовался сервис, который объединит рабочие процессы всех отделов, позволит выстроить прозрачную систему управления доступами и обеспечит надёжное хранение паролей.

Выбор надёжного менеджера паролей

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

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

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

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

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

Построение отказоустойчивой инфраструктуры

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

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

«Мы выбрали трёхуровневую архитектуру для надёжности и масштабируемости системы: балансировщики, серверы приложений и баз данных, а также арбитр для максимальной защиты наших данных»

Все компоненты системы были развёрнуты в виртуальной среде под управлением российской операционной системы РЕД ОС, в соответствии со стратегией импортозамещения. Построение сложной архитектуры происходило поэтапно:

1. Во время тестирования использовали упрощённую конфигурацию с одной базой данных
2. Систему постепенно масштабировали до полноценной отказоустойчивой конфигурации по запросу ИТ-архитекторов банка
3. Чтобы быстро восстановить работу системы в случае сбоя, настроили резервное копирование
4. Подключили LDAP для централизованного управления пользователями на основе службы каталогов Active Directory
5. Для дополнительной защиты учётных записей включили обязательную двухфакторную аутентификацию (2FA) для всех сотрудников

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

Организация работы с данными в Пассворке

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

• Четыре сотрудника являются администраторами системы с правом на изменение системных настроек
• Для сотрудников первой линии технической поддержки создали роль с минимальными правами: доступны изменение адреса электронной почты пользователей и сброс 2FA при необходимости
• Учётные записи технических специалистов интегрированы с API для автоматизации рутинных задач

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

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

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

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

Результат: безопасность и эффективность рабочих процессов

С помощью Пассворка МТС Банк выстроил современную систему управления паролями и конфиденциальной информацией. Все процессы работы с критическими данными объединены в единой платформе под контролем ИБ-отдела.

«Пассворк — это не только личное хранение, но и централизованное управление, и возможность передачи секретов»

Единое пространство для хранения данных

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

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

Архитектура Пассворка позволяет исключить доступ администраторов к личным сейфам пользователей. Это снижает риски для специалистов ИБ и защищает как данные, так и сотрудников, которые с ними работают.

Импортозамещение и соответствие требованиям

Пассворк входит в реестр российского ПО, имеет лицензии ФСТЭК и ФСБ, гарантирует соблюдение стандартов безопасности финансовой отрасли и полностью соответствует политике Банка России по импортозамещению.

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

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

Nexign: как Пассворк упростил управление паролями

Введение АО «Нэксайн» (Nexign) — российская компания с 33-летним опытом разработки высокотехнологичных enterprise-решений для различных отраслей экономики. Готовые продукты и решения Nexign обеспечивают быструю ИТ-трансформацию клиентов, чтобы крупный бизнес мог решать задачи в кратчайшие сроки с уверенностью в результате. В портфеле компании более 150 успешно выполненных проектов в 12 странах мира.

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

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

Пассворк стал лучшим решением для работы с паролями по версии ComNews. Оценивалась архитектура безопасности и удобство работы для ИТ-команд.

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

Python-коннектор 0.1.5: управление секретами в DevOps и CI/CD

Новая версия Python-коннектора 0.1.5 расширяет возможности CLI-утилиты. Мы добавили команды, которые решают ключевые задачи DevOps-инженеров и разработчиков — безопасное получение и обновление секретов в автоматизированных пайплайнах. Почему это важно Секреты, API-ключи, токены и пароли баз данных нельзя хранить в коде — это риск утечки. Ручное обновление замедляет процессы и провоцирует

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