8. 시크릿은 코드 밖에

사고 시나리오

빠르게 만드느라 API 키를 소스에 하드코딩했다. 리포지토리를 공개로 바꾸는 순간, 혹은 협업자를 초대하는 순간 그 키는 유출된 것이다. .env 파일을 실수로 커밋하는 변형도 흔하다. 커밋 히스토리에 한 번 들어간 시크릿은 파일을 지워도 히스토리에 남는다. 자동 스캐너들이 공개 리포지토리를 상시 훑고 있어서, 유출된 클라우드 키는 몇 분 안에 악용된다.

원칙

시크릿은 코드·히스토리·로그 어디에도 존재하면 안 되고, 환경(배포 플랫폼의 시크릿 저장소)에만 존재한다. 그리고 유출은 “일어날 수 있는 일”로 취급해 교체(rotation) 절차를 미리 둔다.

실무 처방

• .env를 .gitignore에 넣는 것은 시작일 뿐이다. 플랫폼의 시크릿/환경변수 저장소에 넣고, 로컬에는 .env.example(키 이름만, 값 없이)을 둔다.
• 저장소 호스팅의 시크릿 스캐닝과 푸시 차단(push protection)을 켠다. 커밋되기 전에 막는 것이 지우는 것보다 백 배 싸다.
• 프론트엔드 번들에 들어가는 키는 전부 공개 키다 — “클라이언트에서 쓰니까 어쩔 수 없다”면, 그 키로 할 수 있는 일이 서버 측 규칙(권한, 도메인 제한, 사용량 제한)으로 묶여 있는지 확인한다.
• 유출 시 절차를 한 줄이라도 적어둔다: 어떤 키가 어디서 발급됐고, 무효화·재발급은 어디서 하는지. 사고 당일에 발급처를 찾아 헤매지 않게.
• 커밋 히스토리에 이미 들어간 시크릿은 지우려 하지 말고 즉시 교체한다. 히스토리 세탁보다 키 무효화가 빠르고 확실하다.

체크리스트

• 소스·커밋 히스토리에 시크릿이 없다 (스캐닝+푸시 차단 켜짐)
• 시크릿은 플랫폼 시크릿 저장소에만 있고 .env.example로 목록화돼 있다
• 클라이언트 노출 키는 서버 측 규칙으로 권한이 묶여 있다
• 키별 발급처·무효화 방법이 적혀 있다