1단계: 노출된 키 즉시 비활성화 (Deactivate)
가장 먼저 할 일은 유출된 키를 더 이상 사용할 수 없게 만드는 것입니다. 삭제(Delete)보다는 비활성화(Deactivate)를 먼저 권장합니다. (추후 로그 분석을 위해 키 ID가 필요할 수 있기 때문입니다.)
방법: IAM 콘솔 → 사용자(Users) → 해당 사용자 클릭 → 보안 자격 증명(Security Credentials) 탭 → Access Key 상태를 'Inactive'로 변경.
2단계: 해당 사용자의 권한 임시 박탈 (Deny All)
키가 비활성화되었더라도, 유출된 키로 이미 생성된 세션이나 다른 취약점이 있을 수 있습니다. 해당 IAM 사용자에게 '모든 거부(Deny All)' 정책을 인라인으로 연결하세요.
Tip: "Deny" 정책은 "Allow"보다 우선순위가 높기 때문에, 기존에 어떤 권한이 있었든 즉시 차단됩니다.
3단계: 침해 사고 조사 (CloudTrail 분석)
공격자가 유출된 키로 어떤 행위를 했는지 파악해야 합니다. CloudTrail 콘솔로 이동하여 최근 24시간 동안 해당 accessKeyId로 발생한 이벤트를 조회하세요.
확인 사항:
신규 IAM 사용자 또는 키를 생성했는가? (Backdoor 생성 여부)
EC2 인스턴스를 대량으로 생성했는가? (코인 채굴 목적)
S3 버킷의 데이터를 외부로 유출(Exfiltration)했는가?
보안 그룹(Security Group)을 0.0.0.0/0으로 개방했는가?
4단계: 리소스 복구 및 정리
조사 결과 공격자가 생성한 리소스가 있다면 모두 삭제합니다.
백도어 제거: 공격자가 새로 만든 IAM 사용자, Role, Access Key를 삭제합니다.
리소스 정리: 무단 생성된 EC2, 스냅샷, 가상 네트워크 등을 삭제하여 과금을 방지합니다.
5단계: 재발 방지 및 보안 강화
동일한 사고가 발생하지 않도록 근본 원인을 해결합니다.
코드 스캔: Git 레포지토리에
git-secrets나trufflehog같은 도구를 도입하여 커밋 전 키 노출을 차단합니다.IAM Role 사용: EC2나 Lambda 내부에서는 Access Key를 직접 하드코딩하지 말고, IAM Role(인스턴스 프로파일)을 사용하도록 아키텍처를 변경합니다.
최소 권한 부여: 사용자에게 필요한 권한만 할당하여, 키가 유출되더라도 피해 범위를 최소화(Blast Radius 제어)합니다.
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.