프로덕션에서 Secrets와 .env 다루기

운영에서 가장 흔한 사고 중 하나는 “코드 배포”가 아니라 시크릿(키/토큰/비밀번호) 유출입니다. .env는 편리하지만, 프로덕션에서는 관리 방식이 중요합니다.

운영 기본 원칙 3가지

1. 코드와 시크릿을 분리합니다. (레포/웹루트에 두지 않기)
2. 시크릿은 최소 권한으로 읽히게 합니다. (권한/소유자/경로)
3. 시크릿은 백업/로그/에러 리포트로 새지 않게 합니다.

체크리스트 (익명화된 실전 패턴)

1) 레포/배포 산출물

• .env는 커밋하지 않고, .env.example만 제공합니다.
• CI/CD 로그에 환경변수가 출력되지 않게 합니다. (특히 printenv, set -x)
• “정적 사이트 빌드 산출물”에 시크릿이 섞이지 않게 합니다. (프론트 번들에 키가 들어가면 끝)

2) 시크릿 파일 위치/권한

• 시크릿 파일은 앱 디렉터리 밖(예: /etc/myapp/myapp.env)에 둡니다.
• 권한은 0600 또는 최소 접근으로, 소유자는 root 또는 해당 서비스 계정으로 제한합니다.
• 웹서버가 접근 가능한 경로(예: 정적 root, 업로드 경로)에 시크릿 파일을 두지 않습니다.

3) 주입 방식

• systemd를 쓴다면 EnvironmentFile=로 주입합니다. → EnvironmentFile
• 애플리케이션은 “환경변수에서 읽는다”만 알고, 파일 위치/권한은 운영이 책임집니다.

관련 문서: systemd EnvironmentFile로 환경변수 주입하기

4) nginx에서 “실수 방지” (노출 차단)

• /.env, /.git/, 백업 파일(.bak, .sql) 등은 무조건 차단합니다.
• 단, /.well-known/acme-challenge/는 SSL 갱신을 위해 예외가 필요할 수 있습니다.

바로 쓰는 스니펫: nginx: 민감 파일(.env/.git/백업) 차단

5) 백업/복구

• 백업은 “성공 로그”가 아니라 복구 테스트가 기준입니다.
• 백업에 시크릿이 섞이면, 백업 유출 = 운영 전체 유출이 됩니다.
• DB 덤프/파일 백업을 분리하고, 시크릿은 별도 저장/암호화/접근통제합니다.

체크리스트: 백업 설계: 복구 가능 + secrets 제외

권장 구조 예시

/srv/myapp/               # 코드/빌드 산출물 (배포 대상)
  current/
  releases/

/etc/myapp/myapp.env      # 시크릿 (권한 제한)
/var/log/myapp/           # 로그

같이 보면 좋은 문서

• systemd EnvironmentFile로 환경변수 주입하기
• nginx에서 한 도메인에 정적/API/WS/서브앱 붙이기
• 백업 설계: 복구 가능 + secrets 제외
• nginx: systemd Node 서비스 유닛 템플릿