Este es un problema común en el desarrollo de aplicaciones de base de datos, con algunas soluciones válidas.
Primero, solo para decirlo, una sola cuenta SQL para la aplicación, con permisos para hacer cualquier cosa que el programa sea capaz de hacer, es mala. Doblemente malo cuando las credenciales de esta cuenta están codificadas en su aplicación para permitir la conexión. La razón por la cual es exactamente la razón por la que postulas; alguien podría ingresar las credenciales en una consola de SQL y ejecutar delete * from User para eliminar tu sistema de seguridad.
La primera solución posible es no otorgar ningún derecho de CRUD a una cuenta que no sea de administrador, y por supuesto nunca codificar o dar una cuenta de administrador al software del cliente. En su lugar, los derechos de lectura pueden otorgarse con permisos SELECT en vistas y derechos C_UD a través de permisos EXECUTE en procedimientos almacenados. Esta es una solución antigua y ampliamente aceptada, y aún se utiliza a pesar de que las mejores prácticas para la mayoría de los idiomas y entornos ahora fomentan otros patrones.
La segunda solución es similar en teoría pero diferente en implementación; implementar un punto final de la capa de servicio que defina las posibles operaciones de datos. Esta es la nueva mejor práctica, especialmente para situaciones que involucran el uso "anónimo" en redes públicas (servicios web). En lugar de que el cliente se conecte a la base de datos, el cliente establece un canal de servicio al punto final y, desde ese punto, solo puede llamar a los métodos que la capa de servicio permite, y también se le puede solicitar que pase datos de autenticación, como un token, para hacer cualquier cambio. llamada de datos que no sea el inicio de sesión inicial.
Las desventajas de ambos enfoques anteriores son que probablemente tendrá que hacer cambios profundos en el acceso a los datos del lado del cliente para llamar a procedimientos almacenados o métodos de servicio en lugar de operaciones directas basadas en tablas. Ahora también tiene lógica de negocios en el lado del servidor e incluso en la capa de datos, en relación con garantizar que los usuarios solo puedan hacer lo que deben y no intenten hacer lo que no deberían. Por último, por necesidad, reduce el alcance de las operaciones de recuperación de datos válidas al exponer métodos de acceso específicos, lo que es un paso atrás en el diseño DAL para la mayoría de los lenguajes modernos como .NET y Java (que tienen ORM como Hibernate y Entity Framework para proporcionar consultas enriquecidas). habilidad sin "cuerdas mágicas").
La última solución requiere la menor implementación pero puede ser más vulnerable; la cuenta de usuario codificada en el cliente tiene los permisos mínimos posibles necesarios para verificar las credenciales de un usuario (lo ideal es que se le otorguen derechos de EJECUCIÓN sobre un solo procedimiento almacenado "PerformLogin"). Como parte de la autenticación del usuario, después de verificar las credenciales, la rutina devolverá las credenciales de SQL de un usuario de la base de datos que tenga los permisos relacionados con los datos relacionados con lo que la cuenta de usuario autenticado puede hacer. El software cliente luego se vuelve a conectar a la base de datos después de la autenticación con las credenciales proporcionadas. La ventaja sobre otras soluciones es que solo se requieren cambios menores en su capa de persistencia (y una reconexión después de que la autenticación sea exitosa) para implementarlo en su sistema actual de una conexión de base de datos directa y operaciones de tabla, en lugar de cambios más profundos en la forma en que obtiene los datos. Invocando procs almacenados o un servicio.
Las desventajas son que los usuarios de SQL disponibles a través de la autenticación tienen que representar secciones transversales útiles de la funcionalidad, generalmente prestando la estructura general más hacia "niveles" de permisos de usuario en lugar de un esquema más modular "a la carta". Los medios para mitigar esto (como la creación dinámica y la configuración de permisos en un usuario después de la autenticación) suelen ser sus propios gusanos de gusano desde un punto de vista de seguridad. Sin embargo, necesitará muchos usuarios "incorporados", uno para cada nivel, para que este proceso de conexión de dos pasos tenga mucho valor real (si el Usuario Johnny tiene el nivel de usuario más bajo, pero solo con la autenticación obtiene un valor cercano). administrador de la cuenta de usuario de SQL para el resto de su sesión, su cliente ahora es la única capa de seguridad y, como hemos discutido, se puede omitir fácilmente). Por último, incluso con cuentas de usuario de SQL bien adaptadas, los permisos necesarios pueden ser bastante amplios; Los derechos de ACTUALIZACIÓN en una tabla son necesarios para que el cliente actualice un registro, pero el atacante puede usarlos maliciosamente desde una consola para eliminarlos a todos. Las otras soluciones limitan muy específicamente las operaciones de datos permitidas a ambos enfoques.