Descrever os elementos 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. Vejamos cada um desses recursos.
Rede
Banco de Dados do Azure para MySQL – Servidor Flexível fornece configurações de firewall robustas para proteger a conectividade do banco de dados para acesso público, bem como as Redes Virtuais do Azure (VNets). Há três configurações para a conexão flexível do servidor 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 resolúvel, acessível através da Internet através de uma lista permitida de intervalos de endereços IP. Por padrão, nenhum endereço IP é permitido. Você pode adicionar endereços IP durante ou após a criação. Também pode permitir o acesso a partir de qualquer endereço IP do Azure (incluindo outras subscrições de clientes noutras regiões).
O acesso privado usa uma sub-rede delegada para hospedar servidores flexíveis MySQL e fornece um endereço DNS resolúvel de dentro de sua VNet ou uma VNet emparelhada. Isso bloqueia o acesso ao banco de dados apenas à sua infraestrutura de rede virtual. Você pode configurar regras de firewall NSG (Network Security Group) 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 dentro de uma sub-rede VNet para se conectar diretamente ao servidor flexível MySQL. O Azure Private Link essencialmente traz os serviços do Azure para 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 PaaS do Azure. Combinado com as regras de firewall do NSG, os links privados fornecem controle refinado sobre quais serviços podem acessar o banco de dados.
Microsoft Defender para a Cloud
O Microsoft Defender for Cloud monitora seu banco de dados em busca de atividades incomuns e potencialmente prejudiciais. O Defender for Cloud é fornecido como um plano adicional para lidar com ameaças potenciais sem a necessidade de criar ou gerenciar o monitoramento de segurança. O Defender for Cloud tem disponibilidade multicloud no Banco de Dados do Azure para MySQL - Servidor Flexível, além do MySQL no AWS Aurora e RDS. O Defender for Cloud também suporta PostgreSQL e MariaDB.
O Defender for Cloud deteta ameaças de banco de dados, como:
- Ataques de força bruta: sinal anormalmente alto em falhas e login bem-sucedido após muitas falhas.
- Padrões de início de sessão invulgares: se um utilizador iniciar sessão pela primeira vez em mais de dois meses.
- Locais de entrada incomuns: se um usuário fizer logon a partir de um banco de dados incomum do Azure, ou outro provedor de nuvem, ou um IP sinalizado como suspeito.
O Defender for Cloud envia alertas de deteção para o portal do Azure e por email. Os alertas incluem:
- Detalhes da atividade suspeita.
- O associado MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge).
- Sugestões para investigar e mitigar 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 MySQL (nome de usuário/senha) e autenticação Microsoft Entra ID. Você pode ativar ambos ao mesmo tempo.
A autenticação Microsoft Entra ID permite a autenticação baseada em identidade para o servidor flexível MySQL usando identidades fornecidas pelo Microsoft Entra ID. Isso centraliza o gerenciamento de usuários para o banco de dados e outros serviços da Microsoft.
Por padrão, um servidor flexível MySQL é definido para usar apenas a autenticação MySQL (nome de usuário/senha). Você pode alterar essa configuração para usar apenas a autenticação do Microsoft Entra ID (sem usuários de banco de dados) ou combinar identidades gerenciadas com a autenticação MySQL.
Quando você usa a autenticação 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 do Microsoft Entra ID. Os grupos de administradores são mais fáceis de gerenciar porque centraliza o gerenciamento de usuários no Microsoft Entra ID em vez de ter que atualizar usuários ou permissões do MySQL diretamente. Você só pode configurar um administrador de ID do Microsoft Entra, 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 MySQL usando uma identidade Microsoft Entra, um token é emitido para permitir o login. A identidade é associada a um usuário de banco de dados por meio de seu ID de usuário exclusivo do Microsoft Entra, em vez de seu nome ou outros atributos.
Encriptação de dados
Os servidores flexíveis MySQL criptografam dados em trânsito. Por padrão, os servidores exigem conexão com Transport Layer Security (TLS) 1.2 e negam conexões não criptografadas ou conexões usando os protocolos TLS 1.0 e 1.1 obsoletos. Você pode desabilitar conexões criptografadas (pode ser que um aplicativo herdado não ofereça suporte à criptografia), permitir versões anteriores à 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 em repouso (incluindo backup e arquivos temporários criados durante a execução de consultas) usando uma chave de criptografia de dados (DEK) simétrica AES de 256 bits. Com chaves gerenciadas pelo cliente (CMK), você pode trazer sua própria chave (BYOK) para adicionar outra camada de criptografia criptografando a DEK do serviço.
O BYOK oferece 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 das chaves 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 a CMK requer vincular um banco de dados a uma UMI (identidade gerenciada atribuída pelo usuário) e, em seguida, especificar a chave, que é armazenada no Cofre de Chaves do Azure, 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.