¿Es la aplicación web conectada a una base de datos a través de un servidor de aplicaciones más segura?

"Más seguro" no es constructivo

Pensar que algo es "más seguro" a menudo conduce a una mala toma de decisiones. Todo tipo de cosas son más seguras y son una mala idea. Es más útil preguntar "¿Añade esto seguridad significativa?" y "¿La seguridad obtuvo una compensación razonable entre costo y beneficio?"

Los niveles no agregan mucha seguridad

La mayoría de los libros informáticos recomiendan el modelo de tres niveles. Descubrí que el modelo de dos niveles es igual de común (quizás más común) y esto incluye una gran cantidad de aplicaciones muy importantes que he auditado: banca en línea, etc.

La realidad es que tener dos niveles es solo un beneficio de seguridad marginal en un solo nivel. La gente suele decir "si el servidor web es hackeado, no están en la base de datos". Si bien técnicamente es cierto, eso es engañoso. El servidor web tendrá credenciales para conectarse a la base de datos, lo que permitirá a un atacante extraer todos los datos. Puedes imaginar ciertos escenarios de ataque donde tener dos niveles bloquea vectores de exploits particulares, pero estos son poco comunes.

El beneficio de seguridad de tres niveles frente a dos es incluso inferior a dos frente a uno. Y esto es especialmente así con los SPA, donde el nivel web está en el cliente.

Editar Para ser claro, me refiero a los niveles como en los niveles en servidores separados (virtuales o físicos), en lugar de una separación puramente lógica.

Si distingue entre el servidor web, el servidor de aplicaciones y la base de datos, en realidad quiere decir front-end, lógica empresarial y back-end (almacenamiento). Esto también se denomina arquitectura de múltiples niveles con nivel de presentación, nivel de aplicación y nivel de datos. En este caso, el servidor de aplicaciones no simplemente pasará por las solicitudes del servidor web, sino que solo permitirá acciones que se ajusten a la lógica de negocios. Esto significa que todo el material de seguridad (es decir, quién puede acceder a qué) se realiza esencialmente en el servidor de aplicaciones y el servidor web está allí para hacer que esta información sea accesible a través de un navegador web.

Si, en cambio, solo tiene un servidor web y una base de datos, la lógica de negocios es esencialmente parte del servidor web. Si bien esto hace que a menudo sea más fácil comenzar con alguna aplicación web, la distinción que falta entre la presentación y la lógica de negocios llevará fácilmente a un desorden que ya nadie puede entender y que a menudo permite evitar la lógica de negocios y así obtener acceso directo a la base de datos para atacante.

Tenga en cuenta que la separación entre las capas no necesariamente tiene que hacerse con un servidor o aplicación independiente, pero también puede ser una separación en proceso (es decir, API, clases ...). Pero es importante que esta separación no se pueda omitir simplemente, lo que a menudo se puede manejar de manera más segura con un proceso o servidor separado. En ocasiones, se puede ver una separación que falta entre la presentación y la aplicación, ya que no se puede acceder a información específica mediante HTML, pero aún se puede acceder a ellas mediante una API JSON o XML.

Necesita un nivel de aplicación como filtro porque la mayoría de los sistemas de base de datos * no permiten el manejo de permisos, que es lo suficientemente detallado para manejar múltiples usuarios.

Generalmente * puede crear usuarios con diferentes permisos de lectura y escritura, pero generalmente * estos están diseñados para una docena de usuarios y no se escalan bien para miles o incluso millones de usuarios. Además, por lo general, * solo se pueden establecer permisos en un nivel de tabla, no en un nivel por fila, pero solo en un nivel por campo.

Esto significa que es difícil para usted controlar qué datos pueden y no pueden ver sus usuarios y qué datos pueden y no pueden editar. Para dar un ejemplo, tomemos una tabla de usuarios con estas columnas

userId
password
profilePicture
createdDate
lastLoggedInDate

Se debería permitir a las personas cambiar su propio profilePicture , pero no el de otras personas. Nadie debería cambiar el campo createdAt y cambiar el userId podría causar todo tipo de hijinks. Cada usuario debe editar el lastLoggedInDate cuando inicia sesión y lo establece en la fecha actual, pero no lo establece en nada diferente. ¿Puede su base de datos manejar esta complejidad *? Ah, y aún no hemos hablado de referencias entre tablas.

Bueno, pero ¿qué pasa si simplemente prohíbe esto en la capa de cliente al no escribir el código GUI para hacer las cosas que el usuario no debe hacer? El problema es que su base de datos no tiene forma de verificar que su aplicación cliente sea realmente el programa que escribió. Cuando habla SQL y envía credenciales de inicio de sesión válidas, la base de datos confiará en ello. Un usuario malintencionado podría escribir su propio cliente y enviar comandos SQL arbitrarios a su base de datos.

_{* No quiero decir que es imposible que exista una base de datos que pueda hacer todo eso, pero hasta ahora no he visto ninguna. Cuando conozca uno, no dude en comentar.}