URL 비밀 토큰 웹훅의 로그 노출을 줄이는 운영 설계

URL 경로의 비밀 토큰은 요청을 인증할 수 있지만, URL이라는 이유로 웹서버 access log·프록시·모니터링 도구에 기록될 수 있습니다. 현재 ChannelTalkWebhookController는 config의 토큰과 hash_equals로 비교하고 실패하면 401을 반환합니다. 이 코드는 애플리케이션 인증 경계이지, 앞단 로그에 이미 남은 값을 지우는 장치가 아닙니다.

선택지 비교: URL 토큰과 로그 노출 경계

채널톡 공식 webhook 안내는 연동 URL과 요청 구조를 설명하지만, 실제 운영 환경의 로그 보존 정책은 우리 인프라의 책임입니다.Webhook 설정 문서를 읽을 때도 공급자 설정과 서버 로그 흐름을 별개의 체크리스트로 나누세요. 토큰 원문을 애플리케이션 로그에 다시 출력하는 것은 인증 실패를 진단하는 방법이 아닙니다.

선택지 A·B를 가르는 운영 기준

• 보호: 미설정 또는 불일치 토큰은 모두 401로 종료한다.

• 보호: 비교에는 hash_equals를 사용해 단순 문자열 비교보다 안전한 경계를 둔다.
• 한계: 라우트 경로 토큰은 nginx·Apache access log에 기록될 수 있다.

비교 사례: 401 probe와 토큰 회전

예시 입력은 잘못된 토큰으로 들어온 POST 한 건입니다. 애플리케이션의 결정은 401이며, 중간 산출물로는 원본 payload를 저장하지 않고 요청 식별자와 상태 코드만 남기는 운영 로그가 적절합니다. 웹서버 access log에는 경로 전체 대신 /webhooks/channel-talk/[REDACTED]가 남도록 마스킹하고, 이미 노출된 토큰이라고 판단되면 env와 공급자 URL을 함께 회전합니다. 기대 결과는 실패 원인을 추적할 최소 정보는 남고 비밀 원문은 검색되지 않는 것입니다.

어느 선택을 바꿔야 하는가

로그에 토큰이 남은 뒤 단순히 로그 파일을 삭제하는 것은 수집기나 백업에 복사된 흔적을 해결하지 못할 수 있습니다. 먼저 새 랜덤 토큰을 생성해 공급자와 서버 설정을 교체하고, 짧은 겹침을 허용할지는 재전송 손실 위험을 따져 결정합니다. 그 다음 접근 로그·수집기·백업의 보존 범위를 확인하고, 권한을 최소화합니다. 회전 중 웹훅이 실패하면 발신자의 재시도 정책을 확인하고 대안으로 수동 원본 확인을 사용하되 토큰을 채팅이나 티켓에 복사하지 않습니다.

결정 기록과 재평가 조건

1. 정상·401 요청에서 로그의 URL과 헤더가 마스킹되는지 확인한다.

2. 토큰 회전 후 정상 요청과 이전 토큰 요청의 결과를 각각 확인한다.

3. 로그 검색 권한과 보존·백업 경로의 담당자를 기록한다.

완료 조건은 테스트 요청과 실패 probe를 재현한 뒤 모든 관찰 가능한 로그에 토큰 원문이 없고, 새 토큰만 성공하며 이전 토큰은 401이 되는 것을 확인하고 회전 일시와 담당자를 기록하는 것입니다.