Gerenciamento de secrets com o Cloud KMS

Os aplicativos costumam exigir acesso a pequenos fragmentos de dados confidenciais no momento da criação ou da execução. Esses fragmentos de dados são frequentemente chamados de secrets. Elas se assemelham, em conceito, aos arquivos de configuração, mas geralmente são mais confidenciais, porque podem conceder acesso a outros dados, como dados de usuário.

Neste tópico, descrevemos alguns dos principais conceitos de gerenciamento de secrets. Apresentamos também orientações sobre como usar o Cloud Key Management Service para gerenciamento de secrets.

Visão geral do gerenciamento de secrets

Há várias opções para gerenciar secrets. Veja a seguir algumas maneiras comuns de armazená-los:

  • código ou binários
  • um gerenciador de implementação
  • um volume secreto em um contêiner
  • metadados de uma VM
  • um sistema de armazenamento

Para escolher entre essas opções, geralmente é preciso encontrar o equilíbrio entre segurança e funcionalidade. Veja a seguir algumas preocupações comuns de segurança:

  • Autorização: gerenciamento de acesso dos secrets ou do local em que eles estão armazenados, incluindo escopos de autorização rígidos.
  • Verificação de uso: a capacidade de auditar, em nível baixo de granularidade (por exemplo, por secret), o acesso e o uso de secrets.
  • Criptografia em repouso: criptografia de secrets em caso de roubo ou perda de dados.
  • Rotação: capacidade de fazer rotação ou atualização de secrets regularmente ou conforme necessário, em reação a um incidente.
  • Isolamento: separação entre o local em que os secrets são gerenciados e o local em que são usados. O isolamento também envolve a separação de deveres entre os usuários que podem gerenciar secrets e os que podem usá-los.

Veja a seguir algumas preocupações comuns de funcionalidade:

  • Consistência: sincronização de secrets entre vários locais e diversos aplicativos.
  • Gerenciamento de versões: compreensão de quando e como as chaves são atualizadas com o objetivo de possibilitar a rotação de secrets.

Como escolher uma solução de gerenciamento de secrets

A escolha da melhor solução de gerenciamento de secrets depende da combinação de ambiente, secrets e necessidades de segurança existentes. Veja a seguir algumas abordagens comuns:

  1. Armazenar secrets no código, criptografados com uma chave do Cloud KMS. Essa solução costuma ser implementada por meio da criptografia de secrets na camada do aplicativo. O uso dela ajuda a fornecer uma camada extra de proteção contra ameaças de pessoas com informações privilegiadas, o que é feito por meio da limitação do escopo de acesso ao secret. O acesso ao secret é vedado a todos os desenvolvedores com acesso ao código, exceto os que têm acesso ao código e à chave correspondente. A implementação dessa opção traz benefícios mesmo nos casos em que todos os desenvolvedores têm acesso ao código e à chave, já que permite fazer auditoria do acesso ao secret, o que talvez não seja possível em um repositório de código.

  2. Armazenar secrets em um intervalo de armazenamento no Cloud Storage, criptografados em repouso. Essa solução oferece benefícios semelhantes aos da solução anterior, porque limita o acesso aos secrets a um conjunto menor de desenvolvedores e permite a auditoria desse acesso. Além disso, ao armazenar os secrets em um local separado, é possível fazer a rotação deles com mais facilidade, quando necessário. Por exemplo, em caso de detecção de uma violação de segurança. Essa solução também permite a separação de sistemas. Se o repositório de código que usa os secrets for violado, os próprios secrets ainda poderão ser protegidos.

  3. Uso de uma solução de terceiros para gerenciamento de secrets. Uma ferramenta dedicada de gerenciamento de secrets tem como base as duas primeiras opções desta lista. Além de facilitarem a rotação de secrets, em alguns casos, essas ferramentas fazem isso para você ou simplificam a rotação normal.

Como alterar secrets

Outra consideração importante ao escolher uma solução de gerenciamento de secrets é a facilidade para alterá-los. Por exemplo, fixar um secret no código muitas vezes é uma solução tentadora, mas que faz a alteração de secrets ficar demorada e difícil.

Ao analisar uma solução de gerenciamento de secrets, considere os seguintes requisitos de design e o grau de relevância deles para o aplicativo:

  • Rotação de secrets. Convém fazer a rotação regular dos secrets, especialmente por questões de segurança. O ideal é armazenar várias versões de cada secrets e fazer com que o código faça o teste deles, um por vez. Ao armazenar muitas versões de um secret e fazer a rotação para secrets mais novos conforme necessário, você melhora a consistência com um sistema externo que talvez precise desse secret. Isso também permite reverter para secrets anteriores, quando necessário. A implementação dessa solução pode ser bem complicada, mas se você considerar essas necessidades com antecedência, poderá facilitar o gerenciamento dos secrets ao longo do tempo.
  • Armazenar secrets em cache local. Dependendo do local onde são armazenados os secrets relativos ao aplicativo, pode ser preciso armazená-los localmente. Desse modo, eles podem ser atualizados com frequência, como várias vezes por hora. A vantagem dessa solução é que, quanto maior for a frequência de atualização, mais rápida será a resposta a uma interrupção. A desvantagem disso é que, se o secret ficar mal configurado de alguma maneira, uma atualização mais rápida permitirá que esse erro se espalhe de modo mais acelerado por toda a frota.
  • Uso de uma solução ou plataforma separada. Quando se trata de gerenciamento de secrets, convém evitar o bloqueio usando uma solução de gerenciamento independente de plataforma. Desse modo, você terá opções caso seja disponibilizada uma solução mais flexível.

Gerenciamento de secrets com o Google Cloud Platform

O GCP oferece várias maneiras de ajudá-lo a implementar sua solução de gerenciamento de secrets com a abordagem que você quer. Nesta seção, descrevemos uma abordagem que usa o Cloud Storage para armazenamento de secrets, o Cloud KMS para chaves de criptografia, o Cloud Identity and Access Management para controle de acesso e o registro de auditoria do Cloud para auditoria.

Veja aqui uma maneira de implementar usando gerenciamento de secrets no GCP. Para mais informações, consulte Como armazenar secrets criptografados com o Cloud KMS.

  • Crie dois projetos. O primeiro projeto usa o Cloud Storage para armazenar secrets. O segundo usa o Cloud KMS para gerenciar chaves de criptografia.
  • Atribua os papéis storage.objectAdmin e cloudkms.cryptoKeyEncrypterDecrypter a qualquer usuário que precisa acessar secrets. Se preferir, use uma conta de serviço que acessa o Cloud Storage em nome de um usuário. Certifique-se de que os usuários sem necessidade de acesso a secrets tenham permissão de gerenciamento, mas não de acesso.
  • No Cloud Storage, armazene cada secret como um objeto criptografado e agrupe-os em intervalos, conforme necessário. Em geral, você poderá agrupar secrets se eles compartilharem as mesmas necessidades de uso, acesso e proteção.
  • Proteja cada intervalo usando uma chave exclusiva no Cloud KMS na camada do aplicativo. Outra opção é aplicar a criptografia padrão do Google.
  • Faça a rotação dos secrets regularmente, sempre que possível.
  • Monitore a atividade usando o Cloud Audit Logging. Por padrão, os registros de atividades administrativas, como rotação de chaves ou alterações de permissões do Cloud IAM, são gravados. Outra opção a se considerar é a ativação da geração de registros de acesso a dados nos objetos do Cloud Storage. Esses registros são úteis no monitoramento dos secrets que são particularmente críticos.

Essa solução atende à maioria dos requisitos de gerenciamento de secrets descritos em Como escolher uma solução de gerenciamento de secrets. Um item não abordado é o gerenciamento de versões. Isso porque a abordagem do gerenciamento de versões varia de acordo com o aplicativo.

Antes de implementar uma solução como essa, você também precisa considerar a opção de criptografia mais adequada às suas necessidades e como quer gerenciar o acesso de usuário aos secrets.

Opções de criptografia

No GCP, você tem duas opções para criptografar secrets:

  • Usar a criptografia de camada de aplicativo com uma chave no Cloud KMS. Com essa opção, você implementa a criptografia em objetos ou intervalos no Cloud Storage com a criptografia atual do Google, por meio de uma chave armazenada no Cloud KMS. Esta é a opção recomendada.

  • Usar a criptografia padrão integrada ao intervalo do Cloud Storage. O GCP criptografa o conteúdo do cliente armazenado em repouso, usando um ou mais mecanismos de criptografia. Como o próprio nome diz, essa criptografia está disponível por padrão e não requer nenhuma outra ação sua.

Para saber mais sobre essas e outras opções de criptografia, consulte Criptografia em repouso.

Criptografia de camada de aplicativo usando uma chave no Cloud KMS

A maneira recomendada de armazenar secrets é usar a criptografia de camada de aplicativo com uma chave no Cloud KMS. Esse método é especialmente útil quando você quer mais uma camada de controle ou tem um requisito de conformidade para gerenciar as próprias chaves.

Para implementar esse tipo de criptografia, envie os secrets ao Cloud KMS para serem criptografados por meio de uma solicitação Encrypt. O Cloud KMS retorna os secrets criptografados para que seja possível gravá-los no armazenamento.

O Cloud KMS pode gerenciar secrets de até 64 KiB. Se você precisa criptografar secrets maiores, é recomendável usar uma hierarquia de chaves, com uma chave de criptografia de dados (DEK, na sigla em inglês) gerada localmente para criptografar o secret, e uma chave de criptografia de chaves (KEK, na sigla em inglês) no Cloud KMS para criptografar a DEK. Para saber mais sobre as DEKs, consulte Criptografia de envelope.

Criptografia padrão

Se o uso da codificação de camada de aplicativo não é uma opção para o aplicativo, outra solução comum é usar a criptografia padrão do Cloud Storage. Essa opção é usada com frequência quando se busca principalmente uma solução em nuvem para proteger os secrets no armazenamento.

Essa criptografia é ativada automaticamente e não requer nenhum esforço extra de sua parte para ser implementada.

Como gerenciar o acesso a secrets

Há duas opções principais para restringir e aplicar o acesso:

  • Controles de acesso no intervalo em que o secret está armazenado. Essa opção aceita vários secrets (objetos) por intervalo, ou apenas um secret por intervalo. Essa é a opção recomendada.
  • Controles de acesso na chave que criptografa o intervalo em que o secret está armazenado. Essa opção aceita vários ou apenas um secret por chave.

A segregação de secrets somente é aconselhável quando ela melhora a segurança e a facilidade de uso. Uma prática recomendada comum é limitar o volume de dados protegido por qualquer chave de criptografia, para fins de isolamento criptográfico, ou protegido por qualquer lista de controle de acesso. Esse artifício permite que você tenha maior controle granular sobre o acesso aos secrets, ajuda a evitar permissões acidentais e aceita auditorias mais detalhadas. Ao agrupar secrets, faça isso quando fizer sentido em termos lógicos. Por exemplo, você pode agrupar alguns secrets para simplificar o controle, como quando um único aplicativo precisa acessar uma determinada coleção de secrets no ambiente de execução.

Ao decidir como armazenar os secrets, é recomendável seguir estas diretrizes:

  • Cada secret é o próprio objeto.
  • Os secrets ficam em um único intervalo, em que eles têm várias características em comum.
  • Uma única chave de criptografia é usada para criptografar cada intervalo, que inclui esses secrets agrupados logicamente.

Veja a seguir alguns cenários em que convém agrupar secrets:

  • O mesmo aplicativo requer acesso de secret.
  • Os mesmos administradores humanos gerenciam versões e acesso de secrets.
  • O mesmo ambiente, como produção, desenvolvimento ou teste.
  • O mesmo tempo de uso, como tempo de criação ou tempo de implementação.
  • O mesmo nível de proteção pretendido.

Rotação de chaves

É recomendável fazer a rotação das chaves regularmente para criptografar secrets. Essa prática ajuda a limitar o volume de dados criptografados com uma única chave e ajuda a limitar o ciclo de vida da chave, caso ela seja comprometida. Além da rotação automática das chaves, você também pode fazer a rotação de uma chave manualmente. Por exemplo, é possível fazer a rotação de uma chave manualmente quando o secret é atualizado para uma nova versão. Para saber mais, consulte Rotação de chave.

Rotação de secrets

Além de fazer a rotação de chaves, é possível fazer a rotação de secrets. Geralmente a rotação (ou atualização) de um secret ocorre quando uma nova versão é criada. Por exemplo, ao gerar uma nova senha para uma credencial de banco de dados. Convém também fazer a rotação de chave regularmente para limitar o ciclo de vida do secret.

Com a rotação, um secret fica com várias versões que você precisa gerenciar. Pode haver uma única versão de um secret que seja válida a qualquer momento ou várias. Pense em manter as versões antigas de um secret por algum tempo, porque elas poderão ser necessárias se o aplicativo for revertido a uma versão anterior.

Uma maneira de gerenciar várias versões de secrets é criar um objeto para cada versão e armazená-los no mesmo intervalo associado a esse secret específico. Em seguida, é possível adotar uma convenção de nomenclatura que será usada para rastrear qual versão está em uso. Além disso, é possível usar um conjunto central de variáveis para ajudá-lo a determinar qual secret precisa estar em uso a qualquer momento.

Gerenciamento de permissões usando o Cloud IAM

Como parte do gerenciamento de secrets no GCP, é recomendável usar o Cloud IAM. Com o Cloud IAM, é possível criar e gerenciar permissões para recursos do GCP. É possível também unificar o controle de acesso de serviços do GCP em um único sistema e apresentar um conjunto consistente de operações. Para saber mais sobre ele, consulte a documentação do Cloud IAM.

Um conceito essencial no gerenciamento de papéis e acesso é a separação de deveres. Convém evitar que apenas uma pessoa seja capaz de criptografar e descriptografar dados, bem como gerenciar ou criar novas chaves. Para mais informações, consulte Separação de deveres.

As duas maneiras de gerenciar permissões são:

  • Sem conta de serviço. Essa é a opção recomendada.
  • Com conta de serviço.

Gerenciamento de permissões sem conta de serviço

Para gerenciar secrets usando o Cloud KMS, a configuração ideal precisa minimizar o acesso desnecessário e impor a separação de deveres. Esse tipo de configuração requer vários usuários:

  • Um administrador no nível da organização. Este é um usuário com o papel resourcemanager.organizationAdmin. O administrador no nível da organização costuma ser o proprietário corporativo da conta. Em vez disso, se você usou o papel resourcemanager.projectCreator, esse usuário recebe o acesso de owner nos respectivos projetos. Esse nível de acesso geralmente não é necessário. Não é recomendado usar esse papel para gerenciamento de secrets.
  • Um segundo usuário que tem o papel storage.objectAdmin. Ele é responsável por gerenciar secrets. Esse usuário também usa uma conta de serviço que tem o papel storage.admin referente ao produto que contém o intervalo do Cloud Storage. Essa conta de serviço limita a capacidade desse usuário de editar os metadados ou de excluir o intervalo.
  • Um terceiro usuário com o papel cloudkms.admin. Ele gerencia as chaves usadas para criptografar secrets.
  • Um quarto usuário que tem os dois papéis storage.objectAdmin e cloudkms.cryptoKeyEncrypterDecrypter. Trata-se do usuário final que precisa acessar os secrets.

Gerenciamento de permissões com conta de serviço

Uma implementação alternativa requer que o usuário final somente tenha permissões no intervalo de armazenamento, e que o serviço de armazenamento use uma conta de serviço para acessar a chave em nome do usuário. Essa configuração é semelhante à descrita em Gerenciamento de permissões sem conta de serviço, com as seguintes alterações:

  • O usuário final que acessa os secrets tem o papel storage.objectAdmin.
  • Um quinto usuário, atribuído à conta de serviço do Cloud Storage, tem o papel cloudkms.cryptoKeyEncrypterDecrypter.

Essa configuração é ideal para uma situação em que nenhuma pessoa tem acesso de criptografia e descriptografia com chave, o que pode ser preferível em alguns casos. No entanto, permite que o Cloud Storage criptografe e descriptografe com a chave por sua própria autoridade.

Como fazer auditoria usando o Cloud Audit Logging

Uma consideração final ao gerenciar secrets no GCP é usar o registro de auditoria do Cloud. Esse serviço consiste em dois streams de registros, “atividade do administrador” e “acesso a dados”, que são gerados pelos serviços do GCP. Esses fluxos ajudam você a responder à pergunta “quem fez o quê, onde e quando?” nos projetos do GCP.

Os registros de “atividade do administrador” contêm entradas para chamadas de API ou ações administrativas que modificam a configuração ou os metadados de um serviço ou projeto. Esse registro fica sempre ativado e visível para todos os membros do projeto.

Os registros “Acesso a dados” contêm entradas de registro para chamadas de API que criam, modificam ou leem dados fornecidos pelo usuário gerenciados por um serviço, como os dados armazenados em um serviço de banco de dados. Os registros de acesso a dados só ficam visíveis para proprietários e usuários do projeto que tenham o papel “Leitor de registros particulares”.

Tanto no Cloud Storage como no Cloud KMS, os registros “Atividade do administrador” são ativados por padrão. Eles incluem ações como criar um novo intervalo ou fazer a rotação de uma chave. Os registros “Atividade do administrador” são ativados por padrão, não exigem nenhuma ação do usuário para isso.

Nem o Cloud Storage nem o Cloud KMS têm registros "Acesso a dados" ativados por padrão, visto que poderiam gerar um volume de dados significativo. Esses registros rastreiam ações que ocorrem com frequência, especialmente quando se implementa a solução descrita aqui. Exemplos dessas ações são: ler o intervalo ou criptografar/descriptografar com uma chave. Além disso, qualquer acesso de secret requer o uso do Cloud Storage e do Cloud KMS, de modo que as interações com secrets possam ser gravadas em um ou outro local (embora seja redundante gravar nos dois).

Se você usar a geração de registros, recomenda-se ativar os registros de "acesso a dados" nos objetos do Cloud Storage, e não nas chaves do Cloud KMS. Esses registros fornecem dados mais granulares e fáceis de auditar do que os de "acesso a dados" nas chaves do Cloud KMS. Também é possível ativar os registros de "acesso a dados" nos objetos do Cloud Storage para secrets particularmente críticos.