Autenticación de Windows y cuenta de servicio de red como db_owner

Question

Hay una serie de productos comerciales que ofrecen instaladores basados ​​en Windows para configurar su aplicación y la base de datos SQL Server DB. Por lo general, le preguntará si desea conectarse al DB con la autenticación de Windows o SQL Server. La mayoría de ellos hacen una recomendación para usar Windows Auth y luego configuran su base de datos con la cuenta de servicio de red asignada al rol de base de datos db_owner. Entiendo que la Autenticación de Windows es más segura porque no tiene que almacenar credenciales en web.config y enviarlas por cable cuando se autentica en SQL Server, pero es una configuración segura para entornos de producción, donde la cuenta del Servicio de red es un db_owner? ¿Algún riesgo específico que debemos conocer?

---

Gracias StingyJack,

escucho lo que está diciendo, tendrían que entrar a la base de datos como un primer usuario de servicio de red sin embargo. ¿Hay una manera fácil de hacer eso?

Lo que realmente estoy tratando de averiguar es si hay riesgos inherentes asociados con el hecho de que es la cuenta de servicio de red predeterminada a la que se le asigna la función db_owner.

Answer 1

Sí, la aplicación (y los usuarios del mismo) potencialmente puede ejecutar cualquier cosa que DBO puede ejecutar en la base de datos. DROP TABLE, SELECT * FROM PASSWORDS, etc.

Si configura medidas preventivas contra SQL Injection y ha escrito su aplicación con la capa de seguridad de aplicación adecuada, entonces esto usando Windows Auth con dbo probablemente va a estar bien.

Si está trabajando con datos muy sensibles, no confían en la aplicación (aún), o quiere ser lo más seguro posible, entonces usted tendrá que implementar la seguridad en la capa de base de datos.

Por ejemplo, el usuario X tiene acceso a las tablas ve a y b y c vista, y el usuario y sólo tiene acceso para ver c. Su aplicación deberá conectarse como el usuario apropiado para acceder al objeto correcto.

Answer 2

Iniciar sesión en la base de datos como servicio de red (dominio \ equipo $) será muy difícil (no tengo ni idea, pero es probable que haya algo de l33t haxor) a menos que sea un servicio en la caja web.

No hay ninguna contraseña, no es interactivo y tiene derechos muy limitados (a menos "sistema local").

El problema principal son los ataques de inyección SQL. Se aplican a cualquier conexión al servidor db.

El riesgo adicional de tener db_owner es la tabla DROP, incluso colocar los ataques de tipo de base. Sin db_owner, sigue siendo peligroso, por ejemplo, los ataques "SELECT * FROM usertable WHERE 1 = 1".

Por desgracia, no tiene otra opción con la Parte aplicaciones comerciales o tercera utilizar procedimientos almacenados, etc. menos permiso de

Usted puede ser capaz de reducir los derechos después de la instalación sin embargo.

Answer 3

Utilizando el servicio de red como db_owner es probablemente correcto para una gran cantidad de entornos.

Si desea tener un mayor nivel de seguridad, simplemente cree una cuenta de Windows separada, otórguele el acceso mínimo que necesita en SQL Server y luego cambie la aplicación para que se ejecute en el contexto de esta nueva cuenta.

Los riesgos específicos serían:

• Una aplicación se ejecute mal escrito en el contexto del servicio de red puede permitir el acceso no autorizado a todos los demás datos que el servicio de red tiene acceso. Mitiga este riesgo creando cuentas separadas para todas las aplicaciones.
• db_owner es probable que tenga más acceso de lo que la aplicación realmente necesita, lo que significa más potencial de abuso/explotación si se ve comprometido. Puede reducir esto un poco eligiendo privilegios de sentido común para otorgar. Lleve demasiado lejos y tendrá rendimientos decrecientes y dolores de cabeza más apoyo, sin embargo.