Práctica recomendada para usuarios/roles en SQL Server para una aplicación web

Question

Busqué en línea un poco y no pude encontrar nada que realmente identificara el lugar o las bases sobre cómo configurar usuarios/roles en una base de datos.

Básicamente, habría un usuario que se utilizaría para acceder a la base de datos desde la aplicación (aplicación web en este caso) que necesitaría acceso a la base de datos para las operaciones regulares de la base de datos (seleccionar, insertar, actualizar, eliminar) y ejecutar procedimientos almacenados (con el ejecutor para ejecutar procedimientos almacenados dentro de otros procedimientos almacenados/UDF).

Entonces, también tendríamos un usuario que sería el administrador principal (esto es bastante simple).

Actualmente tengo un entorno de desarrollo en el que realmente no administramos la seguridad demasiado bien en mi opinión (la aplicación usa un usuario con el rol db_owner, aunque es una aplicación de intranet). Aunque es una aplicación de intranet, aún tenemos la seguridad en mente y nos gustaría ver cuáles son algunas de las maneras en que los desarrolladores configuran los usuarios/roles para este tipo de entorno.

EDITAR: La aplicación web y el servidor SQL residen en máquinas separadas.

EDITAR: Se olvidó de mencionar que se utiliza un ORM que necesitaría acceso directo de lectura/escritura.

Pregunta: ¿Cuáles son las "mejores prácticas" para configurar el usuario para el acceso a la aplicación? ¿Qué roles se aplicarían y cuáles son algunas de las capturas?

Answer 1

En primer lugar, tiendo a encapsular los permisos en las funciones de la base de datos en lugar de adjuntarlas a los principales usuarios únicos.El gran triunfo aquí es que los roles son parte de su base de datos, por lo que puede realizar un script completo de seguridad y luego decirle a los tipos de implementación que "agreguen un usuario y lo agreguen a este rol" y que no luchan contra los boogeymen de permisos de SQL. Además, esto mantiene las cosas lo suficientemente limpias como para evitar el desarrollo en modo db_owner y sentirse mucho mejor consigo mismo, así como practicar como usted juega y, en general, evitar cualquier problema.

En la medida en que solicito permisos para ese rol, tiendo a lanzar la red más ampliamente estos días, especialmente si uno está usando ORMs y manejando la seguridad a través de la aplicación. En términos de T-SQL, que se ve así:

GRANT SELECT, UPDATE, INSERT, DELETE, EXECUTE on SCHEMA::DBO to [My DB Role] 

esto puede parecer un poco de miedo al principio, pero en realidad no lo es - que el papel no puede hacer otra cosa que manipular los datos de cualquier cosa. Sin acceso a procesos extendidos o procesos de sistema u otorgando acceso de usuario, etc. La otra gran ventaja es que cambiar el esquema, como agregar una tabla o un procedimiento, no requiere más trabajo de seguridad mientras permanezca dentro de ese esquema.

Otra cosa a tener en cuenta para SQL 2005+ es utilizar esquemas de base de datos para proteger grupos de objetos. Ahora, el gran truco aquí es que a muchos ORM y herramientas de migración no les gustan, pero si representa el esquema predeterminado [dbo] a la aplicación, puede usar esquemas alternativos para cosas especiales seguras. Por ejemplo, cree un esquema ADMIN para procedimientos especiales y brutales de limpieza de bases de datos que los administradores deben ejecutar manualmente. O incluso un esquema separado para una parte especial y altamente segura de la aplicación que necesita permisos de BD más granulares.

En cuanto al cableado en los usuarios donde tiene cajas separadas, incluso sin un dominio puede usar la autenticación de Windows (en autenticación de términos de servidor Sql). Simplemente cree un usuario con las mismas credenciales (combo de usuario/pase) en ambos cuadros. Configure un dominio de aplicación para que se ejecute como ese usuario en el buzón web y configure un usuario de Sql Server respaldado por ese principal en el cuadro sql y obtenga ganancias. Dicho esto, utilizar las funciones de la base de datos puede prácticamente separarlo de esta decisión, ya que los tipos de implementación deberían ser capaces de gestionar la creación de usuarios sql y modificar las cadenas de conexión según sea necesario.

Answer 2

Cree un usuario 'webuser' que la aplicación web utiliza.

Solo otorgar permisos de ejecución de proc a este usuario. No permita la lectura/escritura directa de la tabla. Si necesita leer algo de una tabla, escriba un proceso. Si necesita escribir datos, escriba otro proceso.

De esta manera todo se mantiene simple y agradable. Un usuario de la aplicación, con solo los permisos relevantes. Si la seguridad está comprometida, todo lo que el intruso puede hacer es ejecutar los procesos.

Answer 3

Durante mucho tiempo, las pautas del SQL Server para acceder a la aplicación fueron aislar el acceso a los datos en procedimientos almacenados, agrupar procedimientos en un esquema y otorgar la ejecución del esquema al principal utilizado por la aplicación. El encadenamiento de propiedad garantizaría el acceso de datos a los llamadores del procedimiento. El acceso se puede revisar inspeccionando los procedimientos almacenados. Este es un modelo simple, fácil de entender, diseñar, implementar y administrar. El uso del procedimiento almacenado puede aprovechar la firma de código, el método de control de acceso más granular y potente, y el único que es inviolable (la firma se pierde si se altera el procedimiento).

El problema es que cada parte de la tecnología que proviene de los diseñadores de Visual Studio va en contra de esta recomendación. Los desarrolladores reciben modelos que son difíciles de usar exclusivamente con procedimientos almacenados. A los desarrolladores les encanta diseñar primero sus modelos de clase y generar la estructura de la tabla a partir del modelo lógico. Las pautas basadas en el procedimiento reuieren los procedimientos para que existan primero, antes de que se escriba la primera línea de la aplicación, y esto es realmente problemático en el desarrollo debido a la forma iterativa del desarrollo moderno. Esto no es irresoluble, siempre y cuando la dirección del equipo esté al tanto del problema y lo aborde (es decir, tenga los procedimientos listos, incluso como se burla, cuando se inicie el ciclo de desarrollo).