Como impedir que os segredos do Jellyfin sejam expostos em ficheiros Compose ou cópias de segurança
Não trate um ficheiro Compose, um repositório Git e um arquivo de cópia de segurança como locais equivalentes para armazenar credenciais do Jellyfin. A receita de implementação pode ser amplamente copiada; os valores secretos devem ter um ciclo de vida, um limite de acesso e um percurso de recuperação mais restritos.
Numa stack Jellyfin, os dados sensíveis podem incluir chaves de API, credenciais de proxy inverso ou túnel, tokens de fornecedores de DNS, palavras-passe de repositórios de cópias de segurança, chaves de encriptação, credenciais de bases de dados de serviços de suporte e outros tokens utilizados por plugins ou automatização. Faça primeiro o inventário e, em seguida, decida quais têm de ser reproduzíveis, quais têm de ser recuperáveis e quais podem simplesmente ser emitidos novamente.
Separe as Referências aos Segredos dos Valores dos Segredos
Mantenha o Compose declarativo: as imagens dos serviços, redes, montagens, portas, nomes de variáveis e referências a segredos pertencem ao ficheiro; as credenciais em bruto, não. Um marcador como BACKUP_PASSWORD documenta o requisito sem transformar o ficheiro Compose no armazenamento de credenciais.
Os ficheiros de ambiente em texto simples são convenientes, mas podem ser facilmente copiados para o controlo de versões, pacotes de diagnóstico ou cópias de segurança não encriptadas. Um guia atualizado sobre gestão de segredos do Docker distingue a fuga de dados durante a compilação da imagem, a proliferação de ficheiros .env locais e a exposição do ambiente em tempo de execução, que são vias diferentes para a mesma fuga de credenciais.
Utilize um gestor de segredos, o mecanismo de ficheiros de segredos suportado pelo Compose ou outro método de injeção em tempo de execução adequado ao serviço dependente. Não presuma que todas as definições do Jellyfin suportam a convenção _FILE; utilize injeção baseada em ficheiros apenas quando o componente específico a suportar.
Impeça que os Segredos Entrem em Imagens, Repositórios e no Histórico da Shell
Exclua os ficheiros de segredos locais tanto do controlo de versões como do contexto de compilação do Docker. O facto de um ficheiro estar listado no .gitignore não impede que uma instrução ampla COPY no Dockerfile o coloque numa imagem, se o .dockerignore continuar a permitir a sua inclusão.
Não passe credenciais de longa duração diretamente numa linha de comandos que ficará armazenada no histórico da shell. Não mostre segredos durante a depuração do arranque. Evite imprimir o ambiente resolvido em pedidos de suporte ou chats partilhados quando uma única variável for suficiente para diagnosticar o problema.
Após uma suspeita de fuga, eliminar a linha do ficheiro Compose mais recente não constitui uma correção. Rode a credencial exposta, invalide os tokens antigos quando possível, inspecione o histórico do repositório e das imagens e remova o valor divulgado de futuras cópias de segurança e diagnósticos.
Conceba as Cópias de Segurança para que os Segredos Necessários Sejam Recuperáveis, mas Não Facilmente Legíveis
Alguns segredos fazem parte da recuperação. Uma cópia de segurança encriptada é inútil se a palavra-passe do repositório ou a chave de desencriptação desaparecer com o mesmo servidor, e uma stack restaurada de proxy ou automatização pode precisar de credenciais que não podem ser reconstruídas apenas a partir da receita Compose.
Um inventário prático de recuperação para alojamento próprio trata as chaves, tokens, códigos de recuperação e palavras-passe das cópias de segurança como materiais essenciais de recuperação, mantendo as chaves que desbloqueiam as cópias de segurança fora do servidor que está a ser salvaguardado. Isto é diferente de colocar um ficheiro .env em texto simples em todos os arquivos.
Crie um manifesto de recuperação de segredos que identifique cada credencial necessária, o respetivo responsável, o local onde se encontra a cópia principal, a forma como é restaurada ou emitida novamente e qual a cópia de segurança que desbloqueia. Armazene os valores sensíveis num gestor de palavras-passe encriptado, num conjunto de cópias de segurança encriptado ou num pacote de recuperação protegido separado, com controlos de acesso adequados ao agregado familiar.
Impeça que os Registos e os Pacotes de Diagnóstico se Tornem um Segundo Armazenamento de Segredos
Os URLs dos pedidos do proxy, os despejos do ambiente, a saída de depuração da aplicação e as transcrições da shell podem expor tokens mesmo quando o Compose está limpo. Antes de partilhar registos, procure cabeçalhos de autorização, chaves de API, tokens em cadeias de consulta, cookies, nomes de anfitrião privados e credenciais.
As orientações de registo recomendam redigir os campos sensíveis antes de a telemetria sair do sistema. Aplique a mesma regra aos pacotes de suporte de servidores domésticos: mantenha o original localmente, se necessário para o diagnóstico, mas partilhe uma cópia redigida.
Restrinja separadamente os leitores de cópias de segurança e de registos. Uma pessoa que pode ler cópias de segurança de multimédia não precisa automaticamente de acesso a tokens de DNS ou a credenciais de proxy inverso. A exposição de segredos é tanto um problema de âmbito de acesso como de formato de ficheiro.
Execute em Conjunto um Teste de Fuga e um Teste de Recuperação
Crie um segredo-canário com um valor falso reconhecível, implemente a stack e procure esse valor no diretório do Compose, no histórico das imagens, na saída de inspeção dos contentores, nos registos, no catálogo de cópias de segurança e numa restauração de teste extraída. Isto revela onde o fluxo de trabalho atual copia segredos sem colocar uma credencial real em risco.
Em seguida, execute o teste inverso: restaure a stack Jellyfin num destino isolado utilizando apenas os materiais de recuperação documentados. Se a recuperação depender de uma credencial que exista apenas no anfitrião avariado, o desenho tem segredos insuficientes; se todas as cópias de segurança comuns expuserem todas as credenciais em texto simples, tem segredos em excesso.
O limite do princípio do menor privilégio da ZimaSpace é a verificação final: cada serviço, tarefa de cópia de segurança, administrador e processo de recuperação deve receber apenas os segredos necessários para a sua função. Rode tudo o que ultrapasse inesperadamente esse limite.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Jellyfin deve utilizar uma conta partilhada ou contas separadas para cada membro do agregado familiar?
Escolha contas domésticas do Jellyfin com base nos limites de identidade, acesso, controlo parental e recuperação de que necessita.
Porque é que a utilização de memória do Jellyfin se mantém elevada depois de concluído o trabalho?
Separe o crescimento do processo Jellyfin da cache do Linux e investigue apenas quando a memória continuar a aumentar ou criar pressão real.
Sinais de que uma configuração de armazenamento do Jellyfin está a tornar-se um risco de recuperação
Audite as funções de armazenamento do Jellyfin, separe o estado ativo das cópias de segurança e dos dados que podem ser recriados e, em...
