Какие пользователи должны иметь sudo

Что проверяют

Понимаете ли вы, что sudo это инструмент ограничения прав, а не способ «дать всем root, но с паролем». Следом обычно спрашивают, как вы раздаёте доступ на сотне серверов и как потом узнать, кто и что запускал.

Как отвечать

Короткий ответ: как можно меньше людей и только на те команды, которые им действительно нужны. Дальше разложите по ролям:

• администраторы и дежурные инженеры: полный sudo, но через именную учётку и группу (sudo в Debian/Ubuntu, wheel в RHEL), а не через общий пароль root;
• сервисные учётки автоматизации (Ansible, раннеры CI): отдельный пользователь, иногда с NOPASSWD, но только на конкретные команды, а лучше вообще без sudo, если хватает прав на нужный каталог;
• разработчики: на проде обычно без sudo, точечно разрешают systemctl restart myapp, а журналы читают через группу systemd-journal или adm;
• сервисы приложений (www-data, postgres): sudo им не нужен никогда.

Технические детали, которые стоит назвать: правила кладутся в /etc/sudoers.d/ и правятся через visudo, который проверяет синтаксис до сохранения; команды в правиле пишутся полным путём, например deploy ALL=(root) /usr/bin/systemctl restart myapp; каждый вызов попадает в журнал (/var/log/auth.log или journalctl), а запись целых сессий дают log_output и sudoreplay. В большой инфраструктуре права руками не раздают: их держат в FreeIPA или LDAP либо раскатывают Ansible-ролью, а доступ к серверам всё чаще выдают временно, через bastion или SSH-сертификаты.

Где спотыкаются

Разрешают «безопасную» команду, из которой можно выйти в шелл: vim, less, find, tar, python. Через :!sh в vim человек получает полноценный root.

Дают NOPASSWD: ALL сервисной учётке CI. Утечка токена раннера сразу превращается в root на всех серверах, куда он ходит.

Правят /etc/sudoers обычным редактором. Одна синтаксическая ошибка ломает sudo целиком, и вернуть доступ можно только через консоль или загрузку в однопользовательском режиме.