¿Por qué la autenticación del sistema operativo se considera una seguridad deficiente para las bases de datos Oracle?

Oracle está desaprobando la autenticación del sistema operativo de acuerdo con la Guía de seguridad de la base de datos de Oracle , que dice

Tenga en cuenta que el parámetro REMOTE_OS_AUTHENT fue desaprobado en Oracle Database 11g Release 1 (11.1), y se conserva solo por compatibilidad con versiones anteriores.

Además, la mayoría de las herramientas y la información de seguridad consideran que la autenticación del sistema operativo (externo) es un problema de seguridad. Estoy tratando de entender por qué este es el caso. Aquí hay algunas ventajas que veo de la autenticación del sistema operativo:

1. Sin OS, las aplicaciones de autenticación deben almacenar contraseñas en una variedad de aplicaciones, cada una con su propio modelo de seguridad y vulnerabilidades.
2. La autenticación de dominio ya tiene que ser segura porque si no lo es, la seguridad de la base de datos solo ralentiza el acceso a la base de datos, pero no puede evitarla.
3. Los usuarios que solo tienen que recordar una contraseña de dominio pueden crear contraseñas de dominio más seguras más fácilmente de lo que pueden crear contraseñas de bases de datos aún menos seguras a medida que aumenta el número de bases de datos diferentes a las que deben conectarse.

Considere el siguiente escenario:

1. Hay un usuario de Unix nombrado gaiusen el servidor de Oracle con autenticación externa, por lo que en Oracle hay un usuario correspondiente llamado ops$gaius. Cuando inicie sesión en un shell, también puedo iniciar sesión directamente en mi esquema de Oracle, y mis trabajos cron tampoco necesitan una contraseña incrustada en el script.
2. Se permite la autenticación remota del sistema operativo, en el supuesto de que la LAN es 100% seguro y los clientes se puede confiar (igual que el rlogin/ rshsolía ser normalmente permitido)
3. Un atacante conecta su computadora portátil a la LAN por cualquier medio, sabe que trabajo allí y crea un usuario local en su computadora portátil llamado gaiusy ejecuta SQL * Plus como ese usuario
4. Oracle ve (es decir, OSUSERen V$SESSION) es gaiusy registra a ese usuario remoto comoops$gaius

Eso no es solamente ridículamente fácil de parodia, pero poner mi sombrero de cínico, Oracle no puede hacer más dinero vendiendo que su fantasía de sesión único producto ... que por cierto no cumplir con todos los puntos que usted plantea como ventajas del sistema operativo -Nivel aut. Dos contraseñas mejores que una son completamente falsas; la mayoría de las personas los configurarán para que sean iguales de todos modos (no hay ningún mecanismo en Oracle para evitar esto).

El principio general es que es extremadamente difícil defender en software cuando un atacante tiene acceso físico. Y nunca confíes en el cliente.

Aumenta los puntos únicos de falla y aumenta la superficie de riesgo de sus datos.

Un atacante que obtenga acceso al sistema, con la autenticación del sistema operativo, tendrá acceso a la base de datos. Al requerir un acceso más seguro a la base de datos, el atacante potencial debe escalar sus privilegios en el sistema comprometido para obtener acceso root u oráculo, en lugar de cualquier usuario.

Este problema es una función del acceso externo a la base de datos. Si no hay acceso externo y la máquina está completamente asegurada, entonces la cuestión de los permisos es discutible. Sin embargo, si los desarrolladores tienen acceso, los permisos de usuario a nivel del sistema operativo aumentan el alcance de posibles desastres de seguridad.

Considere el uso de acceso multinivel para limitar el alcance de las infracciones de seguridad y brindar a cualquier usuario, aplicación o cliente el acceso que necesitan sin la necesidad de crear cuentas de nivel de sistema operativo para cada instancia.

Gaius ya ha señalado por qué la autenticación remota del sistema operativo (a diferencia de la autenticación del sistema operativo estándar en la que permite que los usuarios locales de la máquina accedan a la base de datos sin especificar una contraseña por separado) es relativamente insegura.

Esperaría que Oracle se esté moviendo en esta dirección porque quiere alentar a las personas a usar usuarios empresariales (o el conjunto de gestión de identidad completo) en lugar de usuarios autenticados del sistema operativo remoto. Los usuarios empresariales tienen las mismas ventajas que los usuarios autenticados del sistema operativo remoto, pero Oracle en realidad está saliendo y accediendo a su servidor de Active Directory para autenticar al usuario. Obtiene los mismos beneficios de inicio de sesión único sin dejar el control de seguridad en la máquina del cliente.

Señala específicamente la autenticación de estilo de identificación, pero también me gustaría señalar que otros métodos para vincular la base de datos o cualquier otro inicio de sesión a los inicios de sesión del sistema operativo son igual de malos. (ya sean archivos de contraseña locales, LDAP o lo que sea para el almacenamiento real de las credenciales)

Si permite conexiones remotas a la base de datos (o al servidor web, o lo que sea que esté haciendo la autenticación), algunos sistemas operativos ignorarán las reglas que podrían establecerse para dificultar las cuentas de fuerza bruta (por ejemplo, bloquear las direcciones IP de donde provienen los intentos fallidos; bloquear usuarios por un período después de un número determinado de fallas, etc.). Normalmente, estas reglas están vinculadas sshdy no con el sistema de autenticación en su conjunto.

Entonces, si alguien puede conectarse a la base de datos / servidor web / lo que sea de forma remota, puede forzar la contraseña, ya que las bases de datos no tienden a tener los mismos mecanismos para retrasar los intentos, y luego ingresar una vez que encuentran las credenciales necesarias.