연속성과 복구: 아무도 테스트하지 않은 복원

모든 백업 대시보드에는 녹색 체크마크가 표시된다. 작업 완료, 보존 정책 충족, 스토리지 사용 예상대로. 이것들 중 아무것도 실제 사건 중에 4시간 이내에 도메인 컨트롤러를 베어메탈에서 복구할 수 있는지 여부를 알려주지 않는다. "백업 성공"과 "복원 성공" 사이의 차이가 대부분의 연속성 계획이 조용히 실패하는 곳이다.

체크마크가 거짓말하는 이유

백업 소프트웨어는 바이트를 대상으로 쓰기를 마쳤을 때 성공을 보고한다. 그 바이트가 사용 가능한지는 알 수 없다. SQL Server 백업은 깔끔하게 완료될 수 있지만 3일 전에 트랜잭션 로그 체인이 끊어졌고 아무도 알아차리지 못했기 때문에 복원할 수 없을 수 있다. VM 스냅샷은 콘솔에서 양호해 보일 수 있지만 기본 VSS 라이터가 게스트 OS 내에서 조용히 실패하여 crash-consistent(application-consistent이 아닌) 이미지를 생성했을 수 있다.

랜섬웨어 운영자들은 이를 알고 있다. 과거 사건에서 Conti 스타일 플레이북을 실행 중인 그룹은 의도적으로 백업 인프라를 겨냥했다 — vssadmin delete shadows /all /quiet로 섀도 복사본 삭제, Veeam 저장소 비활성화, SMB를 통해 접근 가능한 NAS 기반 백업 대상 암호화. 백업이 프로덕션과 같은 네트워크 세그먼트에 있고 도메인 자격 증명이 그것들을 건드릴 수 있다면, 그것들은 안전망이 아니라 목표다.

백업 정책이 아닌 복원 런북을 작성하라

연속성 계획은 정상적으로 하는 사람이 아닌 누군가를 위해 작성된 단계별 복원 지시가 필요하다. 다음을 기록하라:

• 정확한 복구 순서(도메인 컨트롤러와 DNS 먼저, 그 다음 핵심 앱, 그 다음 나머지)
• 암호 자격 증명 모음도 다운된 경우 백업 콘솔에 대한 자격 증명이 있는 위치
• "Veeam을 사용하여 VM 복원"이 아니라 구체적인 복원 명령 또는 콘솔 경로
• 벤더 마케팅 숫자가 아닌 실제 측정된 테스트를 기반으로 한 시스템당 예상 소요 시간

Veeam Backup & Replication의 경우 실제 단계를 문서화하는 것을 의미한다: 콘솔 열기, Backups > Disk로 이동, 복원 지점을 마우스 오른쪽 버튼으로 클릭, 시나리오에 따라 Instant VM Recovery 또는 Full VM Restore 선택, 충분한 여유 용량이 있는 대상 호스트 선택. 기본 호스트도 손상된 경우, 미리 식별되고 라이선스가 부여된 격리된 두 번째 호스트가 필요하다.

기발에로 테스트를 하지 말고 일정에 따라 테스트하라

순환을 정하라. 매달, 한 개의 중요한 시스템을 격리된 VLAN으로 복원하고 부팅, 인증 및 데이터 제공이 올바르게 작동하는지 검증하라. 분기마다, 전체 범위 테스트를 실행하라: 도메인 컨트롤러, 파일 서버 및 기본 데이터베이스를 격리된 인프라로 복원한 다음, 백업 팀 외부의 누군가가 로그인을 시도하고 보고서를 가져오도록 하라.

데이터베이스의 경우, .bak 파일을 복원하는 것만이 아니라 검증하라:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

그 다음 실제로 테스트 인스턴스로 복원하고 그것에 대해 DBCC CHECKDB를 실행하라. VERIFYONLY를 통과한 백업은 여전히 쿼리할 때만 나타나는 논리적 손상을 포함할 수 있다.

Bacula 또는 restic과 같은 것을 사용하는 Linux 시스템의 경우, 실제 복원 경로를 테스트하라:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

그 다음 복원된 구성 파일을 프로덕션과 비교하여 아무것도 조용히 삭제되지 않았는지 확인하라.

불변 복사본과 3-2-1-1 규칙

클래식 3-2-1 규칙(3개 복사본, 2개 미디어 유형, 1개 오프사이트)은 랜섬웨어 시대를 위해 업데이트가 필요하다: 3-2-1-1, 추가 "1"은 불변 또는 에어갭된 복사본이다. S3 호환 스토리지(Wasabi, Backblaze B2 또는 Object Lock이 활성화된 AWS S3)의 Object Lock은 정의된 보존 기간 동안 관리자 자격 증명을 가진 계정이라도 삭제 또는 수정을 방지한다. 다음으로 구성하라:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

COMPLIANCE 모드는 루트 계정을 포함한 아무도 보존을 단축하거나 객체를 조기에 삭제할 수 없음을 의미한다. 그것은 공격자가 도메인 관리자를 가질 때 중요하다.

추측이 아닌 실제 숫자로 RTO와 RPO를 측정하라

Recovery Time Objective와 Recovery Point Objective는 경영진이 "얼마나 많은 데이터를 잃고 얼마나 오래 다운되는가"를 물을 때까지 서류 작업처럼 들린다. 마지막 세 번의 테스트 복원의 시간을 재라. RPO 목표가 1시간이지만 백업 작업이 6시간마다만 실행된다면, 기록된 격차가 있으며, 실제 암호화 이벤트 중 토요일 오전 2시가 아닌 테이블탑 연습에서 그 격차를 찾는 것이 낫다.

테스트를 실행하고, 실제 시계 시간을 기록하고, 재해 복구 문서에서 약속한 것과 비교하라. 이 두 숫자 사이의 차이가 연속성 계획의 실제 상태다.

보호 중인 시스템 강화 및 사건 대응 워크플로 구축에 대한 자세한 내용은 Korra Studio의 관련 Blue Team 및 Digital Forensics 섹션을 확인하라.