보안 키 관리의 악몽

"Git에 올라간 JWT Secret Key"

by 제임스

환경별 보안 키 관리의 복잡성

JamesCompany를 개발하면서 가장 신경 쓴 부분 중 하나가 바로 보안 키 관리였습니다. Local, Development, Production 환경별로 다른 키를 사용해야 하고, 각 환경에서 절대 노출되면 안 되는 민감한 정보들... QA 엔지니어로서 보안 테스트는 많이 해봤지만, 직접 관리하는 입장이 되니 그 무게감이 완전히 달랐습니다.


JWT Secret Key: 256비트 랜덤 키의 중요성

환경별 JWT Secret Key 생성


처음엔 간단한 문자열로 JWT Secret을 만들려고 했지만, 이는 매우 위험한 접근이었습니다. 각 환경별로 완전히 다른, 예측 불가능한 키를 생성해야 합니다.


토스페이먼츠 키 관리: Test vs Live 환경 분리

토스페이먼츠 연동에서 가장 중요한 것은 테스트 키와 라이브 키의 철저한 분리였습니다.

환경별 토스페이먼츠 설정


프론트엔드 환경 검증


OAuth Client Secret: 환경별 리다이렉트 URI 관리

OAuth 인증에서는 Client Secret뿐만 아니라 Redirect URI도 환경별로 관리해야 했습니다.


Vercel Dashboard: 환경 변수 계층 관리

Vercel에서 환경 변수를 관리할 때 가장 중요한 것은 환경별 스코프 설정이었습니다.


GitHub Secrets: CI/CD 파이프라인 보안

GitHub Actions에서 사용하는 시크릿 관리도 중요했습니다.


보안 키 로테이션 전략

정기적인 키 로테이션을 위한 체계도 만들었습니다.


실수를 방지하는 Git 훅 설정


배운 교훈들

환경별 완전 분리: 같은 키를 여러 환경에서 사용하는 것은 매우 위험합니다.

자동 검증의 중요성: 배포 전에 환경과 키 타입이 일치하는지 자동으로 검증해야 합니다.

Defense in Depth: Git 훅, CI/CD 검증, 런타임 검증 등 여러 단계의 방어막이 필요합니다.

로테이션 계획: 처음부터 키 로테이션을 고려한 설계가 필요합니다.

메타데이터 관리: 키가 언제 생성되었고, 누가 접근했는지 추적해야 합니다.


QA 엔지니어로서 보안 테스트는 많이 해봤지만, 직접 보안 키를 관리하면서 느낀 것은 "개발자들이 이렇게 많은 것을 신경 쓰고 있었구나"하는 것이었습니다. 이제는 보안 이슈를 리포트할 때도 더 실질적인 개선 방안을 제시할 수 있게 되었습니다.

keyword
이전 06화CORS와 도메인 정책