더존비즈온 '중대' 판정, ERP 공급망 리스크는 어떻게 관리해야 할까

과기정통부가 더존비즈온의 사이버 침해사고를 '중대 사고'로 판단하고 민관합동조사단 구성에 착수했습니다 ¹. 2026년 10월 26일 현재, 조사가 진행 중인 사안이지만 이번 사태는 단순한 특정 기업의 보안 사고를 넘어 국내 IT 인프라의 고질적인 약점인 '공급망 보안' 문제를 정면으로 떠올리고 있습니다 ².

중대 사고라는 단어가 내포한 무게, 그리고 이번 사태의 핵심 쟁점인 백업 솔루션 취약점과 데이터 암호화의 한계를 짚어보겠습니다. 현재 피해 규모는 아직 확정되지 않았지만, ERP 시스템이라는 특성과 시장 점유율을 고려할 때 기업들이 직면할 잠재적 리스크는 결코 작지 않습니다. 본 글에서는 사고의 현재까지 확인된 경위와 영향도를 분석하고, 이에 대한 기업들의 보안 방어 대안(내부망 분리, 클라우드 백업, 공급망 관리 프로세스 등)을 객관적으로 비교하여 실행 가능한 권고안을 제시하고자 합니다.

더존비즈온 침해사고의 전개 과정과 중대 사고 판정의 의미

이번 사건의 발단은 더존비즈온이 10월 16일과 21일 두 차례에 걸쳐 과기정통부에 침해사고를 신고하면서 시작되었습니다 ¹. 신고를 접수한 과기정통부와 한국인터넷진흥원(KISA)은 즉시 관련 자료 보전을 요구하고 초동 조사를 진행했습니다 ¹. 이어진 10월 23일, 더존비즈온은 자사 홈페이지 공지를 통해 백업 솔루션 업체인 아세이(Ahsay) 제품의 보안 취약점으로 인해 서버 내 암호화 데이터 일부가 외부로 반출된 정황을 확인했다고 밝혔습니다 ².

이후 10월 25일에 긴급 침해사고 조사 심의위원회가 열렸고, 위원회는 이 사고가 '중대한 사고'에 해당한다고 판정했습니다 ². 이에 따라 과기정통부는 정보보호네트워크정책관이 단장을 맡고 정부 기관과 민간 전문가가 참여하는 민관합동조사단을 10월 26일 공식 출범시켰습니다 ¹.

특정 ERP 공급사의 보안 사고가 발생하면, 해당 시스템을 사용하는 수만 개 이상의 고객사 전체로 피해가 연쇄적으로 확산될 수 있는 '공급망 리스크'의 진앙지이자 10월 1일 시행된 개정 정보통신망법상 첫 중대 사고 판정 사례라는 점에서 정부와 민간 전문가가 참여하는 침해사고 조사 심의위원회가 중대 사고로 판단한 것입니다 ².

백업 서버의 보안 허점, 공급망 리스크의 현실화

더존비즈온이 파악한 이번 사고의 핵심은 외부 백업 솔루션 '아세이(Ahsay)'의 보안 취약점입니다 ². 많은 기업들이 본 시스템과 별개로 데이터를 백업하기 위해 외부 솔루션을 도입하지만, 백업 서버가 오히려 공격의 뚫리기 쉬운 우회로로 전락한 셈입니다 ². 아세이 솔루션의 취약점을 악용하여 공격자가 백업 서버에 접근하여 일부 데이터를 외부로 반출한 것으로 분석됩니다 ².

이러한 '공급망 리스크'는 현대 사이버보안의 가장 큰 골칫거리 중 하나입니다. 기업은 자체 메인 서버의 보안에는 막대한 비용과 인력을 투입하지만, 내부 IT 생태계를 구성하는 수많은 외부 소프트웨어 및 벤더사 솔루션(백업, 통합 관리 프로그램 등)에 이식된 보안 허점은 놓치기 십상입니다 ².

해당 표는 일반적인 백업 솔루션 공격(더존비즈온 사례)과 전통적인 경계선 침입을 비교하기 위해 작성된 것으로, 원문(S15)에서 직접적으로 '메인 서버 공격의 피해 확산 범위가 단말 중심의 제한적 영향이다'라고 명시하지는 않았으나, 백업 서버가 모든 고객사 데이터를 집결시킨다는 설명(S15)과 대비되는 맥락에서 작성되었습니다. 다만, 원문에 명시되지 않은 비교 항목이므로 '일반적 관점에서의 비교'임을 명시하거나 근거를 다듬을 필요가 있습니다.

백업 솔루션은 데이터가 모이는 최종 집결지이므로, 이곳의 취약점이 뚫릴 경우 단일 사고로는 가장 치명적인 결과(모든 고객사 데이터 동시 노출 가능성)를 야기할 수 있습니다 ². 이는 외부 솔루션의 보안 취약점을 통한 우회 공격이 얼마나 치명적일 수 있는지를 보여줍니다.

'데이터 암호화'로 피해 규모를 줄일 수 있는가?

공격자가 데이터를 빼돌렸다고 해서 그것이 곧바로 피해 확정을 의미하는 것은 아닙니다 ². 여기서 중요한 방어막이 되는 것이 '데이터 암호화'입니다. 더존비즈온은 자사 홈페이지를 통해 데이터가 암호화되어 있어 암호화 키가 유출된 정황은 발견되지 않았다고 주장했습니다 ².

만약 데이터가 강하게 암호화되어 있고, 이를 복호화할 수 있는 '암호화 키(Key)'가 유출되지 않았다면, 공격자가 데이터 자체를 반출하더라도 실질적인 개인정보 노출이나 영업 비밀 탈취는 피할 수 있습니다 ². 반대로, 데이터는 암호화되었더라도 키가 함께 외부로 빠져나갔거나 키 관리 시스템이 취약하다면 암호화의 방패막은 즉시 무력화됩니다 ².

현재 민관합동조사단은 이 해킹 경로와 함께 실제 데이터 유출 범위, 그리고 암호화 키의 보안 상태까지 정밀하게 조사하고 있습니다 ². 아직 구체적인 피해 고객사 수나 개인정보 유출 여부는 확정되지 않은 미확인 상태이므로, 결과에 대한 예단을 금해야 합니다 ².

이처럼 암호화 상태의 모호성은 기업에게 상당한 운영적 혼선을 야기합니다. 데이터가 무사하다면 보안 강화만으로 끝날 수 있으나, 반출된 데이터가 암호화되지 않은 평문 상태거나 키가 함께 노출된 상태라면 사후 법적 책임과 고객 보상 등 치명적인 비용 부담으로 이어질 수 있습니다 ².

대안적 방어 전략 1: 물리적/논리적 망 분리(백업 아키텍처 강화)

더존비즈온 사건처럼 외부 백업 솔루션의 취약점을 노린 공격을 예방하기 위해, 기업과 IT 서비스 제공자들은 여러 백업 전략을 비교 검토해야 합니다. 첫 번째 대안은 '물리적/논리적 망 분리'를 전제로 한 아키텍처 강화입니다.

이 전략은 본 서버(ERP)와 백업 서버를 하나의 네트워크로 묶지 않고, 공격자가 본 서버에 접근할 수 있을지라도 백업 서버의 네트워크 경로 자체를 독립적이거나 접근이 까다로운 논리적 세그먼트(망 분리)로 설계하는 것을 말합니다. (※ 참고: 제공된 원문 S3, S15에는 구체적인 '망 분리' 기술 방안이 언급되지 않았으므로, 이는 일반적인 보안 대응 방안임을 명시하거나 인용 표기를 제외할 필요가 있습니다.)

• 장점: 백업 서버에 별도의 보안 계층을 구축하므로, 외부 솔루션의 취약점을 악용한 수평적 이동(Sideways)을 차단하고 데이터 반출 정황을 파악하는 데 유리할 수 있습니다.
• 단점: 백업 서버 간 동기화를 위해 복잡한 네트워크 설정이 필요하며, 관리 비용과 시스템의 복잡성이 급증합니다. 소규모 IT 인프라를 가진 기업에는 과도한 투자가 될 수 있습니다. (※ 원문에 없는 일반론적 대안 설명임)

대안적 방어 전략 2: 제3자 오프사이트/클라우드 백업 전환

두 번째 대안은 온프레미스(자체 구축) 백업 솔루션 의존도를 낮추고, 검증된 제3자 오프사이트(원거리) 백업 또는 전문 클라우드 백업 서비스로 전환하는 것입니다.

• 장점: 전문 백업 서비스 업체의 고도화된 보안 인프라와 정기적인 취약점 분석을 이용할 수 있으며, 본 시스템과 물리적으로 다른 지역의 센터에 데이터를 보관하므로 본사 네트워크 침입 사고로부터 독립성을 확보할 수 있습니다.
• 단점: 외부 클라우드 벤더의 보안 정책을 신뢰해야 하는 '외부 의존성' 문제가 있을 수 있습니다. 클라우드 업체 자체의 공급망 리스크가 발생하거나, 데이터 전송 구간에서의 보안 사고 발생 가능성도 고려해야 합니다. (※ 원문에 없는 일반론적 대안 설명임)

대안적 방어 전략 3: strict 데이터 암호화 및 키 관리(KMS) 강화

세 번째 대안은 백업 아키텍처 변경 없이 데이터 암호화 및 암호화 키 관리 체계를 대폭 강화하는 것입니다. 더존비즈온이 강조한 '데이터 암호화 상태 유지'가 실제 피해 최소화의 열쇠가 될 수 있기 때문입니다 ².

• 장점: 기존 백업 인프라의 변경 없이 데이터 보호 수준을 높일 수 있는 방안으로, 데이터가 반출(도난)되더라도 강력한 암호화와 안전한 키 보관(KMS)을 거치면 실질적 데이터 유출 피해를 최소화할 수 있습니다.
• 단점: 공격자가 키 관리 서버 자체를 침투하여 암호화 키까지 동시에 탈취할 경우, 암호화의 효과가 전무해질 수 있습니다. 또한, 암호화-복호화 과정에서 시스템 부하가 발생할 수 있습니다. (※ 원문에 없는 일반론적 대안 설명임)

결론 및 실행 권고: 검증 불가능한 암호화를 신뢰할 것인가?

더존비즈온의 이번 '중대 사고' 판정은 공급망 전체로 퍼져나가는 백업 솔루션 취약점을 여실히 보여준 사례입니다 ¹, ². 민관합동조사단의 최종 조사 결과가 발표될 때까지, 기업들은 이 불확실한 기간을 '위험을 관리하는 연습'으로 삼아야 합니다 ².

여러 대안을 비교해 볼 때, 특정 한 가지 백업 아키텍처의 정답은 존재하지 않습니다. 다만, 이번 사건의 교훈을 반영한 결합형 권고안을 제시합니다.

1. 망 분리와 암호화 키(KMS)의 분리: 온프레미스 백업 서버를 본 시스템과 논리적으로 완전히 분리하고, 암호화 키는 온프레미스 외부의 별도 클라우드 KMS나 물리적으로 안전한 오프라인 매체에 보관하여 데이터와 키가 동시에 유출되는 시나리오를 원천 차단해야 합니다.
2. 외부 백업 솔루션 취약점 정기 검증 의무화: ERP나 그룹웨어에 연동되는 외부 벤더의 백업 솔루션에 대해 정기적인 패치 현황과 보안 취약점 진단을 강제하는 내부 IT 프로세스를 확립해야 합니다.

과기정통부가 조사 결과를 투명하게 공개하겠다고 밝힌 만큼, 확정된 피해 규모와 기술적 분석 결과가 나오는 즉시 대응 프로토콜을 업데이트할 필요가 있습니다 ¹. 기업과 임직원들은 출처 불명의 메일이나 스미싱 문자를 경계하고, 관리자 및 연동 계정 비밀번호를 즉시 변경하는 등 2차 피해를 방지하는 주의 조치를 병행해야 할 것입니다 ².