AWS 키가 유출됐다면 파일 삭제부터 하면 안 되는 이유

AWS 액세스 키가 공개됐다면 파일 삭제보다 자격 증명 통제가 먼저다. 이미 복제된 키는 원본 파일과 무관하게 인증에 쓰일 수 있으므로 권한과 사용처를 확인한 뒤, 위험이 크면 즉시 비활성화하고 새 자격 증명 배포와 침해 조사를 이어가야 한다.

운영 중인 애플리케이션이 해당 키에 의존한다면 삭제부터 하는 것도 안전하지 않다. 삭제는 되돌릴 수 없어 장애 대응 여지를 없애므로, 권한이 제한적이고 즉각적인 악용 위험이 낮을 때만 짧은 전환 시간을 두고 새 키를 먼저 배포한다. 민감한 데이터나 관리자 기능에 접근할 수 있다면 서비스 연속성보다 차단을 우선한다.

1. 노출 파일이 아니라 키 자체를 통제한다

Git 커밋, CI 로그, 컨테이너 이미지, 패키지 또는 공개 데이터셋에 키가 나타났다면 유출된 것으로 취급해야 한다. 현재 파일을 지워도 Git 이력, 포크, 캐시, 빌드 산출물과 이미 내려받은 복사본에는 값이 남을 수 있다. 파일 정리는 필요하지만 자격 증명 무효화를 대신하지 못한다.

액세스 키 ID로 소유 AWS 계정과 IAM 사용자를 식별하고, 사용자·그룹 정책과 수임 가능한 역할을 확인한다. 루트 액세스 키이거나 관리자 권한, IAM 변경 권한, 조직 관리 계정 접근 권한, 민감한 데이터의 읽기·쓰기 권한이 있다면 우선 차단해야 한다. 권한이 불분명한 경우에도 낮은 위험이라고 추정해서는 안 된다.

AWS의 노출 키 대응 절차 는 먼저 자격 증명의 접근 범위를 판단하고, 민감한 데이터에 접근할 수 있다면 신속히 비활성화하도록 안내한다. 삭제보다 비활성화를 먼저 권하는 이유는 예상하지 못한 애플리케이션 장애가 생겼을 때 제한적으로 복구할 수 있기 때문이다. 반대로 공개 예정 데이터의 읽기처럼 권한이 제한적이라면 새 자격 증명을 배포한 뒤 기존 키를 끊는 순서를 선택할 수 있다.

2. 서비스 중단을 관리하며 자격 증명을 교체한다

교체는 새 키를 만드는 작업이 아니라 기존 키의 모든 사용처를 새 자격 증명으로 옮기고, 노출된 키를 차단한 뒤 삭제하는 과정이다. 전환 구간은 가능한 한 짧게 잡고 종료 시각과 담당자를 정해야 한다.

1. 사용처를 목록화한다. 배포 환경 변수, CI/CD 보안 변수, 공유 자격 증명 파일, 서버리스 함수 설정, 컨테이너 시크릿, 외부 자동화 도구를 확인한다. 예약 작업과 여러 리전에서 실행되는 워크로드도 포함한다.
2. 새 자격 증명의 권한을 줄인다. 기존 정책을 그대로 복제하지 말고 필요한 API 작업, 리소스, 리전과 조건을 다시 정한다. 과도한 권한까지 새 키에 복사하면 사고 원인을 남기는 셈이다.
3. 새 자격 증명을 배포하고 검증한다. 정상적인 읽기·쓰기 호출과 배치 작업을 실행해 권한 부족과 배포 오류를 구분한다. 키를 여러 애플리케이션이 공유했다면 각각 검증한다.
4. 기존 키를 비활성화한다. 인증 실패와 애플리케이션 오류를 관찰해 빠진 사용처를 찾는다. 재활성화가 불가피하다면 원인을 고치는 짧은 시간에만 허용하고 종료 시각을 다시 정한다.
5. 전환이 끝나면 삭제한다. 삭제 시각, 담당자, 영향을 받은 서비스와 대체 자격 증명의 소유 주체를 사고 기록에 남긴다.

노출된 장기 키로 발급한 임시 자격 증명은 원본 키를 교체해도 남은 유효 시간 동안 작동할 수 있다. 따라서 STS 발급 기록과 세션 경로를 별도로 확인해야 한다. 루트 액세스 키였다면 새 루트 키를 만드는 방식으로 복구하지 말고, 필요한 작업을 제한된 관리 주체나 역할로 이전한 뒤 루트 키를 제거한다.

3. CloudTrail에서 오용과 잔존 접근을 조사한다

키를 차단해도 이미 수행된 작업은 되돌아가지 않는다. 노출 가능 시점부터 비활성화 시점까지 CloudTrail 이벤트를 액세스 키 ID로 조회하고, 평소와 다른 소스 IP, 리전, 사용자 에이전트, 호출 시간과 API 작업을 비교한다. 성공한 호출뿐 아니라 거부된 요청도 권한 범위를 탐색한 흔적일 수 있다.

IAM 사용자·액세스 키·역할·정책의 생성 또는 변경, STS 세션 발급, 로깅 설정 변경부터 살핀다. 이어 S3 데이터 접근과 EC2·Lambda 등 비용을 발생시킬 수 있는 리소스의 생성 여부를 확인한다. 새 사용자, 신뢰 정책 또는 역할처럼 노출 키를 폐기한 뒤에도 접근을 유지하게 하는 변경은 제거 대상이다.

AWS 액세스 키 보안 지침 은 CloudTrail 로그로 AWS에서 누가 작업을 수행했는지 검토하도록 안내하며, 키 ID를 이용해 소유 계정을 확인하고 임시 키라면 STS 이벤트에서 발급 주체를 조사할 수 있다고 설명한다. 다만 조사 기간이나 리전이 빠졌거나 필요한 데이터 이벤트를 사전에 기록하지 않았다면 로그에 의심스러운 항목이 없다는 이유만으로 미사용을 단정할 수 없다. 확인한 범위와 로그 공백도 사고 기록에 남겨야 한다.

4. 차단 후 공개 흔적과 복제본을 정리한다

자격 증명을 무효화한 다음 저장소의 현재 브랜치와 이력, 릴리스 파일, CI 로그, 컨테이너 이미지, 패키지와 공개 데이터셋에서 키를 제거한다. 플랫폼의 삭제나 비공개 전환 기능을 사용하되 이미 만들어진 포크, 미러와 다운로드 사본까지 회수됐다고 가정하지 않는다.

파일 삭제만으로 부족하다는 점은 실제 노출 자료에서도 확인된다. Truffle Security는 2022년 8월부터 2026년 8월 사이 공개된 완전한 AWS 자격 증명 10,616개를 2026년 8월 10일 재검증했으며, 조사 대상의 88%가 여전히 인증되고 그중 기업 관련 활성 키 768개가 계정 전체를 통제할 권한을 보유했다 고 밝혔다. 768개는 루트 키 526개와 AdministratorAccess가 연결된 IAM 사용자 키 242개로 구성됐다. 연구의 재검증은 읽기 전용 메타데이터 호출로 수행됐으므로, 이 수치는 모든 공개 키의 악용 여부가 아니라 조사 표본의 활성 상태와 권한을 뜻한다.

같은 값이 다른 저장소, 위키, 티켓, 메신저, 로컬 설정 예제와 배포 템플릿에 복사됐는지도 검색한다. 내부 기록에 비밀 값을 남겨야 한다면 원문 대신 키 ID와 폐기 상태를 기록하고 접근을 제한한다. 유출된 실제 비밀 값을 탐지 규칙의 테스트 샘플로 다시 커밋해서는 안 된다.

5. 장기 키를 역할 기반 임시 자격 증명으로 바꾼다

복구의 종료 조건은 새 장기 키가 작동하는지가 아니라 같은 노출 경로를 줄였는지다. EC2, ECS, EKS, Lambda 등 AWS에서 실행되는 워크로드에는 서비스에 맞는 IAM 역할을 연결한다. CI/CD는 제공자가 지원하면 OIDC 연동과 역할 수임을 사용하고, 사람의 접근은 IAM Identity Center나 조직의 자격 증명 공급자를 통한 세션 방식으로 전환한다.

AWS 지침에 따르면 IAM 역할로 얻은 임시 보안 자격 증명은 정해진 시간이 지나면 만료되지만 IAM 사용자와 루트 사용자의 장기 액세스 키는 수동으로 취소할 때까지 유효하다. 루트 액세스 키는 만들지 않는 것이 원칙이며, 기존 루트 키가 있다면 사용처를 이전한 뒤 비활성화하고 제거해야 한다.

장기 키를 즉시 없앨 수 없는 외부 시스템이라면 애플리케이션별로 키를 분리하고 최소 권한, 소유자와 검토 기한을 지정한다. 대응은 노출 키의 비활성화·삭제, 대체 자격 증명 배포, CloudTrail 조사, 잔존 접근 제거, 공개 흔적 정리와 역할 전환 계획이 모두 확인돼야 끝난다.