Proteger a integração de expedição

Introdução

Uma integração de expedição lê pedidos pendentes e publica atualizações de envio. Seu exemplo atual parece limpo, mas uma chave removida ainda pode dar acesso. Você deve conter a exposição e recuperar a execução de expedição pendente.

Aplique a investigação do Git, revogação direcionada, seleção de escopos, configuração privada e verificação de negócio dos laboratórios guiados. Complete o resultado de expedição preservando o monitor independente. O desafio começa em seu próprio ambiente preparado.

Recuperar a integração de expedição

Situação atual

A equipe de expedição usa um worker preparado para ler pedidos pendentes e publicar atualizações de envio. Por exemplo, o pedido O-201 deve receber estado ready após processar o lote. Uma chave foi removida do exemplo atual, mas um alerta indica que continua recuperável no histórico. O lote dispatch está pendente. Um monitor independente deve continuar funcionando; admite-se uma pausa temporária da expedição durante a contenção.

O provedor local, métodos do Git, interface de gestão, formato INI e dois papéis de terminal são os mesmos dos laboratórios guiados. O ambiente é sintético e dispensa conta externa.

Use as credenciais desta VM, não de um laboratório anterior. Como nos laboratórios guiados, este provedor usa 401 para chaves inválidas ou revogadas, 403 para chaves válidas sem o escopo necessário e 200 para leituras aceitas. O worker lê o arquivo privado em cada invocação; não precisa de reinício.

Escopo

Workstation abre em /home/labex/project/repository. Seus três commits e shipping-example.ini contêm as evidências históricas. O exemplo atual não é a configuração de execução.
Integration executa como keyworker em /home/labex/project. O arquivo privado é runtime/job.ini; o worker inalterado é /opt/keylab/worker.py, que aceita um nome de lote como argumento.
A API está em http://127.0.0.1:8000. Key Manager administra credenciais com o token de /home/labex/.config/keylab/operator-token.
O monitor independente usa lab_key_monitor_only com GET /v1/health.

Operação	Escopo necessário	Propósito de negócio
`GET /v1/orders`	`orders:read`	Ler pedidos pendentes
`POST /v1/shipment-updates`	`shipment-updates:write`	Publicar estados de envio
`GET /v1/results`	`orders:read`	Consultar lotes recebidos
`GET /v1/customers`	`customers:read`	Diretório independente de clientes
`GET /v1/health`	`health:read`	Monitor separado

Seu objetivo

A credencial historicamente exposta não concede mais acesso à API. O worker inalterado usa uma substituta distinta e dedicada em sua configuração privada, e o serviço receptor contém o resultado completo de dispatch sob essa substituta. O acesso ao diretório de clientes permanece indisponível para ela e o monitor independente está saudável.

Critérios de aceitação

A chave histórica foi revogada e recebe 401 ao acessar pedidos, enquanto a API continua acessível.
A substituta configurada está ativa, é diferente da chave exposta e tem exatamente os dois escopos de negócio de expedição.
/home/labex/project/runtime/job.ini pertence a keyworker, tem modo 600 e é legível por essa conta de serviço. O novo segredo não aparece em arquivos nem commits do repositório.
O worker inalterado leu o lote atribuído dispatch com a substituta configurada, e a API aceitou O-201 e O-202, ambos com estado ready, sob o mesmo ID substituto.
A substituta recebe 403 para o diretório de clientes. A credencial inalterada do monitor continua recebendo 200 do endpoint de saúde.

Dicas

Onde um segredo removido pode permanecer?

Compare o exemplo atual aos commits anteriores. Relacione o ID histórico ao registro do gestor; só o nome exibido não identifica a credencial.

Por que uma substituta válida ainda falha?

O worker faz uma requisição de entrada e outra de saída. Use a tabela para distinguir escopo insuficiente de segredo errado ou revogado. Uma variável do shell não atualiza o arquivo privado de execução.

Que evidência comprova a recuperação?

Uma demonstração ou mensagem no terminal não basta. Consulte o lote atribuído na API receptora e compare o ID da chave com a substituta configurada. Mantenha o worker preparado sem alterações.

Resumo

Você transferiu a resposta a incidentes de uma tarefa de suporte para uma integração de expedição. Uma resposta completa invalida o segredo histórico, restaura a operação real com uma credencial dedicada e restrita, mantém segredos fora do controle de versão e preserva acessos independentes ao serviço.