So verhindern Sie, dass Home-Assistant-Geheimnisse in Compose-Dateien oder Backups gelangen

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Prevent Home Assistant Secrets From Leaking Into Compose Files or Backups - Zima Store Online

Verhindern Sie den Verlust von Geheimnissen, indem Sie Werte aus gemeinsam nutzbaren Compose-Definitionen heraushalten und jedes Backup sowie jeden Diagnoseexport als vertraulich behandeln, bis eine Inhaltsprüfung bestanden wurde.

Home Assistant benötigt zur Laufzeit Zugangsdaten. Daher kann kein lokales Layout sie vor einem Administrator mit vollständigem Hostzugriff verbergen. Das praktische Ziel ist enger gefasst: versehentliche Commits, Uploads für den Support, weitreichende Backup-Kopien und unnötigen Containerzugriff verhindern. Erfassen Sie, wo jeder Wert in den Stack gelangt, ersetzen Sie Literale durch eine kontrollierte Geheimnisquelle und testen Sie die exportierten Artefakte, ohne die Geheimnisse selbst auszugeben.

Erfassen Sie jede Stelle, an der ein Geheimnis entweichen kann

Listen Sie API-Tokens, Datenbankpasswörter, MQTT-Zugangsdaten, Webhook-URLs, Verschlüsselungsschlüssel, private Zertifikate und Wiederherstellungsschlüssel auf. Dokumentieren Sie für jeden Eintrag den Verbraucher zur Laufzeit, den Speicherpfad, den Dateibesitzer, die Aufnahme in Backups, den Repository-Status, die Protokollausgabe und die Methode zur Rotation. Kopieren Sie die Werte nicht in die Bestandsaufnahme.

Geheimnisdateien strukturieren Werte, bleiben für ein Konto mit Leserechten auf dem Host jedoch Klartext. Diese Klartext-Zugriffsgrenze bedeutet, dass die Trennung vor allem versehentliche Offenlegung reduziert, anstatt einen Angreifer mit vollständigen Berechtigungen abzuwehren.

Als Fehler gilt jeder Literalwert in YAML-Dateien von Compose, jede versionierte Umgebungsdatei, jedes für viele Benutzer lesbare Konfigurationsverzeichnis oder jeder Export mit unbekanntem Inhalt. Setzen Sie Freigaben und Pushes in Repositories aus, bis jeder Offenlegungspfad einen Verantwortlichen und eine Korrektur hat.

Trennen Sie Laufzeitgeheimnisse von Bereitstellungsdefinitionen

Ersetzen Sie Literale in Compose durch dateibasierte Geheimnisse mit möglichst eng gefassten Berechtigungen oder durch eine andere von der Bereitstellung unterstützte Geheimnisquelle. Geben Sie jedem Dienst nur die von ihm verwendeten Werte, binden Sie sie nach Möglichkeit schreibgeschützt ein und beschränken Sie die Hostberechtigungen auf die Identität zur Laufzeit und Administratoren.

Umgebungswerte können durch Inspektion, den Prozesskontext oder Protokolle sichtbar werden, während das Einbinden dateibasierter Geheimnisse einschränken kann, welche Container ein Zugangsdaten erhalten. Auch lokale Geheimnisdateien benötigen eine Zugriffskontrolle.

Validieren Sie zunächst mit Platzhaltern, prüfen Sie die gerenderte Compose-Konfiguration auf versehentliche Literale, starten Sie anschließend einen Dienst und bestätigen Sie, dass er nur auf sein zugewiesenes Geheimnis zugreifen kann. Führen Sie ein Rollback durch, wenn die Änderung dazu führt, dass eine Anwendung Werte ausgibt oder weitreichende Verzeichnisberechtigungen erfordert.

Kontrollieren Sie den Inhalt von Backups und Support-Bundles

Behandeln Sie Backups als zugangsdatenhaltig, sofern nicht nachgewiesen ist, dass ihr Umfang etwas anderes ergibt. Verschlüsseln Sie Kopien, die den vertrauenswürdigen Speicherbereich verlassen, bewahren Sie Wiederherstellungsschlüssel separat auf, begrenzen Sie Aufbewahrungsdauer und Zugriff und hängen Sie niemals ein vollständiges Konfigurationsarchiv an, wenn ein redigierter Protokollauszug die Supportfrage beantwortet.

Nutzen Sie den Workflow zum Schutz der Konfiguration, um die Wiederherstellbarkeit zu gewährleisten und gleichzeitig sichere Speicherung von gemeinsam nutzbarem Bereitstellungsmaterial zu trennen.

Prüfen Sie vor der Freigabe Dateinamen und extrahierten Text auf bekannte Schlüsselnamen, Token-Präfixe, private URLs, E-Mail-Adressen, Zertifikate und die exakten Hashes kontrollierter Testmarkierungen. Eine bestandene Prüfung ist eine Freigabebedingung, aber kein Beweis dafür, dass kein Geheimnis in einem unbekannten Format vorhanden ist.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Rotieren Sie offengelegte Werte und weisen Sie den Präventionspfad nach

Wenn ein verwendbarer Wert in ein Repository, Ticket, einen Chat, einen öffentlichen Link oder ein nicht vertrauenswürdiges Backup gelangt ist, widerrufen oder rotieren Sie ihn zuerst. Das Löschen der sichtbaren Kopie macht vorhandene Kopien oder den Verlauf nicht ungültig. Dokumentieren Sie den betroffenen Dienst und den Zeitpunkt der Rotation, ohne den alten Wert aufzubewahren.

Erstellen Sie ein harmloses Canary-Geheimnis, stellen Sie es über den neuen Pfad bereit, erzeugen Sie das normale Compose-Rendering, Backup und Diagnose-Bundle und durchsuchen Sie anschließend diese Artefakte. Die Laufzeitumgebung sollte das Canary-Geheimnis erhalten, während gemeinsam nutzbare Artefakte es außerhalb des absichtlich geschützten Backup-Bereichs nicht offenlegen.

Beenden Sie den Vorgang, wenn echte Geheimnisse in Bereitstellungsdefinitionen und Repositories fehlen, geschützte Backups über einen separaten Wiederherstellungspfad verfügen, die Artefaktprüfungen bestanden sind und offengelegte Zugangsdaten rotiert wurden. Eskalieren Sie den Fall, wenn eine Drittanbieterintegration Geheimniswerte protokolliert oder keine eng begrenzte Geheimnisquelle nutzen kann, ohne weiterreichenden Hostzugriff zu erhalten.