개발에선 열고 운영에선 닫는다: 환경별 우회 필터의 위험

개발 편의가 운영 구멍이 되는 순간

로컬·개발 환경에서 매번 인증하기 번거로워 “인증 우회” 필터를 둔다. 문제는 이 우회가 운영으로 새면 곧 인증 부재라는 점이다. 편의 기능일수록 기본값을 안전하게 설계해야 한다.

안전한 설계 — 기본은 거부, 우회는 명시적으로

@Bean
@Profile("dev")               // dev 프로파일에서만 빈 등록
public Filter devBypassFilter() { ... }

핵심은 우회를 “켜는” 구성이 prod 프로파일에는 존재조차 하지 않게 하는 것이다. 환경 변수 플래그(auth.bypass=true)로만 제어하면, 그 플래그가 실수로 운영에 설정될 때 뚫린다. @Profile로 빈 자체를 분리하면 운영 빌드에는 코드 경로가 없다.

비활성/만료 키 처리 — 401과 403의 구분

API 키 인증에서 키의 상태는 세 가지다: 유효 / 비활성(존재하지만 꺼짐) / 없음.

• 없음·형식 오류 → 401 Unauthorized(인증 자체 실패)
• 유효하지만 권한 부족 → 403 Forbidden
• 비활성/만료 키는 인증 단계에서 걸러 401로 처리하되, 로그에는 “비활성 키 시도”로 남겨 키 회수·탈취를 추적한다.

운영 함정

• 우회 플래그 유출의 사고 모델: “이 플래그가 운영에 켜지면 무슨 일이 일어나는가?”를 항상 자문한다. 답이 “전 API 인증 무력화”라면 플래그가 아니라 프로파일 분리로 가야 한다.
• 비활성 키를 캐시해두면, 키를 꺼도 캐시 TTL 동안 계속 통과한다 → 비활성화는 캐시 무효화와 함께.

핵심 요약

환경별 우회는 “기본 거부 + 프로파일로 빈 분리”가 안전하다. 키 상태는 401/403로 정확히 구분하고, 비활성화는 캐시 무효화까지 한 묶음으로 처리한다.