Compartir a través de

Procedimientos recomendados de seguridad con bases de datos independientes

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 WITH PASSWORD proceso de autenticación, que mueve el límite de autenticación del nivel del motor de base de datos al nivel de base de datos.

Los usuarios en una base de datos contenida que tengan el ALTER ANY USER permiso, como los miembros de los roles de base de datos fijos db_owner y db_securityadmin, 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 independiente aumenta el posible área expuesta a ataques contra toda la instancia de SQL Server. Los administradores deben comprender esta delegación del control de acceso y tener mucho cuidado al conceder a los usuarios en la base de datos independiente el ALTER ANY USER permiso. Todos los propietarios de bases de datos tienen el ALTER ANY USER permiso . Los administradores de SQL Server deben auditar periódicamente a los usuarios de una base de datos independiente.

Acceso a otras bases de datos mediante la cuenta de invitado

Los propietarios de bases de datos y los usuarios de base de datos con el ALTER ANY USER permiso 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 acceder a otras bases de datos en el motor de base de datos, si las otras bases de datos han habilitado la cuenta de invitado .

Crear 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. Esto se puede hacer creando usuarios de base de datos independientes 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 TRUSTWORTHY opción 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; , la TRUSTWORTHY configuración debe estar activada para la base de datos DB1. Ejecute el código siguiente para establecer la TRUSTWORHTY configuración activada.

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Creación de un usuario que duplica un inicio de sesión

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

  • Como procedimiento recomendado, los miembros del rol fijo de servidor sysadmin deben considerar la posibilidad de conectarse siempre sin usar la opción de catálogo inicial. Esto conecta el inicio de sesión a la base de datos maestra y evita los intentos realizados por un propietario de la base de datos para usar el intento de inicio de sesión incorrecto. A continuación, el administrador puede cambiar a la base de datos contenida mediante la USE<instrucción database>. También puede establecer la base de datos predeterminada del inicio de sesión en la base de datos independiente, que completa el inicio de sesión en master y, a continuación, transfiere el inicio de sesión a la base de datos independiente.

  • Como procedimiento recomendado, no cree usuarios de base de datos independientes con contraseñas que tengan el mismo nombre que los inicios de sesión de SQL Server.

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

  • Cuando hay bases de datos contenidas, los usuarios de bases de datos no contenidas deben conectarse al Motor de base de datos sin usar un catálogo inicial o especificar el nombre de la base de datos no contenida como catálogo inicial. Esto evita la conexión a la base de datos independiente, que está bajo un control menos directo por parte de 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 ALTER ANY DATABASE permiso, como los miembros del rol fijo de servidor dbcreator, y los usuarios de una base de datos no contenida que tienen el CONTROL DATABASE permiso, como los miembros del rol fijo de base de datos db_owner, pueden cambiar 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 base de datos independientes con contraseñas. Esto podría proporcionar acceso sin el conocimiento ni el consentimiento de los administradores de SQL Server. Para evitar que las bases de datos queden contenidas, configure la opción Motor de base de datos a 0. Para evitar conexiones por parte de usuarios de bases de datos independientes con contraseñas en bases de datos independientes seleccionadas, use desencadenadores de inicio de sesión para cancelar los intentos de inicio de sesión por parte de usuarios de base de datos independientes con contraseñas.

Adjuntar una base de datos independiente

Al adjuntar una base de datos independiente, un administrador podría conceder 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 línea en RESTRICTED_USER modo, lo que impide la autenticación de usuarios de bases de datos independientes con contraseñas. Solo los principales autorizados mediante login podrán acceder al motor de base de datos.

Los usuarios se crean con los requisitos de contraseña en vigor en el momento en que se crean y las contraseñas no se vuelven a comprobar cuando se adjunta una base de datos. Al adjuntar una base de datos independiente que permitía contraseñas débiles a un sistema con una directiva de contraseña 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 adjunto. Los administradores pueden evitar conservar las contraseñas no seguras al exigir que todas las contraseñas se restablezcan para la base de datos adjunta.

Directivas de contraseña

Las contraseñas de una base de datos pueden ser contraseñas seguras, pero no se pueden proteger mediante directivas de contraseña sólidas. Use la autenticación de Windows siempre que sea posible para aprovechar las directivas de contraseña más extensas disponibles en Windows.

Autenticación Kerberos

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

Ataque de diccionario sin conexión

Los hash de contraseña para los usuarios de base de datos independientes con contraseñas se almacenan en la base de datos independiente. Cualquier persona con acceso a los archivos de la base de datos podría realizar un ataque de diccionario contra los usuarios de la base de datos con contraseñas en un sistema no auditado. Para mitigar esta amenaza, restrinja el acceso a los archivos de base de datos o permita solo las conexiones a bases de datos independientes mediante la autenticación de Windows.

Escape de una base de datos contenida

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

Denegación de servicio a través de AUTO_CLOSE

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

Véase también

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