도메인 하이재킹, 그리고 GuardDuty로 다시 잠들기 — 보안 사고 대응기

AWS에 관해서는 별다른 문의가 없던 나날이 이어지던 어느 날, 뜻밖의 문의가 하나 들어왔다. 회사 홈페이지에 접속했는데, 전혀 엉뚱한 외부 사이트로 접속된다는 문의였다. 확인해 보니 스팸성 사이트로 연결되고 있었다. www가 붙은 도메인은 정상이라는 점이 그나마 다행이었지만, 회사 홈페이지가 스팸 사이트로 연결되는 이상 긴급 대응이 필요한 상황이었다.

다행히 원인 자체는 금방 찾을 수 있었는데, CLI로 CloudFront 배포의 오리진이 가리키는 S3 버킷을 조회하자 금방 실마리를 잡을 수 있었다. 확인해 보니 분명 CloudFront는 우리 것인데, 오리진으로 지정된 버킷은 우리 것이 아니었던 것이다. 해당 S3 버킷이 스팸 사이트로 리디렉션하도록 설정되어 있었고, 그 때문에 회사 도메인으로 접속하면 스팸 사이트로 넘어가고 있었다. 무슨 일이 벌어진 걸까?

당연히 우리 자신이 우리 버킷도 아닌 스팸 버킷을 CloudFront가 참조하도록 세팅한 건 아닐 테다. 나는 최근 어느 시점에서 누군가 IAM 계정 중 하나의 API 키를 탈취하여 우리의 기존 S3 버킷을 제거하고, 신규 스팸 S3 버킷을 생성하여 CloudFront 오리진을 대체했다고 가정했다.

그래서 CloudTrail 이벤트를 조회하여 해당 버킷이 어떠한 경위로 삭제된 것인지를 추적해봤다.

aws cloudtrail lookup-events --no-cli-pager --output json ...

일단 추적으로 x2-s3upload라는 특정 IAM 계정이 버킷 삭제 API로 기존 버킷을 삭제한 걸 확인했다. 보안적으로 꽤나 긴급한 사안이라 판단하여 일단 해당 계정의 API키를 전부 급히 비활성화했다. 다만 삭제까지는 진행하지 않았다. 해당 키에 의존하는 다른 시스템이 있어 연쇄 장애가 날 수 있으니, 복구 여지를 남겨두는 편이 낫다고 판단했기 때문이다. 이어서 CloudFront 오리진을 정상 S3 리소스로 재설정하고, CloudFront 캐시 무효화를 수행했다.

이렇게 해서 회사 홈페이지 도메인 접속 시 스팸 사이트로 리다이렉트되는 현상은 일단 해결했다. 하지만 정말 중요한 것은 따로 있었다. 첫째, 이런 현상이 근본적으로 왜 발생했는지 밝히는 것. 둘째, 비슷한 사고가 다시 터졌을 때 빠르게 대응할 수 있는 체계를 확립하는 것이었다.

그렇다면 첫째, 왜 이런 일이 벌어졌을까? 근본 원인은 최소 권한 원칙이 지켜지지 않았다는 데 있었다. 계정마다 필요 이상의 IAM 권한이 부여되어 있었던 것이다. 가령 이번에 문제가 된 x2-s3upload 계정에는 AmazonS3FullAccess와 AmazonEC2ContainerRegistryFullAccess가 부여되어 있었다. 이 때문에 계정의 API 키가 탈취되면 사내 S3 버킷과 ECR 이미지를 마음대로 삭제할 수 있는 상태였다. 더군다나 이 계정 이외에도 IAM 권한이 과도하게 주어진 계정이 몇 가지 있었다. 나는 이들 계정에서 보안상 위험할 수 있는 권한을 모두 회수하고, 업무에 꼭 필요한 최소 권한만 남도록 재설정했다.

둘째, 사전 예방이 최우선이겠지만 만약 비슷한 사고가 다시 발생한다면 어떻게 최대한 빠르게 대응할 수 있을까? 나는 이런 사태에 가급적 실시간으로 대처할 수 있도록, AWS GuardDuty와 MS Teams를 연동한 실시간 탐지 체계를 구축했다.

GuardDuty (탐지) → EventBridge (심각도 필터링) → SNS → Lambda → Teams 알림

구성은 GuardDuty가 위협을 탐지하면 EventBridge가 심각도를 기준으로 걸러 SNS로 넘기고, SNS가 Lambda를 호출해 Teams로 알림을 보내는 흐름이다. 먼저 GuardDuty Detector를 활성화했고, EventBridge 규칙에는 심각도 4.0 이상(MEDIUM 이상)의 finding만 통과시키는 숫자 필터를 걸었다. 낮은 심각도의 알림까지 모두 보내면 알림이 쌓여 정작 중요한 신호를 놓치기 쉽기 때문이다. 그리고 SNS 토픽을 만들어 EventBridge가 이 토픽에 발행할 수 있도록 권한을 설정했다.

이러한 시스템이 정말 효과가 있을까? 놀랍게도, 시스템을 도입하자마자 또 다른 문제 지점을 찾아낼 수 있었다. 이번 사고와는 별개로, 개발용 RDS 인스턴스에 알려진 악성 IP가 접근을 시도했다는 GuardDuty 알림이 Teams로 들어온 것이다. 다행히 인증 시도까지는 이어지지 않았지만, 원인은 해당 RDS에 적용된 보안 그룹의 인바운드와 아웃바운드 규칙이 모두 0.0.0.0/0으로 열려 있었기 때문이었다. 외부 어디서든 DB에 접근할 수 있는 상태였던 셈이다. 실시간 탐지 체계를 갖추지 않았다면 알아채지 못했을 위험을 발견한 것이다. 이 보안 그룹은 인바운드와 아웃바운드 규칙을 필요한 범위로만 제한하도록 수정해 해당 위험을 해소했다.