Мой коллега по Oracle DBA запрашивает root-доступ к нашему производственные серверы.
Он утверждает, что он нужен ему для выполнения некоторых операций, например перезагрузка сервер и некоторые другие задачи.
Я не согласен с ним, потому что я назначил ему пользователя / группу Oracle и группу dba, к которой принадлежит пользователь Oracle. Все работает без сбоев, и в настоящее время администратор баз данных не имеет доступа с правами root.
Я также думаю, что все административные задачи, такие как запланированная перезагрузка сервера, должны выполняться надлежащим администратором (системным администратором в нашем случае), чтобы избежать каких-либо проблем, связанных с непониманием взаимодействий инфраструктуры.
Я хотел бы получить комментарии как от системных администраторов, так и от администраторов баз данных Oracle. Есть ли веские причины для Администратор баз данных Oracle получит root-доступ в производственной среде?
Если моему коллеге действительно нужен такой уровень доступа, я предоставлю его, но я очень боюсь этого делать из-за проблем с безопасностью и целостностью системы.
Я не ищу плюсов и минусов, а скорее советую, как мне действовать в этой ситуации.
Кто устанавливает Oracle на серверы?
Если это администратор базы данных, им нужен root-доступ. Если это сисадмин, то администратор базы данных - нет.
Кому звонят поздно ночью, когда сервер базы данных не работает?
Если вы не можете обеспечить круглосуточную доступность системных администраторов, вы можете предоставить администратору базы данных root-доступ.
Имейте в виду, что если ваш администратор баз данных уже имеет доступ к оболочке как обычный пользователь (с некоторыми командами или без них, которые он может запускать через sudo; с chrooted или без него), этого достаточно, чтобы возиться с сервером (плохой парень, крадущий его учетную запись, может разветвить бомбу , превышение ulimit рассылки спама, удаление базы данных, ...).
По всем этим причинам я думаю в идеальном мире администраторы баз данных не должны иметь root-доступ; но в реальном мире они, по крайней мере, всегда должны иметь возможность получить его в случае крайней необходимости.
В общем - и не только для администраторов баз данных - всем, кто требует root доступ без указания уважительной причины:
Теперь, возможно, им нужны реальные причины root доступ для решения их задачи, но, опять же, если они не могут объяснить, почему и изложить это в письменной форме, я бы не стал с ними заниматься. Профессионалы, работающие с серверами, понимают и уважают границы. Горячие стрелки, которые знают достаточно, чтобы попасть в беду, считают, что правила применимы ко всем, кроме них.
В тех случаях, когда мне приходилось драться с такими людьми, я настаивал на том, чтобы время было запланировано заранее, чтобы я мог быть на сервере с ними, чтобы решать проблемы по мере их возникновения. И это действительно хорошо сработало.
Другая альтернатива - которая может оказаться непрактичной - - создать точный клон рассматриваемого сервера и предоставить им root доступ к этому. Не забудьте, конечно, сменить пароль на что-то конкретное для них. Пусть взорвут изолированную коробку для разработки.
Но в целом, если вам позвонят поздно вечером, чтобы убрать беспорядок, который может создать этот парень, то у вас есть полное право отказаться от общей просьбы. root доступ.
Теоретически администраторы баз данных могут работать без root-прав, но это PITA для обеих сторон. Практически невозможно определить список команд, которые будут доступны через sudo.
Предоставьте администратору баз данных привилегии root, если:
Администраторам баз данных обычно требуются root-права для: настройки параметров ядра (sysctl), манипулирования хранилищем, исследования проблем.
Правильное прослушивание обеспечивает лучшие условия выполнения, чем строго определенные правила безопасности. Если вы внедрили аудит, вы всегда можете спросить, почему они что-то сделали / изменили. Если у вас нет аудита, у вас все равно нет безопасности.
ИЗМЕНЕНО
Это список общих требований Oracle к автономным (некластеризованным установкам).
Параметры ядра
Может быть около 15-20 параметров sysctl. Для каждого из них Oracle предоставляет рекомендуемое значение или уравнение. Для некоторых параметров рекомендуемое уравнение может меняться со временем (aync io), или в некоторых случаях Oracle предоставил более одного уравнения для одного и того же параметра.
Вам решать, сколько времени вы «потратите впустую», пока проблема не будет решена. Я просто хотел указать, что сильное разделение ролей может быть очень дорогим в некоторых случаях. Поэтому вместо увеличения «безопасности» сосредоточьтесь на снижении рисков и опасностей. Что не то же самое. Такие инструменты, как ttysnoop или оболочки шпион позволяют вам «записи» весь SSH сессии, таким образом, они грантополучателю undeniableness. Это может быть лучше, чем sudo.
Я администратор баз данных Oracle, и мой ответ такой: обычно администратору баз данных не требуется root-доступ. Но администратор базы данных RAC? определенно ему нужен root-доступ для управления CRS, ведения домашнего хозяйства и всего остального.
Этот вопрос возник в то время, когда системы были намного проще, а процессы ОС и базы данных определялись и определялись отдельно. Обязанности и ответственность системного администрирования и администрирования баз данных были очень разными. В современных ИТ-средах и, в частности, в современных серверах баз данных эти обязанности и ответственность, как правило, часто совпадают. Системный администратор тщательно следит за ограничением «корневого» доступа в отношении «управления рисками».
В связи с сегодняшними требованиями «высокой доступности» и «немедленного устранения» проблем, возникающих с нашими системами баз данных RAC, системные администраторы и администраторы баз данных обслуживают свои функциональные бизнес-сообщества, работая вместе как одна команда. Не должно быть никаких проблем с «доверием», поскольку обе стороны кровно заинтересованы в том, чтобы серверы баз данных RAC находились в режиме онлайн почти 100% времени. Имейте в виду, что администратор баз данных уже имеет доступ к оболочке в качестве администратора базы данных (с некоторыми командами или без них, которые он может запускать через sudo; с привязкой к корневому каталогу или без нее), поэтому очевидно, что администратор базы данных является «доверенным» агентом. Итак, в действительности вопрос должен быть таким: «Почему администратору баз данных Oracle не нужен доступ?»
Сегодняшние администраторы баз данных взяли на себя дополнительные обязанности по отношению к серверу базы данных, где сервер базы данных является членом Oracle Real Application Cluster (RAC) и использует Oracle Automatic Storage Management (ASMLIB) для представления общего хранилища в базе данных RAC. Управление RAC и ASM администратором баз данных облегчает и без того перегруженного работой системного администратора, что должно быть желанным вкладом в группу / команду STS.
И, как заявил ibre5043, «... строгое разделение ролей может быть очень дорогостоящим в некоторых случаях. Поэтому вместо увеличения« безопасности »сосредоточьтесь на снижении рисков и опасностей. Что не то же самое. Такие инструменты, как ttysnoop или shell spy, позволяют вам к «записи» всего сеанса SSH, таким образом, они грантополучатель undeniableness. Это может служить лучше, чем Судо «. Кроме того, вам следует спросить, кто следит за SSA.
Если на серверах используется программное обеспечение Oracle Grid Infrastructure, такое как CRS, RAC или Oracle Restart, то многие критически важные службы баз данных работают от имени пользователя root, а многие важные файлы конфигурации базы данных принадлежат пользователю root. Это неотъемлемая черта дизайна программного обеспечения. Если это нарушение ваших политик, их необходимо пересмотреть.
Администратору базы данных потребуется root-доступ для администрирования этих функций. Теоретически вы можете попросить у него список команд, которые он ожидает запустить для ввода в Sudo, но ответ будет очень длинным. Просто посмотрите в $ GRID_HOME / bin список всех двоичных файлов, которые администратор базы данных может использовать на регулярной основе. Если они выполняют действия по установке исправлений (а они должны быть), список может стать еще длиннее.
Я только что задал похожий вопрос. На самом деле причина, по которой системный администратор не хочет предоставлять привилегии root, я думаю, это ответственность и подотчетность.
Но если это причина, администратор базы данных также должен быть единственным системным администратором. Причина проста. Если есть необходимость разделения подотчетности и ответственности, системный администратор ВСЕГДА может также быть администратором баз данных. Он может выдавать себя за учетную запись oracle, он может войти в базу данных как SYSDBA и делать все, что угодно, без необходимости ввода пароля SYS или SYSTEM.
Так что, на мой взгляд, если существует необходимость разделения системных администраторов и администраторов баз данных из-за подотчетности и ответственности, единственной логической причиной является то, что сервером также должен управлять администратор баз данных, а не системный администратор. За сервер и базу данных в целом должен нести ответственность администратор баз данных, который также должен обладать некоторыми знаниями системного администрирования.
Если сервер используется не только для размещения базы данных, и это требует отдельной ответственности и подотчетности, это означает проблемы. Но если сервер используется только для размещения базы данных, то я не вижу причин, по которым администратор базы данных не должен иметь привилегию root, учитывая бесчисленное количество случаев, которые ему тоже понадобятся.
Лично я бы поставил вопрос наоборот. Зачем системному администратору иметь привилегию root на выделенном сервере базы данных? Фактически, его специальность потребуется в гораздо меньшем количестве случаев, чем специализация администратора базы данных (с привилегиями root).
Для установки Oracle grid и исправлений требуется root-доступ. Нет никакого способа обойти это. Если бы существовал способ предоставить временный root-доступ администратору баз данных для таких нужд, это было бы идеально.