Die Versandintegration absichern

Einführung

Eine Versandintegration liest ausstehende Bestellungen und veröffentlicht Versandaktualisierungen. Ihr aktuelles Repository-Beispiel sieht sauber aus, doch ein entfernter API-Schlüssel könnte weiter Zugriff gewähren. Du sollst die Offenlegung eindämmen und den ausstehenden Versandlauf wiederherstellen.

Nutze die Git-Untersuchung, den gezielten Widerruf, die Scope-Auswahl, private Konfiguration und Geschäftsprüfung aus den angeleiteten Labs. Schließe das Versandergebnis ab und erhalte den unabhängigen Monitor. Die Challenge startet in einer eigenen vorbereiteten Umgebung.

Die Versandintegration wiederherstellen

Aktuelle Situation

Das Versandteam verwendet einen vorbereiteten Worker, der ausstehende Bestellungen liest und Versandaktualisierungen veröffentlicht. Beispielsweise soll O-201 nach der Stapelverarbeitung den Status ready erhalten. Ein Schlüssel wurde aus dem aktuellen Beispiel entfernt, ist laut Warnung aber noch im Verlauf abrufbar. Der Stapel dispatch steht aus. Ein unabhängiger Verfügbarkeitsmonitor muss weiterarbeiten; der Versand darf während der Eindämmung kurz pausieren.

Lokaler Übungsanbieter, Git-Methoden, Manager-Oberfläche, INI-Format und beide Terminalrollen entsprechen den angeleiteten Labs. Die Umgebung ist synthetisch und benötigt kein externes Konto.

Verwende die Zugangsdaten dieser VM, nicht die eines früheren Labs. Wie in den angeleiteten Labs nutzt dieser Anbieter 401 für ungültige oder widerrufene Schlüssel, 403 für gültige Schlüssel ohne nötigen Scope und 200 für angenommene Leseanfragen. Der Worker liest die private Datei bei jedem Aufruf; ein Neustart ist unnötig.

Umfang

• Workstation öffnet /home/labex/project/repository. Seine drei Commits und shipping-example.ini enthalten historische Hinweise. Das aktuelle Beispiel ist keine Laufzeitkonfiguration.
• Integration läuft als keyworker in /home/labex/project. Die private Konfiguration heißt runtime/job.ini; der unverändert zu belassende Worker /opt/keylab/worker.py nimmt einen Stapelnamen als Argument.
• Die API liegt unter http://127.0.0.1:8000. Key Manager verwaltet Zugangsdaten mit dem Operator-Token aus /home/labex/.config/keylab/operator-token.
• Der unabhängige Monitor nutzt lab_key_monitor_only für GET /v1/health.

Dein Ziel

Die historisch offengelegten Zugangsdaten gewähren keinen API-Zugriff mehr. Der unveränderte Versand-Worker nutzt einen anderen, eigenen Ersatz in der privaten Laufzeitkonfiguration; der Empfänger enthält das vollständige dispatch-Ergebnis unter diesem Ersatz. Der Ersatz kann nicht auf das Kundenverzeichnis zugreifen, und der unabhängige Monitor bleibt gesund.

Abnahmekriterien

• Der historische Schlüssel ist widerrufen und erhält 401 beim Bestellzugriff, während die API erreichbar bleibt.
• Der konfigurierte Ersatz ist aktiv, unterscheidet sich vom alten Schlüssel und besitzt genau die beiden geschäftlichen Versand-Scopes.
• /home/labex/project/runtime/job.ini gehört keyworker, hat Modus 600 und ist für dieses Dienstkonto lesbar. Der neue Geheimwert steht weder in Repository-Dateien noch in dessen Commits.
• Der unveränderte Worker hat den zugewiesenen Stapel dispatch mit dem konfigurierten Ersatz gelesen; die API hat O-201 und O-202 jeweils mit Status ready unter derselben Ersatz-ID angenommen.
• Der Ersatz erhält 403 beim Kundenzugriff. Die unveränderten Monitor-Zugangsdaten erhalten weiterhin 200 vom Health-Endpoint.

Hinweise

Zusammenfassung

Du hast die Vorfallreaktion von einem Support-Auftrag auf eine Versandintegration übertragen. Eine vollständige Reaktion macht den historischen Geheimwert ungültig, stellt den echten Geschäftsvorgang mit eigenen eingeschränkten Zugangsdaten wieder her, hält Geheimwerte aus der Versionsverwaltung heraus und erhält unabhängigen Dienstzugriff.