Introducción
Hoy quisiera hablar de Seguridad de Acceso en Microsoft SQL Server. Este es un tema que merece mucho la atención, ya que es común que se otorguen derechos de acceso a la base de datos sin privilegios o qué se otorguen privilegios adicionales que no son adecuados para las funciones que se desean. Aquí es importante indicar que la autenticación (permiso para uso del servidor y bases de datos de Microsoft SQL Server) es diferente a la autorización (privilegios para llevar a cabo las actividades). A continuación, veremos un poco más a detalle estos puntos.
Autenticación
Se sabe que Microsoft SQL Server cuenta con dos modos de autenticación:
Autenticación Windows - habilita la autenticación de Windows, este modo de autenticación es la recomendada.
Autenticación Mixta - habilita la autenticación de Windows y la autenticación de Microsoft SQL Server.
Puede observarse que la autenticación de Windows siempre se mantiene y no puede deshabilitarse. Cuando se usa esta autenticación, Microsoft SQL Server valida el nombre de cuenta y la contraseña se pasan a Windows, quien debe confirmarlo, esto es mucho mas seguro que el modo de autenticación de Microsoft SQL Server. La ventaja de esta autenticación es que pueden usarse grupos de Windows y crearse como inicios de sesión para permitir la autenticación de todos los integrantes de ese grupo, en lugar de una definición individual, esto ayuda a simplificar la administración de cuentas.
Por otro lado, la autenticación de Microsoft SQL Server, los inicios de sesión se crean en Microsoft SQL Server, que no se basan en una cuenta de Windows, así, el nombre de usuario y la contraseña se crean y almacenan usando Microsoft SQL Server. De esta forma, cada vez que se conecten deben usar sus credenciales (inicio de sesión y contraseña). Lo mas importante es que deben proporcionarse contraseñas fuertes y establecer la expiración de la contraseña, incluir la política de reforzamiento de contraseña y, cuando se crea el inicio de sesión, indicar que la contraseña debe cambiarse en el siguiente inicio de sesión. Como puede observarse, no se pueden generar grupos y por lo tanto puede resultar complicada la administración de los inicios de sesión.
Una vez que el usuario es autenticado, tendrá acceso a los servicios de Microsoft SQL Server y bases de datos contenidos en la instancia.
Autorización en servidor
Ahora bien, cada uno de los usuarios, hasta este momento identificado como inicio de sesión para SQL Server, que ya se han autenticado tendrán autorización o diferentes privilegios para el uso de los servicios del sistema dentro de Microsoft SQL Server, de esta forma, se han definido los roles de servidor, los cuales brindan la autorización, estos son:
Public - Cada uno de los inicios de sesión pertenece a este rol de servidor. Cuando a un principal no se le han otorgado o denegado permisos específicos sobre un objeto asegurable, el inicio de sesión hereda los permisos otorgados al rol público en ese objeto. Este rol no puede ser cambiado. No hay permisos a nivel de servidor inherentes en este rol, no obstante, los permisos VIEW ANY DATABASE and CONNECT están incluidos, aunque estos permisos pueden revocarse.
Sysadmin – los inicios de sesión que tienen este rol de servidor pueden realizar cualquier actividad en el servidor. Son los administradores del sistema, no tienen restricciones para llevar a cabo las funciones administrativas y de acceso a todos los objetos del servidor.
Securityadmin – Los inicios de sesión que tienen este rol de servidor pueden CONCEDER, DENEGAR y REVOCAR permisos a nivel de servidor o de base de datos si tienen acceso a la base de datos. Además, pueden restablecer contraseñas para inicios de sesión. Este rol puede tratarse como equivalente a sysadmin, en lo referente a los inicios de sesión.
Serveradmin - Los inicios de sesión que tiene este rol de servidor pueden cambiar las opciones de configuración de todo el servidor y apagar el servidor. Este role tiene los permisos requeridos para administrar el servidor, sin embargo, no tiene los permisos relacionados con los inicios de sesión o conexiones.
Setupadmin – Los inicios de sesión que tiene este rol de servidor pueden agregar y eliminar servidores vinculados mediante el uso de instrucciones Transact-SQL, esto solo podrá hacerlo a través comandos, no puede hacerse a través de SQL Server Management Studio.
Processadmin - Los inicios de sesión que tiene ese role pueden finalizar los procesos que se ejecutan en una instancia de Microsoft SQL Server.
Diskadmin – los inicios de sesión que tienen este rol de servidor pueden administrar archivos de disco.
Bulkadmin – los inicios de sesión que tienen este rol de servidor pueden ejecutar la instrucción BULK INSERT.
Dbcreator – los inicios de sesión que tienen este rol de servidor pueden crear, alterar, eliminar y restaurar cualquier base de datos. Tienen completo control de las bases de datos que crean.
Hasta la versión Microsoft SQL Server 2016, no podían generarse nuevos roles de servidor, y los anteriores roles fijos de servidor solo podían utilizarse, sin embargo, con la versión indicada, se hizo posible generar roles basado en los anteriores o bien indicando los permisos que se desean incluir, por ejemplo, podría crearse un rol de servidor denominado SubSysAdmin, que permita la administración de servidor y de seguridad, de esta forma se utiliza la siguiente instrucción:
--- Create new server role based on serveradmin
CREATE SERVER ROLE subsysadmin AUTHORIZATION serveradmin;
GO
--- Grant ALTER ANY LOGIN permission to subsysadmin server role
GRANT ALTER ANY LOGIN TO subsysadmin;
GO
Ahora bien, es usual que los usuarios de desarrollo soliciten acceso al servidor como sysadmin, dado que, según ellos, deben efectuar cargas masivas (bulk insert), cancelar procesos (processadmin) y obviamente administrar las bases de datos en desarrollo (dbcreator), y finalmente usar servidores enlazados (setupadmin), de esta forma es posible generar el rol de servidor denominado devadmin y podría ser creado de la siguiente forma:
--- Create new server role devadmin based on dbcreator
CREATE SERVER ROLE devadmin AUTHORIZATION dbcreator;
GO
--- Setup admin
--- Grant ALTER ANY LINKED SERVER permission to devadmin server role
GRANT ALTER ANY LINKED SERVER TO devadmin;
GO
--- Process admin
--- Grant ALTER SERVER STATE permission to devadmin server role
GRANT ALTER SERVER STATE TO devadmin;
GO
--- Grant ALTER ANY CONNECTION permission to devadmin server role
GRANT ALTER ANY CONNECTION TO devadmin;
GO
--- Bulk admin
--- Grant ADMINISTER BULK OPERATIONS permission to devadmin server role
GRANT ADMINISTER BULK OPERATIONS TO devadmin;
GO
Con este nuevo role de servidor, es posible brindar las características requeridas por los desarrolladores, y no se les otorgan los permisos de administrador de sistema (sysadmin). Por ejemplo, se puede crear al inicio de sesión devuser con autenticación de Microsoft SQL Server y asignarle el rol de servidor devadmin, de la siguiente manera:
--- Assign devadmin role server to devuser
EXEC sp_addsrvrolemember 'devuser', ‘devadmin’;
GO
Muy bien, pero ¿qué se puede hacer cuando se tiene una versión anterior a Microsoft SQL Server 2016? En este caso, es posible hacerlo concediendo los permisos requeridos. En este ejemplo usaremos un grupo de Windows que denominaremos WIN\Developers, en este caso asignaremos el rol fijo de servidor dbcreator como base, de la siguiente forma:
EXEC sp_addsrvrolemember 'WIN\Developers', ‘dbcreator’;
GO
--- Grant ALTER ANY LINKED SERVER permission to WIN\Developers login
GRANT ALTER ANY LINKED SERVER TO WIN\Developers;
GO
--- Process admin
--- Grant ALTER SERVER STATE permission to WIN\Developers login
GRANT ALTER SERVER STATE TO WIN\Developers;
GO
--- Grant ALTER ANY CONNECTION permission to WIN\Developers login
GRANT ALTER ANY CONNECTION TO WIN\Developers;
GO
--- Bulk admin
--- Grant ADMINISTER BULK OPERATIONS permission to WIN\Developers login
GRANT ADMINISTER BULK OPERATIONS TO WIN\Developers;
GO
Hasta este momento hemos hablado de las acciones que se pueden llevar a cabo por los inicios de sesión debido a los roles de servidor que se asignan, sin embargo, aun debemos indicar los usuarios en las bases de datos.
Autorización en base de datos
Es común que el mismo inicio de sesión de Microsoft SQL Server sea el mismo usuario de una base de datos, en la base de datos se deben crear usuarios, generalmente el usuario que lo crea es el dueño de la base de datos y se asigna automáticamente como usuario de la base de datos con el rol de base de datos identificado como dbo (database owner). Y ya que hablamos de los roles de base de datos, debemos indicar que se tienen los siguientes roles fijos de base de datos:
db_accessadmin – los usuarios que tienen este rol de base de datos pueden agregar o eliminar el acceso a la base de datos para inicios de sesión de Windows, grupos de Windows e inicios de sesión de Microsoft SQL Server.
db_backuoperator – los usuarios que tienen este rol de base de datos pueden hacer una copia de seguridad de la base de datos. Esto significa que únicamente pueden ejecutar la instrucción BACKUP DATABASE
db_datareader – los usuarios que tienen este rol de base de datos pueden leer todos los datos de todas las tablas de usuarios. Significa que pueden llevar a cabo consultas sobre todas las tablas, no pueden ejecutar un procedimiento almacenado que lleve a cabo consultas, ya que esto requiere otro tipo de permiso.
db_datawriter - los usuarios que tienen este rol de base de datos pueden agregar, eliminar o cambiar datos en todas las tablas de usuarios. Significa que pueden llevar a cabo modificaciones sobre todas las tablas, no pueden ejecutar un procedimiento almacenado que lleve a cabo modificaciones, ya que esto requiere otro tipo de permiso.
db_dlladmin - los usuarios de este rol de base de datos pueden ejecutar cualquier comando del lenguaje de definición de datos (DDL) en una base de datos. Esto significa que pueden llevar a cabo la creación, modificación y eliminación de objetos dentro de la base de datos.
db_denydatareader – los usuarios que tienen este rol de base de datos no pueden leer ningún dato en las tablas de usuario dentro de una base de datos.
db_denydatawriter – los usuarios que tienen este rol de base de datos no pueden agregar, modificar o eliminar ningún dato en las tablas de usuario dentro de una base de datos.
db_owner - los usuarios de este role de base de datos pueden realizar todas las actividades de configuración y mantenimiento en la base de datos, y también pueden colocar la base de datos en Microsoft SQL Server. Sin embargo, en el caso de un Azure SQL Database y Azure Synapse, algunas actividades requieren permisos adicionales.
db_securityadmin – los usuarios que tienen este rol de base de datos pueden modificar la membresía de roles solo para roles personalizados y administrar permisos. Pueden incluso potencialmente elevar sus privilegios y sus acciones deben ser monitoreadas.
Public - Los usuarios que tiene este rol de base de datos no tiene permisos de nivel de base de datos inherentes, sin embargo, algunos permisos de base de datos están presentes de forma predeterminada, los cuales pueden ser revocados.
Ahora bien, los anteriores son los roles fijos de base de datos, sin embargo, es posible crear roles específicos que permitan una mezcla de ellos. Por ejemplo, supongamos que se desea generar un rol de base de datos que permita la lectura y escritura en todas las tablas, pero además se desea la posibilidad de ejecutar procedimientos almacenados, definiremos el rol como generaluser. Para ello ejecutaremos las siguientes instrucciones:
--- Create database role generaluser based on db_datawriter
CREATE ROLE generaluser AUTHORIZATION db_datawriter;
GO
--- Grant SELECT (data reader) to generaluser
GRANT SELECT TO generaluser;
GO
--- Grant EXECUTE to generaluser
GRANT EXECUTE TO generaluser;
GO
A menudo el dueño de la base de datos desea otorgar privilegios de ejecución de comandos para la creación de objetos, sin necesidad de que los usuarios sean dueños, adicionales a los de lectura, escritura y ejecución de procedimientos, entonces se requiere el privilegio db_ddladmin. Suponga que este privilegio se requiere adicionalmente al de un usuario general, porque dentro de algunos procedimientos almacenados se generan tablas temporales, estas tablas requieren el uso de comandos relativos a la definición de datos, de esta forma creamos el role power_user, de la siguiente manera:
--- Create database role power_user based on db_ddladmin
CREATE ROLE power_user AUTHORIZATION db_ddladmin;
GO
--- Grant SELECT (data reader) to power_user
GRANT SELECT TO power_user;
GO
--- Grant DELETE-INSERT-UPDATE (data writer) to power_user
GRANT DELETE TO power_user;
GRANT INSERT TO power_user;
GRANT UPDATE TO power_user;
GO
--- Grant EXECUTE to power_user
GRANT EXECUTE TO power_user;
GO
Como se puede ver, es posible crear diversos privilegios a nivel de rol, para que un usuario pueda operar en la base de datos. Una vez que se ha creado el rol deseado, es posible otorgarlo a un usuario de la siguiente manera:
--- Add the user user1 to power_user role
ALTER ROLE power_user ADD MEMBER user1;
Conclusión
La seguridad en Microsoft SQL Server es una parte fundamental de las operaciones, si bien, en esta entrega solo he mencionado las referentes a los inicios de sesión y los roles que pueden establecerse a nivel servidor y los roles a nivel de base de datos que pueden asignarse a un usuario, existen algunos otros mecanismos y tecnologías que pueden ser utilizadas para garantizar la seguridad en el ambiente de Microsoft SQL Server, estos temas serán tratados más adelante.
No hay comentarios.:
Publicar un comentario