database - studio - ¿Deberían los usuarios de la aplicación ser usuarios de la base
error de inicio de sesión del usuario ''iis apppool (12)
* no es una buena idea si el RDBMS contiene: * cualquier información cubierta por HIPAA o Sarbanes-Oxley o la Ley de Secretos Oficiales (RU) * información de la tarjeta de crédito u otra información de crédito del cliente (OP, líneas de crédito, etc.) * información personal (ssn , dob, etc.) * información competitiva, de propiedad o IP *
No es cierto, uno puede administrar perfectamente qué datos puede ver un usuario de la base de datos y qué datos puede modificar. Una base de datos (al menos Oracle) también puede auditar todas las actividades, incluidas las selectas. Tener miles de usuarios de bases de datos también es perfectamente normal.
Es más difícil crear buenas aplicaciones seguras porque tiene que programar esta seguridad, una base de datos ofrece esta seguridad y puede configurarla de manera declarativa, sin necesidad de código.
Mi trabajo anterior involucró mantenimiento y programación para una base de datos muy grande con cantidades masivas de datos. Los usuarios vieron estos datos principalmente a través de una interfaz web de intranet. En lugar de tener una tabla de cuentas de usuario, cada cuenta de usuario era una cuenta real de primera clase en RDBMS, lo que les permitía conectarse con sus propias herramientas de consulta, etc., y también nos permitía controlar el acceso a través del RDBMS. de usar nuestra propia lógica de aplicación.
¿Es esta una buena configuración, suponiendo que no estás en la intranet pública y lidiando con potencialmente millones de usuarios (potencialmente maliciosos) o algo así? ¿O siempre es mejor definir sus propios medios para manejar cuentas de usuario, sus propios permisos, su propia lógica de seguridad de aplicaciones, y solo repartir cuentas RDBMS para ayudar a usuarios con necesidades especiales?
Creo que vale la pena destacar qué otras respuestas han tocado:
Una base de datos solo puede definir restricciones basadas en los datos. Es decir, restringir seleccionar / insertar / actualizar / eliminar en tablas o columnas particulares. Estoy seguro de que algunas bases de datos pueden hacer algunas cosas más inteligentes, pero nunca podrán implementar restricciones basadas en reglas comerciales como una aplicación. ¿Qué sucede si un determinado usuario puede actualizar una columna solo a ciertos valores (por ejemplo, <1000) o solo aumentar los precios, o cambiar cualquiera de las dos columnas, pero no ambas?
Diría que a menos que estés absolutamente seguro de que nunca necesitarás nada más que la granularidad de tabla / columna, esta es una razón suficiente por sí misma.
Depende (como la mayoría de las cosas).
Tener múltiples usuarios de bases de datos niega la agrupación de conexiones, ya que la mayoría de las bibliotecas manejan la agrupación en función de las cadenas de conexión y las cuentas de usuario.
Por otro lado, es probablemente una solución más segura que cualquier cosa que hagamos nosotros o yo desde cero. Deja la seguridad en el sistema operativo y en el servidor de base de datos, en el que confío mucho más que yo. Sin embargo, este es solo el caso si se hace un esfuerzo para configurar bien los permisos de la base de datos. Si está utilizando un grupo de usuarios de OS / db con los mismos permisos, no será de mucha ayuda. Todavía obtendrá un registro de auditoría, pero eso es todo.
Dicho todo esto, no sé si me sentiría cómodo permitiendo que los usuarios normales se conecten directamente a la base de datos con sus propias herramientas.
Esta no es una buena idea para cualquier aplicación en la que almacene datos para múltiples usuarios en la misma tabla y no quiere que un usuario pueda leer o modificar los datos de otro usuario. ¿Cómo restringirías el acceso en este caso?
Esto es, en cierto modo, similar a: el servidor sql / AD es bueno para cualquier cosa
No creo que sea una mala idea arrojar su modelo de seguridad, al menos básico, en la base de datos. Puede agregar restricciones en la capa de aplicación para cosméticos, pero independientemente de la cuenta con la que el usuario acceda a la base de datos, ya sea en base a la aplicación o al usuario, es mejor si esa cuenta está restringida solo a las operaciones permitidas por el usuario.
No hablo de todas las aplicaciones, pero hay un gran número que he visto donde capturar la contraseña es tan simple como abrir el código en el bloc de notas, usar un archivo DLL incluido para descifrar el archivo de configuración o encontrar un archivo de respaldo (por ejemplo, web .config.bak en asp.net) al que se puede acceder desde el navegador.
Evitaría dar acceso a cualquier base de datos de usuario. Más tarde, cuando esto comienza a causar problemas, quitarle acceso es muy difícil.
Por lo menos, déles acceso a una réplica de solo lectura de la base de datos para que no puedan matar a toda su compañía con una mala consulta.
Lo sé, estoy respondiendo a una publicación muy antigua, pero recientemente me encontré con la misma situación en mi proyecto actual. También estaba pensando en líneas similares, si "los usuarios de la aplicación son usuarios de la base de datos". Esto es lo que analicé:
- Definitivamente no tiene sentido crear esa gran cantidad de usuarios de aplicaciones en la base de datos (si su aplicación va a ser utilizada por muchos usuarios).
- Digamos que creó X (gran cantidad de usuarios) en la base de datos. Está abriendo una puerta de enlace clara a su base de datos.
Tomemos un escenario para la solución:
Hay dos tipos de usuarios de aplicaciones (gerentes y asistentes). Ambos necesitan acceso a la base de datos para algunas transacciones.
Es obvio que crearía dos roles, uno para cada tipo (Administrador y Asistente) en la base de datos. Pero ¿qué hay de usuario de la base de datos para conectarse desde la aplicación. Si crea una cuenta por usuario, terminará creando linealmente las cuentas en la base de datos.
Lo que sugiero
- Cree una cuenta de base de datos por Rol. (Digamos
Manager_Role_Account) - Deje que su aplicación tenga lógica comercial para asignar un usuario de la aplicación con el rol correspondiente. (Usuario Tom con función de administrador a
Manager_Role_Account) - Use el usuario de la base de datos (
Manager_Role_Account) correspondiente al rol identificado en el n. ° 2 para conectarse a la base de datos y ejecutar su consulta.
Espero que esto tenga sentido!
Actualizado: Como dije, me encontré con una situación similar en mi proyecto (con respecto a la base de datos Postgresql en la parte de atrás y una aplicación web de Java en la interfaz), encontré algo muy útil llamado autenticación de proxy .
Esto significa que puede iniciar sesión en la base de datos como un usuario, pero puede limitar o ampliar sus privilegios según el usuario Proxy. Encontré muy buenos enlaces explicando lo mismo.
Para Postgresql a continuación Opción de enfoque de autenticación para la aplicación financiera en PostgreSQL
- Para Oracle Proxy Authentication
¡Espero que esto ayude!
No estoy de acuerdo en que el uso de la base de datos para el control de acceso de los usuarios sea tan peligroso que otros creen que es. Vengo del ámbito de Oracle Forms Development, donde este tipo de control de acceso de usuario es la norma. Al igual que cualquier decisión de diseño, tiene sus ventajas y desventajas.
Una de las ventajas es que pude controlar los privilegios de seleccionar / insertar / actualizar / eliminar para CADA tabla desde una única configuración en la base de datos. En un sistema teníamos 4 aplicaciones diferentes (administradas por diferentes equipos y en diferentes idiomas) tocando las mismas tablas de la base de datos. Pudimos declarar que solo los usuarios con el rol de Administrador podían insertar / actualizar / eliminar datos en una tabla específica. Si no lo gestionamos a través de la base de datos, entonces cada equipo de aplicación debería implementar (duplicar) correctamente esa lógica en toda su aplicación. Si una aplicación se equivocó, entonces las otras aplicaciones sufrirían. Además, tendrías que duplicar el código para administrar si alguna vez quisiste cambiar los permisos en un único recurso.
Otra ventaja es que no tuvimos que preocuparnos por almacenar las contraseñas de los usuarios en una tabla de base de datos (y todas las restricciones que vienen con ella).
No estoy de acuerdo con que "las cuentas de usuario de la base de datos sean intrínsecamente más peligrosas que cualquier otra cosa en una cuenta definida por su aplicación". Los privilegios necesarios para cambiar los privilegios específicos de la base de datos son MUCHO MÁS duros que los privilegios necesarios para actualizar / eliminar una sola fila en una tabla de "PERSONAS".
Y "escalar" no era un problema porque asignamos privilegios a los roles de Oracle y luego asignamos roles a los usuarios. Con una única declaración de Oracle podríamos cambiar el privilegio para millones de usuarios (no es que tuviéramos tantos usuarios).
La autorización de la aplicación no es un problema trivial. Muchas soluciones personalizadas tienen agujeros que los hackers pueden explotar fácilmente. Los grandes nombres como Oracle han pensado y codificado mucho para proporcionar un sólido sistema de autorización de aplicaciones. Estoy de acuerdo en que el uso de la seguridad de Oracle no funciona para todas las aplicaciones. Pero no sería tan rápido para descartarlo a favor de una solución personalizada.
"cada cuenta de usuario era una cuenta real de primera clase en RDBMS, lo que les permitía conectarse con sus propias herramientas de consulta, etc."
no es una buena idea si el RDBMS contiene:
cualquier información cubierta por HIPAA o Sarbanes-Oxley o The Official Secrets Act (UK)
información de la tarjeta de crédito u otra información de crédito del cliente (órdenes de compra, líneas de crédito, etc.)
información personal (ssn, dob, etc.)
información competitiva, propietaria o de IP
porque cuando los usuarios pueden usar sus propias herramientas de consulta no administradas, la empresa no tiene forma de saber o auditar qué información se consultó o dónde se entregaron los resultados de la consulta.
Oh y qué dijo @annakata.
Editar: Debo aclarar que, a pesar de cualquier cosa en el OP, lo que estás haciendo es definir lógicamente una aplicación incluso si no existe código. De lo contrario, es solo una base de datos pública con todos los peligros que conlleva.
Tal vez me llame a la muerte por este mensaje, pero creo que este es un anti-patrón extraordinariamente peligroso en términos de seguridad y diseño .
Un objeto de usuario debe ser definido por el sistema en el que se está ejecutando. Si realmente los está definiendo en otra aplicación (la base de datos), usted pierde el control.
No tiene sentido desde el punto de vista del diseño, porque si desea ampliar esas cuentas con cualquier tipo de datos (dirección de correo electrónico, número de empleado, MyTheme ...) no podrá ampliar el usuario de la base de datos. y vas a necesitar construir esa tabla de usuarios de todos modos.
Las cuentas de usuario de base de datos son intrínsecamente más peligrosas que cualquier otra en una cuenta definida por su aplicación, ya que podrían promoverse, eliminarse, accederse o manipularse no solo por la base de datos y cualquier DBA que pase, sino por cualquier otra cosa conectada a la base de datos. Ha expuesto un elemento crítico del sistema como público.
Escalar está fuera de discusión. Imagina una abstracción en la que vas a tener decenas o cientos de miles de usuarios. Eso no va a ser manejable como cuentas DB, pero como registros en una tabla solo son datos. El antiguo argumento de "bueno, onyl habrá usuarios de X" no me sirve de nada porque he visto que las aplicaciones internas muy limitadas se exponen públicamente cuando la empresa siente que puede agregar valor al cliente o a la empresa. acaba de ser comprado por un socio gigante que ahora necesita acceso. Debe planificar para una extensibilidad razonable.
No podrá compartir el connpool, no va a estar más seguro que si acaba de crear un puñado de cuentas de roles, y no necesariamente va a poder afectar los cambios masivos cuando necesita hacerlo, o hacer una copia de seguridad de manera efectiva.
Todo parece ser que hay muchos problemas serios para mí, e imagino que otros SO más experimentados podrían enumerar más.
Muchas herramientas de consulta de base de datos están muy avanzadas en estos días, y puede ser una verdadera lástima reimplantar el mundo solo para agregar restricciones. Y siempre que los permisos de usuario de la base de datos estén bloqueados correctamente, podría estar bien. Sin embargo, en muchos casos no puede hacer esto, debe exponer una API de alto nivel a la base de datos para insertar objetos en muchas tablas de manera adecuada, sin que el usuario necesite capacitación específica para que "simplemente agreguen una dirección en esa tabla". ¿Por qué no está funcionando? ".
Si solo quieren usar los datos para generar informes en Excel, etc., entonces tal vez podría usar una interfaz de informes como BIRT.
Entonces, básicamente: si los usuarios conocen bien las bases de datos y los recursos para implementar un front-end adecuado son bajos, siga haciendo esto. Sin embargo, si el recurso aparece, probablemente sea el momento de hacer que los requisitos de la gente creen un front-end más simple orientado a tareas para ellos.
Yo pienso en general En su aplicación de base de datos tradicional no deberían serlo. Por todas las razones ya dadas. En una aplicación de base de datos tradicional existe una capa de negocios que maneja toda la seguridad y esto se debe a que existe una línea tan fuerte entre las personas que interactúan con la aplicación y las personas que interactúan con la base de datos.
En esta situación, generalmente es mejor administrar estos usuarios y roles usted mismo. Puede decidir qué información necesita almacenar sobre ellos, y qué registra y audita. Y lo más importante es que define el acceso basado en reglas comerciales puras en lugar de reglas de bases de datos. No tiene nada que ver con las tablas a las que acceden y todo lo relacionado con si pueden insertar acciones comerciales aquí . Sin embargo, estos no son problemas técnicos. Estos son problemas de diseño. Si eso es lo que debe controlar, entonces tiene sentido administrar usted mismo a los usuarios.
Usted ha descrito un sistema donde permite a los usuarios consultar la base de datos directamente. En este caso, ¿por qué no usar cuentas de DB? Harán el trabajo mucho mejor que usted si intenta analizar las consultas que los usuarios escriben y los examinan en contra de algunas reglas que usted ha diseñado. Eso para mí suena como un sistema de pesadilla para escribir y mantener.
No bloquees las cosas porque puedes. Explique a los responsables cuáles son las implicaciones de seguridad, pero no intente evitar que las personas hagan cosas porque usted puede. Especialmente no cuando están acostumbrados a acceder a los datos directamente.
Nuestro trabajo como desarrolladores es permitir que las personas hagan lo que deben hacer. Y en la situación que has descrito. Específicamente, conéctese a la base de datos y consulte con sus propias herramientas. Luego, creo que cualquier cosa que no sean cuentas de la base de datos será inseguro o innecesariamente restrictivo.