Einführung
Ein Support-Dashboard speichert ein Ticket und sein Verarbeitungsergebnis in Redis. Du erhältst diesen Ablauf und erstellst dabei ein Konto, das nur auf die eigenen Daten zugreifen darf.
Redis speichert Werte unter Namen, den Schlüsseln. Ein Cache-Schlüssel ist ein Datenname, kein Passwort. Dieses Lab verwendet synthetische Tickets und einen echten Redis-Server in einem isolierten Übungsnetz. Grundlegende Terminalbedienung genügt; Redis- oder Programmierkenntnisse sind unnötig. Client und Cache Server öffnen getrennte Container mit gemeinsamem Instanzkern. Dashboard zeigt echte Anfragen, keine Sicherheitsbewertung.
Ein Support-Ticket verarbeiten
In diesem Schritt lernst du den normalen Anwendungsablauf kennen. Redis ist der Server: Er speichert benannte Werte und beantwortet Anfragen. Das Dashboard ist ein Client: Es fragt ein Ticket ab, verarbeitet es und schreibt ein Ergebnis. Ein Cache ist ein praktischer Anwendungsspeicher; die Übungswerte sind synthetisch. Die Eingabe liegt unter support:ticket, die verarbeitete Ausgabe unter support:result.
Öffne Dashboard. Die Seite zeigt input und result. Anfangs lautet die Eingabe Ticket 104: password reset, das Ergebnis ist leer. Klicke einmal auf Process ticket. Das Ergebnis wird zu Processed: Ticket 104: password reset. Neu laden liest den gespeicherten Wert erneut. Eine echte Leseoperation wird von einer Schreiboperation gefolgt.
Die Seite zeigt auch username: default. Der Benutzername bezeichnet das Redis-Konto und ist vom Cache-Schlüssel unabhängig. Die Anwendung verwendet das automatisch verfügbare Standardkonto ohne Passwort. Das funktionierende Ergebnis belegt Verfügbarkeit, sagt aber nichts über sonstige erreichbare Daten aus.
Bei einem Verbindungsfehler lade einmal neu. Eine Fehlerseite ist keine Rechteverweigerung. Lass beide Terminal-Tabs offen und orientiere dich an ihren Namen.
Nützlichen und übermäßigen Zugriff vergleichen
In diesem Schritt liest und schreibst du einen entbehrlichen Wert und erkennst den zu breiten Standardzugriff. Verwende Client. Das vorbereitete Terminal liegt im Anwendungscontainer. redis-cli ist der Redis-Befehlszeilenclient. -h cache-server wählt den Server über seinen privaten Netzwerknamen; localhost wäre hier der Clientcontainer selbst.
GET liest einen Schlüssel. Lies die Dashboard-Eingabe:
redis-cli -h cache-server GET support:ticket
Die Antwort enthält Ticket 104: password reset. Der Doppelpunkt gehört zum Schlüsselnamen. Das Präfix support: fasst die Anwendungsdaten zusammen.
SET schreibt einen Wert. Verwende den entbehrlichen Übungsschlüssel demo:note, damit die Geschäftseingabe unverändert bleibt:
redis-cli -h cache-server SET demo:note practice
OK bedeutet, dass die Schreiboperation gelang. Lies den Wert zurück:
redis-cli -h cache-server GET demo:note
Die Antwort ist practice. Lies nun einen fremden synthetischen Finanzwert:
redis-cli -h cache-server GET finance:payroll
Du erhältst Private payroll: synthetic. Das Support-Dashboard hat keinen fachlichen Grund, Gehaltsdaten zu lesen. Authentifizierung klärt, wer sich verbindet; Autorisierung bestimmt erlaubte Befehle und Schlüssel. Das Standardkonto erlaubt sowohl diesen fremden Lesezugriff als auch unnötige Verwaltungsbefehle.
Ein begrenztes Anwendungskonto erstellen
In diesem Schritt erhält ein benanntes Konto nur die nötigen Operationen und Schlüssel. Wechsle zu Cache Server. cache-admin ist ein vorbereiteter Helfer, der das echte redis-cli mit einem getrennten Wartungskonto ausführt. Er dient der Verwaltung, nicht der Anwendungsidentität.
Eine Zugriffskontrollliste (ACL) legt Befehls- und Schlüsselregeln je Konto fest. Das Dashboard braucht GET und SET unter support:*. Der Stern steht für beliebige Endungen nach support:; dieses einfache Präfixmuster ist kein regulärer Ausdruck.
ACL SETUSER erstellt oder ändert ein Konto. reset entfernt alte Regeln, on aktiviert Authentifizierung, >... setzt das Passwort, ~... das Schlüsselmuster und +get +set erlaubt genau diese Befehle. Einfache Anführungszeichen schützen > und * vor der Shell, die sonst Ausgaben umleiten oder Dateinamen expandieren könnte. Führe aus:
cache-admin ACL SETUSER dashboard reset on '>Dash-Lab-42' '~support:*' +get +set
Erwarte OK. Das Passwort Dash-Lab-42 authentifiziert das Konto; es ist kein Redis-Datenschlüssel. Die Übungszugangsdaten sind lokale Beispiele, keine Produktionsgeheimnisse.
Wechsle zu Client. --user wählt das Konto; --askpass fragt das Passwort ab, ohne es in die Befehlszeile aufzunehmen. Gib bei jeder Abfrage Dash-Lab-42 ein; Zeichen bleiben eventuell unsichtbar:
redis-cli -h cache-server --user dashboard --askpass GET support:ticket
Das Ticket bleibt lesbar. Teste den fremden Schlüssel über eine weitere neue Verbindung:
redis-cli -h cache-server --user dashboard --askpass GET finance:payroll
Erwarte NOPERM: Die Authentifizierung gelang, der Schlüssel ist jedoch verboten. WRONGPASS bedeutet falscher Benutzername oder falsches Passwort; korrigiere und wiederhole. Ein Verbindungsfehler bedeutet Unerreichbarkeit und belegt keine erfolgreiche Einschränkung. Bei einer falschen ACL wiederhole in Cache Server den vollständigen reset-Befehl mit richtigen Werten.
Die aktive ACL speichern
In diesem Schritt speicherst du das Konto dauerhaft, damit seine Rechte einen späteren Serverstart überstehen. Eine ACL-Änderung im Speicher wirkt sofort, aktualisiert aber nicht automatisch die konfigurierte Datei. Verwende Cache Server:
cache-admin ACL SAVE
Erwarte OK. Redis schreibt die aktiven Benutzer nach /data/users.acl, in die von diesem Server verwendete ACL-Datei. cat zeigt eine Datei an; prüfe die gespeicherten Regeln:
cat /data/users.acl
Die Zeile für dashboard enthält ~support:*, -@all, +get und +set; die Reihenfolge kann variieren. -@all verweigert zunächst alle Befehlskategorien. Ein mit # beginnender Wert ist der Redis-Passworthash, kein Klartextpasswort.
Vergleiche das aktive Konto:
cache-admin ACL GETUSER dashboard
Achte auf dieselbe Schlüsselfamilie und dieselben Rechte. Eine ungenutzte Datei zu bearbeiten würde das laufende Konto nicht ändern. ACL SAVE speichert die tatsächlich aktiven Regeln.
Der Standardeintrag bleibt in diesem Lab aktiv. Ein besseres Konto stellt vorhandene Anwendungen nicht automatisch um und entfernt den alten Zugriff nicht. Das nächste Lab startet mit einem unabhängigen Zustand und erklärt diese Änderungen. Trage niemals Wartungszugangsdaten in die Anwendung ein.
Zusammenfassung
Du hast ein echtes Ticket verarbeitet, Datenschlüssel und Passwörter unterschieden, notwendige und übermäßige Zugriffe verglichen und ein benanntes Konto mit GET/SET nur für support:* erstellt und gespeichert. Nach der Anwendungsumstellung muss der alte Standardzugriff noch deaktiviert werden.
