DB 비밀번호를 .env에 적고, API 키를 코드에 하드코딩하고, 슬랙으로 토큰을 주고받습니다. 흔하지만 위험합니다. 깃 히스토리에 한 번 들어간 시크릿은 커밋을 지워도 남고, 환경변수는 프로세스 목록과 로그에 새어 나옵니다. 시크릿은 별도 시스템에서 발급·회수해야 합니다.
무엇이 문제인가
| 보관 위치 | 위험 |
|---|---|
| 코드·깃 | 히스토리에 영구 노출, 권한 분리 불가 |
.env 파일 | 백업·이미지에 그대로 복사됨 |
| 환경변수 | 로그·프로세스 목록 유출, 회전 어려움 |
| 시크릿 매니저 | 중앙 관리·감사·자동 회전 가능 |
핵심 차이는 **회전(rotation)**과 **감사(audit)**입니다. 시크릿 매니저는 누가 언제 시크릿을 읽었는지 기록하고, 주기적으로 값을 자동 교체할 수 있습니다.
두 가지 접근
AWS Secrets Manager — 매니지드 서비스. 인프라 운영이 없고 IAM·RDS와 통합됩니다.
로컬 터미널
aws secretsmanager get-secret-value \
--secret-id prod/db/password \
--query SecretString --output text
HashiCorp Vault — 멀티클라우드·온프레미스를 아우르는 셀프호스팅 옵션. 동적 시크릿(요청 시 단기 DB 계정 발급)이 강점입니다.
| 기준 | Secrets Manager | Vault |
|---|---|---|
| 운영 | 매니지드(운영 부담 없음) | 직접 운영 |
| 환경 | AWS 중심 | 멀티클라우드·온프레미스 |
| 동적 시크릿 | 제한적 | 강력(단기 계정 발급) |
| 비용 | 시크릿당 과금 | 인프라 비용 |
AWS만 쓰면 Secrets Manager가 단순하고, 여러 클라우드나 온프레미스가 섞이면 Vault가 일관성을 줍니다.
적용 원칙
- 앱은 시크릿을 모른다 — 시작 시 매니저에서 받아 메모리에만 둔다. 디스크에 쓰지 않는다.
- 권한은 최소로 —
prod/db/*처럼 경로별로 IAM 정책을 좁혀, 앱이 자기 시크릿만 읽게 한다. - 회전을 자동화 — 비밀번호를 주기적으로 교체하고, 앱은 만료 시 다시 가져오게(
< 24h캐시) 한다. - 유출되면 즉시 무효화 — 코드에 키가 들어간 게 발견되면 지우는 게 아니라 그 키를 폐기하고 새로 발급한다.
요점 정리
- 시크릿은 코드·
.env·환경변수가 아니라 전용 시스템에서 발급·회수한다. - 매니저의 핵심 가치는 자동 회전과 접근 감사 로그.
- AWS 단일이면 Secrets Manager, 멀티클라우드면 Vault.
- 유출된 시크릿은 삭제가 아니라 폐기·재발급으로 대응한다.
IAM 권한을 좁혀 앱이 자기 시크릿만 읽도록 구성하는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.