
1. 개요
1.1 사고 배경
McGraw Hill은 미국을 대표하는 3대 교육 콘텐츠 출판사 중 하나로, 100년 이상 교육 출판 산업을 이끌어온 기업입니다. 온라인 학습 플랫폼을 통해 미국과 캐나다 전역의 대학교 수백 곳에 디지털 교재, 과제 관리, 성적 관리 서비스를 제공하고 있으며, Johns Hopkins University, University of Michigan, UCLA, 캐나다의 McGill University 등 유수의 명문 대학이 고객입니다.
이 사건은 보안 연구자 그룹 vpnMentor가 2022년 6월 12일 정기적인 웹 스캐닝 과정에서 발견한 것으로, McGraw Hill의 온라인 학습 플랫폼 운영 데이터를 저장하는 두 개의 AWS S3 버킷이 공개 접근 가능한 상태로 설정되어 있었습니다. 연구자들이 처음 발견 시점 기준으로 해당 버킷들은 2015년부터 약 7년간 인터넷에 노출된 상태였으며, 웹 브라우저만 있으면 누구나 파일 목록 조회 및 다운로드가 가능한 상태였습니다. 전체 노출 규모는 약 22TB, 1.17억 개 파일에 달했으며, 10만 명 이상의 학생 개인정보뿐만 아니라 McGraw Hill 자체의 소스코드와 암호화 키까지 포함되어 있었습니다.
1.2 사고 요약
이 사건은 공격자의 침입이 전혀 없었음에도 불구하고 기본적인 S3 보안 설정 하나가 누락된 결과로 대규모 데이터가 장기간 외부에 노출되었습니다. 노출된 두 개의 버킷 중 하나는 프로덕션 용도 (약 4,700만 개 파일, 12TB 이상), 다른 하나는 비프로덕션 용도 (약 6,900만 개 파일, 10TB 이상)였습니다.

노출된 데이터에는 다음과 같은 데이터들이 포함되어 있었습니다. - 학생 이름, 이메일 주소, 대학 소속 정보가 포함된 스프레드시트 - 각종 과제의 학생별 성적 기록 - 교수자의 강의 자료, 강의계획서 - McGraw Hill의 온라인 학습 플랫폼 소스코드 - 플랫폼 내부 통신에 사용되는 디지털 암호화 키 및 인증 키
2. 노출 경로 분석
2.1 전체 흐름
- McGraw Hill이 온라인 학습 플랫폼 운영 데이터를 AWS S3에 저장하기 위해 프로덕션 버킷과 비프로덕션 버킷 두 개를 생성
- 버킷 생성 또는 운영 과정 중 어느 시점에서 Block Public Access 설정이 비활성화되고 버킷 정책 또는 ACL이 공개 읽기를 허용하도록 변경됨 (정확한 시점은 2015년경으로 추정)
- 해당 버킷에 학생 PII, 성적, 소스코드, 암호화 키 등 민감 데이터가 지속적으로 축적됨
- 약 7년간 해당 설정이 감지되지 못한 채로 운영됨
- 2022년 6월 12일 vpnMentor 연구팀이 AWS 버킷 스캐닝 중 발견
- 7월 20일 McGraw Hill이 내부적으로 파일 제거 및 설정 수정
2.2 단계별 노출 프로세스
1. 최초 버킷 생성 및 설정 오류
McGraw Hill이 언제 최초로 해당 버킷들을 생성했는지 정확히 알려지지는 않았으나, 파일의 최초 수정 시점을 기준으로 2015년부터 공개 접근 가능한 상태였다는 점이 확인되었습니다. 2015년은 AWS S3의 기본 보안 정책이 현재보다는 느슨했던 시기로, Block Public Access 기능이 존재하지 않았으며 (이 기능은 2018년 11월에 도입됨), 버킷 생성 시 기본 ACL이 private이긴 했지만 관리자가 실수로 ACL을 public-read로 변경할 경우 공개 접근이 즉시 허용되는 구조였습니다. McGraw Hill의 경우 정확한 설정 오류의 원인이 공개되지 않았습니다.
2. 장기간 감지 실패
이 사건의 또 하나의 문제는 설정 오류 자체가 아니라 7년간 해당 오류를 탐지하지 못했다는 점입니다. 2022년 자사의 정기 테스트 과정에서 뒤늦게 문제를 발견했다고 밝혔으나 이는 연구자의 최초 신고 이후 5주 이상 경과한 시점이었습니다. 이는 탐지 통제와 수단 및 절차의 부재가 심각한 보안 리스크임을 보여주는 사례입니다.
3. 설계 원칙 위반
이 사건에서는 또한 노출된 데이터의 구성이 올바르지 않은 설계를 따랐음을 알 수 있습니다.
- 데이터 분류 및 격리 미흡
-
프로덕션 버킷에 학생 PII와 함께 McGraw Hill의 소스코드 및 디지털 암호화 키가 저장되어 있었다는 점입니다. 소스코드와 암호화 키는 데이터 자체가 아니라 다른 데이터를 보호하는 장치이므로, 일반 사용자 데이터와는 전혀 다른 격리 수준이 필요하며 별도의 AWS 계정, 별도 버킷, 별도 KMS 키 체계로 관리되어야 합니다. 만약 악의적 공격자가 이 암호화 키를 먼저 발견했다면 McGraw Hill의 다른 암호화된 시스템까지 복호화가 가능했을 수 있습니다.
-
프로덕션과 비프로덕션 환경 혼용
-
두 개의 버킷 중 하나가 비프로덕션 용도였다는 점 역시 문제라고 할 수 있습니다. 비프로덕션 환경에는 실제 고객 데이터가 존재하는 것은 바람직하지 않으며, 만약 테스트 목적으로 필요하다면 반드시 비식별화 또는 익명화 처리된 합성 데이터를 사용해야 할 것입니다. 비프로덕션 버킷에도 10TB 이상의 파일이 있었다는 점은 해당 환경에 실제 데이터가 복제되어 사용되고 있었을 가능성이 있습니다.
-
감사 로깅의 부재
- 7년간의 노출 기간 동안 해당 버킷에 누가 언제 접근했는지 확인할 수 있는 CloudTrail Data Events 및 S3 Server Access Logs가 활성화되어 있었는지 McGraw Hill은 공개하지 않았는데, 이런 로그가 없었다면 악의적 행위자의 과거 접근 여부 자체를 확인할 수 없게 되며, 이는 포렌식 수준의 사고 대응 자체를 불가능하게 만드는 요소입니다.
3. 대응 방안
3.1 즉각 대응 절차
이와 유사한 S3 버킷 공개 노출 사고가 의심되는 경우, 가장 먼저 해야 할 일은 해당 S3 버킷의 공개 접근을 즉시 차단하는 것입니다. 이 단계의 목적은 추가적인 외부 접근이 더 이상 발생하지 않도록 우선 노출 상태를 멈추는 데 있습니다. 이후에는 현재 버킷에 적용된 공개 설정이 어디에서 비롯되었는지 확인해야 합니다. S3 공개 노출은 버킷 정책, ACL, 또는 퍼블릭 액세스 관련 설정이 복합적으로 작동해 발생할 수 있으므로, 단순히 한 가지 설정만 바꾸는 것으로 끝내지 말고 전체 접근 설정을 함께 점검해야 합니다. 그리고 공개 허용으로 이어질 수 있는 정책 문구나 권한 항목이 있다면 이를 제거하거나 비공개 상태로 수정해야 합니다.
그리고 접근 기록을 확인하여 실제로 외부 유출이 있었는지 점검하는 과정이 필요합니다. 만약 접근 로그가 남아 있다면, 노출 기간 동안 누가 어떤 방식으로 버킷에 접근했는지 분석하여 실제 악용 가능성을 판단해야 합니다. 이를 통해 단순 설정 오류에 그쳤는지, 아니면 외부에서 파일을 조회하거나 다운로드한 정황이 있었는지를 확인할 수 있습니다. 반대로 충분한 로그가 남아 있지 않다면, 정확한 접근 내역을 확인할 수 없으므로 더 보수적으로 대응해야 합니다. 즉, 필요한 경우에는 노출된 데이터가 실제로 외부에 유출되었을 가능성까지 고려하여 후속 조치를 진행해야 합니다.
- S3 Server Access Logs나 CloudTrail Data Events 등을 이용해 노출 기간 동안 어떤 IP에서 어떤 객체에 접근했는지 확인해야 합니다.
- 또한 어느 버킷 어느 정보에 접근했는지 정확하게 파악하는 것은 사실상 불가능하므로, 노출된 모든 데이터가 유출된 것으로 간주하고 대응하는 것이 바람직할 것입니다.
또한 영향 범위를 구체적으로 식별하는 작업이 필요합니다. 노출된 버킷 안에 어떤 데이터가 저장되어 있었는지, 그리고 그 안에 개인정보나 인증 정보 같은 민감한 내용이 포함되어 있었는지를 분류해야 합니다. 이 과정은 모든 데이터를 전수 조사할 때 어떤 정보가 얼마나 위험한지 판단하고, 대응 우선순위를 정하는 데 필수적입니다. 특히 비밀값, 인증서, 접근 키와 같이 다른 시스템의 보안에도 직접 영향을 줄 수 있는 정보가 포함되어 있었다면, 해당 자격증명은 더 이상 신뢰, 사용할 수 없다고 보고 교체 또는 무효화 조치를 함께 진행해야 합니다.
- 이 과정에서 AWS Macie를 활용하면 자동화된 민감 데이터 분류가 가능하며, PII, 인증 정보, 재무 정보, 건강 정보 등을 자동으로 식별하여 우선순위를 매길 수 있습니다.
마지막으로는 관련 기관과 영향 받은 대상에게 적절히 통보하는 절차가 필요합니다. 데이터 노출 사고는 기술적인 복구만으로 끝나지 않으며, 개인정보나 규제 대상 정보가 포함된 경우에는 법적·제도적 대응이 함께 이루어져야 합니다. 따라서 어떤 정보가 노출되었는지, 언제부터 어떤 방식으로 노출되었는지, 현재 어떤 조치를 취했는지를 정리한 뒤 관련 기관 신고와 정보 주체 통지를 검토해야 합니다. 이때 적용 법령과 통지 의무는 국가와 산업 분야에 따라 다를 수 있으므로, 해당 조직이 적용받는 개인정보 보호법이나 업종별 규제를 함께 확인하는 것이 중요합니다.
- 우리나라의 경우 개인정보 보호법 시행령 제40조에 따라 유출 사실을 인지한 때로부터 72시간 이내에 개인정보보호위원회에 신고하고 정보 주체에게 통지해야 합니다.
- 미국의 경우 주별로 다른 데이터 유출 통보 법률을 따라야 하며, 교육 관련 데이터는 FERPA, 의료는 HIPAA, 결제는 PCI DSS 같은 업종별 규제도 검토해야합니다.
3.2 사후 조치 및 재발 방지
조직 수준의 가드레일 구축
단일 계정 수준의 설정만하기보다는, AWS Organizations의 SCP(Service Control Policy)및 RCP(Resource Control Policy)를 활용한 조직 수준의 가드레일을 구축해야 합니다. 예를 들어 s3:PutBucketPublicAccessBlock 작업을 특정 보안팀 외에는 수행할 수 없도록 제한하는 SCP를 적용하면 개별 개발자의 실수로 공개 설정이 활성화되는 것을 차단할 수 있습니다. 또한 RCP를 활용하면 조직 내 모든 S3 버킷에 대해 익명 사용자의 접근을 어떤 상황에서도 허용하지 않는다는 정책을 강제할 수 있습니다.
지속적 탐지 통제 구축
예방 통제만으로는 부족하며, 설정이 변경되었을 때 즉시 탐지할 수 있는 체계가 필요합니다. AWS Config를 활성화하여 aws managed rule을 적용하면 설정 이탈이 발생할 때마다 자동으로 경고가 발생합니다. 또한 IAM Access Analyzer 를 활용하면 외부 계정이나 익명 사용자에게 노출된 리소스를 자동으로 식별해주며, 조직 전체에 대한 외부 노출 현황을 한눈에 볼 수 있는 대시보드를 볼 수 있습니다. 이 두 서비스의 경고를 EventBridge를 통해 Slack이나 이메일로 실시간 알림받도록 구성하면 오랜 기간 동안 방치되는 것을 막을 수 있을 것입니다.
서버 측 암호화 기본 적용
2023년 1월부터 AWS는 신규 생성되는 모든 S3 버킷에 SSE-S3 암호화를 자동 적용하도록 기본값을 변경했으나, 민감 데이터의 경우 SSE-KMS 또는 고객 관리형 CMK(Customer Managed Key)를 사용한 암호화 또한 가능합니다. SSE-KMS의 장점은 버킷이 공개로 설정되어 있더라도 KMS 키에 대한 접근 권한이 없으면 객체 복호화가 불가능하다는 점입니다. 즉 Block Public Access가 실패하더라도 KMS를 통해 더욱 강력히 보호할 수 있습니다. 고객 관리형 CMK를 사용하면 키 로테이션을 자동화할 수 있으며, KMS 키 정책을 통해 어떤 IAM 주체가 복호화할 수 있는지를 세밀하게 통제할 수 있습니다.
이 밖에도 프로덕션 환경의 S3 버킷에는 S3 Server Access Logs와 CloudTrail Data Events를 활성화하여 객체 접근 기록을 남기도록 해야 합니다 또한 민감한 데이터는 종류와 중요도에 따라 분리해 저장해야 하며 프로덕션과 비프로덕션 환경도 분리해 운영해야 합니다. 그리고 S3 접근 경로는 가능한 한 공개 인터넷이 아니라 VPC Endpoint를 활용해 내부 경로로 제한해야 할 필요가 있습니다.
ref
https://www.vpnmentor.com/blog/report-mcgraw-hill-breach/ https://www.theregister.com/2022/12/20/mcgraw_hills_s3_buckets_exposed/ https://edscoop.com/mcgraw-hill-amazon-s3-data-exposure-student-emails-grades/ https://www.bestcolleges.com/news/student-information-exposed-mcgraw-hill-data-breach/ https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html https://www.boannews.com/media/view.asp?idx=112737