SQL Server 2008

Segurança

Rick Byham

Visão geral:

• Aprimoramentos na criptografia
• Aprimoramentos na autenticação
• Auditoria de segurança
• Gerenciamento com base em políticas

O SQL Server 2008 oferece vários aprimoramentos e novos recursos projetados para melhorar a segurança geral do seu ambiente de banco de dados. Ele adiciona recursos de autenticação e criptografia importantes e apresenta um novo sistema de auditoria para

ajudá-lo a relatar o comportamento do usuário e atender seus requisitos regulamentares.

Neste artigo, fornecerei uma visão geral das alterações mais importantes que você encontrará nas lojas para a segurança do SQL Server® 2008. Uma das primeiras coisas que você notará é que a ferramenta Configuração da Área de Superfície do SQL Server 2005 foi descontinuada. As opções de protocolo que eram expostas pela ferramenta Configuração da Área de Superfície estão agora disponíveis na ferramenta Gerenciador de Configurações. No entanto, a ativação e a desativação de recursos agora são feitas usando a nova estrutura de gerenciamento com base em políticas do SQL Server 2008.

Aprimoramentos na criptografia

Existem duas principais melhorias na área da criptografia. Primeiro, o SQL Server pode agora usar chaves de criptografia armazenadas em um módulo de segurança de hardware externo de terceiros. E segundo, os dados armazenados no SQL Server podem ser criptografados em um método transparente para os aplicativos que se conectam ao banco de dados. Isso significa que os administradores de bancos de dados podem facilmente criptografar todos os dados armazenados em um banco de dados inteiro sem ter que modificar o código do aplicativo existente.

A primeira melhoria é possibilitada pelo novo recurso EKM (Gerenciamento Extensível de Chaves), disponível nas edições Enterprise, Developer e Evaluation do SQL Server 2008. O EKM permite que outros fornecedores de soluções de gerenciamento de chaves empresarial e HSM (módulo de segurança de hardware) registrem seus dispositivos no SQL Server. Depois que esses dispositivos forem registrados, os usuários poderão usar as chaves de criptografia armazenadas nesses módulos.

Esses fornecedores podem até mesmo expor recursos de criptografia avançados (como vencimento e rotação de chaves) nesses módulos. Em algumas configurações, isso permite uma proteção de dados a partir dos administradores de bancos de dados que não são membros do grupo sysadmin. As instruções criptográficas T-SQL podem então criptografar e descriptografar dados usando as chaves armazenadas no dispositivo EKM externo.

Outro novo recurso, a criptografia de dados transparente, permite que você criptografe arquivos de bancos de dados sem ter que alterar nenhum dos seus aplicativos. Ele executa criptografia de E/S em tempo real e a descriptografia dos dados e arquivos de log. A criptografia usa uma DEK (chave de criptografia do banco de dados), que é armazenada no registro de inicialização do banco de dados para disponibilidade durante a recuperação. A DEK é protegida por um certificado armazenado no banco de dados mestre do servidor. O diagrama na Figura 1 ilustra a arquitetura que permite a criptografia de dados transparente.

Figure 1** Arquitetura de criptografia de dados transparente **(Clique na imagem para aumentar a exibição)

Isso é útil para proteger os dados em repouso. Embora você possa tomar várias precauções para ajudar a proteger seu banco de dados, como a criptografia de ativos confidenciais e a colocação de um firewall ao redor dos servidores dos bancos de dados, a mídia física na qual o banco de dados é armazenado (mesmo fitas de backup) oferece uma vulnerabilidade diferente. Um usuário mal-intencionado poderia roubar essa mídia e potencialmente acessar os dados armazenados.

A criptografia de dados transparente, no entanto, permite que você criptografe os dados confidenciais no banco de dados e proteja as chaves usadas para criptografar os dados com um certificado. Isso pode ajudar sua organização a estar em conformidade com várias leis, regulamentações e diretrizes da indústria com relação à proteção apropriada de dados.

A criptografia de dados transparente permite que desenvolvedores de software criptografem dados usando algoritmos de criptografia AES (padrão avançado de criptografia) e 3DES (padrão de criptografia de dados triplo). A criptografia do arquivo do banco de dados é executada no nível da página, com páginas sendo criptografadas antes que sejam gravadas em disco e, posteriormente, descriptografadas quando lidas na memória. Arquivos de backup de bancos de dados que possuem a criptografia de dados transparente ativada também são criptografados usando a chave de criptografia de banco de dados.

Para restaurar um banco de dados criptografado, você deve ter acesso ao certificado ou à chave assimétrica que foi usada para criptografar o banco de dados. Sem o certificado ou a chave assimétrica, o banco de dados não pode ser restaurado. Então, certifique-se de manter todas as chaves enquanto possa precisar de acesso aos backups relacionados.

Aprimoramentos na autenticação

Como você provavelmente sabe, Kerberos é o novo protocolo de autenticação de rede usado para fornecer um meio altamente seguro para autenticar mutuamente entidades cliente e servidor (ou entidades de segurança) em uma rede. O Kerberos ajuda os usuários a mitigar vulnerabilidades de segurança, como ataques por sedução e intermediários. Em relação à autenticação NTLM do Windows®, o Kerberos é mais seguro, mais eficiente e oferece um melhor desempenho.

Para autenticar uma conexão manualmente usando o Kerberos, o SPN (nome da entidade de serviço) de uma instância do SQL Server deve ser registrado no Active Directory® e um driver cliente deve fornecer um SPN registrado ao conectar. No SQL Server 2008, a autenticação Kerberos foi expandida a todos os protocolos de rede, incluindo TCP, pipe nomeado, memória compartilhada e VIA (adaptador de interface virtual). Por padrão, o driver cliente automaticamente infere um SPN correto para uma instância do SQL Server à qual ele se conecta. Você também pode especificar explicitamente um SPN no parâmetro de cadeia de caracteres de conexão para uma segurança melhor, controle e solução de problemas.

O IIS (serviço de informações da Internet) não fornece mais acesso ao ASP.NET, ao Gerenciador de Relatórios ou ao Serviço da Web Report Server. No SQL Server 2008, o Reporting Services lida com todas as solicitações de autenticação por meio de um novo subsistema de autenticação que suporta autenticação personalizada e baseada no Windows.

O Reporting Services hospeda agora as tecnologias Microsoft® .NET Framework e ASP.NET incorporadas no CLR (common language runtime) do SQL Server e o Reporting Services usa também os recursos HTTP.SYS do SO. O Report Server inclui um ouvinte HTTP que aceita solicitações direcionadas a uma URL e uma porta que você define durante a configuração do servidor. As reservas e o registro da URL agora são gerenciados diretamente pelo servidor de relatórios por meio de HTTP.SYS.

Auditoria de segurança

O SQL Server Audit é um novo recurso que permitirá a você criar auditorias personalizadas de eventos de mecanismo do banco de dados. Esse recurso usa eventos estendidos para gravar informações para auditorias e fornece as ferramentas e processos necessários para ativar, armazenar e exibir auditorias em vários objetos de servidor e banco de dados.

O SQL Server Audit também é mais rápido que o SQL Server Trace e o SQL Server Management Studio facilita a criação e o monitoramento de logs de auditoria. Você pode fazer a auditoria para um nível mais granular agora, capturando as instruções SELECT, INSERT, UPDATE, DELETE, REFERENCES e EXECUTE para usuários individuais. Além disso, o SQL Server Audit é totalmente programável por scripts com instruções T-SQL CREATE SERVER AUDIT e CREATE SERVER AUDIT SPECIFICATION e suas instruções relacionadas ALTER e DROP.

Para configurar a auditoria, você cria uma auditoria e especifica o local onde os eventos auditados serão gravados. As auditorias podem ser salvas no log da Segurança do Windows, no log do Aplicativo do Windows ou em um arquivo em um local especificado por você. Você nomeia a auditoria e configura suas características, como o caminho para o arquivo de auditoria e seu tamanho máximo. Você também pode selecionar que o SQL Server desligue se a auditoria falhar. E se você precisar registrar em log os eventos auditados em mais de um local, você apenas criará mais de uma auditoria.

A próxima etapa é criar uma ou mais especificações de auditoria. Uma especificação de auditoria do servidor coleta informações sobre a instância do SQL Server e inclui objetos com abrangência de servidor, como logins e associação de função de servidor. Ela também inclui informações de bancos de dados gerenciadas no banco de dados mestre, como o direito de acessar um banco de dados. Quando você define uma especificação de auditoria, você indica que auditoria receberá os eventos monitorados. Você pode definir várias auditorias de servidor e várias especificações de auditoria de servidor, mas cada auditoria de servidor pode incluir apenas uma especificação de auditoria de servidor ativada de cada vez.

Você também pode criar especificações de auditoria de banco de dados que monitoram eventos em um único banco de dados. Você pode adicionar várias especificações de auditoria de banco de dados a uma auditoria, mas uma auditoria de servidor pode ativar apenas uma especificação de auditoria de banco de dados por banco de dados de cada vez.

Os eventos de ação de auditoria do SQL Server usados para especificações de auditoria de servidor são agrupados em conjuntos de eventos de ação de auditoria relacionados. Eles são expostos como grupos de ação de auditoria. Quando você adiciona um grupo à especificação de auditoria, você monitora todos os eventos incluídos nesse grupo. Por exemplo, existe um grupo de ação de auditoria chamado DBCC_GROUP que expõe os comandos DBCC. Os comandos DBCC, no entanto, não estão disponíveis para auditoria individualmente.

Existem 35 grupos de ação de auditoria disponíveis para o servidor, alguns dos quais estão intimamente relacionados uns ao outros. Por exemplo, existe um SUCCESSFUL_LOGIN_GROUP, um FAILED_LOGIN_GROUP e um LOGOUT_GROUP. Existe também um tipo de ação de auditoria AUDIT_ CHANGE_GROUP que você pode usar para fazer a auditoria do processo de auditoria.

As especificações de auditoria do banco de dados também podem especificar grupos de eventos de ação de auditoria coletados em grupos de ação de auditoria no nível do banco de dados. Além dos grupos de ação de auditoria, as especificações de auditoria do banco de dados podem incluir eventos de ação de auditoria para fazer a auditoria de instruções de linguagem de manipulação de dados. Esses eventos podem ser configurados para monitorar todo o banco de dados ou apenas objetos de bancos de dados específicos. A ação de auditoria SELECT, por exemplo, pode ser usada para fazer a auditoria de consultas SELECT para uma única tabela ou um esquema inteiro. Esses eventos também podem ser configurados para monitorar ações por usuários ou funções específicas — como todas as db_writers.

Você pode usar a ação de auditoria SELECT, por exemplo, para fazer a auditoria de consultas SELECT para uma única tabela pelo usuário Mary ou pela função de banco de dados FINANCE_DEPT ou, ainda, pela função de banco de dados pública. Sem dúvida, isso oferece muito controle e flexibilidade para criar as auditorias de que você precisa.

Relatório de dependência

O Relatório de dependência foi aprimorado com uma nova exibição de catálogo e novas funções de sistema. Se você usa sys.sql_expression_dependencies, sys.dm_sql_referencing_entities e sys.dm_sql_referenced_entities, pode relatar em dependências do SQL entre servidores, entre bancos de dados e de bancos de dados para objetos ligados ou não a esquemas.

Novas funções do banco de dados

Existem alterações feitas nas funções do banco de dados incluídas no banco de dados msdb. A função db_dtsadmin foi renomeada para db_ssisadmin, a função db_dtsltduser foi renomeada para db_ssisltduser e a função db_dtsoperator foi renomeada para db_ssisoperator. Para serem compatíveis com versões anteriores, as funções antigas são adicionadas como membros das novas funções quando os servidores são atualizados.

Além dessas alterações, novas funções de bancos de dados foram adicionadas para oferecer suporte a novos recursos do SQL Server 2008. Em particular, o banco de dados msdb inclui novas funções para grupos de servidor (ServerGroupAdministratorRole e ServerGroupReaderRole), gerenciamento com base em políticas (PolicyAdministratorRole) e o coletor de dados (dc_admin, dc_operator e dc_proxy). E o banco de dados do data warehouse de gerenciamento também inclui novas funções para o coletor de dados (mdw_admin, mdw_writer e mdw_reader).

Segurança de FILESTREAM

O SQL Server inclui agora suporte para armazenamento FILESTREAM, que permite aos aplicativos do SQL Server armazenarem dados não estruturados, como documentos e imagens, no sistema de arquivos. Isso, por sua vez, significa que os aplicativos cliente podem se beneficiar das APIs de fluxo contínuo e do desempenho do sistema de arquivos ao mesmo tempo em que mantêm a consistência transacional entre dados não-estruturados e estruturados correspondentes.

Os dados FILESTREAM devem ser armazenados nos grupos de arquivos FILESTREAM — um grupo de arquivos especial que contém diretórios do sistema de arquivos em vez dos arquivos em si. Esses diretórios, chamados contêineres de dados, fornecem a interface entre o armazenamento do mecanismo de banco de dados e o armazenamento do sistema de arquivos.

Em termos de segurança, os dados FILESTREAM são protegidos como qualquer outro dado — as permissões são concedidas nos níveis da tabela ou da coluna. A única conta que recebe permissões de NTFS ao contêiner FILESTREAM é a conta sob a qual a conta de serviço do SQL Server é executada. Quando um banco de dados é aberto, o SQL Server restringe o acesso aos contêineres de dados FILESTREAM, exceto quando o acesso é feito usando as transações T-SQL e as APIs OpenSqlFilestream.

Gerenciamento com base em políticas

O Gerenciamento com base em políticas do SQL Server 2008 fornece um novo sistema para gerenciar o SQL Server. Você pode criar políticas para testar e relatar vários aspectos do SQL Server e as políticas podem ser aplicadas em um único banco de dados, uma única instância do SQL Server ou em todos os SQL Servers que você gerenciar.

Com o Gerenciamento com base em políticas, você pode testar as opções de configuração do SQL Server e várias das configurações de segurança. E para algumas configurações de segurança, você pode criar políticas para detectar servidores de bancos de dados fora de conformidade e executar etapas para forçá-los e estar em conformidade.

No SQL Server 2008, vários recursos não-essenciais são desativados por padrão para minimizar sua exposição a um possível ataque. Você pode usar o Gerenciamento com base em políticas para ativar de forma seletiva qualquer recurso adicional de que precise. Você pode então avaliar sua configuração de forma programada, recebendo alertas se as configurações não corresponderem à política.

O Gerenciamento com base em políticas agrupa propriedades relacionadas e as expõe em componentes chamados facetas. Por exemplo, a faceta Configuração da Área de Superfície contém propriedades para Consultas Remotas Ad Hoc, Integração do CLR, Correio do Banco de Dados, Automação OLE, DAC Remota, SQL Mail, Web Assistant e xp_cmdshell. Você pode criar uma política que permite a Integração do CLR, mas que desabilita todos os outros recursos. A sua política pode incluir instruções de condição complexas, como desabilitar o Correio do Banco de Dados em todas as instâncias do SQL Server, a menos que sejam chamadas Customer_Response.

Depois de criar a política, você poderá avaliá-la em todos os seus servidores para produzir um relatório que diz a você quais servidores não estão em conformidade. Pressione o botão Configure (Configurar) e todas as instâncias que não estiverem em conformidade serão definidas com as configurações de política. Você também deve programar a política para ser executada periodicamente para monitorar o status dos seus servidores. As facetas Configuração da Área de Superfície são fornecidas para Database Engine, Analysis Services e Reporting Services.

Observe, no entanto, que esse Gerenciamento com base em políticas não pretende ser um mecanismo de aplicação de segurança. Na maioria dos casos, um usuário com privilégios suficientes pode gerar instruções que violam uma política ou ignorar a política e executar ações de reconfiguração que podem violar sua política de segurança. O Gerenciamento com base em políticas do SQL Server 2008 deve ser considerado simplesmente como uma ajuda para monitorar suas configurações de segurança do SQL Server.

As facetas variam em sua capacidade de aplicar configurações, dependendo se suas instruções DDL relacionadas podem ser executadas em modos de não confirmação automática. Às vezes, uma faceta pode aplicar uma configuração em uma instância do Database Engine, mas um administrador pode ainda reconfigurar as configurações. Algumas facetas podem ser aplicadas por um disparador do servidor — isso pode impedir que usuários com baixo privilégio alterem a configuração e reduzam a chance de um administrador acidentalmente alterar a configuração. Neste caso, o administrador teria que desabilitar temporariamente a política antes de alterar a configuração. Outras facetas podem apenas relatar o status de uma propriedade, mas não podem alterá-lo. Isso é o que ocorre com uma política que verifica o tamanho de uma chave simétrica ou assimétrica (conforme exibido na Figura 2).

Figure 2** Faceta para chaves assimétricas **(Clique na imagem para aumentar a exibição)

Existem facetas para a maioria dos tipos de objetos de bancos de dados, várias das quais possuem usos de segurança. Por exemplo, a faceta de logon pode determinar se a política de senha é aplicada para cada logon e a faceta de procedimento armazenado pode detectar se todos os procedimentos são criptografados. Outras facetas testam as propriedades de usuários, esquemas, provedores criptográficos, conformidade de critérios comuns e auditoria de C2.

Windows Server 2008

O SQL Server 2008 é totalmente testado com o Windows Server® 2008, enviado com o firewall ativado. Agora é um bom momento para rever como configurar as configurações do firewall. E o Windows Server 2008 também fornece Controle de Acesso de Usuário, que você pode ter experimentado com o Windows Vista®. Isso restringe os privilégios que você recebe automaticamente como usuário administrativo. Esses recursos afetarão todas as versões do SQL Server.

Em conclusão

A segurança continua a ser uma área de aperfeiçoamento para o SQL Server. Os aprimoramentos de criptografia e autenticação fornecem novos recursos e o novo sistema de auditoria e o gerenciamento com base em políticas do SQL Server 2008 fornecem a você novas ferramentas para monitorar o status da conformidade com a segurança.

Rick Byham entrou na Microsoft em 1995. Ele trabalhou como engenheiro de suporte do SQL Server nos Serviços de Suporte ao Cliente e entrou para a equipe do SQL Server no Microsoft Learning. Passou para a equipe de Manuais Online do SQL Server como redator técnico em 2003, onde atualmente é responsável pela documentação de segurança. Entre em contato com Rick pelo email rick.byham@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..