¿Alguna vez es una buena práctica usar una cuenta de base de datos distinta para cada usuario de una aplicación?

Las aplicaciones a las que estoy acostumbrado están basadas en el servidor y usan una cuenta de base de datos para muchos usuarios, con el código de la aplicación controlando lo que el usuario puede hacer, o un solo usuario.

¿Existen aplicaciones comerciales complejas exitosas en las que cada persona necesita su propia cuenta de base de datos y se confía en el servidor de la base de datos para hacer cumplir las reglas de política sobre lo que cada usuario debe tener permitido y no debe hacer?

Estoy pensando en aplicaciones en las que varias personas contribuyen a la información en una base de datos y pueden acceder a la información almacenada por otros, por ejemplo, colegas en una organización que necesitan acceder a los registros de los clientes.

¿También hay un nombre para este tipo de configuración?

Si necesita un control realmente estricto aplicado a nivel de datos. Por ejemplo, auditorías extensas. La auditoría no es muy buena si varios usuarios comparten la misma cuenta. Si tiene algunos usuarios que necesitan acceder a la base de datos directamente.

Si la seguridad es tan estricta, normalmente ni siquiera expone la base de datos directamente. Tiene un servicio y el cliente debe obtener datos del servicio.

En una aplicación web, la base de datos (por ejemplo, el puerto 1433) generalmente no está expuesta directamente, por lo que tiene un nivel de seguridad. Incluso si la aplicación web accede a la base de datos directamente, los usuarios aún no tienen acceso directo a la base de datos.

Si el inicio de sesión y la contraseña se encuentran en la aplicación del cliente, pueden ser pirateados. Si es un dominio, puede usar seguridad integrada.

En la base de datos puedes tener controles bastante finos. Pero el control de nivel de fila es un poco de trabajo. Una base de datos no es una buena herramienta para las reglas comerciales. Las reglas de negocios y la seguridad detallada generalmente se aplican a nivel de aplicación.

Puede tener un modo mixto donde hay algunos procedimientos almacenados utilizados por los administradores y desea rastrear qué administrador. Y puede otorgar acceso de solo lectura a los usuarios que generan informes directamente.

El desafío aquí es que su acceso a la base de datos es administrado por una abstracción. En lugar de que los usuarios se conecten como ellos mismos, esencialmente asumen la identidad de algún rol de aplicación generalizado. No solo pierde visibilidad de la conexión individual, sino que también pierde la granularidad de definir diferentes tipos de acceso para todos sus usuarios individuales.

La razón principal para usar este enfoque es la simplicidad. Muchas aplicaciones están diseñadas para que el usuario de la aplicación no tenga conocimiento de la base de datos. Realmente no lo necesitan, especialmente si la aplicación gestiona su propia seguridad interna. La mayoría de los usuarios individuales nunca se conectarán directamente a la base de datos, por lo que no es necesario definir un inicio de sesión explícito para ellos.

El único momento en que debe considerar permitir que la base de datos administre su seguridad es si tiene usuarios que se conectarán directamente a su base de datos. Esto significa que van alrededor de su aplicación y ya no puede hacer cumplir la seguridad por sí sola. La ventaja aquí es que puede ser más detallado al definir su seguridad. La desventaja es la mayor sobrecarga para administrar usuarios y sus permisos.

Si siente la necesidad de este tipo de acceso, desea utilizar el Control de acceso basado en roles . Debe definir roles según el tipo de permisos necesarios en su base de datos y luego agrupar usuarios individuales bajo esos roles. Esto le brinda una mejor auditoría y control sobre su modelo de seguridad, que puede descontrolarse rápidamente al administrar el acceso directo.

Hay un enfoque híbrido para esto. Si desea que su seguridad sea administrada parcialmente por la base de datos, puede crear múltiples usuarios de aplicaciones, cada uno definido por su rol y otorgar acceso explícito a esos usuarios en función del rol que cumplen. Esto significa que puede aprovechar el motor de base de datos para algunos de sus modelos de seguridad, pero aún debe tener cierta administración dentro de la aplicación. Aumenta la complejidad del modelo de usuario de la aplicación, pero le brinda una granularidad más fina en los diferentes inicios de sesión en uso.

Debe comenzar a aplicar la seguridad al nivel más granular lo antes posible. Los roles ayudan en este sentido: dar acceso a las personas a varias mesas a la vez no es una pesadilla.

La cuenta única para todos es una gran fuente de preguntas aquí y en otros lugares: "se eliminó el registro x, ¿cómo puedo averiguar quién lo hizo?" - la respuesta es que no puedes - sin cuentas individuales y auditorías .

Por "auditar" quiero decir que si bien está muy bien tener una cuenta para todos, eso no significa que tenga una verdadera seguridad. Si, por ejemplo, se elimina un registro en la tabla de recursos humanos, todo lo que puede decir es que alguien con acceso a la tabla de recursos humanos hizo eso, eso es x número de personas.

Necesita activadores en su sistema que registren acciones para poder rastrear hasta el nivel individual que realizó la acción X (a menos que tenga un RDBMS como Oracle donde esto se puede hacer automático).

En cualquier caso, siempre debe hacer que su seguridad sea lo más detallada posible tan pronto como sea posible: otorgue a las personas acceso a las tablas solo en función de la "necesidad de saber". Y siempre incluya marcas de tiempo para las acciones en las mesas: las personas suelen dar sus identificaciones a los demás; si puede decir: "Jimmy, usted era el único en la oficina a las 17:49 ...", una vez más, no es irresistible, solo otra flecha en tu carcaj.

Tal vez si nos proporciona su RDBMS, ¿podría obtener consejos más específicos / relevantes para su situación?

Sí lo es. Conectarse a una base de datos desde una aplicación como un único usuario poderoso es una violación del principio de privilegio mínimo . Esta es la causa raíz de la mayoría de los ataques de inyección SQL.

Esto generalmente se hace debido a la ignorancia, en aras de la simplicidad o, a veces, por el rendimiento.

Las bases de datos a menudo son de larga duración y son utilizadas por múltiples aplicaciones al mismo tiempo y con el tiempo. Puede ahorrar recursos centralizando el control de acceso en la base de datos en lugar de hacerlo en varias aplicaciones.

Desea elegir un servidor db que admita seguridad de fila, seguridad de columna y suplantación / autenticación de proxy (que admite usuarios de db reales + agrupación de conexiones)

También sería más seguro para aplicaciones basadas en "complementos", como Wordpress, donde es difícil evitar inyecciones SQL debido a autores de complementos no calificados. Cada complemento obtiene inicio de sesión de db, en lugar de la aplicación en su conjunto.