Антипаттерн: выдать подрядчику root и забыть

MAATRIX

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

Как это выглядит на практике

Сценарий почти всегда один и тот же. Нужен внешний исполнитель — фрилансер, аутсорс-команда, разовый консультант. Задача горит, разбираться с настройкой отдельного пользователя, sudo и ограничений «нет времени», и проще всего отправить:

Сервер: 203.0.113.40
Логин: root
Пароль: (пароль в открытом виде в чате)

Или ещё удобнее — попросить подрядчика прислать свой публичный ключ и добавить его прямо в /root/.ssh/authorized_keys:

cat contractor_key.pub >> /root/.ssh/authorized_keys

Дальше подрядчик заходит под root, делает то, что нужно, и не только это — потому что ничто его не ограничивает. Он может заодно поставить утилиты, которые ему привычны, поправить конфиг, который его смущает, но напрямую к задаче не относится, оставить тестовый cron-скрипт «на всякий случай». Формально задача выполнена, счёт оплачен, все довольны. А в authorized_keys root остаётся строка, которую никто не планирует убирать — просто потому что убирать её не входит ни в чью зону ответственности. Работа закончилась, а не проект «отозвать доступ».

Почему так делают — и почему это ловушка

Логика, которая приводит к этой практике, вполне рациональна на коротком горизонте. Настройка отдельного пользователя с ограниченными правами через sudo и точечными разрешениями занимает время — нужно понять, какие именно команды нужны подрядчику, прописать это в /etc/sudoers.d/, проверить, что ничего не сломалось. Когда задача на два часа, а не на две недели, это выглядит непропорциональными затратами. Плюс к этому — банальное доверие: подрядчика порекомендовали, с ним уже работали, «он свой человек, зачем ему ограничения».

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

Отдельно стоит разница между разовым фрилансером и постоянной аутсорс-командой. С командой, которая обслуживает сервер годами, соблазн «один раз настроить root и не трогать» ещё сильнее — расширенный доступ выглядит оправданным долгосрочными отношениями. Но чем дольше живёт неограниченный доступ, тем больше людей через него прошло: сотрудники подрядчика меняются, а строка в authorized_keys остаётся привязана к организации, а не к конкретному человеку, который её изначально получил.

Проблема аудита: root не различает важное и неважное

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

Смотрим на это с точки зрения логов. history в bash-сессии подрядчика покажет команды — если он не почистил файл истории и не работал через инструмент, который его не пишет вовсе. Но даже полная история не решает главного: она показывает, что было выполнено, а не зачем. Правка /etc/nginx/sites-available/app.conf — это то, за чем пришёл подрядчик, или побочное действие, которое он сделал по пути, посчитав нужным без согласования? Root это различить не позволяет: любая команда в истории выглядит равноценно любой другой, потому что все они выполнены с одинаковыми максимальными правами.

Сравните это с моделью, где подрядчику выдан ограниченный набор прав через sudoers:

# /etc/sudoers.d/contractor-migration
contractor_ivan ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp, \
  /usr/bin/systemctl status myapp, \
  /bin/cat /var/log/myapp/*.log

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

Доступ, который забывают отозвать

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

На практике доступ подрядчика остаётся живым по нескольким причинам одновременно:

• Нет владельца задачи «закрыть доступ». Кто именно должен вспомнить и удалить ключ через месяц после сдачи проекта — не определено ни в одном регламенте, значит не сделает никто.
• Доступ размазан по системам. SSH-ключ на сервере — это только один из каналов. Токен в CI/CD, доступ к панели хостинга, учётка в мониторинге, VPN-конфиг — каждый требует отдельного отзыва в отдельном интерфейсе, и вспомнить все сразу тяжело даже при желании.
• Страх что-то сломать. Если непонятно, использует ли ещё подрядчик доступ для поддержки в фоне, проще оставить как есть, чем разбираться и рисковать заблокировать что-то нужное.
• Ротация людей на стороне подрядчика. Даже если договор с компанией-подрядчиком закончился, физическое лицо, которое когда-то получило ключ, могло скопировать его до окончания сотрудничества — просто потому что ключ был доступен ему в открытом виде, а не выдан через контролируемый механизм.

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

Не только злой умысел — обычная невнимательность тоже риск

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

Типичные ситуации:

• команда rm -rf выполняется не в той директории, потому что подрядчик перепутал путь на незнакомом ему сервере;
• перезапуск или обновление системного пакета «заодно», который тянет за собой зависимости и ломает несвязанный сервис;
• правка firewall для собственного удобства во время работы (открыть порт для отладки), которую потом забывают закрыть;
• установка инструментов, к которым подрядчик привык, но которые конфликтуют с уже настроенным окружением;
• случайное изменение прав на файлы или каталоги командой вроде chmod -R не в том месте.

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

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

Как правильно: точечный доступ, срок действия, логирование, отзыв

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

1. Точечный доступ под конкретную задачу. Заводится отдельный системный пользователь, а не используется root или общая учётка:

adduser contractor_ivan
usermod -aG sudo contractor_ivan   # если вообще нужен sudo

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

2. Временная учётка с явным сроком действия. Срок задаётся не «на словах», а техническими средствами, которые отработают, даже если про доступ забудут:

useradd -m -e 2026-09-20 contractor_ivan
chage -l contractor_ivan

Флаг -e жёстко ограничивает дату, после которой учётка блокируется автоматически, без ручного вмешательства. Если задача может затянуться, дату продлевают явным действием — chage -E 2026-10-05 contractor_ivan — а не оставляют доступ бессрочным по умолчанию. Это единственный способ, который не полагается на то, что кто-то не забудет.

3. Логирование действий, которое подрядчик не может отключить. Ограниченные права сами по себе снижают риск, но полезно ещё видеть, что именно было сделано. Базовый вариант — включить аудит через auditd:

auditctl -a exit,always -F arch=b64 -S execve -k contractor_actions
ausearch -k contractor_actions

Логи имеет смысл сразу пересылать за пределы сервера (например, через rsyslog на отдельный лог-сервер), чтобы даже теоретический root-доступ не позволял их подчистить задним числом. Для задач с более высокой чувствительностью (доступ к продовым данным, финансовым системам) оправдана запись сессий целиком — через bastion-хост или инструменты вроде Teleport, которые сохраняют не только команды, но и полный терминальный вывод.

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

• дата истечения учётки (chage -E) отрабатывает сама, даже если про задачу все забыли;
• в тикет-системе закрытие проекта блокируется чек-пунктом «доступ отозван», подтверждённым отдельным человеком, а не тем же, кто выдавал;
• через at или systemd-таймер можно заранее запланировать блокировку учётки на конкретный момент: echo "usermod -L contractor_ivan" | at 18:00 2026-09-20;
• если доступов на сервере становится много и вручную их не удержать, имеет смысл описывать список активных пользователей как код (Ansible-плейбук в git) — тогда отсутствие человека в списке само по себе означает отсутствие доступа после следующего прогона.

Что именно проверять при закрытии задачи с подрядчиком — не только SSH-ключ, но и токены CI/CD, доступ к панели хостинга, правила firewall, оставленные «на время» — по шагам разобрано в статье подрядчик закончил работу: как закрыть за ним двери.

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