Partilhar via

Playbook para abordar requisitos de segurança comuns com o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure

  • Artigo

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

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

Nota

Microsoft Entra ID é o novo nome para o Azure Ative Directory (Azure AD). Estamos atualizando a documentação neste momento.

Resolver requisitos comuns de segurança

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 SQL do Azure. É organizado por áreas de segurança de alto nível. Para lidar com ameaças específicas, consulte a seção Ameaças comuns à segurança e possíveis atenuações . Embora algumas das recomendações apresentadas sejam aplicáveis ao migrar aplicativos do local 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
  • Azure SQL VMs (IaaS)
  • SQL Server

Audiência

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

  • Arquitetos de Segurança
  • Gestores de Segurança
  • Responsáveis pela conformidade
  • Responsáveis pela privacidade
  • Engenheiros de Segurança

Como utilizar este guia

Este documento destina-se a complementar a nossa documentação de segurança existente da Base de Dados SQL do Azure.

Salvo indicação em contrário, recomendamos que siga todas as práticas recomendadas listadas em cada secção para atingir o respetivo objetivo ou requisito. Para atender a padrões específicos de conformidade de segurança ou práticas recomendadas, importantes controles de conformidade regulatória são listados na seção Requisitos ou metas, sempre que aplicável. Estas são as normas e regulamentos de segurança que são referenciados neste artigo:

Pretendemos continuar a atualizar as recomendações e as melhores práticas listadas aqui. Forneça informações ou quaisquer correções para este documento usando o link Comentários na parte inferior deste artigo.

Autenticação

A autenticação é o processo de provar que o utilizador é quem diz ser. A Base de Dados SQL do Azure e a Instância Gerida SQL suportam dois tipos de autenticação:

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

Nota

A autenticação do Microsoft Entra pode não ser suportada para todas as ferramentas e aplicativos de terceiros.

Gerenciamento central de identidades

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

  • Gerencie contas de grupo e controle as permissões do usuário sem duplicar logins entre servidores, bancos de dados e instâncias gerenciadas.
  • Gestão de permissões simplificada e flexível.
  • Gestão de aplicações em escala.

Como implementar

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

Melhores práticas

  • 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 Linux.

  • Atribua direitos de acesso a recursos a entidades do Microsoft Entra por meio de 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 contidos que mapeiam para seus grupos do Microsoft Entra. Para atribuir permissões dentro do banco de dados, adicione os usuários de banco de dados contidos que representam seus grupos a funções de banco de dados ou conceda permissões a eles diretamente.

    Nota

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

  • Usar grupos do Microsoft Entra simplifica o gerenciamento de permissões e tanto o proprietário do grupo quanto o proprietário do recurso podem adicionar/remover membros de/para o grupo.

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

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

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

Nota

  • A autenticação do Microsoft Entra é registrada nos logs de auditoria SQL do Azure, mas não nos logs de entrada do Microsoft Entra.
  • As permissões do Azure RBAC concedidas no Azure não se aplicam às permissões do Banco de Dados SQL do Azure ou da Instância Gerenciada do SQL. Essas permissões devem ser criadas/mapeadas manualmente usando permissões SQL existentes.
  • No lado do cliente, a autenticação do Microsoft Entra precisa de acesso à Internet ou via UDR (User Defined Route) para uma rede virtual.
  • O token de acesso do Microsoft Entra é armazenado em cache no lado do cliente e seu tempo de vida depende da configuração do token. Consulte o artigo, Tempos de vida de token configuráveis no Microsoft Entra ID
  • Para obter orientação sobre como solucionar problemas de autenticação do Microsoft Entra, consulte o seguinte blog: Solucionando problemas do Microsoft Entra ID.

Autenticação multifator Microsoft Entra

Mencionado em: OSA Practice #2, ISO Access Control (AC)

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

Como implementar

Melhores práticas

  • Ative o Acesso Condicional no Microsoft Entra ID (requer assinatura Premium).

  • Crie grupos(s) do Microsoft Entra e habilite a política de autenticação multifator para grupos selecionados usando o Acesso Condicional do Microsoft Entra.

  • A autenticação multifator pode ser habilitada para todo o locatário do Microsoft Entra ou para o Ative Directory federado com o Microsoft Entra ID.

  • Use o modo de autenticação interativa do Microsoft Entra para o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure, onde uma senha é solicitada interativamente, seguida pela autenticação multifator:

  • Implemente seus aplicativos para se conectar ao Banco de Dados SQL do Azure ou à Instância Gerenciada SQL do Azure usando autenticação interativa com suporte à autenticação multifator.

    Nota

    Esse modo de autenticação requer identidades baseadas no usuário. Nos casos em que é usado um modelo de identidade confiável que ignora a autenticação de usuário individual do Microsoft Entra (por exemplo, usando identidade gerenciada para recursos do Azure), a autenticação multifator não se aplica.

Minimizar o uso de autenticação baseada em senha para usuários

Mencionado em: OSA Practice #4, ISO Access Control (AC)

Os métodos de autenticação baseados em senha são uma forma mais fraca de autenticação. As credenciais podem ser comprometidas ou entregues por engano.

Como implementar

  • Use a autenticação integrada Microsoft Entra que elimina o uso de senhas.

Melhores práticas

  • Use a autenticação de logon único usando credenciais do Windows. Federar o domínio do Ative Directory local com o Microsoft Entra ID e usar a autenticação integrada do Windows (para máquinas ingressadas no domínio com o Microsoft Entra ID).

Minimizar o uso de autenticação baseada em senha para aplicativos

Mencionado em: OSA Practice #4, ISO Access Control (AC)

Como implementar

  • Habilite o Azure Managed Identity. Você também pode usar a autenticação integrada ou baseada em certificado.

Melhores práticas

Proteja palavras-passe e segredos

Para os casos em que as palavras-passe não são evitáveis, certifique-se de que estão protegidas.

Como implementar

  • Use o Cofre da Chave do Azure 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.

Melhores práticas

  • Se não for possível evitar palavras-passe ou segredos, armazene palavras-passe de utilizador e segredos de aplicações no Cofre de Chaves do Azure e faça a gestão do acesso através das políticas de acesso do Cofre de Chaves.

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

Usar a autenticação SQL para aplicativos herdados

A autenticação SQL refere-se à autenticação de um usuário ao se conectar ao Banco de Dados SQL do Azure ou à Instância Gerenciada do SQL usando nome de usuário e senha. Será necessário criar um login em cada servidor ou instância gerenciada e um usuário em cada banco de dados.

Como implementar

  • Use a autenticação SQL.

Melhores práticas

Gestão de acesso

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

Implementar o princípio do menor privilégio

Mencionado em: FedRamp controla AC-06, NIST: AC-6, OSA Practice #3

O princípio do menor privilégio afirma que os usuários não devem ter mais privilégios do que o necessário para concluir suas tarefas. Para obter mais informações, consulte o artigo Administração suficiente.

Como implementar

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

Melhores práticas

As seguintes práticas recomendadas são opcionais, mas resultarão em melhor capacidade de gerenciamento e suporte da 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 justificativa) – em oposição à abordagem oposta: tirar as permissões passo a passo.

  • Abster-se de atribuir permissões a usuários individuais. Em vez disso, use funções (funções de banco de dados ou de servidor) de forma consistente. As funções ajudam muito com permissões de geração de relatórios e solução de problemas. (O RBAC do Azure só dá suporte à atribuição de permissões por meio de funções.)

  • Crie e use funções personalizadas com as permissões exatas necessárias. Funções típicas que são usadas na prática:

    • Implantação de segurança
    • Administrador
    • Programador
    • Pessoal de apoio
    • Auditor
    • Processos automatizados
    • Utilizador 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 usuários a várias funções.

  • 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 master banco de dados) no Azure
    • Base 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)

    Nota

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

  • Execute verificações regulares usando a Avaliação de Vulnerabilidade (VA) para testar muitas permissões.

Implementar a separação de funções

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 Funções, também chamada de Segregação de Funções, descreve o requisito de dividir tarefas sensíveis em várias tarefas que são atribuídas a diferentes usuários. A separação de funções ajuda a evitar violações de dados.

Como implementar

  • Identificar o nível necessário de Separação de Funções. Exemplos:

    • Entre ambientes de desenvolvimento/teste e produção
    • Tarefas sensíveis em termos de segurança vs tarefas de nível de gerenciamento DBA (Database Administrator) vs tarefas de desenvolvedor.
      • Exemplos: Auditor, criação de política de segurança para Segurança em Nível de Função (RLS), Implementação de objetos do Banco de Dados SQL com permissões DDL.

  • Identificar 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 de nível de gerenciamento no portal do Azure ou por meio da automação do PowerShell, use as funções do Azure. Encontre uma função interna correspondente 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 logins, 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 imediatamente removidas.

  • Implemente a Criptografia de Dados Transparente (TDE) com chaves gerenciadas pelo cliente no Cofre de Chaves do Azure para habilitar a Separação de Funções entre o proprietário dos dados e o proprietário da segurança.

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

  • Nos casos em que o uso do Always Encrypted não é viável, ou pelo menos não sem grandes custos e esforços que podem até tornar o sistema quase inutilizável, compromissos podem ser feitos e mitigados através do uso de controles compensadores, tais como:

    • Intervenção humana em processos.
    • Trilhas de auditoria – para obter mais informações sobre auditoria, consulte Auditar eventos críticos de segurança.

Melhores práticas

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

  • Abster-se de atribuir permissões a usuários individuais. Em vez disso, use funções (funções de banco de dados ou de servidor) de forma consistente. Ter funções ajuda muito com permissões de relatórios 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 muitas permissões ou permissões insuficientes.

  • As atribuições de função também podem ser feitas temporariamente, também conhecidas como DSD (Separação Dinâmica de Funções), 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 tenham acesso às chaves de criptografia ou armazenamentos de chaves e que os administradores de segurança com acesso às chaves não tenham acesso ao banco de dados por sua vez. A utilização da Gestão Extensível de Chaves (EKM) pode tornar esta separação mais fácil de alcançar. O Azure Key Vault pode ser usado para implementar o EKM.

  • Certifique-se sempre 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 dessas por meio do PowerShell.

  • Como qualquer membro da função de banco de dados db_owner pode alterar configurações de segurança, como TDE (Transparent Data Encryption), ou alterar o SLO, essa associação deve ser concedida com cuidado. No entanto, há muitas tarefas que exigem privilégios de db_owner. Tarefa como alterar qualquer configuração de banco de dados, como alterar opções de banco de dados. 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 os dados do usuário. Se houver dados altamente confidenciais em um banco de dados, o Always Encrypted pode ser usado para impedir com segurança que db_owners ou qualquer outro DBA os visualize.

Nota

Alcançar a Separação de Funções (SoD) é um desafio 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 segregar. A maioria dos controles relacionados à conformidade permite o uso de funções de controle alternativas, como auditoria, quando outras soluções não são práticas.

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

Realizar revisões regulares de código

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

A separação de funções não se limita aos dados de uma base de dados, mas inclui o código da aplicação. O código malicioso pode potencialmente contornar os controlos 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 dá suporte ao controle do código-fonte.

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

  • Antes de se comprometer com a ramificação principal, uma pessoa (que não seja o próprio autor do código) tem que inspecionar o código quanto a possíveis riscos de elevação de privilégios, bem como modificações de dados mal-intencionados para proteger contra fraudes e acesso não autorizado. Isso pode ser feito usando mecanismos de controle do código-fonte.

Melhores práticas

  • Padronização: Ajuda a implementar um procedimento padrão que deve ser seguido para quaisquer atualizações de código.

  • A Avaliação de Vulnerabilidade contém regras que verificam permissões excessivas, o 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 controle de qualidade ou teste usando a Proteção Avançada contra Ameaças que verifica se há código vulnerável à injeção de SQL.

  • Exemplos do que procurar:

    • Criação de um usuário ou alteração de configurações de segurança a partir 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 forma não conforme.

  • Certifique-se de que a pessoa que conduz a revisão é um indivíduo diferente do autor do código de origem e conhecedor de revisões de código e 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 comandos ad hoc a serem executados ou implantados em formas de Exibições, Funções, Gatilhos e Procedimentos Armazenados. Ele pode fazer parte das definições de trabalho do SQL Agent (Etapas). Também pode ser executado a partir de pacotes SSIS, Azure Data Factory e outros serviços.

Proteção de dados

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

Nota

A Microsoft atesta o Banco de Dados SQL do Azure e a Instância Gerenciada SQL como sendo compatíveis com FIPS 140-2 Nível 1. Isso é feito depois de verificar o uso estrito de algoritmos aceitáveis FIPS 140-2 Nível 1 e instâncias validadas FIPS 140-2 Nível 1 desses algoritmos, incluindo consistência com comprimentos de chave necessários, gerenciamento de chaves, geração de chaves e armazenamento de chaves. Este atestado destina-se a permitir que nossos clientes respondam à necessidade ou exigência do uso de instâncias validadas FIPS 140-2 Nível 1 no processamento de dados ou entrega de sistemas ou aplicativos. Definimos os termos "Conformidade com FIPS 140-2 Nível 1" e "Conformidade com FIPS 140-2 Nível 1" usados na declaração acima para demonstrar sua aplicabilidade pretendida ao uso pelo governo dos EUA e Canadá do termo diferente "FIPS 140-2 Nível 1 validado".

Criptografar dados em trânsito

Mencionado em: OSA Practice #6, ISO Control Family: Criptografia

Protege os seus dados enquanto os dados se movem entre o cliente e o servidor. Consulte Segurança de rede.

Encriptar dados inativos

Mencionado em: OSA Practice #6, ISO Control Family: Criptografia

A criptografia em repouso é a proteção criptográfica dos dados quando eles são persistentes em arquivos de banco de dados, log e backup.

Como implementar

  • A criptografia de dados transparente (TDE) com chaves gerenciadas por serviço é habilitada por padrão para todos os bancos de dados criados após 2017 no Banco de Dados SQL do Azure e na Instância Gerenciada do 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 TDE do banco de dados original será honrada. Se o banco de dados original não tiver o TDE habilitado, recomendamos que o TDE seja ativado manualmente para a instância gerenciada.

Melhores práticas

  • Não armazene dados que exijam criptografia em repouso no master banco de dados. O master banco de dados 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 TDE. O Azure Key Vault permite a capacidade de revogar permissões a qualquer momento para tornar o banco de dados inacessível. Você pode gerenciar centralmente os protetores TDE juntamente com outras chaves ou girar o protetor TDE em sua própria agenda usando o Azure Key Vault.

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

Nota

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

Proteja dados confidenciais em uso de usuários não autorizados com privilégios elevados

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 banco de dados armazenar dados confidenciais, sua organização poderá ser obrigada a garantir que usuários com privilégios elevados sejam impedidos de exibir dados confidenciais no banco de dados. Usuários de alto privilégio, como operadores da Microsoft ou DBAs em sua organização, devem ser capazes de gerenciar o banco de dados, mas impedidos de exibir e potencialmente exfiltrar dados confidenciais da memória do processo SQL ou consultando o 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 acessíveis aos administradores em texto sem formatação são específicas da sua organização e das regulamentações de conformidade às quais você precisa aderir. Consulte o requisito relacionado: Identificar e marcar dados confidenciais.

Como implementar

  • Use Sempre Criptografado para garantir que dados confidenciais não sejam expostos em texto sem formatação no Banco de Dados SQL do Azure ou na Instância Gerenciada do SQL, mesmo na memória/em uso. O Always Encrypted protege os dados de administradores de banco de dados (DBAs) e administradores de nuvem (ou agentes mal-intencionados que podem se passar por usuários altamente privilegiados, mas não autorizados) e oferece mais controle sobre quem pode acessar seus dados.

Melhores práticas

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

  • Avalie o impacto da criptografia das colunas de dados confidenciais identificadas antes de implantar o Always Encrypted em um banco de dados de produção. Em geral, Always Encrypted reduz a funcionalidade de consultas em colunas criptografadas e tem outras limitações, listadas em Always Encrypted - Feature Details. Portanto, talvez seja necessário rearquitetar seu aplicativo para reimplementar a funcionalidade, uma consulta não suporta, 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 suportam o Always Encrypted esteja crescendo, vários deles não funcionam com colunas criptografadas. A criptografia de uma coluna também pode afetar o desempenho da consulta, dependendo das características da sua carga de trabalho.

  • Gerencie chaves Always Encrypted com separação de funções se estiver usando 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 descrevendo 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 sem formatação.

  • Armazene suas chaves mestras de coluna no Cofre de Chaves do Azure para facilitar o gerenciamento. Evite usar o Repositório de Certificados do Windows (e, em geral, soluções de armazenamento de chaves distribuídas, em oposição às soluções de gerenciamento central de chaves) que dificultam o gerenciamento de chaves.

  • Pense cuidadosamente nas compensações 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 normalmente são suficientes em ambientes de estado estacionário (não no meio de uma rotação de chave). Você pode precisar de chaves adicionais se tiver grupos de usuários diferentes, cada um usando chaves diferentes e acessando dados diferentes.

  • Gire as chaves mestras de coluna de acordo com seus requisitos de conformidade. Se você também precisar girar chaves de criptografia de coluna, considere usar criptografia online para minimizar o tempo de inatividade do aplicativo.

  • Use criptografia determinística se os cálculos (igualdade) em dados precisarem ser suportados. Caso contrário, use criptografia aleatória. Evite usar criptografia determinística para conjuntos de dados de baixa entropia ou conjuntos de dados com distribuição conhecida publicamente.

  • Se estiver preocupado com o facto de terceiros acederem legalmente aos seus dados sem o seu consentimento, certifique-se de que todas as aplicações e ferramentas que têm acesso às chaves e aos dados em texto simples são executadas fora da Nuvem do Microsoft Azure. Sem acesso às chaves, o terceiro não terá como desencriptar os dados, a menos que ignore a encriptação.

  • O Always Encrypted não suporta facilmente a 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 de forma confiável o acesso aos dados do DBA será girar as chaves de criptografia de coluna e as chaves mestras de coluna que protegem os dados, o que é uma operação cara.

  • Para acessar os valores de texto sem formatação em colunas criptografadas, um usuário precisa ter acesso à Chave Mestra de Coluna (CMK) que protege as colunas, que é configurada no armazenamento 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.

Controle o acesso dos usuários do aplicativo a dados confidenciais por meio de criptografia

A criptografia pode ser usada como uma maneira de garantir que apenas usuários específicos do aplicativo que tenham acesso a chaves criptográficas possam visualizar ou atualizar os dados.

Como implementar

  • Use a criptografia no nível da célula (CLE). Consulte o artigo Criptografar uma coluna de dados para obter detalhes.
  • Use Always Encrypted, mas esteja ciente de sua limitação. As limitações estão listadas abaixo.

Melhores práticas:

Ao utilizar o CLE:

Lembre-se de que o Always Encrypted foi projetado principalmente para proteger dados confidenciais em uso de usuários de alto privilégio do Banco de Dados SQL do Azure (operadores de nuvem, DBAs) - consulte Proteger dados confidenciais em uso de usuários não autorizados com privilégios elevados. Esteja ciente dos seguintes desafios ao usar o Always Encrypted para proteger dados de usuários de aplicativos:

  • Por padrão, todos os drivers de cliente Microsoft que suportam Always Encrypted mantêm um cache global (um por aplicativo) de chaves de criptografia de coluna. Depois que um driver de cliente adquire uma chave de criptografia de coluna de texto simples entrando em contato com um armazenamento de chaves que contém uma chave mestra de coluna, a chave de criptografia de coluna de texto sem formatação é armazenada em cache. Isso torna desafiador isolar dados de usuários de um aplicativo multiusuário. Se seu aplicativo representar usuários finais ao interagir com um armazenamento de chaves (como o Cofre de Chaves do Azure), depois que a consulta de um usuário preencher o cache com uma chave de criptografia de coluna, uma consulta subsequente que exija a mesma chave, mas seja acionada por outro usuário, usará a chave em cache. O driver não chamará o armazenamento 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 pode ver os dados criptografados mesmo que não tenha acesso às chaves. Para obter o isolamento de usuários em um aplicativo multiusuário, você pode desabilitar o cache de chave de criptografia de coluna. A desativação do cache causará despesas adicionais de desempenho, pois o driver precisará entrar em contato com o armazenamento de chaves para cada operação de criptografia ou descriptografia de dados.

Proteja os dados contra visualização não autorizada por usuários do aplicativo, preservando o formato dos dados

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

Como implementar

  • Use o mascaramento dinâmico de dados para ofuscar as colunas da tabela.

Nota

Always Encrypted não funciona com mascaramento dinâmico de dados. Não é possível criptografar e mascarar a mesma coluna, o que implica que você precisa priorizar a proteção dos dados em uso versus mascarar os dados para os usuários do seu aplicativo por meio do Dynamic Data Masking.

Melhores práticas

Nota

O mascaramento dinâmico de dados não pode ser usado 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 do aplicativo executem consultas ad hoc (pois eles podem contornar o Dynamic Data Masking).

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

  • O mascaramento dinâmico 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 da rede

Segurança de rede refere-se a 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 SQL

Práticas recomendadas sobre como impedir que máquinas cliente e aplicativos com vulnerabilidades conhecidas (por exemplo, usando protocolos TLS mais antigos e pacotes de codificação) se conectem ao Banco de Dados SQL do Azure e à Instância Gerenciada do SQL.

Como implementar

  • Verifique se as máquinas cliente que se conectam ao Banco de Dados SQL do Azure e à Instância Gerenciada do SQL estão usando a versão mais recente do Transport Layer Security (TLS).

Melhores práticas

  • Imponha uma versão mínima do TLS no nível do servidor do Banco de dados SQL ou da instância gerenciada do SQL usando a configuração de versão mínima do TLS. Recomendamos definir a versão mínima do TLS como 1.2, após o teste, para confirmar se seus aplicativos a suportam. O TLS 1.2 inclui correções para vulnerabilidades encontradas em versões anteriores.

  • Configure todos os seus aplicativos e ferramentas para se conectar ao Banco de dados SQL com a criptografia habilitada

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

  • Se o seu aplicativo usa um driver que não suporta TLS ou suporta 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: OSA Practice #5

Como implementar

Na Base de Dados SQL:

  • Definir Permitir acesso aos serviços do Azure como DESATIVADO no nível do servidor
  • Use os pontos de extremidade do Serviço VNet e as Regras de Firewall da VNet.
  • Use o Link Privado.

Na instância gerenciada do SQL:

  • Siga as diretrizes em Requisitos de rede.

Melhores práticas

  • Restringindo o acesso ao Banco de Dados SQL do Azure e à Instância Gerenciada SQL conectando-se em 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. Aplicativos e ferramentas que estão na mesma rede virtual ou emparelhada na mesma região podem acessá-la diretamente. Aplicativos e ferramentas que estão em regiões diferentes podem usar conexão de rede virtual para rede virtual ou emparelhamento de circuito de Rota Expressa para estabelecer conexão. O cliente deve usar o NSG (Network Security Groups) para restringir o acesso pela porta 1433 apenas aos 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 móveis devem usar conexões VPN ponto a site para se conectar pelo caminho de dados.
    • Os usuários conectados à rede local devem usar a conexão VPN site a site ou a Rota Expressa para se conectar pelo caminho de dados.

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

    • Para um servidor no Banco de dados SQL, use regras de firewall IP para restringir o acesso apenas a endereços IP autorizados.
    • Para Instância Gerenciada SQL, use NSG (Grupos de Segurança de Rede) para restringir o acesso pela porta 3342 apenas aos recursos necessários. Para obter mais informações, consulte Usar uma instância gerenciada com segurança com pontos de extremidade públicos.

    Nota

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

  • Configure os componentes de Rede do Azure:

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

Melhores práticas

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

Melhores práticas

Configurar a hospedagem da Máquina Virtual do Azure para conexões seguras com o Banco de Dados SQL/Instância Gerenciada SQL

Melhores práticas

  • Use uma combinação de regras Permitir e Negar nos NSGs das máquinas virtuais do Azure para controlar quais regiões podem ser acessadas a partir da VM.

  • Certifique-se de que sua VM esteja configurada de acordo com o artigo, Práticas recomendadas de segurança para cargas de trabalho IaaS no Azure.

  • Certifique-se de que todas as VMs estejam associadas a uma rede virtual e sub-rede específicas.

  • Avalie se você precisa da rota padrão 0.0.0.0/Internet de acordo com a orientação em sobre tunelamento forçado.

    • Se sim – por exemplo, sub-rede front-end – mantenha a rota padrão.
    • Se não – por exemplo, camada intermediária ou sub-rede de back-end – habilite o túnel de força para que nenhum tráfego passe pela Internet para chegar ao local (também conhecido como entre locais).

  • Implemente rotas padrão opcionais se estiver usando emparelhamento ou conexão local.

  • Implemente Rotas Definidas pelo Usuário se precisar enviar todo o tráfego na rede virtual para um Dispositivo Virtual de Rede para inspeção de pacotes.

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

Proteja-se contra ataques distribuídos de negação de serviço (DDoS)

Os ataques distribuídos de negação de serviço (DDoS) são tentativas de um usuário mal-intencionado de enviar uma enxurrada de 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 ele rejeite logons e carga de trabalho válidos.

Mencionado em: OSA Practice #9

Como implementar

A proteção contra DDoS é ativada automaticamente como parte da Plataforma Azure. Ele inclui monitoramento de tráfego sempre ativo e mitigação em tempo real de ataques no nível da rede em pontos de extremidade públicos.

Melhores práticas

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

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

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

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

Monitorização, registos e auditoria

Esta seção refere-se aos recursos para ajudá-lo a detetar atividades anômalas que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. Ele também descreve as práticas recomendadas para configurar a auditoria de banco de dados para rastrear e capturar eventos de banco de dados.

Proteja os bancos de dados contra ataques

A proteção avançada contra ameaças permite-lhe detetar e responder a potenciais ameaças à medida que ocorrem, fornecendo alertas de segurança sobre atividades anómalas.

Como implementar

  • Use a Proteção Avançada contra Ameaças para SQL para detetar tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados, incluindo:
    • Ataque de injeção de SQL.
    • Roubo/fuga de credenciais.
    • Abuso de privilégios.
    • Transferência de dados não autorizada.

Melhores práticas

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

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

Auditar eventos críticos de segurança

O acompanhamento de eventos do banco de dados ajuda você a entender a atividade do banco de dados. Você pode obter informações sobre discrepâncias e anomalias que podem indicar preocupações comerciais ou suspeitas de violações de segurança. Também permite e facilita a adesão às normas de conformidade.

Como implementar

Melhores práticas

  • Ao configurar a Auditoria do Banco de Dados SQL em seu servidor ou a Auditoria de Instância Gerenciada para auditar eventos, 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 logins bem-sucedidos e com falha) nos bancos de dados, o que pode resultar em um 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 que foi configurado.

Nota

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

Outros recursos

Logs de auditoria seguros

Restrinja o acesso à conta de armazenamento para dar suporte à separação de funções e separar o DBA dos auditores.

Como implementar

  • Ao salvar logs de auditoria no Armazenamento do Azure, verifique se o acesso à Conta de Armazenamento está restrito aos princípios mínimos de segurança. Controle quem tem acesso à conta de armazenamento.
  • Para obter mais informações, consulte Autorizando o acesso ao Armazenamento do Azure.

Melhores práticas

Gestão de Segurança

Esta seção descreve os diferentes aspetos e as práticas recomendadas para gerenciar a postura de segurança de seus bancos de dados. Ele inclui práticas recomendadas para garantir que seus bancos de dados estejam configurados para atender aos padrões de segurança, para descobrir, classificar e rastrear o acesso a dados potencialmente confidenciais em seus bancos de dados.

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

Melhore proativamente a segurança do seu banco de dados, descobrindo e corrigindo possíveis vulnerabilidades do banco de dados.

Como implementar

  • Habilite a Avaliação de Vulnerabilidade do SQL (VA) para verificar seu banco de dados em busca de problemas de segurança e para executar automaticamente periodicamente em seus bancos de dados.

Melhores práticas

  • Inicialmente, execute o VA em seus bancos de dados e itere corrigindo verificações com falhas que se opõem às práticas recomendadas de segurança. Configure linhas de base para configurações aceitáveis até que a verificação saia limpa ou todas as verificações tenham passado.

  • Configure verificações periódicas recorrentes para serem executadas uma vez por semana e configure a pessoa relevante para receber e-mails resumidos.

  • Reveja o resumo da AV após cada análise semanal. Para quaisquer vulnerabilidades encontradas, avalie o desvio do resultado da verificação anterior e determine se a verificação deve ser resolvida. Analise 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 sejam resolvidos.

Outros recursos

Identificar e marcar dados confidenciais

Descubra colunas que potencialmente contêm dados confidenciais. O que é considerado dado sensível depende muito do cliente, da regulamentação de conformidade, etc., e precisa ser avaliado pelos usuários responsáveis por esses dados. Classifique as colunas para usar cenários avançados de auditoria e proteção baseados em sensibilidade.

Como implementar

  • Use o SQL Data Discovery and Classification para descobrir, classificar, rotular e proteger os dados confidenciais em seus bancos de dados.
    • Exiba as recomendações de classificação criadas pela descoberta automatizada no painel Descoberta e Classificação de Dados SQL. Aceite as classificações relevantes, de modo que seus dados confidenciais sejam marcados persistentemente com rótulos 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.

Melhores práticas

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

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

  • Use a classificação de forma adaptada às necessidades específicas da sua organização. Personalize sua política de Proteção de Informações (rótulos de sensibilidade, tipos de informações, lógica de descoberta) na política de Proteção de Informações SQL no Microsoft Defender for Cloud.

Rastreie o acesso a dados confidenciais

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

Como implementar

Melhores práticas

Visualize o status de segurança e conformidade

Use um sistema unificado de gerenciamento de segurança de infraestrutura que fortaleça a postura de segurança de seus data centers (incluindo bancos de dados no Banco de dados SQL). Veja uma lista de recomendações relativas à segurança das suas bases de dados e ao estado de conformidade.

Como implementar

Ameaças comuns à segurança e potenciais atenuações

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

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

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

A conexão ao servidor através de um ponto de extremidade público apresenta um risco de exfiltração de dados, pois exige que os clientes abram seus firewalls para 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 mal-intencionado obtém acesso à VM e a compromete. Nesse cenário, a exfiltração de dados significa que uma entidade externa usando a VM não autorizada se conecta ao banco de dados, copia dados pessoais e os armazena em um armazenamento de blob ou em um Banco de dados SQL diferente em uma assinatura diferente.

Cenário 2: Um DBA desonesto. Esse cenário é frequentemente levantado por clientes sensíveis à segurança 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.

Potenciais atenuações

Atualmente, o Banco de Dados SQL do Azure e a Instância Gerenciada do SQL oferecem as seguintes técnicas para reduzir as ameaças de exfiltração de dados:

  • Use uma combinação de regras Permitir e Negar nos NSGs das VMs do Azure para controlar quais regiões podem ser acessadas a partir da VM.
  • Se estiver usando um servidor no Banco de dados SQL, defina as seguintes opções:
    • Permitir que os Serviços do Azure sejam DESATIVADOS.
    • Permita apenas o tráfego da sub-rede que contém sua VM do Azure configurando uma regra de Firewall de rede virtual.
    • Usar Link Privado
  • Para a Instância Gerenciada SQL, o uso de acesso IP privado por padrão resolve a primeira preocupação de exfiltração de 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 de Instância Gerenciada SQL.
  • A preocupação com o DBA não autorizado está mais exposta com a Instância Gerenciada SQL, pois ela tem 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 de DBA não autorizado em primeiro lugar (não apenas para exfiltração de dados). Always Encrypted é um método para proteger dados confidenciais, criptografando-os e mantendo a chave inacessível para o DBA.

Aspetos de segurança da continuidade e disponibilidade de negócios

A maioria dos padrões de segurança aborda a disponibilidade de dados em termos de continuidade operacional, alcançada pela implementação de recursos de redundância e failover para evitar pontos únicos de falha. Para cenários de desastre, é uma prática comum manter backups de arquivos de dados e 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óximos passos