studio - ¿La seguridad integrada de SQL Server/Windows es buena para cualquier cosa?
sql server management studio (14)
Al usar seguridad integrada, su aplicación no necesita saber nada ni manejar nada sobre seguridad, también, si el usuario ya inició sesión en su dominio, no es necesario que inicie sesión también en su aplicación (suponiendo que tiene suplantación). configurado correctamente).
La mayor ventaja debe ser utilizar un grupo de AD como inicio de sesión en SQL Server. De esta forma, puede dar acceso a todos los miembros del grupo "Cuentas" para acceder a un conjunto de sprocs, tablas, etc. y todos los integrantes de los grupos "Administradores" acceden a un conjunto diferente, todos con AD. Los administradores de su sistema no tienen que saltar a Management Studio para otorgar a los usuarios derechos de acceso a su aplicación.
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 pseudo-inicios de sesión para roles de bases de datos; pero eso no se asigna útilmente a los permisos de Windows. Asumiendo la verificación de identidad de inicio de sesión único, ¿por qué no simplemente ir con las funciones de base de datos más simples posibles?
EDITAR:
Hasta ahora hemos recogido el beneficio único de que no necesita almacenar una contraseña en su aplicación; pero eso parece más una consecuencia beneficiosa trivial que una meta de diseño; hay muchas otras maneras más directas de lograr eso, sin un acoplamiento cercano de todos los aparatos de seguridad de ambos universos.
EDITAR DE NUEVO
¿Alguien más tiene ningún beneficio que sugerir, aparte del inicio de sesión único y la capacidad de SD para mantener grupos, duplicando así la capacidad para grupos (basados en el mismo inicio de sesión de usuario) que ya existe en SQL Server?
El problema del grupo tiene varios defectos, incluida la suposición de que se supone que el gerente AD está igualmente calificado para mantener ambos; y excluye cualquier conexión de red que no sea parte de AD (lo que lo bloquea en la tecnología MS).
Y para ponerlo en términos de mejores prácticas, has construido el acoplamiento de sistemas, lo que generalmente se reconoce como algo malo.
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 de IIS.
Si tuviera que diseñar el sistema de permisos de SQL Server, con el requisito clave de que estaba integrado en AD, probablemente se le ocurriría algo muy similar. EN MI HUMILDE OPINIÓN.
Me gusta agrupar usuarios en grupos AD y luego crear inicios de sesión de grupo en SQL Server con los diversos 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 conecten.
Los usuarios invitados (como los usuarios web anónimos) deben estar en un grupo de AD propio, según las recomendaciones sobre la configuración de IIS. Darle a este grupo acceso único a lo que deberían tener acceso en la base de datos podría algún día guardar los datos del desastre. Es difícil leer el código fuente para saber si los datos están protegidos, es mucho más fácil estudiar 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.
La base de datos puede tener un acceso detallado con muchas configuraciones diferentes para cada usuario. No es solo un escenario donde tiene un usuario para el acceso a la aplicación y eso es toda la seguridad de los datos.
Si hablamos de desarrollo de equipo, probablemente habrá acceso de desarrollo de grupo de usuarios a la base de datos. Cada usuario de 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 saber para permitir el acceso a la base de datos.
La seguridad integrada proporciona una mayor flexibilidad en el acceso de los usuarios a la 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 correcto para todo.
[EDITAR] También es excelente para el acceso de registro. Si tuviera que crear un inicio de sesión de SQL para cada desarrollador nuevo 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 apuntar con el dedo al jefe que dejó caer un mesa.
La seguridad integrada solo es realmente útil para aplicaciones de intranet. Los pseudologins que he visto son principalmente para aplicaciones web de internet.
De todos modos, es más que simplemente no guardar una contraseña en tu aplicación, ya que de todos modos estarías procesando y configurando tu contraseña. También hay:
El usuario no tiene que iniciar sesión, lo cual es un gran problema, si se lanza a una aplicación web de forma esparcida durante todo el día, o si trabaja en algún lugar que tenga múltiples aplicaciones internas de webapps.
La administración de usuarios es gratuita, ya que el administrador de TI solo tiene que editar al usuario en Active Directory.
Los nombres de usuario y roles son consistentes en toda la organización.
La suplantación del 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)
La aplicación web no necesita hacer ninguna autorización de usuario adicional en la base de datos, ya que todo se maneja a la perfección.
[EDIT] También conoce al usuario en sus objetos de base de datos. Por lo tanto, puede tener una vista solo devolver las 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 un gran valor añadido.
Sin tener en cuenta el lado de la tabla de concesiones / etc, el lado de inicio de sesión es muy útil, ya que su aplicación se puede conectar al servidor SQL mediante la autenticación de Windows, lo que significa
No tiene que poner el nombre de usuario y la contraseña de su base de datos en un archivo de su aplicación en algún lado
Cada vez que ingresa una contraseña en un archivo de texto plano, es un riesgo de seguridad. Evitar eso es genial.
sí, por supuesto, si tiene la capa de acceso a datos a nivel de aplicación ejecutándose como un servicio, puede usar seguridad integrada para hablar con la base de datos usando una "Cuenta de servicio" de aplicación para iniciar sesión en el servidor ... Entonces no tiene para almacenar contraseñas de usuario en el archivo de configuración de aplicaciones, y no está pasando contraseñas a través de la red de cada nueva conexión hecha a la base de datos
¿Qué le parece 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.
Como todos los demás han discutido sobre 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 por otros medios (herramientas SQL, Excel, malware, etc.).
Con SQL Authentication, 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 SQL ... Pero ''Joe User'' no lo hace, lo que significa que las aplicaciones mencionadas anteriormente no podrían tener acceso implícito a la base de datos.
Inicios de sesión de SQL: contraseñas ocultas ofuscadas sobre el cable
Inicio de sesión integrado de Windows con NTLM: Hashes pasó por el cable
Inicio de sesión integrado de Windows con Kerberos: autenticación segura adecuada.
Solo hay una opción si te preocupas por la seguridad.
Muchos de estos se han dicho o son similares a las respuestas anteriores ... Con la integración AD:
a) No tengo que preocuparme por los usuarios que tienen acceso a una aplicación determinada, puedo pasar eso a los chicos de seguridad.
b) Puedo restringir el acceso en 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 los procesos almacenados.
c) Cuando un desarrollador se va de mi grupo, no tenemos que cambiar todas las contraseñas de DB (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 maneras de hacer esto, pero estoy a punto de ser flojo.
e) Se integra con la autenticación de IIS. Si ya está utilizando IE e 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 utilicé antes de mi posición actual. Aquí donde todo está alineado en AD ya ... Es el momento más fácil que he tenido con la seguridad de la base de datos.
Para una aplicación empresarial que se ejecutará en un entorno AD, el uso de 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, usted todavía usaría la seguridad basada en roles del servidor SQL.
Supongo que básicamente se trata de "no reinventar la rueda" y aprovechar el efecto de "muchos ojos".
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 lo desea. Es un sistema ya madurado 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 escanean constantemente el proceso de autenticación de Windows, lo buscan en busca de vulnerabilidades, exploran formas de eludirlo, etc. Cuando se revela abiertamente una vulnerabilidad y se crea una solución para ella, su aplicación obtiene una mejora de seguridad "gratuita" .
En mi trabajo actual, tenemos grupos de AD como inicios de sesión de SQL, por lo que asignamos permisos de SQL basados en membresía a grupos de AD. Entonces todos los miembros del grupo de ingeniería sys tienen algunos permisos, los DBA tienen otros usuarios normales, otros supervisores, etc. Agregar usuarios nuevos o cambiar sus permisos es algo simple de hacer, solo se hace una vez en AD e inmediatamente obtienen el permisos que deberían obtener en la base de datos.
Edición de publicación :
Expandir un poco la "reinvención de la rueda": a una cuenta de AD, puedo negar el derecho de iniciar sesión en una máquina específica o bloquearla en cada máquina, salvo una o dos. Puedo evitar que entren en más de 2 estaciones de trabajo al mismo tiempo. Puedo obligarlos a cambiar 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 gente que trata de imponerlos con trabajos SQL complicados o una especie de daemon casero, que en mi opinión es reinventar una rueda ya inventada.
Y luego no puede detener al usuario SA (o un usuario con privilegios) que inicia sesión desde cualquier máquina. Una vez me dijeron que era una forma inteligente de detener un ataque de fuerza bruta sobre un SQL S. que tenía abierto su puerto de acceso remoto a través de Internet: los administradores del sitio implementaron un trabajo que cambiaba la contraseña de SA cada media hora. Si se tratara de SQL + Windows, simplemente podrían haber dicho que querían que el administrador iniciara sesión solo desde cierto boxen, o usar directamente solo la autenticación de Windows, lo que obliga a cualquier persona a pasar primero por la VPN.
Según mi experiencia, el tiempo de respuesta de las consultas ejecutadas contra una base de datos desde la mayoría de las aplicaciones es significativamente más rápido cuando se conecta mediante autenticación SQL. Elimina el retraso que se produce al solicitar constantemente a AD la validación de la seguridad.
Autenticación de SQL basada en el rendimiento >> seguridad integrada de Windows.