Einführung
Eine Anwendung kann für ihre Benutzer korrekt funktionieren und zugleich Informationen preisgeben, die diese nicht benötigen. DeskLite läuft bereits, doch seine Statusantwort enthält interne Entwicklungsdetails. Du untersuchst diese Antwort, änderst eine Konfigurationsoption und prüfst, ob der Dienst weiterhin nützlich ist.
Du brauchst nur grundlegende Kenntnisse zum Navigieren und Lesen von Dateien im Terminal. Anfragen, HTTP-Antworten, Konfigurationsschalter und der vorbereitete Neustartbefehl werden bei ihrer Verwendung erklärt. Das ist dein erster DevSecOps-Kreislauf: Risiko beobachten, Ursache beheben und Sicherheit sowie normalen Betrieb gemeinsam prüfen.
Eine Dienstantwort Untersuchen und Korrigieren
In diesem Schritt liest du eine DeskLite-Antwort, erkennst unnötige interne Details und korrigierst die verantwortliche Einstellung.
DeskLite ist eine kleine Helpdesk-Anwendung. Mitarbeiter benötigen Ticketinformationen und eine einfache Anzeige, dass der Dienst läuft, aber keine internen Dateipfade oder Entwicklungsdiagnosen. Diese Details sind die zu schützenden Informationen; alle Personen, die eine Antwort lesen können, bilden deren Zielgruppe.
Ein Dienst ist ein Programm, das weiterläuft und Anfragen beantwortet. Eine HTTP-Anfrage fordert etwas von einem Webdienst an; dessen Antwort enthält einen Statuscode und einen Inhalt. Du verwendest das Terminalprogramm curl und brauchst weder Browser noch Programmierkenntnisse.
Der Dienst läuft bereits. Arbeite nur in seinem vorbereiteten Verzeichnis:
cd /home/labex/project/desklite
Eine URL sagt curl, wohin die Anfrage gehen soll. In http://127.0.0.1:8080/status bezeichnet http das Protokoll, 127.0.0.1 diesen Laborrechner, 8080 den Dienst und /status einen Endpunkt, also eine bestimmte angebotene Antwort. Hier musst du kein Netzwerk konfigurieren.
curl http://127.0.0.1:8080/status
Der Inhalt ist JSON: benannte Felder mit Werten zwischen geschweiften Klammern. Du musst dies nur lesen, kein Programm schreiben.
{
"service": "DeskLite",
"status": "running",
"internal_path": "/opt/labex-desklite/private/settings.ini",
"debug_details": "development diagnostics enabled"
}
service und status sind für die vorgesehene Zielgruppe nützlich. internal_path verrät einen internen Dateipfad, debug_details Entwicklungsinformationen. Ein bekannter Pfad gewährt nicht automatisch Dateizugriff, doch unnötige Details können weitere Nachforschungen erleichtern. Das ist Informationspreisgabe.
Füge die Option -i hinzu, um HTTP-Header über dem Inhalt anzuzeigen:
curl -i http://127.0.0.1:8080/status
Die erste Zeile enthält 200 OK: Die Anfrage war erfolgreich. Header wie Content-Type: application/json beschreiben den Inhalt; eine Leerzeile trennt beide Bereiche. Datumsangaben können variieren. Ein erfolgreicher HTTP-Status bedeutet keine sichere Antwort – gerade diese erfolgreiche Antwort gibt Informationen preis.
Lies die Dienstkonfiguration, also die Datei mit den Anwendungseinstellungen:
cat service.conf
[service] gruppiert Einstellungen. Eine Zeile mit # am Anfang ist ein erklärender Kommentar. debug = true ist ein boolescher Schalter: true aktiviert Entwicklungsdiagnosen, false deaktiviert sie. Der Kommentar verbindet die Einstellung mit den offengelegten Statusfeldern.
Die Konfigurationskorrektur Anwenden
Debug-Informationen helfen Entwicklern bei der Fehlersuche. Eine während der Entwicklung nützliche Einstellung kann für Leser, die nur einen öffentlichen Status benötigen, ungeeignet sein. DevSecOps integriert Sicherheit in die gemeinsame Arbeit von Entwicklung und Betrieb: Sichtbarkeit festlegen, Konfiguration ändern und das laufende Ergebnis testen.
Öffne die Konfiguration mit nano, einem Texteditor für das Terminal. Gehe mit den Pfeiltasten zur Einstellung. Halte bei den folgenden Tastenkombinationen Ctrl gedrückt, während du den Buchstaben drückst:
nano service.conf
Ändere nur debug = true in debug = false. Behalte die Überschrift [service] und den Kommentar. Speichere mit Ctrl+O, Enter und verlasse den Editor mit Ctrl+X. Prüfe die gespeicherte Datei:
cat service.conf
Sie sollte jetzt so aussehen:
[service]
## Include development diagnostics in status responses.
debug = false
Eine Datei auf dem Datenträger und ein laufendes Programm sind unterschiedliche Dinge. Dieser Dienst liest Einstellungen beim Start; bloßes Speichern aktualisiert die Antwort nicht. Der Kurs stellt restart.sh bereit, damit du die Konfiguration ohne eigene Prozessverwaltung anwenden kannst. bash führt das vorbereitete Skript aus; du musst es nicht bearbeiten.
bash restart.sh
Erwartete Ausgabe:
DeskLite restarted.
Frage denselben Endpunkt erneut mit Headern ab:
curl -i http://127.0.0.1:8080/status
Erwarte 200 OK und diesen Inhalt:
{
"service": "DeskLite",
"status": "running"
}
Beide internen Felder fehlen, der nützliche Status bleibt. Falls sie noch erscheinen, prüfe, ob du service.conf gespeichert und den Neustart ausgeführt hast. Meldet das Skript einen Konfigurationsfehler, stelle Überschrift und Schreibweise des booleschen Werts wie oben wieder her und versuche es erneut. Ersetze nicht die Anwendung und stoppe nicht den Dienst, um die Antwort zu verbergen.
Sicherheit und Fachfunktion Gemeinsam Prüfen
In diesem Schritt prüfst du, ob die Korrektur einen weiteren Neustart übersteht und DeskLite seine Benutzer weiter bedient.
Ein defekter Dienst würde zwar die Antwort beseitigen, aber auch nützliche Funktionen. Deshalb brauchen wir zwei Belege: Sensible Felder fehlen und der legitime Dienst funktioniert. Ein Healthcheck meldet grundlegende Betriebsbereitschaft; eine fachliche Anfrage prüft die tatsächlich benötigte Funktion.
Starte erneut, um die dauerhafte Wirkung der gespeicherten Einstellung zu prüfen:
bash restart.sh
Frage den Status erneut ab:
curl -i http://127.0.0.1:8080/status
Erwarte 200 OK, service und status, aber weder internal_path noch debug_details. Frage nun den Health-Endpunkt ab:
curl -i http://127.0.0.1:8080/health
Erwarte 200 OK und:
{
"status": "ok"
}
Frage abschließend den fachlichen Endpunkt ab:
curl -i http://127.0.0.1:8080/tickets
Erwarte 200 OK und das ursprüngliche Ticket:
{
"tickets": [
{
"id": 1,
"title": "Printer offline"
}
]
}
Ein gesunder Prozess allein beweist nicht, dass der Ticketzugriff funktioniert. Gemeinsam zeigen die Anfragen die beseitigte Informationspreisgabe und die erhaltene Funktion. curl kann zusätzlich eine Übertragungsanzeige darstellen; beurteile HTTP-Status und Inhalt, nicht diese Anzeige.
Erkläre dir zum Abschluss, warum 200 OK allein keine Sicherheit belegt und ein Healthcheck allein keine funktionierende Fachfunktion beweist. Dies dient deinem Verständnis; eine schriftliche Abgabe ist nicht nötig.
Zusammenfassung
Du hast mit curl und curl -i eine HTTP-Antwort gelesen, eine erfolgreiche Anfrage von einer sicheren Antwort unterschieden und offengelegte Felder einem booleschen Konfigurationsschalter zugeordnet. Nach Speichern und Neustart von DeskLite hast du Status, Healthcheck und Ticketzugriff ohne interne Diagnosen bestätigt.
Du hast die tatsächliche Konfiguration und den laufenden Dienst einschließlich eines weiteren Neustarts geprüft. Dieser kleine Ablauf verbindet Entwicklungseinstellungen, Betriebsverhalten und Sicherheitsprüfung. Die folgende Challenge überträgt dieselben Fähigkeiten auf einen weiteren vorbereiteten Dienst.
