본문 바로가기
기술 단어장/Cloud

[Cloud] SKT의 유심교체 사태로 보는 AWS S3 보안

by MFDO 2025. 4. 28.

 

 

최근 SKT의 유심 정보 유출 사고로 인해 유심 교체 대란이 이어지고 있다.

많은 사람들이 몰리고 있는 가운데, 나는 KT라 비교적 맘놓고 있지만

이러한 많은 트래픽은 내 심장을 두근거리게 하기 충분했다.

 

 

SKT 유심 교체, 온라인 대기인원 7만명…"현장이 낫겠다"(종합) : 네이트 뉴스

한눈에 보는 오늘 : 사회 - 뉴스 : T월드 앱 화면 ⓒ 뉴스1 (서울=뉴스1) 손엄지 김정현 기자 = SK텔레콤(017670)이 유심 정보 해킹 이후 무상 유심 교체를 시작한 28일 현장은 물론 온라인에서도 혼란

news.nate.com

 

 

SK텔레콤 유심 정보 유출 사고

2025년 4월 19일 SK텔레콤 의 홈 가입자 서버(HSS) Home Subscriber Server, 가입자

namu.wiki

 

 

 

인상 깊었던 페이지는 서비스 지연 오류 페이지다.

지연 안내를 위한 페이지 주소가 아래처럼 노출되어있다.

https://s3-tworld-prd-an2-cdn-origin-mobile.s3-ap-northeast-2.amazonaws.com/skt/html/flow_control_page_throttled.html?v=1745800380319

 

T world

 

s3-tworld-prd-an2-cdn-origin-mobile.s3-ap-northeast-2.amazonaws.com

 

 

 

하지만 문제는 단순히 '페이지 노출'에 그치지 않았는다.
이 주소를 자세히 들여다보면, AWS S3 버킷 정보가 고스란히 드러나 있음을 알 수 있다.

따땃한 시선을 보이는 대중

 

 

 

 

 


문제 발생 흐름

 

 

 

 

  • 정식 서비스 링크:
  • 문제 발생 구간:
    • 트래픽이 많을 때, 신청 과정에서 사용자 요청이 서버까지 정상적으로 처리되지 못하고, 정적 파일을 보여주는 상황 발생
  • 문제의 정리 포인트:
    • 트래픽 overload 상황이 발생하면 백엔드에서 준비해둔 정적 에러 페이지로 리다이렉트 또는 연결
    • 그런데 이 에러 페이지가 CloudFront 등을 거치지 않고, S3 원본 URL로 노출된 것

 

 

메인 서비스 흐름은 괜찮...?았지만,
트래픽 과부하 시 보여주는 대기 페이지 처리 과정에서,
보안과 운영 품질이 미흡했다

 

 

 


 

 

 

문제 상황

 

1. 대기 안내 페이지 처리 방식의 문제

  • 대기 안내용 페이지를 AWS S3에 저장해두고, 트래픽 과부하 시 이 페이지를 보여주는 구조
  • 그런데 문제는, 이 페이지 URL이 S3 원본 주소(s3.amazonaws.com) 그대로 노출되었다는 점.

노출된 URL:
https://s3-tworld-prd-an2-cdn-origin-mobile.s3-ap-northeast-2.amazonaws.com/skt/html/flow_control_page_throttled.html?v=1745800380319

 

 

 


 

 

2. CloudFront 같은 보호 계층 없이 S3 직노출

  • CloudFront, WAF 등 보호 레이어 없이
    S3 버킷 주소가 사용자에게 직접 노출.
  • 결과적으로
    • 버킷 이름
    • 리전 정보(ap-northeast-2)
    • 파일 경로 구조
      등이 외부에 모두 드러나게 됨.

보안상 바람직하지 않은 상황.

 

 

s3-tworld-prd-an2-cdn-origin-mobile
  • s3-tworld ➔ SKT tworld 서비스 관련
  • prd ➔ production 환경 (운영 서버용)
  • an2 ➔ AWS 리전 "ap-northeast-2" (서울 리전)와 연결됨
  • cdn-origin-mobile ➔ 모바일용 CDN 원본 파일이라는 의미로 보임

=> 운영환경(prod), 모바일 관련(static origin) 파일이구나!

 

 

 

 

ap-northeast-2
  • AWS 서울 리전 (이건 조금 당연할 수 밖에 없긴 하다...ㅎㅎ)

=> 인프라의 지리적 위치 파악 

 

 

 

 

 

/skt/html/flow_control_page_throttled.html
  • 서비스명(sk telecom) 관련 디렉토리 /skt/
  • html 정적 페이지 디렉토리 /html/
  • flow_control_page_throttled.html ➔ 트래픽 제어(쓰로틀) 안내 페이지 파일

=> 서비스 내부 디렉토리 구조 스타일도 살짝 드러남 (히히 skt는 이렇게 관리하는 구나 신기하다)

 

 

 

 

 

?v=1745800380319
    • v=숫자는 버전 관리를 위한 쿼리 스트링으로 보임
    • 보통 정적 파일 캐싱을 제어하거나, 파일 업데이트 시 버전 구분을 위해 씀
      소소팁: 파일 업데이트 시 캐시를 강제로 갱신하기 위해, S3 URL 끝에 쿼리 스트링(?v=숫자)을 붙여 관리하는 방식이 흔히 사용되는데, 이로 인해 브라우저는 같은 파일 이름이라도 새로운 파일처럼 인식하고 최신 버전을 다시 다운로드 함

=> 파일 업데이트/버전 관리 방식이 유추 가능

 

 

 

s3-xxx.amazonaws.com
  • 만약 CloudFront를 썼으면 보통 cdn.example.com 같은 깔끔한 커스텀 도메인 형태였을 것
  • 이 URL로 누구나 접속 가능하다는 건, 버킷 자체가 퍼블릭하거나
    버킷 정책(Bucket Policy)이나 프리사인드 URL 없이 퍼블릭 객체로 공개됐다는 걸

=> CloudFront 같은 CDN을 안 거치고 S3 원본에 직접 접근하고 있다

 

 

 

 

 


 

 

 

 

 

3. 트래픽 상황에 따른 유동적 대응 부재

  • "현재 서비스가 혼잡합니다" 같은
    고정된 안내 페이지만 무조건 제공.
  • 트래픽 부하 정도에 따라 다른 안내나 동적 컨텐츠 제공이 없음.
  • 사용자 경험(UX) 관점에서도 아쉬운 대응.

 

 

 


 

 

 

 

어떻게 대응했다면 더 좋을까?

메인 서비스는 정상적으로 돌아가되, 장애 발생 시 안정적으로 오류 페이지를 제공하려면,
CloudFront Origin Group 기능을 사용하여 Primary Origin(메인 서버)과 Secondary Origin(S3 정적 페이지)을 구성
이때 S3 버킷은 퍼블릭 접근을 차단하고, CloudFront를 통해서만 접근할 수 있도록 설정하여 보안까지 강화하는 것

 

 

 

 

 

 

 

Q. 길어도 한 3개월 쓸 페이지에 너무 깐깐하신거 아닌가?

보안 복습할 거리라 조금 신난 감도 있지만, 너무 기초적인 내용이라 놀랐기도 하다.

CloudFront는 단순히 콘텐츠를 빠르게 전달하기 위한 서비스가 아니다.

 


CloudFront를 사용하면 S3 버킷을 외부에 직접 노출시키지 않고,
트래픽을 전 세계 엣지 로케이션으로 분산시켜 부하를 줄이며,
콘텐츠 요청에 대한 보안 경계를 만들고, 비용 또한 최적화할 수 있다.

 

 

S3 버킷을 세상에 직접 드러내지 않는 것, CloudFront를 세상에 노출시키는 것
AWS에서 안전하고 신뢰할 수 있는 콘텐츠 서비스를 구성하는 기본 원칙이다.
이 원칙은 대기업이든 개인 개발자이든 예외 없이 적용되며,

CloudFront는 단순한 성능 향상을 넘어, 보안, 비용 절감, 서비스 품질 유지를 위해 반드시 사용해야 하는 인프라 구성 요소다.

 

 

 

 

 

Q. 대기업 S3 URL을 직접 보는 것은 흔한 일인가?

정상적으로 운영되는 서비스라면,

사용자는 CloudFront를 통해서만 콘텐츠에 접근할 수 있으며,

S3 버킷 원본 URL이 외부에 노출되는 일은 절대 없어야 한다.

 

 

그러나 이번 사례처럼,

시스템을 급하게 구축했거나, 보안 정책을 제대로 설정하지 못했거나,

트래픽 폭주 대응을 임시방편으로 처리했을 때,
이러한 실수가 발생할 수 있다.

 

 

정상적인 구조에서는 일반 사용자가 S3 주소를 직접 확인할 수 있는 상황 자체가 발생하지 않는다.
따라서 이번 사례는 운영 체계의 미흡함과 대응 프로세스의 허점을 보여주는 하나의 징후로 볼 수 있다.

나는 그저 이런 임시 페이지는 이렇게 운영해도 되는가? 라는 내용으로 신기했을 뿐도 있기도 하다.

 

 

 

 

 

Q. 비용적으로 치명적일까?

Cloud Front는 비용 절감효과를 준다.

페이지가 작아서 큰 손실은 없겠지만, S3만을 사용했을 때 얼마나 비용적 손실이 있는가 계산해보자.

 

 

해당 기사에 따르면 가입자 수는 2,500만명 이다.

대략 다운로드 받아 확인해봤다

Crtl + S해서 페이지 다운받아왔고, 약 5.27KB를 사용한다.

 

 

 

 

시나리오에 따른 예상 접속자 수

: 실제 접근할 대략적 유저를 추정해본다.

관점 에러 페이지 접근 % 대략 적인 접근 명수
보수적 0.1% 25,000명
현재 사건 수준 0.5% 125,000명
대란 1% 250,000명

 

 

 

 

 

시나리오에 따른 예상 비용

시나리오 접속자 수 총 트래픽량 (계산식) 트래픽량 (GB) S3 전송 요금 (계산식) 총 요금 (약)
0.1% 25,000명 5.27KB × 25,000 = 131,750KB 약 0.1287GB 0.1287GB × $0.114/GB 약 20원
0.5% 125,000명 5.27KB × 125,000 = 658,750KB 약 0.6433GB 0.6433GB × $0.114/GB 약 100원
1% 250,000명 5.27KB × 250,000 = 1,317,500KB 약 1.287GB 1.287GB × $0.114/GB 약 200원

 

 

표로 보아도 알 수 있듯 비용은 아주 차이가 없다!

 

 

 

 

 


 

소소한 소감

 

 

 

이번 SKT 유심 교체 대란 사례를 통해,
짧은 기간 사용하는 단순한 안내 페이지라도
보안운영 품질 측면에서 세심한 관리가 필요하다는 사실을 다시금 느낄 수 있었다.

 

 

 

CloudFront와 같은 보호 계층 없이 S3를 직접 노출하는 것이,
단순한 비용 절감이나 빠른 대응을 위해 선택될 수는 있지만,
결국 장기적으로는 서비스 신뢰성과 기업 이미지를 해칠 수 있는 위험을 동반한다는 점도 새삼 깨달았다.

 

 

또한 실제 트래픽과 비용을 계산해보면서,
단순히 페이지 크기나 기간만 보고 가볍게 판단해서는 안 된다는 것도 느꼈다.
20만 명 이상 사용자가 몰리는 순간, 사소해 보였던 설정 하나가 서비스 품질과 기업 신뢰를 좌우할 수 있다.

 

 

 

짧게 운영할 페이지라도,
최소한의 보안 수칙을 지키는 것이 결국
기업과 사용자를 모두 보호하는 길임을 다시 한번 깊이 이해하게 된 경험이었다.

 


 

+ 25.04.29 - 유심보호 서비스 가입 버튼이 생겼다

댓글