Um plano prático de gestão de segredos para aplicações auto-hospedadas

Porque é que a gestão de segredos é um requisito operacional, e não apenas de segurança

Uma aplicação auto-hospedada raramente funciona com uma única credencial. Pode precisar de uma conta de base de dados, uma palavra-passe SMTP, tokens de API de terceiros, webhooks, material de assinatura e uma ou mais chaves de encriptação. Se estes valores não forem geridos, o trabalho de rotina torna-se arriscado: uma implementação é mais difícil de reproduzir, a saída de um membro da equipa deixa acessos pouco claros e uma suspeita de exposição pode transformar-se numa indisponibilidade urgente.

Um processo útil de gestão de segredos torna o trabalho autorizado previsível. A equipa sabe o que faz cada segredo, quem é o seu responsável, onde é fornecido, de que aplicação depende e como pode ser substituído. Isto é consistente com a ênfase do NIST CSF 2.0 em estabelecer, comunicar e fazer cumprir funções, responsabilidades e autoridades de cibersegurança.

A infraestrutura gerida pode reduzir a carga operacional em torno de uma aplicação, mas não resolve a governação de credenciais. Por exemplo, a Airbip implementa aplicações do catálogo como cargas de trabalho Docker nos seus servidores cloud e automatiza o encaminhamento e os certificados TLS através do Traefik e do Let's Encrypt. Os clientes continuam a ter de decidir quem pode criar, aprovar, consultar e rodar as credenciais da aplicação que ligam essas cargas de trabalho a bases de dados e serviços externos.

• Trate cada segredo de produção como uma dependência operacional com um responsável.
• Conceba procedimentos de substituição antes de um segredo ser urgente ou comprovadamente suspeito de exposição.
• Sempre que for prático, mantenha as responsabilidades de administração de infraestrutura separadas da aprovação de negócio de contas sensíveis de terceiros.

O que conta como segredo

Um segredo é uma informação cuja divulgação poderia permitir acesso não autorizado, personificação, desencriptação ou ação privilegiada. Uma chave secreta, por exemplo, é uma chave criptográfica que não é pública; a sua confidencialidade é fundamental para a sua finalidade.

Não limite o registo a valores literalmente designados PASSWORD. Uma cadeia de ligação pode conter um nome de utilizador e uma palavra-passe. Uma exportação de configuração pode conter um token de integração. Uma chave privada, um valor de assinatura de cookies, um segredo de cliente OAuth ou um código de recuperação pode ser mais relevante do que uma palavra-passe convencional.

Em contraste, a configuração comum normalmente não concede acesso se for divulgada. Exemplos podem incluir o URL público de uma aplicação, uma definição de funcionalidade não sensível, uma localização ou uma escolha de nível de registo. A classificação deve basear-se no que a divulgação permite, e não no nome de uma variável de ambiente.

• Nomes de utilizador e palavras-passe de bases de dados, incluindo credenciais incorporadas em cadeias de ligação.
• Tokens de API, segredos de webhook e segredos de cliente OAuth usados por integrações.
• Nomes de utilizador e palavras-passe SMTP usados para enviar e-mails da aplicação.
• Valores de assinatura de sessão, chaves privadas e outras chaves de assinatura.
• Chaves de encriptação, material de encriptação de chaves e códigos de recuperação.
• Palavras-passe de administrador e tokens de acesso para contas de aplicações, servidores ou serviços de terceiros.

Separe os segredos da configuração não sensível antes da implementação

Antes da implementação, crie duas listas: configuração que pode ser mantida na documentação normal de implementação e valores que precisam de tratamento restrito. Este pequeno passo evita uma falha comum, na qual um ficheiro .env conveniente se torna a fonte de verdade informal para tudo, incluindo credenciais de produção.

Para implementações baseadas em Docker, utilize um método de entrega de segredos separado quando a aplicação o suportar. O Docker aconselha a utilização de segredos em vez de variáveis de ambiente para valores sensíveis em implementações Compose. Os segredos do Compose são declarados no nível superior e depois concedidos explicitamente a serviços individuais; um serviço não pode aceder a um segredo declarado a menos que a sua própria definição inclua essa concessão.

Os segredos do Docker são montados como ficheiros, em vez de serem definidos diretamente como variáveis de ambiente, normalmente em /run/secrets. Esta abordagem pode restringir o serviço que recebe um valor. Não elimina a necessidade de proteger o anfitrião, a configuração de implementação ou as pessoas com acesso administrativo, e a aplicação tem de conseguir ler o segredo no formato fornecido.

Evite colocar credenciais de compilação em argumentos de compilação ou variáveis de ambiente do Docker. O Docker afirma que estes podem persistir na imagem final. Utilize montagens de segredos de compilação ou montagens SSH para credenciais necessárias apenas durante uma compilação. Exclua também ficheiros .env do contexto de compilação com .dockerignore quando possam conter segredos; caso contrário, podem ser incluídos numa camada da imagem.

• Classifique cada valor de implementação antes de o adicionar a um ficheiro Compose, tarefa de CI ou painel de administração.
• Conceda um segredo do Docker Compose apenas ao serviço que precisa dele.
• Consulte a documentação de configuração da aplicação para determinar se aceita um segredo a partir de um ficheiro, variável de ambiente ou outro mecanismo.
• Reveja Dockerfiles, contextos de compilação e histórico de imagens quando tenham sido usadas credenciais durante a compilação.

Mapeie todos os locais onde um segredo pode ser exposto

Um segredo está tão protegido quanto cada cópia dele. O ficheiro de implementação é apenas um local a inspecionar. Artefactos de compilação, o portátil de um programador, um pedido de suporte arquivado ou uma configuração exportada podem tornar-se discretamente cópias adicionais que sobrevivem à credencial prevista.

Crie um mapa de exposição para cada segredo de elevado valor. Registe tanto os locais intencionais, como um armazenamento de segredos restrito, como os possíveis locais acidentais, como o histórico da shell, capturas de ecrã ou relatórios de erro. O mapa é especialmente valioso durante a resposta a incidentes porque indica à equipa o que deve ser revisto após uma rotação.

Os registos merecem atenção explícita. O OWASP ASVS observa que credenciais e detalhes de pagamento podem ser proibidos nos registos, enquanto tokens de sessão podem precisar de hash ou mascaramento. Também exige um inventário dos ficheiros e serviços onde os registos são armazenados ou transmitidos. Trate os destinos de registos, rastreadores de erros e canais de suporte como parte do limite dos segredos.

• Repositórios de código-fonte, incluindo ficheiros .env submetidos, exemplos e commits históricos.
• Ficheiros Compose, variáveis de CI/CD, histórico da shell e saída da linha de comandos.
• Registos de contentores, registos de proxy reverso, relatórios de erro da aplicação e serviços externos de registos.
• Pedidos de suporte, mensagens de chat, e-mail, capturas de ecrã e saída de terminal copiada.
• Cópias de segurança, dumps de bases de dados, exportações de configuração e instantâneos de servidores antigos.
• Computadores de administradores, cofres de gestores de palavras-passe, sessões de navegador e suportes amovíveis.

Escolha um modelo de responsabilidade antes de conceder acesso

As equipas pequenas frequentemente concentram a responsabilidade numa única conta de administrador. Isso pode ser conveniente, mas dificulta a aprovação, a recuperação e o desligamento de colaboradores. Em vez disso, atribua funções nominativas para cada segredo relevante, mesmo quando uma pessoa acumula temporariamente mais de uma função.

Um modelo prático separa o responsável pela aplicação, o administrador de infraestrutura e o responsável pelo serviço de terceiros. O responsável pela aplicação decide se uma integração é necessária e aceita o seu risco de negócio. O administrador de infraestrutura fornece a configuração aprovada ao serviço em execução e mantém o acesso à implementação. O responsável pelo serviço de terceiros administra a conta externa que emitiu a credencial, como um fornecedor de e-mail ou plataforma de API.

As orientações do NIST apoiam a definição de funções e a restrição de contas privilegiadas a pessoas ou funções definidas. Sempre que possível, os administradores devem utilizar contas sem privilégios para o trabalho normal e reservar o acesso privilegiado para tarefas que o exijam.

• Responsável pela aplicação: aprova a finalidade, a utilização de dados e a necessidade de negócio.
• Administrador de infraestrutura: implementa valores aprovados e controla o acesso ao nível da plataforma.
• Responsável pelo serviço de terceiros: gere a conta do fornecedor externo, a relação de faturação e a emissão de credenciais.
• Revisor de segurança ou operações: confirma periodicamente o acesso, a expiração, o estado de rotação e a prontidão de recuperação.

Armazene e forneça segredos de forma segura

Escolha o processo mais simples que limite a divulgação de forma fiável e permita a recuperação. A melhor opção depende do tamanho da equipa, do número de aplicações, da rotatividade de colaboradores, dos requisitos de conformidade e da frequência com que as credenciais mudam. Um sistema de segredos maduro não é automaticamente o primeiro passo certo se a equipa não conseguir operá-lo de forma consistente.

Um armazenamento de segredos encriptado com acesso individual por utilizador é geralmente uma boa escolha quando várias pessoas precisam de acesso controlado a um inventário em crescimento. Uma configuração de implementação restrita é útil quando o mecanismo de implementação pode limitar quem pode ler ou alterar um valor. Um fluxo de introdução manual pode ser adequado para um pequeno número de alterações raras, desde que o processo registe quem introduziu o segredo, onde foi introduzido e como o valor é recuperado.

Evite tratar um documento partilhado em texto simples, um chat de equipa sem restrições ou um repositório como armazenamento principal de segredos de produção. Evite também assumir que um segredo Compose é um cofre completo: o Compose pode obter o conteúdo do segredo a partir de um ficheiro no anfitrião ou, no Docker Compose, de uma variável de ambiente do anfitrião. Esses locais de origem requerem os seus próprios controlos de acesso. Segredos Compose baseados no ambiente não são suportados por docker stack deploy.

• Utilize um armazenamento de segredos encriptado com contas individuais quando várias pessoas precisam de acesso ou a auditabilidade é importante.
• Utilize definições de implementação restritas quando apenas um pequeno grupo administrativo deve fornecer valores às cargas de trabalho.
• Utilize um fluxo manual documentado apenas para alterações de baixo volume com aprovação clara, transferência segura e passos de recuperação.
• Mantenha na documentação de implementação uma referência ao ID de registo do segredo, e não ao seu valor real.

Aplique o privilégio mínimo a bases de dados, serviços de e-mail, APIs e integrações

Privilégio mínimo significa dar aos utilizadores e processos apenas o acesso necessário para as tarefas atribuídas. O NIST também exige que os privilégios sejam revistos periodicamente e que o acesso desnecessário seja removido ou reatribuído. Aplique isto às credenciais, não apenas aos utilizadores humanos.

Para uma base de dados, prefira uma conta específica da aplicação em vez de uma conta de administrador partilhada. Para e-mail, utilize credenciais destinadas à função de envio da aplicação em vez da palavra-passe da caixa de correio de uma pessoa. Para APIs, escolha as permissões mais restritas disponíveis e separe as credenciais de desenvolvimento, teste e produção. Para integrações, identifique se o token pode ler dados, escrever dados, eliminar dados, administrar utilizadores ou criar mais credenciais.

Um teste útil é o raio de impacto: se este valor for exposto, o que pode efetivamente fazer um atacante? Um token com âmbito restrito associado a uma aplicação é mais fácil de revogar e menos prejudicial do que um token amplamente privilegiado reutilizado entre sistemas.

• Crie credenciais de base de dados separadas por aplicação e ambiente onde o serviço o permitir.
• Evite utilizar um superutilizador de base de dados ou uma credencial de administrador com permissões amplas para o acesso normal da aplicação.
• Utilize tokens de API separados para aplicações ou integrações distintas, em vez de reutilizar um token geral.
• Limite as permissões, os dados acessíveis e as capacidades administrativas à necessidade real da aplicação.
• Reveja as credenciais após alterações de função, fornecedor, integração ou arquitetura.

Crie um procedimento de rotação que evite integrações interrompidas

A rotação é uma substituição controlada, não simplesmente uma reposição de palavra-passe. Uma alteração não planeada pode interromper a ligação à base de dados, a entrega de e-mail, webhooks ou automatizações essenciais. A sequência mais segura é preparar uma substituição, atualizar o serviço consumidor, validá-la, revogar o valor antigo e documentar o resultado.

Comece com uma entrada de inventário que indique se são possíveis credenciais em paralelo. Alguns fornecedores permitem que um novo token coexista brevemente com o token antigo; isso facilita uma transição faseada. Quando não existe sobreposição, agende uma janela de manutenção, defina um caminho de reversão e certifique-se de que os responsáveis certos estão disponíveis.

Após a alteração, verifique a função real em vez de apenas confirmar que o serviço iniciou. Teste uma leitura e escrita na base de dados adequadas à aplicação, envie um e-mail controlado, faça uma chamada de API autorizada ou execute o fluxo de trabalho crítico. Em seguida, remova a credencial antiga e pesquise os locais de exposição conhecidos se a rotação tiver ocorrido após uma suspeita de fuga.

• 1. Inventário: identifique a credencial, o responsável, os consumidores, as dependências e os locais de exposição.
• 2. Substituir: gere ou obtenha um novo valor usando o processo aprovado pelo responsável do serviço de terceiros.
• 3. Atualizar: forneça a substituição apenas à aplicação autorizada ou ao caminho de implementação autorizado.
• 4. Validar: teste a integração ou função específica que depende da credencial.
• 5. Revogar: desative, elimine ou invalide de outra forma o valor anterior assim que for seguro.
• 6. Documentar: registe a data, o operador, o resultado da validação, a próxima data de revisão e qualquer exceção.