Нужен ли моему Oracle DBA root-доступ?

Мой коллега Oracle DBA запрашивает root-доступ на наших производственных серверах .
Он утверждает, что ему это нужно для выполнения некоторых операций, таких как перезагрузка сервера и некоторые другие задачи.

Я не согласен с ним, потому что я назначил ему пользователя / группу Oracle и группу dba, к которой принадлежит пользователь Oracle. Все работает без сбоев, и администратор базы данных не имеет root-доступа.
Я также считаю, что все административные задачи, такие как плановая перезагрузка сервера, должны выполняться соответствующим администратором (системным администратором в нашем случае), чтобы избежать любых проблем, связанных с неправильным пониманием взаимодействий инфраструктуры.

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

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

Я не ищу плюсы / минусы, а скорее совет о том, как мне следует поступить, чтобы справиться с этой ситуацией.

• Кто устанавливает Oracle на серверах?
  Если это администратор базы данных, им нужен root-доступ. Если это системный администратор, администратор базы данных - нет.

• Кому звонят поздно ночью, когда сервер базы данных выключен?
  Если вы не можете гарантировать, что системные администраторы доступны 24/7, вы можете предоставить root-доступ к администратору базы данных.

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

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

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

1. Тот, кто не знает, что они делают.
2. Высокомерный и не сотрудничающий.
3. Оба вышеперечисленных.

Теперь могут существовать реальные причины, по которым им нужен rootдоступ для выполнения своей задачи, но, опять же, если они не могут объяснить, почему и изложить это в письменной форме, я бы не стал с ними разбираться. Профессионалы, которые имеют дело с серверами, понимают и уважают границы. Горячие кадры, которые знают достаточно, чтобы попасть в беду, считают, что правила применимы ко всем, кроме них.

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

Другая альтернатива, которая может оказаться непрактичной, - создать точный клон рассматриваемого сервера и предоставить им rootдоступ к нему. Обязательно смените пароль на что-то конкретное для них, конечно. Пусть они взрывают изолированную коробку разработки.

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

Теоретически администраторы баз данных могут работать без прав доступа root, но это PITA для обеих сторон. Определить список команд, доступных для доступа, практически невозможно sudo.

Предоставьте администраторам баз данных привилегии, если:

• Вы не хотите просыпаться среди ночи, просто чтобы перезагрузить сервер
• Вы хотите быстрое и плавное управление инцидентами
• если ваш сервер предназначен только для сервера БД

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

Правильное прослушивание обеспечивает лучшие условия выполнения, чем строго определенные правила безопасности. Если вы провели аудит, вы всегда можете спросить, почему они что-то сделали / изменили. Если у вас нет аудита, у вас все равно нет безопасности.

отредактированный

Это список общих требований Oracle к автономным (некластеризованным установкам)

• Параметры ядра

  • Связанная с памятью (конфигурация больших / огромных страниц, общая оперативная память (ipcs), не подлежащая замене (заблокированная) оперативная память)
  • связанные с сетью (размер окна отправки / получения, TCP keepalive)
  • хранение связано (количество открытых файлов, асинхронный ввод-вывод)

  Там может быть около 15-20 параметров sysctl. Для каждого из них Oracle предоставляет рекомендуемое значение или уравнение. Для некоторых параметров рекомендуемое уравнение может меняться со временем (aync io), или в некоторых случаях Oracle предоставила более одного уравнения для одного и того же параметра.

• Хранение: правила Linux udev не гарантируют загрузку постоянных имен устройств. Поэтому Oracle предоставил драйвер ядра и инструменты (AsmLib). Это позволяет вам пометить физические разделы как корневые, а затем вы можете увидеть эти метки при администрировании хранилища базы данных.
• Исследование проблемы:
  • Когда база данных дает сбой, потому что она не может открыть больше файловых дескрипторов, тогда единственное решение состоит в том, чтобы увеличить ограничение ядра, выполнить 'sysctl -p' и затем запустить базу данных.
  • Также, когда вы обнаружите, что физическая RAM слишком фрагментирована и база данных не может выделять большие страницы, тогда единственный вариант - перезагрузить сервер.
  • (DCD) - обнаружение обрыва соединения. Например, в AIX netstat не печатает PID. Единственный способ связать TCP-соединение с PID - отладчик ядра.
  • glance (что-то вроде top в HP-UX) требует привилегий root
  • различные исследования уровня Veritas
  • и многие другие

Вам решать, сколько времени вы «потратите», пока проблема не будет решена. Я просто хотел указать, что сильное разделение ролей может быть очень дорогим, в некоторых случаях. Поэтому вместо повышения «безопасности» сосредоточьтесь на снижении рисков и опасностей. Который не то же самое. Такие инструменты, как ttysnoop или shell spy, позволяют вам «записывать» весь сеанс ssh, тем самым гарантируя неоспоримость. Это может служить лучше, чем sudo.

Я являюсь администратором базы данных Oracle, и мой ответ: обычно администратору базы данных не нужен root-доступ. Но RAC DBA? определенно ему нужен root-доступ для управления CRS, ведения домашнего хозяйства и всего остального.

Этот вопрос возник еще во времена, когда системы были намного проще, а процессы ОС и базы данных были определены и идентифицированы отдельно. Обязанности и ответственность системного администрирования и администрирования базы данных были очень разными. В современных ИТ-средах и, в частности, в современных серверах баз данных эти обязанности и ответственность чаще всего пересекаются. Системный администратор проводит комплексную проверку, чтобы ограничить «корневой» доступ в отношении «управления рисками».

С сегодняшними требованиями «высокой доступности» и «немедленного устранения» проблем, возникающих с нашими системами баз данных RAC, системные администраторы и администраторы баз данных обслуживают свои функциональные бизнес-сообщества, работая вместе как команда. Не должно быть никаких проблем с «доверием», так как обе стороны заинтересованы в том, чтобы серверы баз данных RAC находились в сети почти 100% времени. Имейте в виду, что администратор базы данных уже имеет доступ к оболочке в качестве администратора базы данных (с некоторыми командами или без них, которые он может запускать с помощью sudo; с или без использования chroot), поэтому очевидно, что DBA является «доверенным» агентом. Итак, на самом деле вопрос должен звучать так: «Почему Oracle DBA не нуждается в доступе?»

Современные администраторы баз данных взяли на себя дополнительные обязанности для сервера базы данных, где сервер баз данных является членом 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, заключается в ответственности и подотчетности, я думаю.

Но если это причина, администратор базы данных также должен быть единственным системным администратором. И причина проста. Если существует необходимость разделения ответственности и ответственности, системный администратор всегда может быть администратором базы данных. Он может выдавать себя за учетную запись оракула, он может войти в базу данных как SYSDBA и делать все, что угодно, без использования пароля SYS или SYSTEM.

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

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

Лично я бы поставил вопрос наоборот. Зачем системному администратору иметь права root на выделенном сервере баз данных? Фактически, его специальность потребовалась бы в гораздо меньшем количестве случаев, чем специальность администратора баз данных (с привилегией root).

Корневой доступ необходим для установки и исправления сетки Oracle. Обойти это невозможно. Если бы был способ предоставить временный root-доступ к DBA для таких нужд, это было бы идеально.