Melhores práticas para proteger bancos de dados de 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. Vejamos 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 da 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 identidades centralizado

Os bancos de dados SQL do Azure podem ser configurados para usar um dos dois tipos de autenticação:

• A autenticação do SQL usa um nome de usuário e senha. Quando você criou o servidor do banco de dados, especificou um logon de "administrador de servidor" com um nome de usuário e uma senha. Usando essas credenciais, é possível se 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 pelo Microsoft Entra ID e tem suporte para domínios gerenciados e integrados. Para usar a autenticação do Microsoft Entra, é necessário 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 com o Banco de Dados SQL do Azure e o Azure Synapse Analytics usando identidades no Microsoft Entra ID. 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 nos servidores de banco de dados. A autenticação do Microsoft Entra permite gerenciar de forma centralizada as identidades dos usuários do banco de dados e de 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 o Microsoft Entra ID em vez da autenticação do SQL

• Permite o rodízio de senhas em um único lugar.
• Gerencia as permissões do banco de dados usando grupos externos do Microsoft Entra.
• Elimina o armazenamento de senhas, permitindo a autenticação do Windows integrada e outras formas de autenticação às quais o Microsoft Entra ID dá suporte.
• Usa usuários de banco de dados independente para autenticar identidades no nível de banco de dados.
• Dá suporte à autenticação baseada em token em 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 (AD FS) ou à autenticação nativa de usuário/senha para um Microsoft Entra ID local sem sincronização de domínios.
• Dá suporte a conexões do SQL Server Management Studio que usam a Autenticação Universal do Active Directory, que inclui o MFA (Autenticação Multifator). A MFA inclui autenticação forte com uma variedade de opções de fácil verificação. As opções de verificação são chamada telefônica, mensagem de texto, cartões inteligentes com PIN ou notificações de aplicativos móveis. Para saber mais, confira Autenticação universal com o Banco de Dados SQL e Azure Synapse Analytics.

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

• Use a autenticação do Microsoft Entra para autenticação com o Banco de Dados SQL, a Instância Gerenciada ou o Azure Synapse Analytics
• Autenticação no Azure Synapse Analytics
• Suporte à autenticação baseada em token para o Banco de Dados SQL do Azure usando a autenticação do Microsoft Entra

Restringir o acesso com base no endereço IP

Você pode criar regras de firewall que especifiquem intervalos de endereços IP aceitáveis. Essas regras podem ser direcionadas nos níveis do servidor e do banco de dados. É recomendável o uso de regras de firewall no nível do banco de dados sempre que possível, a fim de 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 com os mesmos requisitos de acesso, mas não quer gastar tempo configurando cada um individualmente.

As restrições de endereço IP de origem 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 as restrições de endereço IP e firewall do SQL, a autenticação forte ainda é necessária. Consulte as recomendações feitas anteriormente neste artigo.

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

• Conjuntos de dados do Banco de Dados SQL do Azure e controle de acesso do Azure Synapse Analytics
• Regras de firewall do Banco de Dados SQL do Azure e do Azure Synapse Analytics

Criptografar dados em repouso

A TDE (Transparent Data Encryption) é habilitada por padrão. A TDE criptografa de forma transparente os arquivos de log e de dados do SQL Server, do Banco de Dados SQL do Azure e do Azure Synapse Analytics. A TDE protege contra o comprometimento de acesso direto aos arquivos ou aos backups dos arquivos. Isso permite que você criptografe os dados em repouso sem alterar os aplicativos existentes. A TDE deverá permanecer sempre habilitada. No entanto, isso não interromperá um invasor que utilizar o caminho de acesso normal. A TDE proporciona a capacidade de entrar em conformidade com muitas leis, regulamentações e diretrizes estabelecidas em vários setores.

O SQL do Azure gerencia problemas relacionados a chave para a TDE. Assim como com a TDE, devem ser tomados cuidados especiais locais a fim de 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. Confira 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 a criptografia para colunas por meio do Always Encrypted. Isso permite o acesso somente de aplicativos autorizados às colunas confidenciais. O uso dessa variante de criptografia limita as consultas SQL às colunas criptografadas à valores com base em igualdade.

A criptografia do nível do aplicativo também deve ser usada para dados seletivos. Algumas vezes, as preocupações com a soberania de dados podem ser reduzidas com a criptografia de dados com uma chave que seja mantida no país/região corretos. Isso impede que até uma transferência de dados acidental 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 a criação de um sistema seguro, a criptografia de ativos confidenciais e a criação de um firewall em torno de servidores de bancos de dados.

Próximas etapas

Este artigo apresentou uma coleção de práticas recomendadas de segurança do Banco de Dados SQL e 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:

• Proteção de implantações de PaaS
• Securing PaaS web and mobile applications using Azure App Services (Proteção dos aplicativos Web e móveis de PaaS usando os Serviços de Aplicativos do Azure)