Cuando se diseña una base de datos de SQL Server, es crucial implementar una capa de base de datos segura para proteger datos sensibles. En este artículo, discutiremos las mejores prácticas para diseñar y arquitecturar una capa de base de datos segura con múltiples niveles de acceso.

Comprendiendo los niveles de acceso

Consideremos un ejemplo de una aplicación que realiza un seguimiento de préstamos. En este escenario, existen tres niveles diferentes de acceso:

1. Gerente del Departamento de Préstamos: Puede ver y modificar cualquier préstamo.
2. Oficial de Préstamos: Solo puede ver y modificar sus propios préstamos.
3. Auditor Financiero: Puede ver todos los préstamos, pero no puede modificarlos.

Estos niveles de acceso son comunes en muchas aplicaciones. La forma en que se controlan estos niveles de acceso depende principalmente de cómo se autentica la aplicación.

La aplicación se conecta como una cuenta de servicio o inicio de sesión único

Si la aplicación se conecta como un inicio de sesión único, SQL Server no puede manejar múltiples niveles de acceso basados únicamente en el inicio de sesión. En este caso, la aplicación debe manejar los diferentes niveles de acceso dentro del código de la aplicación misma o pasar más información a SQL Server.

La forma más sencilla de pasar la información requerida a SQL Server es mediante el uso de procedimientos almacenados y funciones con parámetros. Por ejemplo, en nuestra aplicación de seguimiento de préstamos, podemos crear un procedimiento almacenado llamado “ObtenerPrestamo” que acepte el ID del préstamo y el usuario como parámetros:

CREATE PROC ObtenerPrestamo @IDPrestamo int, @Usuario varchar(50)
...

Al pasar la información del usuario como parámetro al procedimiento almacenado, podemos controlar los niveles de acceso dentro de la base de datos.

Sin embargo, si está adaptando una aplicación existente o utilizando consultas directas, puede utilizar la función SET CONTEXT_INFO. Esta función le permite establecer una variable similar a una sesión en SQL Server, que se puede utilizar dentro de la conexión. Puede establecer la información de contexto utilizando el siguiente código:

DECLARE @Contexto varbinary(128);
SET @Contexto = CONVERT(varbinary(128), 'John Doe');
SET CONTEXT_INFO @Contexto;

Para recuperar la información de contexto, debe convertirla explícitamente a un formato legible:

SELECT CONVERT(varchar, CONTEXT_INFO());

El uso de SET CONTEXT_INFO puede ser útil al implementar múltiples niveles de seguridad en una aplicación existente que utiliza procedimientos almacenados.

La aplicación se conecta como el usuario

Si la aplicación se conecta como el usuario, el enfoque recomendado es crear roles de base de datos correspondientes a los niveles de acceso y hacer que los usuarios sean miembros de esos roles. Esto se puede lograr creando una tabla RolNegocio y una tabla PertenenciaRol. La seguridad puede basarse en estos roles.

Para recuperar la información del usuario dentro del contexto de la base de datos, puede utilizar las funciones CURRENT_USER o USER_NAME().

Diferente acceso de usuario fuera de la aplicación

En algunos casos, la aplicación puede conectarse como el usuario, pero si el usuario se conecta desde fuera de la aplicación, debería tener un nivel de acceso diferente. En este escenario, la solución recomendada es utilizar roles de aplicación.

Para implementar roles de aplicación, debe:

1. Establecer permisos mínimos para el usuario asumiendo que provienen de fuera de la aplicación.
2. Crear roles de aplicación apropiados con diferentes niveles de acceso.
3. Llamar al procedimiento almacenado sp_setapprole para establecer el rol de aplicación dentro de la aplicación.

Sin embargo, es importante tener en cuenta que solo se puede establecer un rol de aplicación a la vez. Si un usuario necesita múltiples niveles de acceso, la aplicación debe manejar el cambio entre roles, lo que puede ser una tarea compleja. Además, administrar y almacenar contraseñas de forma segura para roles de aplicación puede ser un desafío.

Teniendo en cuenta estos desafíos, los roles de aplicación pueden no ser la solución más frecuentemente elegida para administrar múltiples niveles de acceso.

Conclusión

Asegurar los niveles de acceso a la base de datos de SQL Server es crucial para proteger datos sensibles. Al comprender los diferentes escenarios e implementar las técnicas adecuadas, puede asegurarse de que su base de datos sea segura y solo accesible para usuarios autorizados.