Security and Operations - JanHG98/netcore-tetra GitHub Wiki

Security and Operations

Aktueller Stand 16.10.2026

Verbindlich: main@8fb581b730f7a3833566c4bbb7c87875ad921e69; veröffentlicht bleibt v1.9.0. PR #74–#97 sind integriert. Deployment/Discovery, Imagebuilder, Pi-VPN und Syslog sind auf main, nicht mehr nur historische Vorschau. 26 reguläre Rollen einschließlich Deployment-VM; Provisioning ist optional zusätzlich.

Betreiberbestätigt: KDE-Boot, Rufe, SDS, Aufnahme/RF-Wiedergabe und WLAN am 13.10.; 28/28 Discovery-Agenten aktualisiert und keine ungeklärten Remote-Aufträge mehr am 15.10. Ein aktueller Backend-Gesamtrollout, NAS-Entlastung, SIP/Telegram, VPN-Wechsel und Dauerlauf bleiben separat offen. Vier alte Git-/Timeoutfehler bleiben Fehler.

Gesamtroadmap · Upstream-Vergleich · Roadmap und Releases. NETCORE-IAM-01 ist weiterhin Planung; AD-SSO-Pilot und Gruppenmapping sind konkretisiert, Produkt-/Betriebsentscheidung und Umsetzung offen.

Aktuelle Fachanleitung. Zentrale Gruppen-/Subscriber-/Mobility-Sollwerte sind nicht automatisch im aktiven MM oder Endgerät wirksam; Nachbarzellenaussendung beweist keinen laufenden Handover. Open Lab ist keine endgültige Zugriffsarchitektur.

Historischer Seitenstand bis 07.10.2026

Die folgende frühere Fassung bleibt als datierte Historie erhalten. Frühere Dienstzahlen, Featurebranch-Aussagen, offene Tests und Prioritäten sind keine aktuelle Statusaussage; heutige Verfahren stehen oben beziehungsweise in den verlinkten kanonischen Docs.

Sicherheit und Betrieb

Aktueller Quellenstand 07.10.2026: main 990bffb2; Release weiterhin v1.9.0. PR #59 mit Hell/Dunkel ist integriert, PR #60 ergänzt Projektarchive. Nur main ist als Branch vorhanden. Deployment/Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Pipeline bleiben ausschließlich am historischen Featurecommit bbf0397 vorhanden. Keine neue Live-Abnahme. Roadmap und Releases · Upstream-Vergleich

Zentrale Anmeldung bleibt Planung

NETCORE-IAM-01 umfasst Inventur M0 und Architektur M1 vor Pilot/Migration. Keycloak, eigener LXC, gemeinsamer Rust-Baustein und AD sind Vorschläge. Ressourcenrechte werden im jeweiligen Backend durchgesetzt; Identity-Ausfall öffnet nichts. Drive darf unabhängig lokal starten, aber ausschließlich mit vollständigen eigenen Datei-/Ordnerrechten. Roadmap und Releases

Netzwerkgrenzen

Dashboard, Directory, Piper und Control Room sind Verwaltungsdienste. Ihre direkten Listener gehören in ein isoliertes Managementnetz. Für kontrollierten externen Zugriff kann ein abgesicherter Reverse Proxy hinzukommen; die Direktports müssen weiter geschützt bleiben. Ein bloßes Portforwarding ist keine sinnvolle Standardlösung.

Das aktuelle open_lab-Inventory bindet zahlreiche Fach-WebUIs ohne Login, Management-Token oder TLS. Hier reicht ein Reverse Proxy allein nicht, wenn die direkten LXC-Ports aus anderen Netzen erreichbar bleiben. Alle Management-Endpunkte im isolierten Testnetz halten und die konkrete Exposition mit Firewall/ss prüfen. Diese Vorlage ist nicht für ungeschützte produktive Netze geeignet. Open-Lab-Deployment

Geheimnisse

Nicht in Git, Wiki, Screenshots oder Support-Logs veröffentlichen:

  • Passwörter
  • Tokens
  • Bot-Schlüssel
  • SIP-/Brew-Zugangsdaten
  • interne Teilnehmerlisten
  • private IP-Pläne, wenn sie nicht für die Fehlersuche notwendig sind

Minimalrechte

  • eigener Systembenutzer pro Dienst, soweit praktikabel
  • Konfiguration 0600
  • Schreibrechte nur auf benötigte Verzeichnisse
  • keine globale Schreibbarkeit von NFS- oder Medienpfaden
  • Dashboard-Systemaktionen gezielt absichern

Funkbetrieb

  • nur zulässige Frequenzen und Leistungen verwenden
  • Lasttests kontrolliert durchführen
  • Notfall- und Systemstatus nicht mit realen Einsatznetzen vermischen
  • Simulationsteilnehmer und produktive ISSIs trennen
  • bei Änderungen an Antennen, Filtern oder Verstärkern Spektrum erneut prüfen

Protokollierung

Logs können ISSIs, Gruppen, Texte und Standorte enthalten. Aufbewahrung und Weitergabe müssen zum Testzweck passen. Bei Support-Auszügen sensible Werte schwärzen, aber Zeitstempel und technische Fehlermeldungen erhalten.

Notfalllogik

Notfallereignisse bleiben standardmäßig lokal. Externe Weiterleitung an Telegram, Brew oder Leitstelle nur aktivieren, wenn Empfänger, Eskalation und Rücknahme eindeutig definiert sind.

Schlüssel und Aktoren

Security Core und KMF haben getrennte Zuständigkeiten für Policy/Authentisierung und Schlüssel-Lebenszyklus. Rohschlüssel gehören weder in UI-Screenshots noch in Logs oder Git. Bei Ausfall des KMF dürfen installierte Schlüssel lokal weitergelten, neue Rotation/OTAR ist damit nicht automatisch verfügbar. Physische Ausgänge und HA-/Homematic-Aktionen bleiben im Open-Lab-Beispiel gesondert freizugeben; default_deny und Zielbegrenzung nicht für bequeme Tests aushebeln. MQTT-und-Home-Assistant · Dienstkatalog

Tokenpflicht der Warnzentrale und gezielte Dateirechte

alert-service verlangt standardmäßig ein Bearer-Token für seine Fach-API; allow_unauthenticated=false. NETCORE_ALERT_TOKEN liegt nur in der lokalen Umgebung, nicht in Git. Health-Proben sind gesondert erreichbar. Die HTTP-Listener weiterhin schützen. Warnzentrale

Für generierte Asterisk-Includes gilt als gezielte Ausnahme 0640 mit Gruppe asterisk: Der SIP-Patch in v1.9.0 hält die Dateien auch bei umask 077 lesbar. Diese Include-Dateien nicht mit einer pauschalen 0600-Regel für den Asterisk-Prozess unlesbar machen. Andere Secrets benötigen weiterhin passende Minimalrechte.

Entwicklungsvorschau vom 28 September 2026

Entwicklungsvorschau vom 28.09.2026: Historischer Featurecommit bbf0397, Deployment-Komponente 0.2.3. Diese Funktionen sind noch nicht auf main und kein neuer Gesamtrelease. PR #57 wurde in den Entwicklungsbranch gemergt. Controller/Agent arbeiten auch in der Vorschau ohne Login/TLS/RBAC. Personalisierte Images enthalten OS-/WLAN-/VPN-Daten und sind über die erreichbaren HTTP-Downloads abrufbar. Konkrete Daten nicht veröffentlichen und Artefaktzugriff/Aufbewahrung bewusst begrenzen. Der root-Imagebuilder verwendet einen Unix-Socket; das ersetzt keine Betreiber-Zugriffskontrolle. Deployment-und-Discovery

Planungsreferenzen: Zentrale Anmeldung und RBAC · NetCore Drive. Beide Vorhaben sind Planung; keine installierte main-Funktion.