Configuración de la seguridad para el trasvase de registros de SQL Server

Artículo
06/20/2023

En este artículo se describe cómo configurar la seguridad para SQL Server trasvase de registros y se proporciona información sobre el problema que puede producirse al configurar la seguridad para SQL Server trasvase de registros.

Versión del producto original: SQL Server
Número de KB original: 321247

Resumen

En este artículo se proporciona información sobre cómo configurar la seguridad para el trasvase de registros. Hay varios problemas que se deben tener en cuenta al configurar la seguridad para SQL Server trasvase de registros que van desde la cuenta de inicio para SQL Server hasta el uso compartido de red donde residen las copias de seguridad del registro de transacciones. Estos problemas se describen en este artículo.

Cuenta de dominio

Si ha colocado SQL Server en un dominio, Microsoft recomienda usar una cuenta de dominio para iniciar SQL Server servicios. Debe usar una cuenta de dominio si va a configurar SQL Server para que se ejecute como servidor virtual en Clústeres de Windows. Una cuenta de dominio proporciona la ventaja de un mantenimiento mínimo en caso de cambios de contraseña. Sin embargo, es posible que no pueda iniciar SQL en una cuenta de dominio si SQL Server reside en un servidor que se encuentra en un grupo de trabajo.

Cuenta de red local

Puede usar SQL Server para iniciarse en una cuenta de red creada localmente. En la situación en la que un proceso de SQL Server requiere acceso a la red, que es el caso si ha configurado SQL Server para usar el trasvase de registros, puede usar la seguridad de paso a través de red. Con la seguridad de paso a través, todas las máquinas a las que se accederá mediante SQL Server deben tener la misma cuenta de red con la misma contraseña y los permisos adecuados, configurada localmente. Además, cuando el proceso de SQL Server solicita recursos del segundo equipo, se omite la seguridad de red tradicional si existe la misma cuenta (con la que se inicia el servicio de SQL Server solicitante) con la misma contraseña. Siempre que la cuenta del segundo equipo esté configurada con suficiente permiso para llevar a cabo la tarea solicitada mediante una llamada a SQL Server, la tarea se realizará correctamente.

Cuenta del sistema local

También puede configurar SQL Server para que se inicie en la cuenta del sistema local. La modificación de la contraseña de la cuenta LocalSystem puede provocar el error de algunos servicios que son críticos para la estabilidad del sistema. Esta cuenta es local en el equipo donde reside, lo que significa que el contexto de seguridad que usa SQL Server servicios es local. Como se indica en la sección Cuenta de red local, no puede usar la seguridad de paso a través de red al iniciar SQL Server en la cuenta LocalSystem porque las contraseñas de la cuenta LocalSystem en equipos diferentes son diferentes. Es muy probable que el inicio de SQL Server en esta cuenta cuando se requiera acceso a los recursos de red produzca una finalización incorrecta de las tareas.

Para obtener información sobre los derechos mínimos necesarios para que una cuenta de red se inicie y ejecute correctamente SQL Server y Agente SQL Server servicios, consulte Configuración de cuentas de servicio de Windows.

Descripción del modelo de seguridad de SQL Server

Para comprender completamente las implicaciones de seguridad, es importante comprender el modelo de seguridad que Microsoft implementó en SQL Server 2000. Al crear un inicio de sesión, se agrega a la syslogins tabla de la base de datos MASTER. Para cada base de datos a la que se proporciona acceso a este inicio de sesión recién agregado, se agrega a la sysusers tabla de esa base de datos. La asignación entre syslogins tabla y sysusers tabla se encuentra en el campo SID.

Si una base de datos de usuario se mueve a otro servidor, los valores de SID se transfieren desde el servidor anterior. La seguridad de la base de datos se interrumpe cuando los inicios de sesión en el segundo servidor no se crean con los mismos valores de SID o si la seguridad está configurada incorrectamente debido a la falta de coincidencia de los valores de SID.

Para obtener más información, consulte Cómo resolver problemas de permisos al mover una base de datos entre servidores que ejecutan SQL Server.

Requisitos de seguridad

Recurso compartido de copia de seguridad

Configure el recurso compartido de red configurado para que contenga las copias de seguridad del registro de transacciones para que tenga permisos de lectura o cambio para la cuenta en la que se inician SQL Server servicios (en el servidor secundario configurado para el trasvase de registros).

El recurso compartido de red configurado para almacenar las copias de seguridad del registro de transacciones debe configurarse para tener permisos de lectura o cambio para la cuenta en la que se inician los servicios de SQL Server, en el servidor secundario configurado para el trasvase de registros. El trabajo Copiar en el servidor secundario tiene acceso a este recurso compartido para copiar las copias de seguridad del registro de transacciones en la carpeta local del servidor secundario correspondiente. A continuación, el trabajo cargar carga estas copias de seguridad desde la carpeta local.
Trasvase de registros entre dominios

Si los equipos que ejecutan SQL Server se colocan en un entorno de varios dominios, Microsoft recomienda configurar confianzas bidireccionales entre todos los dominios implicados en el trasvase de registros. Sin embargo, si no puede establecer confianzas entre dominios, puede usar la seguridad de paso a través de red para el trasvase de registros. Consulte la sección de este artículo que describe la opción de inicio de la cuenta de red LocalSystem para los servicios relacionados con SQL Server.
Selección del modo de autenticación para conectarse al servidor de supervisión

Puede seleccionar la autenticación de autenticación de Windows o SQL (por servidores principales y secundarios) para conectarse al servidor de supervisión y actualizar las tablas de supervisión. Puede seleccionarlo al configurar el trasvase de registros o después de configurar el trasvase de registros y que sea funcional. De forma predeterminada, SQL Server usa autenticación de Windows; sin embargo, si selecciona autenticación de SQL, se crea un nuevo log_shipping_monitor_probe de inicio de sesión de SQL en los servidores principal, secundario y de supervisión si no existe uno. Si selecciona Autenticación de SQL para este propósito, configure SQL Server para usar la opción SQL y autenticación de Windows.

Configuración de seguridad en el servidor secundario para bases de datos en espera

Si configura la base de datos secundaria en modo de espera, puede acceder a esta base de datos en estado de solo lectura. Al restaurar la base de datos secundaria en este modo, esto puede proporcionar un medio para ejecutar informes sin conexión, con lo que se descarga parte del trabajo del sistema de producción. Sin embargo, para que la base de datos en espera admita la funcionalidad de solo lectura, es posible que tenga que aplicar la misma configuración de seguridad en el servidor secundario. Dado que la base de datos está en estado de espera, ni siquiera puede realizar modificaciones con el fin de configurar la seguridad. En este caso, debe crear todos los inicios de sesión de SQL Server con los mismos valores de SID en el servidor secundario. Los inicios de sesión de Windows conservan automáticamente los mismos SID porque el GUID de Windows es globalmente único, incluso cuando se usan varios dominios.

Para obtener más información sobre cómo crear inicios de sesión de SQL con el mismo SID en diferentes servidores, vea Cómo conceder acceso a inicios de sesión SQL en una base de datos en espera cuando el invitado está deshabilitado en SQL Server.

Configuración de seguridad al realizar el cambio de rol

El procedimiento de cambio de rol para el trasvase de registros implica la promoción de un servidor secundario para que tome el control como principal. Puede hacerlo con o sin que el servidor principal esté en línea. Como parte del cambio de rol, hay hasta cuatro procedimientos almacenados que se ejecutan. Uno de estos procedimientos almacenados, sp_resolve_logins , ayuda a corregir los valores de SID de los inicios de sesión que residen en la base de datos en espera justo antes de que esté disponible para su uso como base de datos principal.

Como parte de este procedimiento almacenado, un .bcp archivo de la syslogins tabla del servidor principal anterior se carga en una tabla temporal. A continuación, cada inicio de sesión que está presente en esta tabla temporal se compara con la syslogins tabla de la base de datos MASTER del servidor secundario y la sysusers tabla de la base de datos secundaria. Para cada inicio de sesión de la tabla temporal que tiene un inicio de sesión con el mismo nombre en la syslogins tabla y el mismo SID que el de la sysusers tabla de la base de datos secundaria, el SID se corrige (en la base de datos secundaria) mediante sp_change_users_login para que coincida con el que se encuentra en la syslogins tabla.

La configuración de seguridad con este procedimiento almacenado requiere lo siguiente:

Los inicios de sesión de SQL ya deben crearse en el servidor secundario. Para ello, use la tarea Transferir inicios de sesión DTS que se explica en SQL Server tema de los Libros en pantalla: Configuración y realización del cambio del rol de trasvase de registros.
Debe proporcionar un .bcp archivo de la syslogins tabla desde el servidor principal. Este archivo debe estar actual porque un archivo obsoleto puede provocar sp_resolve_logins que no se corrija el inicio de sesión.

Debe cumplir las tres condiciones siguientes antes de sp_resolve_logins poder corregir realmente los inicios de sesión en la base de datos secundaria:

El nombre del inicio de sesión del .bcp archivo de la syslogins tabla debe coincidir con el nombre de la syslogins tabla del servidor principal.
El valor de SID debe coincidir entre el inicio de sesión del .bcp archivo y la sysusers tabla de la base de datos secundaria.
El valor de SID de la base de datos secundaria debe ser diferente del valor de SID de la syslogins tabla de la base de datos MASTER en el servidor secundario.

Si crea inicios de sesión SQL Server como se describe en Q303722, no es necesario ejecutar este procedimiento almacenado porque todos los inicios de sesión ya se presentan con el mismo valor SID en la tabla (en la syslogins base de datos MASTER en el servidor secundario) y la sysusers tabla (en la base de datos secundaria).

Preguntas más frecuentes

Pregunta: ¿Propaga automáticamente el trasvase de registros los cambios relacionados con la seguridad en un servidor secundario?

Respuesta: sí. Dado que todos los cambios en las tablas del sistema son operaciones registradas, se propagan automáticamente al servidor secundario (o servidores).
Pregunta: ¿Puede tener dos inicios de sesión en el servidor secundario con el mismo SID? Lo necesito porque estoy usando el mismo equipo SQL Server para mantener varias bases de datos en espera desde varios servidores.

Respuesta: No. SQL Server modelo de seguridad no permite tener dos inicios de sesión con el mismo SID. Si hay un conflicto en SID al usar el trasvase de registros con varios servidores, la única manera de corregir esto es quitar el inicio de sesión en conflicto en el servidor principal y, a continuación, crearlo con un SID que no exista en el servidor secundario.