Conceitos do AWS Secrets Manager

Secreta

No Secrets Manager, um segredo são informações de segredos, isto é, o valor do segredo mais alguns metadados sobre o segredo. Um valor do segredo pode ser uma string ou um binário. Para armazenar vários valores de string em um segredo, recomendamos usar uma string de texto JSON com pares de chave-valor, por exemplo:

{
  "host"       : "ProdServer-01.databases.example.com",
  "port"       : "8888",
  "username"   : "administrator",
  "password"   : "EXAMPLE-PASSWORD",
  "dbname"     : "MyDatabase",
  "engine"     : "mysql"
}

Os metadados de um segredo incluem:

• Um nome do recurso da Amazon (ARN) com o seguinte formato:

  arn:aws:secretsmanager:<Region>:<AccountId>:secret:SecretName-6RandomCharacters

  O Secrets Manager inclui seis caracteres aleatórios ao final do nome do segredo para ajudar a garantir que o ARN do segredo seja único. Se o segredo original for excluído e, então, for criado um novo com o mesmo nome, os dois segredos terão ARNs diferentes, em função desses caracteres. Os usuários com acesso ao segredo antigo não terão acesso automático ao novo segredo, uma vez que os ARNs são diferentes.

• O nome do segredo, uma descrição, uma política de recursos e etiquetas.

• O ARN para uma chave de criptografia, uma AWS KMS key que o Secrets Manager usa para criptografar e descriptografar o valor do segredo. O Secrets Manager sempre armazena o texto do segredo de forma criptografada e criptografa o segredo em trânsito. Consulte Criptografia e decodificação secretas em AWS Secrets Manager.

• Informações sobre como alternar o segredo, se você configurar a alternância. Consulte Rotation.

O Secrets Manager usa políticas de permissões do IAM para garantir que apenas usuários autorizados possam acessar ou modificar o segredo. Consulte Autenticação e controle de acesso para o AWS Secrets Manager.

Um segredo tem versões que contêm cópias do valor do segredo criptografado. Quando você altera o valor do segredo, ou o segredo é alternado, o Secrets Manager cria uma nova versão. Consulte Versão.

Você pode usar um segredo em várias Regiões da AWS ao replicá-lo. Quando você replica um segredo, você cria uma cópia do segredo primário ou original, chamado de segredo de réplica. O segredo de réplica permanece vinculado ao segredo primário. Consulte Replicar um segredo do AWS Secrets Manager para outras Regiões da AWS.

Consulte Criar e gerenciar segredos com o AWS Secrets Manager.

Versão

Um segredo tem versões que contêm cópias do valor do segredo criptografado. Quando você altera o valor do segredo, ou o segredo é alternado, o Secrets Manager cria uma nova versão.

O Secrets Manager não armazena um histórico linear de segredos com versões. Em vez disso, ele rastreia três versões específicas rotulando-as:

• A versão atual - AWSCURRENT

• A versão anterior - AWSPREVIOUS

• A versão pendente (durante a alternância): AWSPENDING

Um segredo sempre tem uma versão rotulada AWSCURRENT, e o Secrets Manager retorna essa versão por padrão quando você recupera o valor secreto.

Você também pode rotular as versões com suas próprias etiquetas update-secret-version-stageligando para o AWS CLI. É possível anexar até 20 rótulos a versões em um segredo. Duas versões do segredo não podem ter o mesmo rótulo de preparação. As versões podem ter vários rótulos.

O Secrets Manager nunca remove as versões rotuladas, mas as versões sem rótulos são consideradas obsoletas. O Secrets Manager remove versões obsoletas quando há mais de 100. O Secrets Manager não remove versões criadas há menos de 24 horas.

A figura a seguir mostra um segredo que tem versões rotuladas AWS e versões rotuladas pelo cliente. As versões sem rótulos são consideradas obsoletas e serão removidas pelo Secrets Manager em algum momento no future.

Rotation

Alternância é o processo em que você atualiza periodicamente o segredo para dificultar o acesso de um invasor às credenciais. No Secrets Manager, você pode configurar alternância automática para seus segredos. Quando o Secrets Manager alterna um segredo, ele atualiza as credenciais no segredo e no banco de dados ou serviço. Consulte Alternar segredos do AWS Secrets Manager.

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.

Estratégia de alternância

O Secrets Manager oferece duas estratégias de alternância:

• Usuário único
• Usuários alternados

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, você deve 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. 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: 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.

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 secreta atual.

Segunda alternância: a função de alternância atualizada a senha do usuário original.

Terceira alternância: a função de alternância atualizada a senha do usuário clonado.