Подрядчику нужен доступ, иначе он не сможет работать. Компании нужен контроль, иначе она не понимает, кто менял системы и как продолжить работу при смене исполнителя. Это не противоречие: доступ можно организовать так, чтобы он был достаточным для задачи, ограниченным по границе и восстанавливаемым после завершения.
Начните не с пароля, а с границы работы
До выдачи доступа запишите:
- какую систему или площадку затрагивает работа;
- что подрядчик должен сделать;
- что не входит в задачу;
- кто со стороны компании согласует изменения;
- какие другие поставщики участвуют;
- как будет проверяться завершение;
- какие данные и документы останутся у компании.
Чем точнее граница, тем проще определить необходимые права. Формулировка «дать администраторский доступ ко всему» обычно означает, что задача ещё не разложена.
Персональные учётные записи вместо общих
У каждого внешнего специалиста должна быть отдельная учётная запись либо другой способ однозначно связать действия с исполнителем. Общий пароль:
- мешает понять, кто выполнил изменение;
- усложняет отзыв доступа одного человека;
- повышает риск передачи полномочий дальше;
- делает журнал действий менее полезным.
Если платформа не поддерживает персональные записи, зафиксируйте компенсирующие меры: ограниченное окно доступа, согласованный сеанс, запись действий или выдачу временного секрета через контролируемый канал.
Минимально необходимые права
Доступ выдаётся к конкретной системе и на срок, необходимый для работы. Это не означает, что специалисту никогда не понадобится расширение прав. Означает лишь, что расширение должно быть отдельным решением с понятной причиной.
Проверьте:
- к каким объектам есть доступ;
- можно ли изменять настройки или только просматривать;
- разрешена ли выгрузка данных;
- нужен ли постоянный или разовый удалённый доступ;
- включена ли многофакторная аутентификация;
- кто может согласовать повышение привилегий;
- когда учётная запись будет отключена.
Для производственных и складских систем отдельно учитывайте влияние на технологический процесс и требования поставщика оборудования. Стандартный офисный подход может быть неприменим.
Канал удалённого доступа
Удалённый доступ — отдельная часть инфраструктуры, которую нужно учитывать и наблюдать. CISA рекомендует защищать программное обеспечение удалённого доступа и проверять сторонние учётные записи, включая доступы MSP.
Практические вопросы:
- Через какой шлюз или сервис происходит подключение?
- Есть ли многофакторная аутентификация?
- Ограничены ли доступные системы и сетевые сегменты?
- Видно ли начало и окончание сеанса?
- Можно ли быстро отключить доступ без остановки других работ?
- Кто проверяет необычные или неуспешные попытки входа?
Постоянный агент удалённого управления может быть оправдан для регулярной поддержки, но это должно быть осознанное решение, а не побочный эффект первой аварийной работы.
Изменения и согласование
Даже технически правильное изменение может остановить смежную систему, если не учтены зависимости. Для значимых изменений полезна короткая карточка:
- Что меняем и зачем.
- Какие системы и пользователи могут быть затронуты.
- Какое окно выбрано.
- Кто согласовал.
- Как проверить результат.
- Как вернуться к исходному состоянию, если проверка не пройдена.
- Какие записи и схемы нужно обновить.
Это не обязательно тяжёлый процесс. Для типовых безопасных действий можно заранее согласовать класс изменений. Исключения и новые риски требуют отдельного решения.
Документация должна возвращаться компании
Минимальный набор после работы:
- что фактически изменено;
- текущая схема или конфигурация в согласованном объёме;
- новые зависимости;
- где находятся лицензии и договоры;
- какие учётные записи созданы или изменены;
- что проверено;
- какие ограничения и незавершённые вопросы остались;
- кому и когда переданы материалы.
Передача документа не доказывает, что система достигла желаемого результата. Но без неё следующая поддержка будет начинать с повторного исследования.
Завершение и смена подрядчика
Порядок завершения стоит определить до начала работ:
- срок уведомления;
- список данных и конфигураций к передаче;
- формат экспорта заявок и документации;
- отзыв персональных и технических доступов;
- смена общих секретов, если они использовались;
- передача открытых инцидентов и запланированных изменений;
- период совместной передачи знаний;
- ответственный, который подтверждает завершение.
Возможность сменить формат без потери основных сведений — признак контроля, а не недоверия к текущему подрядчику.
Контрольный список перед первым доступом
- [ ] Система, задача и граница работ названы.
- [ ] Есть владелец решения со стороны компании.
- [ ] Назван специалист или команда подрядчика.
- [ ] Выдана персональная или контролируемая временная учётная запись.
- [ ] Права ограничены нужными объектами.
- [ ] Согласован канал и срок удалённого доступа.
- [ ] Определено, какие действия требуют отдельного согласования.
- [ ] Понятно, где сохраняются журналы и результаты работы.
- [ ] Определён состав передаваемой документации.
- [ ] Известен порядок отключения доступа и завершения работ.
Короткий вывод
Контроль сохраняется не потому, что компания делает всё сама. Он сохраняется, когда полномочия выдаются осознанно, действия можно восстановить, изменения согласуются, а знания и доступы возвращаются в управляемое состояние.
Источники и границы материала
- NIST SP 800-161 Rev. 1 — управление рисками поставщиков и услуг на протяжении жизненного цикла.
- NIST SP 1305 — роли, требования и коммуникация с поставщиками.
- CISA Guide to Securing Remote Access Software — риски и защитные меры для удалённого доступа.
- CISA #StopRansomware Guide — проверка стороннего доступа и учётных записей MSP.
Источники проверены 30 августа 2026 года. Конкретные права, журналы и порядок согласования определяются архитектурой, договором и требованиями безопасности компании.