Descrever recursos de segurança
O Banco de Dados do Azure para MySQL – Servidor Flexível fornece vários recursos projetados para proteger e proteger seus dados e operações. Vamos examinar cada uma dessas ferramentas.
Rede
O Banco de Dados do Azure para MySQL – Servidor Flexível fornece configurações robustas de firewall para proteger a conectividade de banco de dados para acesso público, bem como Redes Virtuais do Azure (VNets). Há três configurações para a conexão de servidor flexível do MySQL: acesso público, acesso privado e um link privado. Em todos os casos, as conexões ainda devem ser autenticadas com o servidor.
O acesso Público fornece um endereço DNS publicamente resolvível e acessível pela Internet por meio de uma lista permitida de intervalos de endereços IP. Por padrão, nenhum endereço IP está permitido. Você pode adicionar endereços IP durante ou após a criação. Você também pode permitir o acesso de qualquer endereço IP do Azure (incluindo outras assinaturas de clientes em outras regiões).
O acesso privado usa uma sub-rede delegada para hospedar servidores flexíveis do MySQL e fornece um endereço DNS resolvível de dentro de sua VNet ou de uma VNet emparelhada. Isso bloqueia o acesso de banco de dados apenas à sua infraestrutura de rede virtual. Você pode configurar regras de firewall do Grupo de Segurança de Rede NSG (NSG) para filtrar o tráfego de rede com mais precisão. Você pode usar o acesso privado para se conectar com segurança a um servidor flexível MySQL de dentro da mesma VNet, de uma VNet diferente usando emparelhamento ou até mesmo do local usando uma conexão ExpressRoute ou VPN.
O link privado fornece um ponto de extremidade de endereço IP privado em uma sub-rede VNet para se conectar diretamente ao servidor flexível do MySQL. O Link Privado do Azure essencialmente traz os serviços do Azure dentro de sua VNet privada por meio de um endereço IP como qualquer outro recurso de VNet. Você pode criar vários pontos de extremidade privados, por exemplo, um por aplicativo de conexão ou recurso de PaaS do Azure. Combinados com as regras de firewall do NSG, os links privados fornecem um controle refinado sobre quais serviços podem acessar o banco de dados.
Microsoft Defender para Nuvem
O Microsoft Defender para Nuvem monitora seu banco de dados para atividades incomuns e potencialmente prejudiciais. O Defender para Nuvem é fornecido como um plano de complemento para lidar com possíveis ameaças sem a necessidade de criar ou gerenciar o monitoramento de segurança. O Defender para Nuvem tem disponibilidade de várias nuvens no Banco de Dados do Azure para MySQL – Servidor Flexível, além do MySQL no AWS Aurora e RDS. O Defender para Nuvem também dá suporte ao PostgreSQL e ao MariaDB.
O Defender para Nuvem detecta ameaças de banco de dados, como:
- Ataques de força bruta: falhas de logon anormalmente altas e logon bem-sucedido após muitas falhas.
- Padrões de logon incomuns: se um usuário fizer logon pela primeira vez em mais de dois meses.
- Locais de logon incomuns: se um usuário fizer logon de um banco de dados incomum do Azure ou de outro provedor de nuvem, ou de um IP sinalizado como suspeito.
O Defender para Nuvem envia alertas de detecção para o portal do Azure e por email. Os alertas incluem:
- Detalhes da atividade suspeita.
- O MITRE ATT&CK associado (Táticas de Adversário, Técnicas e Conhecimento Comum).
- Sugestões para investigar e atenuar o ataque.
- Mais opções para investigar com o Microsoft Sentinel.
Autenticação
O Banco de Dados do Azure para MySQL oferece dois modos de autenticação: Autenticação por meio do MySQL (nome de usuário/senha) e autenticação por meio do Microsoft Entra ID. Você pode habilitar ambos ao mesmo tempo.
A autenticação por meio do Microsoft Entra ID habilita a autenticação baseada em identidade para o servidor flexível do MySQL usando identidades fornecidas pelo Microsoft Entra ID. Isso centraliza o gerenciamento de usuários para o banco de dados e outros serviços Microsoft.
Por padrão, um servidor flexível do MySQL é definido para usar somente autenticação por meio do MySQL (nome de usuário/senha). Você pode alterar essa configuração para usar somente a autenticação por meio do Microsoft Entra ID (sem usuários de banco de dados) ou combinar identidades gerenciadas com a autenticação por meio do MySQL.
Quando você usa a autenticação por meio do Microsoft Entra ID, há duas contas de administrador: o administrador original do MySQL e o administrador do Microsoft Entra ID. O administrador do Microsoft Entra ID pode ser um usuário ou um grupo de usuários. Se o administrador for um grupo, qualquer membro do grupo poderá gerenciar a autenticação por meio do Microsoft Entra ID. Os grupos de administradores são mais fáceis de gerenciar porque centralizam o gerenciamento de usuários no Microsoft Entra ID em vez de precisar atualizar usuários ou permissões do MySQL diretamente. Você só pode configurar um administrador do Microsoft Entra ID, seja um único usuário ou um único grupo de usuários.
O diagrama a seguir mostra os dois modos para gerenciar a autenticação.
Quando usuários ou aplicativos tentam se conectar a um servidor flexível do MySQL usando uma identidade do Microsoft Entra, um token é emitido para permitir o logon. A identidade é associada a um usuário de banco de dados por meio de sua ID de usuário exclusiva do Microsoft Entra, em vez de seu nome ou outros atributos.
Criptografia de dados
Servidores flexíveis do MySQL criptografam dados em trânsito. Por padrão, os servidores exigem a conexão com o Transport Layer Security (TLS) 1.2 e negam conexões ou conexões não criptografadas usando os protocolos TLS 1.0 e 1.1 preteridos. Você pode desabilitar conexões criptografadas (talvez um aplicativo herdado não dê suporte à criptografia) ou permitir versões antes da 1.2 ou usar o TLS 1.3, que é a configuração recomendada para o desenvolvimento de novos aplicativos.
Por padrão, o Banco de Dados do Azure para MySQL – Servidor Flexível criptografa dados inativos (incluindo arquivos temporários e de backup criados durante a execução de consultas) usando uma chave de criptografia de dados (DEK) de 256 bits simétrica do AES. Com as chaves gerenciadas pelo cliente (CMK), você pode trazer sua própria chave (BYOK) para adicionar outra camada de criptografia criptografando o DEK do serviço.
O BYOK fornece controle total da criptografia de dados e do ciclo de vida da chave: criação, upload, rotação e exclusão. O gerenciamento do ciclo de vida de chave permite alinhar a rotação de chaves com as políticas da empresa e permite a separação das responsabilidades da equipe de segurança, do DBA e do administrador do sistema.
Habilitar o CMK requer vincular um banco de dados a uma identidade gerenciada (UMI) atribuída pelo usuário e, em seguida, especificar a chave, que é armazenada no Azure Key Vault, a ser usada. Se você criar uma cópia do servidor, a cópia será criptografada e você também poderá adicionar identidades gerenciadas e chaves a réplicas existentes.