Objetivo:
Detalhar as principais características do serviço AWS KMS fazer um teste simples de utilização de chaves.
Overview
Recomendo a leitura prévia do seguinte post: https://arquitetocloud.com.br/aws-kma-principios-de-criptografia/
O KMS é uma solução simples da AWS que gerencia chaves de encriptação.
Sempre que se ouve falar em “encryption” na AWS, provavelmente o KMS estará envolvido. Por exemplo, o KMS é utilizado com EBS para encriptar volumes, além do S3 e RDS utilizarem para encriptação dos dados armazenados, assim como o SSM utiliza para os dados do Parameter Store.
Além dos serviços AWS utilizarem o KMS de forma automática e transparente, também é comum o uso do KMS pelos usuários através do CLI e SDK.
O KMS está completamente integrado com o IAM que por sua vez concede autorização de uso e gerenciamento das chaves de forma simples e centralizada.
CMK - Customer Master Key
Customer Master Keys são os fundamentos do KMS, isto é, são as chaves que o KMS gerencia. CMKs podem ser:
- Simétrica – São chaves de encriptação que utilizam AES-256 e usam uma única chave para encriptar e desencriptar dados. A maioria dos serviços integrados com KMS utilizam chaves simétricas por debaixo dos panos. Com chaves simétricas os clientes nunca têm acesso as chaves desencriptografadas que são utilizadas pelo KMS, isto é, é preciso utilizar APIs com acesso gerenciado pelo IAM para usar as chaves, mas sem conhecer quais são estas chaves.
- Assimétrica – São chaves que utilizam RSA e ECC key pairs. As chaves públicas são conhecidas, mas as chaves privadas não são. Um caso de uso para chaves assimétricas é quando dados precisam ser encriptados fora da AWS, mas não é possível utilizar chamadas de API para o KMS, assim, a chave pública poderia ser utilizada para encriptar os dados antes de enviar para serviços AWS e dentro da AWS os serviços utilizariam a chave privada para descriptografar.
Temos 3 tipos de CMKs (Keys do KMS):
- AWS Managed Service Default – chaves usadas pelos serviços AWS para encriptação de dados de forma transparente.
- Chaves criadas pelos usuários – Tem custo associado para a criação das chaves, assim como, custos para usar destas chaves.
- Chaves importadas – São chaves geradas fora da AWS, mas que podem ser gerenciadas pelo KMS. Estas chaves tem custos associados e não são recomendadas.
AWS KMS features
Com o KMS é possível gerenciar o uso de Keys e policies, por exemplo, criar Keys, definir políticas de rotação de chaves e desabilitar e habilitar chaves.
Pode-se integrar o KMS com o CloudTrail para rastrear o uso das Keys.
Os casos de uso mais comuns para o KMS são:
- Senhas de bancos de dados
- Credenciais para serviços externos
- Private Key de certificados SSL
O real valor do serviço KMS é que as CMKs, usadas para encriptar dados, nunca podem ser visualizadas pelos usuários e podem ser rotacionadas anualmente para garantir segurança extra.
Sempre considere que senhas ou secrets nunca devem ser armazenadas como plaintext, especialmente dentro de códigos de aplicações. Ao invés disto, as senhas deveriam ser armazenadas em variáveis de ambiente depois de encriptadas pelo KMS.
O limite do KMS é de até 4 KB de dados por chamada. Quando é necessário encriptar mais de 4 KB utiliza-se o procedimento conhecido como Envelope Encryption que pode ser entendido em mais detalhes neste post.
Para dar acesso ao KMS para uso e gerenciamento das chaves é preciso:
- Garantir que o usuário tenha permissão no KMS através de Resource Policy. Este tipo de Policy é semelhante a uma Policy aplicada a um bucket ou qualquer outro recurso ou serviço, a diferença é no caso do KMS ela é obrigatória, isto é, precisa existir uma Key Policy que permita acesso ao KMS. Por padrão, uma Key Policy é criada se nenhuma outra Policy for fornecida e esta Policy permite acesso completo ao usuário root o que significa que todos os usuários de uma conta AWS podem ter acesso a uma chave do KMS se houver uma IAM Policy que também permita acessos dos usuários. É possível definir uma Key Policy customizada que defina usuários ou roles que podem ter acesso ao uma Key do KMS ou que permita acesso de administrar as Keys. Uma Key Policy também pode ser útil na definição de permissões cross-account, desta forma, uma outra conta pode fazer cópias de snapshots usando as chaves utilizadas na encriptação do snapshot.
- Garantir que exista uma IAM Policy que permita chamadas de API do KMS. Este tipo de Policy e associada a usuários ou Roles que precisam ter acesso as chaves do KMS. Juntamente com as Key Policies, as IAM Policies garantem que um determinado usuário possa ter acesso de utilização e/ou administração sobre as chaves.
Chaves KMS geradas em uma região não podem ser utilizadas em outra região. Por exemplo, se um volume EBS é encriptado em uma região com uma chave KeyA qualquer snapshot deste volume será encriptado com a mesma KeyA. Se for necessário copiar este snapshot para outra região ele precisa ser encriptado com uma KeyB na outra região e só então, a partir do snapshot copiado, pode ser restaurado um novo volume EBS encriptado com a KeyB.
AWS Managed Keys
As Managed Keys são criadas automaticamente pelos serviços AWS e têm um alias iniciado por AWS/, por exemplo, uma Key utilizada pelo S3 para encriptar dados em um bucket teria o alias iniciado por “aws/s3…”. Os aliases são atribuídos automaticamente pelos serviços que utilizam encriptação e este tipo de Key não tem custo envolvido. Também não é possível utilizar este tipo de chave fora do serviço para qual ela foi criada e não é permitido excluí-las ou fazer rotação destas chaves.
Customer Managed Keys
Este tipo de chave é criada pelos usuários e tem o custo de US$ 1 por mês, além dos custos de utilização da chave, que geralmente são alguns centavos a cada 10.000 solicitações.
Uma Managed Key pode ser simétrica ou assimétrica. Elas podem ter como origem (Key Material Origin) o próprio KMS, isto é, o serviço do KMS irá gerar a chave ou também é possível fornecer uma Key gerada externamente e pedir que o KMS faça o gerenciamento e controle de acesso sobre ela.
Durante a criação de uma Managed Key é possível definir as permissões de administração e utilização das chaves, inclusive definindo acessos cross-account.
As ações possíveis sobre uma Managed Key são desabilitar uma Key, rotacionar uma Key ou agendar sua exclusão.
LAB
Neste lab será utilizada uma key simétrica criada para teste chamada encriptdocker. O AWS CLI está instalado e configurado com um perfil que permite acesso às chaves no KMS. O CMD do Windows será utilizado para executar os comandos.
Depois de instalar e configurar o AWS CLI podemos executar os seguintes comandos para encriptar e desencriptar uma senha.
# Encriptação
echo senhafakenaocriptada > exemploarquivodesenha.txt
more exemploarquivodesenha.txt
aws kms encrypt --key-id alias/encriptdocker --plaintext fileb://exemploarquivodesenha.txt --output text --query CiphertextBlob --region sa-east-1 > .\exemploarquivodesenhaencriptado.base64
more exemploarquivodesenhaencriptado.base64
certutil -decode .\exemploarquivodesenhaencriptado.base64 .\exemploarquivodesenhaencriptado.bin
more exemploarquivodesenhaencriptado.bin
# Desencriptação
aws kms decrypt --ciphertext-blob fileb://exemploarquivodesenhaencriptado.bin --output text --query Plaintext --region sa-east-1 > exemploarquivodesencriptado.base64
more exemploarquivodesencriptado.base64
certutil -decode .\exemploarquivodesencriptado.base64 .\exemploarquivodesencriptado.txt
more exemploarquivodesencriptado.txt
A seguir estão descritos os passos utilizados para encriptar e desencriptar o conteúdo de um arquivo que contém uma senha.
- Primeiro é gerado um arquivo texto que contém uma senha. Esta senha é o queremos encriptar.
- É usado o comando AWS KMS ENCRYPT para encriptar a senha. Na chamada do comando são passados o alias da chave KMS (encriptdocker) e o arquivo que contém a senha que será encriptada.
- Como a saída do comando é um arquivo codificado em Base64, foi utilizado o CERTUTIL para decodificar o hash e obter o dado original, isto é, um binário.
- O binário é a senha criptografada e o comando AWS KMS DECRYPT é usado para desencriptar a senha. É importante observar que este comando não tem indicação de qual alias (chave KMS) utilizar. Isto porque o binário gerado pelo comando de encriptação já contém em seus metadados a informação de qual foi a chave utilizada durante o encrypt. Isto permite que um dado encriptado pelo KMS seja desencriptado mesmo que o usuário não lembre qual foi a chave (alias) utilizada na encriptação, apesar de ser considerada boa prática sempre indicar a chave com o comando AWS KMS DECRYPT.
- A saída do comando é um outro Base64 que precisa ser decodificado com o CERTUTIL para mostrar o dado original, isto é, a senha no formato texto.
Neste post foi possível descrever as principais caraterísticas do KMS e executar um laboratório simples de encriptação de senha.
It’s done!
