Segredos como chaves de criptografia e credenciais não devem ser verificados no controle de origem por alguns motivos. A primeira é, obviamente, que as chaves e credenciais de criptografia sempre devem ser necessárias, e o controle da fonte não é uma maneira confiável de proteger as informações da divulgação. A outra razão pela qual você não deseja esses segredos em seu controle de origem é geralmente porque os segredos são geralmente (mas nem sempre) específicos para um determinado atributo do ambiente em que o aplicativo será executado. (Por exemplo, adquirir uma chave privada para criar um digital assinatura necessária para uma autorização de serviço da web, o terminal específico desse serviço da web pode estar em execução em um ambiente de controle de qualidade que exige uma assinatura de controle de qualidade).
A maneira correta de tratar um ambiente (ou segredo global) é tratá-lo como qualquer outro atributo de configuração ambiental, com controles de segurança adicionais para uma boa medida. Um módulo de código bem projetado, independente e com versão deve ser idêntico entre os ambientes, de modo que o ambiente para o qual eles são implantados informe o aplicativo sobre seus atributos (por exemplo, detalhes de conexão com o banco de dados, credenciais, pontos de extremidade de serviços da Web, caminhos de arquivos, etc ...) os detalhes de configuração cruciais para o seu aplicativo são externalizados e se tornam parâmetros de configuração do seu ambiente.
Agora, para abordar alguns de seus argumentos:
Em geral, não estamos apenas movendo o problema?
Não existe segurança perfeita; no entanto, "mover" o problema para uma área em que medidas e controles adicionais possam ser colocados melhorará a dificuldade e reduzirá a probabilidade de divulgação acidental ou maliciosa de segredos. Uma boa regra a seguir ao projetar um sistema em que os dados confidenciais devem ser protegidos é sempre colocar os controles em dois. O que quero dizer com isso é garantir que, para uma divulgação acidental ou mal-intencionada de informações confidenciais ou incidentes de segurança, ocorra uma falha ou em dois ou mais controles.
Um bom exemplo disso pode ser o armazenamento de um arquivo criptografado em um servidor. Também tenho uma chave de descriptografia secreta que devo manter em sigilo em outro arquivo.
- Armazene a chave e o arquivo criptografado no mesmo servidor (0 controles, qualquer pessoa com acesso ao servidor pode adquirir trivialmente as informações confidenciais)
- Execute as etapas acima e proteja o acesso a ambos os arquivos, para que possam ser legíveis apenas pelo usuário do aplicativo em tempo de execução do sistema operacional (1 Controle, comprometendo a senha do usuário root ou o usuário em tempo de execução do aplicativo permitirá que um invasor adquira informações confidenciais)
- Armazene a chave no cofre de chaves externas, adquira a chave com várias medidas de segurança, como lista branca de endereços IP, autenticação de certificado e outras medidas no aplicativo que pode acessar o arquivo criptografado em seu sistema de arquivos. (Vários controles, várias falhas nos controles de segurança devem ocorrer para que dados confidenciais sejam comprometidos)
Novamente, não existe segurança perfeita, mas o objetivo de ter vários controles garante que várias falhas precisem ocorrer para que a divulgação ocorra.
Parece-me que produtos como o Azure KeyVault não são melhores e são desnecessariamente mais complicados,
Complicado, sim, inútil é completamente subjetivo. Não podemos discutir sobre a inutilidade de segurança adicional sem considerar realisticamente o quão sério seria para os dados confidenciais serem expostos. Se alguém pudesse usar os dados confidenciais para enviar transferências eletrônicas ilícitas para fora de sua instituição financeira, algo como um cofre de chaves é a coisa mais distante do que seria inútil.
do que manter seus segredos em um arquivo de configuração separado e garantir que ele esteja no seu .gitignore ou equivalente.
Até que alguém acidentalmente o verifique no controle de origem, agora o segredo está incorporado no histórico de controle de origem para sempre.
Obviamente, as pessoas provavelmente enviarão um e-mail com segurança para o outro ...
A segurança não é apenas uma questão técnica, é também uma questão de pessoas. Isso seria fora de tópico, no entanto, sinto que neste momento você está tentando se convencer de não fazer o necessário.
Existe uma maneira de gerenciar segredos que não apenas mudam o problema? Acredito que esta pergunta tenha uma única resposta claramente definida. Por analogia, se eu perguntasse como o HTTPS não apenas move o problema, a resposta seria que as chaves da CA são distribuídas com o seu sistema operacional e confiamos nelas porque confiamos no método de distribuição do sistema operacional.
A segurança nem sempre faz com que os problemas desapareçam, na maioria das vezes coloca controles em torno deles. Sua analogia é sucinta, porque é exatamente isso que a criptografia de chave pública-privada faz. Estamos "movendo o problema" para a CA, confiando de forma absoluta e completa em nossa CA para garantir a identidade da entidade proprietária do certificado público. Basicamente, nada menos que uma série de falhas catastróficas (por exemplo, perder a confiança na CA) teria que ocorrer para levar a um problema de segurança.
Como em muitas coisas, a segurança é uma linha que você deve traçar com base em critérios subjetivos, na natureza dos dados, nas consequências da divulgação, no apetite ao risco, no orçamento, etc.
