Журнал sudoer и электронной отчетности
У меня есть пользователь в моей системе Ubuntu, которому нужен доступ sudo, но я не доверяю ему так сильно, как хотел бы. Есть ли способ записать все его действия sudo и отправить мне по электронной почте в конце дня?
3 ответа
Это не очень хорошая идея. В этом плане есть несколько недостатков.
Если ты ему не доверяешь, не давай ему доступа. Отправка вам по электронной почте его зла в конце дня ничего не поможет, если он сделал это уже к вечеру. И если бы он действительно хотел скомпрометировать систему, он наверняка нашел бы способ манипулировать этими противными электронными письмами. Это довольно простой расчет, если пользователь, которому вы не доверяете, имеет административные привилегии в системе, вы не можете доверять системным наблюдениям.
Если ему действительно нужен доступ, можем ли мы обойти привилегии суперпользователя? И если он действительно нуждается в sudo, может ли он быть ограничен только некоторыми командами.
Простой способ сделать это - настроить logwatch на вашем компьютере. По умолчанию logwatch генерирует электронную почту каждую ночь, которая включает в себя различные сведения о системе и важные сообщения журнала. По умолчанию он также включает все зарегистрированные команды sudo.
Затем просто установите адрес электронной почты logwatch в /etc/logwatch.conf на ваш адрес, и вы будете получать эти письма каждую ночь.
Я настоятельно советую вам поговорить с данным пользователем и честно поделиться с ним своими проблемами. Гораздо лучше для него узнать, что он может спросить вас, не смущен ли он чем-либо, чем для вас, чтобы найти ошибки в журналах. Доверяй, но проверяй.
Это классический пример концепции "Принцип наименьших привилегий". То есть пользователь должен иметь наименьший доступ, необходимый для выполнения его рабочих функций. Реальное решение вашей проблемы - внедрить стандартную рабочую процедуру, которая ограничивает полные права администратора на сервере только теми людьми, которые фактически администрируют сервер. Хотя это легко предположить, с вашей стороны потребуется немало усилий для реализации и, как правило, потребуется изменение бизнес-процесса для администраторов баз данных, администраторов приложений и т. Д.
Что вам нужно сделать, это сесть с пользователем и точно определить, что пользователь делает с помощью этой системы, и наметить, какие права доступа это повлечет за собой. Здесь действительно сложно определить, что им нужно делать, а не то, как они это делают. Некоторые из типов вопросов, с которых вы должны начать, это то, что им нужно для редактирования системных файлов, перезапуска служб, просмотра файлов журнала и т. Д.
После того, как вы каталогизировали эту информацию, вы можете начать выяснять, нужно ли вам что-то делать. Например, если файл в / etc / sysconfig необходимо изменить, должен ли пользователь подготовить изменение и затем передать его системному администратору для развертывания? Или, если они должны иметь возможность управлять службами, какие команды на самом деле требуются для этого, и нужно ли это делать как root или как учетная запись службы?
В конце упражнения у вас должен быть список команд, которые им нужно выполнить (и кому), файлы, к которым они должны получить доступ, и процедуры, которые вы и пользователь можете выполнить для внесения ненормальных изменений.