요약

  • IDCF에 따르면 랜섬웨어로 인해 10월 7일부터 East Japan Region 1의 네 개 존에서 가상 머신이 중단되었으며, 495개 기업과 지방정부에 영향을 미쳤습니다. 회사는 조사하는 동안 고객 대면 콘솔을 중단했습니다. 공개 기록에는 공격자, 침입 경로, IDCF Cloud Backup의 상태가 밝혀져 있지 않습니다.
  • IDCF의 제품 자료는 오프사이트 백업 스토리지와 불변(immutable) 스토리지 옵션을 설명합니다. 그러한 설계는 복사본의 위치에 관한 것입니다. 그것만으로는 IDCF Cloud Console이 사용 불가능한 상황에서 고객이 백업 카탈로그와 자격 증명에 접근할 수 있는지, 혹은 다른 곳에 컴퓨팅을 프로비저닝할 수 있는지를 입증하지 못합니다.
  • 두 고객이 서로 다른 복구 경로를 공개했습니다. Six Apart는 10월 7일 01:00의 Google Cloud 백업을 이용해 영향을 받은 31대의 서버를 Sakura Cloud로 옮겼습니다. Future Shop은 선택적 이메일 서비스를 다른 데이터센터에서 재구축했으며, 핵심 쇼핑몰과 관리 사이트는 영향을 받은 플랫폼 외부에 그대로 있었습니다. 어느 보고서도 고객이 IDCF Cloud Backup을 사용했다고 밝히지 않습니다.

IDCF의 장애 대응 안내에서 가장 중요한 문장은 복구에 관한 약속이 아니라, 사용 불가능한 서비스를 우회하는 경로였습니다. 운영 체제를 이용해 다른 환경으로 파일을 옮기라는 것이었습니다. IDCF Cloud Storage의 기존 고객에게 FAQ는 두 번째 문을 가리켰습니다. 연동된 Google 계정과 프로젝트 정보가 있는 고객이라면 Google Cloud Console을 통해 직접 접근할 수 있다는 것이었습니다.

이 조언은 실용적이지만, 하나 이상의 제품을 설명합니다. IDCF Cloud Storage는 Google Cloud Storage에 기반합니다. IDCF Cloud Backup은 별도의 관리형 서비스입니다. FAQ는 백업 서비스 사용 불가능이라는 일반 문구가 그 특정 Veeam-and-Wasabi 서비스를 포함하는지, 어떤 고객 집단을 대상으로 하는지, 혹은 영향을 받은 테넌트 중 그 서비스에 가입한 곳이 있는지 밝히지 않습니다. GCS 경로를 BaaS 리포지터리가 계속 이용 가능했다는 증거로 취급하면 서로 다른 두 시스템을 하나로 묶어버리게 됩니다.

복사본은 복구의 일부일 뿐이다

IDC Frontier에 따르면 사건은 10월 7일 일본 시간 약 03:40에 시작되었습니다. 10월 8일 업데이트는 East Japan Region 1의 영향을 받은 네 개 존 — tesla, henry, pascal, joule — 을 밝혔습니다. 해당 존의 가상 머신은 정지되었고 재시작할 수 없었습니다. IDCF는 데이터 회수나 복원이 어려울 것이며, 그 시점에는 고객이 보유한 백업이 이용 가능한 복구 경로라고 밝혔습니다. 또한 회사가 추가 피해를 제한하기 위해 해당 지역 네트워크와 관리 콘솔을 중단했으며, 안전을 확인하는 동안 다른 지역의 외부 대면 콘솔도 중단했다고 밝혔습니다.

10월 9일 업데이트는 모회사 SoftBank와의 긴급 대응 조직, 백업과 마이그레이션에 관한 고객 안내, 외부 보안 전문가와의 기술 조사를 설명했습니다. 복구 결과나 완료된 조사에 대한 보고는 없었습니다. 따라서 최신 공개 기록은 봉쇄 작업과 고객 복구를 구분합니다. 대응 조직의 존재는 활동의 증거이지 워크로드가 돌아왔다는 증거가 아닙니다.

서비스 설계가 중요한 이유는 IDCF가 이미 이 문제를 둘러싼 상업적 제안을 해왔기 때문입니다. 2025년 3월 출시 보도자료는 IDCF Cloud Backup을 Wasabi Hot Cloud Storage와 결합된 Veeam 서비스 프로바이더 백업 서비스로 설명했습니다. 보도자료는 보호 서버당 월 3,500엔과 스토리지 GB당 5엔을 제시했습니다. 현재 제품 페이지는 운영 체제 에이전트, 증분 복사, 타 사이트 클라우드 스토리지, 불변 스토리지 옵션, 다른 서버로의 복원을 설명합니다. 또한 백업 서비스는 인터넷 연결이 필요하고 스토리지는 현재 East Japan 지역에서 제공된다고 밝힙니다.

이것들은 의미 있는 제품 사양입니다. 의도된 복사 및 복원 모델을 설명할 뿐, 모든 단계에 대한 독립적 통제를 설명하지는 않습니다. 사용자 가이드는 Veeam Service Provider Console을 열기 전에 IDCF Cloud Console에서 백업 서비스를 시작합니다. 서비스 범위 문서는 IDCF Cloud 사용자와 연동되지 않은 로컬 백업 콘솔 사용자를 허용합니다. 이는 잠재적으로 유용한 계정 신원의 분리이지만, 공개 문서는 클라우드 콘솔이 중단된 상황에서 로컬 사용자가 직접 경로로 백업 콘솔에 접근할 수 있는지를 확립하지 않습니다. 영향을 받은 존의 어떤 고객에게 그러한 로컬 계정이 구성되어 있었는지도 밝히지 않습니다.

스토리지 페이지의 "다른 사이트"라는 표현도 복구 보장보다 좁습니다. 현재 FAQ는 백업 스토리지를 East Japan 지역에 두지만, IDCF의 사건은 East Japan Region 1이었습니다. 공개 기록은 그 위치들이 하나의 장애 도메인을 공유하는지 확립하지 않습니다. 넓은 지역 라벨을 겹침의 증거로 취급하는 것도 잘못이고, 분리의 증거로 취급하는 것도 똑같이 잘못입니다. 사이트, 지역, 존, 신원 제공자, 관리 콘솔, 복원 목적지는 서로 다른 차원입니다.

두 고객의 재구축은 복사본 가격이 생략한 것을 보여준다

Six Apart의 Movable Type Cloud 업데이트는 특히 구체적입니다. 영향을 받은 IDCF 지역의 31대 서버가 10월 8일 21:00까지 Sakura Cloud로 옮겨졌으며, 그날 아침 01:00의 백업을 사용했다고 밝혔습니다. 제품 문서에 따르면 서비스는 도쿄의 Google Cloud Storage에 매일의 백업 7개를 유지했습니다. 01:00 시점은 IDCF의 보고된 사건 시작보다 2시간 40분 앞서지만, 공개 보고서는 그 간격 동안 애플리케이션 데이터가 얼마나 변경되었는지, 다른 로그나 복제가 그 차이를 메웠는지 설명하지 않습니다. 기록은 선택된 복원 지점과 완료된 마이그레이션 작업을 확립할 뿐, 보편적인 복구 시간이나 복구 지점 결과는 아닙니다.

대체 목적지는 사건 전부터 Six Apart의 상업적 제안의 일부였습니다. 6월에 회사는 Sakura Cloud 플랜을 발표했습니다. 그렇다고 마이그레이션 비용이 없어지는 것은 아닙니다. Six Apart는 플랜을 옮기면 IP 주소가 바뀌거나 스토리지나 사양이 달라질 수 있고 시간이 걸릴 수 있다고 경고했습니다. 고객이 옮길 수 있었던 이유는 목적지, 서비스 플랜, 백업 절차가 이미 존재했기 때문입니다. 클라우드 백업 청구서만으로는 그런 조건이 만들어지지 않았을 것입니다.

Future Shop의 두 번의 업데이트는 회복탄력성이 단일한 "회사가 복구됨" 상태가 아닌 이유를 보여줍니다. 두 선택적 이메일 제품 — future Scenario Cast와 futureCartRecovery — 의 메일 전송 서버만 IDCF에 호스팅되어 있었고, 메인 전자상거래 사이트와 관리 콘솔은 다른 곳에 있었습니다. Future Shop은 다른 데이터센터에 대체 메일 환경을 구축했고 10월 9일 12:30 JST까지 전송을 재개했습니다. 장애 기간에 예약된 메시지는 자동으로 재전송되지 않았습니다. 전송의 재개는 하나의 서비스 중단을 닫았을 뿐, 잃어버린 소통 창구까지 닫은 것은 아닙니다.

별개의 개인정보 문제도 있었습니다. Future Shop은 영향을 받은 서버에 일부 수신자 주소와 이름, 생년월일, 회원 ID를 포함할 수 있는 메시지 내용이 저장되어 있었다고 밝혔습니다. 해당 기록은 저장 중에 암호화되어 있었고 14일 후 자동 삭제되었지만, 침입 시작 시점과 가능한 데이터 노출 기간은 여전히 불명확하다고 밝혔습니다. 회사는 서비스 재개가 데이터 노출 조사의 완료를 의미하지 않는다고 명시했습니다. 이 구분은 상업적으로 중요합니다. 서비스 연속성과 사건 책임은 서로 다른 시계를 따릅니다.

백업의 시장 가격은 복원의 가격이 아니다

IDCF의 공개 출시 가격은 구매자가 셀 수 있는 것을 상기시켜 줍니다. 서버당 요금과 사용량 기반 스토리지 과금은 보호 용량에 숫자를 붙입니다. 하지만 고객의 대체 컴퓨팅, 데이터 전송 시간, 네트워크 변경, 신원 복구, 애플리케이션 점검, 인력 조율, 혹은 재생할 수 없는 메시지나 거래의 비용에는 숫자를 붙이지 않습니다.

경제적 요점은 관리형 백업이 잘못定价된다는 것이 아닙니다. 관리형 백업은 리포지터리를 구축하고 유지하는 노동을 줄일 수 있고, 불변 보존은 침해된 운영 계정이 삭제할 수 있는 것을 제한할 수 있습니다. 하지만 공급자가 백업 서비스와 그 정상 진입점을 모두 관리할 때, 구매자는 복구 권한이 어디에 있는지 물어야 합니다. 두 번째 스토리지 위치는 데이터 플레인 기능입니다. 독립적인 자격 증명 경로는 관리 기능입니다. 검증된 대체 클라우드는 용량과 이식성 기능입니다. 함께 판매될 수 있지만, 하나가 다른 하나를 입증하지는 않습니다.

유용한 구매자 테스트는 제품 이름이 아니라 장애에서 시작합니다. 훈련에서 표준 클라우드 포털을 비활성화하십시오. 누가 로그인하고, 백업 카탈로그를 회수하고, 최신 사용 가능 지점을 식별하고, 복원을 승인할 수 있는지 물으십시오. 그 다음, 대표적인 워크로드 하나를 신원, 과금, 컴퓨팅 용량이 사용 불가능한 콘솔에 의존하지 않는 목적지로 복원하십시오. 복사 작업이 "완료"라고 말하는 시간이 아니라, 애플리케이션이 작동할 때까지의 시간을 측정하십시오. 데이터 상태와 라우트, 주소, 접근 통제, 고객 대면 서비스를 갱신하는 데 필요한 작업을 기록하십시오.

그러한 훈련은 IDCF의 공개 자료가 해결하지 않는 추가 질문에 답해야 합니다. 고객이 백업 카탈로그 메타데이터를 소유하거나 내보낼 수 있는지; 어떤 자격 증명이 운영 워크로드와 그 백업을 모두 삭제할 수 있는지; 기본 콘솔이 의도적으로 비활성화된 경우 지원이 어떻게 대응하는지; 다른 공급자로의 복원 비용은 얼마인지; 그리고 복사본의 지리가 테스트 중인 컴퓨팅 장애와 분리되어 있는지. 이들은 구매 문항이며, 설계에 대한 혐의가 아닙니다.

추론이 아닌 근거

IDCF는 조율, 조사, 지원을 설명하는 네 번째 장애 업데이트를 공개했습니다. Six Apart와 Future Shop은 고객별 조치를 공개했습니다. IDCF의 제품 페이지는 백업 서비스, 출시 기술, 스토리지 모델, 공개 가격을 밝힙니다. 공개 출처는 영향을 받은 고객 사이에서의 IDCF Cloud Backup 채택률, 그 컨트롤 플레인이 계속 이용 가능했는지, 혹은 특정 백업 복사본이 이 사건에서 사용되었는지 밝히지 않습니다.

그 부재가 결론을 제한합니다. IDCF의 BaaS가 실패했다는 것이 입증된 적은 없고, 고객 사례는 그 성능으로 제시될 수 없습니다. 이 사건이 확립하는 것은 공급자 콘솔, 백업 서비스, 스토리지 계정, 대체 컴퓨팅 목적지가 별개의 운영 의존성이 될 수 있다는 점입니다. 구매자가 그 연결을 테스트하지 않고 보호에 비용을 지불한다면, 눈에 보이는 스토리지 항목이 복구 계획보다 더 완전해 보일 수 있습니다.

출처