아래의 10가지 클라우드 사고에서 피해를 입지 않은 회사는 단 한 곳이었다. 바로 클라우드 데이터를 외부 기업에 백업한 회사였다.
필자는 모든 데이터를 독립적으로 백업해야 한다고 항상 강조해 왔다. 데이터센터에 있든, AWS와 같은 IaaS 공급업체에 있든, 마이크로소프트와 같은 SaaS 공급업체에 있든, 독립적인 백업이 필요하다. 그러나 일부 사람들은 클라우드 서비스 업체가 백업 작업을 제대로 대행할 것이라고 기대한다.
지난 15년간의 클라우드 데이터 손실 사고를 보면 클라우드 중단이 얼마나 심각한 결과를 초래할 수 있는지 잘 알 수 있다. 지난 15년 동안 발생한 10가지 클라우드 재해(알파벳 순으로 나열)를 살펴본다.
– 카보나이트(2009): 이중화 부족과 소비자용 스토리지 어레이 사용으로 인해 카보나이트는 대규모 데이터 손실 사고에서 수천 고객의 백업 데이터를 잃었다. 이 회사는 책임을 지는 대신 스토리지 공급업체를 비난했다.
– 코드 스페이스(2014): 해커가 코드 스페이스의 AWS 환경에 액세스하여 모든 고객 데이터와 백업을 삭제했다. 그 결과 코드 스페이스는 폐업했다.
– 디두스 (2014): 서비스 장애로 인해 디두스(Dedoose)의 기본 연구 데이터베이스와 매월 수행되던 백업이 모두 사라졌다. 이로 인해 많은 연구원들이 한 달 이상의 데이터 손실을 입었다.
– KPMG (2020): 관리자가 실수로 마이크로소프트 팀즈 보존 정책을 변경함에 따라 14만 5,000명 이상의 직원에 대한 채팅 데이터와 파일이 영구적으로 삭제됐다. 마이크로소프트 365의 기본 보존 정책은 복구를 허용하지 않았으며, 이는 데이터 손실의 원인이 됐다.
– 뮤시/모스(2019): 한 스타트업에서 실수로 조직의 구글 계정 전체를 삭제하여 순식간에 100만 달러가 넘는 데이터와 IP를 잃었다. 독립적인 백업이 존재하지 않아 데이터를 복원할 수 없었다.
– OVH (2021): 화재로 인해 OVH의 스트라스부르 데이터센터의 서버가 파괴됐다. OVH는 백업 데이터를 동일한 데이터센터에 저장했기 때문에 다수의 고객이 데이터를 복구할 수 없었다.
– 랙스페이스(2022): 랙스페이스의 호스팅된 익스체인지 환경이 랜섬웨어 공격을 받았다. 느린 패치로 인해 공격이 허용되었고, 백업이 포함되어 있어도 복구하는 데 몇 달이 걸렸다. 결국 랙스페이스는 호스티스 익스체인지 비즈니스를 중단했다.
– 세일즈포스(2019): 결함이 있는 스크립트가 수정될 때까지 모든 세일즈포스 사용자에게 전체 수정 권한이 부여는 상황이 발생했다. 회사의 백업은 적절한 권한 상태로 신속하게 복원해내지 못했다. 독립적인 SaaS 백업의 필요성을 보여준 사례다.
– 스토리지크래프트(2014): 스토리지크래프트는 클라우드 마이그레이션 중에 실수로 서버를 조기에 폐기했다. 결과적으로 고객 백업 메타데이터를 손실했다. CEO는 모든 책임을 지고 고객이 백업을 재시드(re-seed)하는 작업을 지원했다.
– 유니슈퍼/구글 클라우드(2024년): 구글은 구성 오류로 인한 실수로 유니슈퍼의 전체 클라우드 환경을 여러 리전에서 삭제했다. 하지만 유니슈퍼는 타사 백업을 사용하고 있었으며, 덕분에 일주일 이내에 완전히 복구할 수 있었다.
클라우드 중단에서 얻은 교훈
데이터 손실과 비즈니스 중단이라는 끔찍한 경험에서 얻을 수 있는 어려운 교훈에 대해 살펴본다. 먼저, 클라우드는 무한한 이중화와 자동 백업이 가능한 마법의 영역이 결코 아니다. 그저 다른 조직의 컴퓨터일 뿐이며, 다른 컴퓨터와 마찬가지로 문제가 발생할 수 있다. OVH 데이터센터 화재부터 랙스페이스 랜섬웨어 공격에 이르는 사례에서 이러한 진실을 여러 번 체험한 바 있습니다. 데이터의 안전성은 사용자와 클라우드 제공업체가 데이터를 보호하기 위해 취하는 예방 조치에 달려 있다.
그렇다면 여기서 가장 중요한 교훈은 무엇일까? 클라우드 데이터를 백업하라는 것이다. 서비스 제공업체의 기본 제공 백업 서비스만 믿어서는 곤란하다. 앞서 카보나이트, 스토리지크래프트, OVH 사례에서 보았듯이 재난 발생 시 백업 데이터도 기본 데이터와 함께 증발할 수 있다. 3-2-1 규칙을 철저히 준수해야 한다. 데이터 사본을 두 개의 다른 미디어에 최소 3개 이상 보관하고 한 개는 오프사이트에 보관하도록 한다.
클라우드의 맥락에서 ‘다른 미디어’는 모든 것을 같은 유형의 시스템에 저장하지 않고 다른 장애 도메인을 사용한다는 의미다. 또한 ‘오프사이트’는 완전히 별도의 클라우드 계정 또는 더 좋은 방법은 타사 백업 제공업체를 이용하는 것을 의미한다.
하지만 단순히 백업을 하는 것만이 중요한 것이 아니라 올바른 종류의 백업을 하는 것이 중요하다. 스토리지크래프트 사건이 좋은 예다. 이 회사는 클라우드 마이그레이션 과정에서 고객 백업 메타데이터를 손실하여 백업을 무용지물로 만들었다. 이는 기본 데이터를 백업하는 것뿐만 아니라 백업 데이터 자체의 무결성과 복구 가능성을 유지하는 것의 중요성을 거듭 일깨워 준다.
또 다른 불편한 진실은 SaaS 제공업체도 데이터 손실로부터 자유롭지 않다는 것이다. 세일즈포스의 권한 문제와 KPMG의 팀즈 보존 정책 실패는 유명 SaaS 업체도 실수로 데이터를 망칠 수 있다는 것을 증명한다. 그리고 디두스의 사례에서 보았듯이 복구 기능이 심각하게 제한되어 있는 경우도 있다. 그렇기 때문에 백업 및 복구를 제어할 수 있는 타사 솔루션을 사용하여 SaaS 데이터를 독립적으로 백업하는 것이 중요하다.
이 주장에 대한 반박이 떠오를 수 있다. “내 클라우드 제공업체는 지리적 이중화 및 다중 지역 복제를 제공한다. 그것으로 충분하지 않은가?”라고 말할 수 있겠다. 유니슈퍼 사례가 이 주장을 재반박한다. 구글은 실수로 여러 리전에 걸쳐 있는 전체 클라우드 환경을 삭제했다. 유니슈퍼가 타사 백업을 사용하지 않았다면, 해법이 없었을 것이다.
마지막으로 인적 요소에 대해 이야기해본다. 코드 스페이스 해킹이나 뮤시 구글 계정 삭제 사건과 같은 재난의 대부분은 사람의 실수나 부실한 보안 관행으로 인해 발생했다. 이는 클라우드 인프라가 아무리 정교하더라도 데이터는 전체 고리 중 가장 약한 고리만큼만 안전하다는 사실을 극명하게 보여준다. 팀을 교육하고, 강력한 액세스 제어 및 보안 조치를 구현하고, 항상 항상 테스트를 거친 사고 대응 계획을 세워야 한다.
다시 강조하자면 이 10가지 클라우드 재해 목록에서 피해를 입지 않은 회사는 단 한 곳뿐이었으며, 그 회사는 클라우드 데이터의 타사 백업을 테스트한 회사였다.
클라우드는 믿을 수 없을 정도로 강력한 도구이지만 데이터 보호를 위한 만병통치약은 아니다. 신뢰하되 검증해야 한다. 비즈니스가 데이터에 달려 있다는 생각으로 데이터를 백업해야 한다. 다른 사람들의 불행에서 교훈을 얻어 스스로 불행한 사례가 되지 않도록 해야 한다. 세상에는 데이터를 잃어버린 사람과 잃게 될 사람, 두 가지 유형의 사람들이 있다는 사실을 기억할 필요가 있다. 그런 날이 올 때를 대비해 준비할 것을 권한다.
* W. Curtis Preston는 미스터 백업으로 알려진 전문가다. 1993년부터 백업, 스토리지, 복구 분야에 종사해왔다. dl-ciokorea@foundryco.com
