Usuarios de base de datos independiente: hacer que la base de datos sea portátil

Se aplica a: SQL Server Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics

Use los usuarios de base de datos independiente para autenticar conexiones SQL Server y SQL Database en el nivel de base de datos. Una base de datos independiente es una base de datos aislada de otras bases de datos y de la instancia de SQL Server/ SQL Database (y la base de datos maestra) que hospeda la base de datos. SQL Server admite usuarios de base de datos independientes para la autenticación de Windows y SQL Server . Al usar SQL Database, se combinan las reglas de usuarios de la base de datos independiente con las de firewall de nivel de base de datos. En este tema se revisan las diferencias y ventajas de utilizar el modelo de base de datos independiente en comparación con el modelo de inicio de sesión o usuario tradicionales y las reglas de firewall de Windows o de nivel de servidor. Es posible que la lógica de escenarios específicos, de manejabilidad o de software empresarial todavía pueda necesitar el uso de reglas de inicio de sesión o usuario tradicionales y de firewall de nivel de servidor.

Nota

Como Microsoft desarrolla el servicio SQL Database y avanza hacia contrato de nivel de servicio superiores garantizados, es posible que se le pida que cambie a las normas de modelo de usuario de base de datos independiente y las de firewall de ámbito de base de datos para lograr el contrato de nivel de servicio de mayor disponibilidad y mayores tasas de inicio de sesión máximas para una base de datos determinada. Microsoft le recomienda que considere la posibilidad de realizar dichos cambios hoy mismo.

Inicio de sesión tradicional y modelo de usuario

En el modelo tradicional de conexión, los usuarios de Windows o los miembros de los grupos de Windows se conectan a la Motor de base de datos al proporcionar las credenciales de usuario o grupo autenticadas por Windows. O bien, puede proporcionar un nombre y la contraseña y conectarse mediante autenticación de SQL Server . En ambos casos, la base de datos maestra debe tener un inicio de sesión que coincida con las credenciales de conexión. Después de que la Motor de base de datos confirme las credenciales de autenticación de Windows o autentica las credenciales de autenticación de SQL Server , la conexión normalmente intenta conectarse a una base de datos de usuario. Para conectarse a una base de datos de usuario, el inicio de sesión debe asignarse a (es decir, asociado a) un usuario de base de datos de la base de datos de usuario. También es posible que la cadena de conexión especifique la conexión a una base de datos que es opcional en SQL Server pero obligatoria en SQL Database.

El principio importante es que tanto el inicio de sesión (en la base de datos maestra) como el usuario (en la base de datos de usuario) deben existir y estar relacionados entre sí. Esto significa que la conexión a la base de datos de usuario tiene una dependencia en el inicio de sesión en la base de datos maestra y esto limita la capacidad de la base de datos de moverse a un servidor host de SQL Server o Azure SQL Database diferente. Además, si por cualquier motivo no hay una conexión a la base de datos maestra disponible (por ejemplo, una conmutación por error está en curso), aumentará el tiempo total de conexión o es posible que se agote el tiempo de espera de la conexión. En consecuencia, esto puede reducir la escalabilidad de la conexión.

Modelo de usuario de base de datos independiente

En el modelo de usuario de base de datos independiente, el inicio de sesión en la base de datos maestra no está presente. En su lugar, el proceso de autenticación se produce en la base de datos de usuario y el usuario de base de datos de la base de datos de usuario no tiene asociado ningún inicio de sesión en la base de datos maestra. El modelo de usuario de base de datos independiente admite tanto la autenticación de Windows como la autenticación de SQL Server , y se puede usar tanto en SQL Server como en SQL Database. Para conectarse como un usuario de base de datos independiente, la cadena de conexión siempre debe contener un parámetro para la base de datos de usuario de modo que la Motor de base de datos sepa qué base de datos es responsable de la administración del proceso de autenticación. La actividad del usuario de base de datos independiente se limita a la autenticación de base de datos, por lo que al conectarse como un usuario de base de datos independiente, la cuenta de usuario de base de datos debe crearse independientemente en cada base de datos que el usuario necesitará. Para cambiar las bases de datos, los usuarios de SQL Database deben crear una nueva conexión. Los usuarios de base de datos independiente de SQL Server pueden cambiar bases de datos si hay un usuario idéntico en otra base de datos.

Azure: SQL Database y Azure Synapse Analytics admiten las identidades de Azure Active Directory como usuarios de base de datos independiente. SQL Database admite usuarios de base de datos independientes que usan autenticación de SQL Server , pero Azure Synapse Analytics no. Para más información, consulte Usar la autenticación de Azure Active Directory para autenticación con SQL. Al utilizar la autenticación de Active Directory de Azure, las conexiones de SSMS se pueden realizar mediante autenticación universal de Active Directory. Los administradores pueden configurar la autenticación universal para requerir Multi-Factor Authentication, que comprueba la identidad mediante una llamada de teléfono, un mensaje de texto, una tarjeta inteligente con pin o una notificación de aplicación móvil. Para obtener más información, vea Compatibilidad de SSMS con Azure AD MFA con SQL Database y Azure Synapse Analytics.

Para SQL Database y Azure Synapse Analytics, dado que el nombre de la base de datos siempre se requiere en la cadena de conexión, no se necesitan cambios en la cadena de conexión cuando se cambia desde el modelo tradicional al modelo de usuario de base de datos independiente. Para las conexiones de SQL Server , el nombre de la base de datos debe agregarse a la cadena de conexión si no está ya presente.

Importante

Cuando se usa el modelo tradicional, los roles de nivel de servidor y los permisos de nivel de servidor pueden limitar el acceso a todas las bases de datos. Al usar el modelo de base de datos independiente, los propietarios de la base de datos y los usuarios de la base de datos con el permiso ALTER ANY USER pueden conceder acceso a la base de datos. Esto reduce el control de acceso de inicios de sesión de servidor con privilegios altos y amplía el control de acceso para incluir los usuarios de la base de datos con privilegios altos.

Firewalls

SQL Server

Las reglas de Firewall de Windows se aplican a todas las conexiones y tienen el mismo efecto en los inicios de sesión (conexiones de modelo tradicional) y los usuarios de la base de datos independiente. Para obtener más información sobre el Firewall de Windows, consulte Configurar Firewall de Windows para el acceso al motor de base de datos.

SQL Database Firewalls

SQL Database permite reglas de: firewall independientes para las conexiones de nivel de servidor (inicios de sesión) y las conexiones de nivel de base de datos (usuarios de base de datos independiente). Al conectarse a una base de datos de usuario, primero se comprueban las reglas de firewall de base de datos. Si no hay ninguna regla que permita el acceso a la base de datos, se comprueban las reglas de firewall de nivel de servidor, lo que requiere acceso a la base de datos maestra del servidor SQL Database. Las reglas de firewall de nivel de base de datos combinadas con los usuarios de la base de datos independiente pueden eliminar la necesidad de acceder a la base de datos maestra del servidor durante la conexión, lo que puede mejorar la escalabilidad de la conexión.

Para obtener más información sobre las reglas de firewall de SQL Database , vea los temas siguientes:

• Firewall de Azure SQL Database
• Cómo: Configurar los valores del firewall (Azure SQL Database)
• sp_set_firewall_rule (Azure SQL Database)
• sp_set_database_firewall_rule (Azure SQL Database)

Diferencias de sintaxis

Modelo tradicional	Modelo de usuario de base de datos independiente
Cuando se conecta a la base de datos maestra: CREATE LOGIN login_name WITH PASSWORD = 'strong_password'; Después, cuando se conecta a una base de datos de usuario: CREATE USER 'user_name' FOR LOGIN 'login_name';	Cuando se conecta a una base de datos de usuario: CREATE USER user_name WITH PASSWORD = 'strong_password';

Modelo tradicional	Modelo de usuario de base de datos independiente
Para cambiar la contraseña, en el contexto de la base de datos maestra: ALTER LOGIN login_name WITH PASSWORD = 'strong_password';	Para cambiar la contraseña, en el contexto de la base de datos de usuario: ALTER USER user_name WITH PASSWORD = 'strong_password';

de SQL DB

Azure SQL Managed Instance se comporta como SQL Server local en el contexto de las bases de datos independientes. Asegúrese de cambiar el contexto de la base de datos de la base de datos maestra a la de usuario al crear el usuario contenido. Además, no debería haber ninguna conexión activa con la base de datos de usuario al establecer la opción de contención.

Por ejemplo:

Advertencia

Antes de ejecutar el siguiente script, asegúrese de que no haya otras conexiones activas en la base de datos de Instancia administrada. El script puede afectar a otros procesos que se están ejecutando en la base de datos.

Use MASTER;
GO 

ALTER DATABASE Test
SET RESTRICTED_USER
WITH ROLLBACK IMMEDIATE;

ALTER DATABASE Test
SET containment=partial;

ALTER DATABASE Test
SET MULTI_USER;

USE Test;  
GO 

CREATE USER Carlo  
WITH PASSWORD='Enterpwdhere*'  

SELECT containment_desc FROM sys.databases
WHERE name='Test'

Observaciones

• En SQL Server, los usuarios de la base de datos independiente deben estar habilitados para la instancia de SQL Server. Para más información, consulte la opción de configuración del servidor de autenticación de base de datos independiente.
• Los usuarios de base de datos independiente y los inicios de sesión con nombres no superpuestos pueden coexistir en las aplicaciones.
• Si hay un inicio de sesión en la base de datos maestra con el nombre name1 y crea un usuario de base de datos independiente denominado name1, cuando se proporcione un nombre de base de datos en la cadena de conexión, el contexto del usuario de base de datos tendrá prioridad sobre el contexto de inicio de sesión al conectarse a la base de datos. Es decir, los usuarios de base de datos independiente tienen prioridad sobre los inicios de sesión con el mismo nombre.
• En SQL Database , el nombre de un usuario de base de datos independiente no puede ser el mismo que el nombre de la cuenta de administrador del servidor.
• La cuenta de administrador del servidor de SQL Database nunca puede ser un usuario de base de datos independiente. El administrador del servidor tiene los permisos necesarios para crear y administrar los usuarios de la base de datos independiente. El administrador del servidor puede conceder permisos a los usuarios de base de datos independiente en bases de datos de usuario.
• Ya que los usuarios de base de datos independiente son entidades de seguridad de nivel de base de datos, deberá crear usuarios de base de datos independiente en cada base de datos en la que los utilizará. La identidad se limita a la base de datos y es independiente en todos los aspectos de un usuario con el mismo nombre y la misma contraseña de otra base de datos del mismo servidor.
• Use las mismas contraseñas seguras que usaría normalmente para los inicios de sesión.

Consulte también

Bases de datos independientes
Prácticas recomendadas de seguridad con bases de datos independientes
CREATE USER (Transact-SQL)
Conexión a SQL Database mediante autenticación de Azure Active Directory