본문 바로가기

백업 3-2-1 원칙: 랜섬웨어 시대에 데이터 지키는 가장 현실적인 전략

📑 목차

    백업 3-2-1 원칙이 필요한 환경에서 랜섬웨어로 파일이 암호화되거나 계정이 탈취됐을 때, 어떤 복구 경로를 남길지 기준과 점검 순서를 정리한다.

    랜섬웨어 대응은 탐지 도구만으로 끝나지 않는다. 실제로는 "복구가 가능한 백업이 존재하는가"가 피해 규모를 결정한다. 백업이 있다고 말하지만, 막상 복구 버튼을 눌렀을 때 실패하는 경우가 반복된다.

    랜섬웨어 대응에서 자주 터지는 착각

    가장 흔한 착각은 "클라우드에 올려두면 백업이 끝났다"는 생각이다. 동기화 폴더는 편하지만, 랜섬웨어가 암호화한 파일이 그대로 동기화되면 원본까지 동시에 망가질 수 있다. 이때 백업 3-2-1 원칙이 요구하는 "서로 다른 매체"와 "오프사이트"가 빠져 있으면 복구 지점이 사라진다.

    핵심 개념 1: 백업 3-2-1 원칙의 구조

    백업 3-2-1 원칙은 데이터를 3개 사본으로 유지하고, 2개는 서로 다른 저장 매체에 두며, 1개는 원격지(오프사이트)에 보관하는 백업 운영 규칙이다. "사본 개수(3)"는 실수·장애·악성코드 상황에서 복구 지점을 남기기 위한 조건이다. "매체 다양화(2)"는 동일 취약점(같은 NAS, 같은 계정 권한, 같은 랜섬웨어 영향)을 줄이기 위한 조건이다. "원격지(1)"는 화재·침수·도난·사내 네트워크 감염 같은 단일 사건으로 전부 잃는 상황을 막기 위한 조건이다.

    그러나 주의해야 할 점이 있다. 사본이 3개라도 모두 같은 계정 권한으로 접근 가능하면 랜섬웨어가 함께 암호화할 수 있다. 오프사이트가 "항상 연결된 클라우드 드라이브"라면 동기화로 같이 망가질 수 있으므로 버전/불변(immutability) 정책을 함께 확인해야 한다. 백업 성공 로그만 믿고 복구 테스트를 하지 않으면, 필요한 순간에 복구가 실패할 수 있다.

    3-2-1 원칙이 사본·매체·원격지를 나누는 구조
    3-2-1 원칙이 사본·매체·원격지를 나누는 구조

    핵심 개념 2: 랜섬웨어 시대에는 '복구 가능성'을 설계해야 한다

    복구 가능성은 "백업 파일이 존재한다"가 아니라 "원하는 시점으로, 원하는 범위만, 제한 시간 안에 복구할 수 있다"는 운영 상태를 의미한다. 복구 지점은 시점(최근성)과 무결성(암호화/오염 여부) 두 조건을 동시에 만족해야 한다. 랜섬웨어 대응에서는 백업 저장소가 공격자 권한에 노출되지 않도록 분리(계정/네트워크/접속 경로)를 설계해야 한다. 파일 단위 복구와 시스템 단위 복구를 분리해 준비하면, 피해 규모에 따라 복구 시간을 줄일 수 있다.

    실무에서 주의할 점은 다음과 같다. NAS에만 백업하고 NAS가 같은 도메인/같은 관리자 계정에 묶여 있으면 3-2-1처럼 보여도 실제로는 "1-1-0"에 가깝다. 외장 하드가 항상 PC에 연결돼 있으면 오프라인 매체가 아니라 "연결된 매체"로 취급해야 한다. 오프사이트 백업이 있어도 복구 절차(권한, 키, 콘솔 접근)가 준비되지 않으면 복구 지연이 발생한다.

    비교표: 3-2-1을 만족하는 듯 보이지만 실패하는 구성

    구성 상황 문제점과 해결책
    PC + 동기화 클라우드 + NAS 3개처럼 보이지만, 동일 계정/동일 네트워크로 연결돼 있어 동시 암호화 발생. 해결: 외장 드라이브를 평소 분리하고, 오프사이트는 버전/불변 저장소로 구성.
    NAS 백업만 존재 백업 저장소가 공격자 권한에 노출되면 동시 암호화 위험. 해결: 백업 쓰기 권한을 최소화하고, 접근 계정을 운영 계정과 분리.
    클라우드 동기화만 오프사이트 암호화된 파일이 그대로 업로드되면 원격 사본도 손상. 해결: 버전 관리나 불변 저장(삭제 방지)을 반드시 활성화.

    YES/NO 체크리스트: 지금 구성은 3-2-1로 방어가 되는가

    • YES: 데이터 사본이 최소 3개 존재하며, 그중 2개는 서로 다른 매체에 저장돼 있다.
    • YES: 1개 사본은 원격지에 있고, 운영 계정이 탈취돼도 삭제/암호화가 어렵도록 버전 또는 불변 저장 정책이 적용돼 있다.
    • YES: 외장 매체는 평소 분리돼 있고, 백업 저장소 접근 계정은 일상 업무 계정과 분리돼 있다.
    • NO: 모든 백업이 같은 네트워크 공유(동일 관리자 계정) 아래에 있다면 3-2-1처럼 보이더라도 동시 손상이 가능하다.

    실전 점검 절차: 백업 3-2-1을 '복구 가능한 상태'로 만드는 순서

    백업 3-2-1 원칙은 체크박스가 아니라 운영 절차로 완성된다. 아래 순서로 점검하면 "사본은 있는데 복구가 안 되는" 상황을 줄일 수 있다.

    1. 대상 데이터 범위 확정: 업무 핵심 폴더/DB/설정 파일 중 반드시 복구해야 하는 범위를 먼저 정한다.
    2. 3개 사본 확인: 원본 + 백업 1 + 백업 2가 실제로 다른 경로에 존재하는지, 최근 백업 시간이 언제인지 확인한다.
    3. 2개 매체 분리 확인: NAS와 외장 드라이브처럼 물리/논리적으로 다른 매체인지 확인하고, "항상 연결" 상태인지 점검한다.
    4. 1개 오프사이트 확인: 원격지 백업이 단순 동기화인지, 버전 관리 또는 불변 저장(삭제 방지)이 가능한 저장소인지 확인한다.
    5. 접근 권한 분리: 백업 저장소 쓰기 권한을 최소화하고, 백업 작업 전용 계정/키를 분리해 보관한다.
    6. 복구 테스트 수행: 작은 파일 묶음과 중요한 파일 1개를 골라 실제 복구를 실행하고, 소요 시간과 성공 여부를 기록한다.

    점검할 때는 백업 작업 로그에서 다음 정보를 찾아야 한다.

    Backup Job Status: SUCCESS
    Restore Point: 2026-01-05 23:00
    Retention: 30 days
    Immutable: Enabled

    SUCCESS만 보고 끝내면 위험하다. Restore Point와 Retention이 기대한 수준인지, Immutable 같은 삭제 방지 옵션이 켜져 있는지 확인해야 한다. 특히 랜섬웨어 상황에서는 "백업 삭제"가 2차 피해로 이어질 수 있다.

    실전 예시: NAS 백업 시나리오

    사내 파일 서버가 랜섬웨어로 암호화되었고, NAS에 백업이 있다고 판단해 복구를 시도했으나 NAS의 백업 폴더도 같은 확장자로 바뀌어 있었다. NAS가 도메인 관리자 계정으로 마운트 되어 있었고, 백업이 "파일 복사" 형태로만 운영되어 랜섬웨어가 접근 가능한 경로를 모두 암호화했기 때문이다.

    백업 3-2-1 원칙에서 요구하는 "매체 분리"와 "오프사이트"가 사실상 충족되지 않았다. 적합한 구성은 다음과 같다. 외장 매체를 평소 분리해 두고, 오프사이트 백업은 버전/불변 저장으로 구성해 "암호화가 전파되지 않는 사본"을 남겨야 한다. 또한 백업 쓰기 권한을 최소화해 NAS가 공격자 권한에 노출되지 않게 해야 한다.

    복구를 위해서는 먼저 백업 저장소 접근 로그에서 평소 없던 관리자 작업(대량 삭제/대량 변경)이 있었는지 확인한다. 그다음 오프사이트 저장소에서 불변/버전 기반의 이전 시점으로 복구 가능한지 점검한다. 이후에는 백업 전용 계정과 오프라인 매체 운영을 포함해 3-2-1을 재구성해야 한다.

    백업 3-2-1 점검과 복구 테스트를 위한 단계 흐름
    3-2-1 점검과 복구 테스트를 위한 단계 흐름

    결론

    백업 3-2-1 원칙은 사본 3개, 다른 매체 2개, 오프사이트 1개를 통해 단일 사건으로 전부 잃는 위험을 줄이는 운영 규칙이다. 랜섬웨어 시대에는 백업 존재 여부가 아니라 복구 가능성(시점·무결성·시간)을 설계하고, 계정/경로/매체를 분리해야 한다. 복구 테스트를 정기적으로 수행해 "백업 성공"이 실제 복구 성공으로 이어지는지 확인해야 한다.

    연계 주제로는 백업 보존 정책(보관 기간/버전 수)과 계정 권한 분리(백업 전용 계정/키 관리)가 적합하다.

    FAQ

    백업 3-2-1 원칙에서 '2개 매체'는 같은 NAS 두 대로 대체할 수 있나

    같은 종류의 장비를 두 대 쓰는 것만으로는 매체 다양화가 충분하지 않을 수 있다. 두 NAS가 같은 계정/같은 네트워크 권한에 묶이면 랜섬웨어가 동시에 접근할 수 있다. 물리·논리적으로 다른 매체와 분리 운영이 필요하다.

    클라우드 동기화 폴더는 오프사이트 백업으로 볼 수 있나

    동기화는 편리하지만, 암호화된 파일이 그대로 업로드되면 원격지 사본도 함께 손상될 수 있다. 오프사이트로 활용하려면 버전 관리나 불변 저장처럼 이전 시점으로 되돌릴 수 있는 조건을 함께 갖춰야 한다.

    복구 테스트는 어떤 방식으로 해야 백업 3-2-1 점검이 되나

    작은 파일 묶음과 핵심 파일 1개를 선정해 실제 복구를 수행하는 방식이 현실적이다. 복구 지점이 기대한 시점인지, 권한과 접근 절차가 준비돼 있는지, 소요 시간이 허용 범위인지 기록하면 3-2-1 운영 품질을 올릴 수 있다.