Security

Нужен ли моему администратору баз данных Oracle root-доступ?

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

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

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

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

Ответ 1

  1. Кто устанавливает Oracle на серверы?

  2. Если это DBA, то ему нужен root-доступ. Если это сисадмин, то DBA не нужен.

  3. Кто ответственен, когда сервер базы данных не работает?

  4. Если вы не можете обеспечить доступность сисадминов 24 часа в сутки 7 дней в неделю, вы можете предоставить root-доступ DBA.

Имейте в виду, что, если ваш DBA уже имеет shell-доступ как обычный пользователь (с некоторыми командами, которые он может выполнять через sudo; с chrooted или без него), этого достаточно, чтобы испортить сервер (злоумышленник, укравший его аккаунт, может форкнуть систему, превысить ulimit рассылки спама, уронить базу данных…).

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

Ответ 2

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

 

  1. Тем, кто не знает, что делает.

  2. Высокомерным и нежелающим сотрудничать.

  3. И то и другое.

Могут быть реальные причины, по которым им нужен root-доступ, чтобы справиться со своей задачей, но, опять же, если они не могут объяснить причину и изложить ее в письменном виде, я бы не стал иметь с ними дело. Профессионалы, работающие с серверами, понимают и уважают границы. В тех случаях, когда мне приходилось иметь дело с такими людьми, я настаивал на том, чтобы время было запланировано заранее, чтобы я мог находиться на сервере вместе с ними и решать вопросы по мере их возникновения. И это действительно хорошо работало. Другая альтернатива, которая может оказаться непрактичной, – создать точный клон сервера, о котором идет речь, и дать им root-доступ на нем. Конечно, не забудьте изменить пароль на что-то специфическое для них. 

Ответ 3

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

  1. Вы не хотите, чтобы вас будили посреди ночи только для того, чтобы перезагрузить сервер.

  2. Вы хотите быстро и без проблем справиться с инцидентами.

  3. Если ваш сервер предназначен только для сервера БД.

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

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

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

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

  1. Связанные с памятью (конфигурация больших/огромных страниц, разделяемая RAM (ipcs), не заменяемая (заблокированная) RAM).

  2. Связанные с сетями (размер окна отправки/получения, TCP keepalive).

  3. Связанные с хранением данных (количество открытых файлов, асинхронный ввод-вывод).

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

Хранение: правила Linux udev не гарантируют постоянных имен загрузочных устройств, поэтому Oracle предоставил драйвер ядра и инструменты (AsmLib). Они позволяют вам «маркировать» физические разделы от имени root, а затем вы можете видеть эти метки при администрировании хранилища базы данных.

Исследование проблемы:

  1. Когда база данных падает, потому что не может открыть больше файловых дескрипторов, единственное решение увеличить лимит ядра, выполнить «sysctl –p» и затем запустить БД.

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

  3. (DCD) – обнаружение «мертвого» соединения. Например, на AIX netstat не печатает PID. Единственный способ сопоставить TCP-соединение с PID – отладчик ядра.

  4. glance (что-то вроде top на HP-UX) требует root privs.

  5. Различные исследования уровня Veritas.

  6. И многие-многие другие.

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

Ответ 4

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

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

Современные DBA взяли на себя дополнительную ответственность за сервер базы данных, где сервер базы данных является членом Oracle Real Application Cluster (RAC) и использует Oracle Automatic Storage Management (ASMLIB) для представления общего хранилища для базы данных RAC. Управление RAC и ASM со стороны DBA разгружает и без того перегруженного работой системного администратора, что должно стать желанным вкладом в работу группы/команды STS. Также «...сильное разделение ролей может быть очень дорогим в некоторых случаях». Кроме того, вам следует определить, кто следит за SSA.

Ответ 5

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

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

Ответ 6

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

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

Схожие статьи

Security

Есть ли веские причины для отключения виртуализации с аппаратной поддержкой?

Security

Нужен ли в Linux антивирус?

Security

Ошибка автоблокировки Cygwin SSHd при входе в систему

Security

Как защитить общедоступный сервер удаленного рабочего стола?

×