Пассворк

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

Политики паролей

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

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

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

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

Политики паролей в релизе Пассворк 7.8 состоят из двух блоков настроек: Требования к сложности и Срок действия. Каждую настройку внутри блока можно включить или выключить по отдельности.

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

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

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

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

Ограничение на создание паролей

На вкладке Настройки раздела Управление сейфами появился переключатель «Создание записей, не соответствующих политике паролей». Если его выключить, кнопка сохранения в формах добавления и редактирования записи становится неактивной в случае, когда значение поля с паролем не соответствует политике, назначенной этой записи.

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

Как это работает на практике

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

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

Если при сохранении новой или изменённой записи пароль не соответствует требованиям политики, система предупредит об этом. В панели безопасности теперь нет единых правил «слабый / старый» для всей организации: она проверяет запись по политике, которая назначена определённой записи, поэтому пароли одинакового возраста из разных сейфов могут получить разную оценку.

Главное о политиках паролей

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

Сценарии использования политик паролей

Три типичные ситуации, в которых отдельная политика решает конкретную задачу.

1. Разные требования для критичных и второстепенных сейфов

• Ситуация: один сейф хранит доступы к инфраструктуре и базам данных, а другой хранит пароли от внутренних сервисов с низким риском, например корпоративной вики.
• Решение: администратор создаёт отдельную политику для сейфа с более строгими требованиями (например, минимальная длина 16 символов и срок действия 60 дней) и оставляет для остальных сейфов политику по умолчанию «Базовая».
• Польза: критичные системы получают повышенные требования к паролям, а сотрудники, которые работают с менее чувствительными данными, не сталкиваются с избыточными ограничениями.

2. Политика для сейфа с общими аккаунтами в соцсетях

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

3. Подготовка к проверке соответствия

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

Улучшенный веб-интерфейс

Расширили рабочую область веб-интерфейса: на больших мониторах страница теперь растягивается шире, до 1800 px. Сайдбар и основная рабочая область теперь скроллятся независимо друг от друга.

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

Избранные сейфы и папки

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

Новый тип поля «Скрытый текст» в карточке записи

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

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

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

Системная тема интерфейса

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

Другие изменения в релизе

Улучшения

• Добавили отображение пути к записи в результатах поиска и в разделах Недавние, Избранное и Офлайн
• Изменили шрифт в парольных полях, чтобы исключить неоднозначность при чтении символов
• Добавили автоматическую генерацию названия записи на основе URL
• Добавили возможность создавать пользователей сверх лимита лицензии в статусе «Ожидает подтверждения»
• Добавили фильтр по времени последней активности пользователей в разделе управления пользователями
• Добавили передачу типа сейфа в ArcSight syslog
• Визуальные улучшения и исправления интерфейса

Исправления

• Исправили ошибку, при которой могли не отображаться настройки LDAP до перезагрузки страницы
• Исправили ошибку, при которой могла не отображаться форма регистрации после завершения установки
• Исправили ошибку, при которой не отображались предыдущий и новый уровни доступа в деталях событий сброса доступа к директории
• Исправили ошибку, при которой сбрасывались выбранные чекбоксы при поиске или фильтрации в модальных окнах доступа
• Исправили ошибку, при которой могла быть некорректной сортировка списка сессий по дате последнего использования
• Исправили ошибку, при которой мог некорректно завершаться анализ в панели безопасности
• Исправили ошибку, при которой мог не отображаться информационный баннер для неавторизованных пользователей
• Исправили ошибку, при которой могли дублироваться поля в ArcSight syslog
• Исправили ошибку, при которой в некоторых случаях было невозможно скопировать данные в директорию с доступом «Редактирование»

Десктопное приложение

• Добавили механизм запуска внешних приложений на основании правил из внешнего JSON-файла (подробнее в документации)
• Добавили возможность предустановки адреса хоста через CLI-аргументы и параметры инсталлятора
• Исправили ошибку дублирования папки приложения при установке через MSI-инсталлятор на Windows
• Исправили ошибку, при которой полное закрытие приложения на macOS происходило только со второй попытки

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

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

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

Релиз Пассворк 7.7: управляемый офлайн-доступ

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

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

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

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

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

Российские компании Пассворк и МУЛЬТИФАКТОР протестировали и подтвердили совместимость менеджера паролей Пассворк и системы двухфакторной аутентификации и контроля доступа 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).

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

Компании Пассворк и Аладдин подтвердили совместимость своих продуктов: менеджера паролей Пассворк и корпоративной системы централизованного управления 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 техник перебора, объясняем, чем ИИ изменил атаки, и даём конкретные меры защиты: от парольной политики до управления учётными записями.

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

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

В Пассворке используется клиентское шифрование (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 бит, которую держатель генерирует специально для процедуры восстановления. В обычной работе с продуктом он не используется.

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

Главное

• Полноценный справочник по API Пассворка. Инструмент поддерживает поиск, отображает дерево схем и сравнивает версии API.
• Актуальные данные. Схема всегда содержит спецификации последних версий Пассворка с полным списком доступных путей и операций.
• Сравнение версий. Схема показывает удалённые и добавленные эндпоинты, изменения в структуре запросов и правки в документации.
• Каталог по разделам с поиском. Операции сгруппированы по частям API: сейфы, папки, записи, пользователи, LDAP и другие разделы.
• Готовые примеры кода. Значения из формы ввода сразу появляются в примере кода.
• История изменений по каждой операции. Вкладка История показывает, что менялось у выбранной параметра и пути между версиями API.
• Экспорт схемы для ИИ. Всю схему можно скопировать в формате JSON целиком для передачи ИИ-агенту или инструменту генерации кода.

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

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

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

1. Какой метод и путь использовать для конкретной задачи.
2. Какие поля передавать в теле запроса и что вернется в ответе.
3. Как сохранить совместимость текущих скриптов при обновлении Пассворка.
4. Как сформировать готовый код запроса для cURL, Python или консольной утилиты.
5. В каком формате придут данные: строгая JSON-модель, XML-документ или бинарный файл.
6. Как развивался конкретный метод и какие новые пути появились в свежем релизе.
7. Где взять машиночитаемую спецификацию для передачи контекста нейросетям или генерации кода.

Инструмент решает эти задачи без разворачивания тестового стенда и копирования тысяч строк JSON в редактор кода.

Возможности интерактивной схемы

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

Сравнение версий API Пассворка

Кнопка Сравнить схемы запускает анализ двух версий спецификации. Результаты сгруппированы по логике:

Пример использования: вы планируете обновить Пассворк с версии 7.5 на 7.7. В методе POST /v1/vaults/create изменилось обязательное поле. Без предварительного сравнения схем интеграция сломается, и запросы начнут возвращать ошибку 422. Функция сравнения покажет это изменение заранее, без отправки реальных запросов к серверу.

Каталог операций

Слева на странице схемы расположен список операций с группировкой по тегам и строкой поиска. Пути отображаются кратко — префикс /v1 скрыт для удобства чтения. В верхней панели доступно переключение версий спецификации от 7.3.0 до 7.7.0.

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

Описание операции

В центре экрана находится документация выбранной операции:

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

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

Готовые примеры кода

Справа расположена форма ввода параметров и панель генерации примеров для cURL, Python и CLI Пассворка.

В итоговый фрагмент кода попадают только заполненные значения. Тело запроса формируется при ручном вводе JSON. Адрес сервера и токен подставляются в примеры из настроек и не передаются за пределы браузера.

История версий

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

Параметры для генерации примеров

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

Экспорт спецификации

В верхней панели доступна ссылка на исходный JSON-файл и кнопка копирования спецификации. Это удобно для передачи контекста в нейросети или автоматической генерации API-клиентов.

Порядок работы

1. Откройте схему API
2. Выберите версию в верхней панели
3. Найдите нужную операцию через поиск или в списке тегов
4. Изучите структуру запроса и ответа на вкладке Описание
5. Заполните параметры в правой панели и скопируйте готовый пример кода
6. Перед обновлением Пассворка используйте функцию Сравнить схемы для проверки совместимости

Ограничения инструмента

Интерактивная схема работает как справочник и генератор примеров. Она не заменяет полноценный API-клиент.

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

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

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

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

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

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

Релиз Пассворк 7.7: управляемый офлайн-доступ

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

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

Пассворк 7.6: сервисные аккаунты

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

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

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

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

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

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

Как работает офлайн-доступ

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

1. Формирование списка. Пользователь отмечает нужные записи иконкой офлайна. Отмеченные записи попадают в общий список в разделе Офлайн, который синхронизируется между всеми устройствами пользователя. На этом этапе данные не сохраняются локально.
2. Сохранение на устройство. Пользователь открывает десктопное или мобильное приложение, переходит в раздел Офлайн и нажимает Включить на этом устройстве. Зашифрованные данные скачиваются в локальный кеш.

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

Безопасность и администрирование

Администраторам доступны гибкие ролевые настройки офлайн-доступа:

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

Аудит и контроль

Скачивание данных в локальный кеш фиксируется в Журнале событий и Панели безопасности:

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

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

Все офлайн-записи в сейфах и папках можно просмотреть в окне дополнительного доступа к директории.

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

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

Работа при потере связи

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

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

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

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

Главное об офлайне

• Где работает. Функция доступна в Расширенной версии Пассворка в мобильном и десктопном приложениях. Включать её нужно отдельно на каждом устройстве.
• Какие данные доступны. Без сети можно открыть только те пароли, которые вы заранее добавили в офлайн-список и синхронизировали.
• Только чтение. В автономном режиме записи можно только просматривать. Чтобы создать, изменить или удалить пароль, потребуется подключение к серверу.
• Настройки ролей. Администратор задает правила для пользователей: сколько записей разрешено сохранить на устройство и как долго они живут без синхронизации.

Сценарии использования офлайн-доступа

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

1. Работа в изолированных контурах безопасности

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

2. Защита от перебоев с интернетом

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

3. Аварийное восстановление

• Ситуация: Сеть изолирована, связи с сервером Пассворка нет, но нужно срочно поднять инфраструктуру.
• Решение: Системные администраторы используют локальный кеш в десктопном приложении для доступа к резервным серверам и маршрутизаторам.
• Польза: ИТ-отдел оперативно устраняет аварию без доступа к центральному серверу.

4. Выездные инженеры на удалённых объектах

• Ситуация: Инженеры обслуживают подстанции или серверные в регионах, где нет связи.
• Решение: Перед выездом сотрудник сохраняет в офлайн только нужные для работы пароли.
• Польза: Администратор ограничивает лимит записей (например, до 15) и срок жизни кеша (например, 24 часа). Если телефон или ноутбук сотрудника будет утерян, данные сотрутся. Все просмотры фиксируются локально и отправляются в Журнал событий при первом выходе в сеть.

Другие изменения в релизе

• Добавили возможность отключать прикрепление файлов к записям на уровне организации
• Добавили столбец URL-адреса в разделах Недавние, Избранные и в результатах поиска
• Добавили столбец с родительской директорией в списке папок в результатах поиска
• Добавили консольную команду для обновления серверного ключа шифрования
• Добавили автоматическую активацию поисковой строки при вводе символов с клавиатуры
• Добавили серверное шифрование секрета 2ФА
• Заблокировали добавление ключей доступа и ключей безопасности WebAuthn при использовании Пассворка по IP-адресу или без HTTPS
• Добавили обязательную проверку протокола HTTPS для полей Login URL и Logout URL в настройках SSO
• Добавили блокировку пользовательских запросов на время обновления системы
• Добавили проверку наличия кеша перед обработкой веб-запросов

Исправления

• Исправили ошибку, при которой права доступа при добавлении группы в папку могли проверяться в сейфе, а не в самой папке
• Исправили ошибку, при которой не работали ссылки на записи со сроком действия 1 месяц
• Исправили ошибку, при которой во время регистрации приложение могло запросить ввод мастер-пароля вместо его установки
• Исправили ошибку, при которой ручная регистрация LDAP-пользователей могла завершиться с ошибкой после обновления списка пользователей
• Исправили ошибку, при которой могла не выполняться автоматическая очистка Корзины

Десктопное приложение 1.4.1

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

Мобильное приложение 1.2.0

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

Подробнее об офлайн-доступе — в технической документации.
Вся информация о версиях Пассворка — в истории обновлений.

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

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

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

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

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

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

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

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

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

С 23 по 26 июня в Санкт-Петербурге, на базе Технической академии Росатома, прошла ежегодная конференция РОСАТОМ / Информационная безопасность 2026. Площадка собрала более 500 участников из 130 компаний, представлено 120 докладов.

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

Новый ландшафт ИБ: от бумажной безопасности к практической

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

Главными вызовами стали ужесточение регуляторных требований и масштабное импортозамещение критических компонентов.

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

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

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

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

Это приводит к серьёзным рискам:

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

Для субъектов КИИ это прямой регуляторный риск и потенциальный вектор атаки.

Как устроено системное управление секретами

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

Архитектура сейфов как граница доступа

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

Роли и группы

Роль определяет возможности пользователя в системе — Пассворк даёт три встроенные роли (владелец, администратор, участник) и позволяет создавать собственные роли под задачи отдела или подрядчика. Группа определяет доступ к конкретным сейфам и папкам, синхронизируется с группами Active Directory (AD) и заменяет ручное назначение прав каждому сотруднику отдельно.

Политики сейфов

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

Готовность к промышленной эксплуатации: технические и регуляторные аргументы

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

Главный вывод конференции

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

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

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

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

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

Пороговое восстановление доступа в Пассворке: схема Шамира

Администратор сейфа уволился без передачи дел или потерял мастер-пароль — и ключ шифрования исчез вместе с ним. Разбираем, как пороговое восстановление по схеме Шамира возвращает доступ силами нескольких доверенных сотрудников, без раскрытия чужих мастер-паролей и без нарушения zero-knowledge.

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

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

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

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

У ИБ-отдела особый класс секретов: доступы к SIEM, EDR, SOAR, аварийные учётные записи, SSH-ключи критичной инфраструктуры. Их чувствительность определяется не только содержимым, но и тем, что они раскрывают — архитектуру защиты и внутреннюю структуру безопасности.

Хранить такие секреты можно двумя способами:

• Для большинства компаний достаточно логической изоляции: одна инсталляция Пассворка с типами сейфов, ролями, MFA, LDAP/SSO и аудитом. Секреты разделены по назначению и владельцам, доступ разграничен через права и группы.
• Физическая изоляция (отдельный экземпляр Пассворка для ИБ-контура) нужна там, где данные должны быть скрыты от администраторов общего контура не только на уровне прав, но и на уровне самого факта существования: названий сейфов, структуры папок и журналов активности.

Физическая изоляция наиболее полно реализует принцип нулевого доверия (Zero Trust) через разделение полномочий. В этой модели ИТ-администраторы полностью исключаются из цепочки доверия, а управление системой переходит исключительно к ИБ-администраторам.

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

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

Какие секреты хранит ИБ-отдел и почему их нельзя смешивать с обычными доступами

ИБ-секреты отличаются от доступов кадрового отдела, финансов или проектных команд не только уровнем критичности, но и характером чувствительности. Компрометация пароля от корпоративного SaaS — это инцидент. Компрометация доступа к SIEM или EDR — это потенциальная потеря контроля над всей защитной инфраструктурой.

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

Какие секреты требуют особого режима хранения

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

Один экземпляр Пассворка с типами сейфов: когда этого достаточно

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

Одна инсталляция — рациональный стандарт по умолчанию. Она проще в эксплуатации: одно обновление, один процесс резервного копирования, одна интеграция с LDAP/AD и SAML SSO, один регламент. При этом уровень контроля над доступом может быть весьма детальным.

Модель типов сейфов

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

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

Пример настройки политик и прав для типов сейфов

Роли и группы позволяют разграничить доступ подразделений без ручной настройки каждого пользователя. Интеграция с AD/LDAP упрощает добавление новых пользователей и отзыв доступов: сотрудник уходит — доступ отзывается через синхронизацию с каталогом. SAML SSO снижает трение при ежедневной работе. MFA и журнал действий обеспечивают контроль.

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

Два независимых экземпляра Пассворка: когда нужна физическая изоляция

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

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

Что даёт физическая изоляция

• Устойчивость к ошибкам. Ошибка в правах доступа в общем корпоративном контуре не раскрывает ИБ-секреты. Контуры физически разделены: некорректная настройка в одном не затрагивает другой.
• Закрытые метаданные. Администраторы общего контура не видят структуру ИБ-сейфов: ни названий, ни папок, ни активности. ИТ-администратор бизнес-экземпляра Пассворка не знает, какие системы и инструменты находятся под управлением ИБ-команды.
• Независимые администраторы. ИБ управляет своим экземпляром самостоятельно без пересечения с ИТ-администраторами общего контура. Каждая команда настраивает свой экземпляр независимо и не имеет прав в чужом контуре.
• Независимые политики. ИБ применяет собственные настройки: более жёсткие требования к MFA, короткий таймаут сессии, запрет офлайн-доступа, ограничения на экспорт, отдельные правила API-доступа — без компромиссов с требованиями бизнес-подразделений.
• Чистый журнал. ИБ-инсталляция фиксирует только события ИБ-команды без фонового шума от финансов, продаж и подрядчиков. Это упрощает расследования и сокращает время на анализ.
• Прозрачность для аудита. Контур проще описывать в документах модели угроз, при прохождении сертификации и внешних аудитов — в том числе по требованиям ФСТЭК и для объектов КИИ. Разделение контуров часто является требованием регулятора.

Когда ИБ-контур требует закрытой сети

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

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

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

Сравнение двух моделей

Локальный ИБ-инстанс и облако для бизнеса

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

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

Разделение доступов

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

Отдельный DevOps/SRE-контур: чем он отличается от ИБ-контура

DevOps-контур изолируется по другим причинам, чем ИБ-контур. ИБ-секреты требуют изоляции из-за конфиденциальности, независимого администрирования и требований к аудиту расследований. DevOps-секреты — из-за автоматизации, высокой частоты ротации, машинного потребления через API, CLI и SDK, а также большого числа интеграций с CI/CD-пайплайнами.

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

Пассворк поддерживает API-first подход, CLI и SDK для работы с секретами, включая сценарии миграции, аудита и CI/CD-интеграций. Подробнее — в разделе документации «Пассворк как менеджер секретов».

Сравнение сценариев

Как выбрать архитектуру: один или два контура

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

Критерии выбора архитектуры хранения секретов

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

Как внедрить выбранную модель

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

1. Классифицировать секреты. Разделить данные на категории: обычные, ИБ-критичные, инфраструктурные, DevOps, аварийные. После этого понятно, какие данные требуют какого уровня изоляции.
2. Определить владельцев. Назначить ответственного бизнес- или технического владельца для каждого типа. У каждой категории секретов появляется ответственный.
3. Оценить чувствительность метаданных. Проверить, где опасны даже названия систем, папок и сейфов. Это покажет, где логической изоляции недостаточно.
4. Определить допустимых администраторов. Решить, кто может управлять контуром и кто не должен иметь технической видимости. Результат: понятная модель доверия и границы администрирования.
5. Выбрать модель. Одна инсталляция, две локальные, локальный ИБ-контур плюс облачный бизнес-контур или отдельный контур разработки. Архитектурное решение принято и обосновано.
6. Спроектировать типы сейфов. Создать целевую структуру сейфов, ролей, групп и правил создания. Итог: схема, которую можно реализовать и задокументировать.
7. Настроить интеграции. LDAP/SSO, MFA, API/CLI/SDK, SIEM, резервное копирование и мониторинг. Каждая интеграция получает чёткие границы и ответственного.
8. Ввести регулярную проверку прав. Проверять права, администраторов, журналы и структуру сейфов после изменений в командах и инфраструктуре.

Правильная архитектура начинается с классификации

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

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

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

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

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

Нужна ли ИБ-отделу отдельная инсталляция Пассворка?

Отдельный инстанс необходим, если ИБ-отдел хранит секреты, которые не должны быть видны администраторам общего контура даже на уровне структуры: доступы к SIEM, EDR, SOAR, сканерам, аварийные доступы, SSH-ключи, API-токены и сервисные пароли. Если таких требований нет, достаточно одной инсталляции с типами сейфов, ролями, MFA и аудитом.

Когда достаточно одной инсталляции Пассворка?

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

Чем физическое разделение лучше настройки прав доступа?

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

Что такое типы сейфов в Пассворке?

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

Может ли администратор общего инстанса видеть ИБ-сейфы?

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

Как разделить личные, командные и инфраструктурные пароли?

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

Как организовать аудит действий ИБ-команды?

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

Какие секреты нельзя хранить в общих сейфах?

В общих сейфах не стоит хранить аварийные учётные записи, root/admin-доступы, токены EDR/SIEM/SOAR, SSH-ключи критичной инфраструктуры, API-ключи облаков и секреты, раскрытие метаданных которых может навредить безопасности.

Как понять, что компании пора переходить от одной инсталляции к двум?

Триггеры перехода: апрет на видимость ИБ-метаданных ИТ-администраторами, требование независимого аудита ИБ-действий, регуляторные требования (ФСТЭК, КИИ), необходимость применения более жестких политик безопасности (MFA, сессии, экспорт) или выделение изолированного DevOps/SRE-контура.

Пассворк 7.1: типы сейфов

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

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

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

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

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

Импортозамещение ИБ-решений (СЗИ): переход на российское ПО

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

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

Пассворк выступил партнёром конференции TAdviser SummIT 2026 — одного из главных ИТ-событий года, посвящённого корпоративной цифровизации, импортозамещению и кибербезопасности. Саммит собрал более 1500 делегатов, ИТ-директоров, архитекторов и ИБ-специалистов ведущих российских компаний.

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

Тренды пленарного заседания: от цифровизации к ИИ-агентам

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

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

Секция ИБ: ИИ наносит удар по слабому звену

Особое внимание на саммите уделили информационной безопасности. Модератор профильной секции, руководитель центра мониторинга кибербезопасности «ДОМ.РФ» Андрей Устюжанин, поделился тревожной статистикой. За прошлый год на информационные ресурсы России было совершено более 217 000 компьютерных атак. Злоумышленники активно используют ИИ, чтобы сократить время подготовки и проведения взломов.

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

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

• Использовать сложные и разные пароли для всех типов учётных записей (включая серверы и коммутационное оборудование)
• Обязательно применять многофакторную аутентификацию (MFA)
• Регулярно (не реже раза в квартал) блокировать неиспользуемые учётные записи и отзывать избыточные права доступа

Пассворк как фундамент корпоративной безопасности

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

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

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

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

Пассворк уже используют крупные игроки рынка, среди которых Группа «Черкизово», МТС Банк, ВкусВилл и Nexign. Участие в TAdviser SummIT 2026 в качестве партнёра секции «Безопасность» позволяет нам оставаться в постоянном диалоге с ИБ-сообществом и развивать продукт в соответствии с реальными вызовами, с которыми ежедневно сталкиваются ИТ-директора и специалисты по защите данных.

Если ваша компания модернизирует ИТ-системы или переходит на отечественный софт, начните с наведения порядка в доступах. Пассворк поможет объединить все пароли и токены в одной защищённой системе. Протестируйте бесплатно

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

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

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

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

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

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

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

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

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

15 мая на площадке GagarinSpace в Москве прошла конференция GetNet — практическое мероприятие для сетевых инженеров, ИБ, ИТ-специалистов и ИТ-руководителей среднего бизнеса. Пассворк выступил партнёром конференции второй год подряд.

О конференции

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

Программа: что обсуждали на GetNet 2026

В этом году программа охватила множество прикладных тем — ниже лишь часть из них:

• NGFW. Разбор того, почему заявленные характеристики межсетевых экранов расходятся с реальной производительностью в боевых режимах. Отдельный блок — практический разбор остановленной атаки как способ проверить, что NGFW действительно защищает, а не просто фильтрует трафик по правилам.
• Масштабирование инфраструктуры. Типовые технические и бизнес-проблемы при резком росте нагрузки: где закладываются будущие кризисы и как их предотвратить до того, как они проявятся в продакшене.
• Превентивный мониторинг — как «слепые зоны» по CPU, памяти, дискам и сетевым каналам превращаются в каскадные сбои. Инструменты: Zabbix, Prometheus, Grafana, ELK, Loki, Ansible.
• Автоматизация конфигураций — как привести RouterOS к целевому состоянию через annet без лишних команд и ручной сверки с эталоном.
• Автоматизация настройки VLAN — инструменты MVRP, dot1x и интерфейс-листы на оборудовании MikroTik: нюансы, риски и границы применимости.
• Внутренние уязвимости в eCommerce — реальные кейсы: утечки через уязвимый браузер в контакт-центре, открытые репозитории с сертификатами, секреты в CI/CD-пайплайнах. Периметровая защита эти угрозы не закрывает.
• Тестирование отечественного оборудования — 5-шаговая методология: от одиночного устройства до комплексной проверки отказоустойчивости. Принцип — перенести риски с продакшена в лабораторию до закупки.
• Отказоустойчивые сети для среднего бизнеса — практические архитектуры высокой доступности при ограниченном бюджете и без выделенных сетевых специалистов.

Пассворк на GetNet

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

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

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

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

Пассворк в документации Яндекс Облака: настройка SSO через Yandex Identity Hub

Яндекс Облако опубликовало пошаговое руководство по настройке SSO для Пассворка через Yandex Identity Hub. Разбираем, что такое Identity Hub, как устроена интеграция и что это даёт бизнесу.

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

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

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

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

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

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

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