Compartilhar via

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

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

Azure SQL Database e 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 Azure SQL Database e Azure Synapse Analytics em uma implantação de PaaS:

  • Autenticação do Microsoft Entra (em vez de autenticação do SQL Server)
  • Firewall do SQL do Azure
  • Transparent Data Encryption (TDE)

Usar um repositório de identidade centralizado

Azure SQL Database 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.

  • Microsoft Entra authentication usa identidades gerenciadas por Microsoft Entra ID 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.

Microsoft Entra authentication é um mecanismo de conexão com Azure SQL Database e análise de Azure Synapse usando identidades em Microsoft Entra ID. Microsoft Entra ID fornece uma alternativa para SQL Server autenticação 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 Microsoft Entra ID em vez de 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 ao habilitar autenticação integrada do Windows e outras formas de autenticação compatíveis com o Microsoft Entra ID.
  • 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 Active Directory Federation Services (ADFS) ou autenticação nativa de usuário/senha para um Microsoft Entra ID local sem sincronização de domínio.
  • Dá suporte a conexões de SQL Server Management Studio que usam a Autenticação Universal Active Directory, que inclui Multi-Factor Authentication (MFA). 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 Universal Authentication with SQL Database and Azure Synapse Analytics.

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

Observação

Para garantir que Microsoft Entra ID seja uma boa opção para seu ambiente, consulte Recursos e limitações doMicrosoft Entra.

Restringir access 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 access, mas não deseja gastar tempo configurando cada banco de dados 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 de modo que apenas seus endereços IP possam acessar 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 Azure SQL firewall e restrições de IP, confira:

Criptografar dados em repouso

Transparent Data Encryption (TDE) está habilitado por padrão. O TDE criptografa de forma transparente SQL Server, Azure SQL Database e arquivos de log e dados do Azure Synapse Analytics. O TDE protege contra um comprometimento de acesso direto aos arquivos ou seus backups. 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.

Azure SQL 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 em Azure Key Vault por meio de gerenciamento extensível de chaves. Consulte Habilitar TDE no SQL Server Usando EKM. Isso também permite a funcionalidade BYOK (Bring Your Own Key, Traga Sua Própria Chave) por meio da capacidade BYOK dos Key Vaults do Azure.

Azure SQL fornece criptografia para colunas por meio de 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:

  • Last updated on