Introdução
Uma configuração temporária de depuração voltou em uma nova versão do serviço DeskLite. As requisições continuam funcionando, mas os logs operacionais agora incluem uma credencial falsa. Uma verificação apenas de sucesso funcional não detectou essa regressão.
Você acompanhará evidências reais de requisições, interromperá novos vazamentos, substituirá a credencial exposta e adicionará uma asserção que bloqueia um candidato que realmente vaza dados. Os logs históricos permanecem como evidência; não é necessário criar um documento de investigação. O emissor local, o cliente, o serviço, os controles de comparação e os auxiliares de artefatos estão preparados.
Localize o evento real do incidente
Nesta etapa, você correlacionará uma requisição com a versão e a configuração atuais dos logs.
cd /srv/ticket-regression
tail -n 5 lê as últimas cinco linhas, mantendo a visualização pequena. Use sua leitura de administrador autorizada para o log do serviço preparado:
sudo tail -n 5 /opt/labex-ticket-regression/requests.log
Localize request_id=initial-001, version=logging-v2, path=/tickets e status=200. Essa requisição histórica foi bem-sucedida, mas a mesma linha inclui Authorization e o token fictício antigo. Todos os valores pertencem apenas a este laboratório isolado.
grep imprime linhas que contêm um padrão de texto fornecido. As aspas simples mantêm este padrão literal unido:
sudo grep 'request_id=initial-001' /opt/labex-ticket-regression/requests.log
cat logging.conf
include_authorization = true explica o campo sensível. O horário, o ID da requisição, a versão e o status do evento relacionam o comportamento observado à configuração ativa. Preserve o log original; apagá-lo removeria evidências, não impediria vazamentos futuros.
Interrompa os campos sensíveis em novos eventos
Nesta etapa, você alterará a política de logs, preservando campos úteis de auditoria.
nano logging.conf
Use:
[logging]
include_authorization = false
Salve com Ctrl+O, Enter e Ctrl+X. Aplique a configuração salva usando o ponto de entrada preparado de reinicialização:
bash restart.sh
Dê a uma nova requisição de integridade um ID conhecido. X-Request-ID é um cabeçalho de requisição usado para correlacionar seu novo evento:
curl -H 'X-Request-ID: after-policy-fix' http://127.0.0.1:8080/health
sudo grep 'request_id=after-policy-fix' /opt/labex-ticket-regression/requests.log
Espere horário, versão, ID, caminho e status=200, sem o campo Authorization. O evento antigo initial-001 permanece. Avalie os novos eventos por seus próprios IDs, em vez de exigir que todas as linhas históricas estejam livres de segredos.
Revogue e substitua a credencial exposta
Nesta etapa, você removerá a autoridade do token antigo usando o fluxo do emissor já aprendido.
Alterar a política de logs não invalida um valor exposto. Revogue seu ID de gerenciamento:
course-token revoke legacy
curl -i -H 'Authorization: Bearer labex_012345abcdefghijklmnopqrstuvwxyz' http://127.0.0.1:8080/tickets
Espere 401. Agora emita a credencial substituta sem imprimi-la:
course-token issue /srv/ticket-regression/api.token
Proteja-a usando o padrão de administrador/grupo do cliente dos laboratórios de permissões e tokens:
sudo chown root:deskclient api.token
sudo chmod 640 api.token
O emissor criou o valor; você apenas definiu seu acesso. Não o copie para o código-fonte dos testes, o script do cliente nem um relatório escrito.
Restaure o cliente que lê o arquivo
Nesta etapa, você fará o cliente existente usar a credencial substituta protegida.
nano sender.sh
Salve a mesma forma de leitura de arquivo ensinada anteriormente:
#!/bin/bash
exec sudo -u deskclient /usr/bin/python3 /opt/labex-ticket-regression/send.py --token-file /srv/ticket-regression/api.token
Use Ctrl+O, Enter, Ctrl+X.
bash sender.sh
Espere HTTP 200 e o ticket original Printer offline. Leia os eventos operacionais recentes:
sudo tail -n 5 /opt/labex-ticket-regression/requests.log
A nova requisição bem-sucedida preserva os campos de auditoria sem um valor de credencial. Um valor antigo vazado pode permanecer no histórico preservado do incidente enquanto sua autoridade foi removida. Essa distinção evita tanto excluir evidências quanto tratar uma exposição antiga como um caminho de autenticação que continua funcionando.
Veja por que o teste existente não detectou o vazamento
Nesta etapa, você inspecionará o pequeno modelo de teste antes de adicionar o novo requisito.
cat test_security.py
O teste positivo usa o modelo de requisição do laboratório de escrita de testes. O auxiliar preparado api fornece token a partir da fonte de credenciais do alvo e retorna o status HTTP real, o corpo e o evento de log real daquela requisição. "Bearer " + token une duas strings em um valor de cabeçalho; o valor não é copiado para o código-fonte.
Dois controles separados usam o token público falso de teste: good omite campos sensíveis de log, enquanto logging-regression registra deliberadamente o token de teste. Eles não usam nem expõem sua nova credencial substituta operacional.
course-regression-tests good
course-regression-tests logging-regression
Atualmente, ambos passam em test_valid_token: o status e os dados de negócio permanecem corretos em qualquer uma das implementações. O requisito ausente diz respeito ao evento real em response["log"]. Cada requisição do auxiliar usa um ID único, portanto o log retornado pertence àquela nova requisição, não a um evento histórico não relacionado.
Adicione uma asserção real de remoção de dados sensíveis do log
Nesta etapa, você ampliará o teste com requisitos de ausência e de presença para o novo evento.
O in do Python verifica se uma string ocorre dentro de outra. not in exige que ela esteja ausente. Essas são asserções sobre o texto real do log retornado, não sobre um arquivo de evidências fornecido manualmente.
nano test_security.py
Preserve o teste positivo e use este arquivo completo:
from api import request, token
def test_valid_token():
response = request("/tickets", {"Authorization": "Bearer " + token})
assert response["status"] == 200
assert response["body"] == {"tickets": [{"id": 1, "title": "Printer offline"}]}
def test_log_is_redacted():
response = request("/tickets", {"Authorization": "Bearer " + token})
assert response["status"] == 200
assert "Authorization" not in response["log"]
assert token not in response["log"]
assert "request_id=" in response["log"]
assert "path=/tickets" in response["log"]
assert "status=200" in response["log"]
Salve com Ctrl+O, Enter, Ctrl+X. O novo teste rejeita o campo sensível e o valor da credencial, exigindo ao mesmo tempo o ID da requisição, o caminho de negócio e o status de sucesso. Esvaziar o log faria esses requisitos positivos falharem.
O auxiliar fornece internamente um token específico para o alvo. Os testes normais do serviço leem a credencial substituta protegida; os controles de comparação usam o dado público falso de teste. Nenhum dos valores deve estar neste arquivo de teste.
Comprove que o teste detecta a regressão conhecida
Nesta etapa, você validará a nova asserção contra um comportamento seguro e outro que vaza dados deliberadamente.
course-regression-tests good
Espere que ambos os testes passem.
course-regression-tests logging-regression
Espere que apenas test_log_is_redacted falhe com AssertionError, retornando código de saída 1. Essa é uma detecção intencional, não um pedido para enfraquecer a asserção. O teste positivo de negócio deve continuar passando.
course-regression-tests live
Ambos devem passar contra seu serviço real corrigido. Esses testes inspecionam apenas os eventos de suas novas requisições; o evento histórico original com vazamento é mantido intencionalmente. Um erro de sintaxe, um erro de conexão ou uma falha incondicional não demonstraria cobertura eficaz da remoção de dados sensíveis.
Conecte o novo teste à entrega do candidato
Nesta etapa, você impedirá que um candidato futuro seja entregue quando a nova asserção falhar.
O controle preparado usa a mesma estrutura de verificação/construção/teste/implantação do laboratório anterior de controle de entrega. build.sh empacota o servidor original e a política atual de logs e depois inicia esse candidato real em uma porta local separada. O test.sh existente verifica seu comportamento com tokens válidos/ausentes/incorretos; ele não verifica os logs.
nano gate.sh
Adicione a chamada de regressão após a construção e antes dos testes funcionais existentes. Use:
#!/bin/bash
bash checks.sh
status=$?
if [ "$status" -eq 1 ]; then
exit 1
fi
if [ "$status" -ne 0 ]; then
exit 2
fi
bash build.sh || exit 2
bash regression.sh candidate || exit 2
bash test.sh || exit 2
bash deploy.sh
Salve com Ctrl+O, Enter, Ctrl+X. candidate seleciona o aplicativo real recém-construído, portanto a asserção adicionada protege o artefato prestes a ser implantado. || exit 2 interrompe a entrega se seus testes falharem.
bash gate.sh
Espere a verificação preliminar da credencial, a construção real do candidato, a aprovação dos novos testes de regressão, a aprovação dos testes funcionais e a implantação desse candidato na porta local operacional. Apenas deixar um arquivo de teste sem uso não forneceria essa prevenção.
Confirme os novos eventos e o histórico preservado
Nesta etapa, você verificará o comportamento entregue e refletirá sobre as evidências sem escrever um arquivo de relatório.
bash sender.sh
sudo tail -n 5 /opt/labex-ticket-regression/requests.log
Os novos eventos operacionais devem preservar horário, versão real entregue, IDs de requisições, caminhos e status sem credenciais. A versão entregue agora é um hash de artefato em vez do rótulo original logging-v2.
sudo grep 'request_id=initial-001' /opt/labex-ticket-regression/requests.log
O evento original do incidente ainda existe. Seu token antigo está revogado; a credencial substituta protegida funciona. O controle separado de regressão deliberada é uma comparação de ensino, não o serviço implantado.
Explique para si: qual evento revelou o problema, qual configuração o causou, por que corrigir apenas a política foi insuficiente e como a nova asserção do candidato impede a recorrência. A verificação do curso exercita um candidato com uma regressão real, confirma que o controle o bloqueia e verifica se o artefato anteriormente seguro em execução sobrevive. Não é necessário criar um documento de investigação com formato fixo.
Resumo
Você relacionou um evento real do incidente à sua política de logs, interrompeu novos vazamentos, revogou e substituiu a credencial exposta e preservou as evidências históricas. Uma nova asserção detecta a regressão deliberada e executa no candidato real dentro do controle de entrega, preservando o comportamento seguro em execução quando um candidato futuro falha.
