항상 안전하지는 않습니다. process dump, log 출력, 권한이 넓은 runtime 환경에서 노출될 수 있습니다. 접근 제어와 log masking을 함께 적용해야 합니다.

secret을 중앙에서 암호화해 저장하고, 접근 권한 제어, audit log, rotation을 일관되게 관리할 수 있기 때문입니다. 환경 변수로 직접 관리할 때보다 감사와 추적이 쉽습니다.

파일에서 삭제하는 것만으로는 부족합니다. Git history에 남아 있을 수 있으므로 해당 key를 즉시 폐기하고 새 key로 rotation해야 합니다.

장기간 같은 secret을 사용하면 노출 시 피해 기간이 길어집니다. 주기적으로 교체하면 유출되더라도 유효 기간이 제한되어 위험을 줄일 수 있습니다.

환경별로 별도의 secret 집합을 사용하는 것이 기본입니다. secret manager를 쓴다면 환경별 경로나 네임스페이스로 분리하고, 각 환경의 서비스에는 해당 환경의 secret에만 접근 권한을 부여합니다.

코드에 값을 직접 넣지 않고 환경 변수 이름이나 secret manager의 경로만 참조합니다. 실제 값은 배포 시 런타임에 주입합니다. 이렇게 하면 코드 저장소에 secret이 남지 않습니다.