Melhores práticas de segurança do SQL Server

Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

Este artigo fornece informações sobre as melhores práticas e diretrizes que ajudam a estabelecer a segurança para o SQL Server. Para ver uma análise abrangente dos recursos de segurança do SQL Server, confira Proteger o SQL Server.

Para as melhores práticas de segurança específicas do produto, confira Banco de Dados SQL do Azure e Instância Gerenciada de SQL e SQL Server em VMs do Azure.

Visão geral

Uma metodologia de segurança em camadas fornece uma solução de defesa em profundidade usando vários recursos de segurança direcionados a escopos de segurança diferentes. Os recursos de segurança disponibilizados no SQL Server 2016 e aprimorados nas versões subsequentes ajudam a antecipar ameaças à segurança e fornecem aplicativos de banco de dados bem protegidos.

O Azure está em conformidade com vários padrões e regulamentações do setor que podem permitir o build de uma solução em conformidade com o SQL Server em execução em uma máquina virtual. Para obter informações sobre conformidade regulamentar com o Azure, consulte a Central de Confiabilidade do Azure.

Proteção em nível de coluna

As organizações geralmente precisam proteger dados no nível da coluna, uma vez que dados sobre clientes, funcionários, segredos comerciais, dados de produtos, serviços de saúde, financeiros e outros dados confidenciais geralmente são armazenados em bancos de dados do SQL Server. As colunas confidenciais geralmente incluem números de identificação pessoal/do seguro social, números de telefone celular, nome, sobrenome, identificação de conta financeira e quaisquer outros dados que podem ser considerados dados pessoais.

Os métodos e recursos mencionados nesta seção elevam o nível de proteção no nível da coluna com sobrecarga mínima e sem exigir alterações extensivas no código do aplicativo.

Use Always Encrypted para criptografar dados inativos e durante a transmissão por cabo. Os dados criptografados só são descriptografados por bibliotecas de cliente no nível do cliente do aplicativo. Use a criptografia aleatória em vez da determinística sempre que possível. Always Encrypted com enclaves seguros pode melhorar o desempenho de operações de comparação, como BETWEEN, IN, LIKE, DISTINCT, Joins e muito mais para cenários de criptografia aleatória.

Use DDM (Máscara Dinâmica de Dados) para ofuscar dados no nível da coluna quando Always Encrypted não for uma opção disponível. DDM (Máscara Dinâmica de Dados) não é compatível com Always Encrypted. Use o Always Encrypted em relação ao mascaramento dinâmico de dados sempre que possível.

Você também pode CONCEDER permissões no nível da coluna para uma tabela, exibição ou função com valor de tabela. Considere o seguinte: - apenas permissões SELECT, REFERENCES e UPDATE podem ser concedidas em uma coluna. - Um DENY em nível de tabela não tem precedência sobre um GRANT em nível de coluna.

Proteção em nível de linha

A RLS (Segurança em Nível de Linha) permite aproveitar o contexto de execução do usuário para controlar o acesso a linhas em uma tabela de banco de dados. A RLS garante que os usuários só possam ver o registro que pertence a eles. Isso fornece ao seu aplicativo segurança de "nível de registro" sem precisar fazer alterações significativas em seu aplicativo.

A lógica de negócios é encapsulada dentro de funções com valor de tabela controladas por uma política de segurança que ativa e desativa a funcionalidade RLS. A política de segurança também controla os predicados FILTER e BLOCK que estão vinculados às tabelas contra as quais a RLS trabalha. Use a RLS para limitar os registros retornados ao usuário que está fazendo a chamada. Use SESSION_CONTEXT (T-SQL) para usuários que se conectam ao banco de dados por meio de um aplicativo de camada intermediária em que os usuários do aplicativo compartilham a mesma conta de usuário do SQL Server. Para obter o desempenho ideal e a capacidade de gerenciamento, siga as Melhores práticas de Segurança em Nível de Linha.

Criptografia de arquivo

A TDE (Transparent Data Encryption) protege os dados no nível do arquivo fornecendo criptografia inativa para os arquivos de banco de dados. A TDE garante que arquivos de banco de dados, arquivos de backup e arquivos tempdb não possam ser anexados e lidos sem certificados adequados que descriptografam arquivos de banco de dados. Sem a TDE (Transparent Data Encryption), é possível que um invasor use a mídia física (unidades ou fitas de backup) e restaure ou anexe o banco de dados para ler o conteúdo. A TDE tem suporte para trabalhar com todos os outros recursos de segurança no SQL Server. A TDE fornece criptografia de E/S em tempo real e descriptografia dos dados e arquivos de log. A criptografia de TDE aproveita uma DEK (chave de criptografia de banco de dados) armazenada no banco de dados do usuário. A chave de criptografia do banco de dados também pode ser protegida usando um certificado, protegido pela chave mestra do banco de dados master.

Use a TDE para proteger dados inativos, backups e tempdb.

Auditoria e relatórios

Para auditar o SQL Server, crie uma política de auditoria no nível do servidor ou do banco de dados. Políticas de servidor se aplicam a todos os bancos de dados existentes e recém-criados no servidor. Para simplificar, habilita a auditoria no nível do servidor e permite que a auditoria no nível do banco de dados herde a propriedade no nível do servidor para todos os bancos de dados.

Audite tabelas e colunas com dados confidenciais que têm medidas de segurança aplicadas a elas. Se uma tabela ou coluna for importante o suficiente para precisar de proteção de uma capacidade de segurança, ela deverá ser considerada importante o suficiente para a auditoria. É especialmente importante auditar e revisar regularmente tabelas que contêm informações confidenciais, mas onde não é possível aplicar as medidas de segurança desejadas devido a algum tipo de limitação de aplicativo ou arquitetura.

Identidades e autenticação

O SQL Server dá suporte a dois modos de autenticação, modo de autenticação do Windows e "modo de autenticação SQL Server e Windows" (modo misto).

Os logons são diferentes dos usuários de banco de dados. Primeiro, você precisa mapear logons ou grupos do Windows para usuários ou funções de banco de dados separadamente. Em seguida, conceda permissões a usuários, funções de servidor e/ou funções de banco de dados para acessar objetos de banco de dados.

O SQL Server dá suporte aos seguintes tipos de logon:

• Uma conta de usuário local Windows ou uma conta de domínio do Active Directory – SQL Server se baseia no Windows para autenticar as contas de usuário Windows.
• Grupo do Windows – Permitir acesso a um grupo do Windows concede acesso a todos os logons de usuário do Windows que são membros do grupo. Remover um usuário de um grupo remove os direitos do usuário que veio do grupo. A associação de grupo é a estratégia preferencial.
• Logon do SQL Server – O SQL Server armazena o nome de usuário e um hash da senha no banco de dados master.
• Usuários de bancos de dados independentes autenticam conexões do SQL Server no nível do banco de dados. Um banco de dados independente é um banco de dados isolado de outros bancos de dados e da instância do SQL Server (e o banco de dados master) que hospeda o banco de dados. O SQL Server dá suporte a usuários de bancos de dados independentes para autenticação no Windows e SQL Server.

As seguintes recomendações e melhores práticas ajudam a proteger suas identidades e métodos de autenticação:

• Use estratégias de segurança baseadas em função com privilégios mínimos para melhorar o gerenciamento de segurança.

  • É padrão colocar os usuários do Active Directory em grupos do AD. Os grupos do AD devem existir em funções do SQL Server que, por sua vez, devem ter as permissões mínimas exigidas pelo aplicativo.

• No Azure, aproveite a segurança de privilégios mínimos usando controles de RBAC (acesso baseado em função)

• Escolha Active Directory, em vez de autenticação do SQL Server, sempre que possível e, especialmente, escolha Active Directory em vez de armazenar a segurança no nível do aplicativo ou do banco de dados.

  • Se um usuário sair da empresa, será fácil desabilitar a conta.
  • Também é fácil remover usuários de grupos quando os usuários alteram funções ou saem da organização. A segurança de grupo é considerada uma melhor prática.

• Use a autenticação multifator para contas que têm acesso no nível do computador, incluindo contas que usam RDP para fazer logon no computador. Isso ajuda a proteger contra roubos ou vazamentos de credenciais, pois a autenticação baseada em senha de fator único é uma forma mais fraca de autenticação com credenciais em risco de serem comprometidas ou entregues por engano.

• Exigir senhas fortes e complexas que não podem ser adivinhadas facilmente e não são usadas para nenhuma outra conta ou finalidade. Atualizar regularmente senhas e impor políticas do Active Directory.

• As gMSA (Contas de serviço gerenciadas por grupo) oferecem gerenciamento automático de senhas, gerenciamento de SPN (nome da entidade de serviço simplificado) e delegam o gerenciamento a outros administradores.

  • Com a gMSA, o sistema operacional Windows gerencia senhas para a conta, em vez de contar com o administrador para gerenciar a senha.
  • A gMSA atualiza automaticamente as senhas da conta sem reiniciar os serviços.
  • A gMSA reduz o nível da superfície administrativa e melhora a separação de tarefas.

• Minimizar os direitos concedidos à conta do AD do DBA. Considere uma separação de tarefas que limitam o acesso à máquina virtual, a capacidade de fazer logon no sistema operacional, a capacidade de modificar logs de erros e auditoria e a capacidade de instalar aplicativos e/ou recursos.

• Considerar remover contas DBA da função sysadmin e conceder CONTROL SERVER a contas DBA, em vez de fazer delas um membro da função sysadmin. A função de administrador do sistema não respeita DENY enquanto CONTROL SERVER respeita.

Integridade e linhagem de dados

Manter registros históricos de alterações de dados ao longo do tempo pode ser útil para resolver alterações acidentais nos dados. Isso também pode ser útil para auditoria de alteração de aplicativo e pode recuperar elementos de dados quando um ator ruim introduziu alterações de dados que não foram autorizadas.

• Use as tabelas temporais para preservar as versões de registro ao longo do tempo e para ver os dados como eram ao longo do tempo de vida do registro para fornecer uma exibição histórica dos dados do aplicativo.
• As Tabelas Temporais podem ser usadas para fornecer uma versão da tabela atual a qualquer momento.

Avaliação e ferramentas de avaliação de segurança

As ferramentas de configuração e avaliação a seguir lidam com a segurança da área de superfície, identificar oportunidades de segurança de dados e fornecer uma avaliação de melhor prática da segurança do seu ambiente SQL Server no nível da instância.

• Configuração da Área de Superfície – habilite apenas os recursos exigidos pelo seu ambiente para minimizar o número de recursos que podem ser atacados por um usuário mal-intencionado.
• Avaliação de vulnerabilidade para SQL Server (SSMS) – a avaliação de vulnerabilidade do SQL é uma ferramenta no SSMS v17.4+ que ajuda a descobrir, rastrear e corrigir possíveis vulnerabilidades de banco de dados. A avaliação de vulnerabilidade é uma ferramenta valiosa para melhorar a segurança do banco de dados e é executada no nível do banco de dados, por banco de dados.
• Descoberta e Classificação de Dados do SQL (SSMS) – é comum que os DBAs gerenciem servidores e bancos de dados e não estejam cientes da sensibilidade dos dados contidos no banco de dados. A Descoberta e Classificação de Dados adiciona a capacidade de descobrir, classificar, rotular e relatar o nível de sensibilidade de seus dados. A Descoberta e Classificação de Dados tem suporte a partir do SSMS 17.5.

Ameaças SQL comuns

Ajuda saber quais são algumas ameaças comuns que arriscam o SQL Server:

• Injeção de SQL – é um tipo de ataque em que o código mal-intencionado é inserido em cadeias de caracteres, passadas posteriormente para uma instância do SQL Server para execução.
  • O processo de injeção funciona encerrando uma cadeia de caracteres de texto e anexando um novo comando. Como o comando inserido pode ter mais sequências anexadas a ele antes de ser executado, o invasor encerra a cadeia de caracteres injetada com uma marca de comentário --.
  • O SQL Server executa qualquer consulta sintaticamente válida recebida.
• Esteja ciente de ataques de canal lateral, malware e outras ameaças.

Riscos da injeção de SQL

Para minimizar o risco de uma injeção de SQL, considere os itens a seguir:

• Revise qualquer processo SQL que constrói instruções SQL para vulnerabilidades de injeção.
• Construa instruções SQL geradas dinamicamente de maneira parametrizada.
• Os desenvolvedores e administradores de segurança devem revisar todo o código que chama EXECUTE, EXEC ou sp_executesql.
• Não permita os seguintes caracteres de entrada:
  • ;: Delimitador de consulta
  • ': Delimitador de cadeia de dados de caractere
  • --: Delimitador de comentário de linha única.
  • /* ... */: Delimitadores de comentário.
  • xp_: Procedimentos armazenados estendidos do catálogo, como xp_cmdshell.
    • Não é recomendável usar xp_cmdshell em nenhum ambiente do SQL Server. Em vez disso, use SQLCLR ou procure outras alternativas devido aos riscos que xp_cmdshell pode introduzir.
• Sempre valide as entradas do usuário e limpe as saídas de erro de serem expostas ao invasor.

Riscos de canal lateral

Para minimizar o risco de um ataque de canal lateral, considere o seguinte:

• Verifique se os patches mais recentes do aplicativo e do sistema operacional estão aplicados.
• Para cargas de trabalho híbridas, verifique se os patches de firmware mais recentes estão aplicados para qualquer hardware local.
• No Azure, para aplicativos e cargas de trabalho altamente confidenciais, você pode adicionar proteção adicional contra ataques de temporização com máquinas virtuais isoladas, hosts dedicados ou aproveitando máquinas virtuais de computação confidencial, como a série DC e máquinas virtuais que aproveitam processadores AMD EPYC de 3ª geração.

Ameaças de infraestrutura

Considere as seguintes ameaças comuns à infraestrutura:

• Acesso de força bruta – o invasor tenta autenticar com várias senhas em contas diferentes até que uma senha correta seja encontrada.
• Quebra de senha/pulverização de senha – os invasores tentam uma única senha cuidadosamente criada em todas as contas de usuário conhecidas (uma senha para muitas contas). Se a pulverização de senha inicial falhar, eles tentarão novamente, utilizando uma senha cuidadosamente criada diferente, normalmente aguardando um período de tempo definido entre as tentativas para evitar a detecção.
• Ataques de ransomware são um tipo de ataque direcionado em que o malware é usado para criptografar dados e arquivos, impedindo o acesso a conteúdo importante. Os invasores tentam extorquir dinheiro de vítimas, geralmente na forma de criptomoedas, em troca de uma chave de descriptografia. A maioria das vulnerabilidades de ransomware começa com mensagens de email com anexos que tentam instalar ransomware ou sites que hospedam kits de exploração que tentam usar vulnerabilidades em navegadores da Web e outros softwares para instalar ransomware.

Riscos de senha

Como você não deseja que os invasores adivinhem facilmente nomes de conta ou senhas, as etapas a seguir ajudam a reduzir o risco de descoberta de senhas:

• Crie uma conta de administrador local exclusiva que não esteja nomeada como Administrador.
• Use senhas fortes e complexas para todas as suas contas. Para obter mais informações sobre como criar uma senha forte, consulte o artigo Criar uma senha forte.
• Por padrão, o Azure seleciona a Autenticação do Windows durante a instalação da máquina virtual do SQL Server. Portanto, o logon SA é desabilitado e uma senha é atribuída pela instalação. Recomendamos que o logon SA não seja usado nem habilitado. Se você precisar ter um logon do SQL, use uma das seguintes estratégias:

  • Crie uma conta do SQL com um nome exclusivo que tem a associação sysadmin. Faça isso no portal habilitando a Autenticação SQL durante o provisionamento.

    Dica

    Se você não habilitar a Autenticação SQL durante o provisionamento, deverá alterar manualmente o modo de autenticação para Modo de Autenticação do SQL Server e do Windows. Para obter mais informações, consulte Alterar Modo de Autenticação do Servidor.

  • Se precisar usar o logon SA, habilite o logon depois de provisionar e atribuir uma nova senha forte.

Riscos de ransomware

Considere o seguinte para minimizar os riscos de ransomware:

• A melhor estratégia para proteger contra ransomware é prestar atenção específica às vulnerabilidades de RDP e SSH. Além disso, considere as seguintes recomendações:
  • Usar firewalls e bloquear portas
  • Garantir que as atualizações mais recentes de segurança do aplicativo e do sistema operacional sejam aplicadas
  • Usar gMSAs (contas de serviços gerenciados de grupo)
  • Limitar acesso para as máquinas virtuais
  • Exigir acesso JIT (Just-In-Time) e Azure Bastion
  • Melhorar a segurança da área de superfície, evitando a instalação de ferramentas, incluindo sysinternals e SSMS no computador local
  • Evitar a instalação de recursos do Windows, funções e a habilitação de serviços que não são necessários
  • Além disso, deve haver um backup regular completo agendado que seja protegido separadamente de uma conta de administrador comum, para que ele não possa excluir cópias dos bancos de dados.

Conteúdo relacionado

• Protegendo o SQL Server
• Banco de Dados SQL do Azure e a Instância Gerenciada de SQL
• SQL Server em VMs do Azure