Comment empêcher les secrets Plex de se retrouver dans les fichiers Compose ou les sauvegardes

Conservez les jetons Plex, les clés API, les mots de passe et les certificats en dehors des fichiers Compose versionnés, et excluez les informations secrètes des sauvegardes de configuration ordinaires.

Le risque ne se limite pas aux dépôts publics. Les fichiers d’environnement, les journaux de débogage, les ensembles Compose copiés et les archives de sauvegarde peuvent tous élargir l’accès aux identifiants. Inventoriez les valeurs qui sont réellement secrètes, injectez-les au moment de l’exécution et rendez leur rotation possible sans reconstruire toute la pile.

Classez les secrets avant de modifier leur stockage

Toutes les variables d’environnement ne sont pas sensibles, mais les jetons, les mots de passe, les clés privées et les identifiants d’API doivent suivre un processus de traitement différent de celui des paramètres ordinaires.

OWASP recommande l’injection de secrets dans les conteneurs, plutôt que d’intégrer les secrets aux images ou de les exposer via la configuration générale.

Répertoriez chaque identifiant utilisé par Plex, les proxys, les outils de requêtes et les automatisations. Indiquez où chaque valeur est stockée, qui peut la lire et comment elle est renouvelée.

Ne codez pas les identifiants en dur dans Compose

Un fichier Compose est souvent copié, versionné, envoyé par e-mail ou inclus dans des ensembles de sauvegarde. Les secrets codés en dur voyagent avec lui et peuvent subsister longtemps après le remplacement du serveur d’origine.

Un modèle Docker plus sûr utilise une gestion séparée des secrets, afin que les valeurs sensibles soient accordées au service sans devenir du texte de configuration ordinaire.

Remplacez les valeurs codées en dur par un secret ou une source d’exécution protégée. Vérifiez que la sortie Compose générée et l’historique du dépôt ne contiennent plus l’ancien identifiant.

Excluez les fichiers d’environnement des sauvegardes générales

Un fichier `.env` peut être pratique, mais il contient tout de même des données en clair, sauf si une autre couche les protège. Le sauvegarder avec la configuration générale peut élargir discrètement le nombre de personnes qui reçoivent les identifiants.

La portée des variables d’environnement de Compose modifie la résolution de `.env`, de `env_file` et des variables des services. Sachez donc quel fichier contient réellement le secret utilisé.

Séparez les sauvegardes de secrets de la configuration courante des applications et limitez leur accès. Si vous n’avez pas besoin de restaurer une valeur parce qu’elle peut être réémise, privilégiez une rotation documentée plutôt qu’une conservation indéfinie. Conservez les identifiants en dehors de la structure de données persistantes des applications, afin que les sauvegardes ordinaires de ces données ne deviennent pas automatiquement des archives de secrets.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Effectuez une rotation après une exposition ou une modification du processus

Supprimer un jeton divulgué d’un fichier n’invalide pas les copies déjà créées. Traitez toute exposition suspectée comme un événement nécessitant la rotation des identifiants, et non comme une simple tâche de nettoyage de fichier.

La capacité et la rotation normales des sauvegardes peuvent créer de nombreuses copies historiques. C’est pourquoi la rotation des secrets est importante lorsqu’une archive peut déjà contenir l’ancienne valeur.

Effectuez la rotation du jeton concerné, mettez à jour la source d’exécution et vérifiez que l’ancienne valeur ne permet plus de s’authentifier. Ajoutez une étape d’analyse des secrets avant les prochains exports Compose ou de sauvegarde.