회사에서 진행하던 프로젝트에서 AWS에 심각한 보안 문제가 발생했다. 승인되지 않은 개체가 우리 환경에 액세스하여 모든 지역에 걸쳐 여러 ECS 작업을 생성하고 심각한 재정적 및 운영적 피해를 받았다. 이 글에서는 침해를 식별하고 대응하기 위해 취한 단계와 향후 사고를 예방하기 위해 배운 교훈을 적어보았다.
초기 AWS 해킹(9월 6일) switch role 로 full access가 되는 정책으로 변환한 후 접근한 사례
해킹은 금요일 오후에 시작되었고 발견은 월요일 오후에 aws에서 온 메일을 확인하여 알게되었다. 이 시점에서 공격자는 이미 모든 지역에서 여러 ECS 작업을 시작했으며 지역당 약 20개의 작업이 실행되었다. 해킹이 어떻게 발생했는지에 대한 분석은 다음과 같다.
- 초기 진입: (해커) 최초에 root권한을 가진 access key, 또는 root id가 탈취됨 (정확하게 최초 진입이 어디인지는 확인이 불가능)
- 역할 전환 및 전체 액세스 정책: (해커) access key로 역할중 하나에 full access 정책을 하나 추가함
- ECS 작업 생성: 모든 리전을 열고 ECS및 TASK생성( 9월 6일 금)
- AWS 감지 및 알림: (aws) 이상함 인지 후 메일 알림
- 우리의 조치 : (우리) 확인 후 aws 절차대로 비밀번호변경, mfa설정, 기존 IAM 삭제 및 재생성, 탈취 될 수 있는 코드 수정, cloud trail 설정 (9월 9일 월)
비용 영향: 이번 초기 침해로 인해 약 1,300만원의 비용이 발생했다.
두 번째 위반(9월 12일) 해결된줄 알았으나 다시 같은 방식으로 해킹이 시도된 사례
- CloudTrail 로그: (우리) 클라우드 트레일 점검- 해커의 최초 진입점이 switch role인것을 확인
- IAM 역할 조사: iam 역할을 들어가서 하나하나 확인해보니 RDS쪽 정책중에 full access가 있는것을 확인
- 신뢰 정책 취약성: 그 full access 정책중 신뢰할 수 있는 정책에 principal에 해커의 iam arn을 넣으면 switch role이 될 수 있는것을 확인
- 전체 액세스 정책 제거: 위 full access 정책 삭제 (9월 12일)
AWS 보안 위반에서 배운 교훈
- mfa설정
- 코드 상에서 aws 기능을 사용해야 할 경우 최소권한으로 IAM을 만들어서 사용하기
- 메일은 매일 특정시간을 두고 확인하기
- 실수로라도 클라이언트단에 IAM 키를 갖고 사용하고있지 않은지 체크
결론
이번 AWS 위반은 특히 민감한 데이터와 인프라를 처리할 때 클라우드 보안이 얼마나 중요한지 상기시켜 주었다. MFA, 제한된 IAM 역할, 일일 모니터링과 같은 보안 조치를 구현하면 무단 액세스 및 악의적 활동으로부터 조금이나마 안전하게 보호할 수 있다. AWS는 보안 책임의 대부분을 사용자에게 맡기고 있다. 따라서 작은회사여서 괜찮겠지 라고 생각했던 나 자시늘 반성하며 최소한의 보안은 신경써야 한다는 교훈을 주었다.