Einführung
Eine vorübergehende Debug-Einstellung ist in einer neuen DeskLite-Dienstversion zurückgekehrt. Anfragen sind weiterhin erfolgreich, aber die Betriebsprotokolle enthalten jetzt unechte Zugangsdaten. Eine reine Funktionsprüfung auf Erfolg hat diese Regression nicht erkannt.
Du verfolgst echte Anfragenachweise, stoppst neue Offenlegungen, ersetzt die offengelegten Zugangsdaten und ergänzt eine Assertion, die einen tatsächlich undichten Kandidaten blockiert. Historische Protokolle bleiben als Nachweis erhalten; ein Untersuchungsdokument ist nicht erforderlich. Lokale ausstellende Instanz, Client, Dienst, Vergleichsimplementierungen und Artefakthilfsprogramme sind vorbereitet.
Das echte Vorfallsereignis finden
In diesem Schritt verknüpfst du eine Anfrage mit der aktuellen Protokollierungsversion und Konfiguration.
cd /srv/ticket-regression
tail -n 5 liest die letzten fünf Zeilen und hält die Ansicht klein. Verwende deinen erlaubten Administrator-Lesezugriff für das vorbereitete Dienstprotokoll:
sudo tail -n 5 /opt/labex-ticket-regression/requests.log
Suche nach request_id=initial-001, version=logging-v2, path=/tickets und status=200. Diese historische Anfrage war erfolgreich, aber dieselbe Zeile enthält Authorization und das alte fiktive Token. Alle Werte gehören ausschließlich zu diesem isolierten Lab.
grep gibt Zeilen aus, die ein angegebenes Textmuster enthalten. Einfache Anführungszeichen halten dieses wörtliche Muster zusammen:
sudo grep 'request_id=initial-001' /opt/labex-ticket-regression/requests.log
cat logging.conf
include_authorization = true erklärt das sensible Feld. Zeit, Anfrage-ID, Version und Status des Ereignisses verknüpfen das beobachtete Verhalten mit der aktiven Konfiguration. Behalte das ursprüngliche Protokoll bei; es zu löschen würde Nachweise entfernen, statt künftige Offenlegungen zu verhindern.
Sensible Felder in neuen Ereignissen stoppen
In diesem Schritt änderst du die Protokollierungsregel und behältst nützliche Auditfelder bei.
nano logging.conf
Verwende:
[logging]
include_authorization = false
Speichere mit Ctrl+O, Enter und Ctrl+X. Übernimm die gespeicherte Konfiguration mit dem vorbereiteten Neustartbefehl:
bash restart.sh
Gib einer neuen Zustandsanfrage eine bekannte ID. X-Request-ID ist ein Anfrageheader zur Zuordnung ihres neuen Ereignisses:
curl -H 'X-Request-ID: after-policy-fix' http://127.0.0.1:8080/health
sudo grep 'request_id=after-policy-fix' /opt/labex-ticket-regression/requests.log
Erwartet werden Zeit, Version, ID, Pfad und status=200, ohne Feld Authorization. Das alte Ereignis initial-001 bleibt erhalten. Beurteile neue Ereignisse anhand ihrer eigenen IDs, statt von jeder historischen Zeile Geheimnisfreiheit zu verlangen.
Die offengelegten Zugangsdaten widerrufen und ersetzen
In diesem Schritt entziehst du dem alten Token mit dem bereits erlernten Ausstellungsablauf seine Zugriffsberechtigung.
Die Protokollierungsregel zu ändern macht einen offengelegten Wert nicht ungültig. Widerrufe seine Verwaltungs-ID:
course-token revoke legacy
curl -i -H 'Authorization: Bearer labex_012345abcdefghijklmnopqrstuvwxyz' http://127.0.0.1:8080/tickets
Erwartet wird 401. Stelle jetzt den Ersatz aus, ohne ihn auszugeben:
course-token issue /srv/ticket-regression/api.token
Schütze ihn mit dem Administrator-/Clientgruppenmuster aus den Berechtigungs- und Token-Labs:
sudo chown root:deskclient api.token
sudo chmod 640 api.token
Die ausstellende Instanz hat den Wert erzeugt; du legst nur seinen Zugriff fest. Kopiere ihn weder in den Testquellcode noch in das Clientskript oder einen schriftlichen Bericht.
Den dateilesenden Client wiederherstellen
In diesem Schritt stellst du den vorhandenen Client auf den geschützten Ersatz um.
nano sender.sh
Speichere dieselbe zuvor erlernte dateilesende Form:
#!/bin/bash
exec sudo -u deskclient /usr/bin/python3 /opt/labex-ticket-regression/send.py --token-file /srv/ticket-regression/api.token
Verwende Ctrl+O, Enter, Ctrl+X.
bash sender.sh
Erwartet werden HTTP 200 und das ursprüngliche Ticket Printer offline. Lies die jüngsten Betriebsereignisse:
sudo tail -n 5 /opt/labex-ticket-regression/requests.log
Die neue erfolgreiche Anfrage behält Auditfelder ohne Zugangsdatenwert bei. Ein alter offengelegter Wert kann in der erhaltenen Vorfallshistorie bleiben, während seine Zugriffsberechtigung entzogen wurde. Diese Unterscheidung vermeidet sowohl das Löschen von Nachweisen als auch die falsche Annahme, die alte Offenlegung sei weiterhin ein erfolgreicher Authentifizierungsweg.
Verstehen, warum der vorhandene Test die Offenlegung übersehen hat
In diesem Schritt untersuchst du die kleine Testvorlage, bevor du die neue Anforderung ergänzt.
cat test_security.py
Der positive Test verwendet die Anfragevorlage aus dem Lab zum Schreiben von Tests. Das vorbereitete Hilfsprogramm api stellt token aus der Zugangsdatenquelle des Ziels bereit und liefert den echten HTTP-Status, Antwortinhalt und das tatsächliche Protokollereignis dieser Anfrage zurück. "Bearer " + token verbindet zwei Zeichenfolgen zu einem Headerwert; der Wert wird nicht in den Quellcode kopiert.
Zwei separate Vergleichsimplementierungen verwenden das öffentliche unechte Testtoken: good lässt sensible Protokollfelder weg, während logging-regression das Testtoken absichtlich protokolliert. Sie verwenden deinen neuen Ersatz für den Betrieb nicht und legen ihn nicht offen.
course-regression-tests good
course-regression-tests logging-regression
Beide bestehen derzeit test_valid_token: Status und Geschäftsdaten bleiben in beiden Implementierungen korrekt. Die fehlende Anforderung betrifft das echte Ereignis in response["log"]. Jede Hilfsanfrage verwendet eine eindeutige ID, sodass das zurückgegebene Protokoll zu dieser neuen Anfrage gehört und nicht zu einem unbeteiligten historischen Ereignis.
Eine echte Assertion zur Protokollmaskierung ergänzen
In diesem Schritt erweiterst du den Test um Anforderungen sowohl an das Fehlen als auch an das Vorhandensein von Inhalten im neuen Ereignis.
Python prüft mit in, ob eine Zeichenfolge in einer anderen vorkommt. not in verlangt, dass sie fehlt. Dies sind Assertions über den tatsächlich zurückgegebenen Protokolltext, keine manuell bereitgestellte Nachweisdatei.
nano test_security.py
Behalte den positiven Test bei und verwende diese vollständige Datei:
from api import request, token
def test_valid_token():
response = request("/tickets", {"Authorization": "Bearer " + token})
assert response["status"] == 200
assert response["body"] == {"tickets": [{"id": 1, "title": "Printer offline"}]}
def test_log_is_redacted():
response = request("/tickets", {"Authorization": "Bearer " + token})
assert response["status"] == 200
assert "Authorization" not in response["log"]
assert token not in response["log"]
assert "request_id=" in response["log"]
assert "path=/tickets" in response["log"]
assert "status=200" in response["log"]
Speichere mit Ctrl+O, Enter, Ctrl+X. Der neue Test lehnt das sensible Feld und den Zugangsdatenwert ab und verlangt zugleich Anfrage-ID, Geschäftspfad und erfolgreichen Status. Das Protokoll zu leeren würde diese positiven Anforderungen verletzen.
Das Hilfsprogramm stellt intern ein zielspezifisches Token bereit. Normale Diensttests lesen den geschützten Ersatz; Vergleichsimplementierungen verwenden den öffentlichen unechten Testwert. Keiner der beiden Werte gehört in diese Testdatei.
Nachweisen, dass der Test die bekannte Regression erkennt
In diesem Schritt prüfst du die neue Assertion anhand sicheren und absichtlich undichten Verhaltens.
course-regression-tests good
Erwartet wird, dass beide Tests bestehen.
course-regression-tests logging-regression
Erwartet wird, dass nur test_log_is_redacted mit AssertionError fehlschlägt und den Exit-Status 1 liefert. Das ist eine beabsichtigte Erkennung, keine Aufforderung zum Abschwächen der Assertion. Der positive Geschäftstest muss weiterhin bestehen.
course-regression-tests live
Beide sollten für deinen tatsächlich korrigierten Dienst bestehen. Diese Tests untersuchen nur ihre neuen Anfrageereignisse; das ursprüngliche historische Ereignis mit der Offenlegung bleibt absichtlich erhalten. Ein Syntaxfehler, Verbindungsfehler oder bedingungsloser Fehlschlag würde keine wirksame Testabdeckung der Maskierung nachweisen.
Den neuen Test mit der Kandidatenauslieferung verbinden
In diesem Schritt verhinderst du die Auslieferung eines künftigen Kandidaten, wenn die neue Assertion fehlschlägt.
Die vorbereitete Freigabeprüfung verwendet dieselbe Prüf-/Build-/Test-/Bereitstellungsstruktur wie das vorherige Freigabe-Lab. build.sh verpackt den ursprünglichen Server und die aktuelle Protokollierungsregel und startet dann diesen tatsächlichen Kandidaten auf einem separaten lokalen Port. Das vorhandene test.sh prüft sein Verhalten bei gültigem/fehlendem/falschem Token; es prüft keine Protokolle.
nano gate.sh
Ergänze den Regressionsaufruf nach dem Build und vor den vorhandenen Funktionstests. Verwende:
#!/bin/bash
bash checks.sh
status=$?
if [ "$status" -eq 1 ]; then
exit 1
fi
if [ "$status" -ne 0 ]; then
exit 2
fi
bash build.sh || exit 2
bash regression.sh candidate || exit 2
bash test.sh || exit 2
bash deploy.sh
Speichere mit Ctrl+O, Enter, Ctrl+X. candidate wählt die tatsächliche gerade gebaute Anwendung aus, sodass die ergänzte Assertion das zur Bereitstellung anstehende Artefakt schützt. || exit 2 stoppt die Auslieferung, wenn dessen Tests fehlschlagen.
bash gate.sh
Erwartet werden die Zugangsdaten-Vorprüfung, der tatsächliche Kandidaten-Build, bestandene neue Regressionstests, bestandene Funktionstests und die Bereitstellung dieses Kandidaten auf dem lokalen Betriebsport. Eine ungenutzte Testdatei lediglich liegen zu lassen würde diesen Schutz nicht bieten.
Neue Ereignisse und erhaltene Historie bestätigen
In diesem Schritt prüfst du das ausgelieferte Verhalten und denkst über die Nachweise nach, ohne eine Berichtsdatei zu schreiben.
bash sender.sh
sudo tail -n 5 /opt/labex-ticket-regression/requests.log
Neue Betriebsereignisse müssen Zeit, tatsächlich ausgelieferte Version, Anfrage-IDs, Pfade und Statuswerte ohne Zugangsdaten erhalten. Die ausgelieferte Version ist jetzt ein Artefakt-Hash statt der ursprünglichen Bezeichnung logging-v2.
sudo grep 'request_id=initial-001' /opt/labex-ticket-regression/requests.log
Das ursprüngliche Vorfallsereignis existiert weiterhin. Sein altes Token ist widerrufen; der geschützte Ersatz funktioniert. Die separate absichtliche Regression ist ein Lehrvergleich, nicht der bereitgestellte Dienst.
Erkläre dir selbst: Welches Ereignis hat das Problem gezeigt, welche Einstellung hat es verursacht, warum reichte die Korrektur der Regel allein nicht aus, und wie verhindert die neue Kandidaten-Assertion ein erneutes Auftreten? Die Kursprüfung testet einen tatsächlich regressiven Kandidaten, bestätigt seine Blockierung durch die Freigabeprüfung und überprüft, dass das zuvor sichere laufende Artefakt erhalten bleibt. Ein Untersuchungsdokument mit festem Format ist nicht erforderlich.
Zusammenfassung
Du hast ein echtes Vorfallsereignis mit seiner Protokollierungsregel verknüpft, neue Offenlegungen gestoppt, die offengelegten Zugangsdaten widerrufen und ersetzt und historische Nachweise erhalten. Eine neue Assertion erkennt die absichtliche Regression und läuft für den tatsächlichen Kandidaten innerhalb der Auslieferungsfreigabe. So bleibt das sichere laufende Verhalten erhalten, wenn ein künftiger Kandidat fehlschlägt.
