Как раздать доступ команде без выдачи root

MAATRIX

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

Почему root на всех — плохая идея

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

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

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

Создаём персональные аккаунты

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

adduser ivan
mkdir -p /home/ivan/.ssh
echo "ssh-ed25519 AAAA... ivan@laptop" > /home/ivan/.ssh/authorized_keys
chown -R ivan:ivan /home/ivan/.ssh
chmod 700 /home/ivan/.ssh && chmod 600 /home/ivan/.ssh/authorized_keys

Каждый член команды даёт вам свой публичный ключ, вы добавляете его в authorized_keys соответствующего аккаунта. Теперь человек заходит под своим именем по своему ключу — в логах видно, кто именно подключился, а отозвать доступ можно, просто удалив аккаунт или ключ, не трогая остальных. Обязательно отключите на сервере вход по паролю и вход под root по SSH — это закрывает главный вектор атак.

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

Выдаём sudo с ограничениями

Иногда человеку нужно выполнять действия с повышенными правами — перезапустить сервис, посмотреть системный лог. Давать ради этого полный sudo не нужно: sudo умеет ограничивать, какие именно команды разрешены пользователю. Отредактируйте правила через visudo и разрешите конкретному пользователю только нужные команды:

ivan ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, /bin/systemctl status myapp

Такое правило позволяет Ивану перезапускать и смотреть статус только своего сервиса, но не даёт ему полного root. Он не сможет менять системные настройки, читать чужие данные или удалять то, что ему не положено. Для группы разработчиков одного проекта удобно завести отдельную группу и выдавать права на уровне группы, а не каждому по отдельности. Гранулярный sudo — мощный инструмент: он даёт людям ровно то, что нужно для работы, оставляя систему под защитой.

Изолируем проекты по пользователям

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

groupadd projecta
usermod -aG projecta ivan
chown -R root:projecta /var/www/projecta
chmod -R 2750 /var/www/projecta

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

Аудит и отзыв доступа

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

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

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