Гайды

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

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

Лишние права создают два риска:

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

О внешнем риске говорит статистика. По данным Solar 4RAYS, в первом полугодии 2025 года 40% расследованных целевых атак начинались со скомпрометированных учётных записей. Если у сотрудника есть доступ только к тому, что нужно для работы, взлом его записи ограничится этим набором паролей. Три механизма позволяют провести такие границы внутри общего хранилища.

Три слоя разграничения прав доступа в Пассворке

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

• Роль управляет доступом к функциям и настройкам системы.
• Группа с уровнем доступа открывает конкретные сейфы и папки.
• Тип сейфа задаёт правила, по которым создаются и администрируются все сейфы одной категории.

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

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

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

Роли: кто и что может делать в системе

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

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

• Общие — история действий, доступ к разделам «Политики паролей», «Настройки SSO», «Фоновые задачи» и «Информация о лицензии».
• Системные настройки — отдельные блоки системных настроек.
• Сейфы — вкладки раздела «Управление сейфами».
• Настройки LDAP — серверы, списки групп, синхронизация.
• Управление пользователями — пользователи, группы и приглашения.
• Роли — просмотр и изменение ролей.
• Офлайн-доступ — офлайн-копии записей в приложениях.
• Аккаунт — интерфейс, API, приложения и браузерное расширение.
• Аутентификация — срок сессии и токенов, обязательная двухфакторная аутентификация (2FA), ключи безопасности.

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

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

Группы и уровни доступа: кто видит данные

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

Шесть уровней доступа

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

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

Группы из каталога Active Directory можно сопоставлять с группами Пассворка. Для каждой группы AD можно указать одну или несколько групп. Так пользователи из определённой группы будут автоматически получать нужные права.

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

Наследование по папкам

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

Два уровня ведут себя иначе. «Запрещён» и «Администрирование» наследуются вниз без возможности изменения: запрет нельзя снять на вложенной папке, администратора нельзя понизить уровнем ниже.

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

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

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

Собственный тип настраивают по четырём параметрам:

• Название — например, «ИТ-инфраструктура», «Финансы», «Проекты подрядчиков».
• Администраторы — пользователи, которые автоматически добавляются и получают доступ «Администрирование» во всех сейфах типа. Пока они в списке, их нельзя удалить из сейфа или понизить в правах.
• Доступ создателя сейфа — уровень, который получает сотрудник, создавший сейф. Например, «Полный доступ» разрешает работать с сейфом, но не приглашать в него других.
• Право на создание сейфа — конкретные пользователи, группы, роли или все сотрудники.

Преимущества типов сейфов

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

Как Пассворк определяет итоговый доступ сотрудника

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

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

Политики паролей: какие пароли допустимы в каждом сейфе

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

У каждой записи и директории ровно одна политика, и она действует на все парольные поля записи, включая дополнительные поля типа «Пароль». Изменение политики сразу применяется ко всем записям, где она назначена. Наследование здесь мягче, чем у прав: политику можно заменить на любом вложенном уровне, а «Запрещён» и «Администрирование» ниже не меняются.

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

Как спланировать структуру доступа до внедрения

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

План структуры доступа в восемь шагов:

1. Инвентаризируйте учётные данные — выясните, где сейчас лежат пароли, и разделите их по категориям риска: инфраструктура, финансы, рабочие сервисы, личные.
2. Определите типы сейфов — под каждую категорию или отдел свой тип, у каждого типа назначены корпоративные администраторы.
3. Решите, кто создаёт сейфы — безопаснее начать с централизованного создания и открывать это право по мере роста.
4. Повторите оргструктуру в группах — если есть Active Directory, сопоставьте группы каталога с группами Пассворка.
5. Настройте роли — отделите администрирование системы от доступа к данным.
6. Назначьте политики паролей — строгие на привилегированные сейфы, «Базовую» на остальные.
7. Импортируйте данные в готовую структуру — записи, загруженные в систему без типов и групп, потом придётся раскладывать вручную.
8. Назначьте пересмотр — например, раз в квартал проверяйте подключения к сейфам, неактивные группы и записи, которые Панель безопасности отмечает как «слабые» и «старые».

Частые ошибки при разграничении прав доступа

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

• Один сейф на всю компанию — любой сотрудник видит пароли не из своей зоны, а при увольнении приходится менять всё. Разделите сейфы по отделам и задачам.
• У всех роль «Администратор» — каждый может изменить критичные настройки, и непонятно, кто за что отвечает. Оставьте роль «Администратор» двум-трём людям, остальным дайте «Сотрудник» или создайте отдельную роль с нужными правами для задач сотрудника.
• Привилегированные и повседневные доступы в одном сейфе — пароли от серверов видят люди, которым нужна была только почта. Выносите инфраструктуру в отдельный сейф с собственной группой, при необходимости с отдельным типом сейфа.
• Уровень доступа выдают «с запасом» — «Администрирование» или «Полный доступ» ставят, чтобы не возвращаться к вопросу. Но «Полный доступ» разрешает и удаление записей. Начинайте с «Только чтение» или «Редактирование», повышайте уровень под конкретную задачу и на конкретный срок.
• Доступ без срока и пересмотра — подрядчики и сотрудники, сменившие отдел, годами сохраняют права. Назначьте регулярную сверку: раз в квартал сравнивайте состав групп с оргструктурой и списком действующих подрядчиков. Для подрядчиков заводите временные группы и отключайте их по окончании проекта.
• Структуру знает один администратор — его отпуск или уход останавливает выдачу доступа. Назначьте руководителей отделов администраторами их сейфов или типов сейфов и зафиксируйте схему прав в документе.
• Журнал действий ведётся, но его никто не смотрит — без регулярного просмотра он нужен только после инцидента, когда поздно. Назначьте ответственного, настройте выгрузку в SIEM и определите, какие события требуют реакции.

Разграничение прав доступа нужно поддерживать после настройки

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

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

Часто задаваемые вопросы о разграничении прав в Пассворке

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

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

Для кого расширенная версия Пассворка

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

• Малый и средний бизнес. Подрядчики получают доступ только к нужным сейфам, а отказоустойчивость защищает от простоя при сбое сервера.
• Крупный бизнес и холдинги. Группы AD/LDAP сопоставляются с группами в Пассворке, вход идёт через SAML SSO, управление доступом делегируется отделам. Администратор видит, кто и что делает.
• Государственные организации. Журнал событий фиксирует действия с паролями. Репликация и отказоустойчивость нужны для непрерывной работы критичных систем.
• ИТ-компании. API-ключи и токены хранятся в сейфах, а пайплайны CI/CD обращаются к ним через сервисные аккаунты. Распределённым командам доступ выдаётся по группам.
• Банки и финансовые организации. Обязанности разделены по ролям: отдельные администраторы пользователей и безопасности, а аудитор не может менять данные.
• Промышленные и распределённые компании. Для площадок и филиалов заводятся отдельные типы сейфов. Выездным инженерам и изолированным сегментам нужен офлайн-доступ.
• ИБ-отделы и комплаенс. Политики паролей задаются под разные категории систем. Панель безопасности показывает слабые и устаревшие пароли, журнал событий нужен для аудита.

Чем расширенная версия Пассворка отличается от стандартной

Стандартная версия закрывает хранение паролей и совместную работу с ними. Расширенная добавляет SAML SSO, синхронизацию с AD/LDAP, собственные типы сейфов и роли, политики паролей, сервисные аккаунты, офлайн-доступ и отказоустойчивость. Офлайн-доступ появился в версии 7.7, политики паролей в версии 7.8.

Если вам нужен сертифицированный продукт для ГИС, КИИ или ИСПДн, смотрите отдельную версию Пассворка, сертифицированную ФСТЭК.

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

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

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

Сравнение: до и после внедрения типов сейфов

Что меняется для администратора

Администраторы типа попадают в новые сейфы автоматически, а структуру доступа видно по типам. Ручная выдача прав сокращается, аудит становится проще.

Аутентификация через единый вход (SSO)

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

Преимущества

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

Результат

Централизованное и автоматизированное управление доступом освобождает ИТ-отдел от рутинных задач и исключает человеческий фактор.

Сопоставление групп из AD/LDAP с группами Пассворка

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

Как работает синхронизация

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

Сценарий применения

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

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

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

Сравнение со стандартной версией

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

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

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

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

Права настроены так, что никто не изменит критичные настройки случайно и не получит доступ к данным за пределами своей зоны ответственности.

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

Политики паролей: разные требования для разных сейфов

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

Для чего нужны политики паролей

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

• Требования по уровню риска. Для сейфа с доступами к инфраструктуре и базам данных задают строгую политику, например длину от 16 символов и срок действия 60 дней. Остальным сейфам оставляют «Базовую».
• Наследование. Политику назначают на папку, и она действует на все вложенные. На любом уровне её можно заменить другой.
• Контроль слабых паролей. Пароль, который не проходит политику, попадает в Панели безопасности в категорию «слабые», а с истёкшим сроком в категорию «старые». Администратор может запретить сохранять запись, пока пароль не соответствует политике.
• Подготовка к аудиту. ИБ-отдел заводит политики под категории систем и назначает их на нужные сейфы, поэтому требования действуют в системе и дополняют регламент.

Сравнение со стандартной версией

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

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

Для чего нужны сервисные аккаунты

• Один аккаунт на несколько интеграций. Отдельный API-токен заводят под каждую интеграцию и среду, не создавая под них новые учётные записи.
• Независимый отзыв. Токен одной интеграции отзывают, не трогая остальные: они продолжают работать без изменений.
• Меньше точек контроля. Администратор управляет всеми токенами из одной точки, не входя в каждый аккаунт отдельно.
• Прозрачность для аудита. Учётных записей для интеграций меньше, значит, проще аудит и быстрее реакция на инцидент.

Сравнение со стандартной версией

Офлайн-доступ: пароли без связи с сервером

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

Сравнение со стандартной версией

Настройка репликации и отказоустойчивое решение

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

Для организаций, где потеря доступа к паролям останавливает работу отделов, это основное условие надёжности

Как это работает

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

Что даёт отказоустойчивая схема

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

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

Неограниченное количество ярлыков для паролей

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

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

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

Что меняется в общих доступах

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

Оптимизация бюджета

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

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

Следующий шаг: протестируйте расширенную версию

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

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

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

Попробуйте Пассворк бесплатно: разверните расширенную версию на своём сервере и проверьте SSO, синхронизацию с AD, сервисные аккаунты, политики паролей и офлайн-доступ на своих задачах → passwork.ru

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

Чем расширенная версия Пассворка отличается от стандартной?

Расширенная версия добавляет к стандартной SAML SSO, синхронизацию групп из AD/LDAP, неограниченные типы сейфов и роли, сервисные аккаунты, отказоустойчивую схему, собственные политики паролей и офлайн-доступ. В стандартной версии два типа сейфов, ограниченное число ролей и одна политика паролей, «Базовая». Выбор зависит от числа администраторов, интеграций и требований к доступности.

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

Создайте политики в разделе «Политики паролей» меню «Настройки и пользователи», затем назначьте нужную на сейф или папку через пункт «Изменить политику»: потребуется уровень доступа «Администрирование». Вложенные папки наследуют политику родителя. Политика «Базовая» назначена всем записям по умолчанию, её можно перенастроить, но нельзя удалить.

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

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

Что такое сервисные аккаунты и зачем они нужны?

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

Что такое типы сейфов и зачем они нужны?

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

Можно ли установить Пассворк на собственный сервер?

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

Как работает интеграция с Active Directory?

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

Есть ли API у расширенной версии?

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

Можно ли попробовать расширенную версию бесплатно?

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

Можно ли купить подписку на несколько лет?

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

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

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

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

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

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

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

Пассворк 7.8: политики паролей

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

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

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

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

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

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

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

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

Политики паролей в релизе Пассворк 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: управляемый офлайн-доступ

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

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

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

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

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

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

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

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

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

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

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

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

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

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 год.

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

У ИБ-отдела особый класс секретов: доступы к 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 управление доступом стало более гибким благодаря системе типов сейфов. Типы сейфов решают главную проблему администраторов — как контролировать доступ к данным и делегировать управление сейфами в большой компании. Ранее выбор был ограничен двумя типами. Теперь можно создавать собственные типы сейфов под любые задачи и структуру

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

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

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

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

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

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

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

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

Сервисные аккаунты

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

Зачем нужен сервисный аккаунт

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

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

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

Как создать сервисный аккаунт

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

Как создать API-токен

Токены создаются и отзываются в настройках конкретного сервисного аккаунта.

Новые настройки ролей

В настройках ролей появились новые права:

• Создание сервисных аккаунтов — разрешает создавать сервисные аккаунты
• Управление API-токенами — позволяет генерировать и отзывать токены
• Просмотр API-токенов — позволяет видеть созданные токены

Сохранение фильтров

Теперь пользователи могут сохранять выбранные фильтры и быстро применять их повторно. Сохранённые фильтры доступны только создавшему их пользователю.

Чтобы сохранить текущие настройки фильтров, нажмите на кнопку + в меню выбора фильтров.

Автоматическая очистка Корзины

В настройках сейфов появился новый блок «Корзина», где можно включить автоматичкое удаление объектов из Корзины и задать срок их хранения — от 1 до 1461 дня (по умолчанию 30 дней).

По истечении срока хранения пароли, папки и ярлыки удаляются из Корзины безвозвратно.

Мобильная версия веб-интерфейса

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

Улучшения

• Улучшили работу ссылок: страница с одноразовой или истёкшей ссылкой теперь автоматически переходит в состояние «Ссылка истекла» через 30 минут после открытия или истечения без необходимости обновлять страницу
• Кнопка «Войти с ключом доступа» на странице входа теперь скрывается, если для всех ролей отключена настройка «Использование ключа доступа вместо пароля»
• Упростили подключение браузерного расширения: убрали лишние шаги с выбором пользователя и повторной аутентификацией после входа в веб-сессию
• Улучшили отображение состояние блокировки раздела «Аутентификация»
• Изменили значения по умолчанию для политик мастер-пароля и блокировки аутентификации
• Добавили недостающие всплывающие подсказки для неактивных элементов интерфейса
• Обновили отображение всплывающих подсказок для улучшения читаемости
• Внесли улучшения и исправления в интерфейс

Исправления

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

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

• Добавили поддержку нестандартных портов в URL-адресе хоста
• Улучшили механизм обновления приложения и добавили автоматическую проверку актуальной версии

Приказ ФСТЭК № 117: разбор изменений, Кзи и штрафов

С 1 марта 2026 года Приказ ФСТЭК № 17 утратил силу. Его заменил Приказ № 117 с числовыми метриками КЗИ и ПЗИ, жёсткими сроками устранения уязвимостей и расширенной зоной ответственности. В статье рассмотрим, что изменилось и как подготовиться.

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

Киберугрозы марта 2026: инциденты, штрафы и защита данных

Первые оборотные штрафы за утечки. Zero-click уязвимость в Telegram. Каскадная атака через Trivy. Шифровальщик в европейском порту. Новые требования ФСТЭК и КИИ. В статье — разбор ключевых инцидентов, изменений в законодательстве и конкретных шагов по защите корпоративных доступов.

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

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

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

Ваш сисадмин пересылает SSH-ключи через мессенджер в файле «точнонепароли.txt». Ваш HR-менеджер хранит сканы паспортов сотрудников в личной почте в Яндексе. Стажёру выдали права администратора, потому что разбираться с разграничением доступа было некогда. А сотрудник, которого уволили в 2019 году, до сих пор получает еженедельную рассылку с данными клиентов, ведь его электронный адрес просто никто не удалил.

В 2025 году аналитики зафиксировали 230 публичных утечек баз данных российских организаций, а суммарный объём опубликованных данных достиг 767 млн строк — в 1,5 раза больше, чем годом ранее. Большинство инцидентов начинаются одинаково: сотрудник хранит пароль в таблице, браузере или мессенджере. Злоумышленник получает учётные данные, и дальше всё происходит по известному сценарию.

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

Риски хранения паролей в ненадёжных инструментах

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

• Пароли CRM в Excel на сетевом диске. Файл доступен всем, у кого есть доступ к папке. Версионирования нет. Непонятно, кто и когда менял пароль. Результат: бывший менеджер через полгода заходит в CRM и выгружает базу клиентов.
• Доступы передают в чате. Пароль уходит в мессенджер или корпоративную почту и остаётся там навсегда. История переписки не шифруется, не удаляется и доступна всем участникам чата. Через год канал взломали: злоумышленники получили всю историю, включая административные доступы.
• Облачные доступы в памяти администратора. Если сотрудник увольняется или уходит на больничный, доступ теряется вместе с ним. Кейс: единственный человек, знавший пароль от DNS-провайдера, уволился. Компания потеряла контроль над доменом на три дня.
• Нет контроля и аудита. Невозможно ответить: кто заходил в систему, когда и откуда. После утечки из бухгалтерской системы выяснилось, что доступ использовали пять человек с одного логина. Установить виновного оказалось невозможно.
• Пароли в браузере на рабочем ПК. Сотрудники сохраняют доступы в Chrome или Firefox без мастер-пароля. При заражении устройства вредоносным ПО все сохранённые пароли извлекаются за секунды.
• Повторное использование одного пароля. Один и тот же пароль применяют для разных систем: от корпоративной почты до панели управления сервером. Компрометация одного сервиса автоматически открывает доступ ко всем остальным.

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

Масштаб проблемы подтверждается цифрами. Учётные данные остаются одним из главных векторов атак. Около 88% инцидентов в мире в категории атак на веб-приложения связаны с использованием украденных учётных данных. Средняя стоимость утечки данных в мире составляет около $4,44 млн, включая расследование, простои систем, юридические расходы и восстановление инфраструктуры.

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

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

Регуляторный контекст 2026

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

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

Для субъектов КИИ и операторов ИСПДн, обрабатывающих данные 1–3 уровня защищённости, критически важна сертификация ФСТЭК используемых средств защиты информации. Сертификат подтверждает соответствие продукта требованиям регуляторов и является обязательным условием для прохождения аудитов безопасности.

Приказ ФСТЭК России № 117

1 марта 2026 года вступил в силу приказ ФСТЭК России № 117 от 11 апреля 2025 года. Документ пришёл на смену приказу № 17 от 11 февраля 2013 года и расширил сферу регулирования. Прежние требования распространялись на государственные информационные системы (распространение на муниципальные ИС было закреплено отдельным разъяснением ФСТЭК, а не текстом самого приказа).

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

Ответственность за утечки персональных данных

С 30 мая 2025 года вступили в силу поправки, внесённые Федеральным законом № 420-ФЗ от 30 ноября 2024 года в КоАП РФ, которые существенно ужесточили ответственность за утечки персональных данных. Согласно КоАП РФ в действующей редакции, штраф за первичную утечку для юридических лиц составляет от 3 до 20 млн рублей в зависимости от масштаба инцидента и категории данных (максимум — за утечку биометрических данных); за повторную утечку предусмотрен оборотный штраф в размере от 1% до 3% годовой выручки, но не менее 20 млн рублей и не более 500 млн рублей.

С чего начать внедрение менеджера паролей

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

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

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

Шаг 1. Аудит

Масштаб инвентаризации определяет архитектуру решения и объём лицензии. Компания, в которой считают, что в работе 200 учётных записей, после аудита обнаруживают 340, с учётом сервисных аккаунтов, тестовых сред и давно забытых интеграций.

Чек-лист предпроектного аудита

Цель аудита — получить полную картину до того, как будет принято любое архитектурное решение. Чек-лист охватывает шесть областей.

1. Инвентаризация всех корпоративных учётных записей: сервисы, серверы, SaaS-приложения, сетевое оборудование. Цель — полный реестр, без исключений.
2. Выявление «теневых» аккаунтов: личные облачные сервисы для рабочих задач, неучтённые подписки — всё, что создано без ведома ИТ-отдела. Именно здесь чаще всего обнаруживаются неожиданные цифры.
3. Подсчёт привилегированных учётных записей: admin, root, сервисные учётные записи и записи с правами доступа к критическим системам.
4. Анализ текущих практик хранения: опрос сотрудников на предмет использования таблиц, блокнотов, стикеров, браузерных менеджеров паролей, мессенджеров, личных сервисов для хранения данных.
5. Оценка количества общих паролей: один логин на несколько сотрудников (типично для Wi-Fi, принтеров, общих почтовых ящиков, соцсетей).
6. Проверка процедуры увольнения: сколько времени фактически занимает отзыв всех доступов при увольнении. Зафиксируйте реальную цифру.

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

Инструменты для инвентаризации

• AD/LDAP-запросы. Базовый инструмент для любой организации с Active Directory или LDAP-каталогом. Даёт выгрузку всех пользователей и групп с атрибутами: дата последнего входа, статус учётной записи, членство в группах. Учётные записи без активности за последние 90 дней — первые кандидаты на деактивацию. Отдельно стоит выгрузить сервисные аккаунты: они часто не привязаны к конкретному сотруднику и выпадают из регулярных проверок.
• Анализ логов. Логи прокси-сервера и корпоративной почты позволяют обнаружить активность аккаунтов уволенных сотрудников и нетипичные паттерны доступа — например, подключения в нерабочее время или с нестандартных адресов. Это отдельный слой данных, который AD-запросы не покрывают.
• SIEM и системы мониторинга. Если в инфраструктуре уже развёрнут SIEM, он агрегирует события из множества источников и позволяет построить сводную картину по учётным записям быстрее, чем ручная выгрузка из каждой системы по отдельности.
• Опрос руководителей подразделений. Технические инструменты не видят сервисы, которые отделы подключают самостоятельно в обход ИТ. Короткий структурированный опрос с тремя вопросами: какие внешние сервисы использует отдел, кто имеет к ним доступ, где хранятся учётные данные — закрывает этот пробел. Ответы руководителей нередко становятся главным источником данных о теневых аккаунтах.
• Сканирование SaaS-активности. Корпоративные SSO-решения ведут журнал подключённых приложений.

Шаг 2. Выбор решения для хранения паролей

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

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

Локальное развёртывание или облако

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

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

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

Интеграция со службами каталогов и SSO

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

Интеграция с AD/LDAP также упрощает управление ролями. Группы из каталога напрямую интегрируются с ролями в корпоративном менеджере паролей. Изменение состава группы в AD мгновенно отражается в правах доступа.

Поддержка Single Sign-On (SSO) позволяет сотрудникам входить в менеджер паролей через корпоративную учётную запись, не создавая отдельного пароля.

Ролевая модель (RBAC)

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

Ролевая модель на основе RBAC (Role-Based Access Control) позволяет назначать права не каждому пользователю отдельно, а ролям — и затем присваивать роли пользователям.

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

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

Наиболее распространённый второй фактор — TOTP (Time-based One-Time Password): одноразовый код из приложения-аутентификатора, который обновляется каждые 30 секунд. Это надёжный и удобный вариант, не требующий дополнительного оборудования. Для организаций с повышенными требованиями к безопасности предпочтительнее аппаратные ключи — FIDO2/WebAuthn-устройства, которые физически невозможно перехватить удалённо.

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

Аудит и логирование

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

API и интеграции

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

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

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

Реестр российского ПО

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

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

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

Сертификат ФСТЭК России

Сертификат соответствия ФСТЭК России подтверждает, что средство защиты информации прошло обязательную оценку и соответствует требованиям регулятора по защите конфиденциальной информации. Для субъектов КИИ и операторов ИСПДн, обрабатывающих данные 1–3 уровня защищённости, наличие сертификата ФСТЭК у используемых СЗИ является обязательным требованием.

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

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

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

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

• Независимая проверка безопасности. Безопасность Пассворка верифицируют 30 000 независимых экспертов на платформе Standoff Bug Bounty. Это программа вознаграждения за найденные уязвимости, один из наиболее честных способов подтвердить реальный уровень защиты продукта.
• Реальные внедрения в крупном бизнесе. Среди клиентов — МТС Банк, который внедрил Пассворк для централизованного управления паролями и повышения уровня безопасности, Nexign — один из крупнейших российских разработчиков телеком-решений.
• Признание рынка. В 2025 году Пассворк стал победителем премии ComNews Awards в категории «Лучшее решение для работы с паролями в компании», в 2026 — получил «ТБ Премию 2026», эксперты признали продукт надёжным корпоративным решением для безопасного хранения и управления секретами.

Пассворк разворачивается на серверах компании, интегрируется с Active Directory и LDAP и даёт ИТ-отделу полный контроль над учётными данными. Протестируйте Пассворк в своей инфраструктуре бесплатно

Шаг 3. Техническое развёртывание

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

План развёртывания

1. Подготовка инфраструктуры. Выделить сервер, настроить сетевую сегментацию — хранилище паролей не должно быть доступно из интернета напрямую.
2. Установка приложения. Docker-контейнер — предпочтительный вариант: изолированная среда, простое обновление, воспроизводимая конфигурация. Нативная установка используется там, где Docker недоступен по политике безопасности.
3. Первоначальная конфигурация. Настройка подключения к базе данных, генерация мастер-ключа шифрования. Мастер-ключ хранится отдельно от базы данных, это критичное требование, которое часто игнорируют при быстром развёртывании.
4. Настройка резервного копирования. Ежедневный бэкап зашифрованного хранилища на отдельный сервер или в изолированное хранилище. Настроить нужно до миграции данных.
5. Интеграция с AD/LDAP. Синхронизация пользователей и групп. Проверить, что группы Active Directory корректно сопоставлены с ролями в менеджере паролей.

Тестирование и приёмка: проверить доступность интерфейса, корректность синхронизации с AD, успешность первого резервного копирования. Только после успешного прохождения всех проверок переходить к Шагу 4.

Шаг 4. Настройка системы

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

Структура хранилища

Хранилище паролей должно отражать реальную организационную схему компании. Базовый принцип — разделение по подразделениям и типам доступа. Типовая структура: отдельные сейфы для ИТ-инфраструктуры, финансов, кадров, маркетинга. Внутри каждого сейфа — папки по проектам, сервисам или средам (production, staging, dev).

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

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

Системные настройки

• Первое — управление сессиями. Установите таймаут автоматического выхода: 15–30 минут бездействия — разумный баланс между безопасностью и удобством. Для администраторов таймаут стоит сократить.
• Второе — ограничения по IP и устройствам. Если менеджер паролей используется только внутри корпоративной сети, ограничьте доступ на уровне сетевых политик. Это дополнительный барьер, который не требует изменений в самом приложении.
• Третье — многофакторная аутентификация. Подключите TOTP-приложение или аппаратный ключ в настройках безопасности. Сделайте многофакторную аутентификацию обязательной на уровне политики: система не должна разрешать вход без второго фактора ни одному пользователю, включая администраторов.

Роли и права доступа

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

Сопоставьте роли с группами Active Directory, если интеграция настроена. Это позволит автоматически назначать права при онбординге новых сотрудников — без ручных действий администратора при каждом новом найме.

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

Шаг 5. Миграция и онбординг

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

Вариант 1: первый менеджер паролей

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

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

Вариант 2: переход с другого менеджера паролей

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

Запустите параллельную работу двух систем на 1–2 недели. За это время сотрудники убедятся, что все данные перенесены корректно, — и только после этого отключайте старую систему.

Онбординг сотрудников

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

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

Канал поддержки. В первую неделю выделите отдельный канал в корпоративном мессенджере, где ИТ-специалисты смогут оперативно отвечать на вопросы. Это снижает сопротивление и формирует привычку работать с системой.

Шаг 6. Мониторинг и аудит

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

Квартальное ревью доступов

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

Интеграция с SIEM

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

• Сценарий 1 — вход в нерабочее время.
  Попытка аутентификации в хранилище в 3:00 + VPN-соединение с нетипичного IP-адреса. Каждое событие по отдельности — не критично. Вместе — сигнал для немедленного расследования.
• Сценарий 2 — массовая выгрузка перед увольнением.
  Сотрудник экспортировал значительное количество записей за 48 часов до подачи заявления об уходе. Журнал аудита фиксирует каждую операцию экспорта с временной меткой и идентификатором пользователя.
• Сценарий 3 — брутфорс мастер-пароля.
  Серия неудачных попыток входа с одного устройства за короткий промежуток времени. SIEM коррелирует это с аналогичными попытками в других корпоративных системах.

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

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

• Резервные копии создаются ежедневно в автоматическом режиме
• Копии хранятся в изолированном месте, отдельном от основного сервера
• Восстановление из резервной копии проверяется минимум раз в квартал — не теоретически, а практически

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

Заключение

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

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

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

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

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

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

Нужно ли менять все пароли перед миграцией в новое хранилище?

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

Подходит ли корпоративный менеджер паролей для госсектора и субъектов КИИ?

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

Что происходит с доступами при увольнении сотрудника?

При настроенной интеграции с AD/LDAP деактивация учётной записи в Active Directory автоматически отзывает доступ к хранилищу. Пассворк формирует список паролей, к которым имел доступ сотрудник, — их необходимо сменить в течение 24 часов. Целевое время полного офбординга — менее четырёх часов с момента увольнения.

Насколько безопасно хранить все пароли в одном месте?

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

Как менеджер паролей помогает при проверке регулятора?

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

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

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

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

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

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

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

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

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

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

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

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

Почему это важно для бизнеса?

• Безопасное централизованное хранение секретов. Все конфиденциальные данные хранятся в едином защищённом репозитории, что исключает риск их размещения в открытых файлах, скриптах или исходном коде и минимизирует вероятность несанкционированного доступа и утечек.
• Гибкое управление доступом и делегирование прав. Система позволяет детально настраивать права доступа к каждому секрету на уровне пользователей, групп или сервисных аккаунтов, обеспечивая принцип минимальных привилегий (least privilege) и сокращая поверхность атаки за счёт ограничения доступа.
• Аудит и мониторинг обращений к секретам. Все операции с секретами фиксируются: кто, когда и к чему обращался, какие изменения были внесены. Это облегчает соответствие требованиям регуляторов и прозрачность процессов безопасности.
• Автоматизация ротации и обновления секретов. Регулярная автоматическая смена паролей, ключей и других секретов по заданному расписанию или при возникновении событий (например, компрометации) экономит время ИТ-специалистов.
• Интеграция с DevOps-процессами и инфраструктурными компонентами. Секреты доступны через API, CLI, SDK и плагины, что позволяет интегрировать систему управления секретами с CI/CD пайплайнами, облачными сервисами, контейнерными платформами и базами данных.
• Снижение рисков утечки и компрометации данных. Централизованный контроль и автоматизация процессов позволяют оперативно реагировать на инциденты, быстро отзывать и обновлять уязвимые секреты, предотвращая распространение угроз внутри корпоративной среды.

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

Пассворк: больше, чем менеджер паролей

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

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

Другими словами, Пассворк теперь сочетает в себе два полноценных продукта и направления:

1. Менеджер паролей — удобный пользовательский интерфейс для безопасного хранения и совместного использования учётных данных внутри команды.
2. Система управления секретами — программный доступ для разработчиков и администраторов через REST-API, Python-коннектор, CLI и Docker-контейнер, позволяющие автоматизировать работу с секретами в скриптах, сервисах и DevOps-процессах.

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

API как основа интеграции

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

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

Инструменты для разработчиков и DevOps

Python-коннектор

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

Ключевые преимущества:

• Простота интеграции. Все базовые операции сведены к методам вроде create_item, get_item, create_vault, что избавляет от ручной работы с HTTP-запросами.
• Безопасность на клиенте. Шифрование, расшифровка и работа с мастер-ключом выполняются в библиотеке, секреты защищены даже при работе с открытым API.
• Управление сессиями. Коннектор автоматически сохраняет и восстанавливает токены, а также обновляет истекший accessToken через refreshToken.
• Гибкость. Универсальный метод call() позволяет обращаться к любым эндпоинтам, даже если они не покрыты стандартными методами коннектора.

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

from passwork_client import PassworkClient

client = PassworkClient(host="https://passwork.example.com")
client.set_tokens("ACCESS_TOKEN", "REFRESH_TOKEN")  # передаём токены
client.set_master_key("MASTER_KEY")  # мастер-ключ для расшифровки

# создание хранилища и пароля
vault_id = client.create_vault(vault_name="DevOps", type_id="vault_id_type")
password_data = {
    "Name": "Database PROD", 
    "vaultId": vault_id,
    "title": "DB prod",
    "login": "admin",
    "password": "secure-password",
    "url": "https://db.example.com"
}
password_id = client.create_item(password_data)

# получение и использование пароля
secret = client.get_item(password_id)
print(secret['password'])

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

CLI-утилита

Passwork CLI — командная утилита для получения секретов и работы с API из shell-скриптов и CI/CD.

Режимы работы:

1. exec — извлекает секреты, создаёт для них переменные окружения и запускает указанный процесс. Пароли нигде не сохраняются и доступны только во время выполнения.
2. api — выполняет произвольные методы API и выводит ответ в JSON.

Полезно для:

• Безопасного подключения к базам данных и сервисам — пароль подставляется через переменные окружения и не хранится на диске.
• Автоматизации развёртывания и CI/CD — секреты автоматически подгружаются в пайплайне;
• Администрирования серверов — временные переменные позволяют выполнять задачи от имени сервисных учётных записей;
• Интеграции с DevOps-инструментами — легко сочетается с Ansible, Terraform и другими решениями.

Для аутентификации можно использовать флаги (--host, --token, --master-key) либо переменные окружения PASSWORK_HOST, PASSWORK_TOKEN и PASSWORK_MASTER_KEY.

Пример exec
Резервное копирование PostgreSQL. CLI создаст переменную окружения PGPASSWORD и запустит pg_dump:

export PASSWORK_HOST="https://passwork.example.com"
export PASSWORK_TOKEN="your_access_token"
export PASSWORK_MASTER_KEY="your_master_key"

passwork-cli exec --password-id "5f8a7b6c9d0e1f2a3b4c5d6e" \
  pg_dump -h localhost -U username -d database > backup.sql

Пример multi-secret
Запуск скрипта, которому нужны три секрета:

passwork-cli exec \
  --password-id "db123,api456,storage789" \
  deploy.sh --db-pass=$DATABASE_PASSWORD --api-key=$API_KEY --storage-key=$STORAGE_KEY

Пример api
Получить список сейфов:

passwork-cli api --method GET --endpoint "v1/vaults"

CLI поддерживает фильтрацию по тегам и папкам, работу с пользовательскими полями, обновление токенов, временную деактивацию SSL-проверки (только для тестовой среды с флагом --no-ssl-verify).

Docker-контейнер

Для CI/CD подготовлен Docker-образ passwork/passwork-cli. Он содержит предустановленный CLI и запускается от непривилегированного пользователя.

Укажите переменные окружения и запустите команду:

docker run -it --rm \
  -e PASSWORK_HOST="https://passwork.example.com" \
  -e PASSWORK_TOKEN="your_access_token" \
  -e PASSWORK_MASTER_KEY="your_master_key" \
  passwork-cli exec --password-id "db_password_id" mysql -h db_host -u admin -p $DB_PASSWORD db_name

Образ удобен в пайплайнах Bitbucket или GitLab — достаточно указать переменные окружения и выполнить команду passwork-cli exec. Можно использовать docker-compose и пробрасывать секреты другим контейнерам.

Использование секретов в приложениях

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

Пример:

1. В Пассворке создаётся запись DB_PASSWORD
2. В пайплайне запускается команда:

passwork-cli exec --password-id "<id_секрета>" --cmd "node server.js"

3. CLI создаёт переменную DB_PASSWORD и запускает node server.js. Приложение читает пароль из process.env.DB_PASSWORD.

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

Автоматизация ротации паролей

Регулярная смена паролей снижает риск компрометации. Сценарий автоматизации с Python-коннектором:

1. Получить текущий пароль из Пассворка (get_item)
2. Сгенерировать новый пароль
3. Изменить пароль в базе данных (ALTER USER)
4. Обновить запись в Пассворке (update_item)
5. Уведомить команду о завершении

Псевдокод:

from passwork_client import PassworkClient
import secrets
import psycopg2

def rotate_db_password(passwork_host, accessToken, refreshToken, master_key, password_id, db_params):
    client = PassworkClient(passwork_host)
    client.set_tokens(accessToken, refreshToken)
    client.set_master_key(master_key)
    
    secret = client.get_item(password_id)
    current_password = secret['password']
    new_password = secrets.token_urlsafe(32)
    
    conn = psycopg2.connect(
        dbname=db_params['db'], 
        user=db_params['user'],
        password=current_password, 
        host=db_params['host']
    )
    
    with conn.cursor() as cur:
        cur.execute(f"ALTER USER {db_params['user']} WITH PASSWORD '{new_password}'")
    conn.commit()
    
    client.update_item(password_id, {"password": new_password})
    print("Пароль успешно ротирован и обновлён в Пассворке")

Шифрование и модель Zero Knowledge

Пассворк реализует схему шифрования, соответствующую принципу Zero Knowledge: сервер никогда не видит секреты в открытом виде. Существует два уровня защиты:

1. Серверное шифрование — всё содержимое баз данных шифруется на сервере и защищено даже от администраторов.
2. Клиентское шифрование (client-side encryption, CSE) — можно включить для критичных данных: секреты шифруются на стороне клиента библиотеке клиента, на сервер отправляется только шифротекст. При включённом CSE пользователь вводит мастер-пароль, из него генерируется мастер-ключ, которым расшифровываются ключи сейфов и отдельных записей; благодаря этому даже компрометация сервера не раскрывает содержимое сейфов.

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

Авторизация и токены

API использует пару токенов — accessToken и refreshToken. Access-токен действует ограниченное время, refresh-токен позволяет получить новый access-токен без повторной аутентификации — Python-коннектор делает это автоматически.

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

• Создавать отдельных пользователей для интеграций API и выдавать им только необходимые права (минимальные привилегии)
• Назначать сервисным учёткам роль с доступом только к нужным сейфам и папкам
• Регулярно ротировать токены и ограничивать срок их действия
• Хранить токены в переменных окружения или секрет-хранилищах
• Использовать HTTPS для всех запросов

Бизнес-кейсы

Итоги

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

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

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

Читайте также

Персональные данные 2025: новые правила для бизнеса

Новые правила 152-ФЗ и изменения 2025. Как бизнесу защитить персональные данные, избежать штрафов и соблюдать требования Роскомнадзора.

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

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

Содержание * Что такое типы сейфов? * Как это работает? * Базовые типы сейфов * Преимущества типов сейфов * Управление типами сейфов * Миграция с предыдущих версий * Почему это важно Типы сейфов В Пассворк 7.1 управление доступом стало гибче благодаря системе типов сейфов. Типы сейфов решают главную проблему администраторов — как контролировать доступ к данным и

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

Почему бизнес выбирает расширенную версию Пассворка

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

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

Типы сейфов

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

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

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

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

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

Как это работает?

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

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

Базовые типы сейфов

В Пассворке есть два базовых типа сейфов: пользовательские сейфы и корпоративные сейфы — их нельзя удалить или переименовать:

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

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

Преимущества типов сейфов

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

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

Сейфы всех типов поддерживают многоуровневую структуру на основе папок — администраторы могут выстраивать иерархию с вложенными элементами

Управление типами сейфов

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

Создание типа сейфов

Для работы с типами вы можете использовать базовые типы или создать свой собственный. Чтобы создать собственный тип сейфа, нажмите Создать тип сейфов.

Во всплывающем окне создания типа доступны следующие пункты:

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

Редактирование типа сейфов

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

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

Удаление типа сейфа

Чтобы удалить тип сейфа, отметьте один или несколько типов во вкладке Типы сейфов и нажмите Удалить в выпадающем меню в верхней части списка.

Аудит и смена типа сейфа

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

Сейфы можно отфильтровать по типу или показать только те, к которым у вас есть доступ.

Настройки

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

Миграция с предыдущих версий

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

При обновлении с Пассворк 6 до версии 7 система автоматически конвертирует имеющиеся сейфы:

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

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

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

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

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

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

• Можно ли изменить тип существующего сейфа? Да, тип существующего сейфа можно изменить, но только при наличии прав администратора в нужном сейфе. При изменении типа в сейф автоматически добавятся корпоративные администраторы нового типа, применятся новые правила доступа и создадутся запросы на подключение пользователей.
• Почему я не могу удалить некоторых администраторов из сейфа? Если вы не можете удалить администраторов из сейфа, значит они являются корпоративными администраторами. Корпоративные администраторы могут быть удалены только при изменении соответствующей настройки типа сейфа (требуются права администратора системы).

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

Запрет приватных сейфов

Задача: запретить сотрудникам создание приватных сейфов.
Решение: в настройках сейфов откройте тип «Пользовательские сейфы». В разделе «Кто может создавать сейфы» удалите всех пользователей или оставьте только тех, кому нужно сохранить это право.

Корпоративные сейфы с обязательными администраторами

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

Создание приватных сейфов без права добавления пользователей

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

Делегирование обязанностей

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

Ограниченное управление сейфами

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

Почему это важно

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

Читайте также

Почему бизнес выбирает расширенную версию Пассворка

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

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

Как защитить данные с помощью менеджера паролей

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

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

Преимущества и недостатки Single Sign-On

Содержание * Вступление * Что такое единый вход * Как работает SSO * Термины и определения * Почему это важно * Преимущества внедрения единого входа * Недостатки единого входа * Разница между менеджером паролей и SSO * Почему SSO и менеджер паролей должны работать вместе * Сравнение подходов к управлению доступом * Заключение Вступление Как часто ваши сотрудники забывают пароли от

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