Configuração da alternância automática para segredos do Amazon RDS, do Amazon Redshift ou do Amazon DocumentDB usando o console

Alternância é o processo de atualizar periodicamente um segredo. Quando o Secrets Manager alterna um segredo, você atualiza as credenciais tanto no segredo como no banco de dados. No Secrets Manager, você pode configurar a alternância automática para seus segredos de banco de dados.

O Secrets Manager usa funções Lambda para alternar segredos. Para obter uma visão geral, consulte Como o funciona a alternância.

dica

Para alguns Segredos gerenciados por outros serviços, você usa alternância gerenciada. Para usar Alternância gerenciada, primeiro você cria o segredo por meio do serviço de gerenciamento.

Para configurar a alternância usando o console, você precisa primeiro escolher uma estratégia de alternância. Em seguida, você configura o segredo para a alternância, o qual cria uma função de alternância do Lambda, caso você ainda não tenha uma. O console também define permissões para a função de execução da função Lambda. A última etapa é garantir que a função de alternância do Lambda possa acessar o Secrets Manager e seu banco de dados utilizando a rede.

Para ativar a alternância automática, é necessário ter permissão para criar a função de execução do IAM e anexar uma política de permissão a ela. Ambas as permissões iam:CreateRole e iam:AttachRolePolicy são necessárias.

Atenção

Conceder a uma identidade as permissões iam:CreateRole e iam:AttachRolePolicy permite que a identidade conceda a ela mesma quaisquer permissões.

Etapa 1: escolher uma estratégia de alternância e (opcionalmente) criar um segredo de superusuário

Para o Amazon RDS, o Amazon Redshift e o Amazon DocumentDB, o Secrets Manager oferece duas estratégias de alternância:

Estratégia de alternância de usuário único

Essa estratégia atualiza as credenciais de um único usuário em um segredo. O usuário deve ter permissão para atualizar a própria senha. 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. Você pode mitigar esse risco com uma estratégia de nova tentativa apropriada. Após a alternância, as novas conexões usam as novas credenciais.

Estratégia de alternância de 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, você deve 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. Você pode 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.

Importante

Se você escolher a estratégia de usuários alternados, deverá Criar um segredo de banco de dados e armazenar nele as credenciais de superusuário do banco de dados. Você precisa de um segredo com credenciais de superusuário porque a alternância clona o primeiro usuário e a maioria dos usuários não tem essa permissão.

Etapa 2: configurar a alternância e criar uma função de alternância

As funções de alternância do Amazon RDS (exceto Oracle) e o Amazon DocumentDB usam automaticamente o Secure Socket Layer (SSL) ou o Transport Layer Security (TLS) para se conectar ao seu banco de dados, se ele estiver disponível. Caso contrário, utilizarão uma conexão não criptografada.

Para ativar a alternância para um segredo do Amazon RDS, do Amazon DocumentDB ou do Amazon Redshift

1. Abra o console do Secrets Manager em https://console.aws.amazon.com/secretsmanager/.

2. Na página Secrets (Segredos), escolha o segredo.

3. Na página Secret details (Detalhes do segredo), na seção Rotation configuration (Configuração da alternância), escolha Edit rotation (Editar alternância).

4. Na caixa de diálogo Edit rotation configuration (Editar configuração da alternância), siga estas etapas:

   1. Ative a Automatic rotation (Alternância automática).

   2. Em Rotation schedule (Programação da alternância), insira sua programação no fuso horário UTC no Schedule expression builder (Desenvolvedor de expressão programada) ou como uma Schedule expression (Expressão programada). O Secrets Manager armazena sua programação como uma expressão rate() ou cron(). A janela de alternância começa automaticamente à 0h, a menos que você especifique um horário de início. Você pode alternar um segredo com intervalos a partir de quatro horas. Para obter mais informações, consulte Programar expressões.

   3. (Opcional) Em Window duration (Duração da janela), escolha a duração da janela em que deseja que o Secrets Manager alterne o seu segredo, por exemplo, 3h, por uma janela de três horas. A janela não pode se estender até a próxima janela de alternância. Se você não especificar Window duration (Duração da janela) para uma programação de alternância em horas, a janela será automaticamente encerrada após uma hora. Para uma programação de alternância em dias, a janela terminará automaticamente no final do dia.

   4. (Opcional) Escolha Rotate immediately when the secret is stored (Alternar imediatamente quando o segredo for armazenado) para alternar o seu segredo assim que as suas alterações forem salvas. Se você desmarcar a caixa de seleção, a primeira alternância começará no cronograma definido.

      Se a alternância falhar, por exemplo, porque as etapas 3 e 4 ainda não foram concluídas, o Secrets Manager repetirá o processo de alternância várias vezes.

   5. Em Rotation function (Função de alternância), execute uma das ações a seguir:

      • Selecione Create a new Lambda function (Criar uma nova função Lambda) e insira um nome para sua nova função. O Secrets Manager adiciona SecretsManager ao início do nome da função. O Secrets Manager cria a função com base no modelo apropriado e define as permissões necessárias para a função de execução do Lambda.

      • Escolha Use an existing Lambda function (Usar uma função Lambda existente) para reutilizar uma função de alternância usada para outro segredo. As funções de alternância listadas em Recommended VPC configurations (Configurações de VPC recomendadas) têm a mesma VPC e o mesmo grupo de segurança que o banco de dados, o que ajuda a função a acessar o banco de dados.

   6. Em Use separate credentials to rotate this secret (Usar credenciais separadas para alternar esse segredo), siga um dos seguintes procedimentos:

      • Para a single user rotation strategy (estratégia de alternância de usuário único), escolha No (Não).

      • Para a alternating users rotation strategy (estratégia de alternância de usuários alternados), escolha Yes (Sim). Em seguida, escolha o segredo de superusuário criado na Etapa 1.

5. Escolha Save (Salvar).

Etapa 3: (Opcional) Defina condições de permissões adicionais na função de alternância

Na política de recursos para sua função de alternância, recomendamos incluir a chave de contexto aws:SourceAccount para ajudar a evitar que o Lambda seja usado como um confused deputy. Para alguns produtos da AWS, para evitar o cenário de “confused deputy”, a AWS recomenda usar as chaves de condição globais aws:SourceArn e aws:SourceAccount. No entanto, se você incluir a condição aws:SourceArn em sua política de função de alternância, a função de alternância só poderá ser usada para alternar o segredo especificado por esse ARN. Recomendamos que inclua apenas a chave de contexto aws:SourceAccount, de modo que possa usar a função de alternância para vários segredos.

Para atualizar sua política de recursos da função de alternância

1. No console do Secrets Manager, escolha seu segredo e, em seguida, na página de detalhes, em Rotation configuration (Configuração de alternância), escolha a função de alternância do Lambda. Abra o console do Lambda.

2. Siga as instruções em Usar políticas baseadas em recursos para o Lambda para adicionar uma condição aws:sourceAccount.

   "Condition": {
       "StringEquals": {
           "AWS:SourceAccount": "123456789012"
       }
   },

Se o segredo for criptografado com uma chave KMS diferente da Chave gerenciada pela AWS aws/secretsmanager, o Secrets Manager concede permissão à função de execução do Lambda para usar a chave. Você pode usar o contexto de criptografia SecretARN para limitar o uso da função de descriptografia, de modo que a função de rotação tenha acesso apenas para descriptografar o segredo que é responsável pela rotação.

Para atualizar sua função de execução da função de rotação

1. Na função de rotação do Lambda, escolha Configuration (Configuração) e em Execution role (Função de execução), escolha Role name (Nome da função).

2. Siga as instruções em Modifying a role permissions policy (Modificar uma política de permissões de função) para adicionar uma condição kms:EncryptionContext:SecretARN.

   "Condition": {
       "StringEquals": {
           "kms:EncryptionContext:SecretARN": "SecretARN"
       }
   },

Etapa 4: configurar acesso à rede para a função de alternância

Para poder alternar um segredo, a função de alternância do Lambda deve ser capaz de acessar o segredo e o banco de dados ou serviço.

Para acessar um segredo

A função de alternância do Lambda deve ser capaz de acessar um endpoint do Secrets Manager. Se sua função do Lambda puder acessar a Internet, você pode usar um endpoint público. Para localizar um endpoint, consulte Endpoint do AWS Secrets Manager.

Se a função do Lambda for executada em uma VPC que não tem acesso à Internet, recomendamos que você configure endpoints privados de serviço do Secrets Manager dentro de sua VPC. Assim, sua VPC pode interceptar solicitações endereçadas ao endpoint regional público e redirecioná-las para o endpoint privado. Para obter mais informações, consulte VPC endpoint.

Como alternativa, você pode habilitar a função Lambda para acessar um endpoint público do Secrets Manager adicionando um gateway NAT ou um gateway da Internet à VPC, o que permite que o tráfego da VPC alcance o endpoint público. Isso expõe a VPC a um risco maior, pois um endereço IP do gateway pode ser atacado a partir da Internet pública.

Para acessar o banco de dados ou o serviço

Se seu banco de dados ou serviço estiver sendo executado em uma instância do Amazon EC2 em uma VPC, é recomendável que você configure a função do Lambda para ser executada na mesma VPC. Assim, a função de alternância pode se comunicar diretamente com seu serviço. Para obter mais informações, consulte Configuring VPC access (Configurar o acesso à VPC).

Para permitir que a função do Lambda acesse o banco de dados ou serviço, certifique-se de que os grupos de segurança anexados à sua função de alternância do Lambda permitam conexões de saída com o banco de dados ou serviço. Você também deve garantir que os grupos de segurança anexados ao seu banco de dados ou serviço permitam conexões de entrada a partir da função de alternância do Lambda.

Para alternar usuários alternativos em que o segredo do superusuário é gerenciado pelo Amazon RDS, a função de alternância do Lambda deve ser capaz de chamar o endpoint do serviço do Amazon RDS para obter as informações de conexão do banco de dados. Recomendamos que você configure um endpoint da VPC para o Amazon RDS. Para obter mais informações, consulte API do Amazon RDS e endpoints de interface da VPC no Guia do usuário do Amazon RDS.

Próximas etapas

Consulte Solução de problemas de alternância do AWS Secrets Manager.