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á.
Práticas recomendadas do AWS Secrets Manager
O Secrets Manager oferece uma série de atributos de segurança a serem considerados no desenvolvimento e na implementação das suas próprias políticas de segurança. As melhores práticas a seguir são diretrizes gerais e não representam uma solução completa de segurança. Como essas melhores práticas podem não ser adequadas ou suficientes para o seu ambiente, trate-as como considerações úteis em vez de prescrições.
Considere as práticas recomendadas a seguir para armazenar e gerenciar segredos:
- Armazene credenciais e outras informações confidenciais no AWS Secrets Manager
- Encontre segredos desprotegidos em seu código
- Escolha uma chave de criptografia para o seu segredo
- Use o armazenamento em cache para recuperar segredos
- Alternar segredos do
- Reduza os riscos decorrentes do uso da CLI
- Limite o acesso aos segredos
- Replique os segredos
- Monitorar segredos
- Execute sua infraestrutura em redes privadas
Armazene credenciais e outras informações confidenciais no AWS Secrets Manager
O Secrets Manager ajuda a melhorar sua postura de segurança e conformidade, além de reduzir o risco de acesso não autorizado às informações confidenciais. O Secrets Manager criptografa segredos em repouso usando chaves de criptografia que você possui e armazena no AWS Key Management Service (AWS KMS). Quando você recupera um segredo, o Secrets Manager decodifica o segredo e o transmite com segurança via TLS para seu ambiente local. Para ter mais informações, consulte Criação de um segredo do AWS Secrets Manager.
Encontre segredos desprotegidos em seu código
O CodeGuru Reviewer se integra ao Secrets Manager para usar um detector de segredos que localiza segredos desprotegidos em seu código. O detector de segredos pesquisa senhas diretamente codificadas, cadeias de conexão de banco de dados, nomes de usuário e muito mais. Para ter mais informações, consulte Encontre segredos desprotegidos no código com o Amazon CodeGuru Reviewer.
O Amazon Q pode varrer sua base de código em busca de vulnerabilidades de segurança e problemas de qualidade de código para melhorar a postura de suas aplicações durante todo o ciclo de desenvolvimento. Para obter mais informações, consulte Varredura do seu código com o Amazon Q no Guia do usuário do Amazon Q Developer.
Escolha uma chave de criptografia para o seu segredo
Na maioria dos casos, recomendamos usar a chave aws/secretsmanager
gerenciada pela AWS para criptografar segredos. Não há custo para seu uso.
Para poder acessar um segredo de outra conta ou aplicar uma política de chaves à chave de criptografia, use uma chave gerenciada pelo cliente para criptografar o segredo.
-
Na política de chaves, atribua o valor
secretsmanager.<region>.amazonaws.com
à chave de condição kms:ViaService. Isso limita o uso da chave somente às solicitações do Secrets Manager. -
Para limitar ainda mais o uso da chave somente a solicitações do Secrets Manager com o contexto correto, use chaves ou valores no contexto de criptografia do Secrets Manager como condição para usar a chave do KMS, criando:
-
Um operador de condição de string em uma política do IAM ou política de chave
-
Uma restrição de concessão em uma concessão
-
Para ter mais informações, consulte Criptografia e descriptografia de segredos no AWS Secrets Manager.
Use o armazenamento em cache para recuperar segredos
Para usar seus segredos com mais eficiência, recomendamos que você use um dos seguintes componentes de cache com suporte do Secrets Manager para armazenar seus segredos em cache e atualizá-los somente quando necessário:
Use segredos do AWS Secrets Manager em funções do AWS Lambda
Use segredos do AWS Secrets Manager no Amazon Elastic Kubernetes Service
Use o Agente do AWS Secrets Manager para padronizar o consumo de segredos do Secrets Manager em ambientes como o Amazon Elastic Container Service, o AWS Lambda Amazon Elastic Kubernetes Service e o Amazon Elastic Compute Cloud.
Alternar segredos do
Se você não alterar o segredos por um longo período, eles se tornam mais propensos a ser comprometidos. Com o Secrets Manager, é possível configurar alternância automática com intervalos a partir de quatro horas. O Secrets Manager oferece duas estratégias de alternância: Usuário único e Usuários alternados. Para ter mais informações, consulte Alternar segredos do AWS Secrets Manager.
Reduza os riscos decorrentes do uso da CLI
Quando você usa a AWS CLI para chamar operações da AWS, você insere esses comandos em um shell de comandos. A maioria dos shells de comando oferece atributos que podem comprometer seus segredos, como o registro log e a capacidade de ver o último comando digitado. Antes de usar a AWS CLI para inserir informações confidenciais, certifique-se sobre Mitigação de riscos do uso da AWS CLI para armazenar segredos do AWS Secrets Manager.
Limite o acesso aos segredos
Em declarações de política do IAM que controlem o acesso aos seus segredos, use o princípio de acesso de privilégio mínimo. É possível usar políticas e perfis do IAM, políticas de recursos e controle de acesso por atributo (ABAC). Para ter mais informações, consulte Autenticação e controle de acesso para o AWS Secrets Manager.
Tópicos
Bloqueie o acesso amplo aos segredos
Em políticas de identidade que permitem a ação PutResourcePolicy
, recomendamos usar BlockPublicPolicy: true
. Essa condição significa que os usuários só poderão anexar uma política de recursos a um segredo se a política não permitir acesso amplo.
O Secrets Manager usa o raciocínio automatizado Zelkova para analisar políticas de recursos para acesso amplo. Para obter mais informações sobre o Zelkova, consulte Como a AWS usa raciocínio automatizado para ajudar você a obter segurança em escala
O exemplo a seguir mostra como usar BlockPublicPolicy
.
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "secretsmanager:PutResourcePolicy", "Resource": "
SecretId
", "Condition": { "Bool": { "secretsmanager:BlockPublicPolicy": "true" } } } }
Tenha cuidado com as condições de endereço IP nas políticas
Tome cuidado ao especificar os operadores de condição do endereço IP ou a chave de condição aws:SourceIp
em uma declaração de política que permite ou nega acesso ao Secrets Manager. Por exemplo, se você anexar uma política que restrinja ações da AWS para solicitações do intervalo de endereços IP da sua rede corporativa, suas solicitações como um usuário do IAM que invoca a solicitação da rede corporativa funcionarão como o esperado. Porém, se você habilitar outros serviços para acessar o segredo em seu nome, por exemplo, quando você habilitar a alternância com uma função Lambda, essa função chamará as operações do Secrets Manager de um espaço de endereço interno da AWS. As solicitações afetadas pela política com o filtro de endereços IP falharão.
Além disso, a chave de condição aws:sourceIP
é menos efetiva quando a solicitação se origina em um endpoint da Amazon VPC. Para restringir solicitações a um endpoint da VPC específico, use Limite solicitações com condições do endpoint da VPC.
Limite solicitações com condições do endpoint da VPC
Para conceder ou negar acesso a solicitações de uma determinada VPC ou de um endpoint da VPC, use aws:SourceVpc
para limitar o acesso a solicitações da VPC especificada ou aws:SourceVpce
para limitar o acesso a solicitações do endpoint da VPC especificado. Consulte Exemplo: Permissões e VPCs.
-
aws:SourceVpc
limita o acesso a solicitações da VPC especificado. -
aws:SourceVpce
limita o acesso a solicitações do endpoint da VPC especificado.
Se você usar essas chaves de condição em uma declaração de política de recurso que permite ou nega o acesso a segredos do Secrets Manager, poderá inadvertidamente negar acesso a serviços que usam o Secrets Manager para acessar segredos em seu nome. Apenas alguns serviços da AWS podem ser executados com um endpoint em sua VPC. Se você restringir as solicitações de um segredo a uma VPC ou a um endpoint da VPC, poderão ocorrer falhas nas chamadas para o Secrets Manager de um serviço não configurado para o serviço.
Consulte Uso de um endpoint da VPC do AWS Secrets Manager.
Replique os segredos
O Secrets Manager pode replicar automaticamente seus segredos em várias regiões da AWS para atender aos seus requisitos de resiliência ou de recuperação de desastres. Para ter mais informações, consulte Replicar segredos do AWS Secrets Manager por regiões.
Monitorar segredos
O Secrets Manager permite auditar e monitorar segredos por meio da integração com serviços de registro em log, monitoramento e notificação da AWS. Para obter mais informações, consulte:
Execute sua infraestrutura em redes privadas
Sempre que possível, recomendamos que você execute o máximo da infraestrutura em redes privadas que não sejam acessíveis pela Internet pública. É possível estabelecer uma conexão privada entre a sua VPC e o Secrets Manager criando um interface VPC endpoint (Endpoint da VPC de interface). Para ter mais informações, consulte Uso de um endpoint da VPC do AWS Secrets Manager.