Пользователи и группы Linux: настройка безопасности и аудит

Настройка пользователей Linux: где ломается разграничение доступа

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

Вторая типовая поломка — права, выданные «на время». Правило в sudo с отключённым запросом пароля остаётся в файле после закрытия задачи, сотрудник забыт в группе с правами на контейнеры, а публичный ключ уволившегося продолжает лежать в authorized_keys сразу на десятках хостов. Отзыв не был частью процесса, поэтому лишние привилегии живут годами и всплывают только при проверке или после сбоя.

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

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

Что даёт порядок в учётных записях и правах доступа

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

Выдача и отзыв прав — одна операция на весь парк

Права раздаются группами, а не руками по серверам — штатный механизм Linux переносится в единую модель доступа. Сотрудник попадает в нужную группу и получает права везде, где она объявлена; увольнение или смена роли — это снятие из группы, и доступ пропадает на всех узлах одновременно. Доля серверов под общим регламентом стремится к 100%, а отзыв перестаёт зависеть от того, помнит ли дежурный про конкретную машину.

Привилегированных учёток — единицы, срок жизни ограничен

Вместо общей учётки root на каждом хосте — именные записи и правила sudo по ролям, а для разовых работ — временный доступ с датой окончания. Число привилегированных учётных записей сокращается до единиц, и каждый вход под ними объясним. Срок жизни учётной записи подрядчика или стажёра задаётся заранее: запись гаснет сама, и напоминать о ней никому не нужно.

Инцидент разбирается по журналам

Журналирование входа, вызовов sudo и правок в группах идёт в централизованный сбор, где запись привязана к человеку, а не к адресу машины. Разбор вопроса «кто и когда получил доступ к этому узлу» занимает минуты вместо дня переписки с командой.

Разграничение доступа в Linux: локальные записи, каталог, домен

Схема учётных записей определяется не размером парка, а тем, где живёт источник истины и кто отвечает за отзыв доступа. Локальные записи в /etc/passwd и /etc/group работают, пока машин десятки: увольнение сотрудника превращается в обход всех хостов, идентификаторы расходятся между стендами, а наследие в sudoers приходится сверять вручную.

Ниже — три схемы, между которыми реально выбирают. У каждой своя цена в поддержке, и её видно только на второй год эксплуатации.

На практике почти всегда получается гибридная схема: домен отвечает за людей и группы, локальные записи — за сервисы, которым домен не нужен (демоны, резервное копирование, мониторинг). Ключевое здесь — заранее закрепить диапазоны идентификаторов под каждую роль, иначе при подключении хоста к каталогу существующие файлы поменяют владельца и приложение перестанет читать свои данные. Второе условие — управление группами через правила, а не правкой файлов на хосте: тогда отзыв доступа проверяется одной командой и остаётся в журнале аудита.

Как проходит внедрение: от аудита записей до регламента

Внедрение идёт не с правки конфигов, а с полной картины: в парке серверов учётные записи накапливаются, доступ «на время» остаётся навсегда, при увольнении блокируют вход в систему, но забывают ключи в authorized_keys, sudo-правила и задачи в cron. Поэтому пор�� док обратный привычному: сначала фиксируем, что есть, потом проектируем роли, и только затем меняем конфигурацию.

1. Аудит учётных записей. Собираем список пользователей и групп с хостов, разбираем sudoers, сроки действия паролей, ключи и сервисные аккаунты, сверяем с реальными сотрудниками и владельцами процессов.
2. Инвентаризация прав. Строим матрицу «кто — какая группа — какое sudo-правило — на каких хостах», помечаем избыточные права с отключённым паролем и доступ к каталогам, которым он не нужен.
3. Схема доступа. Формулируем роли — администратор, дежурный, разработчик, сервисный аккаунт — и правила: права выдаются группами, а не персонально, вход root по паролю закрыт, централизованный источник учётных записей обязателен.
4. Настройка. Переносим схему в описание конфигурации, чтобы доступ воспроизводился на новом хосте, а не настраивался руками: группы, sudo-политики, ограничения сессий, запись действий в системный журнал.
5. Проверка на стенде, затем на бою. Проверяем синтаксис правил до применения, раскатываем группами серверов с сохранением предыдущей версии конфигурации — откат занимает минуты.
6. Проверка после внедрения. Проходим тесты от лица каждой роли: нужная команда проходит, лишняя отбивается, попытка повышения прав попадает в журнал. На выходе — отчёт «до и после» по числу записей и правил.
7. Передача регламента. Отдаём документ: как завести и как закрыть учётную запись, что делать при увольнении, кто и с какой периодичностью пересматривает права; проводим обучение ответственных и передаём шаблоны проверок.

Конфигурации, схемы доступа и регламенты по учётным записям

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

• Файлы конфигураций — правила входа, ограничения sudo и настройки подключения к каталогу, разложенные по ролям и хостам, а не один общий слепок на весь парк.
• Карта ролей и групп — таблица «роль → группы → хосты → уровень доступа», по которой сразу видно, кто и куда попадает.
• Политики паролей и ключей — срок жизни, сложность, блокировка после неудачных попыток, требования к ключам и второй фактор для административных учёток.
• Регламент выдачи и отзыва прав — заявка, согласующий, срок действия временного доступа, порядок действий при увольнении и переводе.
• Порядок пересмотра прав — сверка активных учёток с кадровыми данными по расписанию и отдельный обход служебных учёток и сервисных ключей.
• Документация по учётным записям — где эталонная конфигурация, как проверить расхождение на хосте, что делать при отказе входа.
• Инструкции для службы поддержки — типовые сценарии: сотрудник ушёл, сменил роль, потерял ключ, нужен разовый доступ на сутки.

Каждый пункт проверяем: разворачиваем доступы на чистом стенде строго по документации и смотрим, где её не хватило. Обычно после такой прогонки инструкции становятся короче, а карта ролей — точнее.

Кейс: единая модель доступа вместо разъехавшихся записей

Что было до работ

К нам пришла Розничная сеть с парком из 40 серверов, где доступ жил в локальных файлах: у каждого администратора своя запись в sudoers или в группе wheel, пароли пересылались в мессенджерах, а ssh-ключи не отзывались после увольнения. Инвентаризация показала 340 записей с повышенными правами — часть принадлежала подрядчикам, которые уже год не касались инфраструктуры. Разбор одного инцидента с падением сервиса занимал три дня: по логам нельзя было понять, чья учётка запускала команду и что именно менялось на диске.

Что изменили и что получилось

Учётные записи свели в единый каталог, а права описали ролями по зонам ответственности, а не по людям. Постоянные привилегии оставили только дежурной смене, агентам мониторинга и сервисным учёткам; остальным выдаём временные — на 4 часа, с указанием задачи и автоматическим истечением срока. Пароли убрали в пользу ключей, а каждое действие с повышенными правами пишется в общий журнал с привязкой к конкретному человеку.

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

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

Что делать, если учётные записи уже разъехались по серверам?

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

Первый шаг на живой инфраструктуре — опись, а не правки. Собираем по всем хостам локальных пользователей и группы, их UID, состав групп, права sudo, владельцев каталогов с данными и активные ключи доступа. Делаем это сборщиком фактов (у нас — Ansible), на выходе — сводная таблица, где сразу видно, кого трогать нельзя вообще, а кого можно переводить первой волной.

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

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

Технические вопросы по учётным записям и правам доступа

Учётные записи и права — область, где изменения копятся годами и редко ревизуются. Ниже — ответы на вопросы, которые чаще всего возникают при разборе доступа и передаче регламента.

Как заводить сервисные учётки?

Без оболочки входа и с минимумом прав: оболочка nologin, доступ к нужным каталогам через группу, а не через право записи для всех. Так сервис не превращается в готовую точку входа для атакующего.

Как дать доступ подрядчику и не потерять контроль?

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

Можно ли выдать права на время?

Да, это штатный режим: правила выдачи выносим в отдельные файлы, включаем и отключаем их по расписанию, а срок жизни самой учётной записи ограничиваем отдельным параметром.

Кому принадлежит регламент после передачи?

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

Расскажите о своём парке серверов — вернёмся с планом

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

Что прислать для старта обсуждения:

• Источник учётных записей: локальные файлы, каталог LDAP или домен Active Directory, а также есть ли гибридные схемы.
• Правила входа: настройки SSH — запрет пароля для сервисных учётных записей, ограничение по группам, отключён ли прямой вход суперпользователя.
• Список привилегированных ролей: кто и через что получает повышенные права, есть ли разовые исключения в sudoers.
• Политику жизненного цикла: срок действия пароля, блокировка после неудачных попыток, порядок увольнения и отзыва ключей.
• Куда пишутся журналы входа и смены прав: локальные файлы, выделенный сервер сбора или внешняя система.
• Инвентарь: сколько серверов, какие группы образов, есть ли контуры с отдельными требованиями к доступу.

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