소개
애플리케이션이 정상적으로 작동하면서도 사용자에게 필요 없는 정보를 노출할 수 있습니다. 이 실습의 DeskLite는 이미 실행 중이지만, 상태 응답에 내부 개발 정보가 포함되어 있습니다. 응답을 조사하고 설정 하나를 바꾼 뒤, 서비스가 계속 유용하게 작동하는지 확인합니다.
터미널에서 기본적인 디렉터리 이동과 파일 읽기만 할 수 있으면 됩니다. 요청, HTTP 응답, 설정 스위치, 준비된 재시작 명령은 사용하는 순서대로 설명합니다. 위험을 관찰하고 원인을 수정한 뒤 보안과 정상 동작을 함께 검증하는 첫 DevSecOps 순환입니다.
서비스 응답 관찰하고 수정하기
이 단계에서는 DeskLite 응답을 읽고 불필요한 내부 정보를 식별한 뒤 노출을 일으키는 설정을 수정합니다.
DeskLite는 작은 헬프데스크 애플리케이션입니다. 직원에게는 티켓 정보와 서비스 실행 여부가 필요하지만, 내부 파일 위치나 개발 진단 정보는 필요하지 않습니다. 이 내부 정보가 보호 대상이며, 응답을 읽을 수 있는 사람이 그 응답의 대상 독자입니다.
서비스는 계속 실행되면서 요청에 응답하는 프로그램입니다. HTTP 요청은 웹 서비스에 무언가를 요구하며, 응답에는 상태 코드와 본문이 들어 있습니다. 터미널 프로그램 curl로 요청하므로 브라우저나 프로그래밍 지식은 필요하지 않습니다.
서비스는 이미 실행 중입니다. 준비된 디렉터리에서만 작업하세요.
cd /home/labex/project/desklite
URL은 curl에 요청을 보낼 위치를 알려 줍니다. http://127.0.0.1:8080/status에서 http는 통신 방식, 127.0.0.1은 현재 실습 머신, 8080은 서비스, /status는 서비스가 제공하는 특정 응답인 엔드포인트를 선택합니다. 여기서는 네트워크를 설정할 필요가 없습니다.
curl http://127.0.0.1:8080/status
본문은 JSON 형식입니다. 중괄호 안에 이름이 있는 필드와 값이 있습니다. 읽기만 하면 되며 프로그램을 작성할 필요는 없습니다.
{
"service": "DeskLite",
"status": "running",
"internal_path": "/opt/labex-desklite/private/settings.ini",
"debug_details": "development diagnostics enabled"
}
service와 status는 의도한 독자에게 유용합니다. internal_path는 내부 파일 위치를, debug_details는 개발 정보를 드러냅니다. 경로를 안다고 파일 접근 권한이 자동으로 생기지는 않지만, 불필요한 세부 정보가 추가 조사를 계획하는 데 도움을 줄 수 있습니다. 이것이 정보 노출입니다.
-i 옵션을 추가하면 본문 위에 HTTP 헤더도 표시됩니다.
curl -i http://127.0.0.1:8080/status
첫 줄의 200 OK는 요청 성공을 뜻합니다. Content-Type: application/json 같은 헤더는 본문을 설명하고, 빈 줄이 헤더와 본문을 구분합니다. 날짜는 달라질 수 있습니다. HTTP 성공 상태가 응답의 안전성을 뜻하지는 않습니다. 지금의 성공 응답도 정보를 노출합니다.
애플리케이션이 사용하는 설정 파일인 서비스 구성을 읽습니다.
cat service.conf
[service]는 설정을 묶는 구역입니다. #로 시작하는 줄은 설명 주석입니다. debug = true는 불리언 스위치로, true는 개발 진단을 켜고 false는 끕니다. 주석은 이 설정과 노출된 상태 필드의 관계를 설명합니다.
설정 수정 적용하기
디버그 정보는 개발자가 문제를 조사하는 데 유용합니다. 하지만 개발 중에 유용한 설정이 공개 상태만 필요한 독자에게도 적절한 것은 아닙니다. DevSecOps는 개발과 운영의 공동 작업에 보안을 포함합니다. 무엇을 공개할지 정하고, 설정을 바꾸고, 실행 결과를 테스트합니다.
터미널 텍스트 편집기 nano로 설정을 여세요. 방향키로 설정 위치로 이동합니다. 아래 Ctrl 단축키를 사용할 때는 Ctrl을 누른 상태에서 해당 문자 키를 누르세요.
nano service.conf
debug = true만 debug = false로 바꿉니다. [service] 제목과 주석은 유지하세요. Ctrl+O, Enter로 저장하고 Ctrl+X로 나갑니다. 저장된 파일을 확인합니다.
cat service.conf
이제 설정은 다음과 같아야 합니다.
[service]
## Include development diagnostics in status responses.
debug = false
디스크의 파일과 실행 중인 프로그램은 서로 다릅니다. 이 서비스는 시작할 때 설정을 읽으므로 저장만으로는 응답이 바뀌지 않습니다. 과정에서는 직접 프로세스를 관리하지 않고 설정을 적용할 수 있도록 restart.sh를 제공합니다. bash는 준비된 스크립트를 실행합니다. 스크립트를 편집할 필요는 없습니다.
bash restart.sh
예상 출력입니다.
DeskLite restarted.
헤더를 포함해 같은 엔드포인트를 다시 요청합니다.
curl -i http://127.0.0.1:8080/status
200 OK와 다음 본문이 예상됩니다.
{
"service": "DeskLite",
"status": "running"
}
내부 필드 두 개는 사라지고 유용한 상태는 남았습니다. 여전히 보인다면 service.conf를 저장하고 재시작 명령을 실행했는지 확인하세요. 스크립트가 설정 오류를 보고하면 위의 구역 제목과 불리언 철자를 복원한 뒤 다시 시도하세요. 응답을 숨기기 위해 애플리케이션을 교체하거나 서비스를 중지하지 마세요.
보안과 업무 기능 함께 검증하기
이 단계에서는 다시 시작해도 수정이 유지되고 DeskLite가 계속 사용자에게 필요한 기능을 제공하는지 확인합니다.
서비스를 망가뜨려도 응답은 없어지지만 유용한 기능도 사라집니다. 따라서 민감한 필드가 없다는 증거와 정상 서비스가 작동한다는 증거가 모두 필요합니다. 상태 점검은 기본적인 준비 상태를 나타내고, 업무 요청은 사용자가 실제로 필요로 하는 기능을 테스트합니다.
저장한 설정이 계속 적용되는지 확인하도록 다시 시작합니다.
bash restart.sh
상태를 다시 확인합니다.
curl -i http://127.0.0.1:8080/status
200 OK, service, status가 있고 internal_path와 debug_details는 없어야 합니다. 이제 상태 점검 엔드포인트를 요청합니다.
curl -i http://127.0.0.1:8080/health
200 OK와 다음 본문이 예상됩니다.
{
"status": "ok"
}
마지막으로 업무 엔드포인트를 요청합니다.
curl -i http://127.0.0.1:8080/tickets
200 OK와 원래 티켓이 예상됩니다.
{
"tickets": [
{
"id": 1,
"title": "Printer offline"
}
]
}
프로세스가 정상이라는 사실만으로 티켓 접근까지 증명되지는 않습니다. 이 요청들을 함께 보면 정보 노출이 제거되었고 의도한 기능도 유지됨을 알 수 있습니다. curl이 전송 진행률을 표시할 수도 있습니다. 진행률이 아닌 HTTP 상태와 본문으로 판단하세요.
마지막으로 200 OK만으로 안전성을 증명할 수 없는 이유와 상태 점검만으로 업무 기능의 정상 동작을 증명할 수 없는 이유를 설명해 보세요. 이해를 위한 생각 정리이며 서면 제출은 필요하지 않습니다.
요약
curl과 curl -i로 HTTP 응답을 읽고, 요청 성공과 응답 안전성을 구분했으며, 노출된 필드를 불리언 설정 스위치와 연결했습니다. 설정을 저장하고 DeskLite를 다시 시작한 후 내부 진단 없이 상태, 상태 점검, 티켓 접근이 작동함을 확인했습니다.
다시 시작한 후의 동작까지 실제 설정과 실행 중인 서비스를 검증했습니다. 이 작은 작업은 개발 설정, 운영 동작, 보안 검증을 연결합니다. 다음 챌린지에서는 같은 능력을 다른 준비된 서비스에 적용합니다.
