¿Mi Oracle DBA necesita acceso raíz?

Solución 1:

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

• ¿A quién se llama a altas horas de la noche cuando el servidor de la base de datos no funciona?
  Si no puede asegurarse de que los administradores de sistemas estén disponibles las 24 horas del día, los 7 días de la semana, es posible que desee otorgar acceso raíz 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 chroot) eso es suficiente para meterse con el servidor (un tipo malo que robe su cuenta puede fork bomb , exceder el límite de envío de spam, eliminar la base de datos, ...).

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

Solución 2:

En general, y no específicamente para los administradores de bases de datos, cualquiera que exija root acceder 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 root acceso para manejar su tarea, pero nuevamente, si no pueden explicar por qué y ponerlo por escrito, no trataría con ellos. Los profesionales que se ocupan de los servidores entienden y respetan los límites. Los buenos que saben lo suficiente como para meterse en problemas creen que las reglas se aplican a todos menos a ellos.

En los casos en los que he tenido que pelear 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 root acceder a eso. Asegúrese de cambiar la contraseña a algo específico para ellos, por supuesto. Que exploten una caja de desarrollo aislada.

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

Solución 3:

Teóricamente, los administradores de bases de datos pueden funcionar sin privilegios de root, pero es PITA  para ambos lados. Es prácticamente imposible definir una lista de comandos para que sea accesible a través de sudo .

Otorgue privilegios de root a los administradores de bases de datos si:

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

Los administradores de bases de datos generalmente necesitan privilegios de root para:ajustes de parámetros del kernel (sysctl), manipulación de almacenamiento, investigación de problemas.

Las audiciones adecuadas garantizan mejores condiciones de ejecución que las reglas de seguridad estrictamente definidas. Si ha implementado una 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 requisitos comunes de Oracle en instalaciones independientes (no en clúster)

• Parámetros del núcleo

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

  Puede haber alrededor de 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 udev de Linux no garantizan nombres de dispositivos persistentes en el arranque. Por lo tanto, Oracle proporcionó el controlador y las herramientas del kernel (AsmLib). Esto le permite "etiquetar" las 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 falla porque no puede abrir más identificadores de archivos, la única solución es aumentar el límite del núcleo, ejecutar 'sysctl -p' y luego iniciar la base de datos.
  • Además, cuando descubre que la RAM física está demasiado fragmentada y la base de datos no puede asignar páginas grandes, entonces la única opción es reiniciar el servidor.
  • (DCD) - detección de conexión muerta. Por ejemplo, en AIX netstat no imprime PID. La única forma de emparejar una conexión TCP con PID es con el depurador del kernel.
  • glance (algo así como top en HP-UX) requiere privilegios de root
  • varias investigaciones de nivel de Veritas
  • y 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 la "seguridad", concéntrese en reducir el riesgo y los peligros. Que no es lo mismo. Herramientas como ttysnoop o shell spy le permiten "grabar" toda la sesión de ssh, por lo que garantizan la innegabilidad. Esto puede servir mejor que sudo.