Revogando e Alternando Segredos Expostos

Depois que uma credencial for confirmada como vazada, a rapidez é importante — mas a ordem também. Desativar uma chave abruptamente pode interromper a produção se você não entender primeiro o que depende dela.

O objetivo é bloquear o invasor mantendo as cargas de trabalho legítimas em execução, idealmente em uma única sequência ensaiada.

A primeira ação diante de uma chave de acesso vazada é desativá-la, não excluí-la. Definir o status da chave como Inactive interrompe imediatamente seu funcionamento.

mantê-la inativa por enquanto preserva a chave para correlação forense no CloudTrail. Exclua-a somente depois que a investigação for concluída.

Para usos legítimos, a alteração consiste em emitir uma nova chave de acesso, atualizar todos os locais que usavam a antiga e então desativar a chave comprometida.

Fazer isso nessa ordem evita uma interrupção: a nova credencial está ativa antes que a antiga seja desligada. Sempre verifique primeiro se o aplicativo funciona com a nova chave.

Desativar uma chave de longa duração não encerra as credenciais temporárias que ela possa já ter produzido. Para funções, use o recurso de revogar sessões do IAM, que anexa uma política de negação baseada em um horário limite de emissão do token.

Isso invalida todas as sessões ativas anteriores àquele momento, fechando a porta para credenciais que já estejam nas mãos do invasor.

Antes de alterar a chave, descubra onde o segredo está. O CloudTrail mostra quais serviços e IPs usaram a chave.

Um segredo inserido diretamente no código em muitos locais é justamente o motivo pelo qual essa prática é perigosa. Mapear cada consumidor garante que a alteração não deixe um sistema esquecido quebrado nem uma cópia do segredo ainda em uso.

O AWS Secrets Manager armazena segredos como senhas de banco de dados e chaves de API e pode alterá-los automaticamente conforme uma programação, usando uma função do Lambda.

A alteração automática significa que um segredo vazado tem uma vida útil curta e que os aplicativos obtêm o valor atual em tempo de execução, em vez de manter uma cópia antiga inserida diretamente no código.

Uma credencial vazada geralmente abre acesso a outras. Se um invasor usou uma chave para ler um banco de dados, as senhas desse banco também podem estar comprometidas.

Altere também os segredos dos sistemas dependentes. Pense na cadeia: todo segredo que o invasor possa ter acessado deve ser considerado exposto e substituído.

Se a AWS detectar uma exposição, poderá anexar AWSCompromisedKeyQuarantineV2 ao usuário, negando ações de alto risco enquanto ainda permite que você investigue.

Não a desanexe simplesmente e siga em frente. Trate-a como um sinal de que a correção real — desativação, alteração e revisão — ainda precisa ser concluída por você.

A alteração interrompe abusos futuros, mas não desfaz danos passados. Use o CloudTrail para listar cada ação realizada pela credencial comprometida.

Desfaça alterações maliciosas: exclua usuários não autorizados do IAM, remova chaves de acesso secundárias e elimine os recursos criados pelo invasor. A contenção e a limpeza são etapas separadas e necessárias.

Após a recuperação, reduza os riscos futuros. Substitua chaves de longa duração por credenciais temporárias baseadas em funções, ative a alteração automática de segredos e adicione a verificação de segredos ao seu fluxo de integração e entrega contínuas.

A correção mais forte é arquitetural: se não houver um segredo estático para vazar, não haverá nada para o invasor encontrar.

A correção não termina até que seja registrada. Documente quais credenciais foram alteradas, o que o invasor fez e o que foi revertido.

Notifique as partes interessadas listadas no seu manual de procedimentos e, se dados regulamentados tiverem sido expostos, cumpra suas obrigações de notificação de violação. Um registro claro transforma o incidente em aprendizado e atende a auditorias posteriores.

Para remediar uma credencial vazada, desative a chave de acesso (preservando-a para a análise forense), faça a rotação para uma nova chave sem indisponibilidade e revogue as sessões ativas de função para invalidar as credenciais temporárias já emitidas. Primeiro, mapeie todos os consumidores, faça a rotação dos segredos posteriores aos quais o invasor pode ter tido acesso e reverta as alterações maliciosas registradas no CloudTrail. Use o Secrets Manager para fazer a rotação automática e migre para credenciais temporárias baseadas em funções para evitar recorrências.