3-2-1-1-0 규칙이 실제로 말하는 것
3-2-1-1-0 규칙은 데이터 사본을 몇 개 보관해야 하는지, 어떤 매체에 보관해야 하는지, 그리고 실제로 제대로 작동한다는 것을 어떻게 입증해야 하는지를 정리한 데이터 보호 공식입니다.
- 3개의 데이터 사본 — 프로덕션 사본 1개에 최소 2개의 백업.
- 2개의 서로 다른 매체 또는 스토리지 플랫폼 — 단일 기술 장애나 벤더 장애로 모든 사본이 한꺼번에 파괴되지 않도록 합니다.
- 1개의 사본은 오프사이트에 보관 — 원본 사이트와 지리적으로 분리된 위치입니다.
- 1개의 추가 사본은 불변 또는 에어갭 상태 — 관리자 자격 증명을 가진 공격자라도 접근하거나 수정할 수 없어야 합니다.
- 0건의 오류 — 모든 백업이 검증되고 모든 복구가 테스트되어야 하며, 작동할 것이라고 그저 가정해서는 안 됩니다.
얼핏 자연스러운 연장처럼 보이지만, 추가된 두 숫자 — 두 번째 '1'과 '0' — 은 원래 공식에 포함되어 있지 않았습니다. 이 둘은 몇 년 뒤, 랜섬웨어가 백업을 구체적으로 노리기 시작한 것에 대한 직접적인 대응으로 덧붙여졌습니다. 이 숫자들이 왜 추가되었는지를 이해하는 것은, 체크리스트 자체보다 현대 백업 전략에 대해 더 많은 것을 설명해줍니다.
이 규칙의 유래
이름 중 '3-2-1' 부분은 랜섬웨어보다 훨씬 이전부터 존재했습니다. 사진작가 Peter Krogh는 2006년 저서 The DAM Book: Digital Asset Management for Photographers 에서 이 표현을 처음 사용했습니다. 그는 IT 전문가들 사이에서 관찰한 여러 관행을, 대체 불가능한 디지털 아카이브를 갑자기 책임지게 되었지만 시스템 관리자는 아니었던 현업 사진작가들도 실제로 실천할 수 있을 만큼 단순한 공식으로 압축해냈습니다. Krogh가 이중화된 오프사이트 사본이라는 근본적인 개념 자체를 만들어낸 것은 아니지만, 그는 이 개념에 기억하기 쉬운 이름을 붙여주었습니다. 이 규칙은 이후 2012년 US-CERT의 데이터 백업 옵션 관련 발간물에서 공식적으로 그의 공로로 인정되었는데, 그 무렵에는 이미 기업 IT 전반에서 기본 권장 사항으로 자리 잡은 상태였고, 오늘날에도 CISA와 NIST 양측 모두가 지지하는 기본 원칙으로 남아 있습니다.
원래의 3-2-1 규칙은 당시 시대의 위협, 즉 디스크 장애, 화재, 홍수, 도난, 실수로 인한 삭제에 대응하기 위해 설계되었습니다. 이 규칙의 핵심 전제는, 단 하나의 물리적 사건만으로는 두 가지 매체 유형과 두 곳의 위치에 분산된 세 개의 데이터 사본을 동시에 파괴할 수 없다는 것이었습니다. 이 전제는 약 10년 동안 유효했습니다.
3-2-1만으로는 더 이상 충분하지 않게 된 이유
이 전제는 랜섬웨어 공격자들이 백업 인프라를 우회해야 할 장애물이 아니라 주요 표적으로 다루기 시작하면서 깨졌습니다. 세 개의 사본이 모두 동일하게 침해된 프로덕션 자격 증명으로 접근 가능하더라도, 두 가지 매체 유형에 하나는 오프사이트로 보관되어 있다면 여전히 3-2-1 규칙을 완벽히 충족합니다 — 그리고 이것이 바로 현대 랜섬웨어 조직이 정확히 노리는 시나리오입니다.
이러한 변화의 규모는 뚜렷합니다. Veeam의 2025년 랜섬웨어 트렌드 보고서에 따르면, 설문에 참여한 1,300개 조직 중 랜섬웨어 피해 조직의 89%가 공격 과정에서 백업 리포지토리를 직접 공격당했습니다. Sophos의 2025년 State of Ransomware 보고서는 해당 설문이 시작된 지 6년 만에 가장 낮은 백업 복구율을 기록했습니다. 백업을 이용해 데이터를 복구할 수 있었던 조직은 54%에 불과했으며, 공격자의 최초 몸값 요구액보다 더 많은 금액을 지불하게 된 조직 중에서는 38%가 백업 실패 또는 오작동을 직접적인 원인으로 꼽았습니다.
지리적으로 분산된 세 개의 사본이라 해도, 이미 세 사본 모두를 삭제할 수 있는 자격 증명을 확보한 공격자를 막지는 못합니다. 바로 이 간극을 메우기 위해 두 개의 추가 숫자가 설계된 것입니다.
추가된 '1': 공격자가 진정으로 닿을 수 없는 사본
추가된 '1'은 최소 하나의 사본이 불변 상태여야 함을 요구합니다 — 일반적으로 클라우드 스토리지의 오브젝트 잠금, Write Once Read Many(WORM) 하드웨어, 또는 스토리지 계층에서 보존 정책이 강제되는 하드닝된 리포지토리를 통해 정해진 보존 기간 동안 변경이나 삭제로부터 보호되어야 합니다 — 또는 에어갭 상태여야 하며, 이는 프로덕션으로부터 상시 열려 있는 네트워크 경로가 전혀 없다는 것을 의미합니다.
이는 처음 보기보다 훨씬 엄격한 요건입니다. 동일한 관리자 계정으로 접근 가능한, 같은 클라우드 제공업체의 두 리전은 이 요건을 충족하지 못합니다 — 자격 증명 분리 없는 지리적 분리는 이미 도메인 관리자 권한을 확보한 공격자에게는 실질적인 보호가 되지 못합니다. 실제로 제대로 구현된 사례들은 대개 빠른 복구를 위한 클라우드 기반 불변 스토리지와, 불변 계층의 관리 플레인마저 침해당하는 최악의 시나리오에 대비한 더 깊은 오프라인 또는 에어갭 사본을 함께 조합합니다.
CISA의 랜섬웨어 가이드라인은 오프라인의 암호화된 백업을 최후의 방어선으로 취급해야 한다고 명확히 밝히고 있습니다. 이는 이러한 백업이 침해된 ID가 도달할 수 있는 피해 반경 바깥에 위치하기 때문입니다.
'0': 백업이 실제로 작동함을 입증하기
'0'은 이 규칙의 운영적 측면을 담당하며, 조직들이 가장 자주 건너뛰는 부분이기도 합니다. 이는 검증되지 않은 백업이 하나도 없어야 한다는 것을 요구합니다 — 단순히 초록색 '작업 성공' 알림만 지켜보는 것이 아니라, 모든 백업의 무결성을 점검하고 모든 복구 경로를 처음부터 끝까지 정기적으로 테스트해야 합니다.
성공으로 보고되는 백업 작업과 실제로 작동하는 복구 사이의 간극은 크며, 이미 잘 알려져 있습니다. 2025년 업계 설문조사에 따르면 조직의 62%가 정기적인 백업-복구 테스트를 수행하지 못하고 있으며, 37%는 백업이 누락되었거나 검증된 적이 없다는 이유만으로 요구되는 복구목표시간 내에 복구하지 못했습니다. 적절한 무결성 및 악성코드 검사 없이 복구를 시도할 경우, 추정치에 따르면 조직의 63%가 애초에 장애를 일으켰던 것과 동일한 감염을 재유입시킬 위험에 놓이며, 이는 복구 시도를 두 번째 사고로 만들어버립니다.
'0'이 존재하는 이유는, 한 번도 복구해본 적 없는 백업은 통제 수단이 아니라 가정에 불과하기 때문입니다. 일정에 따라 수행되고 현실적인 복구 시간 목표를 기준으로 측정되는 검증이야말로, 이러한 가정을 실제 사고 상황에서 믿고 의지할 수 있는 사실로 바꿔줍니다.
3-2-1-1-0을 구현할 때 흔히 저지르는 실수
- 두 개의 클라우드 리전을 '두 가지 매체'로 계산하는 것. 매체 유형의 다양성이란 동일한 오브젝트 스토어의 두 개 인스턴스가 아니라, 진정으로 서로 다른 스토리지 기술이나 플랫폼을 의미합니다.
- 추가된 '1'이 어떤 오프사이트 사본으로든 충족된다고 여기는 것. 오프사이트는 지리적 위험에 대응하는 것이고, 불변 또는 에어갭은 자격 증명 침해에 대응하는 것입니다. 규칙상으로는 오프사이트 요건을 충족하더라도 프로덕션과 ID 체계를 공유하는 사본이라면, 이 숫자가 추가된 본래 취지인 간극을 메우지 못합니다.
- 백업 작업이 초록색으로 표시된다는 이유로 '0'을 건너뛰는 것. 백업 작업 성공은 데이터가 기록되었다는 것만 확인해줄 뿐, 그 데이터가 복구 가능한지, 애플리케이션 일관성을 유지하는지, 복구를 필요하게 만들 악성코드로부터 자유로운지는 확인해주지 않습니다.
- 데이터의 중요도와 관계없이 규칙을 획일적으로 적용하는 것. 티어1 시스템은 일반적으로 아카이브 데이터보다 더 잦은 검증과 더 짧은 RTO가 필요합니다. 전체 자산에 단일한 보존·테스트 정책을 적용하면 대개 가장 중요한 시스템은 보호가 부족해지고, 그렇지 않은 시스템에는 과도한 비용을 쓰게 됩니다.
2026년에도 3-2-1-1-0만으로 충분할까?
대부분의 조직에게 있어, 추가된 '1'과 '0'을 단순히 체크만 하는 것이 아니라 실제로 강제 적용하며 3-2-1-1-0을 올바르게 구현하는 것만으로도, 애초에 랜섬웨어가 백업을 노릴 수 있게 만든 간극의 대부분을 메울 수 있습니다. 이는 여전히 견고한 운영 기준이며, CISA와 NIST 모두 계속해서 이를 하나의 기준으로 지지하고 있습니다.
이 규칙이 부족한 부분은 아키텍처입니다. 3-2-1-1-0은 '사본이 몇 개, 어디에, 어떤 상태로 있어야 하는가'에는 답하지만, 공격을 받는 상황에서 그 사본들이 그 상태를 유지할 수 있는지를 결정하는 접근 거버넌스, 네트워크 세그멘테이션, 지속적인 모니터링에 대해서는 아무것도 말해주지 않습니다. 바로 이 간극을 메우기 위해 만들어진 것이 BackupSec 자체의 Fibonacci Rule of Backup Security(5-3-2-1-1-0)이며, 동일한 사본 수 공식 아래에 다섯 가지 기초 보안 원칙을 추가한 것입니다. 다만 이제 막 3-2-1-1-0을 완전하고 검증 가능하게 갖추려는 조직이라면, 이는 필수 전제 조건이 아니라 다음 단계로 보면 됩니다.
BackupSec이 어떻게 도움이 되는가
BackupSec은 기업 팀이 자사의 3-2-1-1-0 구현이 단순히 문서화된 것이 아니라 실제로 작동하고 있음을 검증할 수 있도록 돕습니다 — 백업 보안을 관찰 가능하고(observable), 자문 가능하며(advisable), 입증 가능하게(provable) 만드는 방식을 통해서입니다.
저희의 접근 방식은 세 가지 계층으로 구성됩니다.
- ZeroMON은 전체 백업 자산에 대한 지속적인 관찰 가능성을 제공합니다 — 실시간 작업 추적, 자동화된 보안 점검, 설정 변경에 대한 포렌식 감사 추적, 원클릭 컴플라이언스 보고서를 갖춘 Veeam 대응 모니터링입니다. 이 계층이 바로 규칙의 '0건의 오류' 요건을 바람에서 증거로 바꿔주는 부분입니다.
- ZeroTAM은 백업 아키텍처, 불변성 설정, 랜섬웨어 복구 계획에 대한 전담 전문가 자문을 제공합니다 — 대부분의 기업이 추가된 '1'이 단순히 지리적으로 떨어져 있는 것이 아니라 진정으로 격리되어 있는지 확인하기 위해 필요로 하는 인적 계층입니다.
- ZeroPEN은 실제 공격자와 동일한 방식으로 백업 인프라를 침투 테스트합니다 — 관리 플레인, 접근 제어, 불변성 설정을 표적으로 삼습니다 — 그런 다음 실제 복구 시나리오를 실행하여 명시된 RTO 내에 깨끗하고 완전하게 복구할 수 있음을 입증합니다.
BackupSec은 온프레미스로 배포되며, 읽기 전용 API 접근을 통해 백업 애플리케이션에 연결되고, 백업 데이터를 여러분의 환경 밖으로 이동시키는 일이 없습니다.
BackupSec과 백업 보안 태세에 대해 상담하기 →
여러분의 환경이 어느 정도 수준인지 확인해보고 싶으신가요? 무료 Backup Security Assessment로 점검해보세요.