Debería de datos de seguridad se pueden realizar en la base de datos secundarios?

Question

Estamos en el proceso de creación de un nuevo marco y la forma de hacer negocios para nuestras nuevas apps internas.Nuestro diseño actual dicta que todos los de seguridad lógica deben ser manejados a través de nuestro base de datos, y toda la información (y me refiero a todos) van a ir en y fuera de la base de datos a través de procedimientos almacenados.

La teoría es, la capa de acceso a datos de solicitudes de información a partir de un procedimiento almacenado y pasa por encima de autenticación a la base de datos.La base de datos determina el rol del usuario/permisos y decide si procede o no realizar la tarea (ya sea la recuperación de los datos o hacer una actualización).

Supongo que esto significa un menor número de transacciones de base de datos.Una llamada a la base de datos.Si la seguridad de que estaba en nuestra capa de acceso a datos, esto requeriría 1 base de datos llamada para determinar si el usuario tuviera permisos adecuados y, a continuación, 1 base de datos independiente de la llamada a realizar la acción.

Yo, por ejemplo, encontrar el SQL Management studio, que carecen por completo como un IDE.Mi principal preocupación es que vamos a terminar encima de tener que mantener cierta cantidad indecente de la lógica de negocio en nuestros procedimientos almacenados para algunos muy mínima ganancia de rendimiento.

Ahora mismo, estamos usando LINQ para nuestro ORM.Parece ligero y rápido, pero lo mejor de todo, es realmente fácil de desarrollar rápidamente en.

Es el costo de mantenimiento de valor de la ganancia de rendimiento?Estamos engañando a nosotros mismos a pensar incluso habrá un notable aumento en el rendimiento?O estamos simplemente haciendo una pesadilla para nosotros mismos?

Nuestro entorno:

• Interna, no aplicaciones de negocios de misión crítica
• C#/ASP.NET 3.5
• Windows 2003
• MS SQL Server 2005
• 35 Medianas aplicaciones web con aprox 500 usuarios

Answer 1

No se que hacer.Recientemente hemos tenido un MUY MAL experiencia cuando la base de datos "gurú" se decidió a ir a otra compañía.El mantenimiento de toda la lógica, los procedimientos son simplemente horrible!!

Sí, vas a tener ciertas mejoras de rendimiento, pero que no vale la pena.De hecho, el rendimiento no es ni siquiera un motivo de gran preocupación en su aplicación interna.Invertir más dinero en un buen servidores.Va a pagar.

Answer 2

Desafortunadamente no hay una respuesta verdadera".La elección que usted debe hacer depende de múltiples factores, como:

• La familiaridad con el equipo con el dado soluciones (es decir, si la mayoría de ellos es cómodo escribir SQL, puede estar en la base de datos, sin embargo si la mayoría de ellos se siente más cómodo con C#, debe estar en el código)
• El "poder político" de cada una de las partes
• etc

No hay ninguna ventaja decisiva en cualquier dirección (como dijo el rendimiento de las ganancias son mínimas), la única cosa a tener en cuenta es el DRY (Don't Repeat Yourself) principio:no vuelva a implementar la funcionalidad de dos veces (en el código y en la DB), porque mantenerlos sincronizados será una pesadilla.Elegir una solución y se adhieren a ella.

Answer 3

Usted podría hacerlo pero su enorme dolor de desarrollar y mantener.Tomar de alguien que está en un proyecto donde casi toda la lógica del negocio está codificado en procedimientos almacenados.

Para la seguridad, ASP.NET tiene usuario y la función de gestión de horneado en él por lo que podría ser el ahorro de los viajes a la base de datos, pero ¿y qué?En el intercambio se hace mucho más molesto para manejar y sistema de depuración de los errores de validación y porque tienen que brotan de la base de datos.

La unidad de pruebas es mucho más difícil, ya que los marcos disponibles para pruebas de unidad sprocs están mucho menos desarrollados.

Adecuada programación orientada a objetos y diseño controlado por dominio es de todos, pero fuera de la ventana.

Y la ganancia de rendimiento va a ser pequeño, si los hubiere.Hemos hablado de esto aquí.

Yo recomendaría que si usted desea guardar su cordura como un desarrollador no puede luchar con uñas y dientes para mantener la base de datos de la capa de persistencia sólo

Answer 4

En mi humilde opinión:

Aplicación de nivel de servicio -> lógica de la aplicación y validación de
Aplicación de la capa de datos -> datos de la lógica y de la seguridad
Base de datos -> la coherencia de los datos

Usted será mordido por el procedimiento almacenado enfoque más pronto o más tarde, he aprendido de la manera difícil.
Procs son grandes por un disparo de operaciones que necesitan un gran rendimiento, pero el CRUD es la parte de los datos de los niveles de empleo

Answer 5

Los procedimientos almacenados son generalmente un triunfo para la seguridad.La simplificación de la relación entre la aplicación y la base de datos reduce el número de lugares donde usted puede tener errores;los errores en el código que las interfaces de lógica de negocio para la base de datos tienden a ser problemas de seguridad.Así, el administrador no está mal sobre el bloqueo de las cosas a los procedimientos almacenados.

Otro de los beneficios de bloqueo de la aplicación de los procedimientos almacenados es que la aplicación de la pila de conexión de base de datos puede tener sus privilegios bloqueado específicas llamadas a procedimientos almacenados y nada más.

Un beneficio de tener un DBA involucrados en la seguridad de la lógica de la aplicación es que las diferentes funciones de la aplicación y los papeles pueden ser divididos en la base de datos de abajo a las vistas, de modo que incluso si SQL dinámico y genérico seleccione declaraciones son necesarios, el daño de un SQL vulnerabilidad puede ser limitada.

La otra cara de esto es, por supuesto, pierde flexibilidad.Un ORM es, obviamente, va a ser más rápido para desarrollar de una constante negociación con bases de datos sobre parámetros del procedimiento almacenado.Y, como la presión sobre los procedimientos almacenados crece, más y más probable que los procedimientos mismos de recurrir a SQL dinámico, que va a ser tan vulnerable como la aplicación compuesta de SQL para atacar.

Hay una feliz tierra de en medio aquí, y usted debe tratar de encontrar.He trabajado en proyectos recientemente que se salvaron de bastante terrible de inyección de SQL problemas debido a un DBA había configurado cuidadosamente la base de datos, sus conexiones y sus procedimientos almacenados para "privilegio mínimo", de manera que cualquier usuario de base de datos sólo tenían acceso a lo que necesitaba saber.

Obviamente, como escribir código SQL en la lógica de la aplicación, asegúrese de que usted está constantemente utilizando con parámetros de declaraciones preparadas, que estás desinfectar tu entrada, que eres consciente de internacionalización de la entrada (hay muchas, muchas maneras de decir una sola cita a través de HTTP), y que eres consciente de cómo su base de datos se comporta cuando las entradas son demasiado grandes para los anchos de columna.

Answer 6

Todo depende de tu caso probablemente es mejor que no vaya por el SP de la ruta y hacer todo lo que la DDD camino (hacer un modelo de Dominio en el código y el uso que).

Sin embargo, si usted tiene una base de datos que se utiliza no sólo por su aplicación, pero por muchos, entonces usted probablemente debería considerar los servicios web.De alguna manera, la base de datos debe ser accesible sólo a través de una capa que hace cumplir las reglas de negocio cosa que usted va a terminar con los "sucios" de datos y desinfección de sus datos después es mucho más grande el dolor que escribir un par de reglas de negocio de antemano.Una buena base de datos debe tener el check-restricciones e índices, de manera que tendrá algunas reglas de negocio, te guste o no.

Y si tiene que lidiar con millones y millones de registros, usted será feliz de tener una buena DB-tipo que resuelve el problema para usted.

Answer 7

Mi opinión es que la propia aplicación debe gestionar la autenticación y la autorización.En el lado de la base de datos sólo debe manejar el cifrado de datos según sea necesario.

Answer 8

He construido procedimiento almacenado de las aplicaciones basadas en el pasado.En su caso hay tal vez una manera de mantener la autenticación en la capa de base de datos y tienen su lógica de negocio en C#.Utilizar las vistas para limitar los datos (sólo ver las filas que tienen la autoridad para).Estas vistas se pueden usar en LINQ con la misma facilidad como tablas.Establece tus actualizaciones a suceder con los procedimientos almacenados.

Esto permite linq, la lógica de negocio en C#, y una capa de autenticación en la base de datos que controla el acceso a los datos.