Considerações sobre segurança para a atualização do Aurora MySQL versão 3 para a 8.4

Ao migrar do Aurora MySQL versão 3 (compatível com MySQL 8.0) para o Aurora MySQL versão 8.4, várias mudanças importantes relacionadas à segurança exigem atenção e um planejamento cuidadoso. Este guia descreve as principais mudanças de segurança e oferece recomendações para a realização de uma migração tranquila.

Política de autenticação (nova na versão 8.4)

O Aurora MySQL versão 3 (compatível com MySQL 8.0) usa o parâmetro default_authentication_plugin para configurar o plug-in de autenticação padrão usado ao criar usuários de banco de dados. No Aurora MySQL versão 8.4, esse parâmetro é substituído pelo parâmetro authentication_policy, definido como *:caching_sha2_password por padrão.

Valores compatíveis no Aurora MySQL:

A pré-verificação de atualização deprecatedDefaultAuth avisa se o cluster de origem tem default_authentication_plugin definido como mysql_native_password. Analise esse aviso e configure o parâmetro authentication_policy no grupo de parâmetros do cluster de destino ao fazer a atualização.

Comportamento do usuário principal

Novos clusters

O usuário principal é criado com o plug-in de autenticação definido pelo parâmetro authentication_policy no momento da criação do cluster. Se você usar o grupo de parâmetros padrão, o usuário principal será criado com o plug-in de autenticação caching_sha2_password. Se você usar um grupo de parâmetros personalizado com o parâmetro authentication_policy definido como *:mysql_native_password, o usuário principal será criado com o plug-in de autenticação mysql_native_password.

Redefinição da senha de usuário principal

Quando você redefine a senha do usuário principal, por meio do Console de gerenciamento da AWS, da CLI (modify-db-cluster --master-user-password) ou da API, o Aurora usa o plug-in padrão atual definido pelo parâmetro authentication_policy no momento da redefinição.

Secrets Manager e alternância de senhas

Ao usar o AWS Secrets Manager para gerenciar senhas de usuário principal, se você atualizar o valor do parâmetro authentication_policy, a próxima alternância de senha definirá o plug-in de autenticação do usuário principal para que corresponda ao novo valor do parâmetro authentication_policy.

Usuários do banco de dados criados após a atualização

Os usuários existentes do banco de dados que usam o plug-in de autenticação mysql_native_password continuam trabalhando após a atualização. Os usuários do banco de dados criados após a atualização sem a especificação da cláusula IDENTIFIED WITH usam o plug-in de autenticação definido pelo parâmetro authentication_policy. Quando o parâmetro está no valor padrão de *:caching_sha2_password, os novos usuários são criados com o plug-in de autenticação caching_sha2_password.

Para alterar o plug-in de autenticação padrão para todos os novos usuários, atualize o valor de authentication_policy. Para ter mais informações sobre os valores compatíveis, consulte Política de autenticação (nova na versão 8.4).

Para criar um usuário com um plug-in de autenticação diferente do padrão, especifique-o explicitamente na instrução CREATE USER:

CREATE USER 'username'@'host' IDENTIFIED WITH authentication-plugin BY 'password';

Alterações na criptografia e no TLS

Para exigir TLS para todas as conexões de usuário com o cluster de banco de dados do Aurora MySQL, use o parâmetro de cluster de banco de dados require_secure_transport. Por padrão, esse parâmetro está definido como ON no Aurora MySQL versão 8.4.

O Aurora MySQL versão 8.4 impõe padrões criptográficos mais rígidos, alinhados com os requisitos de segurança mais recentes nos parâmetros de cluster de banco de dados ssl_ciphers (TLS 1.2) e tls_ciphersuites (TLS 1.3). Para obter mais informações, consulte Segurança com o Amazon Aurora MySQL.

Para evitar interrupções na conexão, verifique as configurações de TLS para o cliente MySQL e o cluster de banco de dados de destino antes da migração.

Migração do componente de validação de senha

O Aurora MySQL versão 8.4 introduz o parâmetro de cluster aurora_enable_validate_password_component para habilitar ou desabilitar o componente validate_password, eliminando a necessidade de instalá-lo ou desinstalá-lo manualmente. Se você já instalou o plug-in validate_password e, desde então, habilitou o componente após a atualização, somente o componente será válido. O plug-in será ignorado.

A partir do Aurora MySQL versão 8.4, se você já tiver instalado o plug-in validate_password por meio do comando INSTALL PLUGIN, poderá migrar para o componente validate_password habilitando o parâmetro aurora_enable_validate_password_component e, em seguida, remover o plug-in por meio do comando UNINSTALL PLUGIN na sua instância de gravador.

Se você já tiver instalado o componente validate_password manualmente usando INSTALL COMPONENT 'file://component_validate_password', defina o parâmetro aurora_enable_validate_password_component no grupo de parâmetros do cluster de banco de dados de destino ao fazer a atualização. Após a atualização, o componente não será mais listado na tabela mysql.component. É possível usar a variável global aurora_enable_validate_password_component para verificar o status do componente.

Na primeira inicialização do mecanismo de banco de dados após a atualização, você verá a seguinte mensagem no log de erros do MySQL se já tiver instalado o componente manualmente:

Component 'file://component_validate_password' is being removed from mysql.component table.
validate_password component can be enabled/disabled through 'aurora_enable_validate_password_component' cluster parameter.

A pré-verificação de atualização auroraValidatePasswordPluginCheck avisa se o plug-in validate_password está instalado no cluster de origem. Esse aviso não impede a atualização, mas você deve se programar para fazer a transição para o componente após a atualização.

Novos privilégios dinâmicos

O Aurora MySQL versão 8.4 permite os seguintes novos privilégios:

Esses privilégios são concedidos automaticamente aos Privilégios da conta de usuário mestre para suas contas de usuário principal na atualização.

Imposição de usuário protegido para rdsproxyadmin

A partir do Aurora MySQL versão 8.4.7, rdsproxyadmin é um usuário protegido. O mecanismo rejeita as operações CREATE, DROP, RENAME, GRANT, REVOKE e SET PASSWORD em relação ao rdsproxyadmin em qualquer host. Para ver a lista completa de operações rejeitadas e exemplos de erro, consulte Usuários reservados no Aurora MySQL.

O Aurora MySQL versão 3 não reserva o nome rdsproxyadmin. Se você criou um usuário de banco de dados chamado rdsproxyadmin na versão 3 (em vez de permitir que o sistema o crie ao registrar um proxy de destino), analise esta seção antes de atualizar para a versão 8.4.

Antes da atualização

Se você criou um usuário rdsproxyadmin no cluster da versão 3, renomeie ou elimine a conta antes de atualizar para a versão 8.4. Você pode usar uma conexão da versão 3 para executar uma das seguintes instruções:

-- Rename the existing account to a non-reserved name
RENAME USER 'rdsproxyadmin'@'host' TO 'new_user'@'host';

-- Or drop the account if it is no longer needed
DROP USER 'rdsproxyadmin'@'host';

Atualize todos as aplicações ou credenciais armazenadas que façam referência ao nome de usuário antigo antes de iniciar a atualização.

Se você não renomear ou descartar o usuário antes da atualização

Se você atualizar um cluster que já tenha um usuário rdsproxyadmin criado por você, a atualização será concluída com êxito. A conta é preservada com sua senha e privilégios existentes, e você ainda pode se conectar ao cluster como rdsproxyadmin usando a senha original.

No entanto, após a atualização, não é possível modificar a conta. Se você tentar descartar, renomear ou alterar os privilégios, ou alterar a senha para rdsproxyadmin, a instrução exibirá um erro.

Se você quiser remover a conta após a atualização ou recuperar o nome rdsproxyadmin para uso do Proxy RDS, entre em contato com o AWS Support. O AWS Support pode remover um usuário rdsproxyadmin preexistente transferido da versão 3.