Configurar a segurança para SQL Server envio de logs

Artigo
06/20/2023

Este artigo descreve como configurar a segurança para SQL Server envio de logs e fornece informações sobre o problema que pode ocorrer quando você está configurando a segurança para SQL Server envio de logs.

Versão original do produto: SQL Server
Número de KB original: 321247

Resumo

Este artigo fornece informações sobre como configurar a segurança para o envio de logs. Há vários problemas a serem considerados quando você está configurando a segurança para SQL Server envio de logs que variam da conta de inicialização para SQL Server compartilhar permissões para o compartilhamento de rede onde residem os backups de log de transação. Esses problemas são descritos neste artigo.

Conta do domínio

Se você colocou SQL Server em um domínio, a Microsoft recomenda que você use uma conta de domínio para iniciar SQL Server serviços. Você deve usar uma conta de domínio se quiser configurar SQL Server para ser executado como um servidor virtual em Clustering do Windows. Uma conta de domínio fornece o benefício da manutenção mínima no caso de alterações de senha. No entanto, talvez você não possa iniciar o SQL em uma conta de domínio se SQL Server residir em um servidor que esteja em um grupo de trabalho.

Conta de rede local

Você pode usar SQL Server para iniciar em uma conta de rede criada localmente. Na situação em que há acesso à rede exigido por um processo de SQL Server, que é o caso se você tiver configurado SQL Server para usar o envio de log, você pode usar a segurança de passagem de rede. Com a segurança de passagem, todos os computadores que serão acessados por SQL Server devem ter a mesma conta de rede com a mesma senha e permissões apropriadas, configuradas localmente. Além disso, quando o processo SQL Server solicita recursos do segundo computador, a segurança de rede tradicional é ignorada se a mesma conta (na qual o serviço de SQL Server de solicitação for iniciado) existir com a mesma senha. Desde que a conta no segundo computador seja configurada com permissão suficiente para executar a tarefa solicitada chamando SQL Server, a tarefa será bem-sucedida.

Conta do sistema local

Você também pode configurar SQL Server para iniciar na conta do Sistema Local. Modificar a senha da conta LocalSystem pode resultar na falha de alguns serviços críticos para a estabilidade do sistema. Essa conta é local para o computador onde ela reside, o que significa que o contexto de segurança que SQL Server serviços usa é local. Conforme indicado na seção Conta de Rede Local, você não pode usar a segurança de passagem de rede ao iniciar SQL Server na conta LocalSystem porque as senhas da conta LocalSystem em computadores diferentes são diferentes. O início do SQL Server nessa conta quando o acesso a recursos de rede for necessário provavelmente resultará na conclusão malsucedida das tarefas.

Para obter informações sobre os direitos mínimos necessários para que uma conta de rede inicie e execute com êxito SQL Server e SQL Server Agent serviços, consulte Configurando contas de serviço do Windows.

Entender o modelo de segurança SQL Server

Para entender completamente as implicações de segurança, é importante entender o modelo de segurança implementado pela Microsoft em SQL Server 2000. Quando você cria um logon, ele é adicionado à syslogins tabela no banco de dados MASTER. Para cada banco de dados ao qual esse logon recém-adicionado tem acesso, ele é adicionado à sysusers tabela nesse banco de dados. O mapeamento entre syslogins tabela e sysusers tabela está no campo SID.

Se um banco de dados de usuário for movido para um servidor diferente, os valores SID serão transportados do servidor anterior. As quebras de segurança do banco de dados quando os logons no segundo servidor não são criados com os mesmos valores SID ou se a segurança estiver configurada incorretamente devido à incompatibilidade de valores SID.

Para obter mais informações, consulte Como resolve problemas de permissão ao mover um banco de dados entre servidores que estão executando SQL Server.

Requisitos de segurança

Compartilhamento de Backup

Configure o compartilhamento de rede configurado para manter os backups de log de transação para ter permissões de leitura/alteração para a conta em que SQL Server serviços (no servidor secundário configurado para envio de logs) estão começando.

O compartilhamento de rede configurado para manter os backups de log de transações deve ser configurado para ter permissões de leitura/alteração para a conta na qual SQL Server serviços, no servidor secundário configurado para envio de logs, estão começando. Esse compartilhamento é acessado pelo trabalho Copiar no servidor secundário para copiar os backups de log de transações para a pasta local no respectivo servidor secundário. Em seguida, o trabalho load carrega esses backups da pasta local.
Envio de log de domínio cruzado

Se os computadores que estão executando SQL Server forem colocados em um ambiente de vários domínios, a Microsoft recomenda que você configure confianças bidirecionais entre todos os domínios envolvidos no envio de logs. No entanto, se você não conseguir estabelecer confiança entre domínios, poderá usar a segurança de passagem de rede para envio de logs. Consulte a seção deste artigo que discute a opção de inicialização da conta de rede LocalSystem para serviços relacionados a SQL Server.
Selecionando o modo de autenticação para se conectar ao Monitor Server

Você pode selecionar autenticação do Windows ou autenticação SQL (por servidores primários e secundários) para se conectar ao servidor monitor e atualizar as tabelas de monitor. Você pode selecionar isso ao configurar o envio de logs ou depois de configurar o envio de logs e ele estiver funcional. Por padrão, SQL Server usa autenticação do Windows; no entanto, se você selecionar autenticação SQL, um novo log_shipping_monitor_probe de logon SQL será criado nos servidores primário, secundário e monitor se não existir. Se você selecionar a autenticação SQL para essa finalidade, configure SQL Server para usar a opção SQL e autenticação do Windows.

Configuração de segurança no servidor secundário para bancos de dados em espera

Se você configurar o banco de dados secundário no modo de espera, poderá acessar esse banco de dados no estado somente leitura. Ao restaurar o banco de dados secundário nesse modo, isso pode fornecer um meio para executar relatórios offline, descarregando assim parte do trabalho do sistema de produção. No entanto, para que o banco de dados em espera dê suporte à funcionalidade somente leitura, talvez seja necessário aplicar as mesmas configurações de segurança no servidor secundário. Como o banco de dados está em estado de espera, você não pode sequer fazer modificações para fins de configuração de segurança. Nesse caso, você precisa criar todos os logons SQL Server com os mesmos valores SID no servidor secundário. Os logons do Windows mantêm automaticamente os mesmos SIDs porque o GUID do Windows é globalmente exclusivo, mesmo usando vários domínios.

Para obter mais informações sobre como criar logons SQL com o mesmo SID em servidores diferentes, confira Como conceder acesso a logons SQL em um banco de dados em espera quando o convidado estiver desabilitado no SQL Server.

Configuração de segurança ao executar a alteração de função

O procedimento de alteração de função para envio de log envolve promover um servidor secundário para assumir como o principal. Você pode fazer isso com ou sem que o servidor primário esteja online. Como parte da alteração de função, há até quatro procedimentos armazenados que são executados. Um desses procedimentos armazenados, , sp_resolve_logins ajuda a corrigir os valores sid para logons que residem no banco de dados em espera pouco antes de ser disponibilizado para uso como o banco de dados primário.

Como parte desse procedimento armazenado, um .bcp arquivo da syslogins tabela do antigo servidor primário é carregado em uma tabela temporária. Cada logon presente nesta tabela temporária é comparado à syslogins tabela no banco de dados MASTER do servidor secundário e à sysusers tabela do banco de dados secundário. Para cada logon na tabela temporária que tem um logon com o mesmo nome na tabela e o syslogins mesmo SID que o sysusers da tabela do banco de dados secundário, o SID é corrigido (no banco de dados secundário) usando sp_change_users_login para corresponder ao que está na syslogins tabela.

A configuração de segurança usando este procedimento armazenado requer o seguinte:

Logons SQL já devem ser criados no servidor secundário. Para fazer isso, use a tarefa Transfer Logins DTS que é explicada no tópico SQL Server Books Online: como configurar e executar a alteração da função de envio de log.
Você deve fornecer um .bcp arquivo da syslogins tabela do servidor primário. Esse arquivo deve estar atual porque um arquivo desatualizado pode resultar em falha na sp_resolve_logins correção dos logons.

Você deve atender às três condições a seguir antes sp_resolve_logins de poder realmente corrigir os logons no banco de dados secundário:

O nome do logon do .bcp arquivo da syslogins tabela deve corresponder ao nome na syslogins tabela do servidor primário.
O valor SID deve corresponder entre o logon do .bcp arquivo e a sysusers tabela no banco de dados secundário.
O valor sid do banco de dados secundário deve ser diferente do valor SID na syslogins tabela no banco de dados MASTER no servidor secundário.

Se você criar logons SQL Server conforme descrito em Q303722, ele não precisará executar esse procedimento armazenado porque todos os logons já foram apresentados com o mesmo valor SID na syslogins tabela (no banco de dados MASTER no servidor secundário) e na sysusers tabela (no banco de dados secundário).

Perguntas frequentes

Pergunta: o envio de logs propaga alterações relacionadas à segurança em um servidor secundário automaticamente?

Resposta: Sim. Como todas as alterações nas tabelas do sistema são operações registradas, elas são propagadas para o servidor secundário (ou servidores) automaticamente.
Pergunta: você pode ter dois logons no servidor secundário com o mesmo SID? Preciso disso porque estou usando o mesmo computador SQL Server para manter vários bancos de dados em espera de vários servidores.

Resposta: Não. SQL Server modelo de segurança não permite ter dois logons com o mesmo SID. Se houver um conflito no SID ao usar o envio de log com vários servidores, a única maneira de corrigir isso é remover o logon conflitante no servidor primário e, em seguida, criá-lo com um SID que não existe no servidor secundário.