이런 경우에 참고
- 조직 표준이 Vault 또는 Cloud Secret Manager인 경우
- Kubernetes, VM, ECS 등에서 중앙 Secret 저장소를 공통으로 쓰는 경우
- Secret 회전과 접근 통제를 운영팀이 중앙 관리하는 경우
권장 방식
- 코드에는 Secret 원문이 아니라 Secret 이름, 경로, 참조 키만 남깁니다.
- 애플리케이션 시작 시 SDK, sidecar, CSI driver, init container 등 현재 운영 방식에 맞는 수단으로 값을 조회합니다.
- Secret 등록과 동시에 회전 주기, 접근 정책, 감사 로그 확인 범위를 함께 정리합니다.
- 중앙 저장소가 지원한다면 장기 정적 Secret보다 동적 자격 증명이나 단기 토큰을 우선 검토합니다.
- 특히 Google Cloud Secret Manager 계열은 가능할 때 파일 또는 환경 변수 전달보다 직접 API 조회 또는 공식 통합 방식을 우선 검토합니다.
예시
변경 전
python
API_KEY = "sk-prod-123456"
DB_PASSWORD = "super-secret-password"
변경 후
python
import os
API_KEY = os.getenv("API_KEY")
DB_PASSWORD = os.getenv("DB_PASSWORD")
실제 API_KEY, DB_PASSWORD 값은 Vault 또는 Secret Manager에서 런타임 환경으로 주입합니다. 이 코드는 이미 주입된 환경 변수를 읽는 예시이며 저장소 API를 직접 호출하지 않습니다. 필수 값이 없으면 시작을 중단하도록 검증하세요.
담당자 조치 절차
- 노출된 Secret은 즉시 폐기하고 새 값을 발급합니다.
- 새 Secret을 조직 표준 저장소에 등록하고 코드와 설정 파일에서 실제 값을 제거합니다.
- 애플리케이션은 Secret 이름 또는 참조값만 사용하도록 수정합니다.
- 중앙 저장소가 지원한다면 정적 Secret 대신 동적 자격 증명으로 전환 가능한지 검토합니다.
- 새 값을 사용하는 서비스가 정상 동작하고 기존 값은 더 이상 사용할 수 없는지 확인합니다.
- 접근 권한이 필요한 서비스 계정만 Secret을 읽을 수 있도록 제한합니다.
담당자에게 안내할 문구 예시
- "코드에 저장된 Secret은 제거하고 Vault/Secret Manager에 등록한 뒤 런타임에 조회하도록 변경하세요."
- "애플리케이션에는 Secret 값이 아니라 참조 이름만 남기고, 실제 값은 중앙 저장소에서 주입해야 합니다."
- "Secret 이전 시 기존 값 재사용 대신 새 값으로 회전하고 접근 권한도 최소화하세요."
추가 확인 사항
- Secret을 읽는 서비스 계정 권한이 과도하지 않은가
- Secret rotation 정책이 있는가
- 애플리케이션 오류 시 Secret 값이 로그에 출력되지 않는가
- 특정 Secret 버전 고정이 필요한 운영 환경인지, 무조건
latest만 참조하고 있지는 않은가