¿La seguridad integrada de SQL Server / Windows es buena para algo?

Question

Las distinciones entre los permisos de usuario de Windows y cualquier conjunto de GRANT de SQL Server parecen conceptos no relacionados. En la mayoría de los casos, parece implementarse con pseudoinicios de sesión para roles de base de datos; pero eso no se asigna útilmente a los permisos de Windows. Suponiendo la verificación de identidad de inicio de sesión único, ¿por qué no simplemente elegir los roles de base de datos más simples posibles?

EDITAR:
Hasta ahora hemos recogido el beneficio único que no necesita almacenar una contraseña en su aplicación; pero eso parece más una consecuencia beneficiosa trivial que un objetivo de diseño; Hay muchas otras formas más directas de lograrlo, sin acoplar estrechamente todo el aparato de seguridad de ambos universos.

EDITAR DE NUEVO:
¿Alguien más tiene algún beneficio que sugerir, aparte del inicio de sesión único y la capacidad de SD para mantener grupos, duplicando así la capacidad de los grupos (basados ??en el mismo inicio de sesión de usuario) ya existentes en SQL Server?

El problema del grupo tiene varios defectos, incluida la suposición de que se supone que el administrador de AD está igualmente calificado para mantener ambos; y excluye cualquier conexión de red que no forme parte de AD (lo que lo bloquea a la tecnología MS).

Y para decirlo en términos de mejores prácticas, ha incorporado el acoplamiento de sistemas, que generalmente se considera una mala cosa.

Answer 1

Muchos de estos se han dicho o son similares a las respuestas anteriores ... Con la integración de AD:

a) No tengo que preocuparme por los usuarios que tienen acceso a una aplicación determinada, puedo pasar eso a los encargados de seguridad.

b) Puedo restringir el acceso a una tabla por nivel de tabla en función de los grupos que ya existen, así como forzar a los usuarios estándar a que solo tengan la capacidad de llamar a procesos almacenados.

c) Cuando un desarrollador deja mi grupo, no tenemos que cambiar todas las contraseñas de la base de datos (es decir, si le importa la seguridad de los datos ...)

d) Es fácil hacer un registro personalizado basado en el usuario que realiza el cambio. Hay otras formas de hacer esto, pero lo importante es ser flojo.

e) Se integra con la autenticación IIS. Si ya estás usando IE & amp; IIS para su intranet, esto simplemente hace la vida mucho más fácil.

Nota: Hay muchas más razones para no usarlo, y nunca lo usé antes de mi posición actual. Aquí donde todo está alineado en AD ... Es el momento más fácil que he tenido con la seguridad de la base de datos.

Answer 2

Al usar la seguridad integrada, su aplicación no necesita saber nada ni manejar nada sobre seguridad, también, si el usuario ya ha iniciado sesión en su dominio, no necesita iniciar sesión en su aplicación también (suponiendo que usted ' tengo la suplantación configurada correctamente).

La mayor ventaja tiene que ser usar un grupo AD como inicio de sesión en SQL Server. De esta manera, puede dar acceso a todos en las "Cuentas". acceso grupal a un conjunto de sprocs, tablas, etc. y a todos los miembros de " Managers " Agrupa el acceso a un conjunto diferente, todos con AD. Los administradores de su sistema no tienen que acceder a Management Studio para otorgar a los usuarios derechos de acceso a su aplicación.

Answer 3

Supongo que básicamente se reduce a "no reinventar la rueda" y aprovechando los "muchos ojos" efecto.

Al usar la autenticación de Windows, aprovecha el poder de la seguridad integrada de Windows, además de lo cual puede agregar sus propias cosas si así lo desea. Es un sistema ya maduro que ha sido probado millones de veces, ahorrándole el esfuerzo (y a sus clientes, el costo) de cometer sus propios errores y descubrirlos / resolverlos más tarde.

Y muchas personas están constantemente escaneando el proceso de autenticación de Windows, verificándolo en busca de vulnerabilidades, explorando formas de evitarlo, etc. Cuando una vulnerabilidad se revela abiertamente y se crea una solución, su aplicación acaba de recibir un " gratis " mejora de seguridad.

En mi trabajo actual tenemos grupos de AD como inicios de sesión de SQL, por lo que asignamos permisos de SQL basados ??en la membresía a grupos de AD. Por lo tanto, todos los miembros del grupo de ingeniería sys tienen algunos permisos, los DBA tienen otros usuarios normales, otros supervisores, etc. Agregar nuevos usuarios o cambiar sus permisos es algo simple, solo se hace una vez en AD e inmediatamente obtienen el permisos que deberían obtener en la base de datos.

Edición de publicaciones :

Expandiendo un poco el " reinventando la rueda " ;: A una cuenta de AD puedo negar el derecho de iniciar sesión en una máquina específica, o bloquearla de cada máquina, salvo una o dos. Puedo evitar que inicien sesión en más de 2 estaciones de trabajo al mismo tiempo. Puedo obligarlos a cambiar las contraseñas después de un tiempo, además de imponerles una fuerza mínima. Y algunos otros trucos, todos los cuales mejoran la seguridad en mi sistema.

Con los usuarios de SQL S., no tienes nada de esto. He visto personas que intentan imponerlos con trabajos complicados de SQL o una especie de demonio casero, que en mi opinión está reinventando una rueda ya inventada.

Y luego no puede evitar que el usuario SA (o un usuario privilegiado) inicie sesión desde cualquier máquina. Una vez me dijeron una forma inteligente de detener un ataque de fuerza bruta sobre un SQL S. que tenía su puerto para el inicio de sesión remoto abierto a través de Internet: los administradores del sitio implementaron un trabajo que cambiaba la contraseña de SA cada media hora. Si hubiera sido SQL + Windows, podrían haber dicho simplemente que querían que el administrador iniciara sesión solo desde ciertos boxen, o simplemente usar la autenticación de Windows, lo que obligó a cualquiera a pasar primero por la VPN.

Answer 4

Como todos los demás han discutido los beneficios de la autenticación de Windows, creo que jugaré a Devil's Advocate ...

Permitir que la cuenta 'Joe User' tenga acceso al servidor significa que no solo se puede conectar con su aplicación, sino que también se puede conectar a través de cualquier otro medio (SQL Tools, Excel, malware, etc.).

Con la autenticación de SQL, su aplicación puede ejecutarse como un determinado usuario y luego la aplicación puede manejar el acceso a la base de datos. Entonces, cuando 'Joe User' ejecuta su aplicación, la aplicación tiene acceso a SQL ... Pero el 'Joe User' mismo no, lo que significa que las aplicaciones mencionadas anteriormente no podrían tener acceso implícito a la base de datos.

Answer 5

sí, por supuesto, si tiene su capa de acceso a datos a nivel de aplicación ejecutándose como un servicio, puede usar la seguridad integrada para comunicarse con la base de datos mediante una Aplicación " Cuenta de servicio " para iniciar sesión en el servidor ... Entonces no tiene que almacenar las contraseñas de los usuarios en el archivo de configuración de las aplicaciones, y no está pasando contraseñas a través de la red para cada nueva conexión realizada a la base de datos

Answer 6

La seguridad integrada solo es realmente útil para aplicaciones de intranet. Los pseudoinicios de sesión que he visto son principalmente para aplicaciones web de Internet.

De todos modos, es más que simplemente no almacenar una contraseña en su aplicación, ya que es de esperar que de todos modos salude y mezcle su contraseña. También hay:

1. El usuario no tiene que iniciar sesión, lo cual es un gran problema, si está saltando a una aplicación web de forma esporádica durante el día, o si trabaja en algún lugar que tenga varias aplicaciones web internas.

2. La administración de usuarios es gratuita, ya que el administrador de TI solo tiene que editar al usuario en Active Directory.

3. Los nombres de usuario y los nombres de roles son coherentes en toda la organización.

4. La suplantación de usuario es un método más seguro al acceder a un servicio web interno. (por ejemplo, un sitio web de Internet accede a un servicio web de intranet)

5. La aplicación web no necesita hacer ninguna autorización adicional del usuario en la base de datos, ya que todo se maneja sin problemas.

6. [EDITAR] También conoce al usuario en los objetos de su base de datos. Por lo tanto, puede tener una vista que solo devuelva filas asociadas a ellos. (a menos que cree un nuevo usuario de SQLServer para cada usuario de la aplicación, esto sería imposible, y crear un nuevo usuario de SQLServer para cada usuario de la aplicación tampoco es razonable)

La seguridad integrada no es adecuada para todo, pero para la empresa, hay mucho valor agregado.

Answer 7

Inicios de sesión SQL: contraseñas de texto en claro ofuscadas sobre el cable

Inicio de sesión integrado de Windows con NTLM: hashes pasados ??por el cable

Inicio de sesión integrado de Windows con Kerberos: autenticación segura adecuada.

Solo hay una opción si le importa la seguridad.

Answer 8

Según mi experiencia, el tiempo de respuesta de las consultas ejecutadas en una base de datos desde la mayoría de las aplicaciones es significativamente más rápido cuando se conecta a través de la autenticación SQL. Elimina el retraso que se produce al pedir constantemente a AD la validación de seguridad.

Autenticaciones de SQL en cuanto al rendimiento > > seguridad integrada de windows.

Answer 9

Sin tener en cuenta el lado de la tabla de concesión / etc. de las cosas, el lado de inicio de sesión de las cosas es muy útil, porque su aplicación puede conectarse al servidor SQL mediante la autenticación de Windows, lo que significa

No tiene que poner su nombre de usuario y contraseña de la base de datos en un archivo en su aplicación en algún lugar

Cada vez que ingresa una contraseña en un archivo de texto sin formato, es un riesgo de seguridad. Evitar eso es genial.

Answer 10

La base de datos puede tener un acceso de grano fino con muchas configuraciones diferentes para cada usuario. No es solo un escenario en el que tiene un usuario para acceder a la aplicación y eso es todo seguridad de datos.

Si estamos hablando del desarrollo del equipo, entonces probablemente habrá un grupo de usuarios con acceso de desarrollo a la base de datos. Cada usuario en este grupo será miembro de su dominio interno y tendrá contraseñas propias que el administrador de la base de datos no debe administrar e incluso sabe que permiten el acceso a la base de datos.

Answer 11

Creo que la seguridad integrada es buena si se usa correctamente. Por alguna razón que no puedo entender, muchas empresas en las que he trabajado no utilizan mucho el AD, los permisos SQL y el modelo de seguridad IIS.

Si tuviera que diseñar el sistema de permisos de SQL Server, con el requisito clave de que estaba integrado en AD, probablemente encontraría algo muy similar. En mi humilde opinión.

Me gusta agrupar a los usuarios en grupos de AD y luego crear inicios de sesión de grupo en SQL Server con los distintos permisos. Las personas no deberían tener más acceso a los datos solo porque tienen herramientas para conectarse a la base de datos. Deben tener los mismos permisos en los datos, sin importar cómo se conectan.

Los usuarios invitados (como en usuarios web anónimos) deben estar en un grupo AD de ellos mismos, según las recomendaciones sobre la configuración de IIS. Darle a este grupo solo acceso a lo que deberían tener acceso en la base de datos podría algún día salvar los datos del desastre. Es difícil leer el código fuente para averiguar si los datos están protegidos, es mucho más fácil examinar los permisos de la base de datos y la configuración de seguridad.

Además, la seguridad no integrada es mala porque las contraseñas siempre se distribuyen, se colocan en archivos de configuración, etc.

Answer 12

La seguridad integrada brinda mayor flexibilidad en el acceso de los usuarios a IMO. Por ejemplo, si mi organización quiere limitar las horas durante las cuales el grupo de desarrolladores puede acceder al servidor, la seguridad integrada es mi mejor opción.

Pero no es adecuado para todo.

[EDITAR] También es ideal para registrar el acceso. Si tuviera que crear un inicio de sesión SQL para cada nuevo desarrollador en una organización grande ... probablemente dejaría de suceder y los inicios de sesión se compartirían, entonces nunca tendría confianza en la capacidad de señalar con el dedo al tonto que dejó caer un mesa.

Answer 13

¿Qué tal el hecho de que si utiliza la autenticación del servidor SQL, la información de la contraseña se envía a través de la red como texto sin cifrar? La seguridad integrada no tiene ese problema.

Answer 14

Para una aplicación empresarial que se ejecutará en un entorno AD, usar la seguridad integrada de Windows es definitivamente el enfoque correcto. No desea que los usuarios que ya están autenticados en el entorno tengan que administrar un conjunto separado de credenciales solo para su aplicación. Tenga en cuenta que estamos hablando de autenticación ... para la autorización , aún usaría la seguridad basada en roles del servidor SQL.