As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Estratégias de alternância da função do Lambda
Em Função do Lambda de alternância, para segredos de bancos de dados, o Secrets Manager oferece duas estratégias de alternância.
Estratégia de alternância: usuário único
Essa estratégia atualiza as credenciais de um único usuário em um segredo. Para instâncias do Db2 do Amazon RDS, como os usuários não podem alterar suas próprias senhas, é necessário fornecer credenciais de administrador em outro segredo. Essa é a estratégia de alternância mais simples, e é apropriada para a maioria dos casos de uso. Em particular, recomendamos que você use essa estratégia para obter credenciais para usuários únicos (ad hoc) ou interativos.
Quando o segredo é alternado, as conexões de banco de dados abertas não são descartadas. Enquanto a alternância acontece, há um curto período entre a alteração da senha no banco de dados e a atualização do segredo. Durante esse período, há um baixo risco de o banco de dados recusar chamadas que usam as credenciais alternadas. É possível mitigar esse risco com uma estratégia de nova tentativa apropriada
Estratégia de alternância: usuários alternados
Essa estratégia atualiza as credenciais de dois usuários em um segredo. Você cria o primeiro usuário e, durante a primeira alternância, a função de alternância o clona para criar o segundo usuário. Toda vez que o segredo é alternado, a função de alternância alterna a senha do usuário que ela atualiza. Como a maioria dos usuários não tem permissão para se clonar, é necessário fornecer as credenciais para um superuser em outro segredo. Recomendamos o uso da estratégia de alternância de usuário único quando os usuários clonados em seu banco de dados não tiverem as mesmas permissões que o usuário original, e para credenciais de usuários únicos (ad hoc) ou interativos.
Essa estratégia é apropriada para bancos de dados com modelos de permissão em que uma função possui as tabelas de banco de dados e uma segunda função tem permissão para acessar as tabelas de banco de dados. Ela também é apropriada para aplicações que requerem alta disponibilidade. Se uma aplicação recuperar o segredo durante a alternância, a aplicação ainda obterá um conjunto válido de credenciais. Após a alternância, as credenciais do user e do user_clone são válidas. Há ainda menos chances de aplicações serem recusadas durante esse tipo de alternância em comparação com a alternância de usuário único. Se o banco de dados estiver hospedado em um farm de servidores em que a alteração de senha demora algum tempo para se propagar para todos os servidores, existe o risco de o banco de dados recusar chamadas que usam as novas credenciais. É possível mitigar esse risco com uma estratégia de nova tentativa apropriada
O Secrets Manager cria o usuário clonado com as mesmas permissões do usuário original. Se você alterar as permissões do usuário original após a criação do clone, também deverá alterar as permissões do usuário clonado.
Por exemplo, se você criar um segredo com as credenciais de um usuário do banco de dados, o segredo conterá uma versão com essas credenciais.
Primeira alternância: a função de alternância cria um clone do seu usuário com uma senha gerada e essas credenciais se tornam a versão do segredo atual.
Segunda alternância: a função de alternância atualiza a senha do usuário original.
Terceira alternância: a função de alternância atualiza a senha do usuário clonado.
