¿Por qué es una mala práctica permitir que todos usen el inicio de sesión sa?

Incluso Microsoft desalienta el uso del modo de autenticación de SQL Server , pero nuestras aplicaciones lo requieren.

He leído que es una buena práctica no permitir que los usuarios usen el sainicio de sesión directamente, en su lugar usar la autenticación de Windows y permitir esos privilegios de administrador de cuentas (o grupos de cuentas).

• ¿No es esencialmente lo mismo? ¿Cuáles son las ventajas / desventajas?
• ¿Cómo aumenta la práctica recomendada la seguridad de mis instancias de SQL Server?
• ¿Esto solo se aplica a las instancias de producción, o también a nuestras instancias de desarrollo interno?

Tienes varias preguntas diferentes aquí, así que las eliminaré individualmente:

"He leído que es una buena práctica no permitir que los usuarios usen el inicio de sesión sa directamente, en lugar de eso, usan la autenticación de Windows"

Aquí está mezclando dos cosas: el concepto de SA y el concepto de autenticación de SQL y autenticación de Windows.

La autenticación de SQL es una lista de nombres de usuario y contraseñas que se almacenan en todos y cada uno de los SQL Server. El hecho de que esté almacenado en SQL es el primer problema. Si necesita cambiar la contraseña de un inicio de sesión, debe cambiarla en cada servidor (o mantener diferentes contraseñas en diferentes servidores). Con la autenticación de Windows, puede deshabilitar centralmente los inicios de sesión, cambiar las contraseñas, establecer políticas, etc.

Si elige utilizar la autenticación de SQL, SA es solo un inicio de sesión de autenticación de SQL. Es el nombre de usuario predeterminado del administrador, al igual que el Administrador está en la autenticación de Windows. Tiene superpoderes locales en esa instancia, pero no superpoderes globales en todas las instancias.

"... y permitir esos privilegios de administrador de sistemas de cuentas (o grupos de cuentas)".

Independientemente del método de autenticación que elija, lo ideal es seguir el principio del privilegio mínimo: otorgar a las personas los derechos mínimos que necesitan para realizar su trabajo, y nada más.

No pienses en ellos como solo inicios de sesión: son personas que pueden despedirte. Si abandonan la base de datos o deshabilitan sus trabajos de copia de seguridad accidentalmente, no serán despedidos, porque de forma predeterminada, SQL no rastrea quién hizo qué. Tú eres el que será despedido porque va a suceder, y no podrás decir qué persona lo hizo.

"¿Cómo la mejor práctica aumenta la seguridad de mis instancias de SQL Server?"

Quieres hacer dos cosas:

1. Evitar que la gente rompa el servidor
2. Cuando rompan el servidor, podrá identificar exactamente quién lo hizo

El primero se logra con el principio de privilegio mínimo: otorgar a las personas solo los permisos que necesitan y nada más.

El segundo se logra dando a cada persona su propio inicio de sesión, no permitiendo inicios de sesión compartidos (como permitir que todos usen el mismo nombre de usuario / contraseña) e, idealmente, auditando los inicios de sesión. Probablemente no haga esa última parte de inmediato, porque es un poco doloroso, pero primero pongamos las piezas en su lugar para que pueda agregar la auditoría más tarde después de que alguien suelte una base de datos y su jefe quiera saber por qué.

Sé lo que estás pensando: "Pero estamos codificando aplicaciones, y la aplicación necesita un inicio de sesión". Sí, otorgue a la aplicación su propio inicio de sesión, y los desarrolladores necesitan saber esa contraseña, pero ese inicio de sesión debe estar tan desprovisto de permisos que nadie en su sano juicio desearía usarlo. Por ejemplo, podría necesitar estar solo en los roles db_datareader y db_datawriter, nada más. De esa manera puede insertar, actualizar, eliminar y seleccionar datos, pero no necesariamente cambiar esquemas, agregar índices, cambiar procedimientos almacenados, etc.

"¿Esto solo se aplica a instancias de producción, o también a nuestras instancias de desarrollo interno?"

Creo que se aplica tanto a las instancias de desarrollo porque generalmente me preocupa que la gente rompa cosas. A la gente le encanta romper servidores en desarrollo. Y, por supuesto, cuando llega el momento de agrupar la lista de cambios para migrar a producción, necesito saber si un índice en particular es realmente vital para la aplicación o si algún huesohueso simplemente ejecutó el Asesor de ajuste de base de datos y le dijo que aplicara todos los cambios . Los permisos adecuados ayudan a disminuir ese dolor.

En realidad, si lees este documento técnico: Documento técnico sobre la separación de tareas de SQL Server

Le indicará que NADIE debe usar privilegios de administrador de sistemas en su cuenta. Su cuenta de acceso diario debe tener acceso mínimo, no derechos explícitos de administrador del sistema. Dado que CONTROL SERVER está realmente cerca de lo que es sysadmin y luego le permite NEGAR / REVOCAR el acceso donde no lo necesitan. Permitir derechos de administrador de sistemas a cualquier persona se convierte en un problema si se le exige cumplir con los estándares de cumplimiento de TI. La mayoría de los estándares requieren un uso mínimo de la función sysadmin.

Inhabilito y cambio el nombre de la cuenta "sa", tal como lo haría con la cuenta de administrador integrada en el sistema operativo. Solo para ser usado en emergencias.

Los desarrolladores generalmente tienen acceso completo a su entorno de desarrollo. Luego, cuando su programa se traslada a la instancia de preproducción, su acceso debe ser mínimo o ninguno; tal como sería en producción. Ese es un mundo perfecto. Sin embargo, si no estás en eso y tus desarrolladores tienen más privilegios de los que crees que necesitan, auditaría muchísimo sus cuentas. Capturaría todo y cualquier cosa que hagan hasta cierto punto. Entonces, en caso de que algo salga mal cuando estaban en su servidor de producción, puede regresar y averiguar exactamente lo que hicieron.

Si está sujeto a controles o estándares regulatorios externos (SOX, PCI, etc.), entonces usted

• fallará una auditoría
• están fallando en sus cheques mensuales de PCI

Los desarrolladores deben tener db_owner en una red SQL Server solo para desarrollo.

Si sus servidores SQL están en la red con una compilación estándar (es decir, la misma cuenta de servicio), sa in one les confiere derechos a todos.

Si la cuenta de servicio es administrador local, entonces sus desarrolladores también tienen control total sobre los servidores.

No hay ventajas.

sa = administrador de sistemas

Iniciar sesión con sa le da al usuario el poder de hacer todo lo siguiente: - soltar y crear bases de datos - modificar objetos en la base de datos - soltar y crear inicios de sesión - cambiar contraseñas - eliminar todos los datos

Otorgar una cuenta de Windows privilegios de administrador del sistema logra lo mismo.

La lista continúa, pero esto debería darle algunas buenas razones para NUNCA NUNCA permitir que un no administrador use sa.

Debe crear una cuenta de Windows o SQL con los privilegios mínimos necesarios para que las aplicaciones funcionen. (es decir, iniciar sesión, acceder a procedimientos almacenados y vistas)

La mejor práctica es poner una contraseña segura y olvidarla.

Tengo dos opciones en mente en este momento, en cuanto a por qué uno no debería tener una cuenta SA débil. Si tiene una contraseña débil / vacía para SA, una persona malvada (traduzca eso a 'colega amigable') podría:

• habilite el procedimiento del sistema xp_cmdshell y, utilizando los privilegios de la cuenta de servicio del servidor SQL, haga daño a su casilla local (crear / eliminar archivos ...). Tener poca seguridad para SA en realidad no dice mucho acerca de la configuración de la instancia, pero podría implicar que el usuario del servicio podría seguir malas prácticas (como ser un administrador :-));

• habilite el correo en su instancia y avance rápidamente un pequeño script divertido de correo no deseado (que probablemente le causará algunos problemas, ya sea con su proveedor de Internet o con sus colegas ... dependiendo de dónde vayan los correos ;-));

No señalaré los hechos obvios de que puede eliminar bases de datos, inicios de sesión ... etc.

• ¿No es esencialmente lo mismo? ¿Cuáles son las ventajas / desventajas?

• No necesariamente: por ejemplo, en la instancia de SQL Server desde su computadora portátil, la diferencia entre la autenticación de Windows y la autenticación de SQL significa que, en teoría, un atacante externo podría usar solo una cuenta de SQL, porque la autenticación de Windows no se puede usar fuera de su propio dominio cuenta. Un usuario puede escanear las computadoras portátiles vecinas desde el centro comercial donde está tomando su café y puede ver que tiene una instancia de SQL instalada e iniciada y podría intentar divertirse de forma gratuita. No es que pueda suceder a menudo ... pero es una posibilidad :-).

• ¿Cómo aumenta la práctica recomendada la seguridad de mis instancias de SQL Server?

• Como todas las mejores prácticas en este mundo hacen su trabajo ... disminuye las posibilidades de una posible desventaja (por ejemplo: la mejor práctica de hacer actividad física disminuirá las posibilidades de que seas como yo ... un teleadicto) que podría ocurrir de otra manera.

• ¿Esto solo se aplica a las instancias de producción, o también a nuestras instancias de desarrollo interno?

• Digamos que sugeriría implementar las mejores prácticas de seguridad (probadas y modificadas según las necesidades de su entorno) al menos en producción. Pero si en el desarrollo también usa datos de producción (sensibles ... etc.), es una fuerte indicación de que también tiene que alterar sus prácticas de desarrollo.

Al abordar su pregunta final, utilizamos cuentas SA en todas nuestras bases de datos de desarrollo (¡con la contraseña "sa", por cierto!)

Sin embargo, es fundamental tener en cuenta que no almacenamos los datos y no los generamos. Nuestras bases de datos se utilizan únicamente para un almacén de datos para una aplicación C / C ++. Estas bases de datos de desarrollo contienen únicamente datos de prueba y con frecuencia se crean, descartan, modifican, etc.

Además, igual de crítico, todas las bases de datos de desarrollo están instaladas en máquinas de desarrollo. (¡Una copia por desarrollador, al menos!) Entonces, si alguien arruina una instalación completa, solo se ha estropeado a sí mismo y a nadie más.

Cuando se trata de un entorno en el que desea asegurarse de que su base de datos, tablas y datos sean realmente consistentes y seguros, entonces desea una contraseña SA segura y sólida. Si deja esto débil, cualquiera y todos tienen acceso completo a sus datos y pueden destruir completamente su base de datos.

Para un grupo de desarrolladores con sus propias copias de la base de datos que contienen únicamente datos de prueba, todavía tengo que encontrar un argumento sólido para mantener una cuenta SA sólida.

Cualquier parámetro de seguridad del sistema SQL Server predeterminado proporcionado debe modificarse. Se recomienda no usar el modo mixto (habilita la autenticación de Windows y SQL Server) para la autenticación. En su lugar, cambie a la autenticación de Windows solamente, que hará cumplir la política de contraseña de Windows, comprobando la longitud de la contraseña, la duración de la vida y el historial. La característica de la política de contraseñas de Windows que la diferencia de la autenticación de SQL Server es el bloqueo de inicio de sesión: después de varios intentos de inicio de sesión fallidos sucesivos, el inicio de sesión se bloquea y no se puede usar para un uso posterior

Por otro lado, la autenticación de SQL Server no proporciona ningún método para detectar intentos de ataque de fuerza bruta, y lo que es peor, SQL Server incluso está optimizado para manejar un gran número de intentos de inicio de sesión rápido. Entonces, si la autenticación de SQL Server es imprescindible en un sistema SQL Server en particular, se recomienda deshabilitar el inicio de sesión SA