Políticas de Chave, Concessões e Condições

Criar uma chave é metade do trabalho; controlar quem pode usá-la é a outra metade. O KMS usa vários mecanismos de acesso em conjunto.

O mais importante é a política de chave, a política baseada em recurso anexada diretamente à chave.

Toda chave do KMS tem uma política de chave, que é a autoridade principal sobre o acesso.

• Ao contrário da maioria dos serviços, uma chave do KMS precisa ter uma política de chave.
• Se a política de chave não conceder acesso, as políticas do IAM, por si só, não poderão concedê-lo.

Isso faz da política de chave a guardiã do acesso.

O acesso a uma chave do KMS exige que a política de chave habilite o IAM; depois, o IAM e a política de chave atuam em conjunto.

A política de chave padrão inclui uma declaração que concede acesso aos principais do IAM da conta sujeito às respectivas políticas do IAM. Sem essa declaração, somente os principais nomeados diretamente na política de chave poderão usar a chave.

Uma concessão é uma forma flexível e temporária de delegar o uso de uma chave.

• Ela permite operações específicas a um principal, geralmente de forma programática.
• Os serviços da AWS usam concessões para acessar chaves em seu nome.

As concessões podem ser aposentadas ou revogadas quando não forem mais necessárias, sendo ideais para delegações de curta duração.

Escolha com base na vida útil e na granularidade:

• Use a política de chave e o IAM para acesso amplo e duradouro.
• Use concessões para permissões temporárias e granulares, geralmente criadas dinamicamente por serviços ou aplicativos.

As concessões evitam editar a política de chave para necessidades de curto prazo.

O KMS oferece suporte a poderosas chaves de condição nas políticas, como kms:ViaService.

ViaService restringe o uso da chave a solicitações feitas por meio de um serviço específico da AWS (por exemplo, somente por meio do S3). Assim, um principal só poderá descriptografar quando o S3 fizer a chamada, e não diretamente.

O contexto de criptografia é um conjunto de pares chave-valor transmitido com a criptografia/descriptografia e vinculado criptograficamente à operação.

• O mesmo contexto precisa ser fornecido para descriptografar.
• Ele aparece no CloudTrail para fins de auditoria.

As políticas podem exigir um contexto específico com a condição kms:EncryptionContext.

Para permitir que outra conta use uma chave, a política de chave precisa permitir o acesso dessa conta externa, e o principal externo também precisa de permissão do IAM.

Esse é o mesmo padrão bilateral das funções entre contas: a política do recurso (neste caso, a política de chave) e a política do IAM de quem faz a chamada precisam permitir a ação.

Aplique o princípio do privilégio mínimo às chaves:

• Separe os administradores de chaves (que gerenciam a chave) dos usuários de chaves (que criptografam/descriptografam).
• Evite kms:* para os usuários.
• Use ViaService e o contexto de criptografia para restringir o escopo.

Isso limita o impacto caso um principal seja comprometido.

Um erro clássico é editar uma política de chave e remover a declaração que habilita o IAM.

Sem ela, até mesmo os administradores da conta perdem o acesso e, como a política de chave é a guardiã do acesso, você pode ficar completamente impedido de acessar a chave. Mantenha sempre um principal administrativo no nível da conta na política de chave para evitar uma chave irrecuperável.

Combine o CloudTrail (cada chamada do KMS com seu contexto) e o IAM Access Analyzer (políticas de chave que concedem acesso externo) para auditar quem pode usar e quem realmente usa cada chave.

As revisões regulares identificam políticas de chave excessivamente amplas antes que se tornem um risco.

Reflita sobre o acesso ao KMS.

Você aprendeu como o acesso ao KMS é controlado.

• A política de chave é a principal guardiã do acesso e precisa habilitar o IAM para que ele possa ser usado.
• As concessões fornecem delegação temporária e granular.
• Condições como ViaService e o contexto de criptografia restringem o escopo.