Gerenciamento de credenciais no ambiente de CI / CD

Question

Configuração: Eu tenho um aplicativo que implemente atualmente manualmente em um servidor. Ele requer várias credenciais (segredos de cliente de serviços externos, tokens e chaves AES e IVs etc.) que eu atualmente armazenei em um arquivo criptografado com gpg . Sempre que eu reinicio o aplicativo, destravo a tecla gpg no console e o serviço descriptografa o arquivo novamente a partir do script do aplicativo (como gpg-agent persiste a frase secreta na memória por um tempo limitado) e analisa-os por meio de tubo.

A vantagem deste método é que nem as credenciais nem a gpg -passphrase necessárias para acessá-los NUNCA são mantidas em disco e mantidas apenas na memória. Portanto, mesmo com acesso root completo, é impossível recuperar as credenciais. A única chance é obter acesso durante o curto período de tempo durante o qual a tecla gpg -key permanece desbloqueada.

As desvantagens são que (a) nenhum outro usuário pode iniciar o serviço (a menos que compartilhemos minha conta) e (b) o aplicativo não possa ser iniciado por nenhum meio automatizado.

Existe o projeto creds no github que é semelhante ao que estou fazendo, mas que ainda compartilha as deficiências acima. Pode ser possível criptografar o arquivo com várias chaves gpg e, em seguida, tentar descriptografá-lo com todas as chaves até que uma seja bem-sucedida.

Pergunta: Quais são as melhores formas de lidar com as credenciais que são (a) acessíveis por vários usuários sem compartilhamento de chaves ou contas, (b) acessíveis por um sistema de CI / CD (onde eu não tem um console toda vez que uma implantação acontece), e (c) mantém somente os dados da senha na memória? A "solução alternativa" com várias chaves gpg parece um hack complexo e não funciona com sistemas CI / CD.

    

Answer 1

Falarei sobre segredos em vez de credenciais, pois pode haver outras informações confidenciais que você gostaria de proteger. Não importa que a sua pergunta seja formulada especificamente para sistemas de CI / CD, o problema é o mesmo, quer estejamos falando sobre como usar certificados X.509 para autenticação, salvar credenciais de banco de dados ou proteger um token de acesso para um agente de compilação.

Não há uma maneira canônica de lidar com isso, pois as necessidades de aplicativos e organizações diferem no que constitui segredos e como lidar com eles. Alguns aplicativos não oferecem outra maneira de armazenar segredos do que em um arquivo.

Alguns aplicativos criptografam segredos no disco, mas como eles costumam ter uma simetria mais ou menos decorativa.

Então, o que você pode fazer?

• Sua primeira linha de defesa é o DAC (controle de acesso discricionário) e MAC (controle de acesso obrigatório) do seu sistema operacional - se estivermos falando Linux, permissões POSIX são DAC e LSMs como o App Armor, o SELinux ou o GRSecurity são MAC.

• Auditando o sistema operacional para os padrões adequados, como CIS ou DISA STIG .

• Usando um HSM ou OpenPGP smartcard para armazenar a chave PGP que você usa para criptografar os segredos nas molas do disco. Dispositivos como estes garantem que a chave nunca sai do hardware.

Tenha em mente que nenhuma medida individual mantém as chaves em um HSM seguro - o acesso físico ainda pode comprometê-las. Os dispositivos de armazenamento de chaves de hardware devem ser combinados com segurança física e procedimentos operacionais adequados para impor sua segurança.

Verifique as principais políticas de CA raiz do navegador ( Chrome , Firefox , Edge/IE ). Eles reforçam o uso de dispositivos de criptografia de hardware e várias restrições e regras sobre como operá-los e quais auditorias você precisa passar.

• Usando um software como o Vault para obter o segredo sob demanda, mas que precisa de suporte de aplicativo. Caso contrário, você está apenas armazenando-o no disco novamente. O que o Google Apps Vault pode adicionar à mistura é um TTL obrigatório para segredos e a capacidade de rotacioná-los por conta própria.