SQL Server es un sistema potente y robusto que ofrece varias configuraciones de seguridad y mejores prácticas para garantizar la seguridad de sus datos. Sin embargo, es importante comprender las posibles vulnerabilidades que pueden surgir cuando no se siguen estas medidas de seguridad. En este artículo, exploraremos algunos escenarios comunes donde la configuración de seguridad puede llevar a problemas inesperados.

Caso 1: Usuario de la base de datos con privilegio db_securityadmin que obtiene el privilegio db_owner en la base de datos

En este caso, examinaremos cómo un usuario con privilegio db_securityadmin puede elevar sus privilegios para convertirse en miembro del rol db_owner. Consideremos un escenario donde un usuario llamado John tiene el privilegio db_securityadmin en una base de datos llamada DB1. John puede obtener el privilegio de ser miembro de db_owner siguiendo un proceso sencillo:

use DB1
create role TestRole; --primero crear un nuevo rol
grant control on database::db1 to [TestRole]; --conceder el máximo permiso a este nuevo rol
alter role [TestRole] add member [John]; --agregar [John] a este nuevo rol

-- ahora [John] puede realizar DML/DDL en cualquier objeto de la base de datos
-- como crear/popular/seleccionar/eliminar una tabla
create table dbo.table_john (id int)
insert into dbo.table_john (id) values (1), (2);
select * from dbo.table_john;
drop table dbo.table_john;

Al crear un nuevo rol, conceder permisos de control a ese rol y agregar a John al rol, John obtiene casi todos los privilegios dentro de DB1. Esto resalta la importancia de administrar cuidadosamente los privilegios de los usuarios para evitar el acceso no autorizado y posibles violaciones de seguridad.

Caso 2: Configuración de confianza de la base de datos = 1

En este caso, exploraremos cómo un usuario de una base de datos puede adquirir la propiedad de otra base de datos si la configuración de confianza está habilitada. Consideremos un escenario donde John es miembro de db_owner en DB1 y Mary es miembro de db_owner en DB2. Si DB1 tiene habilitada la configuración de confianza, John puede convertirse en miembro de db_owner en DB2. Esto se puede demostrar mediante los siguientes pasos:

alter database DB1 set trustworthy on;

Al habilitar la configuración de confianza, John puede suplantar a Mary y obtener los mismos privilegios que un miembro de db_owner en DB2. Esto resalta la importancia de administrar cuidadosamente la configuración de confianza y asegurarse de que solo esté habilitada cuando sea necesario.

Caso 3: Un inicio de sesión con privilegio SecurityAdmin puede obtener el privilegio SysAdmin

En este caso, examinaremos cómo un inicio de sesión con privilegio SecurityAdmin puede elevar sus privilegios para obtener privilegios de SysAdmin. El rol SecurityAdmin es un rol importante en SQL Server y es crucial comprender los riesgos potenciales asociados con él. Consideremos un escenario donde un inicio de sesión llamado John tiene membresía en SecurityAdmin:

use master;
drop login [John];
create login [John] with password='HolaMundo!', check_policy;
-- agregar al rol fijo del servidor [securityadmin]
alter server role securityadmin add member [John];

Al agregar a John al rol SecurityAdmin, obtiene acceso a los privilegios de SysAdmin. Esto significa que John puede realizar acciones como crear/eliminar bases de datos, configurar ajustes del servidor e incluso apagar la instancia de SQL Server. Es importante considerar cuidadosamente las implicaciones de otorgar privilegios de SecurityAdmin e implementar medidas adecuadas de auditoría para detectar cualquier posible abuso de estos privilegios.

Conclusión

Comprender las posibles vulnerabilidades en la configuración de seguridad de SQL Server es crucial para mantener un entorno de base de datos seguro. Al ser conscientes de estas vulnerabilidades, los administradores de bases de datos pueden tomar decisiones informadas y adoptar enfoques de mitigación necesarios para proteger sus datos. Es importante seguir las mejores prácticas, revisar y actualizar regularmente la configuración de seguridad e implementar medidas de auditoría para garantizar la integridad y confidencialidad de sus datos.

Nota: Los ejemplos proporcionados en este artículo fueron probados en SQL Server 2016, pero también deberían ser aplicables a SQL Server 2008 y versiones posteriores.