회계 컨설팅 대기업 Ernst & Young(EY)가 자사 IT 인력이 사용하는 제3자 지원 티켓 시스템 침해 사실을 공개하며 고객 대상 유출 통지를 진행 중인 것으로 확인됐다. 이번 사건은 본사 보안 통제와 무관하게 외부 헬프데스크 SaaS가 만드는 공급망 리스크가 얼마나 현실적인지 다시 한번 일깨워 준다.
- EY가 제3자 지원 티켓 시스템 해킹으로 인한 데이터 유출을 고객에 통지 중임
- 유출 경로는 티켓 첨부 문서로 제한될 가능성이 분석되며 공급망 공격 벡터가 거론되고 있음
- 지원 인프라가 표적이 되면서 고객 공지 및 규제 대응 이슈가 동반됨
본사 보안이 견고해도 외부 헬프데스크 SaaS 한 곳이 신뢰에 영향을 줄 수 있다는 점이 이번 사건이 시사하는 부분이다.
EY 데이터 유출 사고가 보여준 공급망 보안의 현실
보도 시점 기준 2026-07-17 10:55 AM 미국 시간에 Bleeping Computer가 게재한 기사에 따르면 EY는 자사 IT 인력이 일상적으로 사용해 온 제3자 지원 티켓 시스템이 침해된 사실을 인지했고, 영향 받을 수 있는 고객사에 데이터 유출 통지를 보내는 절차를 진행 중이다. 침해의 기술적 경위는 공식적으로 모두 공개되지 않았지만 유출 후보 데이터는 지원 티켓에 첨부되어 있던 문서 범위로 좁혀질 가능성이 큰 것으로 분석된다.
EY와 같은 Big 4 회계법인은 감사·세무·컨설팅 업무 특성상 고객사 재무 정보, 계약서, 내부 메모 등 고민감 문서를 다수 취급한다. 따라서 내부 헬프데스크에 첨부되는 파일 한 건 한 건이 사실상 고객 비밀의 캐리어 역할을 한다. 본 사건은 대형 회계법인에서도 공급망 가시성 확보가 충분하지 않을 수 있다는 점을 보여주는 사례로 평가된다.
왜 지원 티켓 시스템이 해커의 1차 표적이 되는가
해커가 헬프데스크 티켓 SaaS를 노리는 이유는 단순하다. 티켓 시스템은 본사 직원과 외부 사용자 사이의 공식 소통 창구이므로 정상 트래픽과 침해 트래픽을 구분하기 어렵고, 첨부파일에는 자격 증명 스택샷, 계약서, 계약 전 실사 자료 등이 평문으로 포함되는 경우가 흔하다. 공격자는 단일 사용자 침해만으로도 동일 조직 내 다른 계정으로 횡적 이동하거나 첨부파일 메타데이터를 통해 내부 구조를 추론할 수 있다.
또한 지원 티켓 시스템은 SSO 연동, API 키, 토큰 회전 같은 보안 통제가 비교적 느슨하게 운영되는 경향이 있다. 사용자 입장에서는 빠른 장애 처리가 우선이기 때문에 MFA 강제나 첨부파일 암호화가 미흡하기 쉽고, 바로 그 간극이 공격 표면이 된다. 결과적으로 공격자는 본사 방화벽을 우회하지 않고도 데이터에 접근할 가능성이 생긴다.
본사는 안전하다지만 외부 SaaS에서 새는 데이터의 구조적 문제
대부분의 기업 보안 프로그램은 자사 자산 중심으로 설계되어 있어 외부 벤더가 처리하는 데이터 흐름은 가시성 사각지대에 놓이기 쉽다. EY 사례처럼 자사 직원 권한으로 SaaS에 로그인해 업로드한 파일이 유출되면 법적 책임 소재와 데이터 주체별 통지 의무가 복잡하게 얽히게 된다. 특히 글로벌 회계법인은 EU GDPR, 미국 주별 데이터 유출 통지법, 한국 개인정보보호법 등 다중 규제 적용을 받기 때문에 단일 사고 통지만으로도 운영 부담이 폭증한다.
다음 표는 본사 보안과 외부 SaaS 보안의 책임 범위를 비교한 것이다.
| 구분 | 본사 자체 시스템 | 외부 헬프데스크 SaaS |
|---|---|---|
| 자산 통제 | 직접 보유 및 관리 | 벤더가 관리하며 데이터 주체는 고객사 |
| 로그 가시성 | SIEM 직접 수집 가능 | 벤더 감사 로그에 의존 |
| 첨부파일 보호 | DLP 정책 즉시 적용 가능 | 정책 적용이 SaaS 기능에 종속 |
| 사고 책임 | 내부 단독 | 공동 책임 모델 계약상 명시 필요 |
| 규제 대응 | 단일 보고 경로 | 벤더 공시와 고객 통지 이중 절차 |
이처럼 본사 보안의 합격점과 공급망 보안의 합격점은 본질적으로 다르다. EY와 같은 대형 조직은 자체적으로 제로트러스트와 같은 첨단 통제를 운영해 왔음에도 외부 티켓 SaaS라는 작은 창에서 데이터가 새어 나간 것으로 보인다. 외부 SaaS에 의존하는 비중이 커질수록 가시성 격차는 더 벌어질 것이며, 이를 메우지 못하면 동일 유형의 사고가 반복될 것으로 분석된다.
향후 90일간 기업 보안팀이 해야 할 행동
EY 사고를 단순한 뉴스로 소비할지, 자사 공급망 점검의 트리거로 삼을지는 향후 90일의 실행력에 달려 있다. 다음 세 가지 액션을 우선순위화해 적용할 필요가 있다.
벤더 보안 점검과 헬프데스크 SaaS 재평가 체크리스트
첫째, 자사가 사용하는 모든 지원 티켓 SaaS를 목록화하고 데이터 분류 등급을 부여해야 한다. ISO 27001, SOC 2 Type II, 최신 침해사고 발생 이력, 데이터 레지던시, 사고 통지 SLA를 기준으로 벤더를 재점검하고, 등급이 낮은 서비스는 축소하거나 사내 솔루션으로 회수하는 방향을 검토해야 한다. 점검 결과는 CISO가 직접 리뷰하고 이사회 위험 위원회까지 보고하는 라인을 만들어야 효과적이다.
사고 대응 공지 및 규제 신고 시나리오 업데이트
둘째, 사고 대응 플레이북에 공급망 시나리오를 추가해야 한다. EY처럼 벤더 침해가 자사 고객사에 직접 영향을 주는 경우, 자사의 사고 대응팀이 데이터를 직접 보유하지 않은 상태에서 통지를 보내는 절차가 필요해내야 하는 모순이 발생한다. 사전에 벤더와 공동 사고 대응 절차, 통지 템플릿, 메시징 권한, 데이터 주체 매핑 절차를 합의해 둬야 공지 지연으로 인한 평판 손실을 줄일 수 있다.
티켓 첨부파일 마스킹과 자격 증명 회전 자동화
셋째, 기술 통제 차원에서 첨부파일 자동 마스킹과 자격 증명 회전 자동화를 도입해야 한다. 첨부파일 내 주민등록번호, 카드번호, API 키, 패스워드 패턴을 자동 탐지해 마스킹하거나 안전한 링크로 대체하고, 티켓 SaaS 접근용 서비스 계정과 API 토큰은 90일 이내 주기로 자동 회전하도록 구성해야 한다. EY 사고는 첨부파일에 무엇이 들어 있는지조차 추적되지 않은 채 노출됐을 가능성을 보여주며 이는 자가 점검 항목이 된다.
아래는 실무 담당자가 바로 복사해 점검에 사용할 수 있는 압축 체크리스트이다.
- 사용 중인 모든 헬프데스크 SaaS 목록과 데이터 분류 등급 문서화 완료 여부
- 벤더 SOC 2 Type II 보고서 및 침해사고 이력 최근 1년 이내 검토 여부
- 티켓 첨부파일 자동 마스킹 또는 DLP 정책 적용 여부
- 서비스 계정 및 API 토큰 90일 이내 자동 회전 여부
- 벤더 침해 시 72시간 내 공동 통지 절차와 템플릿 합의 여부
마무리 공급망 가시성을 보안의 기본값으로 만들어야 하는 이유
EY 데이터 유출은 본사 보안팀의 실패라기보다 외부 헬프데스크 SaaS가 만들어 낸 공급망 사각지대의 실패로 보는 것이 더 정확하다. 본사 네트워크와 엔드포인트에 쏟아붓는 투자만큼 외부 벤더에 대한 가시성 투자도 늘리지 않으면 같은 사건은 다른 회사에서 반복될 가능성이 높다. 보안의 기본값을 자사 자산에서 공급망 전체로 확장해야, 비로소 고객사가 신뢰할 수 있는 통제 체계를 갖출 수 있다.
사실 요약: EY가 제3자 지원 티켓 시스템 침해로 인한 데이터 유출을 고객에 통지 중이며, 첨부 문서가 주요 유출 후보 경로로 분석된다.
실행 권고: 기업은 헬프데스크 SaaS 재평가, 첨부파일 마스킹 자동화, 자격 증명 회전, 공급망 사고 대응 시나리오 정비를 향후 90일 내 우선 과제로 추진해야 한다.
참고 자료 1: Bleeping Computer – Ernst & Young discloses data breach after support system hack
참고 자료 2: Bleeping Computer – CISA urges immediate action on actively exploited Fortinet flaws