Cuando se trata de administrar permisos en SQL Server, es importante entender la diferencia entre ser miembro del rol db_owner y ser propietario de la base de datos. En este artículo, exploraremos los efectos de tener dichos permisos y cómo pueden afectar la seguridad dentro de la base de datos.

Comencemos creando un inicio de sesión de muestra y una base de datos de muestra para probar:

CREATE LOGIN DatabaseOwner WITH PASSWORD = 'Alguna19Contraseña80Difícil!';
GO 

CREATE DATABASE TestDB;
GO 

ALTER AUTHORIZATION ON DATABASE::TestDB TO DatabaseOwner;
GO 

A continuación, crearemos un usuario dentro de la base de datos que sea miembro del rol db_owner:

USE TestDB;
GO 

CREATE USER InternalUser WITHOUT LOGIN;
GO 

EXEC sp_addrolemember @rolename = 'db_owner', @membername = 'InternalUser';
GO 

Ahora, creemos una tabla de muestra para hacer consultas. Tenga en cuenta que no estamos otorgando permisos explícitos. Por lo tanto, por ser propietario de la base de datos o miembro del rol db_owner, los principios de seguridad pueden acceder a la tabla:

CREATE TABLE dbo.SampleDatabase (SampleColumn INT);
GO 

Ahora, veamos la capacidad de cada escenario de seguridad:

-- Tenga en cuenta que no se otorgan permisos 
EXECUTE AS LOGIN = 'DatabaseOwner';
GO 

-- Ver quién está ingresando
SELECT USER_NAME();
GO 

SELECT SampleColumn FROM dbo.SampleDatabase;
GO

REVERT;
GO 

EXECUTE AS USER = 'InternalUser';
GO 

-- Ver quién está ingresando
SELECT USER_NAME();
GO 

SELECT SampleColumn FROM dbo.SampleDatabase;
GO

REVERT;
GO 

Como podemos ver, tanto el propietario de la base de datos como el miembro del rol db_owner tienen acceso a la tabla. Pero, ¿qué sucede si queremos bloquear el acceso?

Podemos intentar usar DENY en el propietario de la base de datos, pero generalmente se recomienda evitar poner explícitamente un permiso en un usuario. En su lugar, podemos usar un rol para manejar los permisos:

DENY SELECT ON dbo.SampleDatabase TO InternalUser;
GO 

CREATE ROLE DenyRole;
GO 

DENY SELECT ON dbo.SampleDatabase TO DenyRole;
REVOKE SELECT ON dbo.SampleDatabase TO InternalUser;
GO 

EXEC sp_addrolemember @rolename = 'DenyRole', @membername = 'InternalUser';
GO

Es importante tener en cuenta que asignar explícitamente un permiso o un rol al usuario dbo no funciona. El usuario dbo ignora efectivamente el DENY emitido al rol público. Este es el problema principal si una aplicación debe ser propietaria de la base de datos o crea la base de datos para que sea el propietario de forma predeterminada. Puede hacer cualquier cosa dentro de la base de datos y no hay un bloqueo efectivo a menos que se vuelva a diseñar la seguridad.

En conclusión, comprender la diferencia entre ser miembro del rol db_owner y ser propietario de la base de datos es crucial para administrar permisos en SQL Server. Si bien ambos escenarios brindan un amplio acceso dentro de la base de datos, es importante considerar cuidadosamente las implicaciones de seguridad y utilizar roles para manejar los permisos siempre que sea posible.