¿Mi DBA de Oracle necesita acceso de root?

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.

• ¿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.

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.

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.

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.

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.

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.

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).

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.