Как организовать доступы подрядчиков и вовремя их отзывать

Редакция Romanov Lab · Опубликовано 13 октября 2026

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

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

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

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

Опишите полномочия через рабочую задачу

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

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

• Редактор получает права на согласованные материалы и нужные действия с ними.
• Разработчик работает с репозиторием и тестовой площадкой; доступ к рабочему выпуску определяется отдельно.
• Администратор получает права на конкретные инфраструктурные задачи с понятным порядком изменений.
• Аналитик видит нужный набор отчётов без автоматического доступа к управлению пользователями.

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

Отделите человека от технической интеграции

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

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

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

Выдавайте временное расширение отдельно

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

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

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

Учебный разбор: подрядчик завершает сопровождение

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

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

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

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

1. Сверьте список выданных доступов с текущими пользователями и приглашениями каждого сервиса.
2. Закройте персональные роли, SSH-ключи, VPN-доступ и другие разрешённые ранее способы подключения в пределах согласованной процедуры.
3. Проверьте токены, приложения, ключи выкладки и интеграции, связанные с подрядчиком; передайте нужные зависимости и отзовите лишнее.
4. Завершите активные сессии предусмотренным механизмом сервиса.
5. Если исполнитель знал общий секрет, организуйте его замену с обновлением законных зависимостей.
6. Уберите ненужный доступ к документам, журналам, архивам и уведомлениям.

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

Проверьте результат без использования чужих секретов

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

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

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