Como envio de log para configurar a segurança para o SQL Server

Traduções deste artigo Traduções deste artigo
ID do artigo: 321247 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Este artigo fornece informações sobre como configurar a segurança para o envio de log. Há várias questões a serem considerados quando você estiver configurando a segurança para o envio desse intervalo da conta de inicialização para o SQL Server compartilhar permissões para o compartilhamento de rede onde residem os backups de log de transação de log do SQL Server. Eles estão descritos neste artigo.

Conta de inicialização do SQL Server e SQL Server Agent Services no log remessa servidores

Conta de domínio

Se você colocou o SQL Server em um domínio, a Microsoft recomenda que você usar uma conta de domínio para iniciar serviços do SQL Server. Você deve usar uma conta de domínio se você pretende configurar o SQL Server para ser executado como um servidor virtual em clusters do Windows. Uma conta de domínio fornece o benefício de manutenção mínimo no caso de alterações de senha. No entanto, talvez não seja possível iniciar SQL em uma conta de domínio se o SQL Server reside em um servidor que está em um grupo de trabalho.

Conta de rede local

Você pode usar o SQL Server para iniciar em uma conta de rede criado localmente. Na situação onde não há acesso de rede necessário por um processo do SQL Server, que é o caso se você tiver configurado o SQL Server para usar o envio de log, você poderá usar segurança de passagem de rede. Com segurança de passagem, todos os computadores que serão acessados pelo 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 do SQL Server solicita recursos do segundo computador, segurança de rede tradicional é ignorada se a mesma conta (sob a qual o serviço solicitante do SQL Server é iniciado) existir com a mesma senha. Como tempo a conta no segundo computador é configurada com permissão suficiente para executar a tarefa que é solicitada, chamando o SQL Server, a tarefa será bem-sucedida.

Conta do sistema local

Você também pode configurar o SQL Server para iniciar a conta sistema local. Modificar a senha da conta LocalSystem pode resultar em falha de alguns serviços são fundamentais para estabilidade do sistema. Essa conta é local no computador onde ele reside, que significa que o contexto de segurança que usa serviços do SQL Server é local. Conforme mencionado na seção de conta de rede local, você não pode usar segurança de passagem de rede ao iniciar o SQL Server sob a conta do sistema local porque as senhas para a conta LocalSystem em computadores diferentes são diferentes. O início do SQL Server com essa conta quando acesso aos recursos de rede é necessário provavelmente resultará na conclusão de tarefas sem êxito.

Para obter informações sobre os direitos mínimos necessários para uma conta de rede Iniciar e executar serviços SQL Server e SQL Server Agent com êxito, consulte o tópico a seguir nos manuais online do SQL Server:
Setting up Windows Service Accounts

Noções básicas sobre o modelo de segurança do SQL Server

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

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

Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
240872INF: Como resolver problemas de permissão quando um banco de dados é movido

Configuração de envio de log

Requisitos de segurança

compartilhamento de backup

Configure o compartilhamento de rede que é configurado para armazenar os backups de log de transação ter permissões de leitura/alteração para a conta sob a qual SQL Server estiverem iniciando serviços (no servidor secundário que está configurado para envio de log).

O compartilhamento de rede está configurado para armazenar os backups de log de transação, deve ser configurado para ter permissões de leitura/alteração para a conta sob a qual SQL Server estiverem iniciando serviços, no servidor secundário configurado para envio de log. Este compartilhamento é acessado pelo trabalho de cópia no servidor secundário para copiar os backups de log de transação para a pasta local no respectivo servidor secundário. Em seguida, o trabalho de carga carrega esses backups da pasta local.

entre o envio de log do domínio

Se computadores que estão executando o SQL Server são colocados em um ambiente de vários domínios, a Microsoft recomenda que você configure confianças bidirecionais entre todos os domínios que estão envolvidos no envio de log. No entanto, se você não pode estabelecer relações de confiança entre domínios, você pode usar segurança de passagem de rede para envio de log. Consulte a seção deste artigo descreve a opção de inicialização LocalSystem conta de rede para serviços relacionados ao SQL Server.

Selecionar modo de autenticação para conectar ao servidor do Monitor

Você pode selecionar autenticação ou a autenticação do SQL (por servidores primário e secundário) para se conectar ao servidor de monitor e para atualizar as tabelas de monitor. Você pode selecionar isso tanto durante a configuração de envio de log ou depois que você tiver configurado o envio de log e é funcional. Por padrão, o SQL Server usa autenticação do Windows; no entanto, se você selecionar a autenticação do SQL, um novo SQL logon log_shipping_monitor_probe é criada em primária, secundária e servidores de monitor se um não existe. Se você selecionar a autenticação do SQL para essa finalidade, configure o SQL Server para usar a opção de autenticação SQL e 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, você pode acessar este banco de dados no estado somente leitura. Ao restaurar o banco de dados secundário nesse modo, isso poderá fornecer um meio pelo qual executar relatórios off-line, assim, o descarregamento parte do trabalho do sistema de produção. No entanto, para o banco de dados em modo de espera suportar a funcionalidade somente leitura, talvez você precise aplicar as mesmas configurações de segurança no servidor secundário. Como o banco de dados está no estado de espera, não é possível até mesmo fazer quaisquer modificações para fins de configuração de segurança. Nesse caso, você precisará criar todos os logins do SQL Server com os mesmos valores de SID no servidor secundário. Logons do Windows automaticamente mantém os mesmos SIDs porque o GUID do Windows é globalmente exclusivo, mesmo ao usar vários domínios.

Para obter informações adicionais sobre como criar logons do SQL com o mesmo SID em servidores diferentes, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
303722Como conceder acesso para logons de SQL em um banco de dados de espera quando "convidado" usuário está desativado

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

O procedimento de alteração da função para envio de log envolve promover um servidor secundário para assumir como primário. Você pode fazer isso com ou sem o servidor primário que está sendo on-line. Como parte da alteração de função, existem até quatro procedimentos armazenados que são executados. Um desses procedimentos armazenados, sp_resolve_logins , ajuda a corrigir os valores de SID para logons que residem no banco de dados em espera apenas antes que ele está disponível para uso como o banco de dados principal.

Como parte desse procedimento armazenado, um arquivo .BCP da tabela syslogins do primeiro servidor primário for carregado em uma tabela temporária. Em seguida, é comparado com cada logon que está presente nesta tabela temporária à tabela de syslogins no banco de dados MASTER do servidor secundário e a tabela de sysusers de banco de dados secundário. Para cada login na tabela temporária que tenha um logon com o mesmo nome na tabela syslogins e mesmo SID que na tabela sysusers do banco de dados secundário, o SID é corrigido (no banco de dados secundário) usando sp_change_users_login para coincidir com aquele que está na tabela syslogins.

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 de DTS de logons de transferência (que é explicado nos manuais online do SQL Server tópico, "Como configurar e executar envio alteração da função de log".
  • Você deve fornecer um arquivo .BCP da tabela syslogins do servidor primário. Este arquivo deve ser atual porque um arquivo desatualizado pode resultar em sp_resolve_logins Falha ao corrigir os logons.
Você deve atender três condições a seguir antes de sp_resolve_logins realmente pode corrigir os logons no banco de dados secundário:
  1. O nome de logon do arquivo da tabela syslogins .BCP deve corresponder ao nome da tabela syslogins do servidor primário.
  2. O valor SID deve corresponder entre o logon o arquivo .bcp e a tabela sysusers no banco de dados secundário
  3. O valor SID do banco de dados secundário deve ser diferente do valor de SID na tabela syslogins no banco de dados MASTER no servidor secundário.
Se você criar logins do SQL Server, conforme descrito em Q303722, não é necessário executar esse procedimento armazenado porque todos os logons são já estar presente com o mesmo valor de SID na tabela syslogins (no banco de dados MASTER no servidor secundário) e a tabela de sysusers (no banco de dados secundário).

Perguntas freqüentes

pergunta : O envio de log propagar alterações relacionadas à segurança para um servidor secundário automaticamente?

resposta : Sim. Como todas as alterações às tabelas do sistema são operações registradas, esses são propagadas por meio de para o servidor secundário (ou servidores) automaticamente.

pergunta : pode você tem dois logons no secundário servidor com o mesmo SID? Preciso isso porque Estou usando o mesmo computador SQL Server para manter vários bancos de dados em modo de espera de vários servidores.

resposta : não. Modelo de segurança do SQL Server não permite ter dois logons com o mesmo SID. Se houver um conflito no SID durante o uso de envio com vários servidores de log, a única maneira para corrigir isso é descartar o logon em conflito no servidor primário e então criá-lo com um SID que não existe no servidor secundário.
Para informações adicionais sobre o envio de alteração da função de log, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
314515INF: Envio de log - SQL Server 2000 - perguntas freqüentes

Propriedades

ID do artigo: 321247 - Última revisão: quarta-feira, 21 de dezembro de 2005 - Revisão: 3.5
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Palavras-chave: 
kbmt kbhowtomaster KB321247 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 321247

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com