Comparação entre o Aurora MySQL versão 3 e o Aurora MySQL versão 8.4

O Amazon Aurora MySQL versão 8.4 introduz melhorias e alterações significativas em comparação com o Aurora MySQL versão 3 (compatível com o MySQL 8.0). Este guia destaca as principais diferenças para ajudar você a entender o que há de novo e o que mudou.

Autenticação e segurança

Gerenciamento do plug-in de autenticação

O Aurora MySQL versão 3 usa o parâmetro default_authentication_plugin para configurar o plug-in de autenticação padrão para novos usuários do banco de dados.

O Aurora MySQL versão 8.4 substitui o parâmetro authentication_policy pelo parâmetro default_authentication_plugin, que oferece uma configuração de autenticação mais flexível.

TLS e criptografia

O Aurora MySQL versão 8.4 impõe padrões de segurança mais rígidos:

• O parâmetro require_secure_transport é definido ON por padrão, exigindo TLS para todas as conexões.

• Suporte somente a TLS 1.2 e TLS 1.3.

• Aplica padrões criptográficos modernos com suítes de cifras restritas.

Para obter mais informações, consulte Segurança com o Amazon Aurora MySQL.

Gerenciamento de senhas

Validação de senhas

É possível usar o plug-in e componente validate_password com o Aurora MySQL versão 3 por meio da instalação manual, limitada aos parâmetros padrão sem personalização disponível.

É possível usar o gerenciamento do componente validate_password com o Aurora MySQL versão 8.4 por meio de parâmetros de cluster de banco de dados:

• Novo parâmetro de cluster: aurora_enable_validate_password_component

• Nenhuma instalação manual é necessária. Basta habilitar ou desabilitar por meio do parâmetro.

• Componente não listado na tabela mysql.component.

• O status do componente pode ser verificado por meio de APIs de grupo de parâmetros do cluster ou de uma variável aurora_enable_validate_password_component global.

O Aurora MySQL versão 8.4 introduz os seguintes parâmetros em nível de cluster para personalização da validação de senha:

• validate_password.check_user_name

• validate_password.length

• validate_password.mixed_case_count

• validate_password.number_count

• validate_password.policy (permite somente os níveis BAIXO e MÉDIO)

• validate_password.special_char_count

Para obter mais informações, consulte Políticas de senha e validação de senha no Aurora MySQL.

Os seguintes parâmetros em nível de instância não modificáveis do plug-in validate_password foram removidos no Aurora MySQL versão 8.4:

• validate-password

• validate_password_dictionary_file

• validate_password_length

• validate_password_mixed_case_count

• validate_password_number_count

• validate_password_policy

• validate_password_special_char_count

Para obter mais informações, consulte Parâmetros de configuração do Aurora MySQL.

Políticas de senha

O Aurora MySQL versão 8.4 adiciona suporte abrangente a políticas de senha por meio de novos parâmetros de cluster:

• default_password_lifetime

• password_history

• password_reuse_interval

• password_require_current

• disconnect_on_expired_password

Esses parâmetros funcionam com políticas de senha por conta para oferecer controle granular. Para obter mais informações, consulte Políticas de senha e validação de senha no Aurora MySQL.

Alterações padrão nos parâmetros

temptable_max_mmap

O Aurora MySQL versão 3 usa um padrão fixo de 1 GiB (1073741824) para o parâmetro temptable_max_mmap em todas as classes de instância e configurações de armazenamento.

O Aurora MySQL versão 8.4.7 e posterior calcula o padrão dinamicamente com base no armazenamento alocado do cluster. A fórmula é:

LEAST(4294967296, {AllocatedStorage*3/100})

Isso define o padrão como 3% do armazenamento alocado, com um limite máximo de 4 GiB. O padrão escala de acordo com a capacidade de armazenamento e permanece limitado, o que ajuda a reduzir falhas de consulta em instâncias de leitura que usam o mecanismo de armazenamento TempTable.

Com relação à entrada de referência do parâmetro, consulte Parâmetros de configuração do Aurora MySQL.

Privilégios e perfis

Novos privilégios dinâmicos

O Aurora MySQL versão 8.4 permite novos privilégios, concedidos a rds_superuser_role.

• ALLOW_NONEXISTENT_DEFINER

• FLUSH_PRIVILEGES

• OPTIMIZE_LOCAL_TABLE

• SET_ANY_DEFINER

O privilégio SET_USER_ID é removido quando substituído por ALLOW_NONEXISTENT_DEFINER e SET_ANY_DEFINER.

Para obter mais informações, consulte Privilégios da conta de usuário mestre.

Comportamento do usuário principal

Aurora MySQL versão 3: por padrão, o usuário principal usa o plug-in de autenticação mysql_native_password para autenticação baseada em senha.

Aurora MySQL versão 8.4: o plug-in de autenticação do usuário principal é configurado com o valor padrão definido no parâmetro authentication_policy do cluster (por padrão, o plug-in caching_sha2_password).

Quando a senha do usuário principal é redefinida por meio do Console de gerenciamento da AWS, da CLI, da API ou da alternância do AWS Secrets Manager, o Aurora usa automaticamente o plug-in de autenticação definido pelo valor atual do parâmetro authentication_policy no momento da redefinição.

Imposição de usuário protegido para rdsproxyadmin

Aurora MySQL versão 3: rdsproxyadmin é um nome de usuário reservado para o RDS Proxy. No entanto, o mecanismo não impede que você crie, modifique ou elimine um usuário de banco de dados com esse nome.

Aurora MySQL versão 8.4 (a partir da 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.

Se você criou um usuário rdsproxyadmin em um cluster da versão 3, consulte Imposição de usuário protegido para rdsproxyadmin para obter orientações de preparação para a atualização.