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

Программа-вымогатель (ransomware) — не просто вирус. За последние пять лет они превратились в индустрию с разделением труда, арендой вредоносного ПО и рынком готового доступа в корпоративную инфраструктуру. Технический порог входа в этот «бизнес» обнулился: инструменты арендуются, а доступ покупается.

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

Главное о программах-вымогателях за 30 секунд

Ransomware — это индустрия: аренда вредоносного ПО (RaaS), рынок готового доступа (IAB) и профессиональные переговорщики. Защита строится на нескольких уровнях, а наименее закрытый из них — учётные данные.

1. Технический порог входа исчез — разработчик RaaS берёт 20–30% выкупа, а доступ в корпоративную сеть покупается у брокеров первоначального доступа (IAB) как готовый лот.
2. Число инцидентов с шифровальщиками в России выросло на 15%. Рекордный задокументированный выкуп — 500 млн рублей, типичные требования к малому и среднему бизнесу — от 240 тыс. до 4 млн рублей.
3. 15% атак — диверсионные: данные уничтожаются, ключа дешифровки нет изначально.
4. Основные векторы входа — вредоносный файл, который запускает сам сотрудник (66% инцидентов), и эксплуатация уязвимостей: её доля во втором полугодии 2025 года выросла с 5% до 31%. Чаще всего это N-day, когда патч уже вышел, но не установлен.
5. Три из ключевых векторов работают через компрометацию учётных данных.
6. У защитников есть окно для реакции — между проникновением и запуском шифрования проходит от 3 до 5 суток. При работающем мониторинге атакующего можно остановить.

Что такое программа-вымогатель

Программа-вымогатель (ransomware) — класс вредоносного ПО, который шифрует файлы или блокирует доступ к системе, а затем требует выкуп за восстановление. Первый задокументированный случай — PC Cyborg (также известный как AIDS Trojan) в 1989 году, распространявшийся на дискетах.

Взрывной рост атак начался в 2013 году: CryptoLocker применял RSA-2048 для шифрования и Bitcoin как анонимный канал оплаты. За 100 дней было заражено около 250 000 систем, собрано порядка $3 млн выкупа. Атакующие впервые доказали, что модель масштабируется.

Поворотная точка — WannaCry в мае 2017 года. Атака использовала эксплойт EternalBlue (инструмент АНБ США, утёкший через группу Shadow Brokers) и распространялась автоматически по локальным сетям без каких-либо действий пользователя. За трое суток: 230 000 систем в 150 странах, остановленные конвейеры Renault и Nissan, более 19 000 отменённых медицинских приёмов в больницах NHS Великобритании. Ущерб оценивается в $4–8 млрд.

Месяц спустя — NotPetya. Технически это вайпер под маскировкой шифровальщика: ключа дешифровки не существовало. Заражение распространялось через налоговый клиент M.E.Doc, поразив Maersk (~$300 млн ущерба), Merck (~$870 млн) и FedEx. Совокупный ущерб Белый дом оценил в более чем $10 млрд. NotPetya показал: часть атак создаётся не ради выкупа — ради уничтожения.

В конце 2019 года группировка Maze первой применила двойное вымогательство: данные похищались до шифрования. Если жертва восстанавливалась из резервных копий — её всё равно шантажировали публикацией файлов. Тактика стала отраслевым стандартом.

К 2026 году число атак вышло на новый максимум. Только в августе зафиксировано 1 073 инцидента — рост на 12% к июлю. В тройке наиболее активных группировок: Qilin (164 атрибуции), The Gentlemen (116) и Cl0p (89). Среди задокументированных жертв — Boston Dynamics и Manchester Airport Group (Infosecurity Magazine, август 2026).

Сегодня программа-вымогатель — уже не просто вирус-шифровальщик. Ransomware превратился в отрасль с разделением труда. Модель «вымогательское ПО как услуга» (Ransomware-as-a-Service, RaaS) позволяет арендовать вредоносное ПО без технической подготовки: разработчик берёт 20–30% выкупа, партнёр-атакующий — остальное. Появился отдельный рынок брокеров первоначального доступа (Initial Access Brokers, IAB) — посредников, продающих готовый доступ в корпоративные сети. Переговоры с жертвой ведут профессиональные команды.

Эволюция крупнейших инцидентов

Масштаб угрозы в России в 2025 году

В 2025 году атаки шифровальщиков на российские компании выросли на 15% к предыдущему году — данные F6 («Киберугрозы в России», 2025). Рост умеренный на фоне +44% в 2024-м, но статистика скрывает качественный сдвиг: выкупы стали крупнее, а 15% атак обходятся без ключа дешифровки вовсе.

Статистика атак (F6, 2025)

• +15% — рост числа инцидентов с шифровальщиками за 2025 год.
• 500 млн рублей (50 BTC) — рекордный выкуп, зафиксированный в инциденте CyberSec's.
• 240 тыс. — 4 млн рублей — типичный диапазон требований для МСБ.
• 15% атак — диверсионные: данные зашифрованы без ключа, восстановление невозможно даже после оплаты.

Наиболее уязвимые отрасли

По данным F6, производство, торговля и логистика формируют тройку лидеров:

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

Как работает программа-вымогатель: механика атаки

Этап 1: первоначальный доступ

Атакующий проникает в сеть через один из стандартных векторов:

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

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

Этап 2: закрепление и разведка

Получив точку входа, вредонос закрепляется в системе и начинает перемещаться вглубь сети. Для этого используются легитимные инструменты Windows: PsExec, WMI, PowerShell. Такой подход называют Living off the Land (LOTL, «жить за счёт ресурсов жертвы»): с точки зрения систем мониторинга это выглядит как обычная административная активность, а не атака. Параллельно атакующий выявляет ценные данные и системы резервного копирования — они будут зашифрованы или уничтожены первыми, чтобы лишить жертву возможности восстановиться без выкупа.

Этап 3: шифрование или кража данных

Файлы шифруются быстрым симметричным алгоритмом (AES-256 или ChaCha20). Ключ шифрования, в свою очередь, защищается публичным ключом атакующего (RSA или X25519) — это означает, что расшифровать файлы можно только с помощью закрытого ключа, который хранится исключительно у атакующей стороны. Параллельно или вместо шифрования данные выгружаются в инфраструктуру группировки для двойного вымогательства.

Этап 4: требование выкупа и переговоры

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

Стандартный ультиматум — 48–96 часов. При двойном вымогательстве данные публикуются на так называемом Leak-сайте — публичной странице группировки в даркнете, куда выкладываются документы жертв, отказавшихся платить. Публикация немедленно создаёт юридические риски: штрафы регуляторов, претензии клиентов, репутационный ущерб.

Отдельная разновидность — wiper-атака (от англ. wipe, «стереть»): вредонос не шифрует данные с целью получить выкуп, а уничтожает их безвозвратно. В 15% подобных инцидентов ключа расшифрования не существует изначально, цель атаки — разрушение инфраструктуры, а не деньги.

Векторы заражения: как ransomware попадает в сеть

По данным F6, ключевые векторы первоначального доступа:

Загрузка вредоносного ПО

Самый распространённый вектор — 66% инцидентов. Отправная точка почти всегда одна: пользователь сам запускает вредоносный файл — поддельное обновление ПО, пиратский инсталлятор, вложение из мессенджера или скрипт с фишингового сайта. Файл выступает дроппером: скачивает и разворачивает основной модуль атаки с командно-контрольного сервера (C2). Типичная цепочка: сотрудник → пиратский Word → Cobalt Strike beacon (инструмент скрытого удалённого управления) → шифровальщик.

Эксплойты уязвимостей

Во втором полугодии 2025 года доля этого вектора выросла с 5% до 31% — быстрее всех остальных. Причина: массовые незакрытые уязвимости в VPN-шлюзах, продуктах для удалённого доступа и веб-приложениях, доступных из интернета. Группировки применяют два типа: zero-day (патча ещё не существует) и N-day (патч уже выпущен, но не установлен). Второй случай — более распространённый: большинство взломов происходит через уязвимости, для которых обновление было доступно неделями или месяцами.

Фишинг и социальная инженерия

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

Компрометация учётных данных и брутфорс

Три пути: кража паролей стилерами (вредоносное ПО, которое незаметно собирает сохранённые пароли из браузеров и приложений), перебор слабых учётных записей на открытых RDP/VPN, подстановка учётных данных — автоматическая проверка пар логин–пароль из утечек сторонних сервисов на корпоративных ресурсах жертвы. Брутфорс остаётся одним из самых массовых векторов входа в инфраструктуру: слабый пароль — готовая точка входа.

Initial Access Brokers: рынок готового доступа

Брокеры первоначального доступа (IAB) — специализированные посредники, которые взламывают организации и выставляют полученный доступ на продажу в закрытых даркнет-форумах. Группировка-вымогатель покупает готовый лот с параметрами: тип доступа (VPN, RDP, веб-панель), отрасль жертвы, уровень привилегий, страна. Цена лота — от нескольких сотен до десятков тысяч долларов. Фактически это аутсорсинг первого этапа атаки: группировке не нужно самостоятельно взламывать периметр — достаточно выбрать жертву и купить готовый вход.

Виды программ-вымогателей

• Шифровальщик (encrypting ransomware) — классический тип. Вредонос шифрует файлы жертвы: они остаются на диске, но открыть их без ключа невозможно. Операционная система при этом продолжает работать.
• Блокировщик экрана (locker ransomware) — файлы не шифруются, но рабочий стол полностью заблокирован. В корпоративном секторе встречается редко. Основная цель — домашние пользователи.
• Двойное вымогательство (double extortion) — шифрование сочетается с предварительной кражей данных. Если жертва восстановила системы из резервных копий и отказалась платить, данные публикуются на сайте утечек в даркнете (Leak-сайте). Большинство крупных группировок работает именно по этой модели.
• Тройное вымогательство (triple extortion) — расширение предыдущей схемы: к шифрованию и угрозе публикации добавляется DDoS-атака на инфраструктуру жертвы или прямые угрозы её клиентам и деловым партнёрам.
• Вымогательство через угрозу утечки (leakware / doxware) — атакующие похищают данные, после чего предъявляют жертве доказательства кражи и требуют выкуп: заплатишь — данные уничтожим, откажешься — опубликуем. Шифрования нет: системы продолжают работать в штатном режиме, и у жертвы нет очевидного сигнала о произошедшем. Именно в этом ловушка — атаку можно обнаружить только по аномальному трафику, а не по заблокированным файлам. Тренд 2026 года: атаки без шифрования обходят системы защиты конечных точек (EDR — Endpoint Detection and Response), ориентированные на детектирование шифровальщиков (Securelist, 2026).
• Вайперы (wipers, от англ. wipe — «стереть») — маскируются под шифровальщики, но ключа расшифровки не существует в принципе. Цель — уничтожение данных и инфраструктуры. Применяются в диверсионных атаках — те самые 15% по данным F6.
• Программы-вымогатели как услуга (RaaS — Ransomware-as-a-Service) — не технический тип вредоноса, а бизнес-модель. Разработчик создаёт платформу и сдаёт её в аренду партнёрам-операторам, которые проводят атаки и делятся выкупом. Именно поэтому уровень технической подготовки атакующего перестал иметь значение.

Как защититься от программ-вымогателей (ransomware)

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

Уровень конечных точек (endpoint)

• Система обнаружения угроз на конечных точках (EDR) с поведенческим анализом обнаруживает атаки с использованием легитимных инструментов системы и пресекает шифрование файлов до завершения атаки.
• Управление обновлениями (patch management). Критические патчи — в течение 72 часов после выхода. Рост доли эксплойтов с 5% до 31% за полгода — прямое следствие незакрытых уязвимостей.
• Ограничение запуска программ. Запрет исполнения файлов из временных папок (%AppData%, %Temp%) и сетевых директорий.

Уровень сети

• Сегментация. Серверы автоматизированных систем управления технологическими процессами (АСУ ТП), системы резервного копирования и платёжная инфраструктура — в отдельных виртуальных сетях с явными правилами трафика.
• Запрет протокола удалённого рабочего стола наружу (RDP — Remote Desktop Protocol). Если удалённый доступ нужен — только через защищённый туннель (VPN) с многофакторной аутентификацией (MFA). Открытый порт 3389 — приглашение к перебору паролей (брутфорсу).
• Мониторинг сетевого трафика (NDR/NTA — Network Detection and Response / Network Traffic Analysis). Аномальные запросы к системе доменных имён (DNS), нетипичный трафик к внешним IP, горизонтальное перемещение по сети через протокол доступа к сетевым папкам (SMB) — видны на уровне сети раньше, чем на рабочих станциях.

Уровень учётных данных и доступа (identity)

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

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

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

Резервное копирование

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

• Правило 3-2-1: три копии данных, на двух разных типах носителей, одна из которых полностью отключена от сети. Физически изолированную копию или копию в неизменяемом хранилище нельзя ни зашифровать, ни удалить извне.
• Изоляция хранилища. Хранилище резервных копий не должно быть доступно с рабочих станций и с сервера управления корпоративной сетью (контроллера домена): атакующий, захвативший контроллер домена, автоматически получает доступ ко всему, что к нему подключено.
• Регулярный тест восстановления. Нетестированная резервная копия — это не защита. Только реальная проверка восстановления данных подтверждает, что копия рабочая.

Осведомлённость сотрудников

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

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

Threat Intelligence и мониторинг

Разведка угроз (Threat Intelligence) — это постоянное отслеживание признаков, по которым можно узнать конкретную группировку: IP-адреса её серверов, хеши вредоносных файлов, характерные домены. Если эти данные подключены к системе сбора и анализа событий безопасности (SIEM), она автоматически срабатывает, когда в сети появляется что-то похожее на поведение известных атакующих.

Среднее время от момента проникновения до активации шифровальщика — от 3 до 5 суток. Это и есть окно для реагирования: при работающем мониторинге команда безопасности может обнаружить атакующего и остановить его до того, как он нажмёт «зашифровать». Без мониторинга это окно проходит незаметно.

Что делать, если атака уже произошла: чеклист реагирования

Первые действия при обнаружении активного шифровальщика:

• Изолировать поражённые системы от сети — физически или через VLAN-запрет. Не ждать завершения анализа.
• Не перезагружать хосты — перезагрузка уничтожает криминалистические данные в оперативной памяти: активные процессы, сетевые соединения, фрагменты ключей шифрования.
• Уведомить команду реагирования и руководство — у инцидента должен быть ответственный немедленно.
• Задокументировать индикаторы компрометации (IOC) — хеши файлов, имена процессов, IP-адреса C2, следы LOTL-инструментов.
• Оценить охват и определить семейство вредоноса — какие хосты затронуты, к какой группировке и семейству программ-вымогателей относится атака: от этого зависит, есть ли публичный дешифратор (см. nomoreransom.org).
• Восстановление из изолированных бэкапов — только после полного удаления вредоноса с поражённых хостов, иначе повторное шифрование.
• Разбор инцидента (post-incident review) — определить вектор доступа, найти корневую причину, закрыть в течение 30 дней.
• Уведомить регулятора — для субъектов КИИ уведомление ФСБ и НКЦКИ обязательно по статье 9 Федерального закона № 187-ФЗ «О безопасности критической информационной инфраструктуры»; для операторов персональных данных — ФСТЭК и Роскомнадзор по требованиям 152-ФЗ.

Вывод

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

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

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

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

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

Что такое программа-вымогатель простыми словами?

Программа-вымогатель (ransomware) — вредоносное ПО, которое шифрует файлы жертвы и требует деньги за ключ расшифровки. Современные версии также похищают данные и угрожают их публикацией — это называют двойным вымогательством. Без ключа атакующего расшифровать данные практически невозможно.

Как ransomware попадает на компьютер?

Основной вектор в России — загрузка вредоносного ПО (66% инцидентов): поддельные обновления, пиратское ПО, вложения в письмах. К концу 2025 года доля эксплойтов уязвимостей выросла с 5% до 31% (F6, 2025). Брутфорс RDP и кража паролей — ещё два распространённых пути первоначального доступа.

Поможет ли антивирус защититься от шифровальщика?

Антивирус на основе сигнатур защищает от известных семейств шифровальщиков. Современные шифровальщики используют LOTL-тактику — легитимные инструменты Windows, которые сигнатурный антивирус не блокирует. Необходим EDR с поведенческим анализом, дополненный сегментацией сети и изолированными бэкапами.

Что такое двойное вымогательство?

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

Как быстро происходит шифрование после заражения?

Среднее время от первоначального доступа до активации шифровальщика — от 3 до 5 суток. Это окно для обнаружения и реагирования. SIEM с правилами корреляции по аномалиям LOTL позволяет зафиксировать атаку до шифрования.

Что такое RaaS?

Ransomware-as-a-Service (RaaS) — модель, при которой разработчик предоставляет вредоносное ПО и инфраструктуру аффилиатам-партнёрам. Партнёр проводит атаку, разработчик получает 20–30% выкупа. Это позволяет атаковать людям без технической подготовки и масштабирует число операций.

Что такое брутфорс (Brute Force): виды, угрозы и защита

В первом квартале 2025 года число брутфорс-атак на российские организации выросло в 2,7 раза. 48% паролей из реальных утечек взламываются за минуту. Разбираем 8 техник перебора, объясняем, чем ИИ изменил атаки, и даём конкретные меры защиты: от парольной политики до управления учётными записями.

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

Как создать надёжный пароль в 2026: новые требования, правила и примеры

73% российских компаний до сих пор пользуются паролем по умолчанию — притом что одна лишняя буква длины часто защищает больше, чем весь набор спецсимволов. Разбираем, что на этот счёт думают ФСТЭК, NIST и OWASP, и как быстро собрать пароль, который устроит всех.

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

Российский менеджер паролей: как выбрать решение для бизнеса

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

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

Российские компании Пассворк и МУЛЬТИФАКТОР протестировали и подтвердили совместимость менеджера паролей Пассворк и системы двухфакторной аутентификации и контроля доступа MULTIFACTOR.

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

Что это даёт заказчику

Компании, в которых сотрудники пользуются несколькими корпоративными сервисами, обычно накапливают разные механизмы входа. Эту проблему помогает решить MULTIFACTOR с SSO. Single Sign-On (SSO) — технология, которая позволяет пользователю пройти аутентификацию один раз и получить доступ ко всем подключённым сервисам.

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

О Пассворке

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

О MULTIFACTOR

MULTIFACTOR — система двухфакторной аутентификации и контроля доступа для всех видов удалённых подключений: RDP, VPN, VDI, SSH и других. Это инструмент для надёжной 2FA-аутентификации пользователей при доступе к любым корпоративным ресурсам с поддержкой технологии единого входа (SSO). Решение включено в реестр российского ПО под № 7046, имеет сертификат ФСТЭК № 5039.

Комментарии сторон

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

«Интеграция MULTIFACTOR и Пассворк показывает, как два российских продукта могут работать в одной экосистеме, усиливая друг друга. Пассворк помогает компаниям навести порядок в хранении и использовании паролей, а MULTIFACTOR гарантирует, что даже при утечке пароля злоумышленник не сможет войти в систему. Совместное использование этих решений создаёт полноценный защитный периметр», — Иван Дёмкин, руководитель продукта MULTIFACTOR, компания МУЛЬТИФАКТОР

О компании Пассворк

Пассворк — российский разработчик в сфере информационной безопасности с 11-летним опытом работы на рынке. Компания имеет действующие лицензии ФСТЭК России на деятельность по технической защите конфиденциальной информации (ТЗКИ) и созданию средств защиты информации (СЗКИ), а также лицензию ФСБ России на работу с криптографическими средствами.

О компании МУЛЬТИФАКТОР

МУЛЬТИФАКТОР — российский разработчик ИБ- и ИТ-решений. Создаёт продукты для безопасной и стабильной работы ИТ-инфраструктуры бизнеса. Компания является лицензиатом ФСТЭК и соответствует требованиям международного стандарта PCI DSS.

Продукты компании:

• MULTIFACTOR — комплексная система двухфакторной аутентификации и контроля доступа (включена в реестр российского ПО под № 7046, сертифицирована ФСТЭК России)
• MULTIDIRECTORY — служба каталогов (включена в реестр российского ПО под № 28333)
• MULTIPUSHED — инструмент для отправки пуш-сообщений на любые устройства и ОС
• MULTISTATUS — геораспределённый облачный сервис для веб-мониторинга и контроля сетевого периметра

Российский менеджер паролей: как выбрать решение для бизнеса

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

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

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

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

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

Пассворк совместим c JaCarta Management System 4LX

Компании Пассворк и Аладдин подтвердили совместимость своих продуктов: менеджера паролей Пассворк и корпоративной системы централизованного управления JaCarta Management System 4LX для Linux (JMS4LX).

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

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

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

Главное о выборе российского менеджера паролей за 30 секунд

«Российский» — проверяемый статус: запись в реестре Минцифры, сертификат ФСТЭК, лицензия ФСБ на криптографию, локализация данных в РФ, независимость от иностранной юрисдикции вендора.

1. Юридической обязанности нет, деловой риск есть — компаниям вне госсектора переход на российское решение не обязателен по закону, но зависимость от зарубежного продукта способна обернуться блокировкой доступа или остановкой обновлений без переходного периода.
2. Технические критерии обязательны в любом случае — RBAC, SSO, синхронизация с LDAP/AD, журнал аудита с выгрузкой в SIEM и клиентское шифрование нужны независимо от происхождения продукта.
3. Есть сигналы неготового решения — «российское» только в маркетинге без номера в реестре и сертификата, один общий ключ шифрования на всю компанию, плоская модель доступа «админ/пользователь», отсутствие журнала аудита или варианта развёртывания на своём сервере.
4. Перед покупкой стоит пройти чек-лист из 12 вопросов по пяти темам: реестр, шифрование, развёртывание, доступ, юрисдикция вендора. Ответы нужно сверять напрямую с реестром Минцифры и сертификатом ФСТЭК.
5. Пассворк закрывает оба слоя проверки — сертификат ФСТЭК № 5063, запись в реестре российского ПО № 6147, развёртывание на своём сервере или в облаке, интеграцию с LDAP/AD и SSO, браузерные расширения, мобильные и десктопные приложения, управление паролями и техническими секретами через REST API, CLI и Python SDK.

Почему бизнесу, а не только госсектору, стоит выбирать российское решение

Указ Президента РФ № 250 обязывает конкретный список организаций использовать сертифицированные и локализованные средства защиты информации: субъекты критической информационной инфраструктуры (КИИ), органы власти, государственные корпорации и системообразующие предприятия. Компании вне этого списка ничего не нарушают, оставаясь на зарубежном решении. Но у выбора инструмента для паролей есть деловая сторона, не связанная с юридической обязанностью.

• Первый аргумент — цена ошибки в парольной гигиене от статуса компании не зависит. По данным Информзащиты за 2026 год, украденные учётные данные используются как минимум на одном этапе более чем в 80% кибератак, а атаки, построенные на компрометации личности (краже, подборе или повторном использовании паролей, социальной инженерии), обеспечивают 65% первичных проникновений в инфраструктуру.
• Второй аргумент — требование о локализации персональных данных касается почти любой компании. Статья 18 часть 5 Федерального закона № 152-ФЗ «О персональных данных» обязывает хранить базы с персональными данными граждан РФ на серверах в России. Если в сейфах менеджера паролей хранятся логины, привязанные к конкретным сотрудникам или клиентам, эти записи подпадают под определение персональных данных.
• Третий аргумент — зависимость от зарубежного вендора. Такой сервис работает по правилам чужой юрисдикции: вендор может заблокировать учётную запись компании по собственному решению, а санкции — ограничить доступ независимо от его воли. Лицензия может прекратиться, а обновления и техподдержка остановиться без переходного периода. Для системы, которая хранит доступы ко всей инфраструктуре компании, это операционный риск того же порядка, что и утечка.
• Четвёртый аргумент — зависимость от иностранных законодательств. Американский CLOUD Act разрешает властям США требовать у любой компании под юрисдикцией США данные с серверов в любой точке мира. Закон FISA Section 702 даёт спецслужбам США основания для доступа к данным иностранных пользователей через американских провайдеров. В Евросоюзе NIS2 ужесточила требования к отчётности, а GDPR регулирует передачу данных за пределы ЕС. Российская компания на зарубежном сервисе зависит от требований этих норм, даже не находясь в их юрисдикции напрямую.
• Пятый аргумент — вклад в развитие российского рынка средств защиты информации. Деньги, которые компания платит российскому вендору, идут на доработку конкретного инструмента, которым пользуется компания. Чем больше клиентов у российских вендоров средств защиты информации, тем быстрее эти продукты закрывают функциональные разрывы с зарубежными аналогами, и тем меньше поводов у отрасли зависеть от решений, которые в любой момент могут перестать работать в России.

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

Что на самом деле делает менеджер паролей «российским»

Русскоязычный интерфейс и офис в Москве ничего не говорят о статусе продукта перед законом и перед регулятором. Чек-лист из 4 признаков российского менеджера паролей закрывает вопрос без догадок:

1. Запись в реестре российского ПО
2. Сертификация и лицензия
3. Локализация данных
4. Независимость от иностранной юрисдикции

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

Запись в реестре отечественного ПО

Единый реестр российского ПО ведёт Минцифры России на reestr.digital.gov.ru. Запись в реестре подтверждает происхождение кода и прав на него и даёт право на участие в закупках по 44-ФЗ и 223-ФЗ, где предусмотрены приоритеты для отечественного софта. Продукт, который позиционирует себя как российский, но не имеет записи в реестре, либо не прошёл эту проверку, либо не проходил её вовсе.

Сертификация ФСТЭК или лицензия ФСБ

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

Локализация и резидентность данных

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

Юрисдикция вендора и поддержки

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

Критерии выбора менеджера паролей

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

Безопасность и архитектура хранения

Управление доступом и интеграция с каталогами

Контроль, аудит и соответствие требованиям

Удобство использования и кроссплатформенность

Чек-лист вопросов вендору перед покупкой

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

Реестр и сертификация

• Под каким номером продукт числится в реестре российского ПО и как проверить эту запись самостоятельно на reestr.digital.gov.ru?
• Есть ли действующий сертификат ФСТЭК на продукт как средство защиты информации и для какого класса защищённости он выдан?

Шифрование и архитектура

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

Развёртывание и совместимость

• Где физически размещаются данные при облачном варианте, и есть ли коробочная установка на сервере заказчика для изолированного контура?
• С какими российскими ОС, СУБД и службами каталогов продукт совместим официально?
• Что происходит с доступом сотрудника при его увольнении: блокировка происходит автоматически через синхронизацию с LDAP или требует ручного действия администратора?

Доступ и аудит

• Насколько гранулярна ролевая модель — можно ли ограничить доступ на уровне отдельного сейфа или только на уровне всей базы?
• Ведётся ли журнал действий пользователей и можно ли выгрузить его в SIEM-систему при расследовании инцидента?

Поддержка и юрисдикция

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

Ответы стоит сверять с первоисточниками: реестром Минцифры и реестром сертифицированных СЗИ ФСТЭК. Фиксируйте ответы — в переписке или техническом задании, не полагайтесь на устные заверения. Номер сертификата и запись в реестре — проверяемые факты.

Когда менеджер паролей не готов для вашего бизнеса

Несколько сигналов говорят, что решение не готово к использованию в компании:

• «Российское» только в маркетинге. Название на кириллице, домен .ru и фраза «отечественная разработка» на сайте вендора не заменяют запись в реестре и сертификат. Если вендор не может назвать номер записи в реестре Минцифры или ссылается на «сертификацию в процессе оформления» — перед вами обещание, а не готовое решение.
• Юридический риск блокировки не проговорён. Вендор уходит от вопроса про юрисдикцию разработчика и структуру владения компанией. При смене санкционного режима заказчик узнает ответ на собственном опыте — в момент, когда изменить что-то уже нельзя.
• Нулевое знание (zero knowledge) заявлено, но не объяснено технически. На вопрос «где генерируются ключи шифрования» вендор отвечает общей фразой из презентации, а не архитектурной схемой с указанием, на каком устройстве создаётся ключ и куда он передаётся.
• Один ключ шифрования на всю организацию. Если компрометация одной учётной записи открывает доступ не к одному сейфу, а к зашифрованным данным всей компании — архитектура изначально не ограничивает ущерб от кражи пароля.
• Нет разграничения прав ниже уровня «администратор / пользователь». Для команды больше 15–20 человек плоская модель доступа снимает саму пользу от менеджера паролей: рано или поздно кто-то получит доступ к сейфу, который ему не нужен для работы.
• Нет журнала аудита или выгрузки в SIEM. Без истории действий расследование инцидента с учётной записью превращается в опрос сотрудников по памяти — без единого проверяемого факта, кто и когда открывал запись.
• Нет варианта размещения на своём сервере. Если вендор предлагает только облако без возможности развернуть систему в изолированном контуре, компания зависит от чужой инфраструктуры.
• Нет синхронизации с LDAP или Active Directory. Увольнение сотрудника требует, чтобы администратор вручную отозвал доступ в каждом сейфе. На практике это поле забывают, и доступ остаётся активным месяцами.

Как выбрать менеджер паролей под размер и контекст вашего бизнеса

Строгость критериев из предыдущих разделов стоит адаптировать под контекст компании: не всем нужен один и тот же уровень проверки.

Малый и средний бизнес

До сотни сотрудников достаточно подтвердить базовые признаки (реестр, шифрование, простую ролевую модель) и не тратить ресурс на глубокий комплаенс-аудит вендора. Приоритет — скорость внедрения и понятный интерфейс для сотрудников без ИТ-бэкграунда. Отдельного специалиста по безопасности в такой команде часто нет, и решение обычно принимает ИТ-руководитель самостоятельно, без формального тендера.

Крупный бизнес

От нескольких сотен пользователей критичны SSO, синхронизация с LDAP/Active Directory, детальная ролевая модель по подразделениям и экспорт журнала аудита в SIEM. Здесь имеет смысл пройти весь чек-лист вопросов вендору целиком и запросить документы напрямую: сертификат и выписку из реестра. Для компании с несколькими юридическими лицами или распределённой географией добавляется ещё один вопрос: поддерживает ли решение разграничение сейфов и прав между филиалами без потери централизованного аудита.

Регулируемая, но не критическая инфраструктура

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

Пассворк: как российский менеджер паролей закрывает эти критерии

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

Совместимость с российской инфраструктурой

Сертификаты совместимости подтверждают, что продукт протестирован и работает с конкретной операционной системой, СУБД или службой каталогов. Актуальный список опубликован на странице сертификатов совместимости.

Совместимость подтверждена с Astra Linux, РЕД ОС, Альт Сервер, SelectOS, МСВСфера, службой каталогов MultiDirectory, СУБД Pangolin DB и другими решениями на странице сертификатов. Список обновляется — сверяйте его перед принятием решения, а не по памяти из статьи.

Шифрование: два независимых слоя

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

Размещение — на выбор заказчика

Установка на сервере заказчика даёт полный контроль над данными, ключами и резервными копиями, вплоть до изолированного контура без выхода в интернет. Пассворк Облако — вариант для компаний без собственного сервера, где важна локализация данных на территории РФ (в инфраструктуре Yandex Cloud).

Доступ и аудит

Синхронизация с LDAP и Active Directory снимает ручное отключение доступа при увольнении сотрудника. SSO работает через SAML 2.0. Журнал аудита фиксирует действия пользователей и поддерживает выгрузку в SIEM-системы для расследования инцидентов. Панель безопасности помогает выявить риски компрометации.

Гранулярная ролевая модель: роли и группы

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

Настраиваемые типы сейфов

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

Удобство работы

Для повседневной работы есть браузерные расширения (Chrome, Firefox, Edge, Яндекс Браузер) с автозаполнением и мобильные приложения для двухфакторной аутентификации в Play Market, App Store и RuStore. Также есть нативное десктопное приложение на Windows, macOS и Linux с поддержкой биометрии и ключей доступа.

Управление секретами: одна система для пользователей и разработчиков

Пассворк закрывает две задачи одним решением: сотрудники работают с паролями через привычный интерфейс, а разработчики и DevOps-инженеры управляют техническими секретами (API-ключами, токенами облачных провайдеров, сертификатами, строками подключения к БД, SSH-ключами) через REST API, CLI-утилиту и Python SDK.

Простота масштабирования

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

Пошаговый план перехода на российский менеджер паролей

Для бизнеса без обязательной аттестации достаточно четырёх шагов:

1. Аудит текущего состояния. Соберите список мест, где сейчас лежат пароли (Excel, заметки, чаты, память сотрудников), и кто имеет к ним доступ. Без этого шага миграция превращается в перенос хаоса в новый инструмент.
2. Пилот на одной команде. Разверните решение для отдела с наибольшей плотностью критичных доступов, обычно ИТ или DevOps, и проверьте на практике SSO, синхронизацию с LDAP и удобство ежедневной работы, прежде чем тиражировать на компанию.
3. Миграция и раскатка. Перенесите пароли остальных отделов, настройте ролевую модель и группы под оргструктуру, обучите сотрудников базовым сценариям: создание записи, шеринг доступа, отзыв прав при увольнении.
4. Аудит после внедрения. Через один-два месяца проверьте, действительно ли пароли переехали из Excel и чатов в менеджер, а не продолжают жить параллельно.

Сроки зависят от размера компании: пилот на команде из 10–15 человек занимает одну-две недели, для компании в несколько сотен сотрудников миграция и раскатка растягиваются на один-два месяца. Переход требует организационной работы: обучения сотрудников и пересмотра процесса выдачи доступа подрядчикам.

Заключение

«Российское» применительно к менеджеру паролей — это четыре проверяемых признака: запись в реестре, сертификация и лицензии, локализация данных, независимость от иностранной юрисдикции. Язык интерфейса и название компании на кириллице к статусу отношения не имеют. Выбирать решение стоит по этому чек-листу вместе с обычными техническими критериями: RBAC, SSO, LDAP, аудитом, стандартами шифрования.

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

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

Можно ли использовать иностранный менеджер паролей в российской компании?

Юридического общего запрета для бизнеса вне КИИ и госсектора нет. Риск не в законности, а в зависимости: доступ к зарубежному SaaS-сервису способен ограничить решение вендора или санкционный режим без переходного периода, а хранит такой сервис доступы ко всей корпоративной инфраструктуре.

Чем российский менеджер паролей отличается от обычного корпоративного?

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

Обязательна ли сертификация ФСТЭК для менеджера паролей, если компания не относится к КИИ?

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

Как проверить, что менеджер паролей действительно есть в реестре отечественного ПО?

Проверьте номер записи, который называет вендор, напрямую в едином реестре российского ПО на reestr.digital.gov.ru, по названию компании или продукта. Запись в реестре и сертификация ФСТЭК — разные документы, и оба нужно проверять отдельно.

Чем плох Excel или KeePass для хранения рабочих паролей в компании?

Общая таблица или локальная база не дают ролевой модели, журнала действий и централизованного отзыва доступа при увольнении сотрудника. Подробнее об этом можно прочитать в материале «Зачем нужен менеджер паролей для бизнеса, если есть KeePass».

Зачем нужен менеджер паролей для бизнеса, если есть KeePass?

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

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

Как создать надёжный пароль в 2026: новые требования, правила и примеры

73% российских компаний до сих пор пользуются паролем по умолчанию — притом что одна лишняя буква длины часто защищает больше, чем весь набор спецсимволов. Разбираем, что на этот счёт думают ФСТЭК, NIST и OWASP, и как быстро собрать пароль, который устроит всех.

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

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

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

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

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

Главное об аудите парольной безопасности

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

1. Инвентаризация учётных записей — разделить обычные, привилегированные и сервисные, найти забытые и «мёртвые» учётки.
2. Проверка качества и уникальности паролей — длина, случайность, совпадения между системами.
3. Аудит парольной политики и настроек блокировки — сверить регламент с реальными настройками в системах.
4. Проверка многофакторной аутентификации — покрытие MFA и устойчивость метода к фишингу.
5. Проверка журнала аудита и подозрительной активности — нетипичные входы, подбор пароля, повторяющиеся сессии.
6. Приоритизация находок и отчёт — сроки реагирования и документ для руководства.

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

Зачем и когда проводить аудит парольной безопасности

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

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

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

Шаг 1. Инвентаризация учётных записей

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

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

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

С привилегированными и сервисными учётными записями сложнее: часто данных просто нет, потому что их не заводили по единому процессу. По данным BI.ZONE, почти 40% таких записей используют одинаковые или похожие пароли, а больше половины никогда не истекают. На одного ИТ-специалиста в среднем приходится 3–7 привилегированных учётных записей, и часто он сам не может назвать их точное число без выгрузки.

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

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

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

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

Шаг 2. Проверка качества и уникальности паролей

На этом шаге парольного аудита проверяется, соответствуют ли реальные пароли принятому стандарту длины, сложности и уникальности.

Оцените среднюю и минимальную длину паролей

Ориентир — от 15 символов для учётных записей без MFA и от 8 символов при обязательном втором факторе. Пароль короче этого порога — кандидат на принудительную смену независимо от того, из каких символов он состоит.

Не считайте спецсимволы признаком надёжности

Пароли вида P@rr01! формально проходят проверку сложности, но взламываются по словарю за секунды: замена а на @ и цифра в конце давно учтены в базах для брутфорса. Оценивайте длину и случайность пароля, а не набор символов в нём.

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

Международные практики не рекомендуют принудительную ротацию по календарю: пользователь, которого заставляют менять пароль по графику, предсказуемо адаптируется — Parol2025 превращается в Parol2026, и такой пароль взламывается по тому же словарю, что и предыдущий.

ФСТЭК России, напротив, рекомендует смену пароля не реже одного раза в 90 дней. Если организация подпадает под требования регулятора, ориентируйтесь на этот срок, если нет — ориентируйтесь на внутреннюю политику безопасности и меняйте пароль точечно, при подозрении на компрометацию.

Сопоставьте пароли между учётными записями

Проверьте пароли на совпадения и повторы. По данным исследования ГК «Солар», 47% опрошенных используют один и тот же пароль для разных учётных записей. Каждое найденное совпадение — повод для точечной смены конкретного пароля.

Если дефолтные и повторяющиеся пароли — не единичные случаи, а массовое явление

Значит проблема не в дисциплине сотрудников, а в самой парольной политике: минимальная длина занижена, ротация идёт по календарю, уникальность не проверяется техническими средствами. Точечная смена паролей снимает симптом, причину устраняет пересмотр политики. Этому посвящён шаг 4 статьи и статья «Что такое парольная политика».

Рекомендации

Шаг 3. Аудит парольной политики и настроек блокировки

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

Проверьте минимальную длину и требования к алфавиту пароля

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

Проверьте глубину истории паролей

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

Проверьте порог блокировки учётной записи и время автоматической разблокировки

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

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

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

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

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

Шаг 4. Проверка многофакторной аутентификации

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

Задача этого шага: не зафиксировать факт наличия MFA в компании, а проверить её покрытие: у кого она включена и где остались исключения.

Чек-лист проверки MFA:

• Включена ли MFA для всех привилегированных учётных записей без исключений
• Есть ли обходные пути входа без второго фактора: старые интеграции, сервисные API, устаревшие протоколы
• Какой метод MFA используется: SMS-код, приложение-аутентификатор или аппаратный ключ
• Покрывает ли MFA доступ к самим системам управления паролями и секретами, а не только к рабочей почте

Оцените метод MFA на устойчивость к фишингу

SMS-код и одноразовый пароль из приложения — рабочий минимум, но не предел. SMS остаётся уязвимым к перехвату и подмене SIM-карты, поэтому для привилегированных учётных записей его стоит считать временной мерой. Более зрелый уровень защиты — аппаратные ключи (FIDO2) и ключи доступа (passkeys), которые не передают код по каналу связи и поэтому не перехватываются тем же способом.

Проверьте, защищена ли MFA сама система управления паролями и секретами

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

Сверьте, как MFA сочетается с единым входом (SSO)

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

Шаг 5. Проверка журнала аудита и подозрительной активности

Журнал аудита фиксирует, кто и когда входил в систему. Без его регулярного просмотра администратор узнаёт о компрометации только после инцидента, а не до него.

На что смотреть в первую очередь:

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

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

Команда зрелого уровня не проверяет журналы вручную каждый раз, а настраивает экспорт логов в SIEM или Syslog и получает уведомления по заданным правилам.

Шаг 6. Приоритизация находок и отчёт

Список находок без приоритизации бесполезен для руководства: непонятно, что чинить сегодня, а что подождёт до следующего аудита. Задача этого шага — свести результаты шагов 1–5 в документ с чёткими сроками, который можно передать руководству или внешнему аудитору.

Шкала критичности находок (3 уровня)

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

Заметьте закономерность: находки шага 1 (забытые учётные записи, сервисные аккаунты) и шага 4 (пробелы в MFA) чаще попадают в Критично и Важно, а формальные отклонения из шага 2 (длина пароля на пару символов ниже нормы) — почти всегда в Можно отложить. Это не правило: решает не то, на каком шаге найдена проблема, а то, что она открывает злоумышленнику.

Минимальная структура отчёта

Готовый отчёт отвечает на пять вопросов, и каждый прямо опирается на данные, собранные на шагах 1–5:

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

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

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

Привилегированные и сервисные учётные записи

Для машинных секретов (API-ключей, токенов доступа к базам данных, учётных данных CI/CD) в Пассворке есть отдельный механизм сервисных аккаунтов: несколько scoped-токенов на одну систему, каждый можно отозвать или заменить без остановки пайплайна. Это закрывает главную находку большинства аудитов: сервисные аккаунты с пожизненным паролем, который никто не менял с момента настройки интеграции.

Качество и уникальность паролей

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

Многофакторная аутентификация

Пассворк поддерживает TOTP, ключи доступа (passkeys/WebAuthn) и приложение «Пассворк 2ФА». Администратор может настроить обязательную MFA для конкретных ролей — в первую очередь для тех, у кого доступ к привилегированным сейфам.

Права доступа и их пересмотр

Ролевая модель построена на ролях и группах: встроенные роли Владелец, Администратор и сотрудник, а также неограниченное количество настраиваемых ролей для гибкого управления системой. Группы синхронизируются с AD/LDAP — при увольнении сотрудника или его переводе в другой отдел доступ отзывается один раз, а не вручную по каждому сейфу. Для входа доступны SAML SSO и OAuth.

Журнал использования прав

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

Заключение

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

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

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

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

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

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

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

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

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

Нужно ли менять все пароли по графику при аудите?

По умолчанию — нет. Массовая смена паролей по расписанию без разбора создаёт видимость работы, но не устраняет причину: скомпрометированный или повторяющийся пароль останется таким же слабым после ротации. Меняйте точечно, там, где аудит нашёл конкретную проблему. Исключение — системы, подпадающие под требования ФСТЭК (ГИС, КИИ): там периодическая смена паролей может быть прямым требованием регулятора и обязательна независимо от результатов аудита.

Что делать с найденными «мёртвыми аккаунтами» — учётными записями без владельца?

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

Внедрение менеджера паролей: пошаговое руководство

Сисадмин пересылает SSH-ключи в мессенджере. Уволенный сотрудник до сих пор получает рассылку с данными клиентов. Стажёр с правами администратора. Знакомо? Рассмотрим, как ИТ-отделу взять доступы под контроль — от первого аудита до работающей системы.

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

Как создать надёжный пароль в 2026: новые требования, правила и примеры

73% российских компаний до сих пор пользуются паролем по умолчанию — притом что одна лишняя буква длины часто защищает больше, чем весь набор спецсимволов. Разбираем, что на этот счёт думают ФСТЭК, NIST и OWASP, и как быстро собрать пароль, который устроит всех.

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

Управление паролями в компании: система, угрозы, внедрение

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

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

В 2025 году ФСТЭК проверила более 700 значимых объектов КИИ и выявила свыше 1 200 нарушений в части обеспечения информационной безопасности. Направлено более 2 000 требований об устранении недочётов и составлено 603 протокола об административных правонарушениях.

Показательна и другая цифра: по данным, озвученным начальником управления ФСТЭК Еленой Торбенко на «Инфофоруме 2026», лишь 35% проверенных объектов КИИ соответствуют минимальному базовому уровню безопасности. Там же она сообщила, что в этом году ФСТЭК увеличит количество проверок.

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

«Ключевой вызов этого года — сформировать базу для придания этому процессу неизбежности. Тогда, если компания не хочет переходить на российское ПО и ПАКи на КИИ-объектах, пусть пополняет бюджет, из которого мы будем стимулировать дальше этот процесс. В нашем понимании единственный механизм принуждения — это всё-таки какие-то серьёзные штрафы финансовые на те компании, которые нарушают сроки», — Максут Шадаев, министр цифрового развития РФ (Интерфакс, 2026)

В то же время регулирование стало сложнее. 58-ФЗ, типовые отраслевые объекты, обновлённые формы категорирования, проект постановления Минцифры со сроками 2028–2036 годов — всё это появилось за последние два года. Требования различаются в зависимости от статуса организации, категории объекта и вида актива: ПО, СЗИ (средства защиты информации) или ПАК (программно-аппаратный комплекс). Часть запретов уже действует с 2025 года.

Главное

• Часть запретов уже действует. С 01.01.2025 иностранные СЗИ запрещены на всех ЗОКИИ, иностранное ПО — на ЗОКИИ госорганов и госкомпаний. Это действующие нормы.
• Проектируемый базовый дедлайн — 01.01.2028. К этой дате доля российского ПО на всех ЗОКИИ должна составить 100%. Срок содержится в проекте постановления, находящемся в Правительстве, и пока не утверждён окончательно.
• Специальные сроки 2031 и 2036 годов — не массовая отсрочка. Они обсуждаются только для участников особо значимых проектов и отдельных категорий ЗОКИИ. Рассчитывать на них без документальных оснований не следует.
• Штрафы за нарушение сроков готовятся. В июне 2026 года Минцифры подтвердило намерение сформировать нормативную базу для серьёзных финансовых санкций. Действующей нормой они пока не являются, но при планировании этот риск уже нужно учитывать.
• Регулирование усложнилось. 58-ФЗ, типовые отраслевые объекты, обновлённые формы категорирования — всё это появилось за последние два года. Требования различаются в зависимости от статуса организации, категории объекта и вида актива: ПО, СЗИ или ПАК.
• 2026 год — время подготовки, а не ожидания. Лишь 35% проверенных объектов КИИ соответствуют базовому уровню безопасности. ФСТЭК увеличивает число проверок. Компании, которые начнут аудит и ревизию категорирования сейчас, к дедлайну подойдут с готовым планом.

Что изменилось в импортозамещении КИИ к 2026 году

Регулирование критической информационной инфраструктуры (КИИ) менялось поэтапно, каждый этап добавлял новые обязанности для субъектов.

До 2025 года основу составляли Указы Президента № 166 и № 250. Первый ограничивал закупки иностранного ПО для значимых объектов КИИ (ЗОКИИ) без согласования и запрещал его использование на объектах госорганов и госкомпаний с 01.01.2025. Второй обязал всех владельцев ЗОКИИ перейти на российские средства защиты информации (СЗИ) — также с 01.01.2025. Оба указа касались конкретных категорий субъектов и не создавали единой системы управления переходом.

С 1 сентября 2025 вступил в силу 58-ФЗ и изменил архитектуру регулирования. Он существенно расширил полномочия Правительства РФ и создал нормативную основу для системного перехода на российское ПО и программно-аппаратные комплексы (ПАК) на значимых объектах КИИ. Правительство получило право устанавливать:

• перечни типовых отраслевых объектов КИИ;
• отраслевые особенности категорирования;
• порядок и сроки перехода на российское ПО и ПАК;
• требования к ПАК для ЗОКИИ;
• порядок мониторинга исполнения этих обязанностей.

В 2026 году начали появляться подзаконные акты, реализующие 58-ФЗ. Первыми вышли отраслевые постановления по категорированию для атомной энергетики (№ 4 от 16.01.2026), банковской сферы и финрынка (№ 92 от 06.02.2026), науки (№ 246 от 07.03.2026) и ракетно-космической промышленности (№ 356 от 31.03.2026). Постановление Правительства № 402 от 13.04.2026 установило отраслевые особенности категорирования объектов КИИ в сфере связи — они вступили в силу с 01.09.2026. 27 июня 2026 года список пополнило постановление № 796 — для оборонной промышленности.

В мае 2026 года Минцифры представило проект постановления о сроках перехода ЗОКИИ на российское ПО с диапазоном 2028–2036 годов. По состоянию на сентябрь 2026 года проект находится в Правительстве и не утверждён окончательно.

2026 год — не период ожидания дедлайна 2028 года. Уже сейчас нужно уточнить состав объектов КИИ, провести аудит иностранного ПО и СЗИ, проверить наличие российских аналогов и подготовить согласованные дорожные карты перехода.

Кого касаются требования: субъект КИИ, объект КИИ, ЗОКИИ и типовые отраслевые объекты

Субъект КИИ — государственный орган, государственное учреждение или российское юридическое лицо, которому принадлежат информационные системы (ИС), информационно-телекоммуникационные сети (ИТКС) или автоматизированные системы управления (АСУ ТП) в критически важных сферах. После принятия 58-ФЗ индивидуальные предприниматели исключены из этого перечня.

Объект КИИ — конкретная ИС, ИТКС или АСУ ТП, принадлежащая субъекту. Не каждый объект автоматически становится значимым: статус присваивается только по результатам категорирования. Значимый объект КИИ (ЗОКИИ) — тот, которому присвоена одна из трёх категорий значимости. Именно к ЗОКИИ применяются требования по импортозамещению ПО, СЗИ и ПАК.

Отдельный инструмент — типовые отраслевые объекты КИИ: перечни типов ИС, ИТКС и АСУ, утверждаемые Правительством РФ по отраслям. Они служат ориентиром для выявления объектов, подлежащих категорированию, — первый такой перечень утверждён распоряжением № 360-р от 26.02.2026.

Отрасли, на которые распространяется 187-ФЗ

Согласно Федеральному закону от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», к субъектам КИИ относятся организации в сферах:

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

Три категории значимости

Три категории значимости (первая, вторая и третья) определяют объём требований к системе обеспечения информационной безопасности (СОИБ). Первая категория соответствует наиболее критичным объектам и предполагает максимально жёсткие требования; третья — минимальные. Если объект КИИ не соответствует ни одному из критериев значимости, категория ему не присваивается.

Категорию объекту присваивают сами субъекты КИИ на основании оценки по пяти критериям, закреплённым в ст. 7 № 187-ФЗ:

Результаты категорирования субъект КИИ направляет в ФСТЭК России в течение 10 дней после принятия решения. Регулятор в течение 30 дней проверяет правильность присвоения категории.

Сроки перехода на российское ПО, СЗИ и ПАК

Проектируемый базовый срок перехода значимых объектов КИИ на российское ПО — 1 января 2028 года. По состоянию на сентябрь 2026 года этот срок содержится в проекте постановления, находящемся в Правительстве, и должен применяться после утверждения соответствующего акта. К этой дате доля российского программного обеспечения на ЗОКИИ должна составлять 100%.

Для отдельных сценариев в публикациях о проекте фигурируют специальные сроки — 1 января 2031 года и 1 января 2036 года. Обсуждаются следующие сценарии: участие в особо значимых проектах (ОЗП) с началом замещения до 01.09.2026, отсутствие российских аналогов, заключение контрактов ОЗП в 2026–2028 годах, а также отдельные условия для объектов КИИ второй и третьей категорий. До утверждения постановления эти условия следует считать проектируемыми и проверять по финальной редакции акта.

Матрица сроков: от 2022 до 2036 года (актуально на сентябрь 2026)

Ответственность за нарушение сроков: что известно на сетябрь 2026 года

Действующие административные составы за нарушения требований безопасности КИИ сохраняются, и с 20 апреля 2026 года к ним добавился новый: за нарушение правил эксплуатации объекта КИИ или доступа к нему должностному лицу грозит штраф от 10 до 50 тыс. руб., компании — от 100 до 500 тыс. руб. (Федеральный закон от 09.04.2026 № 77-ФЗ).

Отдельные штрафы именно за несоблюдение сроков перехода ЗОКИИ на российское ПО по-прежнему находятся в стадии подготовки: с июня 2026 года новых заявлений или проектов Минцифры не появилось (Интерфакс, 2026). При планировании перехода штрафной риск уже нужно учитывать, но описывать его как действующую норму преждевременно.

Сроки по видам активов

Нормативная база: какие документы учитывать

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

Карта нормативных актов

• 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» — базовый закон. Вводит понятия субъекта КИИ, объекта КИИ, значимого объекта КИИ, устанавливает требования к безопасности и взаимодействию с ГосСОПКА (государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации).
• 58-ФЗ от 07.04.2025 — поправки к 187-ФЗ, вступившие в силу 01.09.2025. Расширяют полномочия Правительства: устанавливать типовые отраслевые объекты, отраслевые особенности категорирования, порядок и сроки перехода на российское ПО и ПАК, требования к ПАК, порядок мониторинга. Исключают ИП из числа субъектов КИИ. Обязывают субъектов КИИ использовать на ЗОКИИ ПО из реестра российского ПО Минцифры.
• Указ Президента РФ № 166 от 30.03.2022 (в ред. от 07.04.2025) — ограничивает закупки иностранного ПО для ЗОКИИ без согласования. С 01.01.2025 устанавливает запрет использования иностранного ПО на ЗОКИИ, принадлежащих госорганам и государственным организациям.
• Указ Президента РФ № 250 — обязывает всех владельцев ЗОКИИ перейти на российские СЗИ. С 01.01.2025 использование иностранных СЗИ на ЗОКИИ запрещено.
• Постановление Правительства РФ № 402 от 13.04.2026 — утверждает отраслевые особенности категорирования объектов КИИ в сфере связи. Вступило в силу 01.09.2026. Один из шести отраслевых актов 2026 года, реализующих полномочия Правительства по 58-ФЗ.
• Постановление Правительства РФ № 796 от 27.06.2026 — утверждает отраслевые особенности категорирования объектов КИИ в оборонной промышленности.
• Приказ ФСТЭК России № 117 — с 01.03.2026 обновляет требования защиты информации для государственных информационных систем (ГИС) и иных систем государственных органов, ГУПов и учреждений. Актуален для организаций, у которых объекты КИИ одновременно являются ГИС.
• Приказ ФСТЭК России № 247 от 11.07.2025 — обновляет форму направления сведений о результатах категорирования объектов КИИ. С 01.09.2025 форма дополнена полем о наименовании типового отраслевого объекта КИИ, доменным именем и внешним сетевым адресом.
• Постановление Правительства РФ № 127 — устанавливает показатели критериев значимости объектов КИИ и порядок категорирования.
• Постановление Правительства РФ № 1478 — определяет требования к системам безопасности значимых объектов КИИ.
• Распоряжение Правительства РФ № 360-р от 26.02.2026 — утверждает перечень типовых отраслевых объектов КИИ. Триггер для ревизии состава объектов у субъектов КИИ.

Как категорирование связано с импортозамещением

Категорирование — отправная точка всего проекта импортозамещения. Объём обязательств по переходу на российское ПО, СЗИ и ПАК напрямую зависит от того, какие объекты признаны значимыми и какую категорию они получили.

58-ФЗ добавил новый инструмент — типовые отраслевые объекты КИИ. Это перечни типов ИС, ИТКС и АСУ, утверждаемые Правительством РФ по отраслям. Они служат ориентиром для выявления объектов, подлежащих категорированию, и позволяют регулятору унифицировать подход к разным субъектам одной отрасли.

Распоряжение Правительства № 360-р от 26.02.2026 утвердило первый такой перечень. Для субъектов КИИ это означает необходимость сверить собственный реестр объектов с типовым перечнем: не исключено, что часть систем, ранее не признававшихся объектами КИИ, теперь попадает в периметр регулирования.

Почему актуализация категорирования критична в 2026 году

Форма направления сведений о результатах категорирования обновлена Приказом ФСТЭК № 247: с 01.09.2025 она включает поле о наименовании типового отраслевого объекта КИИ. Если организация не сверила свои объекты с новыми перечнями и не актуализировала сведения — она рискует направить во ФСТЭК неполные данные.

Реестр ЗОКИИ также получил новый формат регистрационного номера: XXXXXX/Х/XX/Х, где зашифрованы порядковый номер, федеральный округ, сфера деятельности и тип объекта (ИС, АСУ или ИТКС). Сведения из реестра ежемесячно передаются государственным органам, уполномоченным на реализацию государственной политики в соответствующей сфере.

Отраслевые особенности категорирования

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

Аналогичные постановления для оставшихся отраслей (энергетика, транспорт, здравоохранение) ожидаются в 2026–2027 годах по мере реализации полномочий Правительства по 58-ФЗ. Субъектам КИИ из этих отраслей стоит отслеживать появление отраслевых актов и закладывать время на ревизию категорирования.

Что именно нужно заменить: ПО, СЗИ, ПАК и управление доступом

Импортозамещение КИИ охватывает три разных класса активов с разными требованиями, сроками и порядком подтверждения соответствия.

Три класса активов и логика их замены

• Российское ПО — программный продукт, включённый в единый реестр российского программного обеспечения Минцифры России. Включение в реестр подтверждает российское происхождение, но не означает автоматического соответствия требованиям безопасности для ЗОКИИ. Для ПО, используемого в качестве СЗИ, дополнительно требуется сертификат ФСТЭК или ФСБ.
• Средства защиты информации (СЗИ) — отдельный класс продуктов: антивирусные средства, межсетевые экраны, системы обнаружения вторжений, средства криптографической защиты, системы управления доступом и аутентификации. Для ЗОКИИ с 01.01.2025 действует запрет использования иностранных СЗИ (Указ № 250). Российское происхождение СЗИ подтверждается реестром Минцифры, а соответствие требованиям безопасности — сертификатом ФСТЭК или ФСБ в зависимости от класса продукта.
• Доверенные программно-аппаратные комплексы (ПАК) — связка программного и аппаратного компонентов, отвечающая отдельным требованиям доверенности. Требования к ПАК для ЗОКИИ устанавливаются Правительством РФ по 58-ФЗ. Базовый ориентир перехода на доверенные ПАК — 01.01.2030. Сроки и порядок перехода на ПАК отличаются от сроков перехода на ПО: их нельзя смешивать при планировании.

Реестр российского ПО: как проверять

Единый реестр российского ПО ведёт Минцифры России. При проверке продукта важно убедиться:

• что продукт включён в реестр и запись актуальна;
• что класс ПО в реестре соответствует функции, для которой оно применяется на ЗОКИИ;
• что для СЗИ дополнительно получен действующий сертификат ФСТЭК или ФСБ;
• что продукт функционально совместим с существующей инфраструктурой объекта.

План действий на 2026 год

В 2026 году компании должны провести ревизию объектов, уточнить категорирование, определить состав иностранного ПО/СЗИ/ПАК, проверить наличие российских аналогов и подготовить согласованный план перехода. Это минимальный набор действий, без которого старт миграции в 2027 году окажется неуправляемым. Ниже — Дорожная карта импортозамещения КИИ:

Этап 1

1. Ревизия объектов КИИ. Сверьте реестр объектов организации с распоряжением Правительства № 360-р (перечень типовых отраслевых объектов КИИ). Проверьте, не появились ли системы, которые теперь подпадают под определение типового отраслевого объекта КИИ, но ранее не были включены в реестр.
2. Актуализация сведений о категорировании. Обновите форму направления сведений во ФСТЭК с учётом Приказа № 247: добавьте наименование типового отраслевого объекта, доменные имена и внешние сетевые адреса. Если категорирование проводилось до 01.09.2025 — проверьте, нужен ли пересмотр категорирования и актуализация сведений во ФСТЭК.
3. Инвентаризация иностранного ПО, СЗИ и ПАК. Составьте полный реестр иностранного программного обеспечения, средств защиты и программно-аппаратных комплексов на каждом ЗОКИИ. Зафиксируйте: вендор, версия, функция, наличие или отсутствие поддержки, наличие российского аналога.
4. Назначение ответственных. Определите должностное лицо, ответственное за организацию перехода. Для федеральных органов власти и госкорпораций это требование закреплено в предложениях Минцифры: ответственный — не ниже заместителя руководителя.

Этап 2

1. Анализ покрытия и матрица аналогов. Для каждой позиции реестра иностранного ПО/СЗИ/ПАК определите российский аналог: проверьте наличие в реестре Минцифры, наличие сертификата ФСТЭК/ФСБ (для СЗИ), функциональную совместимость с инфраструктурой объекта.
2. Оценка рисков миграции. Оцените технические риски для каждого объекта: несовместимость с другими компонентами, деградация производительности, отсутствие функциональных аналогов, зависимость от иностранного оборудования. Для объектов без российского аналога — зафиксируйте основания для возможного продления срока.
3. Запуск пилотов. Проведите пилотное тестирование приоритетных российских решений в среде, максимально приближённой к промышленной.

Этап 3

1. Подготовка и согласование дорожной карты. Сформируйте документированный план перехода: объекты, решения, сроки, ответственные, контрольные точки. Для федеральных органов и госкорпораций — отраслевой план до 01.09.2026 (согласно предложениям Минцифры).
2. Контроль подрядчиков. Опишите права доступа, обязанности и ответственность внешних подрядчиков, участвующих в проекте миграции. Проверьте, используют ли подрядчики иностранные инструменты для удалённого доступа к ЗОКИИ.
3. Подготовка плана отката. Для каждого этапа миграции разработайте план возврата к предыдущему состоянию. Миграция без плана отката — один из главных технических рисков проекта.

Импортозамещение КИИ — это управляемый проект

Переход на российское ПО, СЗИ и ПАК на значимых объектах КИИ — многоэтапная программа, которая требует корректного определения объектов, инвентаризации активов, проверки аналогов и поэтапной миграции с контролем доступа и документированным планом отката.

Компании, которые начнут с ревизии категорирования и аудита иностранного ПО в 2026 году, к дедлайну 2028 года подойдут с готовым планом.

Практический первый шаг — зафиксировать, какое иностранное ПО, СЗИ и ПАК используется на каждом ЗОКИИ, кто имеет к ним доступ и есть ли российские аналоги с необходимыми сертификатами. Результаты этой инвентаризации станут основой дорожной карты и аргументом при взаимодействии с ФСТЭК.

Управление учётными данными подрядчиков и сотрудников — отдельное требование при проверке ФСТЭК. Менеджера паролей и секретов Пассворк сертифицирован ФСТЭК и включён в реестр российского ПО Минцифры. Протестировать можно бесплатно

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

Кого касается импортозамещение КИИ в 2026 году?

Требования распространяются на субъекты критической информационной инфраструктуры (КИИ) — организации из 13 отраслей, перечисленных в Федеральном законе № 187-ФЗ: энергетика, здравоохранение, транспорт, финансы, связь, оборонная промышленность и другие. Обязательства касаются тех, кто владеет значимыми объектами КИИ (ЗОКИИ) первой, второй или третьей категории.

До какого срока нужно перейти на российское ПО на значимых объектах КИИ?

Базовый срок — 1 января 2028 года: к этой дате доля российского ПО на ЗОКИИ должна составлять 100%. Для отдельных сценариев Минцифры предложило сроки 1 января 2031 года и 1 января 2036 года. По состоянию на сентябрь 2026 года эти сроки содержатся в проекте постановления Правительства и не являются окончательно утверждёнными нормами. Рассчитывать на них без документально подтверждённых оснований не следует.

Чем отличается субъект КИИ от значимого объекта КИИ?

Субъект КИИ — организация, которой принадлежат ИС, ИТКС или АСУ ТП в критически важных сферах. Значимый объект КИИ — конкретная система или сеть, которой присвоена категория значимости (первая, вторая или третья) по результатам категорирования. Не вся инфраструктура субъекта автоматически является значимым объектом: статус присваивается только после прохождения процедуры категорирования и направления сведений во ФСТЭК.

Что такое типовые отраслевые объекты КИИ и зачем они нужны?

Типовые отраслевые объекты КИИ — перечни типов ИС, ИТКС и АСУ по отраслям, утверждаемые Правительством РФ на основании 58-ФЗ. Они служат ориентиром для выявления объектов, подлежащих категорированию, и унифицируют подход к субъектам одной отрасли. Первый перечень утверждён распоряжением № 360-р от 26.02.2026. Субъектам КИИ необходимо сверить свой реестр объектов с этим перечнем.

Достаточно ли включения продукта в реестр российского ПО для использования на ЗОКИИ?

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

Чем доверенный ПАК отличается от российского ПО?

Российское ПО — программный продукт, соответствующий критериям отечественного происхождения и включённый в реестр Минцифры. Доверенный ПАК — связка программного и аппаратного компонентов, отвечающая отдельным требованиям доверенности, которые устанавливает Правительство РФ по 58-ФЗ. Сроки и порядок перехода на ПО и ПАК различаются: проектируемый базовый ориентир для ПАК — 01.01.2030, для ПО — 01.01.2028. Оба срока содержатся в проектируемых актах и подлежат уточнению после их утверждения.

Что нужно сделать субъекту КИИ в 2026 году?

Провести ревизию реестра объектов с учётом типовых отраслевых перечней, актуализировать сведения о категорировании во ФСТЭК, составить реестр иностранного ПО/СЗИ/ПАК, проверить российские аналоги и их совместимость, запустить пилоты, подготовить дорожную карту, назначить ответственного и описать права доступа подрядчиков.

Как связаны импортозамещение и управление доступом?

Импортозамещение меняет состав ПО и СЗИ, но не устраняет угрозы, связанные со слабыми паролями, общими учётными записями и неуправляемым привилегированным доступом. По данным проверок ФСТЭК (2025), при проверке более 700 ЗОКИИ выявлено свыше 1 200 нарушений в части информационной безопасности. Контроль идентификации, аутентификации и прав доступа должен быть частью проекта миграции, а не отдельной задачей.

Можно ли отложить импортозамещение КИИ?

В публикациях о проекте обсуждаются специальные сроки для нескольких сценариев: участие в особо значимых проектах с началом замещения до 01.09.2026, отсутствие российских аналогов, заключение контрактов ОЗП в 2026–2028 годах, а также отдельные условия для объектов КИИ второй и третьей категорий. Окончательный перечень условий зависит от утверждённой редакции постановления. Ни один из этих сценариев не действует автоматически.

Какие ошибки чаще всего допускают при импортозамещении КИИ?

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

Первый менеджер паролей с сертификацией ФСТЭК России

30 апреля 2026 года Пассворк получил сертификат ФСТЭК России № 5063 по 4-му уровню доверия — наивысшему для коммерческих средств защиты информации. Пассворк стал первым российским менеджером паролей, который может применяться в ГИС, ИСПДн, КИИ и АСУ ТП 1 класса защищённости.

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

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

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

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

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

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

Многие уверены, что знают, как создать надёжный пароль: добавить цифру, заменить «а» на «@», поставить «!» в конце — задача решена. Но именно эти действия делают пароль предсказуемым. Типовые замены символов давно внесены в словари для брутфорса, а «сложный» P@rR01! взламывается за секунды.

Эта предсказуемость дорого стоит на уровне организации. По данным исследования DSEC (ГК «Солар»), слабые пароли и пароли, оставленные без изменений после установки оборудования или ПО, встречались в 53% исследованных внутренних сетей российских компаний в 2025 году, а в 13% случаев стали точкой входа для захвата контроля над доменом.

На уровне отдельного пользователя картина не лучше: по данным ГК «Солар» за май 2026 года, 47% опрошенных используют один и тот же пароль для разных учётных записей, а 81% не меняют пароли регулярно — треть считает это просто неудобным. Один пароль на все сервисы и привычка не обновлять его — та же предсказуемость, только не в конструкции пароля, а в том, как его используют.

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

Российский регуляторный минимум (ФСТЭК) и международные ориентиры (NIST, OWASP) расходятся в деталях этой границы. Рекомендации ниже опираются на оба набора правил — они пригодятся тем, кто хочет реально защитить свои данные, а не просто закрыть формальное требование политики безопасности.

Главное о надёжности пароля

Надёжный пароль — это длинная и уникальная для каждого сервиса комбинация, не встречающаяся в списках утечек. Минимум — 12 символов, а лучше больше. Проще всего собрать такой пароль как парольную фразу: несколько случайных слов подряд, например 3-electrica-varyat-vinegret. Она длиннее большинства «сложных» паролей со спецсимволами, и её реально запомнить.

• Длина решает больше, чем состав символов: NIST и OWASP требуют минимум 15 символов без многофакторной аутентификации или 8 символов при её использовании.
• Российский регуляторный минимум другой: мера ИАФ.3 ФСТЭК задаёт не менее 12 символов при алфавите не менее 70 знаков — для государственных информационных систем, без деления по классам защищённости.
• Принудительная смена пароля по расписанию большинству систем не нужна: NIST и OWASP считают её обязательной только при подозрении на утечку. Исключение — государственные информационные системы в контуре ФСТЭК, там смена не реже раза в 90 дней остаётся требованием.
• Один пароль на несколько сервисов обесценивает даже длинную парольную фразу: утечка на одном сервисе открывает доступ ко всем остальным через подстановку учётных данных.
• Генератор паролей и менеджер паролей — самый лёгкий путь к надёжному паролю: генератор создаёт случайную уникальную комбинацию под каждый сервис, а менеджер хранит её и подставляет автоматически, так что запоминать пароль не нужно.

Что такое надёжность пароля

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

Заглавная буква, цифра и восклицательный знак в конце пароля — это как раз тот субъективный критерий «сложности», к устойчивости почти не относящийся. Замена a на @ или o на 0 лишь незначительно расширяет пространство перебора: обе подстановки давно занесены в словари для брутфорса и проверяются в первую очередь.

Что на самом деле делает пароль надёжным

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

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

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

Разница видна на цифрах, если перевести их в привычные величины:

• Восьмисимвольный пароль, где перемешаны заглавные и строчные буквы, цифры и спецсимволы, даёт около 4,3 квадриллиона вариантов перебора — это четыре с лишним миллиона миллиардов.
• Пароль из двенадцати строчных букв, без единой цифры или спецсимвола даёт уже около 95 квадриллионов вариантов, в 22 раза больше.

Четыре лишние буквы одного и того же типа не просто компенсируют, а с запасом перекрывают весь выигрыш от того, что в первом пароле намешаны сразу четыре разных типа символов.

Тот же эффект виден и в оценке времени подбора пароля перебором при текущих вычислительных мощностях: ежегодный расчёт компании Hive Systems даёт три ориентира. Пароль из 8 символов подбирается за секунды, пароль из 20 символов потребует десятков тысяч лет, а пароль из 28 символов делает перебор практически неосуществимым.

Международный стандарт: что говорят NIST и OWASP

NIST SP 800-63B (стандарт Национального института стандартов и технологий США) вышел в новой редакции в августе 2025 года. OWASP Authentication Cheat Sheet, документ открытого проекта по безопасности веб-приложений, синхронизирован с этими требованиями и во многом их детализирует. Разберём позицию обоих документов через два мифа, которые до сих пор определяют парольную политику многих компаний.

Миф 1: пароль нужно менять каждые 90 дней

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

Миф 2: сложный пароль лучше длинного

Обязательный микс регистров, цифр и спецсимволов на практике заставляет людей использовать короткие пароли с предсказуемыми заменами, а атакующему почти не мешает: такие замены давно занесены в словари подбора. Поэтому NIST отказался от обязательных требований к составу символов и заменил их требованием к длине — минимум 15 символов при однофакторной аутентификации или 8 символов, если включена многофакторная аутентификация (2FA/MFA), и допустимый максимум не менее 64 символов.

Те же пороги воспроизведены в OWASP Authentication Cheat Sheet со ссылкой на NIST, но документ идёт дальше формальных цифр — это уже не рекомендации пользователю, а конкретные требования к тому, что должна реализовать команда разработки на стороне сервиса:

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

Разворот на 180 градусов случился не из эстетических соображений: длинную парольную фразу человек и правда способен запомнить, а вот Q7$mK!2x почти никогда, из-за чего пароль оседает на стикере или в заметках телефона.

Российские требования к паролям: ФСТЭК и ГОСТ Р 57580.1

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

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

ФСТЭК: мера ИАФ.3 для государственных информационных систем

Требования Федеральной службы по техническому и экспортному контролю (ФСТЭК) применимы к государственным информационным системам, автоматизированным системам управления и информационным системам государственных органов, ГУП, госучреждений и организаций, включая субъектов критической информационной инфраструктуры. Не к любому сайту или корпоративному сервису.

12 апреля 2026 года ФСТЭК России утвердила новый методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах». Он прямо отменяет предыдущую версию от 11 февраля 2014 года — ту, где длина пароля различалась по классам защищённости (6–8 символов при алфавите 30–70 знаков).

Действующий документ задаёт единое требование для простой (парольной) аутентификации пользователя, без деления по классам:

• длина пароля — не менее 12 символов;
• алфавит паролей — не менее 70 символов;
• не более 5 неуспешных попыток входа, дальше блокировка учётной записи на 15 минут;
• смена пароля — не реже чем раз в 90 дней;
• повторное использование пароля запрещено.

Первоисточник формулирует эти параметры одним абзацем:

«При использовании простой (парольной) аутентификации пользователей для доступа в информационную систему и к ресурсам (объектам защиты) информационной системы длина пароля должна быть не менее 12 символов. Алфавит паролей не менее 70 символов, максимальное количество неуспешных попыток ввода неправильного пароля до блокировки учетной записи пользователя – 5, блокировка программно-технического средства или учетной записи пользователя в случае достижения установленного максимального количества неуспешных попыток аутентификации на 15 минут, смена паролей не более чем через 90 дней. Запрещается повторно использовать пароль для доступа в информационную систему и к ресурсам (объектам защиты) информационной системы», — методический документ ФСТЭК России

Здесь ФСТЭК прямо расходится с NIST. Там, где международный стандарт отказался от обязательной периодической смены пароля, российский регулятор её сохраняет: смена не реже чем через 90 дней остаётся обязательным требованием для государственных информационных систем.

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

ГОСТ Р 57580.1: требования для банков и финансовых организаций

ФСТЭК — не единственный источник обязательных требований к паролю в России. Для банков и других организаций, поднадзорных Банку России, действует ГОСТ Р 57580.1-2017. Стандарт разработан при участии Банка России и введён в действие с 1 января 2018 года.

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

Группа мер РД («Идентификация, аутентификация, авторизация при осуществлении логического доступа») задаёт для пароля такие параметры:

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

Оба стандарта (ФСТЭК и ГОСТ) решают разные задачи и адресованы разным организациям. То, что применимо к государственной системе, не заменяет требований банка, и наоборот: если организация одновременно попадает в оба контура, выполнять нужно оба набора мер, беря более строгое значение по каждому параметру.

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

Нужно ли менять пароль каждые три месяца

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

Это не отменяет корпоративную парольную политику. Для государственных информационных систем в контуре ФСТЭК периодическая смена — прямое требование действующего методического документа: не реже чем раз в 90 дней. Для систем вне этого контура внутренний регламент компании тоже может требовать ротацию по расписанию.

Внутренний документ: парольная политика организации

Соответствие ФСТЭК или ГОСТ Р 57580.1 подтверждается документами. Любая организация, которая обрабатывает персональные данные клиентов или сотрудников, обязана иметь внутренний нормативный акт — парольную политику.

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

Как составить пароль, который трудно взломать и легко запомнить

1. Соберите парольную фразу. Парольная фраза (кодовая фраза, passphrase): несколько не связанных по смыслу слов подряд, например лунный-жираф-кофе-стройка или транслитом Oblaka-gromko-sidyat-42. Четыре случайных слова дают больше энтропии, чем восемь символов со спецсимволами, и человек её реально запоминает, потому что это не набор случайных символов.
2. Возьмите первые буквы предложения. «Мой кот Барсик спит на подоконнике с 2016 года!» превращается в МкБсн2016г!. Предложение запомнить проще, чем набор букв, а по словарю такую комбинацию не подобрать.
3. Не полагайтесь на предсказуемые замены. Замена a на @ уже давно в словарях подбора — это устаревший приём. Такая замена почти не увеличивает время подбора, зато создаёт ложное чувство защищённости.
4. Не используйте личную информацию. Имя, дата рождения, город, номер телефона или паспорта, название сервиса, публичные данные из соцсетей: это первое, что проверяют при подборе пароля, если у атакующего есть доступ к утечке или профилю в соцсети. Личные данные сокращают пространство перебора точнее любого словаря.
5. Не переиспользуйте пароль между сервисами. Даже идеальная парольная фраза теряет смысл, если она одна на все аккаунты: одна утечка и скомпрометированы сразу все сервисы, где она использовалась. Собирать уникальный пароль для каждого сервиса вручную неудобно, а придумывать десятки паролей самостоятельно почти бессмысленно: когда человек старается быть случайным, он всё равно опирается на одни и те же знакомые слова и паттерны.
6. Используйте генератор и менеджер паролей. Генератор паролей опирается на криптографически стойкий генератор случайных чисел и создаёт пароль заданной длины за одно нажатие. Менеджер паролей идёт дальше: хранит отдельный сгенерированный пароль для каждого сервиса и подставляет его при входе, так что вручную запоминать нужно только один мастер-пароль, а не десятки уникальных комбинаций. Так пункты 1–5 из ручной дисциплины превращаются в инструмент, который не забывает и не срезает углы.

Примеры надёжных и ненадёжных паролей

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

Как проверить, не утёк ли ваш пароль

За 2023–2025 годы в России скомпрометировано около 4,5 млрд записей персональных данных, а в 2025 году на одну утечку в среднем пришлось 3,27 млн записей, на 25,8% больше, чем в 2024-м, по данным InfoWatch. При таком масштабе вопрос не «утекал ли когда-нибудь ваш пароль», а «узнаете ли вы об этом вовремя».

NIST и OWASP прямо требуют проверять новый пароль по спискам скомпрометированных и распространённых паролей. В России такого регуляторного требования нет.

Проверьте свой пароль на надёжность

Где хранить пароли

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

Браузер — не место для паролей

Хранилища паролей в Chrome, Firefox и Edge по умолчанию не защищены отдельным мастер-паролем, и это делает их целенаправленной мишенью инфостилеров — вредоносных программ, которые вытаскивают сохранённые логины и пароли без ведома пользователя. По данным международного исследования Verizon Data Breach Investigations Report, инфостилеры остаются одним из основных каналов первичной компрометации паролей.

Как устроено хранение в менеджере паролей

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

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

Генератор паролей в менеджере паролей создаёт уникальный пароль под политику организации сразу в вебе, расширении браузера, десктопном и мобильном приложении, а мастер-пароль остаётся только у пользователя.

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

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

Почему генератор паролей надёжнее человека

Человек предсказуем. Даже когда старается быть случайным — выбирает знакомые слова, привычные паттерны, удобные для набора последовательности. Генератор паролей лишён этих ограничений: он использует криптографически стойкий генератор случайных чисел (CSPRNG), который не опирается ни на словари, ни на клавиатурные паттерны, ни на личные предпочтения.

Каждый символ выбирается независимо из заданного набора — без какой-либо логики, которую можно предугадать или воспроизвести. Результат: пароль вида xK9#mQ2@vL5$nR8!pT3 обладает максимальной энтропией для своей длины и не встречается ни в одном словаре для брутфорса. Запоминать его не нужно — менеджер паролей подставит его автоматически.

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

Длина, уникальность и проверка на утечку определяют надёжность пароля сильнее, чем спецсимвол в середине слова. Международные стандарты и российский регуляторный минимум расходятся в деталях: там, где NIST требует 15 символов и проверку по спискам утечек, ФСТЭК фиксирует 12 символов, но жёсткий алфавит, обязательную ротацию и контроль попыток входа.

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

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

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

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

Сколько символов должно быть в надёжном пароле?

По актуальным рекомендациям NIST и OWASP — минимум 15 символов без многофакторной аутентификации или 8 символов при её использовании, максимум не менее 64. Для государственных информационных систем в России действующий методический документ ФСТЭК (мера ИАФ.3, утверждён 12 апреля 2026 года) требует не менее 12 символов при алфавите не менее 70 знаков — единое значение для всех классов защищённости, без деления по классам.

Нужно ли использовать спецсимволы и разный регистр в пароле?

Формально это больше не обязательное требование по NIST и OWASP: приоритет отдан длине пароля, а не составу символов. Спецсимволы и разный регистр всё ещё немного повышают стойкость к подбору, но не заменяют длину и не спасают короткий пароль. Требование обязательного микса символов, наоборот, часто подталкивает людей к предсказуемым заменам вроде a на @.

Как часто нужно менять пароль?

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

Что такое парольная фраза и зачем она нужна?

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

Как узнать, что пароль уже украли при утечке данных?

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

Можно ли использовать один и тот же длинный пароль для нескольких сервисов?

Нет. Уникальность нужна независимо от длины: при утечке базы одного сервиса скомпрометированный пароль сразу проверяют на всех остальных методом подстановки учётных данных (credential stuffing). Длинный переиспользуемый пароль всё ещё делает уязвимыми сразу все аккаунты, где он стоит, — атакующему для этого не нужно ничего подбирать заново.

Что такое брутфорс (Brute Force): виды, угрозы и защита

В первом квартале 2025 года число брутфорс-атак на российские организации выросло в 2,7 раза. 48% паролей из реальных утечек взламываются за минуту. Разбираем 8 техник перебора, объясняем, чем ИИ изменил атаки, и даём конкретные меры защиты: от парольной политики до управления учётными записями.

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

Почему опасно хранить пароли в браузере: риски, статистика и защита

Инфостилерам не нужно взламывать браузер — ключ шифрования и база паролей лежат в одной папке. В 2025 году так украли 3,3 млрд учётных записей. Разбираем архитектуру уязвимости в Chrome, Firefox, Safari и Edge, а также рабочую альтернативу для бизнеса.

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

7 способов взлома соцсетей: как воруют аккаунты в 2026 году

Число взломов аккаунтов в соцсетях выросло на 123% за год. Разбираем 7 методов, которые используют злоумышленники прямо сейчас, — и что конкретно закрывает каждый из векторов.

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

Компании Пассворк и Аладдин подтвердили совместимость своих продуктов: менеджера паролей Пассворк и корпоративной системы централизованного управления JaCarta Management System 4LX для Linux (JMS4LX).

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

Таким образом, пользователю не нужно запоминать ещё один пароль или носить отдельный токен для доступа к хранилищу — он проходит аутентификацию через сервис JaCarta Identity Provider (JIP), входящий в JMS4LX.

JaCarta Management System 4LX: платформа управления аутентификацией

JaCarta Management System 4LX — система централизованного управления средствами аутентификации и электронной подписи, защищёнными носителями информации, аппаратными OTP/U2F-токенами и программными аутентификаторами.

В её состав входят высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS), сервис Aladdin 2FA и JaCarta Identity Provider (JIP) – провайдер аутентификации/авторизации в приложения с поддержкой протоколов SAML и OIDC.

JMS4LX зарегистрирована в реестре российского ПО (№ 11260 от 05.08.2021) и сертифицирована ФСТЭК России по 4-му уровню доверия (№ 4516 от 25.01.2022).

Пассворк: менеджер паролей и секретов для бизнеса

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

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

Пассворк регулярно тестирует совместимость с отечественными ИТ-продуктами и операционными системами. Посмотреть все актуальные сертификаты совместимости можно на этой странице.

Подтверждённая совместимость как основа для развития

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

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

«Подтверждение совместимости JMS4LX и Пассворка позволяет заказчикам использовать уже существующую инфраструктуру аутентификации для доступа к менеджеру паролей. Для компаний, где JIP уже используется в качестве корпоративного SSO, это означает, что сотрудникам не нужно заводить отдельные учётные данные для Пассворка», — Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин»

О компании Аладдин

Аладдин — ведущий российский разработчик ключевых компонентов для построения доверенной безопасной ИТ-инфраструктуры предприятия и защиты её главных информационных активов. Компания работает на рынке с апреля 1995 г. (31 год). Многие продукты, решения и технологии компании стали лидерами в своих сегментах, во многих крупных организациях и федеральных структурах — стандартом де-факто.

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

Менеджер паролей для организаций госсектора: выбор и внедрение

Менеджер паролей для госсектора должен соответствовать 152-ФЗ, 187-ФЗ и требованиям ФСТЭК: сертификация, реестр отечественного ПО, локализация данных. Разбираем 8 групп критериев выбора, план внедрения в 5 фаз и то, как этим требованиям отвечает Пассворк.

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

Сертификация ФСТЭК: что это, кому нужна и как пройти

Разбираем систему сертификации ФСТЭК: кто обязан применять сертифицированные СЗИ, как устроена процедура от заявки до выдачи сертификата, чем отличаются уровни доверия УД-6 — УД-4 и какие обязательства возникают после получения сертификата.

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

Что такое брутфорс (Brute Force): виды, угрозы и защита

В первом квартале 2025 года число брутфорс-атак на российские организации выросло в 2,7 раза. 48% паролей из реальных утечек взламываются за минуту. Разбираем 8 техник перебора, объясняем, чем ИИ изменил атаки, и даём конкретные меры защиты: от парольной политики до управления учётными записями.

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

«Петрович-Тех» — аккредитованная ИТ-компания и основной цифровой партнёр СТД «Петрович», одного из крупнейших DIY-ритейлеров России. Интернет-магазин «Петровича» входит в топ крупнейших в стране и ежемесячно обслуживает более шести миллионов посетителей.

«Петрович» работает на рынке с 1995 года в сегментах B2C и B2B: от розничных покупателей до крупных девелоперов. Компания закрывает полный цикл: продажи, хранение, кредитование и сопровождение проектов любого масштаба. Такой охват требует зрелой и устойчивой цифровой инфраструктуры.

«Петрович-Тех» основана в 2022 году на базе ИТ-департамента «Петровича». Сегодня это 300+ специалистов в 14 отделах: высоконагруженные системы электронной коммерции, микросервисная архитектура, машинное обучение и анализ данных, автоматизация процессов и поддержка всей ИТ-инфраструктуры бизнеса.

Задача: выстроить управляемую модель доступа

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

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

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

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

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

Внедрение менеджера паролей: поэтапный запуск без лишней нагрузки на команду

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

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

Дополнительно настроены интеграции со службой каталогов и SSO. Сотрудники работают с системой через веб-версию, браузерное расширение и мобильное приложение. 

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

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

«Пассворк внедряли поэтапно: сначала на 10–15 человек — информационная безопасность, ИТ-отдел. Далее масштабировали на отделы с более высоким риском: юридический, финансовый и отдел разработки. Собрали обратную связь, написали инструкции, провели презентацию внутри компании. Самое убедительное преимущество Пассворка — то, что сотрудники легко восприняли сервис»

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

Внутренняя политика: цифровая грамотность как часть ИБ

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

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

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

Параллельно с внедрением менеджера паролей «Петрович-Тех» выстраивали культуру безопасности: проводили презентации и доклады для отделов, объясняя, почему важно хранить пароли именно в корпоративной и управляемой системе.

«Мы уделяем внимание цифровой грамотности именно нетехнических специалистов, менеджеров, сотрудников финансового и юридического отделов. Цель — чтобы при онбординге сотрудников каждый сразу получал доступ в Пассворк»

В «Петрович-Тех» сотрудникам доступны личные сейфы в Пассворке. Это не просто удобство: слабые и незащищённые личные учётные данные являются распространённым вектором атаки на корпоративную инфраструктуру, поэтому их надёжная защита тоже входит в ИБ-периметр.

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

Результат: удобство и полный контроль

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

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

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

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

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

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

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

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

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

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

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

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

В 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 в России.

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

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

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

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

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

В Пассворке используется клиентское шифрование (zero-knowledge), и сброс мастер-пароля администратора эту проблему не решает. Мастер-пароль защищает доступ к ключу шифрования, но сам по себе этим ключом не является. Если пароль сброшен, а ключ, который он защищал, никуда заранее не передан, — ключ теряется вместе с доступом. Ни поддержка, ни администратор компании не могут «просто открыть» такой сейф — ключа нет ни у кого, кроме владельца учётной записи.

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

Главное о пороговом восстановлении

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

• Открыть сейф в одиночку не может никто. Ключ восстановления делят на несколько частей (например, на 5). Чтобы восстановить доступ, нужно собрать не все 5, а заранее заданное минимальное количество (например, 3 из 5). Меньшего числа частей недостаточно, даже если их несколько.
• Единого ключа «от всего» не существует. Восстановление настраивается не на всю компанию сразу, а отдельно для каждой категории сейфов. Можно сделать один общий контур восстановления на все данные, разные контуры для разных отделов и типов данных — или не настраивать восстановление вовсе, если это не нужно.
• Настраивает ИТ-специалист, а не пользователь через интерфейс. Готовой кнопки «восстановить доступ» в интерфейсе нет. Настройка и сама процедура восстановления проходят через командную строку — потребуется сотрудник с навыками работы в CLI Пассворка.
• Способ настройки зависит от версии Пассворка. В Расширенной версии с сервисными аккаунтами восстановление можно автоматизировать. В остальных версиях доступен ручной вариант — он работает через обычную учётную запись.
• Принцип нулевого знания не нарушается. Каждая часть ключа шифруется личным ключом того сотрудника, который её хранит, и лежит отдельно от Пассворка. Сам Пассворк, как и раньше, не может увидеть расшифрованные данные — ни во время обычной работы, ни при восстановлении.
• Механизм работает через уже существующую функцию — политики доступа к сейфам. Учётную запись восстановления один раз добавляют в администраторы нужной политики (типа сейфов). После этого она получает доступ к сейфам этой категории точно так же, как обычный администратор — без отдельной настройки.

Что такое схема разделения секрета Шамира

Схема разделения секрета Шамира — это криптографический метод, при котором секрет (например, ключ шифрования) делится на $ N $ частей (долей) с порогом $ M $: любые $ M $ долей полностью восстанавливают секрет, а $ M − 1 $ долей не дают о нём вообще никакой информации, даже частичной. Метод предложил криптограф Ади Шамир в 1979 году в работе «How to Share a Secret» (Communications of the ACM).

Кому это нужно и зачем

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

Ниже каждая роль разобрана отдельно — с конкретными сценариями и ограничениями, которые важно знать заранее.

Главное преимущество: сегментация вместо единого ключа на всё

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

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

Что такое политика доступа к сейфам

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

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

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

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

Практические сценарии

Настройка порогового восстановления масштабируется вместе с компанией: от одного контура с порогом 2 из 3 в небольшой команде до нескольких контуров с порогом 5 из 9 и держателями из разных офисов в крупной организации. Три типичных профиля внедрения:

Например, средняя компания может закрыть продуктовые сейфы одним контуром с держателями из ИТ и ИБ, а сейфы кадров и финансов — отдельным контуром с держателями из руководства: утечка долей одного контура не открывает данные другого.

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

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

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

Для администраторов: понятная процедура вместо ручного разбора

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

Пример: администратор сейфа «Финансы» увольняется без передачи доступа. Без подготовленного контура восстановления вариантов немного — просить бывшего сотрудника войти и передать доступ лично, надеяться на добрую волю или создавать новые сейфы и переносить туда данные вручную.

С подготовленным контуром процедура известна заранее:

1. Держатели расшифровывают свои доли личным RSA-ключом и передают их оператору.
2. Оператор собирает нужное количество долей и восстанавливает ключ учётной записи восстановления.
3. Через CLI Пассворка этой учётной записи выдаётся доступ уровня «Администратор» к нужному сейфу.
4. Восстановленный ключ и промежуточные файлы сразу удаляются.

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

Для ИБ-специалистов: контролируемый резервный контур

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

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

Из ограничений, которые стоит знать заранее: сам факт сбора кворума (кто именно передал доли и когда) не попадает в стандартный «Журнал событий» Пассворка — это операционное действие, которое нужно фиксировать отдельно, если этого требует политика аудита.

Для пользователей: сейфы команды не блокируются навсегда

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

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

Чего ждать не стоит

У порогового восстановления есть три ограничения, о которых стоит знать до внедрения:

• Нет визуального конструктора в интерфейсе. Настроить порог, раздать доли и провести восстановление можно только командами через CLI Пассворка — мастера в веб-интерфейсе для этого не предусмотрено. Понадобится сотрудник с навыками работы в командной строке.
• Кворум восстановления не отображается в продукте. Кто из держателей участвовал и когда — фиксируется во внешнем журнале, который ведёт оператор, а не в Журнале событий Пассворка.
• Замена одного держателя — это пересборка всего контура. Если один из держателей скомпрометирован или уволился, компания создаёт новую учётную запись восстановления и раздаёт новые доли всем держателям заново — точечно заменить одну долю нельзя.

С чего начать

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

1. Изучите документацию. Прочитайте раздел Восстановление доступа по схеме Шамира и Основные концепции в технической документации Пассворка.
2. Определите версию Пассворка. Проверьте, есть ли у вас доступ к сервисным аккаунтам из Расширенной версии Пассворка, и выберите автоматизированный или ручной вариант восстановления.
3. Назначьте держателей долей. Выберите доверенных сотрудников, желательно из разных отделов или офисов.
4. Подключите аккаунт восстановления к политике сейфов. Добавьте учётную запись восстановления в администраторы нужной политики (типа) сейфов.
5. Проведите тестовое восстановление. Убедитесь, что процедура работает на некритичном сейфе — готовые команды собраны в разделе Примеры.

Заключение

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

Вопросы о пороговом восстановлении

Может ли Пассворк сам восстановить доступ, если кворум не собрать?

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

Меняет ли эта функция модель нулевого знания Пассворка?

Нет. Доли ключа шифруются на стороне держателей их публичными RSA-ключами и никогда не передаются на сервер в открытом виде. Принцип zero-knowledge сохраняется на всех этапах — от разделения ключа до финального восстановления доступа администратором.

Что будет, если один из держателей потеряет свою долю?

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

Можно ли добавить одному держателю сразу несколько долей?

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

Если скомпрометирован один контур восстановления, под угрозой все данные?

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

Видно ли восстановление доступа в Журнале событий?

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

Чем ключ для шифрования долей отличается от обычного ключа пользователя?

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