Проблема
Ежедневная работа системного администратора полна рутинных операций, которые не требуют полного доступа к root: перезапуск веб-сервера, просмотр журналов, создание резервных копий. Однако начинающие администраторы и операторы часто получают команду sudo -i или sudo su, что фактически даёт им неограниченные привилегии. Случайное удаление системных файлов, изменение прав доступа или остановка критического сервиса могут парализовать инфраструктуру. В то же время излишнее ограничение может блокировать работу сотрудников, вынуждая их искать обходные пути (например, хранить пароль root на стикере). Настройка sudo на уровне детализированных политик позволяет выдавать ровно те права, которые нужны для выполнения задач, и ни битом больше, сохраняя аудит всех действий.
Решение
Вместо того чтобы добавлять пользователей в группу sudo с полными привилегиями, мы будем использовать централизованный файл /etc/sudoers и дополнительные файлы в /etc/sudoers.d/. Создадим алиасы команд, ограничим параметры, запретим опасные операции (такие как запуск оболочки root) и включим логирование каждого выполненного действия. Все изменения будут вноситься исключительно через visudo, что гарантирует проверку синтаксиса и предотвращает блокировку доступа. Официальные руководства по синтаксису и директивам доступны в man sudoers и на Sudo Manual. Рекомендации по безопасности описаны в Sudoers Best Practices. Применяемый подход соответствует требованиям многих стандартов, включая PCI DSS и CIS Benchmarks.
Пошаговая инструкция
Шаг 1. Структура файлов sudoers и синтаксис
Основной файл дежит тут: /etc/sudoers. Однако для модульности рекомендуется создавать отдельные файлы в директории /etc/sudoers.d/, которые подключаются директивой #includedir /etc/sudoers.d (или @includedir в современных версиях). Файлы в этой директории читаются в алфавитном порядке. Создадим файл /etc/sudoers.d/operators:
bash
sudo visudo -f /etc/sudoers.d/operatorsВсе изменения выполняются через visudo, который блокирует файл и проверяет синтаксис перед сохранением.
Шаг 2. Создание алиасов команд и пользователей
Для удобства определяем алиасы в начале файла. Алиасы позволяют переиспользовать списки команд и уменьшают количество ошибок.
Пользовательские алиасы:
User_Alias WEBTEAM = %webadmins, ivanov, petrov
User_Alias DBTEAM = %db_admins, sidorovЗдесь %webadmins это группа UNIX, а ivanov это конкретный пользователь.
Командные алиасы:
Cmnd_Alias WEB_SERVICES = /usr/bin/systemctl start nginx, /usr/bin/systemctl stop nginx, /usr/bin/systemctl reload nginx, /usr/bin/systemctl status nginx
Cmnd_Alias WEB_LOGS = /bin/cat /var/log/nginx/*, /usr/bin/tail /var/log/nginx/*
Cmnd_Alias DB_BACKUP = /usr/bin/pg_dump *Звёздочка (*) означает любое значение после команды. Это важно ограничивать, чтобы пользователь не передал нежелательный параметр. Например, DB_BACKUP разрешает pg_dump с любыми опциями, но если нужно ограничить конкретную базу, можно указать /usr/bin/pg_dump mydb.
Шаг 3. Назначение прав без пароля (NOPASSWD) или с паролем
Пользователи группы webadmins могут перезапускать nginx без ввода пароля, а для просмотра логов пароль потребуется:
User_Alias WEBTEAM = %webadmins
WEBTEAM ALL = (root) NOPASSWD: WEB_SERVICES, PASSWD: WEB_LOGSПараметр (root) означает, что команды выполняются от имени пользователя root. NOPASSWD убирает запрос пароля для указанной группы команд. Если нужно, чтобы команды выполнялись от имени другого пользователя (например, www-data), укажите (www-data).
Шаг 4. Запрет опасных команд и получения root-оболочки
Даже разрешив операторам конкретные команды, вы должны явно запретить им запуск оболочки root или изменение своего уровня привилегий. Добавьте в файл /etc/sudoers.d/restrictions:
# Запрет всех команд, кроме явно разрешённых (необязательно, если политика строится по принципу "только разрешённое")
Cmnd_Alias DANGEROUS = /bin/su, /usr/bin/su, /bin/bash, /usr/bin/sudo, /usr/bin/passwd root
%webadmins ALL = (ALL) !DANGEROUSСимвол ! перед алиасом означает запрет. Важно, чтобы порядок правил соблюдался: последнее совпадающее правило имеет приоритет. Обычно сначала идут разрешающие правила, затем запрещающие.
Шаг 5. Ограничение аргументов команд
Для systemctl можно ограничить доступные подкоманды, но также важно не дать оператору возможность выполнить systemctl set-property, что изменило бы поведение службы. Используйте шаблоны:
Cmnd_Alias SAFE_SYSTEMCTL = /usr/bin/systemctl start *, /usr/bin/systemctl stop *, /usr/bin/systemctl status *Если нужен перезапуск только определённой службы, укажите точный путь:
WEBTEAM ALL = (root) /usr/bin/systemctl restart nginxЭто безопаснее, чем systemctl restart *, так как оператор не сможет перезапустить критичные сервисы (например, sshd).
Шаг 6. Включение детального логирования
По умолчанию sudo логирует в /var/log/auth.log (через syslog). Для аудита действий операторов рекомендуется вести отдельный журнал. В том же файле /etc/sudoers или в отдельном файле /etc/sudoers.d/logging добавьте:
Defaults syslog=local2
Defaults logfile=/var/log/sudo.log
Defaults log_year
Defaults log_hostТеперь каждое выполнение sudo, включая неудачные попытки, будет записано в /var/log/sudo.log с указанием пользователя, команды и времени. Настройте ротацию логов в /etc/logrotate.d/sudo, чтобы файл не заполнил диск.
Шаг 7. Использование sudoedit для безопасного редактирования файлов
Редактирование файлов от root через sudo vim или sudo nano позволяет пользователю запустить оболочку из редактора (:shell в vim). Безопасная альтернатива sudoedit:
WEBTEAM ALL = (root) sudoedit /etc/nginx/sites-available/*sudoedit копирует файл во временную область, запускает редактор от имени пользователя и после сохранения копирует обратно с сохранением прав и владельца. Это исключает возможность побега из редактора.
Шаг 8. Настройка таймаута аутентификации
После ввода пароля sudo кеширует его на некоторое время (по умолчанию 15 минут). Для операторов, выполняющих короткие задачи, это неудобно. Можно изменить таймаут или вовсе отключить кеширование:
Defaults timestamp_timeout=1Значение 0 потребует пароль каждый раз, -1 никогда не кешировать (не рекомендуется). Для групп, использующих NOPASSWD, таймаут не применяется.
Шаг 9. Проверка конфигурации и предоставленных прав
Перед передачей пользователям проверьте, какие права фактически получит пользователь:
bash
sudo -U ivanov -lВывод покажет список разрешённых команд. Пользователь сам может выполнить sudo -l для самопроверки. Убедитесь, что никаких нежелательных привилегий не появилось.
Устранение распространённых проблем
| Симптом | Вероятная причина | Решение |
|---|---|---|
| После изменения sudoers пользователь не может применить sudo | Синтаксическая ошибка в файле, visudo не использовался | Загрузитесь в recovery mode или используйте pkexec visudo для исправления. Всегда применяйте visudo при редактировании. |
| Разрешённая команда не выполняется, «user is not in the sudoers file» | Пользователь не включён в группу или группа неверно указана | Проверьте членство: groups username. В sudoers используйте %groupname. |
Не работает systemctl restart nginx даже при разрешении | В команде используется относительный путь, а в sudoers указан абсолютный | Указывайте полный путь: /usr/bin/systemctl. Узнайте командой which systemctl. |
| Лог-файл sudo пуст | syslog не настроен на приём сообщений от local2 | Добавьте в /etc/rsyslog.conf или /etc/rsyslog.d/50-default.conf: local2.* /var/log/sudo.log и перезапустите rsyslog. |
Оператор в vim получает оболочку root (:shell) | Используется sudo vim вместо sudoedit | Замените на sudoedit или ограничьте редактор через Cmnd_Alias SAFE_EDITOR = /usr/bin/rvim. |
Грамотная настройка sudo превращает этот инструмент из простого способа получения root в мощную систему делегирования прав с полным аудитом. Разделение обязанностей между администраторами, операторами и разработчиками снижает риск человеческой ошибки и повышает безопасность всей инфраструктуры. Используя описанные техники от алиасов и запретов до sudoedit и детального логирования вы строите безопасное окружение, в котором каждый сотрудник выполняет только разрешённые задачи, а администратор всегда знает, кто и зачем применял привилегии.
