¿Autenticación de SQL Server o seguridad integrada?

Question

Tenemos algunos usuarios de intranet corporativa que utilizan una aplicación WinForms para trabajar en un sistema con un servidor SQL detrás.Se configura la seguridad integrada, lo que permite a todos los usuarios actualizar y eliminar permisos, donde la seguridad de la aplicación limita cómo y dónde se realizan las actualizaciones de las tablas.

Sin embargo, algunos usuarios son usuarios avanzados con herramientas de consulta SQL a su disposición y acceden a la base de datos directamente para crear informes.Sin embargo, con la seguridad integrada, tienen derechos de actualización predeterminados en tablas que no deberían tener, ya que la aplicación aplica reglas a las actualizaciones.

¿Es este un ejemplo de dónde es más apropiado proporcionar a la aplicación un inicio de sesión autenticado con SQL central, mientras que los usuarios obtienen derechos de solo lectura para la seguridad integrada?

Answer 1

Como se mencionó Jon procedimientos almacenados le daría la protección sobre las modificaciones directas de mesa. Hay otras opciones también. Puede utilizar "función de aplicación" de SQL Server (a través de proc sp_setapprole). Esto le permite continuar a utilizar un ID diferente para todos, pero sólo en tiempo de conexión de la aplicación (a través del front-end) se elevan los derechos del usuario.

Una importante desventaja de usar una identificación compartida es perder la noción de quién está la presentación de SQL para el servidor, aunque si todos son interno puede llegar al nombre del equipo.

Otra cosa es preocupante sin embargo. Parece como si los usuarios pueden conectarse a la base de datos y ejecutar consultas a voluntad. Ejecutar un mayor riesgo de tiempo de inactividad en la aplicación debido al comportamiento de los usuarios en las sesiones de SQL directamente conectados. Si usted puede llevarlo a cabo es posible que desee para tratar de tener una base de datos de informes creado que se actualiza a intervalos que su negocio puede tolerar, es decir, todos los días. HTH

Answer 2

supongo que por la forma en que has redactada así su pregunta que su aplicación se ejecuta directamente las sentencias SQL. Si usted podría refactorizar para que ejecute los procedimientos almacenados, puede otorgar derechos Exec en los procedimientos y negar la actualización directa de las tablas. Esto podría no ser posible, sin embargo, dependiendo de lo que hace su aplicación.

Answer 3

autenticación de SQL es una opción. Los procedimientos almacenados son otra. Sin embargo, la construcción de los roles más granulares para asignar sólo los permisos apropiados para sólo los tipos de usuario apropiados es donde realmente se debe buscar.

Adicionalmente , yo realmente no dar a estos usuarios acceso directo a la base de datos en absoluto. razones de seguridad a un lado, no se necesita mucho para un usuario que no es competente en SQL para ejecutar accidentalmente una consulta que va a inundar el servidor de base de datos y crear una negación efectiva del servicio. Incluso los profesionales pueden hacer esto accidentalmente de vez en cuando.

En su lugar, darles acceso a una solución de servicios de presentación de informes o análisis de tipo servicios, o utilizar la replicación para darles acceso a un clon de los datos. De esta manera el sistema de producción está protegida.

Answer 4

Personalmente, haría todo el acceso a los datos de la aplicación a través de procedimientos almacenados.Configuraría la seguridad integrada para que solo permita a los usuarios ejecutar los SP y no manipular los datos directamente.

Se puede otorgar acceso avanzado a los administradores de bases de datos para manipular los datos directamente cuando sea necesario.

Los permisos basados ​​en grupos le brindarán mucha más flexibilidad para los derechos de acceso y menos carga administrativa al controlarlos con seguridad integrada.