Como proteger e gerenciar segredos usando o Google Cloud KMS

Ramesh Lingappa Blocked Unblock Seguir Seguindo 7 de janeiro Segredos + Google KMS + Git

Vamos pular para a direita. Todos nós sabemos que é uma má idéia armazenar os segredos do aplicativo dentro do nosso código. Então, por que estamos armazenando lá ainda? Vamos dar um exemplo.

Poderíamos armazenar esses segredos em um arquivo e adicioná-lo ao gitignore para que ele não seja adicionado ao controle de versão. Mas há alguns obstáculos:

  • Como gerenciamos esses segredos?
  • O que acontece quando a cópia local é excluída?
  • Como podemos compartilhá-lo com outros desenvolvedores?
  • Como gerenciamos o controle de versão desses segredos durante as alterações e um registro de auditoria de quem mudou o quê?

Muitas perguntas! Então acabamos armazenando dentro do código, já que é muita complexidade para lidar.

Para um grande aplicativo ou aplicativo que precisa de um nível mais alto de segurança, podemos usar serviços de gerenciamento secreto de nível de produção como o Hashicorp Vault .

Neste artigo, veremos uma abordagem decente ao lidar com os segredos e, ao mesmo tempo, alcançar uma melhor segurança. Vamos conseguir isso usando a automação do Google KMS + Git + IAM +.

A ideia não é nova. Isso é o que vamos fazer:

  • Vamos armazenar a versão criptografada de texto sem formatação no controle de versão usando o Google KMS
  • Usaremos o KMS IAM para permitir que usuários apropriados gerenciem segredos para cada ambiente, concedendo funções de criptografia / descriptografia
  • Vamos implantar o aplicativo com arquivos secretos criptografados
  • Permitiremos permissão para o servidor descriptografar segredos para cada ambiente
  • No tempo de execução, carregaremos arquivos criptografados, descriptografá-los usando APIs do KMS e usá-lo.

O Cloud KMS é um serviço de gerenciamento de chaves hospedado na nuvem que permite gerenciar chaves criptográficas para seus serviços em nuvem. Você pode gerar, usar, girar e destruir chaves criptográficas. O Cloud KMS é integrado ao Cloud IAM e ao Cloud Audit Logging para que você possa gerenciar permissões em chaves individuais e monitorar como elas são usadas.

Então, o Cloud KMS irá criptografar e descriptografar nossos segredos para que não tenhamos que armazenar as chaves. Somente um usuário autorizado ou uma conta de serviço pode executar operações de criptografia ou descriptografia.

Vamos começar!

Passo 1: Preparando Segredos

Para nosso caso de uso, teremos segredos de aplicativos para cada ambiente, stag prod e dev . Fazemos isso criando uma nova pasta chamada credentials na pasta do projeto raiz e, em seguida, criamos uma pasta para cada ambiente.

credenciais por cada ambiente

Certifique-se de que esta pasta não seja rastreada sob o controle de versão, adicionando a seguinte linha no arquivo .gitignore :

 /credenciais/ 

Aqui estou usando um arquivo de propriedades , mas poderia ser qualquer coisa como JSON, YAML etc. Agora você pode adicionar qualquer informação sensível nesses arquivos. Eu adicionei o seguinte:

 # credenciais dev 
oauth_client_id = 1234
oauth_client_secret
= abcd
api_key = api_123
# ...

Ok, nossos segredos estão prontos para se esconder.

Etapa 2: Criando chaves secretas do KMS

Precisamos criar chaves de criptografia para cada ambiente para usar este serviço. Para nós, cada ambiente será um projeto diferente do Google Cloud (recomendado). É melhor assim, pois dá isolamento e controle de acesso (mais sobre isso depois).

Então, vá em frente e crie uma chave para cada ambiente usando este link Creating Symmetric Keys (recommended) . Ele tem instruções passo a passo (maneiras diferentes) para criar essas chaves. Estamos criando essas chaves usando a linha de comando como abaixo:

 // create key-ring (think of this as grouping) 
gcloud kms keyrings create [KEYRING_NAME]
--location [LOCATION]
--project live-project-id
 // cria a chave de criptografia 
gcloud kms keys create [KEY_NAME]
--location [LOCATION]
--keyring [KEYRING_NAME]
--purpose encryption
--project live-project-id

Aqui estou criando uma chave para produção usando o id do projeto de produção. Repita esse processo para cada ambiente, substituindo o ID do projeto por veado e outros ambientes .

Nota: Você precisa ter quatro peças de informação para cada tecla: location keyring cryptokey e project . Esta informação não é sensível para que você possa armazená-la em seu código ou criar scripts

Passo 3: Atribuindo permissão para usar essas chaves

Aí vem a beleza do sistema KMS IAM: para usar cada chave, precisamos conceder acesso explicitamente a um usuário individual ou a uma conta de serviço. Isso faz com que seja muito poderoso, pois agora podemos definir quem pode gerenciar segredos, quem pode ver esses segredos e muito mais.

Confira Usando o IAM com o Cloud KMS para mais informações. Com isso, podemos conseguir o seguinte:

Ambiente de produção:

Ninguém deve ser capaz de ver os segredos, exceto as poucas pessoas que podem fazer alterações nos segredos. Podemos fazer isso concedendo-lhes o papel:

 cloudkms.cryptoKeyEncrypterDecrypter 

Assim, dessa forma, mesmo que as credenciais criptografadas sejam armazenadas no controle de versão, outros desenvolvedores não poderão usá-las. Note que mesmo esses desenvolvedores podem fazer implementações ao vivo sem precisar conhecer os segredos (mais sobre isso mais tarde).

Ambiente de preparação:

Todo desenvolvedor pode ver os segredos e usá-los no desenvolvimento, mas apenas algumas pessoas podem fazer alterações nos segredos. Podemos fazer isso concedendo-lhes o papel:

 // for read only 
cloudkms.cryptoKeyDecrypter
 // for managing 
cloudkms.cryptoKeyEncrypterDecrypter

Da mesma forma, você pode conceder papéis-chave para diferentes ambientes, dependendo da necessidade. Para os comandos exatos, consulte Conceder permissão nos documentos.

Passo 4: Criptografando Segredos

Nós terminamos o trabalho de preparação e agora é hora de esconder alguns segredos. Supondo que você tenha a função de criptografia , com isso você pode criptografar um arquivo usando o seguinte comando:

 gcloud kms encrypt --location global  
--keyring secrets-key-ring --key quickstart
--plaintext-file credentials/stag/credentials.properties
--ciphertext-file credentials-encrypted/stag/credentials.properties.encrypted

Como é um comando shell gcloud, você pode integrá-lo facilmente a qualquer sistema de compilação para criptografar todos os arquivos na pasta de credenciais . Por exemplo, estou usando gradle para isso:

Basicamente, existem duas funções auxiliares:

  • kmsEncryptSecrets pega a pasta src para criptografar cada arquivo dentro dela e gravá-la na pasta de destino com extensão .enc (criptografada), e
  • kmsDecryptSecrets que faz o processo inverso.

Então, cada vez que modificamos segredos, você pode chamar o método de criptografia com uma tarefa simples:

Agora a pasta criptografada ficará como abaixo:

arquivos de credenciais criptografadas

Essa pasta pode ser adicionada ao controle de versão para que, sempre que um usuário autorizado alterar segredos, um novo arquivo criptografado seja gerado e registre o histórico no controle de versão.

Da mesma forma, há uma tarefa Decrypt para o processo inverso.

Passo 4: Usando Segredos Criptografados na Implementação

Agora que terminamos de criptografar os segredos e gerenciá-los adequadamente no controle de versão, vamos ver como ele pode ser usado no tempo de execução, ou seja, quando o aplicativo está realmente em execução na preparação ou na produção. Podemos fazer isso de duas maneiras:

1. Descriptografando segredos e passando durante a implantação:

Assim, durante a implantação, um usuário autorizado pode simplesmente descriptografar esses segredos criptografados e adicioná-los à implantação (por exemplo: diretório de compilação), tornando-os disponíveis para o código em tempo de execução. Nós não vamos cobrir isso profundamente.

Essa abordagem é boa quando o implantador precisa ser muito restritivo ou o processo é automatizado usando o pipeline de CD.

2. Passando segredos criptografados durante a implantação e decodificando no tempo de execução:

Aqui não vamos descriptografar nem enviar segredos brutos durante a implantação. Em vez disso, estamos simplesmente passando segredos criptografados. E durante a execução, descriptografaremos esses segredos e os usaremos.

Observação: isso funciona melhor no Google Cloud Platform. Caso contrário, você precisará gerar uma conta de serviço para poder usar essa abordagem com provedores externos.

Essa abordagem é ainda mais segura, pois não dependemos de nenhuma ação intermediária do usuário ou pipeline, mas apenas em servidores autorizados que podem descriptografar o conteúdo em tempo de execução.

Por exemplo, podemos permitir ao servidor de temporariedade (conta de serviço) a capacidade de descriptografar segredos de preparação e não a capacidade de descriptografar segredos de produção.

Com essa abordagem, até mesmo qualquer desenvolvedor que não tenha acesso à descriptografia de segredos de produção pode executar a implantação de produção e tudo ainda funciona bem.

Etapa 5: Usando segredos em tempo de execução

Vamos usar a segunda abordagem (passando segredos criptografados).

Para a demonstração, vamos supor que vamos implantar para o AppEngine, pois ele já tem uma conta de serviço padrão gerada. Nós concederemos a ele o acesso para decifrar os segredos como abaixo:

 gcloud chaves kms add-iam-policy-binding segredos-chave-chave  
--projeto kms-demo
--localização global
- chave de anel de segredo segredos
--membro
serviceAccount: kms-demo@appspot.gserviceaccount.com
--projeto kms-demo
-
funções de papel / cloudkms.cryptoKeyDecrypter

Assim, quando o servidor é iniciado, podemos simplesmente carregar o arquivo criptografado e usar as bibliotecas do cliente KMS para descriptografar seu conteúdo.

Etapa 6: registros de auditoria do KMS

Por fim, você pode ver os logs de auditoria para operações em cada chave ativando o log de auditoria do KMS (não ativado por padrão). Assim, podemos agora acompanhar todas as operações realizadas para auditoria futura.

Você pode ativar o registro de auditoria usando gcloud, mas já vimos o suficiente da linha de comando. Como alternativa, podemos ativar essa configuração usando a interface do usuário do Cloud Console. No menu à esquerda, escolha IAM e admin -> Registros de auditoria.

Clique em Cloud Key Management Service e ative Data Read e Data Write e clique em Salvar.

Console de registro de auditoria do Google IAM

É isso aí! Agora, se qualquer criptografia, decodificação ou qualquer outro tipo de operação for executada, um log de auditoria será gerado e você poderá verificar isso na seção Logging, em Cloud KMS CryptoKey.

Logs de auditoria para operações do IAM

Como você pode ver, ele possui logs de auditoria para todos os tipos de operações, incluindo falhas como permissões inválidas ou solicitações, etc. Ele mostra qual usuário executou a operação usando qual chave (ou se foi feita em uma conta de serviço). Essa é uma solução bem legal. Para mais informações, leia Uso do log de auditoria na nuvem com o Cloud KMS .

Conclusão

Com essa abordagem, podemos armazenar, gerenciar e usar segredos de aplicativos ou qualquer informação confidencial de forma segura e também acompanhar as alterações usando o controle de versão. As técnicas discutidas neste artigo podem ser usadas com qualquer linguagem, e podem ser usadas total ou parcialmente em outras plataformas, bem como iOS, Android, servidores externos etc.

Para obter uma lista de comandos kms, consulte Comandos KMS . Além disso, confira o aplicativo de amostra para o código completo:

ramesh-dev / gae-dynamic-config-demo
Demonstração da Configuração Dinâmica do AppEngine. Contribua para o desenvolvimento do ramesh-dev / gae-dynamic-config-demo criando… github.com

Aqui estão alguns links de referência:

Texto original em inglês.