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

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

Условный пример: подрядчик исправил сайт вечером в пятницу, но общий административный пароль остался ему известен после завершения работ. Срок проекта сам по себе не прекратил доступ. Ниже — шаблон из девяти полей и порядок согласования, выдачи, продления и закрытия, который можно перенести в Service Desk, задачник или корпоративный портал.

Кто вправе согласовать чужой доступ

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

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

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

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

Шаблон заявки: девять обязательных полей

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

Поле заявки	Что записать
Инициатор	Сотрудник и подразделение, запросившие работу
Исполнитель	Конкретный представитель подрядчика
Ресурс	Система, проект, папка или группа записей
Основание	Задача, договор или заявка на изменение
Полномочия	Какие действия разрешены и запрещены
Срок	Начало и точное окончание доступа
Согласование	Кто утвердил и когда
Выдача	Какой администратор предоставил доступ
Закрытие	Кто, когда и как проверил прекращение прав

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

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

Согласование по критичности ресурса

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

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

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

Как выдавать секрет без пересылки в чат

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

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

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

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

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

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

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

Срок закончился. А права?

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

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

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

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

Когда нужно менять уже раскрытый пароль

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

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

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

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

Экстренная заявка: ускорить, а не отменить контроль

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

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

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

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

Как проверить, работает ли регламент

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

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

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

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

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

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

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

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

• Как защитить аккаунты при увольнении
• Что такое RBAC и зачем он нужен

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