Управление пользователями и правами в Linux: полный гайд для администратора офисного сервера

Привет! Я, Семёнов Евгений Сергеевич, директор ITFresh. За плечами — больше пятнадцати лет работы с Linux-серверами. И каких только не было! От крошечных виртуальных машин на одном ядре до настоящих монстров: многопроцессорных Dell Xeon Platinum 8280, которые крутятся в дата-центре МТС с 40G Mellanox. И вот что я понял за эти годы: большинство серьёзных проблем с безопасностью возникают не из-за хитрых хакерских атак. Нет, всё куда проще! Чаще всего это банальные ошибки в управлении учётными записями. Этот гайд — моя личная квинтэссенция многолетней практики. Никакой воды, только суть. Обещаю!

База: файлы /etc/passwd, /etc/shadow, /etc/group

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

• /etc/passwd — имя, UID, GID, GECOS, домашняя директория и оболочка. Читается всеми.
• /etc/shadow — хеши паролей, даты смены. Только root.
• /etc/group — список групп и их членов.
• /etc/gshadow — пароли групп (редко используется).

Вот как выглядит каждая строка в /etc/passwd:

ivanov:x:1001:1001:Ivan Ivanov,IT-отдел,+74951234567:/home/ivanov:/bin/bash

UID ниже 1000 всегда отданы системным учётным записям. А где же обычные пользователи? Они стартуют с 1000 (так в Debian/Ubuntu) или 1001 (если вы работаете с RHEL).

Создание и удаление пользователей

Вот базовый набор команд, без которого мы и дня не проводим в своей практике:

# Создать пользователя с домашним каталогом и bash
useradd -m -s /bin/bash -c "Ivan Ivanov, Sales" ivanov
passwd ivanov

# То же самое на Debian через adduser
adduser ivanov

# Добавить в дополнительные группы
usermod -aG sudo,docker,sales ivanov

# Сменить оболочку
chsh -s /bin/zsh ivanov

# Заблокировать учётку (но не удалять)
usermod -L ivanov
# Или через passwd
passwd -l ivanov

# Разблокировать
usermod -U ivanov

# Удалить пользователя вместе с домашним каталогом
userdel -r ivanov

Я всегда использую флаг -aG при добавлении в группы — без -a команда заменит все вторичные группы, и пользователь потеряет доступ к критичным ресурсам. Классическая ошибка начинающих админов.

Группы и их роль в политике доступа

Группы — наш незаменимый помощник. Это основной инструмент, чтобы чётко разделить права доступа к файлам, да и ко многим службам. Забудьте навсегда про то, чтобы давать права каждому пользователю по отдельности! Гораздо, гораздо проще создавать группы. Объединяйте людей по отделам, по проектам — как угодно, лишь бы это было логично и удобно.

Запомните ключевое отличие: у каждого пользователя — только одна первичная группа. Но вторичных групп может быть сколько душе угодно! Все новые файлы, которые он создаст, автоматически наследуют права именно первичной группы.

Права на файлы: chmod, chown, umask

POSIX-модель доступа к файлам? Да это же элементарно! Она работает с тремя категориями — user, group, other — и тремя битами: read, write, execute. Мы задаём эти комбинации двумя способами: либо восьмеричным числом, либо используя символический синтаксис.

# Дать владельцу полный доступ, группе — чтение и исполнение, остальным — ничего
chmod 750 /var/www/intranet

# Изменить владельца и группу рекурсивно
chown -R www-data:www-data /var/www/intranet

# Установить setgid на каталоге — все новые файлы наследуют группу
chmod g+s /srv/share/sales

# Sticky bit — удалять файлы в каталоге может только владелец
chmod +t /tmp

# Маска по умолчанию для новых файлов (022 = 644, 077 = 600)
echo "umask 077" >> /etc/profile

Помните: для каталогов бит execute значит «можно войти в каталог и прочитать список файлов». Без него даже владелец не сможет сделать cd.

POSIX ACL: когда стандартных прав не хватает

Классические права? Они работают отлично, но только для связки «владелец/группа/остальные». А что, если надо дать доступ к конкретному файлу какому-то одному пользователю? При этом вы не хотите трогать ни владельца, ни группу! В такой ситуации выручают списки контроля доступа — или, как мы их зовём, ACL.

# Проверить, смонтирована ли ФС с поддержкой ACL
mount | grep acl
# В /etc/fstab добавить опцию acl, если её нет

# Дать пользователю petrov права rwx на каталог
setfacl -m u:petrov:rwx /srv/share/finance

# Посмотреть ACL
getfacl /srv/share/finance

# Сделать ACL наследуемыми для новых файлов внутри
setfacl -d -m u:petrov:rwx /srv/share/finance

# Удалить ACL-запись
setfacl -x u:petrov /srv/share/finance

На нашей практике ACL просто незаменимы. Возьмём, к примеру, общие папки бухгалтерии: главбух получает полный доступ, его помощники могут только читать, а внешний аудитор на время проверки спокойно получает временный rwx, даже не входя в основную группу. Очень удобно!

sudo: привилегированный доступ без root-пароля

Раздавать пароль root? Нет, это просто ужасная практика! Я всегда, слышите, всегда настаиваю на sudo. Почему? Всё просто: каждая команда логируется, а права можно ограничить до конкретной утилиты. Если что-то пойдёт не так, вы точно будете знать, кто и что сделал. Это же бесценно при расследовании инцидентов!

# Редактирование только через visudo — иначе рискуете сломать синтаксис
visudo

# Примеры правил
# Полный sudo для группы wheel/sudo без пароля
%sudo   ALL=(ALL:ALL) NOPASSWD: ALL

# Только перезапуск nginx пользователю devops
devops  ALL=(root) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl reload nginx

# Запрет опасных команд
Cmnd_Alias DANGEROUS = /usr/bin/rm -rf /*, /usr/sbin/shutdown, /sbin/reboot
admins  ALL=(ALL) ALL, !DANGEROUS

Правила лучше класть в отдельные файлы в /etc/sudoers.d/ — так проще управлять через Ansible и откатывать изменения.

Кейс: наведение порядка на файловом сервере юридической фирмы

Помню, был март 2026 года. К нам обратилась одна московская юркомпания. У них стоял Ubuntu Server 22.04 на Dell PowerEdge, с рейдом на 8 ТБ, и на нём работали 42 сотрудника из четырёх разных отделов. Главная боль? Сервер жил своей жизнью почти полтора года (целых 14 месяцев!), разрастаясь совершенно хаотично. Представляете: у пятерых учётных записей каким-то чудом оказался UID 0, в группу sudo входило аж 28 человек, а общие папки... да они вообще были с правами 777! Ну и что в итоге? Всего за один день аудита мы нашли конфиденциальные договоры, лежащие прямо в общедоступной шаре. Неудивительно, правда?

За 2 дня мы провели санацию:

• Выделили группы lawyers, paralegals, accounting, management с внятными GID от 2000.
• Перестроили дерево /srv/share/ с setgid и ACL по отделам.
• Когда речь заходит о правах sudo, здесь компромиссы неуместны, верно? Мы кардинально сократили количество администраторов: теперь доступ остался всего у трёх человек. И сами правила? Мы сузили их до максимально конкретных команд. Ничего лишнего, только строго по делу – для вашей же безопасности.
• Хотите досконально знать, кто и когда обращался к самым важным файлам системы? Мы активировали auditd. Настроили его с чёткими правилами, чтобы он внимательно следил за любыми изменениями в /etc/passwd и /etc/shadow. Эти файлы – сердце пользовательских данных и паролей, так что каждое движение здесь под нашим полным контролем.
• Кто-то пытается подобрать пароль к учётной записи? С нами это просто не пройдёт! Мы внедрили и настроили pam_tally2. Теперь после всего лишь пяти неудачных попыток система автоматически блокирует эту учётную запись. Злоумышленник просто не сможет продолжить свой подбор. Это простой, но очень эффективный барьер для вашей защиты.

Каков результат? В следующие полгода, после того как мы навели порядок, число инцидентов информационной безопасности упало до нуля. Все работы обошлись в 78 000 рублей. Кстати, в эту сумму уже был включён полный бэкап системы. Мало ли что!

SELinux и AppArmor — мандатный контроль доступа

POSIX-права решают базовую задачу: может ли пользователь вообще открыть этот файл? А вот MAC, Mandatory Access Control, копает куда глубже. Он спрашивает: «А имеет ли право процесс, который запустил этот пользователь, открыть файл именно в этом контексте?» На CentOS/RHEL, вы знаете, это SELinux. А на Ubuntu/Debian — наш добрый друг AppArmor.

# Состояние SELinux
getenforce
sestatus

# Переключить в permissive (только логирование) на время отладки
setenforce 0

# Посмотреть контекст файла
ls -Z /var/www/html/index.html

# Восстановить стандартные контексты
restorecon -Rv /var/www/html

# Открыть нестандартный порт для httpd
semanage port -a -t http_port_t -p tcp 8081

# На AppArmor — посмотреть и отключить профиль
aa-status
aa-disable /usr/sbin/nginx

Аудит и мониторинг учётных записей

Какой смысл настраивать права, если вы в принципе не понимаете, что творится на сервере? Вот минимальный набор, без которого о мониторинге можно забыть:

• last, lastb, lastlog — история входов.
• who, w — кто в системе прямо сейчас.
• journalctl _COMM=sudo — все sudo-команды.
• aureport -au — отчёт auditd по аутентификации.
• pwck и grpck — проверка целостности файлов учёток.

# Найти пользователей с UID=0 кроме root
awk -F: '$3==0 {print $1}' /etc/passwd

# Учётки без пароля
awk -F: '$2=="" {print $1}' /etc/shadow

# Пользователи с shell, но никогда не входившие
lastlog -b 90 | grep "Never"

FAQ — частые вопросы по правам в Linux

Чем отличается useradd от adduser?

useradd — низкоуровневая утилита, доступная во всех дистрибутивах. adduser — интерактивная обёртка, которая есть только в Debian/Ubuntu и автоматически создаёт домашний каталог, копирует скелет и запрашивает пароль. На RHEL/CentOS используйте useradd с ключом -m.

Какая разница между chmod 755 и chmod 775?

755 — владельцу полный доступ, группе и остальным только чтение и исполнение. 775 — владельцу и группе полный доступ, остальным чтение и исполнение. 775 используется для общих каталогов, где члены группы должны иметь возможность создавать файлы.

Зачем нужен setgid на каталоге?

Флаг setgid на каталоге заставляет все новые файлы внутри наследовать группу-владельца каталога. Это стандартное решение для общих папок отдела.

Как посмотреть последние входы пользователей?

Команда last показывает успешные входы, lastb — неудачные попытки, lastlog — последний вход каждого пользователя. Для аудита sudo — journalctl или /var/log/auth.log.

Стоит ли отключать SELinux?

Нет. Используйте режим permissive на этапе отладки, чтобы увидеть нарушения в audit.log, и переводите систему в enforcing после настройки политик через audit2allow.