Sicherheit · Masterkey · Verschlüsselung · interne Änderungssicherung
Reldon Control ist ein eigenständiges Projekt aus Deutschland. Sicherheit soll nicht nur ein Nebensatz sein, sondern ein eigener Grundbaustein: mit klarer Trennung zwischen WireGuard-Transportverschlüsselung, Reldon-interner Secret-Verwaltung, Masterkey-Konzept, Passwort-Hashing und interner Änderungssicherung.
Wichtig vorab
Diese Seite beschreibt die Sicherheitsrichtung von Reldon Control. Einige Bausteine sind Entwicklungsziel oder geplantes Konzept und werden erst mit der jeweiligen Implementierung verbindlich. Reldon Control verspricht keine unknackbare Sicherheit und ersetzt keine sorgfältige Systemhärtung, Updates, Rechteverwaltung oder Prüfung durch den Betreiber.
Grundprinzip
Reldon Control soll sensible Verwaltungsdaten nicht beiläufig behandeln. Entscheidend ist nicht nur, welcher Algorithmus eingesetzt wird, sondern auch, wo Schlüssel entstehen, wie sie abgeleitet werden, welche Daten gespeichert werden, welche Rechte ein Systemnutzer besitzt und ob Änderungen nachvollziehbar bleiben.
Ziel ist ein nachvollziehbares Sicherheitsmodell ohne eigene Kryptografie-Experimente: etablierte Verfahren, getrennte Schlüsselbereiche, klare Rollen, kontrollierte Änderungen und möglichst wenig unnötige Datenweitergabe.
Nicht verwechseln
WireGuard bringt die eigentliche VPN-Transportverschlüsselung mit. Diese schützt den Datenverkehr innerhalb des WireGuard-Tunnels. Reldon Control ersetzt diese Kryptografie nicht, sondern verwaltet Konfiguration, Gegenstellen, Routing, Status und Diagnose rund um WireGuard.
Davon getrennt ist die Reldon-interne Secret-Verwaltung. Dabei geht es um Dinge, die Reldon selbst speichern oder schützen muss: zum Beispiel API-Tokens, SSH-bezogene Secrets, Zugangsdaten, interne Verwaltungsdaten oder Reldon-relevante Konfigurationszustände.
Masterkey
Das geplante Sicherheitsmodell sieht einen zentralen Masterkey je Installation vor. Dieser Masterkey soll nicht einfach überall direkt verwendet werden. Er dient als geheimer Ausgangspunkt, aus dem zweckgebundene Schlüssel für unterschiedliche Bereiche abgeleitet werden können.
So können beispielsweise getrennte Schlüsselbereiche für SSH-bezogene Secrets, API-Tokens, interne Änderungssicherung oder andere Reldon-relevante Geheimnisse entstehen. Dadurch muss nicht jedes Secret mit demselben direkten Schlüssel behandelt werden.
Ein Masterkey sollte nicht wie ein kurzes Alltagskennwort verstanden werden. Als technische Mindestanforderung können Länge und Komplexität gelten; empfohlen ist eine längere Passphrase oder ein generierter Schlüssel mit hoher Entropie.
Hashing & Verschlüsselung
Passwörter sollen nicht im Klartext gespeichert werden. Für Passwort-Hashing und vergleichbare Prüfwerte ist Argon2id als Zielrichtung vorgesehen. Hashing ist für Daten gedacht, die nicht wieder entschlüsselt, sondern nur geprüft werden sollen.
Secrets, die Reldon später wieder lesen muss, brauchen Verschlüsselung statt Hashing. Für solche Daten ist eine Verschlüsselung aus der ChaCha20-Familie vorgesehen, voraussichtlich XChaCha20-Poly1305 oder ChaCha20-Poly1305.
Verschlüsselte Daten sollen nicht nur unlesbar sein, sondern auch Manipulationen erkennbar machen. Deshalb ist eine authentifizierte Verschlüsselung mit Integritätsschutz wichtig.
Was geschützt werden soll
Welche Daten im Detail verschlüsselt, gehasht oder nur protokolliert werden, hängt vom finalen Implementierungsstand ab. Grundsätzlich sollen sensible Daten nicht unnötig im Klartext liegen.
SSH-bezogene Secrets, eingeschränkte Systemnutzer wie ein späterer reldon-Benutzer und besondere administrative Zugriffe sollen getrennt betrachtet und nicht frei als Klartextdaten abgelegt werden.
Root-Zugriffe sind nicht als normaler Alltagsweg gedacht. Sie gehören in einen strengeren Ausnahme-, Recovery- oder Bootstrap-Kontext und sollen entsprechend vorsichtig behandelt werden.
API-Tokens und vergleichbare Geheimnisse müssen geschützt werden, weil sie Zugriff auf Verwaltungsfunktionen ermöglichen können. Sie gehören daher zu den besonders sensiblen Secret-Bereichen.
Interne Änderungssicherung
Reldon Control ist kein Backup-Manager, kein Backup-Server und kein Backup-Service. Wenn Reldon Control interne Sicherungen erstellt, geht es um Reldon-relevante Konfigurationen, Änderungszustände oder betroffene Dateien vor Verwaltungsaktionen.
Solche internen Änderungssicherungen können vor geplanten Änderungen, Validierungen oder kritischen Verwaltungsaktionen entstehen, damit ein vorheriger Zustand nachvollziehbar und bei Bedarf wiederherstellbar bleibt.
Dabei werden nicht pauschal alle Daten eines Systems gesichert. Im Fokus stehen die betroffenen Konfigurationsdateien, Verwaltungsdaten oder Zustände, die für die jeweilige Änderung relevant sind.
KI-Unterstützung
KI-Funktionen sind als spätere optionale Unterstützung geplant, zuerst voraussichtlich über eine OpenAI-API-Schnittstelle. Gedacht sind Hilfen für Erklärung, Diagnose, Log- oder Konfigurationsanalyse und verständliche Hinweise, warum etwas nicht funktioniert.
Reldon Control ist nicht als autonom entscheidende KI-Plattform geplant. Kritische Netzwerk-, Sicherheits- oder Infrastrukturänderungen sollen nicht ungeprüft durch eine KI automatisch ausgeführt werden.
Nutzer sollen einstellen können, ob KI-Funktionen deaktiviert sind oder in Modi wie Diagnose, Erklärung oder Assistenz genutzt werden. Ebenso soll kontrollierbar sein, welche Daten eine KI sehen darf und welche Aufgaben erlaubt sind. Externe KI-APIs können nutzungsabhängige Kosten verursachen.
Was Reldon Control nicht verspricht
Reldon Control soll robuste, moderne Sicherheitsverfahren nutzen. Trotzdem ist kein System allein durch gute Verschlüsselung automatisch sicher. Sicherheit hängt auch von Implementierung, Schlüsselverwaltung, Updates, Betriebssystemhärtung, Benutzerrechten, Netzsegmentierung und korrekter Bedienung ab.
Deshalb werden Begriffe wie „unknackbar“, „absolut sicher“ oder „magische Enterprise-Sicherheit“ bewusst vermieden. Ziel ist ein nachvollziehbares, prüfbares und sauber dokumentiertes Sicherheitsmodell.
Quellen & technische Einordnung
Die konkrete Reldon-Implementierung ist noch Entwicklungsarbeit. Die folgenden Quellen beschreiben die technischen Grundlagen, auf die sich die Sicherheitsrichtung bezieht: