Una de las principales labores que tenemos como administradores de bases de datos es la gestión de su seguridad y, para eso, es imprescindible la gestión de inicios de sesión (Logins) y usuarios (Users). Puede parecer que son lo mismo pero no lo son y, entender sus particularidades y diferencias va a ser clave para nuestra labor. Además, a estos conceptos tenemos que sumarle uno nuevo, los usuarios independientes, que se han implementado en las soluciones SQL en Azure y que harán que cambiemos nuestra forma de actuar en muchos casos.
Logins o Inicios de Sesión, primera capa de seguridad
Los inicios de sesión en SQL Server son entidades de seguridad a nivel de servidor que permite a los usuarios autenticarse y acceder al servidor SQL. Los inicios de sesión pueden ser de dos tipos: inicios de sesión basados en Windows y inicios de sesión de SQL Server.
Los logins de Windows aprovechan las cuentas de usuario o grupos de seguridad definidos en Active Directory o en el equipo local, permitiendo una autenticación integrada y centralizada. Por otro lado, los logins de SQL Server son gestionados directamente por SQL Server y, para crearlos, tendremos que proporcionar un nombre de inicio de sesión y una contraseña específicos para SQL Server.
Creación de logins
Para crear logins usaremos la sintaxis CREATE LOGIN de la siguiente manera:
a) Para un login de Windows usaremos:
CREATE LOGIN MiDominio\MiUsuarioDeWindows FROM WINDOWSb) Para un login de SQL usaremos:
CREATE LOGIN MiLogin WITH PASSWORD=’MiContraseñ@SuperSegurísima1234’Usuarios en SQL Server, segunda capa de seguridad
A diferencia de los inicios de sesión, los usuarios en SQL Server existen a nivel de base de datos. Mientras que el inicio de sesión proporciona acceso a la instancia del servidor, el usuario define qué recursos dentro de una base de datos específica puede acceder ese inicio de sesión.
Los usuarios se utilizan para gestionar permisos dentro de una base de datos, controlando el acceso a tablas, procedimientos almacenados y otros objetos. Cada usuario de base de datos puede estar asociado a un inicio de sesión o no, pero un inicio de sesión puede estar asociado a múltiples usuarios en diferentes bases de datos. Cuando un usuario no está asociado a un inicio de sesión decimos que está huérfano.
Creación de users
Crear un usuario en SQL Server se hace, posicionado en la base de datos, con la sintaxis CREATE USER y obligatoriamente implica especificar el inicio de sesión al que estará asociado. Por ejemplo:
USE MiBaseDeDatos
GO
CREATE USER MiUsuario FOR LOGIN MiLogin;El Concepto de SID ¿Qué es y por qué es clave para la seguridad?
El SID (Security Identifier) es un identificador único que SQL Server asigna a cada inicio de sesión y usuario. Este identificador es crucial porque es lo que realmente utiliza SQL Server para vincular inicios de sesión con usuarios y para gestionar los permisos. Aunque los nombres de los inicios de sesión y usuarios pueden ser los mismos en diferentes bases de datos o instancias, el SID es lo que realmente distingue a cada entidad de seguridad.
Cuando estamos usando logins de windows siempre usaremos el SID que tenga ese usuario en el Directorio Activo (lo sé es lioso pero es que a nivel windows si se llama usuario y nosotros en SQL lo usamos como login).
Problemas conocidos con los SID
Como habrás imaginado, cada SID es único para cada inicio de sesión y, aunque en dos servidores tengamos un login con el mismo nombre, al mover las bases de datos de uno a otro no van a coincidir esos SID y se quedará huérfano el usuario en la base de datos. Lo explico más en detalle, los permisos a nivel de base de datos asignados a un usuario o a nivel de instancia a un login, están realmente vinculados a su SID, no a su nombre. Esto hace que, durante migraciones o en configuraciones de alta disponibilidad, como los Grupos de Disponibilidad (AG) en SQL Server, sea fundamental que los SIDs de los inicios de sesión y usuarios coincidan entre las diferentes instancias y bases de datos.
Si los SIDs no coinciden, los usuarios no podrán acceder a los recursos correspondientes porque SQL Server no los reconocerá correctamente. Por suerte eso se puede solucionar copiando el SID del login en uno de los servidores y recreando el login en el resto con ese mismo SID como te expliqué aquí en un artículo o aquí en video
Usuarios Independientes o Contenidos, simplificando la seguridad
Tanto en SQL Server a partir de SQL 2012 como en las soluciones SQL en Azure existe un modelo de entidades de seguridad que se basa en usuarios sin necesidad de login. A esto se le llama usuarios de base de datos independientes o contenidos. Estos usuarios no están vinculados a un inicio de sesión a nivel de servidor, sino que existen exclusivamente dentro de una base de datos.
Tiene ciertos inconvenientes como que en la conexión siempre se debe especificar a qué base de datos te quieres conectar y si quieres cambiar de base de datos tienes que cerrar tu conexión actual y volver a conectar. Sin embargo en Azure SQL Database, donde “no hay servidor” y esto no es un problema, los usuarios independientes cobran relevancia. Si nos olvidamos de esta limitación, si no es importante para nosotros, las ventajas son indiscutibles, cada base de datos puede tener su propio conjunto de usuarios y permisos, independiente de otros recursos lo que hace que las bases de datos pueden moverse entre servidores o instancias sin necesidad de volver a crear o ajustar inicios de sesión a nivel de servidor.
Ventajas en Entornos de Replicación y Alta Disponibilidad
Los usuarios independientes son particularmente ventajosos en entornos con replicación y alta disponibilidad (HA). En configuraciones tradicionales, cada vez que replicamos o movemos una base de datos a otra instancia, debemos asegurarnos de que los inicios de sesión y sus SIDs coincidan en todas las instancias involucradas. Esto puede ser complicado y propenso a errores.
En entornos de Grupos de Disponibilidad (AG), se requiere un cuidadoso manejo de los inicios de sesión para asegurar que los usuarios puedan acceder a las bases de datos replicadas en diferentes nodos del AG. Debemos crear cada inicio de sesión manualmente en cada réplica secundaria, asegurando que los SIDs coincidan. Con usuarios independientes, este problema se simplifica enormemente. Dado que estos usuarios existen únicamente dentro de la base de datos y no dependen de un inicio de sesión a nivel de servidor, las preocupaciones sobre la coincidencia de SIDs se eliminan. Esto hace que la administración de permisos y accesos en entornos distribuidos sea más sencilla y menos propensa a errores.
Comparación con el Paradigma Tradicional
Comparado con el enfoque tradicional de SQL Server, los usuarios independientes proporcionan una mayor flexibilidad y facilidad de gestión en entornos distribuidos. En cambio, la capacidad de gestionar usuarios directamente dentro de cada base de datos, reduce la complejidad administrativa.
Por ejemplo, un usuario independiente se crea así:
USE MiBaseDeDatos
CREATE USER MiUsuarioIndependiente WITH PASSWORD = 'ContraseñaSegura';Mientras que según el enfoque tradicional sería:
USE master
CREATE LOGIN MiLogin WITH PASSWORD = 'ContraseñaSegura';
USE MiBaseDeDatos
CREATE USER MiUsuario FOR LOGIN MiLogin;Seguridad y buenas prácticas
Para asegurar nuestras instancias de SQL Server y las bases de datos asociadas, debemos seguir varias buenas prácticas. Lo primero y fundamental es seguir el principio de privilegios mínimos otorgando solo los permisos necesarios a cada usuario. Otra recomendación es seguir una política de contraseñas que asegure contraseñas fuertes y políticas de expiración y complejidad. Por último, os recomendaría crear auditorías para rastrear el acceso y las acciones de los usuarios.
Seguridad en Azure
En Azure, además de las prácticas anteriores, debemos considerar las herramientas y servicios adicionales que ofrece la plataforma.La integración con Microsoft Entra (antes llamado Azure Active Directory) para una gestión centralizada de identidades será un gran aliado. Al usar Microsoft Entra podremos implementar requisitos de segundo factor de autenticación (MFA) como por ejemplo requerir un código temporal enviado por SMS, llamada o una aplicación de autenticación además de la contraseña del usuario. También disponemos de servicios como Azure Key Vault para la gestión de claves y certificados. Y por supuesto, las alertas y monitorización avanzada utilizando Azure Security Center, Azure Monitor y Azure Insights para detectar y responder a amenazas de seguridad.
Conclusión
La gestión de inicios de sesión y usuarios en SQL Server es un aspecto fundamental de la administración de bases de datos, que garantiza la seguridad y el control de acceso a nuestros datos. Mientras que los inicios de sesión proporcionan acceso a la instancia del servidor, los usuarios dentro de las bases de datos gestionan el acceso a los recursos específicos. Con la evolución hacia entornos cloud, los usuarios independientes en Azure SQL Database ofrecen una mayor flexibilidad y facilitan la administración en escenarios distribuidos. Aprovechar las ventajas de los usuarios independientes en entornos de replicación y HA nos permite reducir la complejidad y mejorar la eficiencia administrativa.
Comprender estas diferencias y aplicar las mejores prácticas de seguridad nos permite aprovechar al máximo nuestras bases de datos SQL Server, ya sea en implementaciones tradicionales o en la nube.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
