Restaurar uma tarefa com uma chave restrita

CibersegurançaBeginner
Pratique Agora

Introdução

A chave de suporte exposta foi revogada. O serviço está disponível, mas a tarefa de resumo não autentica porque sua configuração privada ainda contém o valor antigo. O lote pendente daily ainda precisa do resumo.

Você aprenderá escopos, emitirá uma substituta, atualizará a configuração privada do worker e concluirá uma execução real de negócio. Também testará que o diretório de clientes continua proibido e o monitor independente permanece saudável. Este laboratório oferece seu próprio estado após a contenção, sem reutilizar a VM anterior.

Testar uma credencial somente de leitura

Nesta etapa, você distinguirá uma credencial inválida de uma válida com permissões insuficientes. O ambiente novo começa após a contenção: key_support_old está revogada, a tarefa usa seu segredo antigo e daily não foi processado. Não precisa dos arquivos nem da VM do laboratório anterior. Chaves e tokens de operador pertencem a esta VM; obtenha os valores aqui em vez de reutilizar credenciais de outro ambiente.

Workstation é o terminal de manutenção em /home/labex/project/repository. Integration executa como keyworker em /home/labex/project. Key Manager é a interface de manutenção do provedor. A API local está em http://127.0.0.1:8000; seu comportamento sintético é específico deste curso.

Um escopo permite uma operação nomeada. Privilégio mínimo concede apenas operações necessárias à tarefa, deixando as demais indisponíveis. O programa lê tickets e publica resumos; não lê o diretório de clientes.

Operação Escopo necessário A tarefa precisa?
GET /v1/tickets tickets:read Sim: entrada
POST /v1/summaries summaries:write Sim: saída
GET /v1/customers customers:read Não
GET /v1/health health:read Não: monitor separado
GET /v1/results tickets:read Consultar resumos recebidos

Reconheça uma falha de permissão

Uma chave de demonstração somente de leitura é válida, mas não permite publicar. Em Workstation, envie uma requisição de publicação. curl -X POST escolhe a escrita; -H fornece cabeçalhos, -d o corpo JSON, -s oculta o progresso e -w mostra o estado. O objeto vazio {} basta, pois o provedor rejeita a permissão antes de validar o corpo: O cabeçalho Content-Type: application/json informa ao serviço que o corpo usa JSON.

curl -s -w '\nHTTP %{http_code}\n' -X POST -H 'Authorization: Bearer lab_demo_read_only' -H 'Content-Type: application/json' -d '{}' http://127.0.0.1:8000/v1/summaries
{"error":"Missing scope","required":"summaries:write"}
HTTP 403

Nesta API, 403 significa que houve autenticação, mas falta o escopo necessário. Já 401 rejeita a própria credencial. Uma chave de leitura não conclui uma tarefa de leitura e escrita; uma chave de acesso total permite demais. A substituta precisa dos dois escopos de negócio da tabela.

Emitir uma substituta dedicada

Nesta etapa, você emitirá uma substituta dedicada com os dois escopos escolhidos anteriormente. Guardará o segredo privadamente na próxima etapa. O nome é um rótulo útil; somente os escopos controlam as permissões.

Emita uma credencial dedicada

Em Workstation, imprima o token de operador com cat, que exibe um arquivo:

cat /home/labex/.config/keylab/operator-token

Em Key Manager, insira em Operator token, selecione Sign in e Open Key Manager. A autenticação de operador é separada das chaves de aplicação. Confirme que key_support_old já está Revoked.

Em Issue a key, preencha Name com Support summary replacement. Selecione somente tickets:read e summaries:write, depois Issue key. Aparecem um ID não secreto e Secret shown once. Copie o segredo que começa com lab_key_ antes de sair da página. O provedor armazena um hash, não um segredo recuperável. Um hash é uma impressão digital unidirecional: permite comparar um valor fornecido sem mostrar o original armazenado.

Se perder o valor, revogue a chave não usada pelo ID e emita outra. Não reutilize o valor exposto nem amplie permissões para corrigir um erro de cópia.

Salvar a configuração privada de execução

Nesta etapa, você salvará a substituta no arquivo privado da conta de serviço e verificará as permissões. Use Integration para todos os comandos abaixo.

A configuração de execução é o arquivo lido pelo programa ao funcionar. O worker lê /home/labex/project/runtime/job.ini a cada invocação, dispensando reinício. O exemplo do repositório é outro arquivo. Em Integration, veja a configuração atual:

cat /home/labex/project/runtime/job.ini
[integration]
api_key = lab_key_support_exposed

Mantenha segredos fora do repositório e do histórico de comandos. read do Bash aceita um valor em um prompt: -r preserva caracteres literais, -s oculta a entrada e -p imprime a mensagem. API_KEY é uma variável temporária do shell. Execute em Integration, cole o novo segredo quando solicitado e pressione Enter. A entrada fica oculta:

read -r -s -p 'Replacement key: ' API_KEY

printf escreve texto formatado. \n cria quebras de linha, %s insere o valor, aspas duplas o mantêm como um argumento e > substitui o arquivo indicado. O arquivo privado existente pertence a keyworker, a conta deste terminal:

printf '[integration]\napi_key = %s\n' "$API_KEY" > /home/labex/project/runtime/job.ini

Use chmod para definir permissões. O modo 600 permite leitura e escrita apenas ao proprietário; grupo e outras contas ficam sem acesso:

chmod 600 /home/labex/project/runtime/job.ini

ls -l mostra propriedade e permissões sem imprimir o segredo:

ls -l /home/labex/project/runtime/job.ini

Procure -rw------- e proprietário keyworker. Tamanho e data podem variar. Uma variável sozinha não atualiza o arquivo; salvar a configuração faz a próxima invocação usar a nova credencial.

Mantenha este terminal Integration aberto. API_KEY pertence a este shell, não a todos os terminais. A próxima etapa a utiliza para requisições independentes e depois a remove. Se fechar ou reconectar o terminal, repita esta etapa com o segredo atual de job.ini, mostrado pelo comando cat acima.

Concluir e verificar a execução de negócio

Nesta etapa, você processará daily e testará comportamentos permitidos e proibidos. O worker está preparado: mantenha /opt/keylab/worker.py inalterado. A tarefa é recuperar credenciais, não alterar o programa para contornar a autenticação.

Em Integration, execute o lote atribuído:

python3 /opt/keylab/worker.py daily
Read batch: daily (3 items)
{"batch":"daily","count":3,"subjects":["Reset password","Invoice copy","Delivery question"]}
Received batch: daily
Receiving key ID: ...

O ID receptor deve corresponder ao da substituta em Key Manager. Se ocorrer 401, confira se o segredo salvo corresponde à substituta ativa. Com 403, compare os escopos à tabela. Se necessário, revogue a substituta incorreta, emita outra adequada, atualize o arquivo privado e repita o lote. A repetição substitui o registro recebido em vez de criar resumos duplicados.

Inspecione o serviço receptor real

Continue no mesmo terminal Integration. A variável API_KEY da etapa anterior ainda está disponível; não é preciso digitar novamente o segredo exibido uma só vez.

Use o endpoint de resultados somente de leitura. Um pipeline | passa a resposta ao próximo programa; python3 -m json.tool executa o formatador JSON do Python com indentação legível:

curl -s -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/results | python3 -m json.tool

Encontre daily, seus três assuntos em payload e o key_id da substituta. O registro vem da API receptora, não de um arquivo local de sucesso. O backend também registra qual credencial leu os dados de origem.

Teste agora a requisição proibida ao diretório de clientes:

curl -s -w '\nHTTP %{http_code}\n' -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/customers
{"error":"Missing scope","required":"customers:read"}
HTTP 403

A rejeição esperada confirma a restrição. Use unset para remover a variável temporária quando não precisar mais dela; o arquivo de execução salvo permanece inalterado:

unset API_KEY

Em Workstation, confirme que a chave antiga continua inutilizável e o monitor está saudável:

curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' http://127.0.0.1:8000/v1/tickets
{"error":"Invalid or revoked key"}
HTTP 401
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_monitor_only' http://127.0.0.1:8000/v1/health
{"status":"ok","integration":"monitor"}
HTTP 200

Por fim, git status --short lista de forma compacta arquivos modificados ou não rastreados do repositório:

git status --short

O percurso guiado não produz saída, pois apenas o arquivo privado foi modificado. Nunca coloque a substituta em um exemplo ou commit. Como mostrou o primeiro laboratório, o histórico pode guardar segredos após desaparecerem suas linhas visíveis.

Resumo

Você distinguiu falha de autenticação de falta de permissão, escolheu escopos de leitura e escrita, guardou privadamente um segredo exibido uma só vez e concluiu o resumo pendente. Verificou o registro recebido, a rejeição da chave antiga, a proibição de acesso a clientes e a disponibilidade do monitor. Uma rotação útil restaura o trabalho legítimo e remove o acesso da credencial exposta.