04. 배포 전 운영 보안 체크리스트 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• 배포 전에는 코드 테스트 외에 어떤 운영 보안 설정을 검증해야 하는가?
• CORS, HTTPS, secret, 로그, alert, rollback은 API 배포와 어떻게 연결되는가?
• 배포 전 보안 체크리스트의 실패는 어떤 release gate로 다뤄야 하는가?

개요

배포 전 운영 보안 체크리스트는 마지막 형식 절차가 아니다. 코드가 안전해도 production CORS가 *이거나 secret이 image에 들어 있거나 로그 마스킹이 꺼져 있으면 배포 순간 취약점이 된다.

운영 설정은 코드와 분리되어 있어 리뷰에서 빠지기 쉽다. reverse proxy, load balancer, gateway, secret manager, observability, WAF, database user 권한, rollback manifest까지 함께 봐야 한다.

배포 전 체크는 “현재 버전이 안전한가”뿐 아니라 “rollback하면 안전한가”도 확인한다. 과거 설정이 오래된 signing key, 넓은 CORS, 낮은 rate limit를 되살릴 수 있다.

이 문서의 핵심은 production에서 실제로 적용될 보안 경계를 배포 직전에 확인하는 것이다.

공격 시나리오

• staging에서는 Origin allowlist였지만 production 환경 변수 누락으로 CORS가 *로 열린다.
• 새 API secret이 Docker image layer에 포함되어 registry 접근자로부터 노출된다.
• rollback manifest가 이전 JWT signing key와 오래된 security header 설정을 되살린다.
• gateway route가 인증 필요 API를 public route로 배포한다.
• 로그 마스킹 설정이 빠져 token과 개인정보가 error tracking에 들어간다.
• alert rule이 신규 security event를 모르기 때문에 차단 이벤트가 조용히 쌓인다.

취약한 요청/응답 예시

OPTIONS /api/admin/reports HTTP/1.1
Host: api.example.com
Origin: https://evil.example
Access-Control-Request-Method: POST

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

release-check=passed
cors=not-reviewed
secret-scan=skipped
alert-rule=todo
rollback-security-diff=unknown

CORS와 secret, alert, rollback이 검증되지 않은 배포는 기능 테스트가 통과해도 보안 gate를 통과한 것이 아니다.

주제별 핵심 판단

• HTTPS와 HSTS, Secure cookie가 production domain에서 실제로 적용되는지 확인한다.
• CORS Origin, method, credential 정책이 환경별로 맞는지 확인한다.
• CSRF가 cookie 기반 상태 변경 API에 적용되는지 확인한다.
• secret은 runtime에 주입되고 image와 log에 남지 않아야 한다.
• 보안 헤더와 error response가 reverse proxy 뒤에서도 유지되어야 한다.
• 신규 security event가 로그 수집, alert, dashboard에 등록되어야 한다.
• rollback 보안 diff를 배포 전 확인한다.

개선된 요청/응답 예시

release=2026.07.01-4
api=POST /api/admin/reports
checks=https,hsts,cors,csrf,secret-scan,log-mask,alert,rollback-diff
result=blocked
reason=cors_allows_credentials_with_wildcard
owner=platform
due=2026-07-02

배포 전 체크는 release artifact와 연결되어야 한다. 실패한 보안 gate는 “나중에 확인”이 아니라 release decision이다.

방어 설계

• production-like 환경에서 smoke security test를 실행한다.
• HTTPS redirect, HSTS, Secure cookie, SameSite, CSP, CORS를 실제 응답으로 검증한다.
• secret scan은 source, build artifact, container image, CI log를 모두 본다.
• gateway route와 Spring Security matcher가 같은 보호 기준을 갖는지 비교한다.
• 신규 endpoint가 API inventory와 monitoring에 등록되는지 확인한다.
• 신규 security event가 log pipeline, alert rule, dashboard에 반영되는지 확인한다.
• rollback manifest와 이전 설정의 보안 차이를 확인한다.
• risk acceptance가 필요한 배포는 owner, expiry, mitigation을 release note에 남긴다.

Spring/HTTP 예시

curl -i https://api.example.com/api/me \
  -H 'Origin: https://evil.example'

expected:
- no Access-Control-Allow-Origin for untrusted origin
- Set-Cookie includes Secure, HttpOnly, SameSite
- Strict-Transport-Security exists on HTTPS response
- no stack trace in error response

releaseGate:
  required:
    - secret-scan
    - cors-smoke-test
    - security-event-dashboard
    - rollback-security-diff

실제 배포 gate는 도구가 달라도 된다. 중요한 것은 production 응답과 artifact를 대상으로 검증한다는 점이다.

운영 로그와 감사 지점

level=INFO event=release_security_gate_passed result=allowed release=2026.07.01-4 checks=https,cors,secret-scan,log-mask,alert reviewer=platform:lee traceId=de21c708

level=WARN event=release_security_gate_blocked result=blocked release=2026.07.01-4 reason=missing_alert_for_authorization_denied owner=team-order traceId=de21c708

• release gate 결과는 배포 이력과 함께 남긴다.
• 예외 승인에는 owner와 만료일을 남긴다.
• 배포 후 synthetic security event가 alert로 도달하는지 확인한다.
• rollback 실행도 보안 이벤트로 기록한다.
• 운영 설정 변경은 코드 PR과 같은 수준으로 리뷰한다.

실전 판단 기준

• staging 설정이 production 설정과 다르면 smoke test가 필요하다.
• Access-Control-Allow-Credentials: true와 wildcard Origin 조합은 위험 신호다.
• secret scan이 source만 보고 image와 CI log를 보지 않으면 부족하다.
• 신규 이벤트가 dashboard에 없으면 사고 때 “아무 일도 없었다”고 보일 수 있다.
• rollback이 항상 안전한 것은 아니다.
• release note에 보안 정책 변경이 없으면 운영팀과 고객지원이 대응하기 어렵다.

테스트 포인트

• HTTPS redirect와 HSTS header를 production domain에서 확인한다.
• 신뢰하지 않는 Origin preflight가 거부되는지 확인한다.
• cookie 기반 상태 변경 API에 CSRF 방어가 적용되는지 확인한다.
• container image와 CI log에 secret이 없는지 확인한다.
• 오류 응답에 stack trace와 SQL이 없는지 확인한다.
• 신규 보안 이벤트가 alert로 도달하는지 synthetic test를 실행한다.
• rollback 후에도 보안 헤더, CORS, signing key 정책이 안전한지 확인한다.

위험 신호!

• 배포 체크리스트가 기능 smoke test만 포함한다.
• production CORS가 환경 변수 누락 시 기본 허용으로 열린다.
• secret scan이 배포 artifact를 보지 않는다.
• 로그 마스킹 설정이 운영에서 꺼져 있다.
• 신규 endpoint가 monitoring과 inventory에 등록되지 않는다.
• rollback 보안 영향이 검토되지 않는다.

확인 질문

확인 질문

• 배포 전 보안 체크의 대상은 무엇인가?
  • 코드뿐 아니라 production 응답, artifact, secret, gateway route, log pipeline, alert, rollback manifest다.
• rollback도 검토해야 하는 이유는 무엇인가?
  • 이전 설정이 오래된 key, 넓은 CORS, 약한 header를 되살릴 수 있기 때문이다.
• 배포 gate 실패의 완료 조건은 무엇인가?
  • 수정 배포, 명시적 risk acceptance, owner와 만료일, 보완 조치가 기록되는 것이다.

참고 문서

• OWASP REST Security
• OWASP Transport Layer Security
• OWASP Secrets Management
• OWASP Logging