☰

Вы готовы отказаться от root-доступа?

tag-icon • tag-icon security
Вы готовы отказаться от root-доступа?

Есть предыдущий вопрос:

Стоит ли нам отключить пользователя root?

Большинство людей, выступавших против этой возможности, говорили, что она вам понадобится, и у вас будут большие проблемы, если ее не будет.

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

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

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

решение1

Когда возможности будут поддерживаться более глобально во всем, это безусловно так.

До тех пор я буду держаться sudoподальше от нескольких вещей, которые все еще требуют явного повышения привилегий. Однако в последний раз, когда я это изучал, понятие возможностей все еще относительно не поддерживалось во многих системах из коробки. Это было бы важно иметь. Таким образом, независимо от того, какая у вас система, вы можете сказать «Этот пользователь имеет возможность получить к этому доступ», без фактического повышения до другой учетной записи пользователя. Конечно, предоставленные привилегии должны быть основаны на ролях пользователей в системах, но в конечном итоге никто не должен обладать всеми полномочиями учетной записи (по крайней мере, если есть несколько функций, которые используются для обработки другими).

Если вы DBA, вам не нужна никакая форма доступа суперпользователя, пока вы владеете системным процессом базы данных и областью(ями) хранения файловой системы. Это может означать, что вам придется попросить администратора диска выполнить fsck на ваших разделах или восстановить их время от времени, или что-то еще, но DBA не должен иметь возможности вывести машину из строя с собственными правами доступа, если только он не «владеет» сервером.

Тем не менее, если вы единственный человек, управляющий 100% процессов на сервере, то этого sudoабсолютно достаточно. Только когда у вас есть другие, которые используют сервер и/или управляют вещами на нем (или зависят от него), и есть несколько администраторов, то разделение привилегий вступает в силу, в любом случае.

решение2

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

решение3

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

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

Если система стандартная *nix (или близкая к стандартной), то мне, вероятно, понадобитсякореньдоступ к какой-то административной задаче в какой-то момент, просто потому, что так было десятилетиями, и в этом способе ведения дел много инерции. Но это не значит, что я буду входить в систему под этой учетной записью, когда она мне не нужна, или оставлю эту учетную запись открытой и незащищенной.

Если я не несу ответственности за хост, то мне, вероятно, не следует давать учетную запись root. На самом деле, я часто стараюсь не позволять кому-либо сообщать мне пароль root.

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

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

решение4

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

  • Полностью отключите удаленный доступ или разрешите SSH только с аутентификацией по ключу.
  • Отключить/заблокировать пароль root (а-ля Ubuntu).
  • Строго требуйте использования sudoи обеспечьте правильность ведения журнала.
  • Заблокировать /bin/suвозможность выполнения только определенной группой (часто, wheelили sysadmin).
  • Убедитесь, что корневые оболочки хорошо протоколируются (принудительно script, с использованием sudosh, трюками с историей оболочек и т. д.).
  • rootПрава предоставляются только пользователям, которым требуется доступ sudo ALL, в противном случае права предоставляются через sudo на основе каждого использования.

UID 0 по-прежнему требуется, особенно для таких задач, как открытие портов ниже 1024, даже если права доступа сбрасываются после запуска приложения.

Безопасность и удобство являются взаимоисключающими в ИТ. Использование rootучетной записи напрямую часто является вопросом удобства, а не необходимости, возможно, потому, что администраторы ненавидят sudoпостоянно печатать?

Связанный контент