Guia estratégico para tratar dos requisitos de segurança comuns no Banco de Dados SQL do Azure e na Instância Gerenciada de SQL do Azure

  • Artigo

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

Este artigo fornece as práticas recomendadas sobre como resolver requisitos de segurança comuns. Nem todos os requisitos são aplicáveis a todos os ambientes. Você deve consultar sua equipe de banco de dados e segurança para saber quais recursos implementar.

Observação

O Microsoft Entra ID era anteriormente conhecido como Azure Active Directory (Azure AD).

Resolver requisitos de segurança comuns

Este documento fornece orientação sobre como resolver requisitos de segurança comuns para aplicativos novos ou existentes usando o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure. Ele é organizado de acordo com áreas de segurança de alto nível. Para lidar com ameaças específicas, consulte a seção Ameaças de segurança comuns e possíveis mitigações. Embora algumas das recomendações apresentadas sejam aplicáveis ao migrar aplicativos locais para o Azure, os cenários de migração não são o foco deste documento.

Ofertas de implantação do Banco de Dados SQL do Azure abordadas neste guia

Ofertas de implantação não abordadas neste guia

  • Azure Synapse Analytics
  • VMs do SQL do Azure (IaaS)
  • SQL Server

Público

Os públicos-alvo deste guia são os clientes que estão se perguntando como proteger o Banco de Dados SQL do Azure. As funções de interesse neste artigo de práticas recomendadas incluem, mas não estão limitadas a:

  • Arquitetos de segurança
  • Gerentes de segurança
  • Responsáveis pela conformidade
  • Responsáveis pela privacidade
  • Engenheiros de segurança

Como usar este guia

Este documento foi criado para servir como complemento à nossa documentação de Segurança do Banco de Dados SQL do Azure.

A menos que indicado de outra forma, recomendamos que você siga todas as práticas recomendadas listadas em cada seção para atingir a respectiva meta ou requisito. Para atender a padrões de conformidade de segurança ou práticas recomendadas específicas, os controles de conformidade regulatória importantes ficam listados na seção Requisitos ou Metas sempre que aplicável. Estes são os padrões de segurança e as normas referenciadas neste documento:

Planejamos continuar atualizando as recomendações e as práticas recomendadas listadas aqui. Forneça comentários ou correções para este documento usando o link de Comentários na parte inferior deste artigo.

Autenticação

A autenticação é o processo de provar que o usuário é quem diz ser. O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure dão suporte a dois tipos de autenticação:

  • Autenticação SQL
  • autenticação do Microsoft Entra

Observação

A autenticação do Microsoft Entra pode não ter suporte em todas as ferramentas e aplicações de terceiros.

Gerenciamento central de identidades

O gerenciamento central de identidades oferece os seguintes benefícios:

  • Gerenciamento de contas de grupo e controle de permissões de usuário sem duplicar logons em servidores, bancos de dados e instâncias gerenciadas.
  • Gerenciamento de permissões simplificado e flexível.
  • Gerenciamento de aplicativos em escala.

Como implementar

  • Use a autenticação do Microsoft Entra para gerenciamento de identidades centralizado.

Práticas recomendadas

  • Crie um locatário do Microsoft Entra e crie usuários para representar usuários humanos e crie entidades de serviço para representar aplicativos, serviços e ferramentas de automação. As entidades de serviço são equivalentes às contas de serviço no Windows e no Linux.

  • Atribua direitos de acesso aos recursos de entidades de segurança do Microsoft Entra por meio da atribuição de grupo: crie grupos do Microsoft Entra, conceda acesso a grupos e adicione membros individuais aos grupos. Em seu banco de dados, crie usuários de banco de dados independente que mapeiem seus grupos do Microsoft Entra. Para atribuir permissões dentro do banco de dados, adicione os usuários de banco de dados independente que declaram seus grupos a funções de banco de dados ou conceda permissões a eles diretamente.

    Observação

    Na Instância Gerenciada de SQL, você também pode criar logons que são mapeados para entidades de segurança do Microsoft Entra no banco de dados master. Consulte CREATE LOGIN (Transact-SQL).

  • Usar os grupos do Microsoft Entra simplifica o gerenciamento de permissões. Além disso, o proprietário do grupo e o proprietário do recurso podem adicionar ou remover membros do grupo.

  • Crie um grupo separado para administradores do Microsoft Entra para cada servidor ou instância gerenciada.

  • Monitore as alterações de associação de grupo do Microsoft Entra usando relatórios de atividades de auditoria do Microsoft Entra ID.

  • No caso de uma instância gerenciada, é necessária uma etapa separada para criar um administrador do Microsoft Entra.

Observação

  • A autenticação do Microsoft Entra é registrada nos logs de auditoria do SQL do Azure, mas não nos logs de credenciais do Microsoft Entra.
  • As permissões RBAC do Azure concedidas no Azure não se aplicam ao Banco de Dados SQL do Azure ou às permissões da Instância Gerenciada de SQL do Azure. Essas permissões devem ser criadas/mapeadas manualmente usando as permissões de SQL existentes.
  • Do lado do cliente, a autenticação do Microsoft Entra precisa de acesso à Internet ou a uma rede virtual por meio de uma Rota Definida pelo Usuário (UDR).
  • O token de acesso do Microsoft Entra é armazenado em cache do lado do cliente e seu tempo de vida depende da configuração do token. Confira o artigo Tempos de vida configuráveis de tokens no Microsoft Entra ID
  • Para obter diretrizes sobre como solucionar problemas de autenticação do Microsoft Entra, confira o seguinte blog: Solução de problemas do Microsoft Entra ID.

Autenticação multifator do Microsoft Entra

Mencionado em: Prática de OSA #2, Controle de Acesso ISO (AC)

A autenticação multifator do Microsoft Entra ajuda a fornecer segurança adicional exigindo mais de uma forma de autenticação.

Como implementar

  • Habilite a autenticação multifator no Microsoft Entra ID usando o acesso condicional e use a autenticação interativa.

  • A alternativa é habilitar a autenticação multifator para todo o locatário do Microsoft Entra ou domínio do Active Directory.

Práticas recomendadas

Minimize o uso de autenticação com senha para usuários

Mencionado em: Prática de OSA #4, Controle de Acesso ISO (AC)

Os métodos de autenticação com senha são uma forma mais fraca de autenticação. As credenciais podem ser comprometidas ou fornecidas de maneira equivocada.

Como implementar

  • Use uma autenticação integrada do Microsoft Entra que elimine o uso de senhas.

Práticas recomendadas

  • Faça a autenticação de logon único usando as credenciais do Windows. Realize a federação do domínio do Active Directory local com o Microsoft Entra ID e use a autenticação integrada do Windows (para computadores conectados ao domínio com o Microsoft Entra ID).

Minimize o uso de autenticação com senha para aplicativos

Mencionado em: Prática de OSA #4, Controle de Acesso ISO (AC)

Como implementar

  • Habilite a identidade gerenciada do Azure. Você também pode usar a autenticação integrada ou com certificado.

Práticas recomendadas

Proteger senhas e segredos

Nos casos em que não é possível evitar o uso de senhas, verifique se elas estão protegidas.

Como implementar

  • Use o Azure Key Vault para armazenar senhas e segredos. Sempre que aplicável, use a autenticação multifator para o banco de dados SQL do Azure com usuários do Microsoft Entra.

Práticas recomendadas

  • Se não for possível evitar o uso de senhas ou segredos, armazene senhas de usuário e segredos de aplicativos no Azure Key Vault e gerencie o acesso por meio das políticas de acesso do Key Vault.

  • Várias estruturas de desenvolvimento de aplicativos também podem oferecer mecanismos específicos da estrutura para proteger segredos no aplicativo. Por exemplo: o aplicativo ASP.NET Core.

Usar a autenticação via SQL para aplicativos herdados

A autenticação via SQL consiste na autenticação de um usuário ao se conectar ao Banco de Dados SQL do Azure ou à Instância Gerenciada de SQL do Azure usando nome de usuário e senha. Será necessário criar um logon em cada servidor ou instância gerenciada, e um usuário precisará ser criado em cada banco de dados.

Como implementar

  • Use a autenticação do SQL.

Práticas recomendadas

Gerenciamento de acesso

O gerenciamento de acesso (também chamado de Autorização) é o processo de controle e gerenciamento do acesso e dos privilégios de usuários autorizados ao Banco de Dados SQL do Azure ou à Instância Gerenciada de SQL.

Aplicar o princípio de privilégios mínimos

Mencionado em: Controles FedRamp AC-06, NIST: AC-6, Prática de OSA #3

O princípio de privilégios mínimos indica que os usuários não devem ter mais privilégios do que os necessários para concluir suas tarefas. Para obter mais informações, consulte o artigo Administração Just Enough.

Como implementar

Atribua apenas as permissões necessárias para concluir as tarefas exigidas:

Práticas recomendadas

As práticas recomendadas a seguir são opcionais, mas resultarão em uma melhor capacidade de gerenciamento e suporte para a sua estratégia de segurança:

  • Se possível, comece com o menor conjunto possível de permissões e comece a adicionar permissões uma a uma se houver uma necessidade real (e uma justificativa), ao contrário do que acontece na abordagem oposta, que é remover as permissões passo a passo.

  • Evite atribuir permissões a usuários individuais. Use funções (funções de banco de dados ou de servidor) de forma consistente. As funções ajudam muito com as permissões de geração de relatório e solução de problemas. (O RBAC do Azure dá suporte à atribuição de permissão apenas por meio de funções.)

  • Crie e use funções personalizadas com as permissões exatamente necessárias. Funções tipicamente usadas na prática:

    • Implantação de segurança
    • Administrador
    • Desenvolvedor
    • Equipe de suporte
    • Auditor
    • Processos automatizados
    • Usuário final

  • Use funções internas somente quando as permissões das funções corresponderem exatamente às permissões necessárias para o usuário. Você pode atribuir várias funções a usuários.

  • Lembre-se de que as permissões no mecanismo de banco de dados podem ser aplicadas dentro dos seguintes escopos (quanto menor o escopo, menor o impacto das permissões concedidas):

    • Servidor (funções especiais no banco de dados master) no Azure
    • Backup de banco de dados
    • Esquema
      • É uma prática recomendada usar esquemas para conceder permissões dentro de um banco de dados.
    • Objeto (tabela, exibição, procedimento e assim por diante)

    Observação

    Não é recomendável aplicar permissões no nível de objeto porque esse nível adiciona complexidade desnecessária à implementação geral. Se você decidir usar permissões no nível de objeto, elas deverão ser claramente documentadas. O mesmo se aplica às permissões no nível de coluna, que são ainda menos recomendadas pelos mesmos motivos. Além disso, lembre-se de que, por padrão, uma DENY (negação) em nível de tabela não substitui uma GRANT (concessão) em nível de coluna. Isso exigiria que a configuração dos critérios comuns do servidor de conformidade fosse ativada.

  • Execute verificações regulares usando a VA (avaliação de vulnerabilidade) para testar se há muitas permissões.

Implementar a Separação de Tarefas

Mencionado em: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

A Separação de Tarefas, também chamada de Diferenciação de Tarefas, descreve a necessidade de dividir tarefas confidenciais em várias tarefas que são atribuídas a diferentes usuários. A Separação de Tarefas ajuda a evitar violações de dados.

Como implementar

  • Identifique o nível necessário de Separação de Tarefas. Exemplos:

    • Entre ambientes de desenvolvimento/teste e produção
    • Tarefas confidenciais de segurança versus tarefas de nível de gerenciamento do DBA (Administrador de Banco de Dados) versus tarefas de desenvolvedor.
      • Exemplos: auditor, criação de política de segurança para RLS (segurança em nível de função), implementação de objetos de Banco de Dados SQL com permissões DDL.

  • Identifique uma hierarquia abrangente de usuários (e processos automatizados) que acessam o sistema.

  • Crie funções de acordo com os grupos de usuários necessários e atribua permissões a funções.

    • Para tarefas em nível de gerenciamento no Portal do Azure ou por meio da automação do PowerShell, use funções do Azure. Localize uma função interna que corresponda ao requisito ou crie uma função personalizada do Azure usando as permissões disponíveis
    • Crie funções de servidor para tarefas em todo o servidor (criação de novos logons ou bancos de dados) em uma instância gerenciada.
    • Crie funções de banco de dados para tarefas no nível de banco de dados.

  • Para determinadas tarefas confidenciais, considere a criação de procedimentos armazenados especiais assinados por um certificado para executar as tarefas em nome dos usuários. Uma vantagem importante dos procedimentos armazenados assinados digitalmente é que, se o procedimento for alterado, as permissões concedidas à versão anterior do procedimento serão removidas imediatamente.

  • Implemente TDE (Transparent Data Encryption) com chaves gerenciadas pelo cliente no Azure Key Vault para habilitar a Separação de Tarefas entre o proprietário dos dados e o proprietário da segurança.

  • Para garantir que um DBA não possa ver os dados considerados altamente confidenciais e ainda possa realizar tarefas de DBA, você pode usar o Always Encrypted com separação de funções.

  • Nos casos em que o uso do Always Encrypted não é viável ou, pelo menos, que não ocorrerá sem grandes custos e esforços que podem até mesmo fazer com que o sistema fique quase inutilizável, as consequências podem ser assumidas e atenuadas com o uso de controles de compensação, como:

Práticas recomendadas

  • Certifique-se de que contas diferentes sejam usadas em ambientes de desenvolvimento/teste e produção. Contas diferentes ajudam a realizar a separação entre sistemas de teste e produção.

  • Evite atribuir permissões a usuários individuais. Use funções (funções de banco de dados ou de servidor) de forma consistente. Ter funções ajuda muito com as permissões de geração de relatório e solução de problemas.

  • Use funções internas quando as permissões corresponderem exatamente às permissões necessárias. Se a união de todas as permissões de várias funções internas levar a uma correspondência de 100%, você também poderá atribuir várias funções simultaneamente.

  • Crie e use funções definidas pelo usuário quando as funções internas concederem permissões demais ou insuficientes.

  • As atribuições de função também podem ser feitas temporariamente, o que é conhecido como DSD (Separação Dinâmica de Tarefas), dentro das etapas de trabalho do SQL Agent no T-SQL ou usando o Azure PIM para funções do Azure.

  • Certifique-se de que os DBAs não têm acesso às chaves de criptografia ou aos repositórios de chaves e que os administradores de segurança com acesso às chaves, por sua vez, não têm acesso ao banco de dados. O uso de EKM (Gerenciamento Extensível de Chaves) pode facilitar a realização dessa separação. O Azure Key Vault pode ser usado para implementar EKM.

  • Sempre certifique-se de ter uma trilha de auditoria para ações relacionadas à segurança.

  • Você pode recuperar a definição das funções internas do Azure para ver as permissões usadas e criar uma função personalizada com base em trechos e acumulações delas por meio do PowerShell.

  • Como qualquer membro da função de banco de dados db_owner pode alterar configurações de segurança como a TDE (Transparent Data Encryption) ou alterar o SLO (logoff único), essa associação deve ser concedida com cuidado. No entanto, muitas tarefas exigem privilégios de db_owner. Tarefas de alteração de qualquer configuração de banco de dados, como alterar opções de BD. A auditoria desempenha um papel fundamental em qualquer solução.

  • Não é possível restringir as permissões de um db_owner e, portanto, impedir que uma conta administrativa visualize dados de usuários. Se houver dados altamente confidenciais em um banco de dados, o Always Encrypted poderá ser usado para impedir com segurança os db_owners de visualizá-los.

Observação

Conseguir colocar em prática a SoD (Separação de Tarefas) é algo desafiador para tarefas relacionadas à segurança ou à solução de problemas. Outras áreas, como desenvolvimento e funções de usuário final, são mais fáceis de separar. A maioria dos controles relacionados à conformidade permite o uso de funções de controle alternativas, como a de Auditoria, quando outras soluções não forem práticas.

Para os leitores que desejam se aprofundar na SoD, recomendamos os seguintes recursos:

Realizar revisões de código constantes

Mencionado em: PCI: 6.3.2, SOC: SDL-3

A Separação de Tarefas não está limitada aos dados em um banco de dados, ela inclui o código do aplicativo. Um código mal-intencionado pode potencialmente burlar os controles de segurança. Antes de implantar o código personalizado na produção, é essencial revisar o que está sendo implantado.

Como implementar

  • Use uma ferramenta de banco de dados, como o Azure Data Studio, que ofereça suporte ao controle de código-fonte.

  • Implemente um processo de implantação de código segregado.

  • Antes de fazer commit para a ramificação principal, uma pessoa (diferente do autor do próprio código) precisa examinar o código para detectar uma potencial elevação de riscos de privilégios e modificações de dados mal-intencionadas para prevenir fraudes e acesso não autorizado. Isso pode ser feito usando mecanismos de controle de código-fonte.

Práticas recomendadas

  • Padronização: ajuda implementar um procedimento padrão que deve ser seguido em qualquer atualização de código.

  • A Avaliação de Vulnerabilidades contém regras que buscam permissões excessivas, uso de algoritmos de criptografia antigos e outros problemas de segurança em um esquema de banco de dados.

  • Verificações adicionais podem ser feitas em um ambiente de QA ou de teste usando a Proteção Avançada contra Ameaças, que busca códigos vulneráveis à injeção de SQL.

  • Exemplos do que deve ser examinado:

    • A criação de um usuário ou a alteração de configurações de segurança de dentro de uma implantação automatizada de atualização de código SQL.
    • Um procedimento armazenado, que, dependendo dos parâmetros fornecidos, atualiza um valor monetário em uma célula de uma forma que não respeita a conformidade.

  • Certifique-se de que a pessoa que realiza a revisão seja um indivíduo diferente do autor do código-fonte e seja especialista em revisões de código e em codificação segura.

  • Certifique-se de conhecer todas as fontes de alterações de código. O código pode estar em scripts T-SQL. Pode ser que comandos ad hoc sejam executados ou implantados em forma de exibições, funções, gatilhos e procedimentos armazenados. Ele pode fazer parte das definições de trabalho do SQL Agent (etapas). Ele também pode ser executado a partir de pacotes do SSIS, Azure Data Factory e outros serviços.

Proteção de dados

A proteção de dados é um conjunto de recursos que serve para proteger informações importantes de comprometimento por meio de criptografia ou ofuscação.

Observação

A Microsoft atesta que o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL está em conformidade com o FIPS 140-2 Nível 1. Isso é feito depois de verificar o uso estrito dos algoritmos aceitáveis do FIPS 140-2 Nível 1 e das instâncias validadas do FIPS 140-2 Nível 1 desses algoritmos, incluindo consistência com os comprimentos de chave, o gerenciamento de chaves, a geração de chaves e o armazenamento de chaves necessários. Esse atestado serve para permitir que nossos clientes respondam à necessidade ou ao requisito de uso de instâncias validadas do FIPS 140-2 Nível 1 no processamento de dados ou na entrega de sistemas ou aplicativos. Definimos os termos "Em conformidade com o FIPS 140-2 Nível 1" e "Conformidade com o FIPS 140-2 Nível 1" usados na instrução acima para demonstrar sua aplicabilidade em relação ao uso do governo canadense e norte-americano do termo "Validado para FIPS 140-2 Nível 1", que é diferente.

Criptografar dados em trânsito

Mencionado em: Prática de OSA #6, Família de Controle ISO: Criptografia

Protege seus dados enquanto os dados são transferidos entre o cliente e o servidor. Consulte Segurança de rede.

Criptografar dados em repouso

Mencionado em: Prática de OSA #6, Família de Controle ISO: Criptografia

A criptografia de dados inativos é a proteção criptográfica dos dados quando ela é mantida em arquivos de banco de dados, log e backup.

Como implementar

  • A TDE (Transparent Data Encryption) com chaves gerenciadas pelo serviço é habilitada por padrão em qualquer banco de dados criado após 2017 no Banco de Dados SQL do Azure e na Instância Gerenciada de SQL.
  • Em uma instância gerenciada, se o banco de dados for criado a partir de uma operação de restauração usando um servidor local, a configuração da TDE do banco de dados original será respeitada. Se o banco de dados original não estiver com a TDE habilitada, recomendamos que a TDE seja ativada manualmente para a instância gerenciada.

Práticas recomendadas

  • Não armazene dados inativos que exigem criptografia no banco de dados master. O banco de dados master não pode ser criptografado com TDE.

  • Use chaves gerenciadas pelo cliente no Azure Key Vault se precisar de maior transparência e controle granular sobre a proteção via TDE. O Azure Key Vault dá a capacidade de revogar permissões a qualquer momento para tornar o banco de dados inacessível. Você pode gerenciar centralmente os protetores da TDE junto com outras chaves ou fazer a rotação do protetor da TDE em seu próprio agendamento usando o Azure Key Vault.

  • Se você estiver usando chaves gerenciadas pelo cliente no Azure Key Vault, siga os artigos Diretrizes para configurar a TDE com o Azure Key Vault e Como configurar a Geo-DR com o Azure Key Vault.

Observação

Alguns itens considerados conteúdo do cliente, como nomes de tabela, de objeto e de índice, podem ser transmitidos em arquivos de log para obter suporte e solução de problemas da Microsoft.

Proteger dados confidenciais em uso de usuários com alto privilégio e não autorizados

Os dados em uso são os dados armazenados na memória do sistema de banco de dados durante a execução de consultas SQL. Se o seu banco de dados armazena dados confidenciais, pode ser que sua organização precise garantir que usuários com alto privilégio sejam impedidos de visualizar dados confidenciais em seu banco de dados. Os usuários de alto privilégio, como operadores da Microsoft ou DBAs da sua organização, devem ser capazes de gerenciar o banco de dados, mas impedidos de visualizar e potencialmente exfiltrar dados confidenciais da memória do processo SQL ou de consultar no banco de dados.

As políticas que determinam quais dados são confidenciais e se os dados confidenciais devem ser criptografados na memória e não podem ser acessados por administradores em texto não criptografado são específicas da sua organização e dos regulamentos de conformidade que você precisa cumprir. Consulte o requisito relacionado: Identificar e marcar dados confidenciais.

Como implementar

  • Use o Always Encrypted para garantir que os dados confidenciais não sejam expostos em texto não criptografado no Banco de Dados SQL do Azure ou a Instância Gerenciada de SQL, mesmo que esteja na memória/em uso. O Always Encrypted protege os dados de DBAs (Administradores de Banco de Dados) e administradores de nuvem (ou atores maliciosos que podem representar usuários com alto privilégio, mas não autorizados) e oferece mais controle sobre quem pode acessar seus dados.

Práticas recomendadas

  • O Always Encrypted não é um substituto para a criptografia de dados inativos (com TDE) ou em trânsito (com SSL/TLS). O Always Encrypted não deve ser usado com dados não confidenciais para minimizar o impacto no desempenho e na funcionalidade. Usar o Always Encrypted em conjunto com o TDE e o protocolo TLS (Transport Layer Security) é recomendado para proteção abrangente de dados em repouso, em trânsito e em uso.

  • Avalie o impacto de criptografar as colunas de dados confidenciais identificadas antes de implantar o Always Encrypted em um banco de dado em produção. Em geral, o Always Encrypted reduz a funcionalidade de consultas em colunas criptografadas e tem outras limitações, listadas em Always Encrypted - Detalhes do recurso. Portanto, talvez seja necessário rearquitetar seu aplicativo para reimplementar a funcionalidade que não é compatível com uma consulta no lado do cliente e/ou refatorar seu esquema de banco de dados, incluindo as definições de procedimentos armazenados, funções, exibições e gatilhos. Os aplicativos existentes podem não funcionar com colunas criptografadas se não aderirem às restrições e limitações do Always Encrypted. Embora o ecossistema de ferramentas, produtos e serviços da Microsoft que dão suporte ao Always Encrypted esteja crescendo, várias delas não funcionam com colunas criptografadas. A criptografia de uma coluna também pode afetar o desempenho da consulta, dependendo das características da carga de trabalho.

  • Gerencie as chaves do Always Encrypted com separação de função se você estiver usando o Always Encrypted para proteger dados de DBAs mal-intencionados. Com a separação de funções, um administrador de segurança cria as chaves físicas. O DBA cria a chave mestra de coluna e os objetos de metadados da chave de criptografia de coluna que descrevem as chaves físicas no banco de dados. Durante esse processo, o administrador de segurança não precisa acessar o banco de dados e o DBA não precisa acessar as chaves físicas em texto não criptografado.

  • Armazene suas chaves mestras de coluna no Azure Key Vault para facilitar o gerenciamento. Evite usar o repositório de certificados do Windows (e, em geral, as soluções distribuídas do repositório de chaves, como as soluções de gerenciamento de chaves centrais) que tornam o gerenciamento de chaves difícil.

  • Pense com cuidado sobre as vantagens e desvantagens de usar várias chaves (chave mestra de coluna ou chaves de criptografia de coluna). Mantenha o número de chaves pequeno para reduzir o custo de gerenciamento de chaves. Uma chave mestra de coluna e uma chave de criptografia de coluna por banco de dados geralmente são suficientes em ambientes estáveis (que não estão passando por uma rotação de chaves). Você poderá precisar de chaves adicionais se tiver grupos de usuários diferentes, cada um usando chaves diferentes e acessando dados diferentes.

  • Faça a rotação das chaves mestras de coluna de acordo com seus requisitos de conformidade. Se você também precisar fazer a rotação das chaves de criptografia de coluna, considere usar a criptografia online para minimizar o tempo de inatividade do aplicativo.

  • Use a criptografia determinística se as computações (igualdade) nos dados precisarem ter suporte. Caso contrário, use uma criptografia aleatória. Evite usar criptografia determinística para conjuntos de dados de baixa entropia ou conjuntos de dados com distribuição publicamente conhecida.

  • Se você estiver preocupado com terceiros acessando seus dados legalmente sem seu consentimento, garanta que todos os aplicativos e ferramentas com acesso às chaves e aos dados em texto não criptografado sejam executados fora da nuvem do Microsoft Azure. Sem acesso às chaves, o terceiro não terá como descriptografar os dados, a menos que ele quebre a criptografia.

  • O Always Encrypted não dá suporte fácil à concessão de acesso temporário às chaves (e aos dados protegidos). Por exemplo, se você precisar compartilhar as chaves com um DBA para permitir que o DBA faça algumas operações de limpeza em dados confidenciais e criptografados. A única maneira de revogar com segurança o acesso a dados do DBA será fazer a rotação das chaves de criptografia de coluna e das chaves mestras de coluna que protegem os dados, o que é uma operação cara.

  • Para acessar os valores em texto não criptografado em colunas criptografadas, um usuário precisa ter acesso à CMK (Chave Mestra de Coluna) que protege as colunas, configurada no repositório de chaves que contém a CMK. O usuário também precisa ter as permissões de banco de dados VIEW ANY COLUMN MASTER KEY DEFINITION e VIEW ANY COLUMN ENCRYPTION KEY DEFINITION.

Controlar o acesso de usuários de aplicativos a dados confidenciais por meio de criptografia

A criptografia pode ser usada como uma maneira de garantir que apenas usuários de aplicativos específicos que tenham acesso às chaves de criptografia possam exibir ou atualizar os dados.

Como implementar

  • Use CLE (Criptografia em Nível de Célula). Consulte o artigo Criptografar uma coluna de dados para obter detalhes.
  • Use o Always Encrypted, mas esteja ciente de suas limitações. As limitações estão listadas abaixo.

Práticas recomendadas:

Ao usar CLE:

  • Controle o acesso a chaves por meio de permissões e funções do SQL.

  • Use AES (AES 256 é recomendado) para criptografia de dados. Algoritmos, como RC4, DES e TripleDES, são preteridos e não devem ser usados por causa de vulnerabilidades conhecidas.

  • Proteja chaves simétricas com chaves/certificados assimétricos (não senhas) para evitar o uso do 3DES.

  • Tenha cuidado ao migrar um banco de dados usando a criptografia em nível de célula por meio de exportação/importação (arquivos bacpac).

Tenha em mente que o Always Encrypted é projetado principalmente para proteger dados confidenciais em uso de usuários de alto privilégio do Banco de Dados SQL do Azure (operadores da nuvem, DBAs). Consulte Proteger dados confidenciais em uso de usuários com alto privilégio e não autorizados. Esteja atento aos seguintes desafios ao usar o Always Encrypted para proteger dados de usuários de aplicativos:

  • Por padrão, todos os drivers de clientes da Microsoft que oferecem suporte ao Always Encrypted mantêm um cache global (um por aplicativo) de chaves de criptografia de coluna. Quando um driver de cliente adquire uma chave de criptografia de coluna em texto não criptografado contatando um repositório de chaves que mantém uma chave mestra de coluna, a chave de criptografia de coluna em texto não criptografado é armazenada em cache. Isso torna o isolamento de dados de usuários de um aplicativo com vários usuários desafiador. Se seu aplicativo representar os usuários finais ao interagir com um repositório de chaves (como o Azure Key Vault), depois que a consulta de um usuário popula o cache com uma chave de criptografia de coluna, uma consulta subsequente que requer a mesma chave, mas é disparada por outro usuário, usará a chave armazenada em cache. O driver não chamará o repositório de chaves e não verificará se o segundo usuário tem permissão para acessar a chave de criptografia de coluna. Como resultado, o usuário poderá ver os dados criptografados mesmo que não tenha acesso às chaves. Para conseguir fazer o isolamento de usuários em um aplicativo com vários usuários, você pode desabilitar o cache de chaves de criptografia de coluna. A desabilitação do cache causará sobrecargas de desempenho adicionais, pois o driver precisará contatar o repositório de chaves em cada operação de criptografia ou descriptografia de dados.

Proteger dados contra visualização não autorizada por usuários de aplicativos enquanto preserva o formato de dados

Outra técnica para impedir que usuários não autorizados visualizem dados é ofuscar ou mascarar os dados, preservando os tipos de dados e formatos para garantir que os aplicativos de usuários possam continuar manipulando e exibindo os dados.

Como implementar

Observação

O Always Encrypted não funciona com a Máscara Dinâmica de Dados. Não é possível criptografar e mascarar a mesma coluna, o que significa que você precisa priorizar a proteção de dados em uso versus mascarar os dados para os usuários de aplicativos por meio da Máscara Dinâmica de Dados.

Práticas recomendadas

Observação

A Máscara Dinâmica de Dados não pode ser usada para proteger dados de usuários de alto privilégio. As políticas de mascaramento não se aplicam a usuários com acesso administrativo como db_owner.

  • Não permita que os usuários de aplicativos executem consultas ad hoc (pois eles podem contornar Máscara Dinâmica de Dados).

  • Use uma política de controle de acesso apropriada (por meio de permissões, funções e RLS do SQL) para limitar as permissões para usuários fazerem atualizações nas colunas mascaradas. Criar uma máscara em uma coluna não impede atualizações nessa coluna. Os usuários que recebem dados mascarados ao consultar a coluna mascarada podem atualizar os dados se tiverem permissões de gravação.

  • A Máscara Dinâmica de Dados não preserva as propriedades estatísticas dos valores mascarados. Isso pode afetar os resultados da consulta (por exemplo, consultas que contêm predicados de filtragem ou junções nos dados mascarados).

Segurança de rede

Segurança de rede consiste em controles de acesso e práticas recomendadas para proteger seus dados em trânsito para o Banco de Dados SQL do Azure.

Configurar meu cliente para se conectar com segurança ao Banco de Dados SQL/à Instância Gerenciada de SQL

Práticas recomendadas sobre como impedir que computadores cliente e aplicativos com vulnerabilidades conhecidas (por exemplo, aqueles que usam protocolos TLS e conjuntos de codificação mais antigos) de se conectarem ao Banco de Dados SQL do Azure e a Instância Gerenciada de SQL.

Como implementar

  • Certifique-se de que os computadores cliente que se conectam ao Banco de Dados SQL do Azure e à Instância Gerenciada de SQL estão usando o protocolo TLS.

Práticas recomendadas

  • Impor uma versão TLS mínima no nível Banco de Dados SQL ou Instância Gerenciada de SQL usando uma configuração mínima de versão TLS. Depois de você confirmar que os aplicativos dão suporte ao protocolo, é recomendável definir a versão mínima do TLS como 1.2. O TLS 1.2 inclui correções para vulnerabilidades encontradas em versões anteriores.

  • Configure todos os seus aplicativos e ferramentas para se conectarem ao Banco de Dados SQL com criptografia habilitada

    • Encrypt = On, TrustServerCertificate = Off (ou equivalente em drivers que não são da Microsoft).

  • Se seu aplicativo usa um driver que não dá suporte a TLS ou que oferece suporte a uma versão mais antiga do TLS, substitua o driver, se possível. Se não for possível, avalie cuidadosamente os riscos de segurança.

Minimizar a superfície de ataque

Minimize o número de recursos que podem ser atacados por um usuário mal-intencionado. Implemente controles de acesso à rede para o Banco de Dados SQL do Azure.

Mencionado em: Prática de OSA #5

Como implementar

No Banco de Dados SQL:

  • Defina Permitir Acesso aos Serviços do Azure como DESATIVADO no nível do servidor
  • Use pontos de extremidade de serviço VNet e regras de firewall VNet.
  • Usar um Link Privado.

Na Instância Gerenciada do SQL:

Práticas recomendadas

  • Restrição do acesso ao Banco de Dados SQL do Azure e à Instância Gerenciada de SQL conectando-se a um ponto de extremidade privado (por exemplo, usando um caminho de dados privado):

    • Uma instância gerenciada pode ser isolada dentro de uma rede virtual para impedir o acesso externo. Os aplicativos e as ferramentas que estão na mesma rede virtual ou em uma rede virtual emparelhada na mesma região podem acessá-la diretamente. Aplicativos e ferramentas que estão em regiões diferentes podem usar a conexão de rede virtual para rede virtual ou o emparelhamento de circuito do ExpressRoute para estabelecer uma conexão. O cliente deve usar NSG (Grupos de Segurança de Rede) para restringir o acesso pela porta 1433 somente a recursos que exigem acesso a uma instância gerenciada.
    • Para um Banco de Dados SQL, use o recurso Link Privado, que fornece um IP privado dedicado para o servidor dentro de sua rede virtual. Você também pode usar Pontos de extremidade de serviço de rede virtual com regras de firewall de rede virtual para restringir o acesso aos servidores.
    • Os usuários em dispositivos móveis devem usar conexões VPN ponto a site para se conectarem por meio do caminho de dados.
    • Os usuários conectados à sua rede local devem usar a conexão VPN site a site ou o ExpressRoute para se conectarem por meio do caminho de dados.

  • Você pode acessar o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL conectando-se a um ponto de extremidade público (por exemplo, usando um caminho de dados público). As seguintes práticas recomendadas devem ser consideradas:

    Observação

    O ponto de extremidade público da Instância Gerenciada de SQL não está habilitado por padrão e deve ser habilitado explicitamente. Se a política da empresa não permitir o uso de pontos de extremidade públicos, use o Azure Policy para impedir a habilitação de pontos de extremidade públicos em primeiro lugar.

  • Configure componentes de rede do Azure:

Configure o Power BI para conexões seguras para o Banco de Dados SQL/Instância Gerenciada de SQL

Práticas recomendadas

Configure o Serviço de Aplicativo para conexões seguras para o Banco de Dados SQL/Instância Gerenciada de SQL

Práticas recomendadas

Configurar o host da máquina virtual do Azure para fazer conexões seguras com o Banco de Dados SQL ou a Instância Gerenciada de SQL

Práticas recomendadas

  • Use uma combinação de regras de permissão e negação nos NSGs de máquinas virtuais do Azure para controlar quais regiões podem ser acessadas por meio da VM.

  • Verifique se sua VM está configurada de acordo com o artigo Práticas recomendadas de segurança para cargas de trabalho de IaaS no Azure.

  • Verifique se todas as VMs estão associadas a uma rede virtual e a uma sub-rede específicas.

  • Avalie se você precisa da rota padrão 0.0.0.0/Internet conforme a orientação em sobre o túnel forçado.

    • Se sim (por exemplo, a sub-rede de front-end), mantenha a rota padrão.
    • Caso contrário (por exemplo, a camada intermediária ou a sub-rede de back-end), então habilite o túnel forçado para que nenhum tráfego passe pela Internet para alcançar um local (ou seja, entre locais).

  • Implemente rotas padrão opcionais se você estiver usando o emparelhamento ou conectando-se a um local.

  • Implemente rotas definidas pelo usuário se você precisar enviar todo o tráfego na rede virtual para uma solução de virtualização de rede para inspecionar pacotes.

  • Use pontos de extremidade de serviço de rede virtual para proteger o acesso aos serviços de PaaS, como o Armazenamento do Azure, por meio da rede de backbone do Azure.

Proteção contra ataques de DDoS (Negação de Serviço Distribuído)

Ataques de DDoS (Negação de Serviço Distribuído) são tentativas que um usuário mal-intencionado faz para inundar o tráfego de rede para o Banco de Dados SQL do Azure com o objetivo de sobrecarregar a infraestrutura do Azure e fazer com que ela rejeite logons válidos e cargas de trabalho válidas.

Mencionado em: Prática de OSA #9

Como implementar

A proteção contra DDoS está habilitada automaticamente como parte da Plataforma Azure. Ela inclui monitoramento de tráfego Always On e mitigação em tempo real de ataques em nível de rede em pontos de extremidade públicos.

Práticas recomendadas

  • Seguir as práticas descritas em Minimizar a superfície de ataque ajuda a minimizar as ameaças de ataque de DDoS.

  • O alerta de Credenciais SQL de força bruta da Proteção Avançada contra Ameaças ajuda a detectar ataques de força bruta. Em alguns casos, o alerta pode até mesmo distinguir cargas de trabalho de testes de penetração.

  • Para aplicativos host da VM do Azure que se conectam ao Banco de Dados SQL:

    • Siga a recomendação de Restringir o acesso por meio de pontos de extremidade para a Internet no Microsoft Defender para Nuvem.
    • Use conjuntos de dimensionamento de máquinas virtuais para executar várias instâncias do seu aplicativo em VMs do Azure.
    • Desabilite o RDP e o SSH da Internet para evitar ataques de força bruta.

Monitoramento, registro em log e auditoria

Esta seção refere-se aos recursos que irão ajudá-lo a detectar atividades anormais que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. Ela também descreve as práticas recomendadas para configurar a auditoria de banco de dados com o objetivo de rastrear e capturar eventos de banco de dados.

Proteger bancos de dados contra ataques

A Proteção Avançada contra Ameaças permite detectar e responder a ameaças potenciais à medida que elas ocorrem fornecendo alertas de segurança sobre atividades anormais.

Como implementar

  • Use a Proteção Avançada contra Ameaças para SQL para detectar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados, incluindo:
    • Ataque de Injeção de SQL.
    • Roubo/vazamento de credenciais.
    • Abuso de privilégio.
    • Exfiltração dos dados.

Práticas recomendadas

  • Configure o Microsoft Defender para SQL para um servidor específico ou uma instância gerenciada. Você também pode configurar o Microsoft Defender para SQL para todos os servidores e instâncias gerenciadas em uma assinatura habilitando o Microsoft Defender para Nuvem.

  • Para obter uma experiência de investigação completa, é recomendável habilitar aAuditoria do Banco de Dados SQL. Com a auditoria, você pode acompanhar eventos de banco de dados e gravá-los em um log de auditoria em uma conta de Armazenamento do Azure ou no workspace do Azure Log Analytics.

Auditar eventos de segurança críticos

O rastreamento de eventos de banco de dados ajuda a entender a atividade no banco de dados. Você pode obter informações sobre discrepâncias e anomalias que podem indicar preocupações para os negócios ou suspeitas de violações de segurança. Ele também habilita e facilita a adesão aos padrões de conformidade.

Como implementar

  • Habilite a Auditoria do Banco de Dados SQL ou a Auditoria da Instância Gerenciada para rastrear eventos de banco de dados e gravá-los em um log de auditoria em sua conta de Armazenamento do Azure, em um workspace do log Analytics (versão prévia) ou em hubs de eventos (versão prévia).

  • Logs de auditoria podem ser gravados em uma conta de Armazenamento do Azure, em um workspace do Log Analytics para consumo dos logs do Azure Monitor ou em um hub de eventos para consumo usando o hub de eventos. Você pode configurar qualquer combinação dessas opções, e os logs de auditoria serão gravados em cada uma.

Práticas recomendadas

  • Ao configurar a Auditoria do Banco de Dados SQL no servidor ou a Auditoria da Instância Gerenciada para eventos de auditoria, todos os bancos de dados existentes e recém-criados nesse servidor serão auditados.
  • Por padrão, a política de auditoria inclui todas as ações (consultas, procedimentos armazenados e logons bem-sucedidos e com falha) relacionadas aos bancos de dados, o que pode resultar em alto volume de logs de auditoria. É recomendável que os clientes configurem a auditoria para diferentes tipos de ações e grupos de ações usando o PowerShell. Configurar isso ajudará a controlar o número de ações auditadas e minimizará o risco de perda de eventos. As configurações de auditoria personalizadas permitem que os clientes capturem apenas os dados de auditoria necessários.
  • Os logs de auditoria podem ser consumidos diretamente no Portal do Azure ou do local de armazenamento em que foram configurados.

Observação

Habilitar a auditoria no Log Analytics incorrerá em custo com base nas taxas de ingestão. Esteja ciente do custo associado ao uso dessa opçãoou considere armazenar os logs de auditoria em uma conta de armazenamento do Azure.

Outros recursos

Logs de auditoria seguros

Restringir o acesso à conta de armazenamento para dar suporte à Separação de Tarefas e para separar DBAs de Auditores.

Como implementar

  • Ao salvar os logs de auditoria no Armazenamento do Azure, certifique-se de que o acesso à conta de armazenamento seja restrito aos princípios de segurança mínima. Controle quem pode acessar a conta de armazenamento.
  • Para obter mais informações, consulte Autorização de acesso ao Armazenamento do Azure.

Práticas recomendadas

Gerenciamento de Segurança

Esta seção descreve os diferentes aspectos e práticas recomendadas para o gerenciamento da postura de segurança de bancos de dados. Ela inclui as práticas recomendadas usadas para garantir que seus bancos de dados estejam configurados e possam atender aos padrões de segurança e para descobrir, classificar e controlar o acesso a dados potencialmente confidenciais em seus bancos.

Garantir que os bancos de dados estão configurados para atender às práticas recomendadas de segurança

Aprimore de forma proativa a segurança do banco de dados descobrindo e corrigindo possíveis vulnerabilidades do banco de dados.

Como implementar

Práticas recomendadas

  • Inicialmente, execute a VA em seus bancos de dados e itere corrigindo verificações com falha opostas às práticas recomendadas de segurança. Configure linhas de base para configurações aceitáveis até que a verificação fique limpaou até que todas as verificações tenham sido aprovadas.

  • Configure a execução semanal de verificações recorrentes e periódicas e configure quem será a pessoa relevante que deve receber emails com os resumos.

  • Revise o resumo da VA após cada verificação semanal. Caso encontre quaisquer vulnerabilidades, avalie a diferença em relação ao resultado da verificação anterior e determine se a verificação deve ser resolvida. Examine se há um motivo legítimo para a alteração na configuração.

  • Resolva verificações e atualize linhas de base quando relevante. Crie itens de tíquete para resolver ações e acompanhe-os até que eles sejam resolvidos.

Outros recursos

Identificar e marcar dados confidenciais

Descubra colunas que potencialmente contêm dados confidenciais. O que é considerado dado confidencial depende muito do cliente, da regulamentação de conformidade etc. e precisa ser avaliado pelos usuários encarregados desses dados. Classifique as colunas para usar cenários de proteção e auditoria com base em confidencialidade avançada.

Como implementar

  • Use a Descoberta e Classificação de dados SQL para descobrir, classificar, rotular e proteger os dados confidenciais em seus bancos de dados.
    • Exiba as recomendações de classificação criadas pela descoberta automática no painel Descoberta e Classificação de dados SQL. Aceite as classificações relevantes, de modo que seus dados confidenciais sejam marcados persistentemente com marcas de classificação.
    • Adicione manualmente classificações para quaisquer campos de dados confidenciais adicionais que não foram descobertos pelo mecanismo automatizado.
  • Para obter mais informações, consulte Descoberta e classificação de dados SQL.

Práticas recomendadas

  • Monitore o painel de classificação regularmente para obter uma avaliação precisa do estado da classificação do banco de dados. Um relatório sobre o estado da classificação do banco de dados pode ser exportado ou impresso para compartilhamento por fins de conformidade e auditoria.

  • Monitore continuamente o status dos dados confidenciais recomendados na Avaliação de Vulnerabilidades do SQL. Acompanhe a regra de descoberta de dados confidenciais e identifique qualquer diferença nas colunas recomendadas para classificação.

  • Use a classificação da forma adequada às necessidades específicas de sua organização. Personalize sua política de Proteção de Informações (marcas de confidencialidade, tipos de informações, lógica de descoberta) na política de Proteção de Informações do SQL no Microsoft Defender para Nuvem.

Acompanhar o acesso aos dados confidenciais

Monitore quem acessa dados confidenciais e capture consultas de dados confidenciais em logs de auditoria.

Como implementar

Práticas recomendadas

Visualizar o status de segurança e conformidade

Use um sistema de gerenciamento de segurança de infraestrutura unificado que fortaleça a postura de segurança de seus data centers (incluindo os bancos de dados no Banco de Dados SQL). Exiba uma lista de recomendações relacionadas à segurança de seus bancos de dados e ao status de conformidade.

Como implementar

Ameaças comuns de segurança e possíveis mitigações

Esta seção ajuda a localizar medidas de segurança para proteção contra determinados vetores de ataque. Espera-se que a maioria das mitigações possa ser obtida seguindo uma ou mais das diretrizes de segurança acima.

Ameaça de segurança: exfiltração dos dados

A exfiltração dos dados é a cópia, transferência ou recuperação não autorizada de dados de um computador ou servidor. Consulte uma definição para Exfiltração dos dados na Wikipédia.

Conectar-se ao servidor por meio de um ponto de extremidade público apresenta um risco de exfiltração dos dados, pois exige que os clientes abram seus firewalls a IPs públicos.

Cenário 1: um aplicativo em uma VM do Azure se conecta a um banco de dados no Banco de Dados SQL do Azure. Um ator não autorizado obtém acesso à VM e a compromete. Nesse cenário, exfiltração dos dados significa que uma entidade externa que usa a VM conecta-se ao banco de dados, copia dados pessoais e os armazena em um armazenamento de Blobs ou em um Banco de Dados SQL diferente de uma assinatura diferente.

Cenário 2: um DBA invasor. Esse cenário geralmente é gerado por clientes com segurança de dados confidenciais de setores regulamentados. Nesse cenário, um usuário de alto privilégio pode copiar dados do Banco de Dados SQL do Azure para outra assinatura não controlada pelo proprietário dos dados.

Possíveis mitigações

Hoje, o Banco de Dados SQL do Azure e a Instância Gerenciada de SQL oferecem as seguintes técnicas para mitigar as ameaças de vazamento:

  • Use uma combinação de regras de permissão e negação nos NSGs de VMs do Azure para controlar quais regiões podem ser acessadas por meio da VM.
  • Se estiver usando um servidor no Banco de Dados SQL, defina as seguintes opções:
    • Permitir Serviços do Azure deve ser DESATIVADO.
    • Permita somente o tráfego da sub-rede que contém sua VM do Azure configurando uma regra de firewall VNet.
    • Usar um Link Privado
  • Para a Instância Gerenciada de SQL, usar o acesso via IP privado por padrão resolve a primeira preocupação de exfiltração dos dados de uma VM não autorizada. Ative o recurso de delegação de sub-rede em uma sub-rede para definir automaticamente a política mais restritiva em uma sub-rede da Instância Gerenciada de SQL.
  • O problema de ter um DBA não autorizado fica mais exposto com a Instância Gerenciada de SQL, pois há uma área de superfície maior e os requisitos de rede são visíveis para os clientes. A melhor mitigação para isso é aplicar todas as práticas neste guia de segurança para evitar o cenário do DBA não autorizado em primeiro lugar (não apenas para exfiltração dos dados). O Always Encrypted é um método usado para proteger dados confidenciais criptografando-os e mantendo a chave inacessível para o DBA.

Aspectos de segurança da continuidade e disponibilidade dos negócios

A maioria dos padrões de segurança aborda a disponibilidade de dados em termos de continuidade operacional, obtida via implementação de redundância e recursos de failover para evitar pontos únicos de falha. Para cenários de desastre, é uma prática comum manter backups de arquivos de dados e de log. A seção a seguir fornece uma visão geral de alto nível dos recursos internos do Azure. Ele também fornece opções adicionais que podem ser configuradas para atender a necessidades específicas:

Próximas etapas