워크로드 자격증명 점검: 담당자부터 종료 처리까지

서비스 계정이나 역할 같은 워크로드 신원과 그 신원으로 인증하는 키는 서로 다릅니다. 일부 워크로드는 장기 키를 밖으로 내보내지 않고 역할이나 연합 인증을 쓸 수 있습니다. 다른 워크로드는 아직 고정 자격증명에 의존합니다. 먼저 실제 서비스와 발급처를 확인한 뒤 아래 여섯 항목을 적용하세요. 볼트는 그중 한 수단일 뿐입니다.

1. 사용 서비스와 담당자를 적으세요

서비스 또는 작업, 권한 주체, 운영 환경, 필요한 리소스와 변경 담당자를 기록합니다. Google Cloud는 서비스 계정을 한 용도로 쓰고 애플리케이션 이름과 연락처를 남기라고 권합니다. 자격증명을 코드에 올린 개발자는 복사본의 출처를 알 수 있지만 현재 서비스 담당자라고 단정할 수는 없습니다.

2. 가능하면 임시 인증을 우선하세요

AWS는 워크로드에 역할 기반 임시 자격증명을 권합니다. Google Cloud는 환경이 지원하면 연결된 서비스 계정이나 워크로드 신원 연합을 권합니다. 이런 방식은 고정 키의 배포를 줄이지만, 부여된 권한까지 안전하게 만들어 주지는 않습니다. 장기 키가 꼭 필요한 연동이라면 이유와 교체 담당자를 기록하세요.

3. 권한 범위를 발급처에서 확인하세요

발급 서비스에서 허용된 작업, 리소스, 조건을 확인하고 실제 사용 기록과 비교해 불필요한 권한을 줄입니다. 넓은 권한을 가진 키를 안전한 곳에 보관해도 IAM 권한은 그대로입니다. 서비스나 연동이 바뀔 때 권한도 다시 검토하세요.

4. 남겨야 하는 키의 복사본을 관리하세요

저장소, 티켓, 빌드 결과물에 자격증명을 남기지 마세요. Docker는 빌드 시크릿에 빌드 인자나 환경 변수 대신 시크릿 마운트를 권합니다. 값이 이미지에 남을 수 있기 때문입니다. 보관 방식은 키 종류와 플랫폼에 따라 선택해야 합니다. Google Cloud는 가능한 경우 사용자 관리 서비스 계정 키 자체를 피하라고 하며, 그 키를 Secret Manager에 넣어 보관·회전하는 방식을 일반 해법으로 권하지 않습니다. 남는 키의 접근 권한과 사용 기록을 제한·확인하세요.

5. 평소 교체와 노출 대응을 구분하세요

정기 교체는 의존 워크로드를 찾고, 새 키를 배포해 사용을 확인한 다음 기존 키를 무효화하는 순서로 계획합니다. 실제 키가 노출됐다면 발급처에서 신속히 조치하고, 확인 가능한 접근 로그와 다른 복사본을 조사하세요. GitHub도 저장소 기록을 정리하기 전에 키를 폐기·교체하라고 권합니다. 파일을 지워도 이미 만들어진 복사본은 회수되지 않습니다. 단기 토큰이라도 사용 흔적이 없다고 단정할 수는 없습니다.

6. 서비스 종료와 함께 권한을 정리하세요

애플리케이션이나 연동이 끝나면 부여한 권한을 제거하고, 쓰지 않는 신원을 비활성화하며, 남은 키를 폐기하고 의존 서비스가 없는지 확인합니다. Google Cloud는 미사용 서비스 계정을 삭제하기 전에 비활성화하라고 권합니다. OWASP도 종료 처리 누락과 시크릿 노출을 별도 위험으로 다룹니다. 한 소스의 검사 결과가 깨끗하다는 이유로 오래된 권한까지 정리됐다고 볼 수는 없습니다.

Cremit이 돕는 범위

Cremit은 지원하는 연결 소스에서 자격증명 패턴을 찾고, 지원 유형의 발급처 상태를 확인합니다. 확인 가능한 AWS·GCP 접근 정보와 담당자 단서를 발견 결과에 모읍니다. 모든 실행 중인 워크로드를 열거하거나, IAM 역할을 설정하거나, 모든 키를 보관·교체하거나, 악용을 입증하지는 않습니다. 서비스 담당자가 필요한 권한을 결정하고 발급처 대응과 종료 처리를 마쳐야 합니다.