시크릿 회전 자동화: 장애 없이 키를 바꾸는 운영 순서

핵심 요약

시크릿 회전은 새 값을 만든 뒤 옛 값을 지우는 한 줄 작업이 아니다. 발급, 병행 허용, 소비자 전환, 사용 검증, 옛 값 폐기, 잔존 탐지의 순서를 분리해야 장애와 노출 시간을 동시에 줄일 수 있다.

API 키와 데이터베이스 비밀번호는 언젠가 바꿔야 한다. 사고가 없어도 정기 정책, 인력 변경, 공급자 요구, 권한 축소, 암호화 체계 변경 때문에 회전이 필요하다. 그런데 실제 장애는 “키를 바꿨다”는 사실보다 생산자와 소비자가 서로 다른 시점에 새 값을 사용하면서 발생한다.

한 서비스만 쓰는 비밀값이라면 비교적 단순하다. 하지만 배치 작업, 서버리스 함수, 오래 떠 있는 컨테이너, 외부 파트너, 캐시된 설정, 재해복구 환경이 같은 키를 공유하면 누가 언제 새 값을 읽는지 알기 어렵다. 장애 없는 회전의 핵심은 이 의존성을 먼저 드러내고 전환을 여러 단계로 나누는 것이다.

회전 전에 만드는 의존성 목록

비밀값마다 최소한 다음 정보를 인벤토리에 둔다.

항목	확인 내용
소유자	업무 소유자와 기술 담당자
발급자	클라우드 IAM, DB, 외부 SaaS, 사내 PKI 등
소비자	애플리케이션, 배치, CI/CD, 운영 스크립트, 파트너
환경	개발·스테이징·운영·DR의 분리 여부
권한	읽기·쓰기·관리 범위와 대상 리소스
전달 방식	시크릿 매니저, 파일, 환경 변수, 이미지, 수동 복사
재로딩 방식	재시작, 핫 리로드, 다음 요청, 캐시 만료
최근 사용	마지막 인증 시각과 호출 출처
폐기 조건	새 값 사용률, 오류율, 관찰 시간
비상 연락	실패 시 롤백과 재발급 담당자

소비자를 모르면 자동 회전을 켜지 않는다. “어딘가에서 쓸 수도 있다”는 장기 키는 자동화 실패보다 더 큰 운영 부채다. 액세스 로그, 코드 검색, 구성 관리, 네트워크 흐름, 비밀값 조회 로그를 이용해 실제 사용처를 확인한다.

가장 안전한 기본 순서

회전 가능 구조라면 다음 여섯 단계를 독립된 상태로 관리한다.

1. 새 시크릿을 발급한다

기존 값은 유지한 채 새 값을 만든다. 이때 새 값은 기존 권한을 그대로 복제하지 말고 실제 필요한 권한으로 줄일 기회로 삼는다. 발급 이벤트에는 소유자, 목적, 만료 예상일, 회전 티켓을 기록한다.

2. 발급자 측에서 두 값을 병행 허용한다

서비스가 이중 키, 두 사용자, 두 인증서 체인을 지원한다면 제한된 전환 기간 동안 둘 다 유효하게 둔다. 병행 기간은 무기한이 아니라 관찰 창을 위한 임시 상태다.

3. 소비자에게 새 값을 배포한다

모든 소비자를 한 번에 바꾸지 않는다. 스테이징, 카나리 인스턴스, 비중이 낮은 배치부터 전환한다. 시크릿 매니저 참조만 바꾸는지, 프로세스 재시작이 필요한지, 연결 풀이 기존 인증을 계속 쓰는지 확인한다.

4. 새 값 사용을 검증한다

애플리케이션이 정상이라는 것만으로 부족하다. 인증 로그나 키 식별자를 통해 새 값이 실제 사용되는지 확인한다. 구 키 호출이 계속 보이면 어떤 소비자가 남았는지 추적한다.

5. 구 값을 비활성화한다

즉시 삭제보다 먼저 비활성화 또는 권한 제거 상태를 둔다. 오류가 발생하면 제한 시간 안에 다시 활성화할 수 있도록 한다. 단, 노출 사고 대응이라면 공격자가 구 값을 알고 있다고 가정하고 재활성화를 롤백 수단으로 쓰지 않는다.

6. 구 값을 삭제하고 잔존을 탐지한다

관찰 시간이 지나면 구 값을 폐기하고 저장소, 이미지, 로그, 백업, 로컬 파일에 남은 복사본을 찾는다. 삭제는 회전의 마지막 단계이지 첫 단계가 아니다.

이중 키를 지원하지 않을 때

모든 시스템이 병행 인증을 지원하는 것은 아니다. 단일 DB 계정 비밀번호처럼 한 번에 하나의 값만 유효할 수 있다면 다른 패턴을 사용한다.

두 계정 교대 패턴

app_a, app_b처럼 같은 최소 권한을 가진 두 계정을 준비하고 한쪽을 활성 소비자로 사용한다. 다음 회전 때 비활성 계정의 비밀번호를 바꾸고 소비자를 전환한 뒤 이전 계정을 중지한다. 계정별 감사가 가능하고 롤백 경계가 분명해진다.

프록시 또는 중개 계층 패턴

애플리케이션이 장기 비밀번호를 직접 갖지 않고 인증 프록시, 워크로드 아이덴티티, 짧은 수명 토큰 발급기를 사용하게 한다. 장기 비밀값의 회전 부담을 중앙 계층으로 줄일 수 있지만, 중개 계층 자체의 가용성과 권한을 별도로 보호해야 한다.

짧은 유지보수 창 패턴

대체 구조가 불가능하면 변경 창을 명시하고 연결 종료, 값 변경, 재시작, 검증을 빠르게 수행한다. 이 경우 자동화보다 사전 리허설과 롤백 기준이 중요하다. 정기적으로 이런 창이 필요하다면 아키텍처 개선 과제로 올린다.

배포 순서에서 자주 생기는 장애

시크릿 저장소는 바뀌었지만 프로세스가 다시 읽지 않는다

환경 변수는 대개 프로세스 시작 시 읽힌다. 파일 마운트도 애플리케이션이 캐시하면 반영되지 않는다. “시크릿 버전 변경”과 “소비자 재로딩 완료”를 별도 이벤트로 기록해야 한다.

연결 풀이 오래된 인증 세션을 유지한다

DB 연결 풀은 기존 연결이 살아 있는 동안 구 비밀번호 폐기를 늦게 발견할 수 있다. 새 연결 생성 테스트와 기존 연결 종료 후 재연결 테스트를 모두 해야 한다.

배치와 DR 환경이 잊힌다

매일 또는 매주 실행되는 작업은 관찰 창 동안 호출되지 않을 수 있다. 마지막 사용 시각만 보고 폐기하면 다음 실행 때 실패한다. 스케줄 목록과 재해복구 환경을 인벤토리에 포함한다.

마스킹된 로그가 사실은 값을 노출한다

일부 도구는 전체 값은 가리지만 명령행 인자, 디버그 출력, 오류 메시지, 환경 덤프에 비밀값을 남긴다. 회전 전후 로그를 검색하고, 노출된 로그의 접근과 보존도 정리한다.

파트너에게 전달한 키가 수동 절차에 묶인다

외부 소비자는 조직의 배포 속도와 다르다. 새 키 전달 채널, 수신 확인, 전환 시각, 구 키 폐기 합의를 계약·운영 문서에 포함한다. 이메일 본문이나 메신저 평문 전달은 피한다.

검증 신호와 중단 기준

회전은 “배포 성공” 이벤트가 아니라 관측 지표로 판단한다.

신호	정상 조건	중단 또는 롤백 조건
인증 성공률	기준선 범위 유지	특정 소비자에서 오류 급증
새 키 사용 비율	단계적으로 증가	카나리 전환 후 증가하지 않음
구 키 사용	관찰 창 내 감소	예상치 못한 출처에서 계속 사용
애플리케이션 오류	변경 전과 유사	인증·연결 오류가 임계치 초과
지연 시간	허용 범위	재연결 폭주로 지연 상승
시크릿 조회 실패	없어야 함	권한·네트워크 문제 발생

임계치는 서비스 SLO와 트래픽 특성에 맞춰 정한다. 예시 숫자를 전사 공통값으로 복사하지 말고 변경 전 정상 구간과 장애 비용을 기준으로 설정한다.

사고 대응 회전은 일반 회전과 다르다

유출이 의심되면 구 값을 다시 살릴 수 있는 롤백 대상으로 보면 안 된다. 공격자가 이미 보유했다고 가정해야 한다.

영향 범위와 권한을 확인한다.
새 값을 발급하고 가능한 경우 권한을 축소한다.
소비자를 빠르게 전환한다.
구 값을 즉시 폐기하거나 네트워크·리소스 정책으로 사용을 차단한다.
구 값 사용 시도를 탐지 규칙으로 추가한다.
로그, 저장소, 빌드 산출물에서 노출 경로를 제거한다.
같은 경로에 있던 다른 시크릿도 조사한다.

CI/CD에서 노출된 경우 CI/CD 시크릿 관리 원칙에 따라 워크플로 권한, 로그, 러너, 아티팩트를 함께 점검한다. 저장소에서 문자열을 지웠더라도 커밋 기록, 캐시, 포크, 아티팩트에 남았을 수 있으므로 반드시 값 자체를 폐기한다.

자동화 설계 예시

state: ISSUED
  -> 새 값 발급, 권한 검증
state: DUAL_VALID
  -> 두 값 허용, 카나리 준비
state: CANARY
  -> 일부 소비자 전환, 오류율·새 키 사용 확인
state: ROLLOUT
  -> 전체 소비자 전환
state: OLD_DISABLED
  -> 구 값 비활성화, 재연결 테스트
state: OLD_REVOKED
  -> 구 값 폐기, 잔존 검색
state: VERIFIED
  -> 증거 저장, 다음 회전일 예약

각 상태 전이는 재실행 가능해야 한다. 자동화가 중간에 실패해도 현재 상태를 조회해 이어갈 수 있도록 멱등성을 설계한다. 값 자체를 로그에 쓰지 말고 버전 ID나 키 ID만 기록한다.

완료 증거

새 시크릿의 소유자와 최소 권한이 확인되었다.
모든 소비자가 새 버전을 사용한다는 로그가 있다.
구 시크릿 사용이 관찰 창 동안 0건임을 확인했다.
구 시크릿이 발급자 측에서 폐기되었다.
저장소, 이미지, 로그, 백업에서 잔존 여부를 점검했다.
실패와 롤백 리허설 결과가 남아 있다.
다음 회전일과 자동화 소유자가 등록되었다.

참고 기준

시크릿 회전의 성공 기준은 새 값이 생성된 것이 아니다. 모든 소비자가 새 값을 쓰고, 구 값이 더 이상 호출되지 않으며, 폐기 후에도 서비스가 정상이고, 노출된 복사본이 남지 않은 상태가 완료다. 이 순서를 상태 기계처럼 운영하면 보안과 가용성을 동시에 지킬 수 있다.