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á.
# ABAC para AWS KMS
O controle de acesso baseado em atributos (ABAC) é uma estratégia de autorização que define permissões com base em atributos. AWS KMS oferece suporte ao ABAC, permitindo que você controle o acesso às chaves gerenciadas pelo cliente com base nas tags e aliases associados às chaves KMS. As chaves de condição de tag e alias que permitem a entrada do ABAC AWS KMS fornecem uma maneira poderosa e flexível de autorizar os diretores a usar as chaves do KMS sem editar políticas ou gerenciar concessões. Porém, você deve usar esse recurso com cuidado, para que as entidades principais não sejam tenham o acesso inadvertidamente permitido ou negado.
Se você usar ABAC, esteja ciente de que a permissão para gerenciar etiquetas e aliases agora é uma permissão de controle de acesso. Certifique-se de conhecer as etiquetas e os aliases existentes em todas as chaves do KMS antes de implantar uma política que depende de etiquetas ou aliases. Tome precauções razoáveis ao adicionar, excluir e atualizar aliases e ao marcar e desmarcar chaves. Conceda permissões para gerenciar etiquetas e aliases apenas às entidades principais que precisam deles e limite as etiquetas e os aliases que eles podem gerenciar.
**Observações**
Ao usar o ABAC para AWS KMS, tenha cuidado ao dar permissão aos diretores para gerenciar tags e aliases. A alteração de uma etiqueta ou de um alias pode permitir ou negar permissão para uma chave do KMS. Os administradores de chaves que não tiverem permissão para alterar políticas de chaves ou criar concessões poderão controlar o acesso às chaves do KMS se tiverem permissão para gerenciar etiquetas ou aliases.
Pode levar até cinco minutos para que alterações de etiqueta e alias afetem a autorização de chaves do KMS. Alterações recentes podem estar visíveis em operações de API antes de afetarem a autorização.
Para controlar o acesso a uma chave do KMS com base em seu alias, você deve usar uma chave de condição. Você não pode usar um alias para representar uma chave do KMS no elemento `Resource`de uma instrução de política. Quando um alias é exibido no elemento `Resource`, a instrução de política aplica-se a esse alias, e não à chave do KMS associada.
**Saiba mais**
+ Para obter detalhes sobre o AWS KMS suporte ao ABAC, incluindo exemplos, consulte [Usar aliases para controlar o acesso a chaves do KMS](alias-authorization.md) e. [Usar tags para controlar o acesso a chaves do KMS](tag-authorization.md)
+ Para obter mais informações gerais sobre o uso de tags para controlar o acesso aos AWS recursos, consulte [Para AWS que serve o ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)? e [controlar o acesso aos AWS recursos usando tags de recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) no *Guia do usuário do IAM*.
## Chaves de condição ABAC para AWS KMS
Para autorizar o acesso a chaves do KMS com base em suas etiquetas e aliases, use as seguintes chaves de condição em uma política de chaves ou política do IAM.
| Chave de condição para ABAC | Description | Tipo de política | AWS KMS operações |
| --- | --- | --- | --- |
| [leis: ResourceTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) | A etiqueta (chave e valor) na chave do KMS corresponde à etiqueta (chave e valor) ou ao padrão de etiqueta na política | Somente política do IAM | Operações de recursos de chaves do KMS 2 |
| [aws:RequestTag//tecla de *tag*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) | A etiqueta (chave e valor) na solicitação corresponde à etiqueta (chave e valor) ou ao padrão de etiqueta na política | Políticas de chaves e políticas do IAM1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html), [UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) |
| [leis: TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) | Chaves de etiqueta na solicitação correspondem a chaves de etiqueta na política | Políticas de chaves e políticas do IAM1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html), [UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) |
| [kms: ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) | Aliases associados à chave do KMS correspondem a aliases ou padrões de alias na política | Somente política do IAM | Operações de recursos de chaves do KMS 2 |
| [kms: RequestAlias](conditions-kms.md#conditions-kms-request-alias) | O alias que representa a chave do KMS na solicitação corresponde ao alias ou aos padrões de alias na política. | Políticas de chaves e políticas do IAM1 | [Operações criptográficas](kms-cryptography.md#cryptographic-operations), [DescribeKey[GetPublicKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html)](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) |
1Qualquer chave de condição que possa ser usada em uma política de chaves também pode ser usada em uma política do IAM, mas somente se[a política de chaves a permitir](key-policy-default.md#key-policy-default-allow-root-enable-iam).
2A *operação de recurso de chave do KMS* é uma operação autorizada para uma chave do KMS específica. Para identificar as operações de recursos de chaves do KMS, no [tabela de permissões do AWS KMS](kms-api-permissions-reference.md#kms-api-permissions-reference-table), procure um valor de chave do KMS na coluna `Resources`para a operação.
Por exemplo, é possível usar essas chaves de condição para criar as seguintes políticas.
+ Uma política do IAM com `kms:ResourceAliases` que concede permissão para usar chaves do KMS com um alias específico ou um padrão de alias. Isso é um pouco diferente das políticas que dependem de tags: embora você possa usar padrões de aliases em uma política, cada alias deve ser exclusivo em uma região Conta da AWS e. Isso permite que você aplique uma política a um conjunto selecionado de chaves KMS sem listar a chave ARNs das chaves KMS na declaração de política. Para adicionar ou remover chaves do KMS do conjunto, altere o alias da chave do KMS.
+ Uma política de chaves com `kms:RequestAlias` que permite que as entidades principais usem uma chave do KMS em uma operação `Encrypt`, mas somente quando a solicitação `Encrypt` usa esse alias para identificar a chave do KMS.
+ Uma política do IAM com `aws:ResourceTag/tag-key` que nega permissão para usar chaves do KMS com uma determinada chave de etiqueta e um valor de etiqueta. Isso permite aplicar uma política a um conjunto selecionado de chaves KMS sem listar a chave ARNs das chaves KMS na declaração de política. Para adicionar ou remover chaves do KMS do conjunto, marque ou desmarque a chave do KMS.
+ Uma política do IAM com `aws:RequestTag/tag-key` que permite que as entidades principais excluam somente etiquetas `"Purpose"="Test"` de chaves do KMS.
+ Uma política do IAM com `aws:TagKeys` que nega permissão para marcar ou desmarcar uma chave do KMS com uma chave de etiqueta `Restricted`.
O ABAC torna o gerenciamento de acesso flexível e escalável. Por exemplo, você pode usar a chave de condição `aws:ResourceTag/tag-key` para criar uma política do IAM que permite que as entidades principais usem uma chave do KMS para operações especificadas somente quando essa chave tem uma etiqueta `Purpose=Test`. A política aplica-se a todas as chaves do KMS em todas as regiões da Conta da AWS.
Quando anexada a um usuário ou função, a seguinte política do IAM permite que as entidades principais usem todas as chaves do KMS existentes com uma etiqueta `Purpose=Test` para as operações especificadas. Para fornecer esse acesso a chaves do KMS novas ou existentes, não é necessário alterar a política. Basta anexar a etiqueta `Purpose=Test`às chaves do KMS. Da mesma forma, para remover esse acesso das chaves do KMS com uma etiqueta `Purpose=Test`, edite ou exclua essa etiqueta.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AliasBasedIAMPolicy",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:*:111122223333:key/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Purpose": "Test"
}
}
}
]
}
```
------
No entanto, se você usar esse recurso, tenha cautela ao gerenciar etiquetas e aliases. Operações de adicionar, alterar ou excluir uma marca ou alias podem inadvertidamente permitir ou negar acesso a uma chave do KMS. Os administradores de chaves que não tiverem permissão para alterar políticas de chaves ou criar concessões poderão controlar o acesso às chaves do KMS se tiverem permissão para gerenciar etiquetas e aliases. Para atenuar esse risco, considere[limitar permissões para gerenciar etiquetas](tag-permissions.md#tag-permissions-conditions) e[aliases](alias-access.md#alias-access-limiting). Por exemplo, é possível permitir que apenas as entidades principais selecionadas gerenciem etiquetas do `Purpose=Test`. Para obter mais detalhes, consulte [Usar aliases para controlar o acesso a chaves do KMS](alias-authorization.md) e [Usar tags para controlar o acesso a chaves do KMS](tag-authorization.md).
## Etiquetas ou aliases?
AWS KMS suporta ABAC com tags e aliases. Ambas as opções proporcionam uma estratégia de controle de acesso flexível e escalável, mas são ligeiramente diferentes uma da outra.
Você pode decidir usar tags ou usar aliases com base em seus padrões de AWS uso específicos. Por exemplo, se você já concedeu permissões de marcação para a maioria dos administradores, talvez seja mais fácil controlar uma estratégia de autorização baseada em aliases. Ou, se você estiver se aproximando da cota de [aliases por chave do KMS](resource-limits.md#aliases-per-key), talvez prefira uma estratégia de autorização baseada em etiquetas.
Os benefícios a seguir são de interesse geral.
**Benefícios do controle de acesso baseado em tags**
+ O mesmo mecanismo de autorização para diferentes tipos de AWS recursos.
É possível usar a mesma etiqueta ou chave de etiqueta para controlar o acesso a vários tipos de recursos, como cluster do Amazon Relational Database Service (Amazon RDS), volume do Amazon Elastic Block Store (Amazon EBS) e chave do KMS. Esse recurso permite diversos modelos de autorização diferentes que são mais flexíveis que o controle de acesso baseado em função tradicional.
+ Autorize o acesso a um grupo de chaves do KMS.
É possível usar etiquetas para gerenciar o acesso a um grupo de chaves do KMS na mesma região e Conta da AWS . Atribua a mesma etiqueta ou chave de etiqueta às chaves do KMS qye você escolher. Em seguida, crie uma declaração easy-to-maintain de política simples baseada na tag ou na chave da tag. Para adicionar ou remover uma chave do KMS do seu grupo de autorização, adicione ou remova a etiqueta: não é necessário editar a política.
**Benefícios do controle de acesso baseado em alias**
+ Autorize o acesso a operações de criptografia com base em aliases.
A maioria das condições de política baseadas em solicitações para atributos, incluindo [aws:RequestTag/*tag-key*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag), afetam somente as operações que adicionam, editam ou excluem o atributo. Mas a chave [kms: RequestAlias](conditions-kms.md#conditions-kms-request-alias) condition controla o acesso às operações criptográficas com base no alias usado para identificar a chave KMS na solicitação. Por exemplo, você pode conceder uma permissão à entidade principal para usar uma chave do KMS em uma operação `Encrypt`, mas somente quando o valor do parâmetro `KeyId`é`alias/restricted-key-1`. Para atender a essa condição, é necessário o seguinte:
+ A chave do KMS deve estar associada a esse alias.
+ A solicitação deve usar o alias para identificar a chave do KMS.
+ A entidade principal deve ter permissão para usar a chave do KMS sujeita à condição `kms:RequestAlias`.
Isso é particularmente útil se seus aplicativos geralmente usam nomes de alias ou alias ARNs para se referir às chaves KMS.
+ Forneça permissões muito limitadas.
Um alias deve ser exclusivo em uma região Conta da AWS e. Como resultado, o ato de conceder acesso para as entidades principais a uma chave do KMS baseada em um alias pode ser muito mais restritivo do que o conceder acesso para eles com base em uma etiqueta. Diferentemente de aliases, etiquetas podem ser atribuídas a várias chaves do KMS na mesma conta e região. Se você escolher, é possível usar um padrão de alias, como`alias/test*`, a fim de conceder acesso para as entidades principais a um grupo de chaves do KMS na mesma conta e região. Porém, permitir ou negar o acesso a um alias específico possibilita um controle muito rigoroso sobre as chaves do KMS.
# Solução de problemas do ABAC para 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.
------
#### [ JSON ]
****
```
{
"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 ficar evidente quando o diretor tenta ler ou gravar dados em um AWS serviço que usa uma chave gerenciada pelo cliente. Para rastrear a alteração da tag, revise seus CloudTrail registros [TagResource](ct-tagresource.md)ou [UntagResource entradas](ct-untagresource.md).
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 e[limite as permissões de marcação](tag-permissions.md#tag-permissions-conditions) 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 criar um CloudWatch alarme da Amazon quando determinadas tags forem alteradas.
## 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 declaração de política do IAM usa a chave de ResourceAliases condição [kms:](conditions-kms.md#conditions-kms-resource-aliases) para permitir o acesso às chaves KMS em diferentes regiões da conta com qualquer um dos aliases especificados.
------
#### [ JSON ]
****
```
{
"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 do alias, revise seus CloudTrail registros de [CreateAlias[UpdateAlias](ct-updatealias.md)](ct-createalias.md), e [DeleteAlias](ct-deletealias.md)entradas.
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](alias-access.md#alias-access-limiting) 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
Os usuários autorizados a usar uma chave KMS por meio de uma ResourceAliases condição [kms:](conditions-kms.md#conditions-kms-resource-aliases) receberão uma `AccessDenied` exceção se a chave KMS exceder os [aliases padrão por cota de chave KMS](resource-limits.md#aliases-per-key) 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. É provável que esse atraso seja maior do que o breve atraso eventual de consistência que afeta a maioria das AWS KMS operações.
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 [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html)operação seja concluída e a [ListResourceTags](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListResourceTags.html)resposta confirme que a tag está atribuída à chave KMS, os diretores podem não ter acesso à chave 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.
A [descriptografia](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) e as [ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)solicitações que especificam o [nome do alias ou](concepts.md#key-id-alias-name) o [ARN](concepts.md#key-id-alias-ARN) do alias podem falhar porque o alias agora está associado a uma chave 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.
Você pode rastrear a alteração examinando CloudTrail os registros de [CreateAlias[UpdateAlias](ct-updatealias.md)](ct-createalias.md), e as entradas de [DeleteAlias](ct-deletealias.md)registro. Você também pode usar o valor do `LastUpdatedDate` campo na [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html)resposta para detectar uma alteração.
Por exemplo, o [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html)exemplo de resposta a seguir mostra que o `ProjectAlpha_Test` alias na `kms:ResourceAliases` condição foi 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](alias-access.md#alias-access-limiting) para aliases que elas precisam gerenciar.