Common SQL Server Security Issues and Solutions

Artigo
10/26/2016

Segurança

Problemas de segurança de servidores SQL comuns e soluções

Paul S. Randal

Visão geral:

Físico e segurança de rede
Ataque de superfície, contas de serviço e privilégios mínimos
Inclusão de autenticação, autorização e SQL
Recuperação de desastres e auditoria

Conteúdo

Segurança física
Segurança de rede
Minimization superfície de ataque
Contas de serviço
Restringindo o uso de privilégios de administrador
Autenticação
Autorização
Inclusão de SQL
Recuperação de desastres
Auditoria
Resumo

Quem foi ao redor o setor de TI sabe que segurança é um tópico ativo.Afinal, dados da empresa são um dos ativos mais preciosa possui e proteger os dados é crítico.Como eu estava planejando que escrever para esse problema de segurança, eu tentei determinar qual recurso de segurança deve ter um artigo inteiro dedicado a ele.Mas, em seguida, iniciado para pensar sobre os números burgeoning de "DBAs involuntárias" (os profissionais de TI que inadvertidamente eólica up responsável por uma instância do SQL Server) e a resposta ótima tivemos que oPrincipais dicas para manutenção de banco de dados efetivasartigo de 2008 de agosto.Ele impressionou-me que o que deve fazer é escrever um artigo que aborda problemas comuns de segurança do SQL Server — um tipo de Introdução à segurança melhor para seus instâncias do SQL Server.

Um artigo que descreve todos os os problemas de segurança que você deve estar procurando em seria uma revista toda em si, portanto, eu canvassed meu colega MVPs do SQL Server (e minha esposa) para entrada de como a que deve incluir.Eu liquidadas em fornecer as principais áreas de segurança 10 ACREDITO que você deve se preocupar sobre se você não for um DBA savvy com segurança e, de repente, perceber que está responsável por uma instância do SQL Server e associados ao aplicativo.Lembrar que não é uma lista completa. Para cada problema, deu uma breve visão de geral do problema, conselhos sobre como atenuá-lo e um link para informações mais detalhadas.

Todos os links para livros online do são para as versões do SQL Server 2008, mas cada página de Web links para a versão do SQL Server 2005 também.Disposição até o artigo, fornecem links para o principais informes oficiais e seções de manuais online para a segurança para o SQL Server 2005 e o SQL Server 2008.

Segurança física

É imperativo que você apenas não considere segurança do SQL Server propriamente dito, mas todas as camadas que devem ser envolvidas para ir para SQL Server em primeiro lugar.Para esse conceito de segurança em camadas, chamado de "defesa em camadas," você não segura apenas uma camada, mas considere todo o sistema.

A consideração primeira mais óbvia é a segurança física do computador que executa o SQL Server — nessa camada, no entanto, geralmente é ignorada ou é o assunto da complacency.Eu não estou fazendo referência simplesmente para se o computador pode ser roubado ou não, mas também para o acesso físico a coisas como o sistema de armazenamento que hospeda os arquivos de banco de dados, as fitas de backup e os servidores que hospedam cópias redundantes do banco de dados.Somente às pessoas com uma necessidade real fisicamente tocar a esses objetos devem ter acesso a elas; qualquer pessoa que precisa de acesso temporário deve estar acompanhada e monitorada.

Uma consideração menos óbvia é a segurança das áreas de trabalho das pessoas que têm acesso de altamente privilegiado ao SQL Server.Se uma pessoa tem acesso sysadmin para o SQL Server, mas deixam sua área de trabalho Windows desbloqueada, em seguida, a segurança no mundo não vai para impedir que alguém movimentação após o sistema autônomo de potencialmente acessar dados confidenciais.Um problema mais traiçoeiro seria se alguém movimentado past e alterado alguns dados — por exemplo, um funcionário desonesto que sabe o esquema de banco de dados de recursos humanos e tenta alterar undetectably um salário.

Há um muito interessante TechNet white paper (incluindo um slide-baralho e webcasts), intitulado"Segurança física na Microsoft" que descreve como o Microsoft gerencia a segurança física de seus vários servidores.

Segurança de rede

Embora os servidores podem ser fisicamente inacessíveis, eles provavelmente estiver conectados a uma rede de algum tipo.Isso pode ter apenas uma isolado empresa LAN com não fora de conexões, ou pode ser uma conexão direta com a Internet.Não importa o que a situação, existem algumas coisas que você precise considerar (em inglês):

Verifique se o servidor do Windows tem segurança de rede adequada configurada.
Decidir quais protocolos de rede para permitir e desabilitar qualquer que não são necessários.
Certifique-se haja um conjunto de firewalls backup (como o Firewall do Windows) e configurá-lo para permitir acesso ao SQL Server (como mostrado naA Figura 1).
Optar por criptografar conexões com o SQL Server e configurar corretamente.
Se Kerberos for usados, registre um nome principal do servidor.Kerberos é um mecanismo de autenticação que underpins autenticação do Windows (que descrevo neste artigo), mas ele é mal compreendido.Uma explicação clara e concisa foram fornecida por Rob Greene, engenheiro de escalonamento de suporte, na postagem do blog"Kerberos para o administrador de ocupado." Eu recomendo check-out.
Decida se você deseja usar o serviço Navegador do SQL Server para ajudar os clientes localizar instâncias do SQL Server instaladas e decidir se deseja ocultar algumas instâncias.Ocultar uma instância significa aplicativos cliente e os usuários precisarão saber os detalhes de conexão da instância do SQL Server, mas impede que as pessoas trawling da rede para procurar por instâncias do SQL Server.

Figura 1 configurar o Firewall do Windows para permitir o acesso TCP para o SQL Server

Todas essas tarefas (e muito mais) são explicadas em SQL Server 2008 Books Online, iniciando com o tópicoConfiguração de rede do servidor. Há também uma seção boa emConfiguração de rede do cliente.

Minimization superfície de ataque

Os mais serviços e recursos que são habilitados, quanto mais houver para bandidos a ataques de área de superfície ou de superfície de ataque.O SQL Server 2005 levou o "desativado por padrão" estratégia — recursos com as implicações de segurança são desabilitados por padrão e são apenas habilitados por banco de dados quando necessário.(Esse processo de ativar e desativar serviços normalmente é chamado configuração da área de superfície.)

Um exemplo dos principais de um recurso que convém desativado é xp_cmdshell, que fornece uma maneira de executar comandos no host Windows sistema de dentro do contexto de uma instância do SQL Server.Se um comprometer intruso a instância do SQL Server e a conta de serviço do SQL Server possui elevados privilégios do Windows, xp_cmdshell podem ser usados para acessar o sistema Windows, também.

Há uma variedade de métodos de configuração de área de superfície.Tanto o SQL Server 2005 e o SQL Server 2008 oferecem suporte o SQL Server Configuration Manager para configurar serviços e protocolos de rede.Ambos também suportam o procedimento de sp_configure armazenado para configurar recursos do mecanismo de banco de dados e opções.Por exemplo, esse código desabilitará o recurso de xp_cmdshell:

-- To allow advanced options to be changed
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for -- advanced options
RECONFIGURE;
GO
-- To disable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 0;
GO
-- To update the currently configured value for this -- feature
RECONFIGURE;
GO

Os métodos gráficos de configurar opções de mecanismo de banco de dados e recursos são muito diferentes entre as duas versões. O SQL Server 2005 introduziu a ferramenta SQL Server superfície área configuração (SAC). Isso permite que você faça facilmente alterações. a Figura 2 , por exemplo, mostra como você pode desabilitar xp_cmdshell usando o SAC.

A Figura 2 xp_cmdshell desabilitar usando o SAC no SQL Server 2005

No SQL Server 2008, SAC foi removido completamente e a funcionalidade incorporadas pelo recurso de gerenciamento de com base em diretivas. Você pode encontrar mais informações sobre isso no tópico manuais online do SQL Server 2008" Administrando servidores usando o gerenciamento com base em diretiva." a Figura 3 ilustra criando uma condição para verificar que xp_cmdshell está desabilitado. Depois de configurado, as diretivas podem direcionar instâncias de SQL Server 2005 e o SQL Server 2008 e podem até mesmo ser "aplicadas," permitindo que você basicamente, altere a configuração com um clique.

A Figura 3 Criando uma condição de gerenciamento de diretiva-com base no SQL Server 2008

Contas de serviço

SQL Server é executado como um ou mais serviços no Windows, e cada serviço precisa ter uma conta do Windows que é usada para executar o serviço. A conta precisa ter acesso a vários recursos no sistema Windows (como a rede e vários diretórios de sistema de arquivo). A prática recomendada é para a conta tenha os privilégios menos possíveis necessários para permitir o SQL Server para funcionar corretamente. Isso faz parte do que é chamado o princípio de privilégio mínimo, que afirma que um sistema pode ser feito mais seguros, concedendo a um usuário ou processam apenas os privilégios necessários e nada mais.

Assim, uma conta de serviço do SQL Server não deve ser uma conta altamente privilegiado (, como sistema local ou o administrador local) porque se SQL Server for comprometido, há a possibilidade do sistema do Windows também ser comprometida. Os serviços normalmente são executados em uma conta interna chamada serviço de rede, mas se SQL Server exigir acesso aos outros recursos do domínio, uma nova conta de usuário de domínio deve ser criada com o mínimo de privilégios e recursos acessos necessários. O tópico manuais online do SQL Server 2008" Configurando contas de serviço do Windows"fornece uma lista abrangente de contas de serviço, privilégios necessários e recursos. Observe que se for necessário alterar uma conta de serviço (ou algo sobre ela), você deve sempre usar o SQL Server Configuration Manager para garantir que todas as alterações necessárias de configuração são feitas corretamente.

Restringindo o uso de privilégios de administrador

O logon de exposição a associação de segurança mais ou a função de servidor fixo sysadmin tiver, o potencial de mais houver para uma violação de segurança — ou um acidente. Existem algumas práticas recomendadas a seguir.

Minimizar o número de pessoas que têm acesso à conta SA e restrinja a participação da função sysadmin (e outras funções privilegiadas) portanto, apenas as pessoas que realmente precisam privilégios sysadmin têm-los. Não forneça a senha para qualquer pessoa que deseja acessar temporário para o SQL Server ou a um usuário do SQL que deseja executar alguma tarefa rápida. Nessas situações, crie um novo logon SQL e conceda a qualquer privilégio é necessário.

É melhor para que as pessoas que os membros do sysadmin em vez de usar a conta SA. Dessa forma, você pode remover logon do usuário sem ter que alterar a senha da conta. Se você assumir um servidor antigo e você não tem idéia que tinham acesso a ele antes, alterar a senha do SA portanto, está no controle.

Um problema que provokes debate é que se deseja remover o grupo do Windows Builtin/administradores da função de sysadmin (ele é adicionado por padrão). Um administrador do Windows poderá consultar o banco de dados de RH? Ou faz sua empresa explicitamente confiar todos os administradores tenham integridade e honesty? Se você decidir para removê-la, continue com cuidado. Isso ocorre especialmente em um ambiente de cluster em que se você não execute as etapas corretas, o SQL Server pode não iniciar. Para obter mais informações sobre isso e outros problemas de cluster, consulte o artigo da Base de Dados de Conhecimento" Cluster SQL Server dos, Don'ts e Basic Warnings."

Para aqueles que têm acesso de sysadmin, recomende não fazer logon com privilégios altos, a menos que absolutamente necessário — fornecer cada um desses logons de usuários dois, um privilégio e um não. Usando a conta sem privilégios por padrão ajuda a minimizar a possibilidade de erros dispendiosos e também reduz a probabilidade de que um Windows desbloqueado terminal terá uma janela com privilégios sysadmin abrir em-lo. Lembre-se: proteção em camadas!

O último ponto que fará aqui é evitar ter aplicativos que necessitam de privilégios sysadmin. Infelizmente, isso é uma prática inválida comuns e inevitável com alguns aplicativos, mas você deve evitar esta prática em aplicativos pessoal e reclamar com aos desenvolvedores de aplicativos que necessitam de privilégios sysadmin.

Autenticação

Há dois modos de autenticação disponíveis: autenticação do Windows e modo misto (que é a autenticação do Windows combinada com a autenticação do SQL Server).

Autenticação do Windows usa contas de rede/domínio para validar a conta do Windows que está sendo usada para se conectar ao SQL Server. Se esta opção for selecionada durante a instalação, a conta SA é criada com uma senha gerada aleatoriamente, mas efetivamente desabilitada. Imediatamente após a instalação, você deve alterar a senha para uma senha forte e segura mas continuar a deixar a conta desabilitada a menos que absolutamente necessário.

Autenticação do SQL Server depende de cada usuário ter uma conta do SQL Server e a senha armazenada no SQL Server definido. E, obviamente, isso significa que a conta SA está ativada e deve ter uma senha definida. Com a autenticação do SQL Server, os usuários ter pelo menos dois nomes de usuário e senhas (uma para a rede) e outra para o SQL Server. Geralmente, é recomendável que você use somente autenticação do Windows quando possível, pois é uma solução mais segura. O tópico Books Online" Escolhendo um modo de autenticação"explica mais detalhadamente, juntamente com como alterar o modo de autenticação.

Se a autenticação de SQL é usada, todos os usuários devem possuir uma senha de alta segurança — uma que seja complexa o suficiente para ser resistente a sendo esperar por um programa para decifrar senhas. Isso é especialmente importante para contas altamente privilegiado, como associação de segurança e os membros da função sysadmin. (Um dos mais comuns ainda pior práticas costumava ser para ter uma senha SA em branco. Felizmente, como SQL Server 2000 SP3, que não é possível.)

As senhas devem também ser alteradas regularmente e sua empresa deve publicar diretivas corporativas para ajudar funcionários use práticas recomendadas de senha segura e alta segurança. Para obter uma visão geral de práticas recomendadas para criar e proteger a senha de alta segurança, consulte o artigo" Senhas de alta seguras: como criar e utilizar-." Você pode incorporar essas diretivas em uma diretiva corporativa.

Se o SQL Server 2005 ou SQL Server 2008 estiver sendo executado no Windows Server 2003 ou posterior, ele pode fazer uso do Windows mecanismos de diretiva de senha para impor diretivas de complexidade e vencimento. A seção manuais online do SQL Server 2008 chamado" Diretiva de senha"possui informações sobre suporte para senhas de alta segurança e várias diretivas de senha no SQL Server.

Autorização

Como você já mencionei, uma das filosofias de proteção de sistemas é usar o princípio de privilégio mínimo. Enquanto isso se aplica diretamente a privilégios de administrador-nível, também se aplica às permissões para usuários do banco de dados regular. Um usuário em um banco de dados (provavelmente) não deve conseguir acessar dados em outro banco de dados. O proprietário de um conjunto de tabelas deve ser impossível estragar com tabelas de outra pessoa. Os usuários devem só consiga acessar os dados que deveriam para acessar, e mesmo assim eles devem apenas ser capazes de executar ações necessárias nos dados (por exemplo, SELECT, mas não UPDATE ou DELETE).

Tudo isso pode ser feito dentro do SQL Server por um sistema permissões abrangente e hierárquica onde os usuários ou funções (chamadas de objetos) são concedidas ou negadas determinadas permissões específicas no determinados recursos (chamados securables) como um objeto, esquema ou banco de dados. Uma visão geral sobre a hierarquia de permissões do SQL Server é ilustrada na Figura 4 . Isso também significa que você siga o princípio de privilégio mínimo. Por exemplo, não faça todos os desenvolvedores membros da função db_owner do banco de dados. Restringir permissões à função pública e só conceder permissões para o nível mais baixo (usuário ou função) para minimizar o acesso direto. Uma discussão completa sobre as práticas recomendadas para permissões está além do escopo deste artigo, mas os manuais online do SQL Server 2008 inclui uma seção chamada" Identidade e controle de acesso (mecanismo de banco de dados)"que oferece drill-liste em todos os conceitos.

A Figura 4 hierarquia de permissões O SQL Server

Para permitir que permissões mais granulares e melhor separação de funções dentro de um banco de dados, SQL Server 2005 introduziu separação de esquema de usuário, onde esquemas são independentes de usuários do banco de dados e são apenas recipientes de objetos. Isso permite que muitas alterações de comportamento, incluindo mais precisão específicas para o gerenciamento de permissões. (Quatro partes de nomeação segue o server.database.schema.object de formato no SQL Server 2005 e no SQL Server 2008, o formato era anteriormente server.database.owner.object.)

Por exemplo, um esquema pode ser criado com os desenvolvedores de banco de dados permissões de controle. Eles podem criar, ALTER e DROP qualquer objetos dentro dos esquemas elas controlam mas têm não permissões implícitas para outros esquemas dentro do banco de dados e eles não precisam mais direitos db_owner para banco de dados desenvolvimento. Além disso, a separação de esquema de usuário permite que os usuários do banco de dados ser descartado sem precisar recode todos os objetos relacionados ou o aplicativo com um novo nome de usuário — os objetos são membros de um esquema e eles não estão ligados a criador do objeto.

É uma prática recomendada usar esquemas de posse de objetos devido a esses motivos. Mais informações podem ser encontradas nos manuais online do SQL Server 2008 no tópico" Separação de esquema de usuário."

Outra maneira de impedir que os usuários fazer as coisas que não precisa para fazer é impedir acesso direto à suas tabelas base. Isso pode ser feito fornecendo procedimentos armazenados e funções que são usadas para encapsular, controle e isolar as operações como atualizações e exclusões e fornecendo exibições que permitir controlada e ideal seleciona.

Inclusão de SQL

Um dos métodos mais comuns de obtenção de acesso não autorizado aos dados é usar um ataque de injeção de SQL. Inclusão de SQL pode tomar vários formulários, mas a abordagem principal aproveita do código que usa seqüências de caracteres construídas dinamicamente e "injeta" código inesperado para a construção. Por exemplo, o ataque de injeção seguinte aproveita mal-escrito lógica para validar a entrada usuário a rodada do SQL Server para aceitar a entrada, incluindo caracteres de escape na cadeia de caracteres de entrada. Embora contrived, este exemplo realça que pode acontecer quando o código cria dinamicamente seqüências usando entrada que não é validada completamente:

DECLARE @password VARCHAR (20);
DECLARE @input    VARCHAR (20);
DECLARE @ExecStr  VARCHAR (1000);

SELECT @password = 'SecretSecret';

-- assume application gets input 'OR''='
SELECT @input = '''OR''''=''';

SELECT @ExecStr = 'IF ''' + @password + ''' LIKE ''' + @input + ''' PRINT ''Password Accepted''';

EXEC (@ExecStr);
GO

Se você executar esse código, ele imprimirá a frase aceito de senha mesmo que a entrada do usuário claramente não corresponde a seqüência de caracteres da senha. A entrada do usuário continha uma seqüência de escape que alterou a lógica de Transact-SQL porque a entrada foi analisada e verificada corretamente.

Inclusão de SQL não deve ser um problema para um aplicativo bem escrito e existem alguns truques específicos (como usar QUOTENAME para identificadores delimitados). Mas se você herdar um aplicativo antigo (ou talvez um projeto de homebrew que se tornou um aplicativo corporativo), você deve testar especificamente para verificar se ele está vulnerável a ataques de injeção de SQL. Há uma variedade de técnicas disponíveis para atenuar os ataques de injeção de SQL. Manuais online do SQL Server 2008 tem uma seção abrangente, começando com o tópico apropriadamente nomeado" Inclusão de SQL."

Recuperação de desastres

Quanto você precisa se preocupar com isso depende de quais são os requisitos de perda de tempo de inatividade e dados. (Se você já não tiver definido esses requisitos, você deve!) Problemas de segurança podem ocorrer em muitos níveis. Existem alguns problemas quando a recuperação de desastres envolve failover para outro SQL Server ou a necessidade de restaurar um banco de dados contendo os dados criptografados.

No primeiro caso, os problemas ocorrem quando os logins necessárias para acessar o banco de dados não tem sido duplicados no servidor de failover — por exemplo, quando usando o envio de log ou espelhamento do banco de dados. Se o banco de dados ocorrer failover para a instância de espelhamento e o aplicativo tenta se conectar usando um login específico que não existe no servidor espelho, o aplicativo receberá o erro 18456 "logon falhou". Os logins fazem parte do ecossistema de aplicativos e devem ser definidos na instância que hospeda o banco de dados. Artigo da Base de Dados de Conhecimento da 918992" Como transferir os logins e as senhas entre instâncias do SQL Server 2005" explica como fazer isso, e irá discutir solução de problemas erro 18456 em alguns instantes.

No segundo caso, problemas ocorrem quando o backup do banco de dados contém dados criptografados e a criptografia de chave (ou chaves) usada para criptografar os dados não foram feitas backup ou não estão disponíveis na instância do SQL Server em que o banco de dados está sendo restaurado. O melhor caso aqui é que apenas alguns dos dados no banco de dados são criptografados e para que apenas esse subconjunto de dados não pode ser acessado. O pior cenário de caso é que todo o banco de dados foram criptografado usando a criptografia de dados transparente (TDE) no SQL Server 2008. Nesse caso, se o certificado de servidor usado para proteger a chave de criptografia do banco de dados não foi feito backup ou não estiver disponível, o banco de dados inteiro não pode ser restaurado e retornará os seguintes erros:

Msg 33111, Level 16, State 3, Line 1
Cannot find server certificate with thumbprint
'0xFBFF1103AF133C22231AE2DD1D0CC6777366AAF1'.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Obviamente, isso é o ponto de TDE — que alguém acontecendo em um backup perdido do banco de dados criptografado não é possível restaurá-lo e acessar os dados confidenciais. Mas se os dados são sua, e você precisa acessá-lo, em seguida, você deve ter o certificado do servidor disponível ou os dados serão perdidos.

Criptografia é um tópico enorme em si e tem cobertura completa no SQL Server 2008 Books Online, iniciando com o " Criptografia do SQL Server"seção. Você também pode assistir me Demonstre TDE e restaurar com êxito para uma segunda instância em um acompanhamento screencast vídeo disponível em .com/dicas.

Auditoria

Uma das coisas mais importantes que você deve fazer para melhorar a segurança de um sistema é implementar a auditoria. Com isso, você saberá que o que está fazendo. Isso ainda pode ser obrigatório, dependendo da natureza da sua empresa.

No mínimo, você deve auditar logons com falha e bem-sucedidas para que você pode dizer se, por exemplo, cinco falhas em tentativas de logon foram seguidas por um bem-sucedido. Em seguida, você sabe quando alguém está tentando quebrar em sua instância do SQL Server (e com o logon). mostra a Figura 5 configurando a auditoria de logon pela caixa de diálogo Propriedades do servidor no SQL Server 2005 Management Studio. Logons com falha são auditados como mensagem 18456 no log de erros e o estado de erro fornece o motivo da falha. A melhor descrição que foi possível localizar os diferentes estados, bem como uma discussão longa sobre solução de problemas, está em uma postagem de il-Sung Lee no blog SQL protocolos intitulado" Noções básicas sobre 'Falha de Logon' (Erro 18456) mensagens de erro no SQL Server 2005."

A Figura 5 Confi guring logon de auditoria no SQL Server 2005 Management Studio

Auditoria completa de todas as ações é difícil no SQL Server 2005 (e muito além do escopo deste artigo). Ela envolve vários disparadores e rastreamento SQL. No SQL Server 2008, a auditoria foi bastante simplificada com a introdução de um novo recurso: auditoria do SQL Server. Isso é abordado em um recente, muito detalhado informe oficial intitulado" Auditoria no SQL Server 2008." O que acompanha screencast vídeo, demonstrarei auditoria do SQL Server. Você pode obter detalhes sobre outras ferramentas de auditoria no SQL Server 2008 Books Online" Auditoria (mecanismo de banco de dados)"seção.

Resumo

Que muitos tópicos e muita de links, mas esse era o ponto de neste artigo. Eu queria fornecer uma visão geral dos tópicos de segurança importantes que você deve considerar quando você estiver um banco de dados que não usaram para lidar com segurança.

Existem algumas ferramentas que podem ajudar você a verificar o sistema para vulnerabilidades de segurança comuns. O primeiro é o utilitário Microsoft Baseline Security Analyzer (MBSA) que verificarão para Windows, rede, sistema de arquivos e até mesmo alguns problemas de segurança do SQL Server 2000 e SQL Server 2005. A versão mais recente é Microsoft Baseline Security Analyzer 2.1. Novamente para SQL Server 2000 e SQL Server 2005 somente, há uma SQL Server–specific ferramenta chamada a Best Practices AnalyzerBPA (). Isso usa uma lista predefinida de regras para verificar a configuração do SQL Server e sinaliza problemas (por exemplo, uma senha SA em branco).

Nenhuma dessas ferramentas funciona com o SQL Server 2008. Na verdade, BPA será não liberada para o SQL Server 2008 em todos os e foi substituída, juntamente com a ferramenta de configuração de área de superfície do SQL Server 2005 curta duração, pelo novo recurso de gerenciamento de diretivas-com base em discutido anteriormente. Parte a razão para essa substituição é que BPA e o SAC eram ferramentas somente leitura para ajudar você encontrar problemas — eles não foi possível corrigir problemas. Gerenciamento com base em diretivas oferece muitas opções corretivas e ele ainda pode ser usado para servidores de destino SQL Server 2000 e SQL Server 2005.

Obviamente, você deve sempre ser usando o Windows Update para garantir que os novos patches de segurança e service packs são baixados para instalação em um tempo apropriado — essa é a melhor maneira para ficar atualizado com as atualizações mais recentes. Instalar esses sem levando tempo de inatividade é além do escopo deste artigo, mas algumas idéias apresentadas no Coluna de p & r do SQL de dezembro de 2006.

Se você está tentando localizar recursos Microsoft gerais sobre segurança, existem muitos destinos que aparecerão no seu mecanismo de pesquisa favorito. Para salvar alguns tempo clicando em torno, vai sugiro duas chaves white papers que você deve ler.

" SQL Server 2005 segurança melhor Practices–Operational e tarefas administrativas"e" SQL Server 2008: visão geral de segurança para administradores de banco de dados."

Para o SQL Server 2005, o ponto de entrada para a seção de segurança do Books Online é o tópico" Considerações de segurança para bancos de dados e aplicativos de banco de dados." Para o SQL Server 2008, o ponto de entrada manuais online do equivalente é o " Segurança e proteção (mecanismo de banco de dados)."

Como diz respeito takeaways deste artigo, eu quero você perceber que há algumas etapas que você precisa percorrer para garantir os dados que você está armazenando no SQL Server como seguras que ele seja necessário. Isso é especialmente importante quando você herdar uma instância do SQL Server que alguém Gerenciando. É exatamente como comprar uma casa de outra pessoa — você precisará perguntar se o alarme funciona, se o jardim é fenced em, e quem tem cópias das chaves. Execução através da lista que deu neste artigo é um bom começo, mas verifique se que você examine mais em áreas que são relevantes para você. E como sempre, se você tiver quaisquer comentários ou dúvidas, solte-me uma linha no Paul@SQLskills.com.

Paul S. Randal é o diretor de gerenciamento de SQLskills.com e um MVP do SQL Server. Ele trabalhou na equipe mecanismo de armazenamento do SQL Server da Microsoft de 1999 para 2007. Paul escreveu DBCC CHECKDB/reparo para o SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Paul é um especialista em recuperação de desastres, alta disponibilidade e manutenção de banco de dados e é um apresentador regular em conferências em todo o mundo. Blogs de he em SQLskills.com/blogs/paul.

Recursos adicionais