Prácticas recomendadas de seguridad con bases de datos independientes

Se aplica a:SQL ServerAzure SQL Managed Instance

Las bases de datos independientes tienen algunas amenazas únicas que los administradores de Motor de base de datos de SQL Server deben comprender y mitigar. La mayoría de las amenazas están relacionadas con el USER proceso de autenticación WITH PASSWORD, que mueve el límite de autenticación del nivel de Motor de base de datos al nivel de base de datos.

Los usuarios de una base de datos contenida que tengan el permiso ALTER ANY USER, como los miembros de los roles fijos de base de datos db_owner y db_accessadmin, pueden conceder acceso a la base de datos sin el conocimiento ni el permiso del administrador de SQL Server. Conceder a los usuarios acceso a una base de datos contenida aumenta la posible superficie de ataque de toda la instancia de SQL Server. Los administradores deben comprender esta delegación de control de acceso y tener mucho cuidado al conceder a los usuarios en la base de datos independiente el permiso ALTER ANY USER . Todos los propietarios de la base de datos tienen el permiso ALTER ANY USER . Los administradores de SQL Server deben auditar periódicamente a los usuarios de una base de datos independiente.

Acceder a otras bases de datos mediante la cuenta Invitado

Los propietarios de bases de datos y los usuarios de base de datos con el permiso ALTER ANY USER pueden crear usuarios de base de datos independientes. Después de conectarse a una base de datos independiente en una instancia de SQL Server, un usuario de base de datos independiente puede obtener acceso a otras bases de datos en el motor de base de datos, si en estas bases de datos se ha habilitado la cuenta invitado.

Crear un usuario duplicado en otra base de datos

Algunas aplicaciones pueden solicitar que un usuario tenga acceso a más de una base de datos. Esto se puede hacer creando usuarios de base de datos contenida idénticos en cada base de datos. Use la opción SID al crear el segundo usuario con contraseña. En el ejemplo siguiente se crean dos usuarios idénticos en dos bases de datos.

USE DB1;  
GO  
CREATE USER Carlo WITH PASSWORD = '<strong password>';   
-- Return the SID of the user  
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';  
  
-- Change to the second database  
USE DB2;  
GO  
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;  
GO

Para ejecutar una consulta entre bases de datos, debe establecer la opción TRUSTWORTHY en la base de datos que realiza la llamada. Por ejemplo, si el usuario (Carlo) definido anteriormente está en DB1, para ejecutar SELECT * FROM db2.dbo.Table1; el valor de TRUSTWORTHY debe estar activado para la base de datos DB1. Ejecute el código siguiente para activar la configuración TRUSTWORTHY .

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Crear un usuario que duplica un inicio de sesión

Si se crea un usuario contenido de base de datos con contraseña con el mismo nombre que un inicio de sesión de SQL Server, y si este se conecta especificando la base de datos contenida como catálogo inicial, ese inicio de sesión de SQL Server no podrá conectarse. La conexión se evaluará como el usuario de base de datos independiente con entidad de seguridad con contraseña en la base de datos independiente en vez de como usuario basado en el inicio de sesión de SQL Server. Esto podría ocasionar una denegación de servicio intencional o accidental para el inicio de sesión de SQL Server.

  • Como práctica recomendada, los miembros del rol fijo de servidor sysadmin siempre deben considerar realizar la conexión sin usar la opción de catálogo inicial. De esta forma, se conecta el inicio de sesión a la base de datos maestra y se evita que un propietario de base de datos use incorrectamente el intento de inicio de sesión. Después, el administrador puede cambiar a la base de datos independiente con la instrucción USE<baseDeDatos>. Además, puede establecer la base de datos predeterminada del inicio de sesión en la base de datos contenida, lo que completa el inicio de sesión en master y, a continuación, transfiere el inicio de sesión a la base de datos contenida.

  • Como práctica recomendada, no cree usuarios de bases de datos independientes con contraseñas que tengan el mismo nombre que los inicios de sesión de SQL Server.

  • Si existe el inicio de sesión duplicado, conéctese a la base de datos maestra sin especificar ningún catálogo inicial y, a continuación, ejecute el comando USE para cambiar a la base de datos independiente.

  • Cuando estén presentes bases de datos independientes, los usuarios de base de datos que no sean bases de datos independientes deben conectarse al motor de base de datos sin usar ningún catálogo inicial ni especificar el nombre de una base de datos dependiente como el catálogo inicial. De esta forma, se evita conectarse a la base de datos contenida, que está bajo un control menos directo de los administradores del Motor de base de datos.

Incrementar el acceso cambiando el estado de contención de una base de datos

Los usuarios que dispongan del permiso ALTER ANY DATABASE, como los miembros del rol fijo de servidor dbcreator, y los usuarios de una base de datos no contenida que tengan el permiso CONTROL DATABASE, como los miembros del rol fijo de base de datos db_owner, pueden modificar la configuración de contención de una base de datos. Si la configuración de contención de una base de datos se cambia de NONE a PARTIAL o FULL, se puede conceder acceso de usuario mediante la creación de usuarios de bases de datos independientes con contraseñas. De esta forma, se podría proporcionar acceso sin el conocimiento ni el consentimiento de los administradores de SQL Server. Para evitar que las bases de datos sean independientes, establezca el valor de la opción Autenticación de la base de datos independiente de Motor de base de datos en 0. Para evitar que se conecten los usuarios de bases de datos independientes con contraseñas en las bases de datos independientes seleccionadas, use desencadenadores de inicio de sesión para cancelar los intentos de inicios de sesión de los usuarios de bases de datos independientes con contraseñas.

Adjuntar una base de datos contenedora

Si se adjunta una base de datos independiente, un administrador podría dar acceso a usuarios no deseados a la instancia del motor de base de datos. Un administrador al que le preocupe este riesgo puede poner en línea la base de datos en el modo RESTRICTED_USER , que evita la autenticación de usuarios de bases de datos independientes con contraseñas. Solo las entidades de seguridad autorizadas mediante inicios de sesión podrán acceder al motor de base de datos.

Los usuarios se crean con los requisitos de contraseña en vigor en el momento de su creación y las contraseñas no se vuelven a comprobar cuando se adjunte una base de datos. Si se adjunta una base de datos independiente que permitía contraseñas no seguras en un sistema con una directiva de contraseñas más estricta, un administrador podría permitir contraseñas que no cumplan la directiva de contraseñas actual en el motor de base de datos que se adjunta. Los administradores pueden evitar la conservación de contraseñas no seguras exigiendo que todas las contraseñas se restablezcan para la base de datos adjunta.

Directivas de contraseñas

Se puede requerir que las contraseñas de una base de datos sean contraseñas seguras, pero no se pueden proteger mediante directivas de contraseñas sólidas. Use la autenticación de Windows siempre que sea posible para aprovechar las directivas de contraseñas más amplias disponibles de Windows.

Autenticación Kerberos

Los usuarios de bases de datos independientes con contraseñas no pueden usar la autenticación Kerberos. Siempre que sea posible, use la autenticación de Windows para aprovechar características de Windows como Kerberos.

Ataque de diccionario offline

Los valores hash de contraseña de los usuarios de bases de datos independientes se almacenan en la base de datos independiente. Cualquiera que tuviera acceso a los archivos de la base de datos podría llevar a cabo un ataque de diccionario contra los usuarios contenidos en la base de datos con contraseña en un sistema no auditado. Para mitigar esta amenaza, restrinja el acceso a los archivos de base de datos o solo permita conexiones a bases de datos independientes mediante la autenticación de Windows.

Establecer secuencias de escape en una base de datos independiente

Si una base de datos está parcialmente contenida, los administradores de SQL Server deben auditar periódicamente las capacidades de los usuarios y los módulos de las bases de datos parcialmente contenidas.

Denegación de servicio mediante AUTO_CLOSE

No configure bases de datos independientes para que se cierren automáticamente. Si se cierra la base de datos, su apertura para autenticar un usuario consume recursos adicionales y podría contribuir a un ataque de denegación de servicio.

Consulte también

Bases de datos contenidas
Migrar a una base de datos parcialmente independiente

  • Last updated on