공항이 또 뚫렸다는 소식, 그런데 눈이 멈춘 지점은 따로 있었다
공항이 해킹당했다는 소식은 이제 놀랍지도 않다. 그런데 이번 사건을 들여다보다가 좀 다른 지점에서 눈이 멈췄다. 유출 규모보다 침입 경로로 지목된 방식이 너무 익숙했기 때문이다.
맨체스터·스탠스테드·이스트미들랜즈 공항을 운영하는 맨체스터 공항그룹(MAG)이 사이버 공격을 공식 인정했다. 이번 맨체스터 공항 해킹 사건은 개인정보 유출 그 자체보다 다른 문제를 드러냈다. 흔하지만 치명적인 API 키 노출 보안사고의 전형을 다시 보여줬다는 점에서 눈여겨볼 만하다. 필자가 보기엔 이 사건의 진짜 교훈은 피해 규모가 아니라 실수의 패턴에 있다.
MAG가 공식적으로 인정한 것과, 아직 인정하지 않은 것
2026년 8월 27일, MAG는 사이버 공격을 받았다는 사실을 공식적으로 확인했다. 노출된 정보는 이메일 주소, 전화번호, 차량 등록번호, 우편번호였다고 밝혔다. 영향을 받은 서비스는 주차장, 라운지, Fast Track 예약, 공항 와이파이 등록 시스템이었다.
MAG는 성명에서 “효과적인 조치를 취했다고 확신한다”는 취지로 밝혔다. 다만 이후 해커 조직이 제기한 구체적인 주장에 대해서는 직접 답하지 않았다. 이 지점이 흥미로운데, 공식 확인과 미확인 주장이 뉴스에서 뒤섞여 보도되는 경우가 적지 않다. MAG는 FulcrumSec의 구체적인 주장에 대해 공식 입장을 밝히지 않았다는 사실은 분명히 짚고 넘어가야 한다.
익스토션 그룹 FulcrumSec의 주장, 사실과 어떻게 구분해야 할까
이 공격의 배후를 자처한 곳은 익스토션(협박) 해킹 그룹 FulcrumSec이다. 이는 어디까지나 해커 측의 자기주장이며, MAG나 제3자가 검증한 사실은 아니다. 개인적으로는 이런 자기주장형 발표를 다룰 때마다 표현 수위를 신중하게 골라야 한다고 느낀다.
FulcrumSec은 처음엔 약 86GB(압축 기준)의 데이터를 탈취했다고 주장했다. 이후 압축 해제 기준으로는 약 640GB에 달한다고 주장을 수정했다. 2026년 하반기 예정된 여행과 관련된 기록도 다수 포함됐다고 알려졌다. 그리고 2026년 9월 3일, FulcrumSec은 탈취했다고 주장한 데이터를 실제로 공개했다.
공식 발표와 해커 측 주장을 나란히 놓고 보면 차이가 뚜렷하다. 아래 표로 정리해봤다.
| 구분 | MAG 공식 확인 사실 | FulcrumSec(해커 측) 주장 |
|---|---|---|
| 사건 발생 인정 | 2026년 8월 27일 공식 확인 | 공격 배후 자처, 시점은 그 이전으로 주장 |
| 노출 데이터 종류 | 이메일, 전화번호, 차량 등록번호, 우편번호 | 위 항목 외 대규모 개인정보 포함 주장 |
| 데이터 규모 | 공식 수치 미공개 | 86GB → 640GB(압축 해제)로 주장 수정 |
| 침입 경로 | 공식 입장 없음 | 클라이언트사이드 노출 Iterable API 자격증명이라 주장 |
| 유출 공개 여부 | 공식 확인 없음 | 2026년 9월 3일 데이터 실제 공개 주장 |
이 표에서 여기서 눈에 띄는 건 ‘침입 경로’ 행이다. 공식 확인이 없는 영역일수록 해커의 서사가 언론을 통해 먼저 퍼진다. 그래서 독자는 어느 문장이 확인된 사실이고, 어느 문장이 주장인지 늘 구분해서 읽어야 한다.
왜 하필 ‘클라이언트사이드 노출’인가 — 흔하지만 치명적인 실수
FulcrumSec은 공항 전용 Iterable API 자격증명이 브라우저에서 실행되는 자바스크립트 코드에 노출돼 있었다고 주장했다. Iterable은 마케팅 자동화와 이메일 발송을 대행하는 SaaS 플랫폼이다. 솔직히 이건 좀 아이러니하다. 가장 화려한 마케팅 자동화 도구가 가장 허술한 문 하나로 뚫렸다는 주장이기 때문이다.
이 실수의 구조는 사실 단순하다. 프론트엔드 코드에 백엔드나 서드파티 API 키가 그대로 박혀 있으면, 누구나 브라우저 개발자도구만 열어도 그 키를 꺼낼 수 있다. 키를 꺼낸 다음엔 정상적인 API 호출처럼 위장해 데이터를 끌어낼 수 있다. 방화벽이나 침입 탐지 장비가 이런 요청을 굳이 막지 않는 이유도 여기에 있다.
이 지점이 흥미로운데, 이런 실수는 신생 스타트업만의 문제가 아니다. 대형 인프라 운영사도 마케팅 도구 하나를 급하게 붙이는 과정에서 똑같은 함정에 빠진다. 필자가 보기엔 문제의 본질은 기술 난이도가 아니라 조직의 검토 절차 부재다.
SaaS 연동이 만들어내는 공급망형 리스크
기업이 쓰는 SaaS 도구는 대개 하나가 아니라 수십 개다. 분석 툴, 채팅 위젯, 마케팅 자동화, 결제 연동까지 프론트엔드에 스크립트를 심는 도구가 넘쳐난다. 각 도구마다 발급받는 자격증명은 결국 하나의 확장된 공격 표면이 된다.
이런 구조는 전형적인 공급망형 보안 리스크와 닮았다. 내부 시스템은 아무리 견고해도, 외부 SaaS 연동 지점 하나가 약하면 전체가 흔들린다. 실제로 오픈소스 생태계에서도 비슷한 패턴이 반복돼 왔다. GitLab 취약점이 공개 며칠 만에 실전 공격당한 사례는 노출된 틈이 얼마나 빨리 악용되는지를 보여준다.
기업은 이 실수를 어떻게 막아야 하는가
이 문제의 해법은 사실 새롭지 않다. 다만 실행이 늘 뒷전으로 밀린다는 게 문제다. 개인적으로는 아래 세 가지가 최소 방어선이라고 본다.
- 백엔드 프록시: 프론트엔드가 서드파티 API를 직접 호출하지 않고, 서버를 거쳐 우회 호출하도록 구조를 바꾼다.
- 토큰 스코핑: 마케팅 자동화용 키에는 발송 권한만 부여하고, 데이터 조회나 대량 추출 권한은 아예 제거한다.
- 시크릿 스캐닝: 배포 파이프라인에 자동 스캐너를 넣어, 코드에 키가 하드코딩되는 순간 배포 자체를 막는다.
여기서 눈에 띄는 건, 이 세 가지 모두 큰 예산이 필요한 대책이 아니라는 점이다. 오히려 조직이 이걸 ‘누구 담당인지’ 정하지 못해서 놓치는 경우가 더 많다. 마케팅팀이 도구를 붙이고, 보안팀은 그 사실조차 모르는 구조가 흔하다.
IT-SUE의 시각
이번 맨체스터 공항 해킹 사건에서 필자가 가장 주목하는 건 유출 규모가 아니다. API 키 노출 보안사고라는 패턴이 대형 인프라 기업에서도 똑같이 반복된다는 사실이다. 규모가 크다고 보안 수준까지 비례해서 높은 건 아니라는 얘기다.
물론 침입 경로에 대한 FulcrumSec의 주장은 아직 제3자가 검증하지 않았다. 이 부분은 앞으로 포렌식 조사나 추가 공식 발표를 지켜봐야 한다. 다만 설령 이번 사건의 구체적 경위가 다르게 밝혀지더라도, 클라이언트사이드에 자격증명을 노출하는 실수 자체는 이미 업계 전반에서 반복되고 있다.
필자가 보기엔 진짜 질문은 “이번에도 그랬는가”가 아니라 “다음에도 또 그럴 것인가”다. SaaS 연동이 늘어날수록 이 질문은 더 자주 되풀이될 수밖에 없다. 그래서 지금 이 순간, 자사 프론트엔드 코드를 한 번쯤 열어보는 게 어떤 보고서보다 유용할 수 있다.
답글 남기기