Inicio de sesión en el sitio web usando credenciales de base de datos

Edit: Hice muchas suposiciones en esta respuesta que no eran necesariamente ciertas. Acabo de descubrir que el DB en cuestión es Postgres. Mi respuesta está más adaptada a SQL Server, que hasta la versión 2016 no tenía seguridad de nivel de fila. Dejaré mi respuesta aquí con fines informativos.

Lo que está sugiriendo no es la mejor práctica, por muchas razones. Eso no significa que usted no pueda hacerlo, pero debe estar dispuesto a conceder todos estos puntos si no lo hace:

Con su modelo, cualquier usuario puede acceder a la base de datos directamente sin utilizar el sitio web. (Editar: esto es suponiendo que está en una intranet local y que sus usuarios pueden acceder a la base de datos directamente usando otra herramienta fuera del sitio web).

Debido a esto:

1. Cualquier usuario puede agregar / editar / ver / eliminar información para todos los usuarios, no solo su propia información. (Nota: esto no es necesariamente cierto si su base de datos admite la seguridad a nivel de fila y si la usa).
2. Si las credenciales de cualquier usuario están comprometidas, todos los datos están potencialmente en riesgo. (Nota: esto no es necesariamente cierto si su base de datos admite la seguridad a nivel de fila y si la usa).
3. Un usuario que accede directamente a la base de datos podría, por cierto, ejecutar consultas que hacen algo que no pretendían. También pueden, sin saberlo, bloquear la base de datos y hacerla inutilizable para otros.

Hay otras razones para no hacerlo, pero hablemos de la "norma" en su lugar. Por lo general, usted administra a sus usuarios desde el sitio web y luego le da acceso al sitio web a la base de datos con un solo usuario que tiene el conjunto mínimo de permisos necesarios. Si alguna vez sospecha que la contraseña de la base de datos se ha comprometido, simplemente puede cambiar esa contraseña y luego informar al sitio web sobre la nueva contraseña (generalmente en un archivo cifrado de algún tipo que no es accesible por la web). Esto también hace que sea más fácil proporcionar diferentes niveles de permisos a diferentes usuarios, simplemente controlando su acceso en el código del sitio web. También puede obtener mucho más granular, por ejemplo, podría permitir que ciertos usuarios solo actualicen una columna particular de una tabla en particular, si así lo desea.

Afortunadamente, hay muchas soluciones gratuitas listas para usar que administran usuarios y roles en prácticamente todas las plataformas web populares. Realmente no puedo pensar en una buena razón para alejarme de la norma para conectarse a una base de datos a través de un sitio web.

Editar: aunque es posible que las mejores prácticas de Postgres difieran de mis sugerencias en esta respuesta, todavía no estoy convencido de que proporcionar acceso directo a la base de datos sea mejor que mi sugerencias Sin saber más sobre Postgres, preferiría este modelo. Pero eso podría ser simplemente porque esto es a lo que estoy acostumbrado.

En realidad, hay dos preguntas aquí: cómo autenticar a un usuario frente a un servidor web y qué usuario usar para conectarse a la base de datos como.

La verdadera pregunta es, ¿la seguridad de la base de datos debe estar a cargo del DBA o del programador web?

Los servidores de bases de datos son de larga duración y, a menudo, son compartidos por múltiples aplicaciones.

Lo ideal sería autenticar a los usuarios de su aplicación web (LAN) contra un servidor LDAP (también conocido como ActiveDirectory), a través de Kerberos + SPNEGO. Esto le brinda autenticación centralizada e inicio de sesión único en muchas aplicaciones.

También puede autenticar a los usuarios de la aplicación web directamente contra los usuarios de la base de datos, por ejemplo aquí . Si es ahí donde está toda la información de usuario de tu usuario y no usas LDAP / Kerberos, también podrías usar eso.

La siguiente pregunta es qué usuario de la base de datos usará cuando se conecte desde el servidor web:

1. Conéctese como usuario avanzado y agregue información de ID de usuario "real" a sus declaraciones SQL (¡por supuesto, con parámetros!)
2. Conéctese como el usuario real de db (esto elimina la agrupación de conexiones)
3. Conéctese como usuario limitado y suplante al usuario real utilizando set role

ONE es el más común, no porque sea una buena idea, sino porque la gente quería usar la agrupación de conexiones en el pasado y no entendía la suplantación. Esto patea el Principle of Least Privilege directamente en la entrepierna.

Hay vulnerabilidades increíblemente comunes, con finalización de carrera, más probables con la opción 1: Inyección de SQL y Referencias de objetos inseguros :

El servidor web se conecta a db como powerUser , Malice inicia sesión en el sitio web como malice y encuentra una inyección SQL y elimina su tabla payments , ya que powerUser tiene esa autoridad.

Sus desarrolladores web agregan el ID de usuario al sql para la URL /bank-accounts , pero son estúpidos y se olvidan de agregar el ID de usuario para las URL de las cuentas bancarias individuales (como /bank-accounts/999 ). Malice inicia sesión como malice y ve el saldo bancario de bobs .

Estos riesgos se pueden minimizar utilizando la suplantación y la seguridad de la fila de la base de datos (que esencialmente requiere la suplantación). PG 9.5 es compatible con la seguridad de la fila. Puedes imitarlo en versiones anteriores con security_barrier check option vistas y activadores.

También facilita la auditoría de datos, ya que tiene el nombre de usuario real en su base de datos como current_user

Diría que una base de datos como Postgres tiene mejor seguridad que la mayoría de los marcos de seguridad web, como lo hace Fila de seguridad, Seguridad de columna y tiene un buen sistema de roles jerárquico.

He visto marcos de seguridad web que seleccionan todas las filas para una consulta determinada, luego descartan todo lo que no pertenece al usuario X. Esto arruina la paginación y es terrible para el rendimiento. Además, nunca he visto uno que haga bien la seguridad de Columna / Campo.