tipos - usuario dbo sql server
Práctica recomendada para usuarios/roles en SQL Server para una aplicación web (3)
Cree un usuario ''usuario web'' que la aplicación web utiliza.
Solo conceda 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 agradable y simple. 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.
Busqué en línea un poco y no pude encontrar nada que realmente identificara el lugar o cubrí las bases sobre cómo configurar usuarios / roles en una base de datos.
Básicamente, habría un usuario que se usaría para acceder a la base de datos desde la aplicación (aplicación web en este caso) que necesitaría acceder 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 administrador principal (esto es bastante simple).
Actualmente tengo un entorno de desarrollo en el que, en mi opinión, no administramos la seguridad demasiado bien (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: Olvidé mencionar que se usa 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?
Durante mucho tiempo, las pautas de SQL Server para el acceso de la aplicación a la base de datos fueron para aislar el acceso a los datos en procedimientos almacenados, agrupar procedimientos en un esquema y otorgar la ejecución en el 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 poderoso, 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 sale de los diseñadores de Visual Studio va en contra de esta recomendación. A los desarrolladores se les presentan 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 el liderazgo del equipo sea consciente del problema y lo aborde (es decir, tenga listos los procedimientos, incluso cuando se burlen, cuando comience el ciclo de desarrollo).
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 esa función, tiendo a ampliar la red en estos días, especialmente si uno está utilizando ORM y manejando la seguridad a través de la aplicación. En términos de T-SQL, se ve así:
GRANT SELECT, UPDATE, INSERT, DELETE, EXECUTE on SCHEMA::DBO to [My DB Role]
Esto puede parecer un poco aterrador al principio, pero realmente no lo es; esa función no puede hacer otra cosa que manipular datos. 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 siempre que permanezca dentro de ese esquema.
Otra cosa a tener en cuenta para SQL 2005+ es usar 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.