はじめに
出荷連携は保留中の注文を読み、出荷更新を公開します。現在のサンプルは安全に見えても、削除された API キーがまだアクセスを許す可能性があります。あなたは漏えいを封じ込め、保留中の出荷実行を復旧する担当です。
ガイド付きラボで練習した Git 調査、対象を絞った失効、スコープ選択、非公開設定、業務検証を適用します。無関係な監視を維持しつつ出荷結果を完了してください。チャレンジは独自の準備済み環境で始まります。
出荷連携を復旧する
現在の状況
出荷チームは、保留中の注文を読み出荷更新を公開する準備済み worker を使います。たとえばバッチ処理後、注文 O-201 は状態 ready になるはずです。現在のサンプルからキーは削除されましたが、警告では履歴から取得できるとされています。dispatch は未処理です。独立した可用性監視は継続必須ですが、封じ込め中は出荷処理を一時停止できます。
ローカル教材サービス、Git 手法、管理 UI、INI 形式、2 つのターミナル役割はガイド付きラボと同じです。架空の環境であり外部アカウントは不要です。
前のラボではなく、この VM の認証情報を使ってください。ガイド付きラボと同様、無効・失効済みキーは 401、有効でも必要なスコープがないキーは 403、受理された読み取りは 200 です。worker は毎回非公開ファイルを読むため、再起動は不要です。
対象範囲
- Workstation は
/home/labex/project/repositoryで開きます。3 つのコミットとshipping-example.iniに過去の証拠があります。現在のサンプルは実行時設定ではありません。 - Integration は
/home/labex/projectでkeyworkerとして動きます。非公開設定はruntime/job.ini、変更禁止の worker は/opt/keylab/worker.pyで、バッチ名を引数に取ります。 - API は
http://127.0.0.1:8000です。Key Manager は/home/labex/.config/keylab/operator-tokenのトークンで認証情報を管理します。 - 独立した監視は
lab_key_monitor_onlyでGET /v1/healthを使います。
| 操作 | 必要なスコープ | 業務の目的 |
|---|---|---|
GET /v1/orders |
orders:read |
保留中の注文を読む |
POST /v1/shipment-updates |
shipment-updates:write |
出荷状態を公開する |
GET /v1/results |
orders:read |
受信済みバッチ結果を見る |
GET /v1/customers |
customers:read |
無関係な顧客ディレクトリ |
GET /v1/health |
health:read |
独立した監視 |
目標
過去に漏えいした認証情報では API にアクセスできません。変更されていない出荷 worker が非公開実行時設定内の別の専用キーを使い、受信サービスにその代替キーで完全な dispatch 結果が保存されています。代替キーは顧客ディレクトリにアクセスできず、無関係な監視は正常です。
合格条件
- 過去の漏えいキーは失効し、注文へのアクセスで
401が返り、API 自体は到達可能です。 - 設定された代替キーは有効で、古いキーと異なり、出荷業務用の 2 スコープだけを持ちます。
/home/labex/project/runtime/job.iniの所有者はkeyworker、モードは600で、このサービスアカウントが読めます。新しい秘密値はリポジトリのファイルにもコミットにも含まれません。- 変更されていない worker が設定された代替キーで指定の
dispatchを読み、受信 API が同じ代替キー ID で注文O-201とO-202をそれぞれ状態readyとして受け付けています。 - 代替キーによる顧客ディレクトリアクセスは
403、変更されていない監視用認証情報のヘルスアクセスは200です。
ヒント
削除した秘密値はどこに残りますか？
現在のサンプルを過去のコミットと比較します。過去のキー ID と管理画面の記録を照合してください。表示名だけでは認証情報を特定できません。
有効な代替キーでも失敗するのはなぜですか？
worker は入力と出力の両方のリクエストを送ります。表からスコープ不足と、誤った値・失効済みの値を区別します。シェル変数は非公開実行時ファイルを更新しません。
復旧を示す証拠は何ですか？
デモやターミナルメッセージだけでは不十分です。受信 API の指定バッチを見て、キー ID と設定された代替キーを比較します。準備済み worker は変更しません。
まとめ
インシデント対応をサポート集計から出荷連携へ応用しました。完全な対応には、過去の秘密値の無効化、専用の制限された認証情報での実業務の復旧、秘密値をバージョン管理外へ保存すること、無関係なサービスアクセスの維持が必要です。
