Назад | Перейти на главную страницу

Как лучше всего определить список команд и доступ, который потребуется для администрирования определенного приложения?

Моей команде необходимо установить и администрировать очень большое приложение в Red Hat 5.7, и мне нужно иметь возможность делать это с правами root. Во время проекта группа поддержки Unix (которая отвечает за поддержку ОС) предоставляет нам (группе поддержки приложений) sudo весь доступ, чтобы мы могли это сделать. Однако наша внутренняя политика диктует, что после того, как сервер будет введен в действие (получит официальную поддержку нашей командой Unix и начнет работать), никто, кроме них, не должен иметь root-доступ.

Чтобы иметь возможность однозначно поддерживать рассматриваемое приложение, моей команде потребуется предоставить полный список команд и требований доступа команде Unix, чтобы они могли предоставить нам sudo доступ ко всем этим командам индивидуально. Поставщик приложения не поддерживает этот тип ограничительного администрирования и не имеет определенного рецепта, чтобы сделать это правильно и без проблем. Это будет в значительной степени методом проб и ошибок.

Тем не менее, что было бы лучшим методом для перечисления всех необходимых команд, которые нам нужно будет запустить, и для перечисления каждого доступа к каталогам / файлам, которые нам понадобятся?

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

Я начал с перечисления всех файлов с perms u + x и получил ошеломляющее количество файлов - 2801 после базовой, неизмененной установки. Это за исключением сценариев инициализации в /etc/init.d и других системных команд (таких как chown, chmod, ps, kill и т. Д.), Которые нам, возможно, также придется запустить.

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

Во-первых, мне нравится ваш первоначальный подход к поиску всех исполняемых файлов. Однако похоже, что у поставщика есть дурная привычка маркировать все исполняемые файлы. Я очень надеюсь, что в продукте нет 2 801 двоичного файла! Возможно, вы могли бы передать все эти файлы через file и посмотрите, какие на самом деле двоичные файлы, скрипты и т. д. Это должно сузить область действия.

Во-вторых, обязательно включите все, что требуется для остановки и запуска приложения. Похоже, поставщик устанавливает сценарий инициализации, так что, вероятно, это все, что вам нужно. Также доступ к less любые файлы журналов, если они хранятся в системном расположении, таком как / var / log, и недоступны для чтения непривилегированным пользователям.

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

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

Вот несколько моментов, которые можно счесть полезными (надеюсь):

  1. Веб-интерфейс избавит от необходимости иметь доступ по ssh и, следовательно, привилегии sudo.
  2. После того, как приложение заработало должным образом, ответственность за его запуск должна лежать на группе системных администраторов, а не на разработчиках.
  3. Вы можете запросить разрешения на изменение файлов конфигурации приложения и некоторых файлов данных, если таковые имеются. Нет необходимости изменять каждый файл / папку приложения.
  4. Если это тестовый сервер, разработчикам следует предоставить большую гибкость, чтобы они могли легко отлаживать приложение.