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

Évitez les fuites de secrets en gardant les valeurs hors des définitions Compose partageables et en considérant chaque sauvegarde ou export de diagnostic comme sensible jusqu’à ce qu’il ait passé une analyse de contenu.

Home Assistant a besoin d’identifiants à l’exécution ; aucune organisation locale ne peut donc les rendre invisibles à un administrateur disposant d’un accès complet à l’hôte. L’objectif pratique est plus restreint : empêcher les validations accidentelles, les téléversements vers le support, les copies de sauvegarde trop larges et les accès inutiles aux conteneurs. Répertoriez l’endroit où chaque valeur entre dans la pile, remplacez les littéraux par une source de secrets contrôlée et testez les artefacts exportés sans afficher les secrets eux-mêmes.

Cartographiez chaque endroit où un secret peut s’échapper

Répertoriez les jetons d’API, mots de passe de base de données, identifiants MQTT, URL de webhook, clés de chiffrement, certificats privés et clés de récupération. Pour chacun, indiquez le consommateur à l’exécution, le chemin de stockage, le propriétaire du fichier, l’inclusion dans les sauvegardes, l’état dans le dépôt, l’exposition dans les journaux et la méthode de rotation. Ne copiez pas les valeurs dans l’inventaire.

Les fichiers de secrets organisent les valeurs, mais celles-ci restent en clair pour un compte capable de lire l’hôte. Cette limite d’accès en clair signifie que la séparation réduit principalement la divulgation accidentelle, plutôt qu’elle ne neutralise un attaquant disposant de privilèges complets.

Il y a échec dès qu’une valeur littérale apparaît dans un fichier YAML Compose, dans un fichier d’environnement suivi par le contrôle de version, dans un répertoire de configuration largement accessible ou dans un export au contenu inconnu. Suspendez les partages et les envois vers les dépôts jusqu’à ce que chaque chemin d’exposition ait un responsable et une correction.

Séparez les secrets d’exécution des définitions de déploiement

Remplacez les littéraux dans Compose par des secrets basés sur des fichiers, avec des droits strictement nécessaires, ou par une autre source de secrets prise en charge par le déploiement. Accordez à chaque service uniquement les valeurs qu’il consomme, montez-les en lecture seule lorsque possible et limitez les permissions de l’hôte à l’identité d’exécution et aux administrateurs.

Les valeurs d’environnement peuvent apparaître lors de l’inspection, dans le contexte des processus ou dans les journaux, tandis que le montage de secrets basé sur des fichiers peut limiter les conteneurs qui reçoivent un identifiant. Les fichiers de secrets locaux nécessitent toujours un contrôle des permissions.

Validez d’abord avec des valeurs fictives, inspectez la configuration Compose générée pour détecter d’éventuels littéraux accidentels, puis démarrez un seul service et vérifiez qu’il ne peut lire que le secret qui lui est attribué. Revenez en arrière si la modification amène l’application à afficher des valeurs ou exige un accès permissif au répertoire.

Contrôlez le contenu des sauvegardes et des lots de support

Considérez les sauvegardes comme contenant des identifiants, sauf si le contraire est démontré. Chiffrez les copies qui quittent la limite de stockage de confiance, conservez les clés de récupération séparément, limitez la durée de conservation et l’accès, et ne joignez jamais une archive complète de configuration lorsqu’un extrait de journal anonymisé suffit à répondre à la question de support.

Utilisez le processus de protection de la configuration afin de préserver la récupérabilité tout en séparant le stockage sécurisé des éléments de déploiement partageables.

Avant la diffusion, analysez les noms de fichiers et le texte extrait à la recherche de noms de clés connus, de préfixes de jetons, d’URL privées, d’adresses e-mail, de certificats et des hachages exacts de marqueurs de test contrôlés. Une analyse propre constitue une condition de diffusion, et non la preuve qu’aucun format de secret inconnu ne peut exister.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Faites tourner les éléments exposés et prouvez l’efficacité de la prévention

Si une valeur utilisable est entrée dans un dépôt, un ticket, une conversation, un lien public ou une sauvegarde non fiable, révoquez-la ou faites-la tourner en premier ; supprimer la copie visible n’invalide ni les copies ni l’historique. Notez le service concerné et l’heure de rotation sans conserver l’ancienne valeur.

Créez un secret témoin inoffensif, déployez-le via le nouveau chemin, produisez le rendu Compose, la sauvegarde et le lot de diagnostic habituels, puis recherchez ce secret dans ces artefacts. L’exécution doit recevoir le secret témoin, tandis que les artefacts partageables ne doivent pas l’exposer en dehors de la limite de sauvegarde intentionnellement protégée.

Arrêtez-vous lorsque les vrais secrets sont absents des définitions de déploiement et des dépôts, que les sauvegardes protégées disposent d’un chemin de récupération distinct, que les analyses d’artefacts réussissent et que les identifiants exposés ont été renouvelés. Faites remonter le problème lorsqu’une intégration tierce consigne des valeurs secrètes ou ne peut pas utiliser une source de secrets restreinte sans accès plus large à l’hôte.