¿Mi DBA de Oracle necesita acceso de root?

14

Mi colega de Oracle DBA solicita acceso a la raíz en nuestros servidores de producción .
Él está argumentando que lo necesita para realizar algunas operaciones como reiniciar el servidor y algunas otras tareas.

No estoy de acuerdo con él porque le he configurado un usuario / grupo de Oracle y un grupo dba al que pertenece el usuario de Oracle. Todo funciona sin problemas y sin que el DBA tenga acceso root actualmente.
También creo que todas las tareas administrativas, como el reinicio programado del servidor, deben ser realizadas por el administrador adecuado (el administrador de sistemas en nuestro caso) para evitar cualquier tipo de problemas relacionados con un malentendido de las interacciones de la infraestructura.

Me gustaría recibir información de los administradores de sistemas y los DBA de Oracle: ¿hay alguna buena razón para que un DBA de Oracle tenga acceso de root en un entorno de producción ?

Si mi colega realmente necesita este nivel de acceso, lo proporcionaré, pero tengo mucho miedo de hacerlo debido a problemas de seguridad e integridad del sistema.

No busco pros / contras, sino consejos sobre cómo debo tomar para hacer frente a esta situación.

Dr. I
fuente
12
Pida una lista de comandos que necesita y luego adapte su archivo sudoers para permitir solo esos comandos.
dmourati
Diría que seguir el camino de los sudoers, como se sugirió anteriormente, es claramente el camino correcto.
Sami Laine
No usaré sudo, este es un servidor confidencial controlado y de acceso restringido, lo haré de la manera difícil usando POSIX Rights y Chrooted / limited prompt shell.
Dr I
En mi humilde opinión como administrador de sistemas, siempre sigo el camino de los sudoers y restrinjo el acceso en la medida de lo posible. Es mejor comenzar con lo mínimo y luego agregar acceso a los comandos de forma incremental según sea necesario. +1 @dmourati
sgtbeano
77
Su DBA necesita la contraseña de root tanto como necesita SYSDBAacceso.
Michael Hampton

Respuestas:

14
  • ¿Quién instala Oracle en los servidores?
    Si es el DBA, necesitan acceso de root. Si es administrador del sistema, el DBA no.

  • ¿A quién se llama tarde en la noche cuando el servidor de la base de datos está inactivo?
    Si no puede asegurarse de que los administradores del sistema estén disponibles las 24 horas, los 7 días de la semana, es posible que desee otorgar acceso de root al DBA.

Tenga en cuenta que si su DBA ya tiene acceso de shell como usuario normal (con o sin algunos comandos que puede ejecutar a través de sudo; con o sin chrooteado), eso es suficiente para meterse con el servidor (un tipo malo que roba su cuenta puede bifurcar) , exceda el envío de spam de ulimit, descarte la base de datos, ...).

Por todas estas razones, creo que en un mundo ideal, los DBA no deberían tener acceso de root ; pero en el mundo real, al menos siempre deberían poder obtenerlo en caso de emergencia.

voretaq7
fuente
3
puede usar sudoreglas de sudo válidas en lugar de dar acceso a la raíz.
jirib
3
@Jiri: Tener algo como% dba ALL = (ALL) ALL en / etc / sudoers en realidad está dando acceso a la raíz. Listado de un conjunto restringido de comandos para dba es lo que yo llamo "acceso de shell regular".
2
Oracle + docker suena como una receta para el desastre. Sudo no está permitido? Parece que quien está restringiendo el medio ambiente no tiene idea de lo que está haciendo.
dmourati
44
@DrI Extracción sudoy dar a las personas el acceso root sin restricciones es un paso muy importante HACIA ATRÁS en la seguridad del sistema. Seré franco, si las cosas de tu jefe sudoson "tecnología esotérica" ​​son un idiota.
voretaq7
1
@ voretaq7 Lo sé, pero como ya lo dije, estoy trabajando para una gran corporación, no para mí, así que no manejo todos los aspectos de nuestra TI y tengo que lidiar con mis herramientas ;-) Mi pregunta principal estaba relacionada a las NECESIDADES de que DBA tenga acceso a la raíz, y la mayoría de la gente piensa lo contrario, así que investigaré más sobre sus necesidades ;-) y luego trataré con él por una situación comprometida.
Dr I
6

En general, y no específico para los DBA, cualquiera que exija rootacceso sin dar una razón válida es:

  1. Alguien que no sabe lo que está haciendo.
  2. Arrogante y poco cooperativo.
  3. Ambos de los anteriores.

Ahora, puede haber razones reales por las que necesitan rootacceso para manejar su tarea, pero de nuevo si no pueden explicar por qué y ponerlo por escrito, no trataría con ellos. Los profesionales que trabajan con servidores entienden y respetan los límites. Las personas que saben lo suficiente como para meterse en problemas creen que las reglas se aplican a todos menos a ellos.

En los casos en que he tenido que lidiar con personas como esta, he insistido en que se programe el tiempo con anticipación para poder estar en el servidor con ellos para manejar los problemas a medida que surjan. Y esto realmente ha funcionado bien.

Otra alternativa, que podría no ser práctica, es crear un clon exacto del servidor en cuestión y darles rootacceso a eso. Asegúrese de cambiar la contraseña a algo específico para ellos, por supuesto. Deja que exploten una caja de desarrollo aislada.

Pero, en general, si usted es el que será llamado a altas horas de la noche para limpiar un desastre que este tipo podría crear, entonces tiene todo el derecho de decir no a una solicitud general de rootacceso.

JakeGould
fuente
4

Teóricamente, los DBA pueden funcionar sin privilegios de raíz, pero es PITA para ambos lados. Es prácticamente imposible definir una lista de comandos a la que se pueda acceder mediante sudo.

Proporcione privilegios de raíz de DBA si:

  • no desea que lo despierten en medio de la noche, solo para reiniciar el servidor
  • desea una gestión de incidentes rápida y fluida
  • si su servidor está dedicado solo para el servidor DB

Los DBA generalmente necesitan privs raíz para: ajustes de parámetros del kernel (sysctl), manipulación de almacenamiento, investigación de problemas.

La audición adecuada garantiza mejores condiciones de ejecución que las reglas de seguridad estrictamente definidas. Si ha implementado la auditoría, siempre puede preguntar por qué hicieron / cambiaron algo. Si no tiene auditoría, no tiene seguridad de todos modos.

EDITADO

Esta es una lista de los requisitos comunes de Oracle en autónomo (instalaciones no agrupadas)

  • Parámetros del núcleo

    • Relacionado con la memoria (configuración de páginas grandes / grandes, RAM compartida (ipcs), RAM no intercambiable (bloqueada))
    • redes relacionadas (tamaño de ventana de envío / recepción, TCP keepalive)
    • relacionado con el almacenamiento (número de archivos abiertos, IO asíncrono)

    Puede haber unos 15-20 parámetros sysctl. Para cada uno de ellos, Oracle proporciona un valor recomendado o una ecuación. Para algunos parámetros, la ecuación recomendada puede cambiar con el tiempo (aync io) o, en algunos casos, Oracle proporcionó más de una ecuación para el mismo parámetro.

  • Almacenamiento: las reglas de Linux udev no garantizan los nombres de dispositivos persistentes de arranque. Por lo tanto, Oracle proporcionó herramientas y controlador del núcleo (AsmLib). Esto le permite una "etiqueta" de particiones físicas como raíz y luego puede ver estas etiquetas al administrar el almacenamiento de la base de datos
  • Investigación del problema:
    • Cuando la base de datos se bloquea porque no puede abrir más identificadores de archivos, la única solución es aumentar el límite del kernel, ejecutar 'sysctl -p' y luego iniciar la base de datos.
    • Además, cuando descubra que la RAM física está demasiado fragmentada y la base de datos no puede asignar páginas grandes, la única opción es reiniciar el servidor.
    • (DCD): detección de conexión inactiva. Por ejemplo, en AIX netstat no imprime PID. La única forma de vincular una conexión TCP con PID es el depurador de kernel.
    • vistazo (algo así como superior en HP-UX) requiere privs raíz
    • varias investigaciones a nivel de Veritas
    • y muchos muchos otros

Depende de usted decidir cuánto tiempo "perderá" hasta que se resuelva el problema. Solo quería señalar que la fuerte separación de roles puede ser muy costosa en algunos casos. Entonces, en lugar de aumentar el enfoque de "seguridad" en la reducción de riesgos y peligros. Que no es lo mismo. Las herramientas como ttysnoop o shell spy le permiten "grabar" toda la sesión ssh, por lo que otorgan innegable credibilidad. Esto puede servir mejor que sudo.

ibre5041
fuente
44
El DBA no tiene la función de reiniciar los servidores de producción, modificar el parámetro del kernel del servidor de producción, manipular el almacenamiento del servidor de producción, etc. Su función es definir cómo se debe configurar un servidor de producción y dejar que la tarea de implementación a los administradores del sistema. La gestión de incidentes que afecta a un servidor de producción siempre debe ir al administrador del sistema, no al dba.
Stephane
66
@Stephane En un mundo ideal, sí, los roles de todos están claramente definidos. Pero en muchos casos, no lo es. Y en el caso del trabajo de DBA como se describe, podría ser que este DBA se esté contratando para ajustar el rendimiento a nivel del servidor. Seamos realistas: no todos los administradores de sistemas entienden las optimizaciones de configuración para todas las aplicaciones bajo su control. Pero aún así, lo que me molesta es el deseo del DBA de acceder sin detalles. Enorme bandera roja en mi libro.
JakeGould
2
@Stephane Oracle es muy específico en este caso. Sus requisitos para los sintonizables de kernel pueden ser no triviales, tiene su propio LVM (llamado ASM) y, además, en el caso de Oracle RAC, algunos de sus procesos CLusterwares se ejecutan con privs raíz y también manipula el almacenamiento y las NIC. A veces es más fácil dejar que DBA ejecute el vxdisk resizecomando y luego jugar ping-pong por correo electrónico en medio de la noche. Se trata más de confianza y auditoría que de "seguridad".
ibre5041
Oracle es una pila humeante. Los mejores documentos disponibles son: puschitz.com
dmourati
1
Si están ajustando cosas específicas para solucionar o mejorar problemas específicos, entonces deberían probarlos / verificarlos en un entorno de desarrollo (y, bueno, darles la raíz) y luego pasar instrucciones al equipo sysadmin / ops sobre lo que se debe hacer con precisión al entorno en vivo para implementar estos cambios una vez que se prueban. Y si no están haciendo eso, y en cambio solo están jugando con la configuración hasta que funcione, nadie debería estar haciendo eso en el entorno en vivo de todos modos .
Rob Moir
1

Soy un DBA de Oracle y mi respuesta es, normalmente, DBA no necesita acceso de root. Pero un RAC DBA? definitivamente necesita el acceso raíz para administrar CRS, mantenimiento y todo.

Mohamed Amjad
fuente
0

Esta pregunta se remonta a una época en que los sistemas eran mucho más simples y los procesos del sistema operativo frente a la base de datos se definían e identificaban por separado. Los deberes y responsabilidades de la administración del sistema y la administración de la base de datos eran muy distintos. Con los entornos de TI actuales y, en particular, con los servidores de bases de datos actuales, estos deberes y responsabilidades, en la mayoría de los casos, tienden a superponerse. El administrador del sistema realiza la debida diligencia para restringir el acceso "raíz" con respecto a la "gestión de riesgos".

Con las demandas actuales de "alta disponibilidad" y "solución inmediata" para los problemas que surgen con nuestros sistemas de base de datos RAC, los administradores del sistema y los administradores de la base de datos sirven a sus comunidades comerciales funcionales, trabajando juntos como un equipo. No debe haber ninguna preocupación con la "confianza", ya que ambas partes tienen un interés personal en mantener los servidores de bases de datos RAC en línea cerca del 100% del tiempo. Tenga en cuenta que el DBA ya tiene acceso de shell como administrador de la base de datos (con o sin algunos comandos que puede ejecutar a través de sudo; con o sin chrooteado), por lo que obviamente el DBA es un agente "confiable". Entonces, en realidad, la pregunta debería ser: "¿Por qué el DBA de Oracle no necesita acceso?"

El DBA de hoy ha asumido responsabilidades adicionales para el servidor de bases de datos, donde un servidor de bases de datos es miembro de Oracle Real Application Cluster (RAC) y utiliza Oracle Automatic Storage Management (ASMLIB) para presentar el almacenamiento compartido en las bases de datos de RAC. La gestión del RAC y la ASM por parte del DBA alivia al administrador del sistema ya sobrecargado de trabajo, lo que debería ser una contribución bienvenida al Grupo / Equipo STS.

Y, como dijo ibre5043, "... una fuerte separación de roles puede ser muy costosa en algunos casos. Entonces, en lugar de aumentar el enfoque de" seguridad "en la reducción de riesgos y peligros. Lo que no es lo mismo. Herramientas como ttysnoop o shell spy le permiten para "grabar" toda la sesión ssh, por lo tanto, conceden innegable. Esto puede servir mejor que sudo ". Además, debe preguntar quién está monitoreando los SSA.

Gary Cates
fuente
0

Si los servidores usan el software Oracle Grid Infrastructure, como CRS, RAC u Oracle Restart, muchos de los servicios críticos de la base de datos se ejecutan como root, y muchos de los archivos de configuración críticos de la base de datos son propiedad de root. Es una característica de diseño inherente del software. Si esto es una violación de sus políticas, entonces las políticas deben revisarse.

El DBA requerirá acceso de root para administrar estas características. Teóricamente, podría pedirle una lista de los comandos que esperará ejecutar para ingresarlos a Sudo, pero la respuesta será una lista muy larga. Solo eche un vistazo en $ GRID_HOME / bin para obtener una lista de todos los archivos binarios que el DBA podría usar regularmente. Si realizan actividades de parcheo (que deberían ser), la lista podría ser aún más larga.

Andrew Brennan
fuente
0

Acabo de enviar una pregunta similar. En realidad, creo que la razón por la que un administrador de sistemas no quiere otorgar el privilegio raíz es la responsabilidad y la responsabilidad.

Pero si esta es la causa, el DBA también debería ser el único administrador de sistemas. Y la razón es simple. Si es necesario separar la responsabilidad y la responsabilidad, el administrador del sistema SIEMPRE también puede ser el DBA. Puede suplantar la cuenta de Oracle, puede ingresar a la base de datos como SYSDBA y hacer lo que sea, sin la necesidad de la contraseña SYS o SYSTEM.

Entonces, en mi opinión, si existe la necesidad de separar los administradores de sistemas y los administradores de bases de datos, debido a la responsabilidad y la responsabilidad, la única causa lógica es que el servidor también debe ser administrado por el administrador de bases de datos y no por el administrador de sistemas. El servidor y la base de datos deben ser en su conjunto responsabilidad del DBA, que también debe tener algunos conocimientos de administración del sistema.

Si el servidor se usa para algo más que alojar la base de datos, y existe esta necesidad de responsabilidad y responsabilidad separadas, esto significa problemas. Pero si el servidor se usa solo para alojar la base de datos, entonces no veo ninguna razón por la cual el DBA no debería tener el privilegio de root, teniendo en cuenta los innumerables casos que también necesitaría.

Personalmente, pondría la pregunta al revés. ¿Por qué el administrador del sistema tiene el privilegio de root en un servidor de base de datos dedicado? De hecho, su especialidad sería requerida en muchos menos casos, que la del DBA (con el privilegio de root).

Savvas
fuente
0

Se requiere acceso a la raíz para la instalación y parcheo de Oracle grid. No hay manera de evitarlo. Si hubiera una manera de otorgar acceso raíz temporal a un DBA para tales necesidades, sería ideal.

David M Skibinski
fuente