백업 보안의 피보나치 규칙: 현대 백업 보안을 위한 3-2-1-1-0의 확장

성숙한 백업 전략이 2026년에 실패하는 이유

수년 동안 3-2-1 백업 규칙은 데이터 보호의 토대였습니다. 사진작가 Peter Krogh는 The DAM Book 초판을 쓰면서 이 용어를 자신이 만들었다고 말하며, ASMP의 dpBestflow 프로젝트를 위해 작성한 백업 가이드에서 이를 설명합니다. 중요한 파일은 모두 세 개의 사본으로, 두 가지 서로 다른 미디어 유형에 보관하고, 그중 하나는 오프사이트에 두라는 것입니다. 이 공식은 사진 분야를 훨씬 넘어 퍼졌습니다. 데이터 백업 옵션에 관한 CISA의 문서도 개인 및 업무 데이터에 대해 이 규칙을 되풀이합니다.

이 규칙은 효과가 있었습니다. 더 이상 효과가 없어지기 전까지는요.

Verizon의 2025 Data Breach Investigations Report는 검토한 침해 사고의 44%에서 랜섬웨어를 발견했으며, 이는 이전 판의 32%에서 늘어난 수치입니다. 이 판은 2023년 11월부터 2024년 10월까지의 사고를 다루며, 2024년 11월부터 2025년 10월까지를 다루는 2026년 판은 그 비중을 48%로 제시합니다. 랜섬웨어 그룹이 게시한 피해자를 추적하는 GuidePoint Security 연구팀은 2025년 랜섬웨어 피해자 수가 전년 대비 58% 증가했다고 기록했으며, 이는 이 팀이 추적해 온 해 가운데 가장 활발한 해였습니다. 기업 리스크 책임자에게 더 큰 영향을 주는 사실도 있습니다. Mandiant의 2025년 사고 대응 업무 전반에서 Google Threat Intelligence Group은 랜섬웨어 침입의 약 77%에서 데이터 탈취가 확인되었거나 의심된다고 관찰했으며, 이는 2024년의 약 57%에서 늘어난 수치입니다. 데이터가 이미 탈취되었다면 완벽한 복원은 시스템을 되살릴 뿐 침해 자체를 해결하지는 못합니다.

3-2-1 규칙은 하드웨어 장애, 지역 단위 정전, 실수로 인한 삭제를 대비해 설계되었습니다. 백업 리포지토리를 노리고 들어오는 위협 행위자나 유효한 관리자 자격 증명을 가진 내부자를 대비해 설계된 것이 아닙니다. 공격자는 백업을 파괴하면 피해자에게 몸값 지불 외의 대안이 사라진다는 것을 알고 있습니다. 같은 Google 보고서는 랜섬웨어 행위자들이 "often disabled or deleted backups to inhibit and/or limit recovery options"(복구 선택지를 막거나 제한하기 위해 백업을 비활성화하거나 삭제하는 경우가 많았다)라고 기록합니다.

그래서 이 규칙은 확장되어 왔습니다. Veeam은 자사의 확장판인 3-2-1-1-0을 불변 사본 하나와 복구 오류 0을 더한 것으로 설명합니다. BackupSec은 여기서 한 걸음 더 나아간 방안을 제안하며, 이를 백업 보안의 피보나치 규칙(Fibonacci Rule of Backup Security)이라 부르고 5-3-2-1-1-0으로 표기합니다. 이는 저희의 프레임워크이며 업계 표준이 아닙니다. 피보나치 수열을 거꾸로 읽은 형태이며, 여섯 번째 요소를 더합니다. 바로 그 아래의 모든 계층을 떠받쳐야 하는 다섯 가지 기본 보안 원칙입니다.

성숙한 백업 환경을 운영하는 조직을 위해, 이 글은 2026년에 "포괄적인 데이터 보호"가 무엇을 의미해야 하는지 다시 정의합니다.

3-2-1에서 3-2-1-1-0으로: 간단한 요약

피보나치 규칙을 소개하기 전에, 여기까지 어떻게 왔는지 짚어 볼 필요가 있습니다.

원래의 3-2-1 규칙은 데이터 사본 세 개를 두 가지 서로 다른 미디어 유형에 보관하고, 그중 하나는 오프사이트에 두도록 요구했습니다. 이 규칙은 단일 물리적 사건이 세 사본을 한꺼번에 파괴할 수는 없다는 가정 아래 중복성에 초점을 맞췄습니다.

원래 규칙을 Veeam이 확장한 것으로 지금은 널리 쓰이는 3-2-1-1-0 규칙은 두 가지를 보완했습니다.

• 관리자 자격 증명을 가진 공격자조차 수정하거나 삭제할 수 없는 불변 또는 에어갭 사본 하나.
• 백업 검증에서 오류 0. 모든 백업이 단지 존재하는 것이 아니라 복원 가능하다는 것이 확인된 상태여야 합니다.

이 진화는 두 가지 중요한 공백을 메웠습니다. 백업을 노리는 랜섬웨어, 그리고 재해가 닥치기 전까지 한 번도 테스트되지 않은 백업이 소리 없이 실패하는 문제입니다. 하지만 이 규칙은 그 사본들을 둘러싼 전체 보안 아키텍처, 즉 ID 분리, 권한 있는 접근, 세분화, 지속적 모니터링, 피해 범위(blast radius) 억제를 정의하려 하지 않습니다.

백업 보안의 피보나치 규칙은 바로 이 공백을 메우기 위해 설계되었습니다.

왜 피보나치인가: 숫자 뒤의 논리

피보나치 수열(0, 1, 1, 2, 3, 5, 8, 13...)은 수학에서 가장 우아한 패턴 중 하나로, 각 수는 앞의 두 수의 합입니다. 저희 프레임워크를 거꾸로 읽으면(5, 3, 2, 1, 1, 0) 같은 누적의 논리가 적용됩니다. 각 보호 계층은 그 아래의 토대 위에 쌓입니다.

• 5가지 기본 보안 원칙. 백업을 어떻게 설계할지를 규율하는 다섯 가지 원칙.
• 데이터 사본 3개. 모든 핵심 데이터 세트에 대해 최소 세 개의 사본.
• 2가지 서로 다른 미디어 또는 스토리지/플랫폼 유형. 두 가지 서로 다른 미디어, 스토리지 플랫폼 또는 기술 스택에 보관.
• 오프사이트 사본 1개. 지리적으로 떨어진 위치에 사본 하나.
• 불변, 격리 또는 그 밖의 방식으로 보호되는 추가 사본 1개. 수정이나 파괴로부터 보호되는 추가 사본 하나.
• 검증되지 않은 백업 또는 해결되지 않은 복구 오류 0. 검증되지 않은 채 남은 백업도, 해결되지 않은 복구 오류도 없음.

원래의 3-2-1-1-0 규칙은 "사본이 몇 개, 어디에, 어떤 상태로 있어야 하는가?"라는 운영상의 질문에 답했습니다. 저희가 더한 "5"는 더 근본적인 아키텍처 질문에 답합니다. "백업이 안전하다는 것은 실제로 무엇을 의미하는가?"

이 다섯 가지 원칙이 없으면 나머지 체인은 속이 비어 있습니다. 세 개의 사본으로, 두 가지 미디어에, 불변 상태로 존재하지만 부실한 접근 통제 아래 있거나 침해된 관리자 워크스테이션에서 접근할 수 있는 백업은 보호된 것이 아닙니다. 노출을 기록한 문서일 뿐입니다.

"5": 백업 보안의 다섯 가지 기본 원칙

이 다섯 가지 원칙은 플랫폼 선택부터 보존 정책, 접근 거버넌스에 이르기까지 백업 환경의 모든 아키텍처 결정에 반영되어야 합니다.

1. 설계 단계부터의 사이버 복원력 아키텍처

백업 보안은 나중에 덧붙일 수 없습니다. 첫날부터 설계 제약 조건이어야 합니다.

사이버 복원력을 갖춘 백업 아키텍처는 모든 구성 요소(카탈로그, 스토리지 계층, 관리 평면, 복구 환경)를 잠재적 표적으로 취급합니다. 침해를 전제하고, 손상에 대비해 계획하며, 기술적이든 인적이든 적대적이든 어떤 단일 장애도 복구 능력의 전면 상실로 번지지 않도록 보장합니다.

실무에서 이는 다음을 의미합니다.

• 심층 방어: 각 계층을 여러 개의 독립적인 통제가 보호하므로, 하나가 실패해도 시스템이 노출되지 않습니다.
• 피해 범위 억제: 프로덕션 환경의 침해가 백업 인프라로 번질 수 없고, 한 백업 계층의 침해가 다른 계층으로 번질 수 없습니다.
• 복구 우선 설계: 아키텍처는 데이터를 얼마나 잘 백업하는지만이 아니라 적대적 조건에서, 즉 DNS가 다운되었거나, ID 공급자가 침해되었거나, 주 사이트에 접근할 수 없을 때 얼마나 안정적으로 복원할 수 있는지로 평가됩니다.
• 기능이 아닌 아키텍처의 기본 요소로서의 암호화: 모든 백업은 어떤 상태에서든 저장 시와 전송 시 모두 강력한 업계 표준 암호화로 보호되어야 하며, 암호화 키는 가능한 한 백업 인프라와 독립적으로 관리되어야 합니다. 이상적으로는 전용 HSM이나 관리 소유권이 분리된 키 관리 서비스에 두어야 합니다. 키가 데이터 옆에 있다면 그것은 암호화가 아니라 난독화입니다. 국경을 넘는 데이터 흐름이 있는 기업에게 키 주권(누가, 어떤 관할권에서, 어떤 일정으로 공개를 강제할 수 있는가)은 사고 대응의 문제가 아니라 설계 결정이 됩니다.

과거의 위협 환경에 맞춰 설계된 백업 시스템에 나중에 덧댄 보안은 사고가 한창일 때 그 빈틈을 드러내는 경향이 있으며, 그때가 되면 아키텍처 자체가 약점으로 드러납니다. 복원력은 처음부터 설계에 녹아 있어야 합니다.

2. 제로 트러스트 접근과 강력한 인증

원칙은 단순합니다. 절대 신뢰하지 말고, 항상 검증하라. 백업을 읽거나, 쓰거나, 수정하려는 모든 요청은 네트워크 출처와 관계없이 요청 시점에 인증되고 인가되어야 합니다.

실무적으로 이를 위해서는 다음이 필요합니다.

• 백업 인프라에 접근하는 모든 관리자 ID에 대한 다중 인증(MFA). 이상적으로는 하드웨어 토큰 같은 피싱 저항 방식을 사용합니다.
• 세분화된 범위에서 최소 권한 원칙을 강제하는 역할 기반 접근 제어(RBAC).
• 프로덕션 시스템과 백업 시스템에 대한 별도의 관리자 ID. 침해된 도메인 관리자가 최후의 방어선에 접근할 수 있어서는 안 됩니다.
• 적시(JIT) 권한 상승, 세션 기록, 그리고 보존 정책 변경 같은 민감한 작업에 대한 승인 워크플로를 갖춘 권한 있는 접근 관리(PAM).

랜섬웨어 피해를 입은 3,400개 조직을 대상으로 한 Sophos의 State of Ransomware 2025 설문조사에서 피해자들은 공격의 23%에 대해 침해된 자격 증명을 근본 원인으로 꼽았으며, 이는 악용된 취약점(32%)에 이어 두 번째로 흔한 기술적 근본 원인이었습니다. 백업 환경이 프로덕션을 보호하는 것과 같은 ID 인프라를 신뢰한다면, 그것은 계층형 방어로 포장된 단일 장애 지점입니다.

3. 불변성과 WORM 스토리지

불변성(immutability), 즉 데이터가 한 번 기록되면 정해진 보존 기간 동안 변경하거나 삭제할 수 없는 속성은 "모범 사례"에서 "타협할 수 없는 요건"으로 바뀌었습니다. 클라우드 스토리지의 Object Lock으로 구현하든, WORM(Write Once Read Many) 미디어로 구현하든, 하드웨어로 강제되는 보존 잠금으로 구현하든, 불변성은 백업 리포지토리를 노리고 찾아다니는 위협 행위자에 대한 가장 효과적인 아키텍처적 방어 수단 중 하나입니다.

기록 보존 규정을 적용받는 기업에게 불변성은 규정 준수에도 도움이 될 수 있습니다. SEC Rule 17a-4는 브로커-딜러가 전자 기록을 타임스탬프가 찍힌 완전한 감사 추적과 함께 보관하거나, "in a non-rewriteable, non-erasable format"(재기록 및 삭제가 불가능한 형식으로) 보관할 수 있도록 허용합니다. HIPAA Security Rule은 전자 보호 건강 정보의 "retrievable exact copies"(검색 가능한 정확한 사본)를 생성하고 유지하는 데이터 백업 계획을 요구합니다. 랜섬웨어로부터 여러분을 보호하는 통제 영역은 감사인이 묻는 영역과 같은 경우가 많습니다.

CISA는 대부분의 벤더보다 신중합니다. CISA의 #StopRansomware Guide는 조직에 "maintain offline, encrypted backups of critical data"(핵심 데이터의 오프라인 암호화 백업을 유지하라)라고 권고하며, 그 가용성과 무결성을 정기적으로 테스트하라고 말합니다. 클라우드 벤더의 불변 스토리지는 경고와 함께만 언급합니다. 불변 스토리지가 "does not meet compliance criteria for certain regulations"(특정 규정의 준수 기준을 충족하지 않는다)는 것, 그리고 잘못 구성하면 상당한 비용이 발생할 수 있다는 것입니다. 불변성은 이미 관리자 자격 증명을 쥔 공격자로부터 백업을 온전하게 지켜 줍니다. 하지만 오프라인 사본이나 테스트된 복원을 대신하지는 못합니다.

4. 지속적 검증과 복구 테스트

테스트하지 않은 백업은 백업이 아닙니다. 가설일 뿐입니다.

3-2-1-1-0의 "0"은 오류 0을 요구하지만, 이 주장을 입증하는 유일한 방법은 지속적으로 테스트하는 것입니다. 성숙한 프로그램은 자동화된 무결성 검사, 주기적인 전체 복원 훈련, 검증을 위한 격리된 복구 환경, 그리고 기술 계층만큼 엄격하게 인적 계층과 프로세스 계층을 시험하는 구조화된 도상 훈련(tabletop exercise)을 시행합니다.

복구는 빨라지고 있습니다. 같은 Sophos 설문조사에서 랜섬웨어 피해자의 53%가 일주일 이내에 완전히 복구했으며, 이는 2024년의 35%에서 늘어난 수치이고, 97%는 3개월 이내에 완전히 복구했습니다. Sophos는 이러한 개선이 사고 대비와 복구 준비에 대한 투자를 반영하는 것일 수 있다고 봅니다. 이 설문조사는 테스트된 계획의 효과만을 따로 분리해 보지는 않지만, Sophos 자체의 조언은 양질의 백업을 확보하고 그 백업으로부터의 복원을 정기적으로 연습하라는 것입니다.

리스크 책임자를 위한 교훈은 이것입니다. 백업을 가진 조직과 복구할 수 있는 조직을 가르는 것은 테스트입니다.

5. 격리와 네트워크 세분화

백업 인프라는 프로덕션과 강력하게 세분화되어야 하며, 가능한 한 프로덕션 시스템을 보호하는 것과 같은 관리 신뢰 경계에 의존해서는 안 됩니다.

현대의 모범 사례는 논리적 세분화(별도 VLAN, 전용 서브넷, 엄격한 방화벽 규칙, 마이크로 세분화)와 모든 백업 중 최소 한 사본에 대한 에어갭 또는 준에어갭 아키텍처를 결합합니다. 별도의 ID 공급자를 둔 클라우드 불변성, 오프라인 테이프 순환, 전용 복구 환경, 공유 인프라에서의 테넌시 격리는 모두 같은 아키텍처 목표를 위한 것입니다. 어떤 단일 침해의 피해 범위도 복구 계층까지 미치지 못하게 하는 것입니다.

도메인 컨트롤러를 장악한 위협 행위자가 같은 자격 증명으로 백업 리포지토리에 접근할 수 있다면, 그 백업은 공격 표면과 분리된 것이 아니라 그 일부입니다.

"3-2-1": 여전히 중요한 중복성

다섯 가지 원칙을 토대로 삼더라도, 고전적인 3-2-1 계층은 여전히 필수입니다.

• 모든 핵심 데이터 세트의 사본 3개: 프로덕션 데이터와 최소 두 개의 백업.
• 2가지 서로 다른 미디어 또는 스토리지 플랫폼: 로컬 디스크와 클라우드, 또는 온프레미스 오브젝트 스토리지와 별도의 클라우드 공급자. 목적은 단일 기술 장애, 벤더 장애 또는 한 종류의 공격이 모든 사본을 동시에 파괴할 수 없도록 하는 것입니다.
• 오프사이트 사본 1개: 주 사이트와 지리적으로 분리되어 있고, 이상적으로는 다른 위협 도메인에 있으며, 적절한 경우 다른 규제 관할권에 있는 사본.

이 규칙이 처음 만들어진 이후 달라진 것은 해석입니다. 같은 공급자의 두 클라우드 리전은 "두 가지 서로 다른 미디어"가 아닙니다. 프로덕션 어레이 옆에 있는 SAN의 백업 볼륨은 실질적으로 "오프사이트"가 아닙니다. 현대 기업의 위협 모델링은 각 요건을 더 엄격하게 해석할 것을 요구합니다.

"1-1": 오프사이트, 그리고 불변 또는 에어갭

두 개의 "1"은 서로 다른 장애 도메인을 다룹니다.

첫 번째 "1"은 사이트 단위 사고, 인프라 장애 또는 물리적 재해가 모든 복구 선택지를 한꺼번에 없애지 못하도록, 사본 하나를 주 환경과 지리적으로 분리된 오프사이트에 보관할 것을 요구합니다.

두 번째 "1"은 최소 하나의 추가 사본을 불변성, 에어갭 또는 이에 상응하는 격리 메커니즘으로 수정이나 파괴로부터 보호할 것을 요구합니다. 목적이 다릅니다. 오프사이트 분리는 위치 장애로부터 보호하고, 불변성이나 격리는 관리자 접근 권한을 얻은 공격자로부터 보호합니다.

이 요건들은 구현상 겹칠 수 있습니다. 오프사이트 사본이 동시에 불변 사본일 수도 있으며, 성숙한 환경은 불변 복구 계층과 더 깊은 오프라인 또는 에어갭 사본을 모두 유지하기도 합니다. 중요한 것은 지리적 분리만으로 보안 격리가 된다고 여기지 않는 것입니다.

이 구분은 불변성이 피보나치 규칙의 다섯 가지 보안 원칙에 포함된 이유이기도 합니다. 숫자 "1"은 백업 사본에 대한 최소 보호 요건을 정의하고, 보안 원칙은 보존 통제, 관리자 접근, ID 분리, 관리 평면을 포함한 아키텍처 전반에서 불변성을 고려할 것을 요구합니다.

"0": 검증되지 않은 백업에 대한 무관용

모든 백업은 검증됩니다. 모든 복원은 테스트됩니다. 모든 공백은 문서화되고 해소됩니다.

"0"은 프레임워크의 운영 규율 계층입니다. 자동화된 체크섬, 예약된 복원 검증, 백업 작업 메타데이터에 대한 이상 탐지(작업 크기가 갑자기 급증하면 위협 행위자가 암호화 전 준비 단계에 있다는 신호일 수 있습니다), 백업 관리 활동에 대한 행위 모니터링, 그리고 검증이 실패했을 때의 명확한 에스컬레이션 경로 같은 엄격함을 요구합니다.

이유는 간단합니다. 백업을 파괴하려는 공격자는 먼저 백업 시스템을 건드려야 하며, 그 변경은 복원이 실패하기 전에 작업 설정, 보존 값, 감사 로그에 드러납니다. 오류 0은 허영 지표가 아닙니다. 그 차이가 가장 중요한 순간에 확신과 거짓 확신을 가르는 차이입니다.

기업 리스크 책임자에게 주는 의미

조직이 다른 위협 환경을 위해 설계된 백업 전략으로 운영되고 있다면, 현재 가진 것과 필요한 것 사이의 격차는 더 이상 이론적인 문제가 아닙니다. 재무적 현실을 생각해 보십시오.

• Sophos의 2025년 설문조사는 몸값 지불액 중앙값을 100만 달러로, 몸값을 제외한 평균 복구 비용을 153만 달러로 제시했습니다.
• Verizon의 2025 DBIR는 랜섬웨어 피해 조직의 64%가 몸값을 지불하지 않았다고 보고하며, 이는 2년 전의 50%에서 늘어난 수치입니다. 다른 표본을 조사한 Sophos는 피해자의 49%가 데이터를 되찾기 위해 몸값을 지불했다고 밝혔습니다. 어느 쪽이든 지불은 더 이상 기본 선택이 아니며, 지불을 거부하는 조직에는 실제로 작동하는 복원 경로가 필요합니다.

규제 산업에 속하거나 복잡한 하이브리드 환경을 관리하는 기업에게는 이 계산이 훨씬 더 절박합니다. 미국 상장 기업은 중대한 사이버 보안 사고를 Form 8-K로 공시해야 하며, 일반적으로 사고가 중대하다고 판단한 날로부터 영업일 기준 4일 이내에 공시해야 합니다. 그 밖의 많은 관할권과 산업도 자체적인 보고 의무를 부과합니다. 복구할 수 없는 사고의 비용은 더 이상 운영상의 비용에 그치지 않습니다. 평판과 규제 측면의 비용이기도 합니다.

피보나치 규칙을 도입한다고 해서 인프라를 처음부터 다시 구축할 필요는 없습니다. 필요한 것은 정직한 아키텍처 평가, 명확한 원칙에 따른 우선순위별 개선, 그리고 백업 보안을 구매 항목이 아니라 통합된 분야로 다루겠다는 거버넌스 차원의 약속입니다.

BackupSec의 역할

BackupSec은 팀이 위의 원칙에 맞춰 Veeam 백업 환경을 운영할 수 있도록 돕습니다. 저희는 백업 플랫폼을 대체하지 않습니다. 그 보안을 관찰 가능하게 만들고, 조언하고, 테스트합니다.

• ZeroMON은 Veeam Backup & Replication을 모니터링합니다. 작업 상태, 누가/무엇을/언제 변경했는지 추적하는 구성 변경 이력, Security Analyzer 체크리스트, 보고서, 허니팟을 제공합니다. Veeam의 리포지토리 설정이 보고하는 그대로 불변성 상태를 보여 주며, 스토리지의 오브젝트 수준 잠금을 검증하지는 않습니다. 경보는 이메일과 인앱 알림으로 전달됩니다. OVA 형태로 온프레미스에 배포되고, 읽기 전용 계정으로 연결되며, BackupSec이나 어떤 제3자에게도 아무것도 보내지 않습니다.
• ZeroTAM은 아키텍처, 용량, 랜섬웨어 복구 계획, 위기 시 우선 지원을 위한 전담 백업 보안 어드바이저를 제공합니다.
• ZeroPEN은 Veeam Backup & Replication, Veeam ONE, Enterprise Manager를 대상으로 하는 위협 주도형 모의 침투 테스트로, MITRE ATT&CK에 매핑된 8개의 킬 체인 단계로 구성됩니다. 이 과정에는 복원 무결성 및 불변성 검증도 포함됩니다. 실제 백업을 삭제하거나, 실제 암호화를 수행하거나, 프로덕션 또는 백업 서비스를 중단하는 일은 절대 없습니다. 감사 대응이 가능한 증거와 치명적 발견 사항에 대한 재테스트를 받게 됩니다.
• ZeroVault는 오프사이트 불변 사본을 위한, Object Lock을 지원하는 S3 호환 불변 클라우드 오브젝트 스토리지입니다.

백업 보안 태세에 대해 BackupSec과 상담하기 →