Compartilhar via

Práticas recomendadas para proteger bancos de dados PaaS no Azure

Neste artigo, discutiremos uma coleção de práticas recomendadas de segurança do Banco de Dados SQL do Azure e do Azure Synapse Analytics para proteger seus aplicativos Web e móveis de PaaS (plataforma como serviço). Essas práticas recomendadas derivam da nossa experiência com o Azure e da experiência de clientes como você.

O Banco de Dados SQL do Azure e o Azure Synapse Analytics fornecem um serviço de banco de dados relacional para seus aplicativos baseados na Internet. Vamos examinar os serviços que ajudam a proteger seus aplicativos e dados ao usar o Banco de Dados SQL do Azure e o Azure Synapse Analytics em uma implantação de PaaS:

  • Autenticação do Microsoft Entra (em vez da autenticação do SQL Server)
  • Firewall do SQL do Azure
  • Criptografia de Dados Transparente (TDE)

Usar um repositório de identidade centralizado

O Banco de Dados SQL do Azure pode ser configurado para usar um dos dois tipos de autenticação:

  • A autenticação SQL usa um nome de usuário e uma senha. Ao criar o servidor para seu banco de dados, você especificou um logon de "administrador do servidor" com um nome de usuário e uma senha. Usando essas credenciais, você pode autenticar em qualquer banco de dados nesse servidor como o proprietário do banco de dados.

  • A autenticação do Microsoft Entra usa identidades gerenciadas pela ID do Microsoft Entra e tem suporte para domínios gerenciados e integrados. Para usar a autenticação do Microsoft Entra, você deve criar outro administrador de servidor chamado "Administrador do Microsoft Entra", que tem permissão para administrar usuários e grupos do Microsoft Entra. Este administrador também pode executar todas as operações executadas por um administrador de servidor comum.

A autenticação do Microsoft Entra é um mecanismo de conexão ao Banco de Dados SQL do Azure e ao Azure Synapse Analytics usando identidades no Microsoft Entra ID. A ID do Microsoft Entra fornece uma alternativa à autenticação do SQL Server para que você possa interromper a proliferação de identidades de usuário em servidores de banco de dados. A autenticação do Microsoft Entra permite que você gerencie centralmente as identidades de usuários de banco de dados e outros serviços da Microsoft em um local central. O gerenciamento central de IDs fornece um único local para gerenciar os usuários do banco de dados e simplifica o gerenciamento de permissões.

Benefícios de usar a ID do Microsoft Entra em vez da autenticação SQL

  • Permite o rodízio de senhas em um único lugar.
  • Gerencia permissões de banco de dados usando grupos externos do Microsoft Entra.
  • Elimina o armazenamento de senhas habilitando a autenticação integrada do Windows e outras formas de autenticação compatíveis com a ID do Microsoft Entra.
  • Usa usuários de banco de dados independentes para autenticar identidades no nível do banco de dados.
  • Dá suporte à autenticação baseada em token para aplicativos que se conectam ao Banco de Dados SQL.
  • Dá suporte à federação de domínio com os Serviços de Federação do Active Directory (ADFS) ou a autenticação nativa de usuário/senha para uma ID local do Microsoft Entra sem sincronização de domínio.
  • Dá suporte a conexões do SQL Server Management Studio que usam a Autenticação Universal do Active Directory, que inclui a MFA (Autenticação Multifator). A MFA inclui autenticação forte com uma variedade de opções de verificação fáceis. As opções de verificação são chamada telefônica, mensagem de texto, cartões inteligentes com pin ou notificação de aplicativo móvel. Para obter mais informações, consulte Autenticação Universal com o Banco de Dados SQL e o Azure Synapse Analytics.

Para saber mais sobre a autenticação do Microsoft Entra, confira:

Observação

Para garantir que a ID do Microsoft Entra seja uma boa opção para seu ambiente, consulte os recursos e limitações do Microsoft Entra.

Restringir o acesso com base no endereço IP

Você pode criar regras de firewall que especificam intervalos de endereços IP aceitáveis. Essas regras podem ser direcionadas aos níveis de servidor e banco de dados. Recomendamos usar regras de firewall no nível do banco de dados sempre que possível para aprimorar a segurança e tornar seu banco de dados mais portátil. As regras de firewall no nível do servidor são melhor usadas para administradores e quando você tem muitos bancos de dados que têm os mesmos requisitos de acesso, mas não deseja gastar tempo configurando cada banco de dados individualmente.

As restrições de endereço IP de origem padrão do Banco de Dados SQL permitem o acesso de qualquer endereço do Azure, incluindo outras assinaturas e locatários. Você pode restringir isso apenas para permitir que seus endereços IP acessem a instância. Mesmo com o firewall do SQL e as restrições de endereço IP, a autenticação forte ainda é necessária. Consulte as recomendações feitas anteriormente neste artigo.

Para saber mais sobre o Firewall do SQL do Azure e restrições de IP, confira:

Criptografar dados em repouso

A TDE (Transparent Data Encryption) está habilitada por padrão. O TDE criptografa de forma transparente o SQL Server, o Banco de Dados SQL do Azure e os arquivos de log e dados do Azure Synapse Analytics. O TDE protege contra um comprometimento do acesso direto aos arquivos ou ao backup. Isso permite que você criptografe dados em repouso sem alterar os aplicativos existentes. O TDE sempre deve permanecer habilitado; no entanto, isso não interromperá um invasor usando o caminho de acesso normal. A TDE fornece a capacidade de cumprir muitas leis, regulamentos e diretrizes estabelecidas em vários setores.

O SQL do Azure gerencia os principais problemas relacionados ao TDE. Assim como acontece com o TDE, é necessário ter cuidado especial local para garantir a capacidade de recuperação e ao mover bancos de dados. Em cenários mais sofisticados, as chaves podem ser explicitamente gerenciadas no Azure Key Vault por meio do gerenciamento extensível de chaves. Consulte Habilitar TDE no SQL Server usando EKM. Isso também permite o BYOK (Bring Your Own Key) por meio da capacidade BYOK do Azure Key Vault.

O SQL do Azure fornece criptografia para colunas por meio do Always Encrypted. Isso permite que somente aplicativos autorizados acessem colunas confidenciais. O uso desse tipo de criptografia limita as consultas SQL para colunas criptografadas a valores baseados em igualdade.

A criptografia no nível do aplicativo também deve ser usada para dados seletivos. Às vezes, as preocupações com a soberania de dados podem ser atenuadas criptografando dados com uma chave que é mantida no país/região correto. Isso impede até mesmo a transferência acidental de dados de causar um problema, pois é impossível descriptografar os dados sem a chave, supondo que um algoritmo forte seja usado (como o AES 256).

Você pode usar precauções adicionais para ajudar a proteger o banco de dados, como criar um sistema seguro, criptografar ativos confidenciais e criar um firewall em torno dos servidores de banco de dados.

Próximas etapas

Este artigo apresentou uma coleção de práticas recomendadas de segurança do Banco de Dados SQL e do Azure Synapse Analytics para proteger seus aplicativos Web e móveis de PaaS. Para saber mais sobre como proteger suas implantações de PaaS, confira: