Actualmente tengo dos proyectos ASP.NET Core que comparten algunas clases de lógica empresarial, así como DbContext. Se inyectan como dependencias en ConfigureServices, tal y como suele mostrarnos Microsoft Docs.

Sin embargo, cuando se trata de la implementación, mi cliente sugiere separar el acceso a la base de datos (es decir, cualquier lógica comercial que requiera conexión a la base de datos) a un servidor diferente y servir como api web.

Descubrí que esta idea rara vez se menciona en Internet, pero de alguna manera tiene tanto sentido para mí: esto garantiza que, incluso si alguien piratea el servidor web, no tenga acceso directo a la base de datos y cause daños o fugas de datos.

¿Alguien puede decirme si es una buena práctica o en realidad no es un éxito?

0
clifflau1120 16 oct. 2018 a las 06:33

2 respuestas

La mejor respuesta

Puede tener sentido agregar un servicio de API web al que las dos aplicaciones cliente realizan solicitudes http. Algo parecido a un microservicio. Sin embargo, las solicitudes de servicios web que deben autenticarse requieren que se configuren. Lo que conduce a cómo está configurada actualmente su autenticación. Si está alojado en la nube, puede usar puertas de enlace de API y combinar oauth. Cada proveedor de nube pública ofrece su propio estilo de pasarela. Ex. Azure ofrece servicio de administración de api.

0
jbooker 16 oct. 2018 a las 03:47

La instancia de su base de datos definitivamente debería estar en un servidor separado de sus aplicaciones web, tanto por razones de rendimiento como de seguridad. Sin embargo, mover el propio código de acceso a la base de datos a un servidor separado no le proporciona nada en términos de seguridad. Supongo que podría dificultar la ejecución de la inyección SQL si hay una API que actúa como intermediario, pero eso no es garantía. Un código incorrecto es un código incorrecto, y si su código no es lo suficientemente competente para evitar la inyección de SQL en primer lugar, es probable que introduzca alguna falla en la API que aún podría permitirlo.

En resumen, hay mérito en agregar una capa de API, pero la seguridad no es parte de eso. De hecho, las API presentan sus propios problemas de seguridad independientes que deberá tener en cuenta. En otras palabras, puede asegurar una aplicación monolítica que acceda a la base de datos directamente y puede asegurar una que acceda a una API, pero el mero hecho de agregar una API no lo protege de alguna manera.

0
Chris Pratt 16 oct. 2018 a las 13:15