Einführung
Das Dashboard hat ein vorbereitetes begrenztes Konto, verbindet sich aber noch über das weitreichende Redis-Standardkonto. Du änderst die Konfiguration und deaktivierst den alten Zugriffsweg bei weiterhin laufender Überwachung.
Diese unabhängige Umgebung enthält das Konto dashboard aus der vorherigen Lektion. Die dort erklärten Redis-Befehle und ACL-Konzepte reichen aus. Jede Anwendungsoperation öffnet eine neue Verbindung; die nächste Anfrage nutzt die aktuelle Konfiguration.
Den Ausgangszustand der Anwendung prüfen
In diesem Schritt stellst du den normalen Ablauf in dieser neuen Umgebung fest. Öffne Dashboard. Die Eingabe ist Ticket 104: password reset, das Ergebnis leer und der Benutzer default. Klicke auf Process ticket und prüfe Processed: Ticket 104: password reset.
Lies in Client die private Konfiguration. cat zeigt die Datei. Das Terminal startet in /workspace, dem Konfigurationsverzeichnis:
cat app.json
JSON speichert benannte Felder in geschweiften Klammern. username bezeichnet den Redis-Benutzer, password liefert das Authentifizierungsgeheimnis. Zeichenketten stehen in doppelten Anführungszeichen; Kommas trennen Felder. Momentan ist der Benutzer default, das Passwort leer.
Die Anwendung liest die Datei bei jeder Anfrage erneut und öffnet neue Redis-Verbindungen. Neustart und eigener Clientcode sind unnötig. Das separate Konto monitor liest monitor:heartbeat; es muss nach Änderung des Standardkontos funktionieren. Die Datei enthält Geheimnisse und wird deshalb privat gehalten statt öffentlich ausgeliefert.
Die Dashboard-Verbindung umstellen
In diesem Schritt verwendet die Anwendung das begrenzte Konto. Ersetze in Client die Konfiguration mit zwei Feldern. cat > app.json leitet den folgenden Text in die Datei und ersetzt ihren Inhalt. Das zitierte EOF beginnt ein Here-Dokument. Füge alle Zeilen einschließlich des letzten alleinstehenden EOF ein. Die Anführungszeichen verhindern Shell-Erweiterungen im JSON.
cat > app.json <<'EOF'
{"username":"dashboard","password":"Dash-Lab-42"}
EOF
Nur die Konfiguration ändert sich. Das Konto hat in diesem neuen Zustand bereits GET/SET für support:*. Lade Dashboard neu, prüfe den Benutzer dashboard und klicke erneut auf Process ticket. Ein altes Ergebnis genügt nicht; die neue Operation beweist Lesen und Schreiben mit dem konfigurierten Konto.
Bei WRONGPASS korrigiere die JSON-Zugangsdaten und wiederhole die Anfrage. Bei NOPERM prüfe Muster und Befehle mit cache-admin ACL GETUSER dashboard in Cache Server. Der vollständige Reset-Befehl aus dem ersten Lab repariert ein falsch eingestelltes Konto. Fehlerhaftes JSON lässt sich durch erneutes Einfügen des Blocks korrigieren.
Verwende nicht maint als Abkürzung: Die Anwendung braucht ihr eigenes begrenztes Konto.
Den weitreichenden Standardeintrag deaktivieren
In diesem Schritt deaktivierst du den automatischen Zugriff, während legitime Konten erhalten bleiben. Wechsle zu Cache Server. Das Wartungskonto von cache-admin bleibt aktiv und ermöglicht weitere Verwaltung.
ACL SETUSER default off verhindert neue Authentifizierung als Standardbenutzer. Speichere die aktive Änderung in der konfigurierten ACL-Datei:
cache-admin ACL SETUSER default off
cache-admin ACL SAVE
Beide Befehle antworten mit OK. Wechsle zu Client und teste eine neue Verbindung ohne Zugangsdaten:
redis-cli -h cache-server GET support:ticket
Erwarte NOAUTH Authentication required., die beabsichtigte Ablehnung. Anders als NOPERM betrifft sie eine nicht authentifizierte Anfrage. Jeder Aufruf erstellt eine neue Verbindung. Das Deaktivieren eines Benutzers garantiert nicht, bereits authentifizierte Sitzungen zu beenden; deren Widerruf gehört nicht zu dieser Übung.
Lade Dashboard neu und klicke auf Process ticket. Das benannte Konto sollte weiter funktionieren. Hast du das falsche Konto deaktiviert, wende im Wartungsterminal seine vollständige richtige Reset-Regel an und speichere erneut. Aktiviere den breiten Standardzugriff nicht, um einen Konfigurationsfehler zu verdecken.
Sicherheit und Verfügbarkeit gemeinsam testen
In diesem Schritt vergleichst du erlaubte Arbeit, verbotene Daten und einen unnötigen Befehl. Verwende Client. Gib bei jeder Abfrage durch --askpass das Passwort Dash-Lab-42 ein.
redis-cli -h cache-server --user dashboard --askpass GET support:result
Das verarbeitete Ergebnis bleibt lesbar. Der nächste Befehl fragt absichtlich fremde Finanzdaten ab:
redis-cli -h cache-server --user dashboard --askpass GET finance:payroll
Erwarte NOPERM. CONFIG GET liest Servereinstellungen; selbst dieser Verwaltungslesezugriff ist unnötig. Der zitierte Stern verlangt alle Einstellungsnamen und muss unverändert Redis erreichen:
redis-cli -h cache-server --user dashboard --askpass CONFIG GET '*'
Erwarte NOPERM wegen des Befehlsrechts. Verwende nun das vorhandene Überwachungskonto und gib Monitor-Lab-42 ein:
redis-cli -h cache-server --user monitor --askpass GET monitor:heartbeat
Erwarte healthy. Alle Konten zu deaktivieren oder Redis anzuhalten würde diesen positiven Test brechen und ist keine Reparatur. Zeige in Cache Server die aktiven ACLs und die gespeicherte Datei:
cache-admin ACL LIST
cat /data/users.acl
Gespeicherte und aktive Einträge müssen einschließlich default off übereinstimmen. Wiederhole andernfalls cache-admin ACL SAVE. Klicke abschließend erneut auf Process ticket in Dashboard. Echte Verfügbarkeit und gezielte Ablehnungen belegen das Ergebnis; eine funktionierende Seite allein beweist keine minimalen Rechte.
Zusammenfassung
Du hast die echte Anwendung auf ihr begrenztes Redis-Konto umgestellt, neue Standardzugriffe deaktiviert, die ACL gespeichert sowie verbotene Anfragen und legitime Geschäfts- und Überwachungsfunktionen geprüft. Die Tests nutzen neue Verbindungen und belegen keinen Widerruf vorhandener Sitzungen.
