소개
배송 연동은 대기 중인 주문을 읽고 배송 업데이트를 게시합니다. 현재 저장소 예제는 깨끗해 보이지만 삭제한 API 키가 여전히 접근을 허용할 수 있습니다. 여러분은 유출을 차단하고 대기 중인 배송 실행을 복구할 책임이 있습니다.
가이드 실습에서 배운 Git 조사, 대상 키 폐기, 권한 선택, 비공개 설정, 업무 검증을 적용하세요. 무관한 모니터를 유지하면서 배송 결과를 완료합니다. 챌린지는 자체 사전 구성 환경에서 시작합니다.
배송 연동 복구
현재 상황
배송팀은 준비된 worker로 대기 주문을 읽고 배송 업데이트를 게시합니다. 예를 들어 묶음 처리 후 주문 O-201은 ready 상태가 되어야 합니다. 현재 예제에서 키가 삭제되었지만 경고에 따르면 이력에서 찾을 수 있습니다. dispatch 묶음은 대기 중입니다. 독립적인 가용성 모니터는 계속 작동해야 하며 차단 중 배송 작업의 일시 정지는 허용됩니다.
로컬 교육용 제공자, Git 방법, 관리 UI, INI 형식, 두 터미널 역할은 가이드 실습과 같습니다. 가상 환경이며 외부 계정은 필요하지 않습니다.
이전 실습이 아닌 현재 VM의 자격 증명을 사용하세요. 가이드 실습처럼 이 제공자는 무효하거나 폐기된 키에 401, 유효하지만 필요한 권한이 없는 키에 403, 수락한 읽기에 200을 사용합니다. worker는 호출마다 비공개 파일을 읽으므로 재시작할 필요가 없습니다.
범위
- Workstation은
/home/labex/project/repository에서 열립니다. 세 커밋과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 자체는 접근 가능합니다. - 설정된 대체 키는 활성 상태이고 이전 키와 다르며 배송 업무 권한 두 개만 가집니다.
/home/labex/project/runtime/job.ini는keyworker소유, 모드600이며 해당 서비스 계정이 읽을 수 있습니다. 새 비밀값은 저장소 파일과 커밋 어디에도 없습니다.- 변경되지 않은 worker가 설정된 대체 키로 지정된
dispatch를 읽고, 수신 API가 같은 대체 키 ID로O-201과O-202를 각각ready상태로 수락했습니다. - 대체 키의 고객 디렉터리 접근은
403입니다. 변경되지 않은 모니터 자격 증명으로 상태 확인 엔드포인트에 접근하면 계속200입니다.
힌트
삭제한 비밀값은 어디에 남을까요?
현재 예제와 이전 커밋을 비교하세요. 과거 키 ID와 관리 화면 기록을 연결하세요. 표시 이름만으로는 자격 증명을 식별하지 못합니다.
유효한 대체 키가 왜 계속 실패할까요?
worker는 입력 요청과 출력 요청을 모두 수행합니다. 엔드포인트 표로 권한 부족과 잘못되거나 폐기된 비밀값을 구분하세요. 셸 변수는 비공개 런타임 파일을 업데이트하지 않습니다.
어떤 증거가 복구를 입증할까요?
데모 실행이나 터미널 메시지만으로는 부족합니다. 수신 API의 지정 묶음을 보고 키 ID를 설정된 대체 키와 비교하세요. 준비된 worker는 변경하지 마세요.
요약
지원 요약 작업의 사고 대응을 배송 연동으로 확장했습니다. 완전한 대응은 과거 비밀값을 무효화하고 제한된 전용 자격 증명으로 실제 업무를 복구하며, 비밀값을 버전 관리 밖에 두고 무관한 서비스 접근을 유지하는 것입니다.
