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

Artigo
10/18/2023

Neste artigo, discutimos 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 plataforma como serviço (PaaS). Estas práticas recomendadas derivam da nossa experiência com o Azure e das experiências 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 SQL do Azure
Encriptação 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 senha. Quando você criou o servidor para seu banco de dados, você especificou um login "administrador do servidor" com um nome de usuário e 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 é suportada para domínios gerenciados e integrados. Para usar a autenticação do Microsoft Entra, você deve criar outro administrador de servidor chamado "Microsoft Entra admin", que tem permissão para administrar usuários e grupos do Microsoft Entra. Este administrador também pode fazer todas as operações que um administrador de servidor normal faz.

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

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

Permite a rotação de senhas em um único lugar.
Gerencia permissões de banco de dados usando grupos externos do Microsoft Entra.
Elimina o armazenamento de palavras-passe ao permitir a autenticação integrada do Windows e outras formas de autenticação suportadas pelo Microsoft Entra ID.
Usa usuários de banco de dados contidos para autenticar identidades no nível do banco de dados.
Suporta autenticação baseada em token para aplicativos que se conectam ao Banco de dados SQL.
Suporta federação de domínio com os Serviços de Federação do Ative Directory (ADFS) ou autenticação nativa de utilizador/palavra-passe para um 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 Ative Directory, que inclui MFA (Multi-Factor Authentication). O 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 aplicações móveis. Para obter mais informações, consulte Autenticação Universal com Banco de Dados SQL e Azure Synapse Analytics.

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

Nota

Para garantir que o Microsoft Entra ID seja adequado ao seu ambiente, consulte 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 para os níveis de servidor e banco de dados. Recomendamos o uso de regras de firewall no nível de banco de dados sempre que possível para aumentar a segurança e tornar seu banco de dados mais portátil. As regras de firewall no nível de 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 quer perder 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 para permitir apenas que seus endereços IP acessem a instância. Mesmo com o firewall SQL e as restrições de endereço IP, a autenticação forte ainda é necessária. Veja as recomendações feitas anteriormente neste artigo.

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

Encriptar dados inativos

A Criptografia de Dados Transparente (TDE) está habilitada por padrão. A TDE criptografa de forma transparente os dados e arquivos de log do SQL Server, do Banco de Dados SQL do Azure e do Azure Synapse Analytics. TDE protege contra um comprometimento de acesso direto aos arquivos ou seu backup. Isso permite criptografar dados em repouso sem alterar os aplicativos existentes. A TDE deve permanecer sempre ativada; No entanto, isso não impedirá que um invasor use o caminho de acesso normal. A TDE oferece 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. Tal como acontece com a TDE, deve ter-se um cuidado especial no local para garantir a capacidade de recuperação e ao mover bases de dados. Em cenários mais sofisticados, as chaves podem ser explicitamente gerenciadas no Cofre de Chaves do Azure por meio do gerenciamento extensível de chaves. Consulte Habilitar TDE no SQL Server usando EKM. Isso também permite Bring Your Own Key (BYOK) por meio do recurso BYOK do Azure Key Vaults.

O SQL do Azure fornece criptografia para colunas por meio do Always Encrypted. Isso permite que apenas 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 mantida no país/região correto. Isso evita que até mesmo a transferência acidental de dados cause um problema, uma vez que é impossível descriptografar os dados sem a chave, supondo que um algoritmo forte seja usado (como AES 256).

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

Próximos passos

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 PaaS. Para saber mais sobre como proteger suas implantações de PaaS, consulte: