Introdução
Uma aplicação pode funcionar corretamente e revelar informações de que seus usuários não precisam. O DeskLite já está em execução, mas sua resposta de status inclui detalhes internos de desenvolvimento. Você investigará essa resposta, alterará uma opção e confirmará que o serviço continua útil.
Basta saber navegar por diretórios e ler arquivos no terminal. Requisições, respostas HTTP, opções de configuração e o comando de reinicialização são apresentados conforme você os utiliza. Este é seu primeiro ciclo DevSecOps: observar um risco, corrigir sua causa e verificar segurança e funcionamento normal juntos.
Observar e Corrigir a Resposta de um Serviço
Nesta etapa, você lerá uma resposta do DeskLite, identificará detalhes internos desnecessários e corrigirá a opção que os expõe.
O DeskLite é uma pequena aplicação de suporte. A equipe precisa de informações sobre chamados e de uma indicação simples de que o serviço está funcionando, não de caminhos internos ou diagnósticos de desenvolvimento. Esses detalhes são as informações que queremos proteger; as pessoas que conseguem ler uma resposta formam seu público.
Um serviço é um programa que permanece em execução e responde a requisições. Uma requisição HTTP pede algo a um serviço web; a resposta contém um código de status e um corpo. Você usará curl pelo terminal, sem precisar de navegador ou conhecimentos de programação.
O serviço já está preparado e funcionando. Trabalhe somente em seu diretório:
cd /home/labex/project/desklite
Uma URL informa ao curl para onde enviar a requisição. Em http://127.0.0.1:8080/status, http é o protocolo, 127.0.0.1 representa esta máquina do laboratório, 8080 seleciona o serviço e /status seleciona um endpoint, uma resposta específica oferecida pelo serviço. Não é necessário configurar redes aqui.
curl http://127.0.0.1:8080/status
O corpo está em JSON: campos com nomes e valores entre chaves. Você precisa apenas lê-lo, não escrever um programa.
{
"service": "DeskLite",
"status": "running",
"internal_path": "/opt/labex-desklite/private/settings.ini",
"debug_details": "development diagnostics enabled"
}
service e status são úteis para o público previsto. internal_path revela um local interno de arquivo, e debug_details revela informações de desenvolvimento. Conhecer um caminho não concede automaticamente acesso ao arquivo, mas detalhes desnecessários podem ajudar alguém a planejar outras investigações. Isso é divulgação de informações.
Adicione a opção -i para incluir os cabeçalhos HTTP acima do corpo:
curl -i http://127.0.0.1:8080/status
A primeira linha contém 200 OK: a requisição foi bem-sucedida. Cabeçalhos como Content-Type: application/json descrevem o corpo; uma linha vazia separa as duas partes. As datas podem variar. Um status HTTP de sucesso não significa uma resposta segura — essa própria resposta bem-sucedida divulga informações.
Leia a configuração do serviço, o arquivo de ajustes usado pela aplicação:
cat service.conf
[service] agrupa as opções. Uma linha iniciada por # é um comentário explicativo. debug = true é uma opção booleana: true habilita os diagnósticos de desenvolvimento e false os desabilita. O comentário relaciona a opção aos campos de status expostos.
Aplicar a Correção de Configuração
Informações de depuração ajudam desenvolvedores a investigar problemas. Uma opção útil durante o desenvolvimento pode ser inadequada para um público que precisa apenas de um status público. DevSecOps inclui segurança no trabalho conjunto de desenvolvimento e operações: definir o que deve ser visível, alterar a configuração e testar o resultado em execução.
Abra a configuração com nano, um editor de texto para terminal. Use as setas para chegar à opção. Nos atalhos seguintes, mantenha Ctrl pressionada enquanto aperta a letra:
nano service.conf
Altere somente debug = true para debug = false. Mantenha o cabeçalho [service] e o comentário. Salve com Ctrl+O, Enter, e saia com Ctrl+X. Confira o arquivo salvo:
cat service.conf
Agora deve aparecer:
[service]
## Include development diagnostics in status responses.
debug = false
Um arquivo em disco e um programa em execução são coisas diferentes. Este serviço lê as opções ao iniciar, então apenas salvar não atualiza a resposta. O curso fornece restart.sh para aplicar a configuração sem você precisar gerenciar processos. bash executa esse script preparado; não é necessário editá-lo.
bash restart.sh
Saída esperada:
DeskLite restarted.
Solicite novamente o mesmo endpoint, incluindo os cabeçalhos:
curl -i http://127.0.0.1:8080/status
Espere 200 OK e este corpo:
{
"service": "DeskLite",
"status": "running"
}
Os dois campos internos desapareceram, e o status útil permanece. Se ainda estiverem presentes, confira se salvou service.conf e executou a reinicialização. Se o script informar um erro de configuração, restaure o cabeçalho e a grafia do booleano mostrados acima e tente novamente. Não substitua a aplicação nem interrompa o serviço para ocultar a resposta.
Verificar Segurança e Função de Negócio Juntas
Nesta etapa, você verificará se a correção permanece após outra reinicialização e se o DeskLite continua atendendo aos usuários.
Quebrar o serviço também eliminaria a resposta, mas removeria funções úteis. Precisamos de duas evidências: os campos sensíveis estão ausentes e o serviço legítimo funciona. Uma verificação de integridade indica prontidão básica; uma requisição de negócio testa a função realmente necessária aos usuários.
Reinicie mais uma vez para confirmar a aplicação da opção salva:
bash restart.sh
Confira novamente o status:
curl -i http://127.0.0.1:8080/status
Espere 200 OK, service e status, sem internal_path nem debug_details. Solicite agora o endpoint de integridade:
curl -i http://127.0.0.1:8080/health
Espere 200 OK e:
{
"status": "ok"
}
Por fim, solicite o endpoint de negócio:
curl -i http://127.0.0.1:8080/tickets
Espere 200 OK e o chamado original:
{
"tickets": [
{
"id": 1,
"title": "Printer offline"
}
]
}
Um processo saudável, sozinho, não prova que o acesso aos chamados funciona. Juntas, essas requisições mostram que a divulgação foi removida e a função prevista foi preservada. O curl também pode mostrar um indicador de transferência; avalie o status HTTP e o corpo, não esse indicador.
Antes de terminar, explique por que 200 OK sozinho não estabelece segurança e por que uma verificação de integridade isolada não prova o funcionamento das funções de negócio. Essa reflexão serve à compreensão; não há entrega escrita.
Resumo
Você usou curl e curl -i para ler uma resposta HTTP, diferenciou requisição bem-sucedida de resposta segura e relacionou os campos expostos a uma opção booleana. Salvou o ajuste, reiniciou o DeskLite e confirmou que status, integridade e acesso aos chamados continuavam funcionando sem diagnósticos internos.
Você verificou a configuração real e o serviço em execução, inclusive após outra reinicialização. Esse pequeno fluxo conecta ajustes de desenvolvimento, comportamento operacional e verificação de segurança. O próximo desafio aplica as mesmas habilidades a outro serviço preparado.
