Partilhar via

Práticas recomendadas de segurança do SQL Server

  • Artigo

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure

Este artigo fornece informações sobre práticas recomendadas e diretrizes que ajudam a estabelecer a segurança para o SQL Server. Para obter uma revisão abrangente dos recursos de segurança do SQL Server, consulte Protegendo o SQL Server.

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

Visão geral

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

O Azure está em conformidade com vários regulamentos e padrões do setor que podem permitir que você crie uma solução compatível com o SQL Server em execução em uma máquina virtual. Para obter informações sobre conformidade regulatória com o Azure, consulte Central de Confiabilidade do Azure.

Proteção ao nível da coluna

As organizações geralmente precisam proteger os dados no nível da coluna, pois os dados relativos a clientes, funcionários, segredos comerciais, dados de produtos, assistência médica, financeiros e outros dados confidenciais geralmente são armazenados em bancos de dados do SQL Server. As colunas sensíveis geralmente incluem números de identificação/segurança social, números de telefone celular, nome, sobrenome, identificação da conta financeira e quaisquer outros dados que possam 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 extensas no código do aplicativo.

Utilize Always Encrypted para criptografar dados em repouso e durante a transmissão. Os dados criptografados só são descriptografados por bibliotecas de cliente no nível do cliente do aplicativo. Utilize criptografia aleatória em vez de determinística sempre que possível. Always Encrypted com enclaves seguros podem melhorar o desempenho para operações de comparação, como ENTRE, NA, COMO, DISTINTO, Junções e muito mais para cenários de criptografia aleatória.

Utilize de Mascaramento Dinâmico de Dados (DDM) para ofuscar dados ao nível da coluna quando *Always Encrypted* não for uma opção disponível. Mascaramento Dinâmico de Dados (DDM) não é compatível com Always Encrypted. Sempre que possível, use Always Encrypted em vez de mascaramento de dados dinâmicos.

Você também pode permissões GRANT no nível da coluna para uma tabela, exibição ou função com valor de tabela. Considere o seguinte: - Somente as permissões SELECT, REFERENCESe UPDATE podem ser concedidas em uma coluna. - Uma DENY ao nível da tabela não tem precedência sobre uma GRANTao nível da coluna.

Proteção em nível de linha

Row-Level Security (RLS) possibilita usar o contexto de execução do utilizador 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 lhes pertence. Isso dá ao seu aplicativo segurança de "nível de registro" sem ter que fazer alterações significativas no seu aplicativo.

A lógica de negócios é encapsulada em 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 opera. Use Row-Level Security (RLS) para limitar os registros que são retornados ao usuário que faz 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 um desempenho e capacidade de gerenciamento ideais, siga as práticas recomendadas de segurança Row-Level.

Dica

Utilize a Segurança Row-Level (RLS) juntamente com o "Always Encrypted" ou o "Dynamic Data Masking" (DDM) para maximizar a postura de segurança da organização.

Encriptação de ficheiros

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

Use TDE para proteger dados em repouso, backups e tempdb.

Auditoria e relatórios

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

Faça uma auditoria nas tabelas e colunas com dados confidenciais que tenham medidas de segurança aplicadas. Se uma tabela ou coluna é importante o suficiente para precisar de proteção por um recurso de segurança, então ela deve ser considerada importante o suficiente para 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 aplicação ou limitação arquitetônica.

Identidades e autenticação

O SQL Server oferece suporte a dois modos de autenticação , modo de autenticação do Windows e 'Modo de autenticação do SQL Server e do Windows' (modo misto).

Os logins são separados dos usuários do banco de dados. Primeiro, mapeie 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 servidore/ou funções de banco de dados acessar objetos de banco de dados.

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

  • Uma conta de usuário local do Windows ou uma conta de domínio do Ative Directory - o SQL Server depende do Windows para autenticar as contas de usuário do Windows.
  • Grupo do Windows - Conceder acesso a um grupo do Windows concede acesso a todos os logins 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 pertença a um grupo é a estratégia preferida.
  • 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 banco de dados contidos autenticam as conexões do SQL Server ao nível do banco de dados. Um banco de dados contido é um banco de dados isolado de outros bancos de dados e da instância do SQL Server (e do banco de dados master) que hospeda o banco de dados. O SQL Server dá suporte a utilizadores de bases de dados autónomas para autenticação no Windows e no SQL Server.

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

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

    • É padrão colocar usuários do Ative Directory em grupos do AD, grupos do AD devem existir em funções do SQL Server e as funções do SQL Server devem receber as permissões mínimas exigidas pelo aplicativo.

  • No Azure, utilize a segurança baseada no princípio de privilégios mínimos usando controles de acesso baseado em papéis (RBAC).

  • Escolha Active Directory em vez da autenticação do SQL Server sempre que possível e, especialmente, prefira o Active Directory a guardar as informações de segurança ao nível da aplicação ou base de dados.

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

  • Use a autenticação multifator para contas que tenham acesso ao nível da máquina, incluindo contas que utilizam RDP para iniciar sessão na máquina. Isso ajuda a proteger contra roubo ou vazamentos de credenciais, já que 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.

  • Exija palavras-passe fortes e complexas que não possam ser facilmente adivinhadas e que não sejam utilizadas para quaisquer outras contas ou fins. Atualize senhas regularmente e aplique políticas do Ative Directory.

  • Group-Managed Contas de Serviço (gMSA) Fornecem gestão automática de senhas, gestão simplificada do nome principal de serviço (SPN) e delegam a gestão a outros administradores.

    • Com o gMSA, o sistema operacional Windows gerencia senhas para a conta em vez de depender do administrador para gerenciar a senha.
    • O gMSA atualiza automaticamente as senhas da conta sem reiniciar os serviços.
    • O gMSA reduz a superfície administrativa e melhora a separação de funções.

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

  • Considere remover as contas DBA da função de sysadmin e conceder CONTROL SERVER às contas DBA, em vez de torná-las membros da função sysadmin. A função de administrador do sistema não respeita DENY, enquanto o servidor de controlo respeita.

Linhagem e integridade dos dados

Manter registos históricos das alterações de dados ao longo do tempo pode ser benéfico para lidar com alterações acidentais aos dados. Ele também pode ser útil para auditoria de alteração de aplicativo e pode recuperar elementos de dados quando um agente mal-intencionado introduz alterações de dados que não foram autorizadas.

  • Use tabelas temporais para preservar versões de registo ao longo do tempo e para ver os dados como estavam durante todo o período de existência do registo, fornecendo uma visão histórica dos dados da sua aplicação.
  • As Tabelas Temporais podem ser usadas para fornecer uma versão da tabela atual a qualquer momento.

Ferramentas e análise de segurança

As ferramentas de configuração e avaliação a seguir abordam a segurança da área de superfície, identificam oportunidades de segurança de dados e fornecem uma avaliação de práticas recomendadas da segurança do seu ambiente do SQL Server no nível da instância.

  • Configuração da área de superfície - Você deve habilitar 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 vulnerabilidades para o SQL Server (SSMS) - A ferramenta de avaliação de vulnerabilidades de SQL no SSMS v17.4+ ajuda a descobrir, rastrear e corrigir possíveis vulnerabilidades do banco de dados. A avaliação de vulnerabilidade é uma ferramenta valiosa para melhorar a segurança do seu banco de dados e é executada no nível do banco de dados, por banco de dados.
  • Descoberta e Classificação de Dados SQL (SSMS) - É comum que os DBAs gerirem servidores e bases de dados sem estarem cientes da sensibilidade dos dados que estes contêm. A Classificação de Descoberta de Dados & adiciona a capacidade de descobrir, classificar, rotular e relatar o nível de sensibilidade dos seus dados. A Descoberta & Classificação de Dados é suportada a partir de SSMS 17.5.

Ameaças comuns do SQL

Ele ajuda a saber quais são algumas ameaças comuns que colocam em risco o SQL Server:

  • Injeção de SQL - A injeção de SQL é um tipo de ataque em que código malicioso é inserido em cadeias que são passadas para uma instância de um servidor SQL para execução.
    • O processo de injeção funciona encerrando uma cadeia de texto e anexando um novo comando. Como o comando inserido pode ter mais cadeias de caracteres 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 & outras ameaças.

Riscos de injeção de SQL

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

  • Analise qualquer processo SQL que construa instruções SQL para vulnerabilidades de injeção.
  • Construa instruções SQL geradas dinamicamente de forma parametrizada.
  • Os programadores e administradores de segurança devem rever todo o código que chama EXECUTE, EXECou sp_executesql.
  • Não permitir os seguintes caracteres de entrada:
    • ;: Delimitador de consulta
    • ': Delimitador de cadeia de dados de caracteres
    • --: Delimitador de comentários de linha única.
    • /* ... */: Delimitadores de comentários.
    • xp_: Procedimentos armazenados de catálogo estendido, como xp_cmdshell.
      • Não é recomendável usar xp_cmdshell em qualquer ambiente do SQL Server. Use SQLCLR em vez disso, ou procure outras alternativas devido aos riscos que xp_cmdshell pode introduzir.
  • Sempre validar as entradas do utilizador e limpar as saídas de erro para evitar que sejam divulgadas e expostas a atacantes.

Riscos de canal lateral

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

  • Certifique-se de que os patches mais recentes de aplicativos e sistemas operacionais sejam aplicados.
  • Para cargas de trabalho híbridas, certifique-se de que os patches de firmware mais recentes sejam aplicados a qualquer hardware local.
  • No Azure, para aplicativos e cargas de trabalho altamente confidenciais, você pode adicionar proteção adicional contra ataques de canal lateral com máquinas virtuais isoladas, hosts dedicados ou usando máquinas virtuais de computação confidencial, como o da série DC e máquinas virtuais que usam processadores AMD EPYC de 3ª geração.

Ameaças à infraestrutura

Considere as seguintes ameaças comuns à infraestrutura:

  • Acesso por força bruta - o invasor tenta autenticar e com múltiplas palavras-passe em contas diferentes até que uma palavra-passe correta seja encontrada.
  • Quebra de senha / spray de senha - os invasores tentam uma única senha cuidadosamente criada contra todas as contas de usuário conhecidas (uma senha para muitas contas). Se o spray de senha inicial falhar, eles tentam novamente, utilizando uma senha diferente cuidadosamente criada, normalmente aguardando um determinado período de tempo entre as tentativas para evitar a deteção.
  • Ataques de Ransomware são um tipo de ataque direcionado em que se usa malware para criptografar dados e arquivos, impedindo o acesso a conteúdo importante. Os atacantes tentam extorquir dinheiro às vítimas, geralmente sob a forma de criptomoedas, em troca da chave de desencriptação. A maioria das infeções ransomware começa com mensagens de e-mail 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 da palavra-passe

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

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

    • Crie uma conta SQL com um nome exclusivo que seja membro do sysadmin. Você pode fazer isso no portal ativando 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 SQL Server e o Modo de Autenticação do Windows. Para obter mais informações, consulte Alterar o modo de autenticação do servidor.

    • Se você precisar usar o SA login, habilite o login após o provisionamento e atribua uma nova senha forte.

Riscos de ransomware

Considere o seguinte para minimizar os riscos de ransomware:

  • A melhor estratégia para se proteger contra ransomware é prestar especial atenção às vulnerabilidades RDP e SSH. Além disso, considere as seguintes recomendações:
    • Utilize firewalls e bloqueie portas
    • Garantir que as atualizações de segurança mais recentes do sistema operacional e do aplicativo sejam aplicadas
    • Usar contas de serviço geridas de grupo (gMSA)
    • Limitar o acesso às máquinas virtuais
    • Exigir acesso Just-in-time (JIT) e Azure Bastion
    • Melhore a segurança da área de superfície evitando a instalação de ferramentas, incluindo sysinternals e SSMS, na máquina local
    • Evite instalar recursos, funções e habilitar serviços do Windows que não são necessários
    • Além disso, deve haver um backup completo regular agendado que seja protegido separadamente de uma conta de administrador comum para que não possa excluir cópias dos bancos de dados.

Conteúdo relacionado