Administración de una base de datos parcialmente contenida
Mantener la configuración de la base de datos en la propia base de datos en lugar de en la master, permite que cada propietario tenga más control sobre su base de datos, sin necesidad de conceder permisos al administrador de la base de datos sysadmin.
Limitaciones
Las bases de datos parcialmente contenidas no permiten las siguientes características:
Utilizar la replicación, cambiar la captura de datos ni cambiar el seguimiento.
Procedimientos numerados.
Objetos vinculados al esquema que dependen de funciones integradas con cambios de intercalación
Cambio de enlace resultante de cambios de intercalación, incluidas referencias a objetos, columnas, símbolos o tipos.
Replicación, cambio de captura de datos y seguimiento de cambios.
Advertencia. Los procedimientos almacenados temporales están permitidos. Pero dado que los procedimientos almacenados temporales infringen el confinamiento, no se espera que sean compatibles con versiones futuras de la base de datos contenida.
Identificación de contención de la base de datos
Hay dos formas de identificar el estado de contención de la base de datos. Sys.dm_db_uncontained_entities es una vista que muestra todas las entidades potencialmente no contenidas en la base de datos. El evento database_uncontained_usage se produce cuando se identifica cualquier entidad no contenida real en tiempo de ejecución.
Esta vista muestra todas las entidades de la base de datos que tienen el potencial de no estar contenidas, como las que cruzan el límite de la base de datos. Esto incluye aquellas entidades de usuario que pueden utilizar objetos fuera del modelo de base de datos. Sin embargo, debido a que la contención de algunas entidades (por ejemplo, aquellas que utilizan SQL dinámico) no se puede determinar hasta el tiempo de ejecución, la vista puede mostrar algunas entidades que estén contenidas.
El evento XEvent de database_uncontained_usage
Este evento (XEvent) se dispara siempre que se identifica en tiempo de ejecución una entidad no contenida. Esto incluye entidades originadas en código de cliente. Este evento ocurrirá sólo para las entidades no contenidas reales. Sin embargo, el evento sólo se producirá en tiempo de ejecución. Por tanto, cualquier entidad de usuario no contenida que no se haya ejecutado no será identificada por este evento.
Buenas prácticas de seguridad con Bases de Datos contenidas
Las bases de datos contenidas están expuestas a algunas amenazas únicas que deben ser tenidas en cuenta y mitigadas. La mayoría de las amenazas están relacionadas con el proceso de autenticación USER WITH PASSWORD, que mueve el límite de autenticación desde el nivel del motor de base de datos hasta el nivel de base de datos.
Amenazas relacionadas con los usuarios
Los usuarios de una base de datos contenida con permisos ALTER ANY USER, como miembros de las funciones de base de datos db_owner y db_securityadmin, pueden conceder acceso a la base de datos sin el conocimiento o el permiso o el administrador de SQL Server. Conceder a los usuarios acceso a una base de datos contenida incrementa riesgo de ataque potencial contra la instancia de SQL Server. Los administradores deben tener en cuenta esta delegación de control de acceso y tener mucho cuidado al conceder a los usuarios de la base de datos contenida el permiso ALTER ANY USER. Todos los propietarios de bases de datos tienen el permiso ALTER ANY USUARIO. Los administradores de SQL Server deben auditar periódicamente a los usuarios de una base de datos contenida.
Acceso a otras bases de datos con la cuenta de invitado
Los propietarios y usuarios de bases de datos con permiso ALTER ANY USER pueden crear usuarios de bases de datos contenidas. Una vez un usuario se conecta a una base de datos contenida, puede acceder a otras bases de datos en el motor de base de datos, si las otras bases de datos tienen habilitada una cuenta de invitado Guest.
Creación de un usuario duplicado en otra base de datos
Algunas aplicaciones pueden requerir que un usuario tenga acceso a más de una base de datos. Para ello se pueden crear usuarios de bases de datos idénticos en cada base de datos contenida. Se puede utilizar la opción SID para crear un segundo usuario con contraseña. El siguiente ejemplo crea dos usuarios idénticos en dos bases de datos.
USE DB1;
GO
CREATE USER Pepe WITH PASSWORD = '<strong password>';
-- Return the SID of the user
SELECT SID FROM sys.database_principals WHERE name = 'Pepe';
-- Change to the second database
USE DB2;
GO
CREATE USER Pepe WITH PASSWORD = '<same password>', SID = <SID from DB1>;
GO
Para ejecutar una consulta entre bases de datos, es necesario marcar la opción TRUSTWORTHY en la base de datos de llamadas. Por ejemplo si el usuario (Pepe) definido anteriormente está en DB1, para ejecutar SELECT * FROM db2.dbo.Table1; Entonces debe estar activada para la base de datos DB1 la configuración TRUSTWORTHY. Es necesario ejecutar el siguiente código para activar la configuración de confianza TRUSTWORTHY.
ALTER BASE DE DATOS DB1 SET TRUSTWORTHY ON;
Creación de un usuario que duplica un inicio de sesión
Si se crea un usuario de una base de datos contenida con contraseña con el mismo nombre que un inicio de sesión de SQL Server y si el inicio de sesión de SQL Server se conecta especificando la base de datos contenida como el catálogo inicial, el inicio de sesión de SQL Server no podrá conectarse. La conexión se evaluará como el usuario de base de datos contenida con la contraseña principal de la base de datos contenida en vez de como un usuario basado en el inicio de sesión de SQL Server. Esto podría causar una denegación de servicio intencional o accidental para el inicio de sesión de SQL Server.
Como práctica recomendada, los miembros de la función fija de servidor sysadmin deben considerar la posibilidad de conectarse siempre sin utilizar la opción de catálogo inicial. Esto conecta el inicio de sesión a la base de datos master y evita cualquier intento de inicio de sesión no autorizado de un propietario de la base de datos. A continuación, el administrador puede cambiar a la base de datos contenida mediante la instrucción USE <base de datos>. También se puede establecer un inicio de sesión predeterminado de la base de datos contenida, que complete el inicio de sesión de master y, a continuación, transferir el inicio de sesión a la base de datos contenida.
Como práctica sugerida, no se deben crear usuarios de base de datos contenidas con contraseñas que tengan el mismo nombre que los inicios de sesión de SQL Server. Si existe una conexión duplicada, es mejor conectarse a la base de datos master sin especificar un catálogo inicial y, a continuación, ejecutar el comando USE para cambiar a la base de datos contenida.
Cuando hay bases de datos contenidas, los usuarios de bases de datos no contenidas deben conectarse al motor de base de datos sin utilizar un catálogo inicial o especificando el nombre de base de datos de una base de datos no contenida como el catálogo inicial. Esto evita la conexión a la base de datos contenida que está bajo control menos directo por los administradores del motor de base de datos.
Aumentar el acceso cambiando el estado de contención de una base de datos
Los inicios de sesión que tienen el permiso ALTER ANY DATABASE, tal como los miembros de la función de servidor fijo de dbcreator y los usuarios de una base de datos no contenida que tienen el permiso CONTROL DATABASE, como miembros del rol de base de datos fijo db_owner, pueden cambiar la configuración de una base de datos contenida. En el caso de que se cambie de NONE a PARTIAL o FULL, se puede conceder acceso de usuario creando usuarios de base de datos con contraseña. Esto puede proporcionar acceso sin el conocimiento o consentimiento del administrador. Para evitar que las bases de datos contengan las conexiones de los usuarios con contraseñas es necesario utilizar triggers de inicio de sesión para cancelar los intentos de inicio de sesión.
Adjuntar una base de datos contenida
Para adjuntar una base de datos contenida, un administrador debe dar a los usuarios no deseados acceso a la instancia del motor de base de datos. Un administrador preocupado por este riesgo puede poner la base de datos en modo RESTRICTED_USER, lo que impide la autenticación de usuarios con contraseña. Sólo los usuarios autorizados a través de inicios de sesión podrán acceder al motor de base de datos.
Los usuarios se crean utilizando los requisitos de contraseña en vigor en el momento de su creación y las contraseñas no se vuelven a verificar cuando se adjuntan a una base de datos. Al adjuntar una base de datos contenida a un sistema con una directiva de contraseñas más estricta, si la base de datos adjuntada contiene contraseñas débiles, el administrador podría permitir contraseñas que no cumplan la directiva de contraseñas actual en el motor de base de datos adjunto. Los administradores pueden evitar las contraseñas débiles obligando a que todas las contraseñas se restablezcan para la base de datos adjunta.
Políticas de password
Las contraseñas de una base de datos deben ser contraseñas seguras, pero no es posible protegerlas mediante políticas de contraseña sólidas. Es mejor utilizar la autenticación de Windows siempre que sea posible para aprovechar las políticas de contraseña más extensas disponibles desde Windows.
Autentificación Kerberos
Las contraseñas de usuario de las bases de datos no pueden utilizar la autenticación Kerberos. Por tanto siempre que sea posible hay que utilizar la autenticación de Windows para aprovechar las características de Windows como Kerberos.
Acceso al diccionario fuera de línea
Los hashes de contraseñas de los usuarios de base de datos con contraseñas se almacenan en la base de datos contenida. Cualquier persona con acceso a los archivos de base de datos podría realizar un ataque de diccionario contra los usuarios de base de datos con contraseñas en un sistema no auditado. Para mitigar esta amenaza, hay que restringir el acceso a los archivos de base de datos o solo permitir conexiones a bases de datos contenidas mediante la autenticación de Windows.
Migrar a una base de datos parcialmente contenida
Preparación para migrar una base de datos
Revisar los siguientes elementos para considerar la migración de una base de datos al modelo de base de datos parcialmente contenido.
Es necesario comprender el modelo de base de datos parcialmente contenido.
Es necesario comprender los riesgos exclusivos de las bases de datos parcialmente contenidas
Las bases de datos contenidas no admiten replicación, cambio de captura de datos o seguimiento de cambios. Es necesario confirmar que la base de datos no utiliza estas funciones.
Hay que revisar la lista de características que se modifican en la base de datos para convertirla en parcialmente contenidas.
Supervisar el objeto XEvent de database_uncontained_usage para ver cuándo se utilizan las entidades no contenidas.
Habilitar bases de datos contenidas
Antes de poder crear bases de datos contenidas estas, deben estar habilitadas en la instancia del motor de base de datos de SQL Server, Para habilitar las bases de datos contenidas. El siguiente ejemplo habilita bases de datos contenidas en la instancia del motor de base de datos de SQL Server.
sp_configure 'contained database authentication', 1;
GO
RECONFIGURE ;
GO
Habilitación de bases de datos contenidas utilizando Management Studio
Para habilitar bases de datos contenidas utilizando management studio es necesario:
Sobre el explorador de objetos, hacer clic con el botón secundario del ratón en el nombre del servidor y, a continuación, clic en Propiedades.
En la página Avanzado, en la sección Contención, establecer la opción Habilitar bases de datos contenidas en Verdadero.
Hacer clic en Aceptar.
Convertir una base de datos en una parcialmente contenida
Una base de datos se convierte en una base de datos contenida al cambiar la opción CONTAINMENT con management studio o bien a través de comandos de SQL.
El ejemplo siguiente convierte una base de datos denominada Contabilidad a una base de datos parcialmente contenida.
USE [master]
GO
ALTER DATABASE [Accounting] SET CONTAINMENT = PARTIAL
GO
Conversión de una base de datos parcialmente contenida mediante Management Studio
El ejemplo siguiente convierte una base de datos en una base de datos parcialmente contenida.
1. En Explorador de objetos, expanda Bases de datos, haga clic con el botón secundario en la base de datos para convertir y, a continuación, haga clic en Propiedades.
2. En la página Opciones, cambie la opción Tipo de contención a Parcial.
3. Haga clic en Aceptar.
Migración de usuarios a usuarios de bases de datos contenidas
El ejemplo siguiente migra a todos los usuarios que se basan en inicios de sesión de SQL Server a usuarios de bases de datos con contraseñas. El ejemplo excluye los inicios de sesión que no están habilitados. Debe ejecutarse sobre la base de datos contenida.
DECLARE @username sysname ;
DECLARE user_cursor CURSOR
FOR
SELECT dp.name
FROM sys.database_principals AS dp
JOIN sys.server_principals AS sp
ON dp.sid = sp.sid
WHERE dp.authentication_type = 1 AND sp.is_disabled = 0;
OPEN user_cursor
FETCH NEXT FROM user_cursor INTO @username
WHILE @@FETCH_STATUS = 0
BEGIN
EXECUTE sp_migrate_user_to_contained
@username = @username,
@rename = N'keep_name',
@disablelogin = N'disable_login';
FETCH NEXT FROM user_cursor INTO @username
END
CLOSE user_cursor ;
DEALLOCATE user_cursor ;
