Мой DBA Oracle должны базироваться доступ?

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

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

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

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

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

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

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

Дайте администратору баз данных привилегии root, если:

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

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

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

EDITED

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

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

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

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

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

Вам решать, сколько времени вы «потратите впустую», пока проблема не будет решена. Я просто хотел указать, что сильное разделение ролей в некоторых случаях может стоить очень дорого. Поэтому вместо увеличения «безопасности» сосредоточьтесь на снижении рисков и опасностей. Что не то же самое. Такие инструменты, как 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 или оболочки шпиона позволяют вам «запись» всего сеанса SSH, таким образом, они грантополучатель undeniableness. Это может служить лучше, чем sudo ". Кроме того, вам следует спросить, кто отслеживает SSA.

Если на серверах используется программное обеспечение Oracle Grid Infrastructure, такое как CRS, RAC или Oracle Restart, то многие критически важные службы баз данных работают от имени пользователя root, а многие важные файлы конфигурации базы данных принадлежат пользователю root. Это неотъемлемая черта дизайна программного обеспечения. Если это является нарушением ваших политик, их необходимо пересмотреть.

Администратору баз данных потребуется root-доступ для администрирования этих функций. Теоретически вы можете попросить у него список команд, которые он ожидает запустить для ввода в Sudo, но ответ будет очень длинным. Просто посмотрите в $ GRID_HOME / bin список всех двоичных файлов, которые администратор базы данных может использовать на регулярной основе. Если они выполняют действия по установке исправлений (а они должны быть), список может стать еще длиннее.

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

Я только что задал похожий вопрос. На самом деле, причина, по которой сисадмин не хочет давать корневую привилегию, я думаю, в ответственности и подотчетности.

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

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

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

Лично я бы поставил вопрос наоборот. Почему сисадмин должен иметь привилегию root на выделенном сервере БД? На самом деле, его специализация потребуется в гораздо меньших случаях, чем у DBA (с привилегией root).