Armazenar segredos para scripts não supervisionados: systemd credentials, DPAPI, keychain do macOS — e o que não fazer

Objetivo

Entregar a um script ou serviço não supervisionado o segredo de que precisa em tempo de execução, sem expô-lo no ambiente de outros processos, na listagem de processos nem em um arquivo legível por todos.

Pré-requisitos

systemd 247+ para LoadCredential=, 250+ para systemd-creds e LoadCredentialEncrypted= (a criptografia usa uma chave derivada do TPM2, a chave do host /var/lib/systemd/credential.secret, ou ambas; portanto, um TPM não é estritamente necessário); PowerShell 5.1+ para Export-Clixml, ou o módulo Microsoft.PowerShell.SecretManagement para uma abstração mais completa de cofre de segredos; macOS com a ferramenta de linha de comando security (já incluída no sistema).

Passos

1. Linux/systemd: como root, execute systemd-creds encrypt --name=mysecret plaintext.txt /path/mysecret.cred, apague plaintext.txt e referencie o resultado na seção [Service] com LoadCredentialEncrypted=mysecret:/path/mysecret.cred. O nome embutido deve corresponder ao ID da credencial; sem --name=, ele é tirado do nome do arquivo de saída. O serviço lê o valor descriptografado em $CREDENTIALS_DIRECTORY/mysecret, uma cópia somente leitura acessível apenas ao serviço (funciona com DynamicUser=), em vez de uma variável de ambiente herdada por todos os processos filhos.
2. Windows: Get-Credential | Export-Clixml -Path secret.xml serializa um objeto de credencial. A documentação da Microsoft indica que isso se baseia na Windows Data Protection API (DPAPI); por isso, o arquivo gerado só pode ser descriptografado pela mesma conta de usuário, na mesma máquina em que foi criado. Copiá-lo para outro host ou usuário o torna inutilizável, então crie-o executando como a conta que fará a leitura. Isso vale apenas no Windows: o PowerShell no Linux/macOS grava a senha apenas codificada, não criptografada. Import-Clixml -Path secret.xml lê o arquivo de volta dentro do script. Para segredos nomeados, o Microsoft.PowerShell.SecretManagement precisa de uma extensão de cofre, como Microsoft.PowerShell.SecretStore, que por padrão pede uma senha, a menos que sua autenticação seja reconfigurada.
3. macOS: armazene o segredo uma vez com security add-generic-password -a "myservice" -s "myservice-token" -T /usr/bin/security -w; com -w por último e sem valor, o comando pede o segredo de forma interativa, mantendo-o fora do ps e do histórico do shell. Um script o recupera com security find-generic-password -a "myservice" -s "myservice-token" -w, que imprime apenas o valor. O keychain precisa estar desbloqueado, o que o keychain de login de um usuário muitas vezes não está em sessões SSH ou em LaunchDaemons, e uma ferramenta que não conste na lista de acesso do item (-T) provoca um prompt gráfico.
4. Nos três casos, restrinja o arquivo ou o repositório de credenciais à conta do próprio serviço (no Linux: use o diretório por serviço do LoadCredential= em vez de um caminho compartilhado; um arquivo criado manualmente deve, de todo modo, ter chmod 0600).

Resultado esperado

O segredo pode ser lido pela conta de serviço prevista em tempo de execução e por nenhuma outra conta; uma inspeção do tipo ps//proc/<pid>/environ no processo em execução não mostra nenhum segredo em texto simples, e encerrar e reiniciar o processo não exige digitá-lo novamente à mão.

Limites e base de verificação

Nenhum desses mecanismos impede que um processo com os mesmos privilégios do próprio serviço, ou um usuário que possa usar sudo/Run as Administrator, leia o texto simples depois de descriptografado. O que eles evitam é colocar o segredo em uma variável de ambiente (visível a todos os processos filhos e frequentemente registrada em logs), em um argumento de linha de comando (visível no ps/Gerenciador de Tarefas e no histórico do shell) ou em um arquivo comum com permissões padrão.