Solução de problemas com o ABAC para o AWS KMS - AWS Key Management Service

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á.

Solução de problemas com o ABAC para o AWS KMS

Controlar o acesso a chaves do KMS com base em etiquetas e aliases é uma estratégia conveniente e poderosa. No entanto, ela está propensa a alguns erros previsíveis que convém evitar.

Acesso alterado devido a mudanças de etiqueta

Se uma etiqueta for excluída ou seu valor for alterado, as entidades principais que tiverem acesso a uma chave do KMS com base apenas nessa etiqueta terão acesso negado à chave do KMS. Isso também pode acontecer quando uma etiqueta incluída em uma instrução de política de negação é adicionada a uma chave do KMS. Adicionar uma etiqueta relacionada a uma política a uma chave do KMS pode permitir acesso a entidades principais que não devem ter esse acesso a uma chave do KMS.

Por exemplo, suponha que uma entidade principal tenha acesso a uma chave do KMS com base na etiqueta Project=Alpha, como a permissão fornecida pelo seguinte exemplo de instrução de política do IAM.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAMPolicyWithResourceTag", "Effect": "Allow", "Action": [ "kms:GenerateDataKeyWithoutPlaintext", "kms:Decrypt" ], "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": "Alpha" } } } ] }

Se a etiqueta for excluída dessa chave do KMS ou se o valor da etiqueta for alterado, a entidade principal não terá mais permissão para usar a chave do KMS nas operações especificadas. Isso pode se tornar evidente quando a entidade principal tenta ler ou gravar dados em um serviço da AWS que usa uma chave gerenciada pelo cliente. Para rastrear a alteração da etiqueta, revise seus logs do CloudTrail em busca de entradas TagResource ouUntagResource.

Para restaurar o acesso sem atualizar a política, altere as etiquetas na chave do KMS. Essa ação tem impacto mínimo diferente de um breve período em que está entrando em vigor no AWS KMS. Para evitar um erro como esse, conceda permissões de marcação e desmarcação apenas a entidades principais que precisem delas elimite as permissões de marcação a etiquetas que eles precisam gerenciar. Antes de alterar uma etiqueta, pesquise políticas para detectar o acesso que depende dessa etiqueta e obtenha chaves do KMS em todas as regiões que tenham a etiqueta. Você pode considerar a criação de um alarme do Amazon CloudWatch quando etiquetas específicas forem modificadas.

Alteração do acesso devido a mudanças de alias

Se um alias for excluído ou associado a uma chave do KMS diferente, as entidades principais que tiverem acesso a essa chave do KMS com base apenas nesse alias terão acesso negado a ela. Isso também pode acontecer quando um alias associado a uma chave do KMS é incluído em uma instrução de política de negação. Adicionar um alias relacionado a uma política a uma chave do KMS também pode permitir acesso a entidades principais que não devem ter esse acesso a uma chave do KMS.

Por exemplo, a seguinte instrução de política do IAM usa a chave de condição kms:ResourceAliases para permitir o acesso a chaves do KMS em diferentes regiões da conta com qualquer um dos aliases especificados.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AliasBasedIAMPolicy", "Effect": "Allow", "Action": [ "kms:List*", "kms:Describe*", "kms:Decrypt" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "ForAnyValue:StringEquals": { "kms:ResourceAliases": [ "alias/ProjectAlpha", "alias/ProjectAlpha_Test", "alias/ProjectAlpha_Dev" ] } } } ] }

Para rastrear a alteração de alias, reveja seus logs do CloudTrail em busca de entradas CreateAlias, UpdateAlias e DeleteAlias.

Para restaurar o acesso sem atualizar a política, modifique o alias associado à chave do KMS. Como cada alias pode ser associado a apenas uma chave do KMS em uma conta e região, o gerenciamento de aliases é um pouco mais difícil que o de etiquetas. Restaurar o acesso a algumas das entidades principais em uma chave do KMS pode negar acesso para as mesmas ou outras entidades principais a uma chave do KMS diferente.

Para evitar esse erro, conceda permissões de gerenciamento de alias somente às entidades principais que precisam dele e limite suas permissões de gerenciamento de alias para aliases que elas precisam gerenciar. Antes de atualizar ou excluir um alias, pesquise políticas para detectar o acesso que depende do alias e localize chaves do KMS em todas as regiões associadas a ele.

Acesso negado devido à cota de aliases

Usuários autorizados a usar uma chave do KMS por uma condição kms:ResourceAliases receberão uma exceção de AccessDenied se a chave do KMS exceder a cota padrão de aliases por chave do KMS para essa conta e região.

Para restaurar o acesso, exclua aliases associados à chave do KMS, para que esta esteja em conformidade com a cota. Outra opção é usar um mecanismo alternativo para conceder aos usuários acesso à chave do KMS.

Alteração de autorização atrasadas

Alterações feitas em etiquetas e aliases podem levar até cinco minutos para afetar a autorização de chaves do KMS. Como resultado, uma alteração de etiqueta ou alias pode ser refletida nas respostas das operações da API antes que estas afetem a autorização. Esse atraso provavelmente será maior que o breve atraso de consistência final que afeta a maioria das operações do AWS KMS.

Por exemplo, você pode ter uma política do IAM que permita que certas entidades principais utilizem qualquer chave do KMS com uma etiqueta "Purpose"="Test". Em seguida, você adiciona a etiqueta "Purpose"="Test" a uma chave do KMS. Embora a operação TagResource seja concluída e a resposta ListResourceTags confirme que a etiqueta está atribuída à chave do KMS, as entidades principais podem não ter acesso à chave do KMS por até cinco minutos.

Para evitar erros, crie esse atraso esperado no seu código.

Solicitações com falha devido a atualizações de alias

Quando você atualiza um alias, associa um alias existente a uma chave do KMS diferente.

Solicitações Decrypt e ReEncrypt que especificam o nome do alias ou o ARN do alias podem falhar porque o alias agora está associado a uma chave do KMS que não criptografou o texto cifrado. Essa situação geralmente retorna uma IncorrectKeyException ou NotFoundException. Ou, se a solicitação não tiver o parâmetro KeyId ou DestinationKeyId, a operação pode falhar com uma exceção AccessDenied porque o autor da chamada não tem mais acesso à chave do KMS que criptografou o texto cifrado.

É possível rastrear a alteração observando os logs do CloudTrail em busca de entradas de log CreateAlias, UpdateAlias e DeleteAlias. Também é possível usar o valor do campo LastUpdatedDate na resposta ListAliases para detectar uma alteração.

Por exemplo, o seguinte exemplo de ListAliases mostra que o alias ProjectAlpha_Test na condição kms:ResourceAliasesfoi atualizado. Como resultado, as entidades principais que têm acesso com base nesse alias perdem acesso à chave do KMS anteriormente associada. Em vez disso, elas têm acesso à chave do KMS recém-associada.

$ aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]' { "Aliases": [ { "AliasName": "alias/ProjectAlpha_Test", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test", "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321", "CreationDate": 1566518783.394, "LastUpdatedDate": 1605308931.903 }, { "AliasName": "alias/ProjectAlpha_Restricted", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted", "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1553410800.010, "LastUpdatedDate": 1553410800.010 } ] }

A solução para essa alteração não é simples. É possível atualizar o alias novamente para associá-lo à chave do KMS original. No entanto, antes de fazer isso, você precisa considerar o efeito dessa alteração na chave do KMS atualmente associada. Se as entidades principais usaram a última chave do KMS em operações de criptografia, talvez elas precisem de acesso contínuo a ela. Nesse caso, convém atualizar a política para garantir que as entidades principais tenham permissão para usar as duas chaves do KMS.

Para evitar um erro como esse, antes de atualizar um alias, pesquise políticas para detectar o acesso que depende do alias. Em seguida, obtenha chaves do KMS em todas as regiões associadas a esse alias. Conceda permissões de gerenciamento de alias somente às entidades principais que precisam dele e limite suas permissões de gerenciamento de alias para aliases que elas precisam gerenciar.