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

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

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

1. Сначала определите границы проекта

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

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

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

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

2. Разделите обязательные требования и пожелания

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

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

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

3. Пишите «сценарий — результат — доказательство»

Слабая формулировка: «Система поддерживает разграничение доступа». Сильнее: «Сотрудник филиала А не может открыть, обнаружить через поиск или экспортировать записи филиала Б; проверка проводится под тестовым пользователем с заведомо ограниченными правами». Это уже можно испытать.

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

Требование	Как подтвердить
Разделение подразделений	Войти под двумя тестовыми ролями и провести положительные и отрицательные проверки
Отзыв прав	Исключить пользователя из группы, проверить новый вход, активную сессию и доступ к записи
Интеграция каталога	Создать, перевести и заблокировать тестового сотрудника
Восстановление	Развернуть копию в изолированном контуре и проверить записи, права и вложения
Журналирование	Найти согласованные события по тестовой операции
Пользовательская работа	Выполнить типовые операции без подсказки администратора

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

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

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

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

4. Опишите безопасность через реальные операции

Раздел по безопасности часто превращается в каталог терминов: шифрование, MFA, RBAC, Zero-Knowledge, TLS. Но сами слова не отвечают на вопрос, где проходит граница доверия и кто способен получить содержимое корпоративной записи.

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

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

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

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

Подробнее: Архитектура надёжного менеджера паролей.

5. Заранее согласуйте интеграции и размещение

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

Не смешивайте LDAP и SSO в одно требование. Первый может отвечать за получение пользователей и групп; второй — за аутентификацию через провайдера. В некоторых проектах их используют вместе, в других — по отдельности. У BearPass подключение LDAP/Active Directory и SAML SSO описано в документации как возможность платных тарифов. Для пилота согласуйте редакцию с этими интеграциями и проверяйте каждую по отдельному сценарию.

Для on-premise задайте схему сервера приложения, БД, файлового хранилища, сетевых соединений, резервирования, мониторинга и обновлений. Здесь пригодится не абстрактное требование «высокая доступность», а допустимое время простоя, перечень зависимостей и испытание отказа одного из компонентов. Если компания предпочитает облачный формат, столь же чётко разграничьте эксплуатационную ответственность сторон.

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

6. Не забудьте миграцию, эксплуатацию и поддержку

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

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

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

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

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

7. Приёмка должна начинаться ещё при написании ТЗ

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

Используйте четыре статуса: «пройдено», «не пройдено», «пройдено с ограничением» и «не проверено». Для ограничения обязательно опишите риск и принимающего его владельца; для непроведённого теста — причину, ответственного и срок. Отсутствие испытания не означает успешную приёмку. Условия приёмки обычно согласуют ИТ, ИБ и владелец соответствующего процесса. Закупки фиксируют последствия для договора, но не должны самостоятельно решать, допустим ли риск доступа к чужим секретам.

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

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

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

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

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

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

По состоянию на 29 октября 2026 года на странице BearPass о сертификации указано, что процедура ФСТЭК продолжается; ожидаемый срок выдачи — I квартал 2027 года. Это плановый срок, а не выданный сертификат. Если он нужен проекту, выделите получение и проверку документа в отдельное условие решения. Укажите требуемую версию, область применения и этап, к которому документ должен быть представлен; актуальный статус проверьте повторно перед закупкой.

Рекомендуем к прочтению

• IAM, PAM и менеджер паролей
• Облако или on-premise: что выбрать

Частые вопросы