수정 이력(초판만, 2026년 11월 01일 공개)
- 최초 공개
이 글을 인용하기(DOI: 10.5281/zenodo.23969173)
이 글은 Zenodo에 보관되어 있습니다. 항상 최신 버전으로 연결되는 DOI와 지금 보고 있는 버전에 고정된 DOI를 아래에 함께 제시합니다.
Go Komura (2026). 「랜섬웨어에 견디는 백업 ── 3-2-1 규칙, 덮어쓸 수 없는 저장소, 복원할 수 있는지 확인」. 합동회사 코무라소프트. https://doi.org/10.5281/zenodo.23969173 https://comcomponent.com/ko/blog/ransomware-resilient-backup/
- DOI(최신 버전)
- 10.5281/zenodo.23969173
- DOI(이 버전)
- 10.5281/zenodo.23969174
랜섬웨어 피해에서는 백업을 해 두었는데도 복원하지 못했다는 예가 많습니다. 가장 많은 원인은 백업도 함께 암호화되어 있었다는 것입니다. 이 글에서는 중소기업의 Windows PC와 파일 서버를 대상으로, 공격에 견디는 백업을 만드는 방법을 설명합니다.
요점은 세 가지입니다. 감염된 PC가 덮어쓸 수 없는 복제본을 하나 둘 것, ‘이전 버전’을 백업 대신 쓰지 않을 것, 실제로 복원할 수 있는지 확인할 것입니다. 3-2-1 규칙으로 복제본의 수와 둘 곳을 정하지만, 그것만으로는 랜섬웨어 대비로 부족한 점이 있습니다.
글에 나오는 명령은 Windows 전용이며, Windows Server 2022의 관리자 명령 프롬프트에서 실행해 출력을 확인했습니다. 제품의 설정 화면과 요금은 바뀔 수 있으므로 도입할 때는 각 회사의 최신 자료를 확인하세요.
백업이 있어도 복원하지 못한 기업이 많다
일본 경찰청은 랜섬웨어 피해를 입은 기업·단체에 백업 상황을 묻고 있습니다. 2025년 상반기 보고에서는 응답한 53건 중 51건이 백업을 해 두었습니다. 그런데 백업에서 피해 직전 수준까지 복원할 수 있었는지를 물은 48건 중 복원할 수 있었던 것은 7건이고, 41건은 복원하지 못했습니다1.
복원하지 못한 이유를 답한 35건에서는 ‘백업도 암호화’가 23건, ‘운용 미비’가 8건, ‘기타’가 4건이었습니다1. 같은 보고는 랜섬웨어 그룹이 흔적을 지우고 복구 작업을 못 하게 하려고 피해 기업의 로그와 백업을 삭제한다고 쓰고 있습니다. 그런 다음 백업을 오프라인 환경에 보관하라고 요구하고 있습니다2.
flowchart TB
accTitle: 백업이 있어도 복원하지 못하는 흐름
accDescr: 백업을 해 두어도 감염된 PC에서 닿는 곳에 있으면 함께 암호화되고, 복원 절차를 확인해 두지 않았다면 운용 미비로 복원하지 못한다는 것을 보여 주는 그림.
A["백업을 해 두었다"] --> B{"감염된 PC에서 닿는가"}
B -->|"닿는다"| C["함께 암호화·삭제된다"]
B -->|"닿지 않는다"| D{"복원 절차를 확인했는가"}
D -->|"확인하지 않았다"| E["운용 미비로 복원하지 못한다"]
D -->|"확인했다"| F["복원할 수 있다"]
그림 1: 백업은 감염된 PC에서 닿지 않고, 복원 절차를 확인해 두었을 때 쓸 수 있다.
복원한 예도 있습니다. IPA의 「중소기업의 정보보안 대책 가이드라인」 제4.0판에는 VPN 기기를 통해 침입당해 파일 서버 등이 암호화된 건설업 사례가 실려 있습니다. 이 회사는 연 2회 복원 훈련을 하던 덕분도 있어, 발각 5일 뒤에는 백업에서 기간 시스템을 다시 가동했습니다. 그래도 각 사내 시스템의 재개에는 41일, 원격 접속의 재개에는 4개월이 걸렸고, 사내 파일의 20% 남짓을 잃었습니다3. 백업에서 복원할 수 있다고 해서 피해가 없어지는 것은 아닙니다.
그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 13건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle
공격자는 닿는 곳의 백업을 지운다
미국 CISA 등이 내고 있는 #StopRansomware 가이드는, 많은 랜섬웨어가 몸값을 내지 않으면 복원할 수 없는 상태로 만들기 위해 손이 닿는 백업을 찾아 삭제하거나 암호화하려 한다고 쓰고 있습니다. 그래서 백업을 오프라인으로 보관하는 것이 중요하다고 합니다4.
Microsoft도 공격자가 백업 소프트웨어나, 볼륨 섀도 복사본 같은 OS 기능을 쓸 수 없게 만드는 데 힘을 쏟는다고 쓰고 있습니다5. 감염된 PC에서 닿는 백업에는 다음과 같은 것이 있습니다.
- PC에 항상 연결해 둔 외장 드라이브
- 드라이브 문자를 할당한 NAS나 파일 서버의 공유 폴더
- 평소 계정으로 쓸 수 있는 클라우드 동기화 폴더
- 같은 볼륨에 있는 섀도 복사본(이전 버전)
OS에 들어 있는 명령으로도 섀도 복사본과 백업 카탈로그는 지울 수 있습니다. MITRE ATT&CK은 이 수법을 ‘Inhibit System Recovery’(T1490)로 정리하고 있습니다. 거기에는 vssadmin.exe delete shadows /all /quiet로 섀도 복사본을 모두 지우는 예와, wbadmin.exe delete catalog -quiet로 Windows 백업 카탈로그를 지우는 예가 나와 있습니다6. CISA 가이드도 vssadmin.exe, wbadmin.exe, wmic.exe(shadowcopy) 등의 수상한 사용을 감시하라고 요구합니다4.
flowchart TB
accTitle: 감염된 PC에서 닿는 백업과 닿지 않는 백업
accDescr: 감염된 PC에서 상시 연결된 외장 드라이브, 할당한 공유 폴더, 동기화 폴더, 섀도 복사본에는 쓸 수 있지만, 분리한 미디어와 덮어쓸 수 없는 저장소에는 쓸 수 없다는 것을 보여 주는 그림.
P["감염된 PC"] --> R["쓸 수 있는 곳"]
P -.-x N["분리한 미디어, 덮어쓸 수 없는 저장소"]
R --> A["상시 연결된 외장 드라이브"]
R --> B["할당한 공유 폴더"]
R --> C["클라우드 동기화 폴더"]
R --> D["섀도 복사본"]
그림 2: 감염된 PC가 쓸 수 있는 곳에 있는 백업은 공격 대상이 된다.
시간을 들이는 공격에도 주의가 필요합니다. Microsoft는 랜섬웨어가 키를 시스템에 남겨 둔 채 조금씩 암호화를 진행하는 경우가 있다고 씁니다. 그동안에도 사용자는 평소처럼 데이터를 쓸 수 있으므로, 암호화를 알아채지 못한 채 암호화된 데이터의 백업이 늘어 갑니다. 모두 암호화한 뒤 키가 지워지면 최근 백업도 읽을 수 없게 됩니다5. 가장 최근의 1세대만 남겨 두면 이 경우에 돌아갈 곳이 없습니다.
‘이전 버전’은 백업을 대신하지 않는다
Windows의 ‘이전 버전’과 공유 폴더의 섀도 복사본은 볼륨 섀도 복사본 서비스(VSS)를 사용합니다. Windows에 포함된 VSS 시스템 공급자는 블록이 덮어쓰이기 전에 그 내용을 차이 영역으로 옮겨 두는 쓰기 시 복사 방식으로, 어느 시점의 볼륨을 재현합니다7.
Microsoft는 VSS 자료에서 섀도 복사본과 백업의 차이를 다음과 같이 설명합니다. 섀도 복사본에서 테이프 같은 이동식 미디어로 데이터를 옮겼을 때, 그 미디어의 내용이 백업이 됩니다. 옮긴 뒤에는 섀도 복사본 자체를 삭제해도 된다고 합니다7. 차이 영역이 부족해지면 오래된 섀도 복사본부터 차례로 삭제된다는 점도 적혀 있습니다7.
flowchart TB
accTitle: 섀도 복사본과 백업의 차이
accDescr: 섀도 복사본은 원래 볼륨의 차이로, 공간 부족이나 공격으로 삭제되는 반면, 별도 미디어로 옮긴 백업은 원래 볼륨을 잃어도 남는다는 것을 보여 주는 그림.
V["원래 볼륨"] --> S["섀도 복사본(차이)"]
S --> L["공간 부족으로 오래된 순서로 삭제"]
S --> K["공격자가 vssadmin으로 삭제"]
S -->|"별도 미디어로 옮긴다"| B["백업"]
B --> R["원래 볼륨을 잃어도 남는다"]
그림 3: 섀도 복사본은 원래 볼륨의 데이터를 전제로 하며, 별도 미디어로 옮긴 것이 백업이 된다.
섀도 복사본은 실수로 덮어쓴 파일을 사용자가 직접 되돌리기에는 편리합니다. 다만 앞 절에서 본 것처럼 공격자에게 지워지는 경우가 있습니다. 원리와 운용의 자세한 내용은 「볼륨 섀도 복사본(VSS)의 원리와 실무」에서 설명합니다.
어떤 섀도 복사본이 남아 있는지는 관리자 명령 프롬프트에서 vssadmin list shadows를 실행하면 목록으로 볼 수 있습니다. 이 하위 명령은 클라이언트와 서버 양쪽에서 쓸 수 있습니다8.
vssadmin list shadows
OneDrive와 SharePoint의 버전 기록과 휴지통도 사용자가 파일을 되돌리는 수단이 됩니다. Microsoft는 OneDrive 전체를 이전 시점으로 되돌리는 방법을 사용자에게 알려 두라고 권합니다. 아울러 공격자를 몰아냈다고 확신할 수 있을 때 되돌리게 할 것, 사용자가 맬웨어까지 되돌려 버린 경우의 대책을 마련해 둘 것을 들고 있습니다5.
3-2-1 규칙은 복제본의 수와 둘 곳을 정한다
3-2-1 규칙은 백업 복제본을 갖추는 방법을 보여 주는 경험칙입니다. 미국 US-CERT를 위해 2012년에 만들어진 「Data Backup Options」는 다음과 같이 설명합니다9.
- 3: 중요한 파일은 원본 1개와 백업 2개를 합쳐 3개를 가진다.
- 2: 종류가 다른 재해에 대비해 2종류의 미디어에 둔다.
- 1: 1개는 집이나 사업장 밖에 둔다.
이 자료는 출처로 사진가 Peter Krogh의 디지털 사진 관리 책 「The DAM Book」을 들고 있습니다9. Microsoft도 랜섬웨어에 대비하는 백업 자료에서 이 규칙을 들고, ‘1’을 ‘사외 또는 콜드 복제본’으로 설명합니다5.
3-2-1 규칙이 요구하는 것은 사외에 두는 것입니다. 사외의 복제본이 오프라인인지, 덮어쓸 수 없는지까지는 요구하지 않습니다. 그래서 사외의 복제본이 감염된 PC에서 항상 쓸 수 있는 클라우드에 있으면, 가까이 있는 복제본과 함께 암호화될 수 있습니다. CISA 가이드와 Microsoft 자료는 랜섬웨어 대비로 오프라인 보관을 듭니다. Microsoft는 덮어쓸 수 없는 저장소도 듭니다45.
flowchart TB
accTitle: 3-2-1 규칙과 랜섬웨어 대비
accDescr: 복제본 3개, 미디어 2종류, 1개를 사외에 두는 3-2-1 규칙에 오프라인이거나 덮어쓸 수 없는 복제본을 하나 더하고, 복원할 수 있는지 확인하는 것을 보여 주는 그림.
A["복제본 3개"] --> B["미디어 2종류"]
B --> C["1개는 사외"]
C --> D["1개는 오프라인이거나 덮어쓸 수 없음"]
D --> E["복원할 수 있는지 확인한다"]
그림 4: 3-2-1 규칙에, 감염된 PC가 덮어쓸 수 없는 복제본과 복원할 수 있는지의 확인을 더한다.
백업 제품 업체 Veeam은 이를 ‘3-2-1-1-0 규칙’으로 알리고 있습니다. Veeam의 자료에서 추가된 ‘1’은 오프라인, 에어갭, 또는 덮어쓸 수 없는 복제본을 하나 두는 것, ‘0’은 정기적인 복원 검증에서 오류가 없는 것입니다10. 이는 업체 자료에 있는 이름이며 공적인 규격이 아닙니다. 다만 추가된 두 항목은 CISA와 IPA가 요구하는 것과도 겹칩니다.
감염된 PC가 덮어쓸 수 없는 복제본을 하나 둔다
덮어쓸 수 없는 복제본을 만드는 방법은 크게 두 가지입니다. 미디어를 PC에서 분리해 보관하는 방법과, 일정 기간은 덮어쓰기도 삭제도 할 수 없는 클라우드 저장소를 쓰는 방법입니다. 어느 쪽을 고르든 백업을 관리하는 권한을 평소 작업과 나누어 둡니다.
미디어를 PC에서 분리해 보관한다
IPA 가이드라인은 자체 진단의 대책 예로, 백업에 쓰는 장치나 미디어는 백업할 때만 PC에 연결할 것을 듭니다. 그 밖에 백업 방법을 정할 것, 안전한 곳에 보관할 것, 복원할 수 있는지 정기적으로 확인할 것도 듭니다11.
더 본격적으로 대처하는 단계에서는 ‘물리적 격리’를 듭니다. 백업을 원래 시스템에서 물리적으로 떨어진 곳에 두는 방법으로, 외장 스토리지나 백업 테이프를 되도록 먼 곳에 보관합니다. 보관 장소의 예로 은행 대여 금고나, 신뢰할 수 있는 거래처나 관계사를 듭니다12.
이처럼 운영 시스템에서 분리해 보관하는 백업을 오프라인 백업이라고 부릅니다. 분리한 미디어에는 감염된 PC가 쓸 수 없습니다. 대신 연결을 바꾸고 옮기는 일을 사람이 하므로, 백업을 잊거나 반출을 잊는 일이 생깁니다. 누가 언제 미디어를 연결하고, 분리하고, 보관 장소로 옮기는지를 정해 둡니다.
덮어쓸 수 없는 클라우드 저장소를 쓴다
클라우드 스토리지에는 정한 기간 동안 데이터의 덮어쓰기도 삭제도 할 수 없게 하는 기능이 있습니다. WORM(Write Once, Read Many)이라고 부르는 상태로 보관하는 것입니다.
Azure Blob Storage의 변경할 수 없는 스토리지에서는 시간 기반 보존 정책을 설정하면, 그 기간 동안 데이터를 만들고 읽을 수는 있어도 변경하거나 삭제할 수는 없습니다13. 정책은 처음에는 잠기지 않은 상태로 만들어지고, 시험해 본 뒤 잠급니다. 잠근 정책은 삭제할 수 없고, 보존 기간을 늘릴 수는 있어도 줄일 수는 없습니다13. Microsoft는 계정의 관리자 권한을 가진 사용자도 데이터를 변경하거나 삭제할 수 없다고 설명합니다13.
Amazon S3의 Object Lock에는 두 가지 모드가 있습니다. 규정 준수 모드에서는 AWS 계정의 루트 사용자를 포함해 보존 기간 동안 누구도 객체 버전을 덮어쓰거나 삭제할 수 없습니다. 거버넌스 모드에서는 특별한 권한을 가진 사용자만 보존 설정을 바꾸거나 삭제할 수 있습니다14. Object Lock은 S3 버전 관리를 켠 버킷에서만 쓸 수 있습니다14.
flowchart TB
accTitle: 덮어쓸 수 없는 저장소의 두 가지 예
accDescr: Azure Blob Storage의 변경할 수 없는 스토리지는 잠근 정책을 삭제할 수 없고 보존 기간을 줄일 수 없다는 것, S3 Object Lock은 규정 준수 모드에서는 루트 사용자도 삭제할 수 없고 거버넌스 모드에서는 특별한 권한으로 변경할 수 있다는 것을 보여 주는 그림.
W["덮어쓸 수 없는 저장소"] --> AZ["Azure Blob Storage의 변경할 수 없는 스토리지"]
W --> S3["S3 Object Lock"]
AZ --> AZ1["잠근 뒤에는 보존 기간을 줄일 수 없다"]
S3 --> C["규정 준수 모드"]
S3 --> G["거버넌스 모드"]
C --> C1["루트 사용자도 삭제할 수 없다"]
G --> G1["특별한 권한으로 변경할 수 있다"]
그림 5: 두 저장소 모두 정한 기간 동안 덮어쓰기와 삭제를 거부한다. 강도는 설정에 따라 다르다.
Azure에서는 정책을 잠근 뒤에 설정 실수를 알아채도 보존 기간을 줄일 수 없습니다13. CISA 가이드는 일부 클라우드 사업자가 덮어쓸 수 없는 저장소를 제공한다고 소개한 뒤, 설정을 잘못하면 큰 비용이 들 수 있다고 주의합니다. 특정 규제의 요건을 충족하지 못하는 경우가 있다는 점도 언급합니다4. 보존 기간을 길게 설정해 잠그면 그 기간 동안 데이터를 지울 수 없고 보관 요금이 계속 듭니다. 처음에는 잠그지 않은 상태나 짧은 기간으로 시험하고, 복원할 수 있음을 확인한 뒤 운영 설정으로 바꿉니다.
백업을 관리하는 권한을 나눈다
덮어쓸 수 없는 저장소를 쓰더라도, 백업 설정이나 정책을 평소 관리자 계정으로 바꿀 수 있으면 공격자가 바꿀 수 있습니다. Microsoft는 온라인 백업을 변경하거나 삭제하기 전에 다단계 인증이나 보안 PIN 같은 별도 절차를 요구하라고 권합니다. 백업과 복원 작업을 정해진 역할의 사용자로 한정하는 것, 파일 공유에서 많은 사용자가 쓰기·삭제할 수 있는 상태를 줄이는 것도 듭니다5.
PC 관리와 백업 관리를 같은 사람이 맡는 경우에도, 백업 대상의 관리에 쓰는 계정은 평소 PC 로그인에 쓰지 않고 다단계 인증을 걸어 둡니다.
세대를 남긴다
IPA 가이드라인은 여러 시점의 백업을 갖는 ‘세대 관리’를 듭니다. 데이터가 손상되거나 사라졌을 때 특정 시점까지 거슬러 올라가 복원할 수 있게 하는 방법입니다12. 앞 절에서 본 것처럼 암호화를 알아채기까지 시간이 걸리면, 가장 최근 백업은 암호화된 뒤의 데이터가 되어 있습니다. 몇 세대를 남길지는 암호화를 알아채기까지 걸릴 수 있는 시간과 보관 비용으로 정합니다.
flowchart TB
accTitle: 덮어쓸 수 없는 복제본을 갖기 위한 세 가지 방법
accDescr: 미디어를 분리해 보관하거나 덮어쓸 수 없는 저장소를 쓰고, 백업을 관리하는 권한을 평소 계정과 나누며, 여러 세대를 남기는 것을 보여 주는 그림.
A["덮어쓸 수 없는 복제본"] --> B["미디어를 분리해 보관"]
A --> C["덮어쓸 수 없는 저장소"]
B --> D["관리 권한을 나눈다"]
C --> D
D --> E["여러 세대를 남긴다"]
그림 6: 둘 곳을 정한 다음, 관리 권한을 나누고, 늦게 알아채도 돌아갈 수 있도록 세대를 남긴다.
복원할 수 있는지 확인한다
경찰청 보고에서 복원하지 못한 이유의 두 번째는 ‘운용 미비’였습니다1. 백업이 실제로 복원되는지는 복원해 보지 않으면 알 수 없습니다. 백업에서 실제로 복원해 보며 확인하는 작업을 복원 테스트라고 부릅니다.
IPA 가이드라인은 백업 운용을 취득·보관·복구의 세 가지로 나눕니다. 복구에서는 복구 계획을 세우고, 올바르게 복구할 수 있는지 확인하라고 요구합니다3. 사업상 중요한 시스템에 대해서는 목표 복구 시간(RTO)과 목표 복구 시점(RPO)에 맞춰 백업 취득과 절차를 정비하고, 훈련으로 실효성을 확인하라고 요구합니다. RTO는 목표 수준까지 복원하는 데 걸리는 시간, RPO는 복원하는 시점, 즉 가장 최근 백업의 시점입니다15. CISA 가이드도 재해 복구를 염두에 두고 백업이 쓸 수 있는지, 손상되지 않았는지를 정기적으로 확인하라고 요구합니다4.
flowchart TB
accTitle: 복원 테스트를 진행하는 방법
accDescr: 복원 순서를 정하고, 별도 환경에 복원하고, 걸린 시간과 복원된 시점을 RTO와 RPO에 비추어 보고, 절차서를 고치는 흐름을 보여 주는 그림.
A["복원 순서를 정한다"] --> B["별도 환경에 복원한다"]
B --> C["걸린 시간을 RTO와 비교한다"]
B --> D["복원된 시점을 RPO와 비교한다"]
C --> E["절차서를 고친다"]
D --> E
E -.->|"다음 확인"| A
그림 7: 복원해 보고, 시간과 시점이 목표에 맞는지 확인하며, 결과를 절차서에 반영한다.
무엇을 확인할까
확인할 내용은 IPA와 Microsoft의 자료에서 다음과 같이 정리할 수 있습니다.
| 확인할 것 | 볼 점 | 근거 |
|---|---|---|
| 파일 단위로 복원할 수 있는가 | 사용자가 쓰는 파일이 열리는가 | IPA11 |
| 시스템 전체를 복원할 수 있는가 | 운영 환경과 다른 PC나 서버에 복원해 업무 앱이 동작하는가 | IPA3, Microsoft5 |
| 걸린 시간 | 정한 RTO 안에 들어가는가 | IPA15 |
| 복원된 시점 | 정한 RPO보다 오래되지 않았는가 | IPA15 |
| 복원 순서 | 인증이나 기간 업무 등 먼저 복원할 것이 정해져 있는가 | Microsoft5 |
| 절차서를 두는 곳 | 사내 시스템이 모두 멈춰도 읽을 수 있는가 | Microsoft5 |
Microsoft는 먼저 업무에 꼭 필요한 시스템을 정하고, 그것을 정기적으로 백업하라고 권합니다. 그렇게 만든 백업의 우선순위 목록이 그대로 복원 순서의 목록이 됩니다. 우선순위가 높은 것으로 Active Directory처럼 다른 모든 시스템에 들어가는 데 필요한 인증 구조를 가장 먼저 듭니다5. 모든 시스템이 멈춘 상태에서 업무를 다시 일으키는 훈련을 정기적으로 하라고도 권합니다. 그때 메일이나 채팅도 쓸 수 없는 것으로 가정합니다5.
Microsoft는 복원 절차서와 네트워크 구성도를 공격자가 의도적으로 노린다고 씁니다. 보호하거나 인쇄해서 가까이 두라고 권합니다5. 절차서가 파일 서버 안에만 있으면, 그 파일 서버가 암호화되었을 때 읽을 수 없습니다.
피해 뒤에 복원할 때의 주의
실제 피해 뒤에는 랜섬웨어 본체를 환경에서 없앤 다음 복원합니다5. Microsoft는 감염되지 않았다고 확인된 시점의 백업을 고를 것, 복원하기 전에 백업에 맬웨어가 없는지 조사할 것을 듭니다5. 경찰청 보고는 침입 경로를 막아도 다시 들어올 수 있도록 랜섬웨어 그룹이 원격 조작할 수 있는 소프트웨어를 백도어로 설치하는 경우가 있다고 씁니다2. 복원하기 전에 침입 경로와 남겨진 장치를 조사해야 합니다.
flowchart TB
accTitle: 피해 뒤에 백업에서 복원하는 순서
accDescr: 랜섬웨어 본체와 침입 경로를 없애고, 감염되지 않은 시점의 백업을 고르고, 맬웨어가 없는지 조사한 뒤, 우선순위가 높은 시스템부터 복원하는 것을 보여 주는 그림.
A["랜섬웨어 본체를 없앤다"] --> B["침입 경로와 장치를 조사한다"]
B --> C["감염되지 않은 시점을 고른다"]
C --> D["백업을 조사한다"]
D --> E["우선순위가 높은 것부터 복원한다"]
그림 8: 피해 뒤에는 공격자가 남긴 장치를 없애고, 감염되지 않은 시점을 확인한 다음 복원한다.
얼마나 자주 확인할까
IPA 가이드라인도 CISA 가이드도 복원할 수 있는지의 확인을 ‘정기적으로’ 하라고 요구하지만, 횟수는 제시하지 않습니다114. 앞에서 소개한 IPA 사례의 회사는 연 2회 복원 훈련을 하고 있었습니다3. 업무가 멈춰도 되는 시간과 복원 시점이 어디까지 오래되어도 되는지를 정하고, 그것을 충족하고 있는지 확인할 수 있는 빈도로 합니다.
먼저 정할 것
지금까지의 내용을 중소기업이 먼저 정할 것으로 정리합니다.
| 항목 | 정할 것 |
|---|---|
| 대상 | 복원하지 못하면 업무가 멈추는 데이터와 시스템 |
| 복제본 | 3-2-1 규칙에 따른 복제본의 수·미디어·둘 곳 |
| 덮어쓸 수 없는 복제본 | 분리한 미디어와 덮어쓸 수 없는 저장소 중 어느 쪽을 쓸지 |
| 권한 | 백업을 관리하는 계정과 다단계 인증 |
| 세대 | 몇 세대를 얼마 동안 남길지 |
| 목표 | 업무별 RTO와 RPO |
| 확인 | 무엇을 누가 어느 빈도로 복원해 볼지 |
| 절차서 | 복원 순서와 절차를 적은 문서를 어디에 둘지 |
flowchart TB
accTitle: 랜섬웨어에 견디는 백업을 정하는 순서
accDescr: 대상을 정하고, 복제본을 둘 곳과 덮어쓸 수 없는 복제본을 정하고, 권한과 세대를 정하고, RTO와 RPO를 정해 복원할 수 있는지 확인하는 순서를 보여 주는 그림.
A["대상을 정한다"] --> B["복제본을 둘 곳을 정한다"]
B --> C["덮어쓸 수 없는 복제본을 정한다"]
C --> D["권한과 세대를 정한다"]
D --> E["RTO와 RPO를 정한다"]
E --> F["복원할 수 있는지 확인한다"]
그림 9: 대상부터 정하고, 마지막으로 복원할 수 있는지 확인하는 데까지를 한 흐름으로 정한다.
IPA 가이드라인 제4.0판에서는 처음 실천하는 「정보 보안 5개조」에 「백업을 해 두자!」가 더해져 6개조가 되었습니다16. 가이드라인 전체를 진행하는 방법은 「중소기업의 보안 대책, 무엇부터 시작할까」에 정리했습니다. 서버를 교체할 계획이 있다면 「Preparing for Windows Server 2016 End of Support」도 참고하세요.
관련 글
- 중소기업의 보안 대책, 무엇부터 시작할까 ── IPA 「중소기업의 정보보안 대책 가이드라인」 제4.0판 활용법
- 볼륨 섀도 복사본(VSS)의 원리와 실무 ── 사용 중인 파일은 어떻게 백업되는가
- Preparing for Windows Server 2016 End of Support
참고 자료
-
일본 경찰청 사이버경찰국, 2025년 상반기 사이버 공간을 둘러싼 위협 정세 등에 대하여(2025년 9월, 일본어). 자료편 61쪽 「랜섬웨어 피해에 관한 통계④」. 백업 취득 상황(유효 응답 53건 중 취득 51건), 복원 결과(유효 응답 48건 중 복원 가능 7건·복원 불가 41건), 복원하지 못한 이유(유효 응답 35건 중 백업도 암호화 23건·운용 미비 8건·기타 4건). ↩ ↩2 ↩3
-
일본 경찰청 사이버경찰국, 2025년 상반기 사이버 공간을 둘러싼 위협 정세 등에 대하여(일본어). 9쪽. 랜섬웨어 그룹이 피해 기업의 로그와 백업을 삭제하는 것, 재침입을 위해 백도어를 설치하는 것, 백업을 오프라인 환경에 보관하도록 요구되는 것. ↩ ↩2
-
IPA, 중소기업의 정보보안 대책 가이드라인 제4.0판(일본어). 11쪽의 사례 3(연 2회 복원 훈련, 발각 5일 뒤 기간 시스템 재가동, 파일의 20% 남짓 손실)과 21쪽의 칼럼 「적절한 백업 운용을 한다」(취득·보관·복구). ↩ ↩2 ↩3 ↩4
-
CISA 외, #StopRansomware Guide. 오프라인으로 암호화한 백업의 유지와 가용성·무결성의 정기 확인. 많은 랜섬웨어가 손이 닿는 백업을 삭제·암호화하려 하는 것. vssadmin.exe, wbadmin.exe 등의 수상한 사용 감시. 덮어쓸 수 없는 저장소의 설정 오류로 인한 비용과 규제에 대한 주의. ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Microsoft Learn, Azure backup and restore plan to protect against ransomware. 공격자가 백업과 볼륨 섀도 복사본을 노리는 것, 조금씩 암호화하는 수법, 3-2-1 규칙, 오프라인·덮어쓸 수 없는 저장소, 다단계 인증과 보안 PIN, 복원 순서, 절차서 보호, 복원 전 확인. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14
-
MITRE ATT&CK, Inhibit System Recovery (T1490). vssadmin.exe를 이용한 섀도 복사본 삭제와 wbadmin.exe를 이용한 백업 카탈로그 삭제의 예. ↩
-
Microsoft Learn, Volume Shadow Copy Service (VSS). 쓰기 시 복사 방식, 섀도 복사본과 백업의 차이, 차이 영역이 부족해졌을 때의 삭제. ↩ ↩2 ↩3
-
Microsoft Learn, vssadmin.
vssadmin list shadows등의 하위 명령과 클라이언트·서버에서의 사용 가능 여부. ↩ -
Paul Ruggiero, Matthew A. Heckathorn, Data Backup Options(2012년, Carnegie Mellon University가 US-CERT를 위해 작성). 3-2-1 규칙의 내용과 출처인 Peter Krogh의 「The DAM Book」. ↩ ↩2
-
Veeam, [3-2-1 Rule Veeam Backup for Microsoft 365 Best Practices](https://bp.veeam.com/vb365/guide/design/3-2-1). 업체 자료. 3-2-1-1-0 규칙의 추가된 ‘1’(오프라인, 에어갭, 또는 덮어쓸 수 없는 복제본)과 ‘0’(복원 검증에서 오류가 없는 것). -
IPA, 중소기업의 정보보안 대책 가이드라인 제4.0판(일본어). 24쪽. 백업 대책 예(정기적으로 한다, 장치·미디어는 백업할 때만 연결한다, 안전한 곳에 보관한다, 복원할 수 있는지 정기적으로 확인한다). ↩ ↩2 ↩3
-
IPA, 중소기업의 정보보안 대책 가이드라인 제4.0판(일본어). 33쪽 「적절한 백업을 한다」. 세대 관리와 물리적 격리. ↩ ↩2
-
Microsoft Learn, Immutable storage for blob data overview. WORM 상태, 시간 기반 보존 정책, 잠근 정책은 삭제할 수 없고 보존 기간을 줄일 수 없는 것, 관리자 권한을 가진 사용자도 변경·삭제할 수 없는 것. ↩ ↩2 ↩3 ↩4
-
AWS, Locking objects with Object Lock. 규정 준수 모드와 거버넌스 모드, 버전 관리가 필요한 것. ↩ ↩2
-
IPA, 중소기업의 정보보안 대책 가이드라인 제4.0판(일본어). 38쪽. 목표 복구 시간(RTO)과 목표 복구 시점(RPO)에 맞춘 백업 취득·절차 정비와 훈련을 통한 실효성 검증. ↩ ↩2 ↩3
-
IPA, 「중소기업의 정보보안 대책 가이드라인」 제4.0판 공개(일본어). 「백업을 해 두자!」를 더해 정보 보안 6개조로 한 것. ↩
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 깊이 있게 쌓을 수 있습니다.
볼륨 섀도 복사본(VSS)의 원리와 실무 ── 사용 중인 파일은 어떻게 백업되는가
사용 중인 파일은 공유 위반으로 복사하지 못하는데, 백업 소프트웨어는 어떻게 복사할까요. 볼륨 섀도 복사본(VSS)의 requester·writer·provider 역할, copy-on-write 동작, vssadmin 실무와 diff area의...
BitLocker 실무 가이드 ── 복구 키 관리부터 시작하는 드라이브 암호화
Windows 11 24H2 이후 클린 설치에서는 디바이스 암호화가 기본으로 켜져, '어느새 암호화되어 있었다'는 사고가 실제로 일어납니다. 복구 키 저장 위치 판단표를 축으로, 원리·조직 운영·사고 대응·폐기까지 정리합니다.
중소기업의 보안 대책, 무엇부터 시작할까 ── IPA 「중소기업의 정보보안 대책 가이드라인」 제4.0판 활용법
중소기업 보안 대책은 무엇부터 시작해야 할까요. IPA 「중소기업의 정보보안 대책 가이드라인」 제4.0판을 바탕으로 정보보안 6개 조항, 5분이면 끝나는 자사 진단, SECURITY ACTION까지 단계적으로 설명합니다.
Windows 가상화의 심층(제2회) ── 커널에서도 보이지 않는 메모리: VBS·HVCI·Credential Guard의 구조
대응 하드웨어에 클린 설치하면 기본으로 켜지는 VBS는, 하이퍼바이저와 SLAT로 커널보다 강한 격리를 만듭니다. VTL, 보안 커널, HVCI, Credential Guard의 구조를 설명합니다.
Named Pipe 실무 ── Windows 프로세스 간 통신의 정석을 설계부터 보안까지
Windows 프로세스 간 통신의 정석인 Named Pipe를 실무 관점에서 설명합니다. 바이트/메시지 모드의 선택, 여러 클라이언트를 처리하는 서버 설계, ACL과 impersonation 보안, .NET의 NamedPipeStream까지 일차...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용의 기술 토픽을 모은 입구입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
기술 상담 & 설계 리뷰
사내 PC와 파일 서버의 백업이 감염된 PC에서 닿는 곳에 있지 않은지, 복원 절차가 실제로 쓸 수 있는지를 구성에 맞춰 함께 확인할 수 있습니다.
기존 Windows 소프트웨어의 수정·개선 및 유지 보수
오래된 Windows 서버나 업무 앱이 포함된 환경에서 복원 순서와 절차서를 정비하고 복원 테스트를 하고 싶을 때 상담해 주세요.
자주 묻는 질문
이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.
- 백업을 해 두면 랜섬웨어에 감염되어도 원래대로 되돌릴 수 있나요?
- 백업을 해 두기만 해서는 되돌리지 못하는 경우가 많습니다. 일본 경찰청이 정리한 2025년 상반기 피해에서는 백업을 해 두었던 기업·단체 중 응답한 48건 가운데 41건이 피해 직전 수준까지 복원하지 못했습니다. 가장 많은 이유는 백업도 암호화되어 있었다는 것이었습니다. 감염된 PC가 덮어쓸 수 없는 복제본을 두고, 복원할 수 있는지 확인해 두어야 합니다.
- Windows의 '이전 버전'이 있으면 백업은 필요 없나요?
- 필요합니다. 이전 버전은 볼륨 섀도 복사본으로, 원래 볼륨에 있는 차이입니다. Microsoft는 섀도 복사본에서 테이프 같은 미디어로 옮긴 것을 백업으로 봅니다. 랜섬웨어는 vssadmin 등으로 섀도 복사본을 지우는 경우가 있으므로 별도 미디어에 둔 백업과 함께 사용합니다.
- 3-2-1 규칙을 지키면 랜섬웨어 대책으로 충분한가요?
- 그것만으로는 부족할 수 있습니다. 3-2-1 규칙은 복제본 3개, 미디어 2종류, 1개를 사외에 두는 것을 요구하지만, 사외의 복제본이 오프라인이거나 덮어쓸 수 없는 것까지는 요구하지 않습니다. 감염된 PC에서 항상 쓸 수 있는 클라우드의 복제본은 똑같이 암호화될 수 있습니다. 오프라인 미디어나 덮어쓸 수 없는 저장소에 복제본을 하나 더합니다.
- 백업에서 복원할 수 있는지는 얼마나 자주 확인하면 되나요?
- IPA 가이드라인도 CISA 가이드도 '정기적으로'라고만 하고 횟수는 제시하지 않습니다. IPA 가이드라인에는 연 2회 복원 훈련을 하던 기업이 발각 5일 뒤에 기간 시스템을 다시 가동한 사례가 실려 있습니다. 업무가 멈춰도 되는 시간과 복원 시점이 어디까지 오래되어도 되는지를 정하고, 그것을 충족하는지 확인할 수 있는 빈도로 합니다.