Кто получает root-доступ?


8

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

Вопрос, к которому мы постоянно возвращаемся, таков: кто получает права root?

Наши экземпляры сервера будут иметь пользователя root. Этот пользователь root будет иметь пароль. Кто должен иметь доступ к этому? Возможно ли / желательно иметь машину, на которой никто не может иметь root-доступ?

Буду признателен за любые ваши мысли по этому вопросу.


Это привлекло мое внимание. Похоже, хорошая практика.
Росс Макфарлейн

Ответы:


14

Никто. Сделайте sudoтак, чтобы они использовались так, чтобы все команды корневого уровня регистрировались и относились к конкретному человеку.


6
+1. Измените пароль root на что-то очень случайное, распечатайте его и запечатайте в конверт только для экстренного использования.
EEAA

4
также измените свою корневую учетную запись .bashrc, чтобы PROMPT_COMMAND был настроен на запись всего как обычного пользователя root в syslog. Handy.
Sirex

1
пользователь может использовать sudo для запуска оболочки, тогда команды не будут регистрироваться (только для входа в bash)
ooshro

правда, если они не делают "sudo bash -l" - что они должны. если вы установите корень .bashrc prompt_command, он тоже запишет это, что является одной из причин, по которой его стоит делать.
Sirex

+1 Также обязательно установите sudo для более высоких уровней доступа. В одном месте все корневые пароли хранились в запечатанном конверте на всякий случай, если печать была сломана, о ней нужно было сообщить в целях безопасности и сменить пароли.
st3v3o

3

Никто, кроме, может быть, аппаратного администратора не получает пароль root! Пароль root должен использоваться только на консоли, а не через SSH или другие службы.

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


-1

Если вы используете и развертываете selinux, можно удалить типичную учетную запись «все видят, все знают», которая является обычной настройкой root, и преобразовать ее в учетную запись с большей безопасностью.


1
как? Ответ не очень полезен, если он не дает никаких указаний относительно того, как;)
0xC0000022L

Тема слишком большая, чтобы уместиться в одном ответе. Но, насколько мне известно, selinux может (и часто используется) для этой цели.
Sirex

-5

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

По этой причине я бы порекомендовал использовать su (переключается на пользователя root) вместо sudo (временно повышает права доступа к корневому уровню для одной команды). Если им нужно разрешение root, измените их на пользователя root.

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


4
@ user76897: я не согласен. sudoидеально подходит для этой цели, и он регистрирует каждую команду, непосредственно переданную с sudoпрефиксом. Где, когда используется su, вы получаете оболочку, и ничего внутри этой оболочки не регистрируется. /etc/sudoersможно настроить очень сильно. Вы можете сказать, какая команда может быть выполнена каким пользователем, каким пользователем и требуется ли пароль, или нет, а также множество других полезных опций. Одна из причин, по которой кому-то может понадобиться root - перезапустить демон. Это легко сделать sudoбез предоставления полного доступа к учетной записи root.
0xC0000022L

Этот ответ не имеет никакого смысла или адрес вопроса. Предпочтение suover sudoне защищено и, согласно большинству других голосов здесь, фактически будет частью первоначальной проблемы парней, а не решением.
Калеб
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.