랜섬웨어 시대의 백업: 복구보다 먼저 불변성을 확인하라

랜섬웨어 대응에서 “백업이 있다”는 말은 출발점일 뿐이다. 공격자는 운영 데이터만 암호화하지 않는다. 백업 콘솔의 관리자 계정, 스냅샷, 복제본, 가상화 관리 서버, 도메인 계정, 저장소 수명주기 정책을 함께 공격한다. 백업 파일이 남아 있어도 암호화 키, DNS, 인증서, identity, 애플리케이션 설정이 없으면 서비스는 복구되지 않는다.

따라서 백업의 품질은 용량이나 성공률보다 다음 질문으로 평가해야 한다.

• 공격자가 운영 관리자 권한을 얻어도 백업을 지울 수 없는가
• 감염 전 시점의 깨끗한 사본을 식별할 수 있는가
• 격리된 환경에서 실제 업무를 다시 시작할 수 있는가
• 목표 복구 시점과 시간 안에 복구를 반복해 증명했는가

불변성은 “읽기 전용 표시”가 아니다

불변 백업은 정해진 보존 기간 동안 수정·삭제·보존 축소가 제한돼야 한다. 공격자가 같은 관리자 계정으로 설정을 바꾸거나 저장소를 폐기할 수 있다면 논리적 불변성은 쉽게 무너진다.

불변성을 검토할 때는 다음 층을 분리한다.

층	확인 질문
백업 객체	보존 기간 중 덮어쓰기·삭제가 기술적으로 차단되는가
정책	관리자가 보존 기간을 단축하거나 잠금을 해제할 수 있는가
계정	운영 관리자와 백업 관리자 identity가 분리돼 있는가
플랫폼	계정·구독·저장소 자체 삭제를 별도 승인으로 막는가
키	암호화 키 삭제·비활성화가 백업 삭제와 같은 효과를 내지 않는가
사본	한 공급자·한 리전·한 자격증명에 모든 사본이 묶이지 않는가
복구	실제 복원과 애플리케이션 검증을 정기적으로 했는가

제품의 “immutable”, “object lock”, “vault lock”이라는 이름만 보고 판단하지 않는다. governance와 compliance 모드, privileged delete, 계정 폐기, 키 삭제, 법적 보존 기능은 제품마다 다르므로 도입 시점의 공식 문서와 계약 조건을 확인해야 한다.

3-2-1-1-0을 운영 질문으로 바꾼다

백업 전략을 기억하기 위한 3-2-1-1-0 원칙은 다음처럼 해석할 수 있다.

• 운영 데이터와 별도로 여러 사본이 있는가
• 서로 다른 장애·공급망에 묶이지 않은 매체나 저장 계층인가
• 적어도 한 사본이 다른 위치 또는 독립 영역에 있는가
• 적어도 한 사본이 오프라인 또는 실질적으로 불변인가
• 복구 검증 오류를 0으로 만들기 위한 테스트가 있는가

숫자를 맞추는 것보다 실패 도메인을 분리하는 것이 중요하다. 같은 클라우드 계정의 여러 버킷, 같은 도메인 관리자가 통제하는 NAS 두 대, 같은 KMS 키로 암호화된 리전 복제본은 동시에 손상될 수 있다.

백업 control plane을 운영 환경에서 분리한다

별도 identity와 관리 경로

백업 시스템은 별도 계정·구독·테넌트 또는 최소한 별도 관리자 역할로 운영한다. 일상 운영 계정이 백업 삭제, 보존 정책 변경, 키 폐기를 할 수 없게 한다. 관리자 로그인에는 피싱 저항성 MFA, 전용 관리 기기, 조건부 접근, 짧은 세션을 적용한다.

break-glass 계정은 일상 사용을 막고, 자격증명을 오프라인 보호하며, 사용 시 즉시 다중 경보가 발생해야 한다. 백업 서비스 계정에 대화형 로그인이나 광범위한 도메인 권한을 주지 않는다.

쓰기 경로와 삭제 경로 분리

운영 시스템은 백업을 보낼 수만 있고 기존 백업을 삭제하거나 보존 정책을 바꾸지 못하게 한다. 백업 저장소가 운영 네트워크의 공유 파일 시스템으로 항상 마운트돼 있으면 랜섬웨어가 그대로 암호화할 수 있다.

키 수명주기 분리

암호화 키가 없으면 불변 객체도 복구할 수 없다. 키 관리자, 복구 담당자, 백업 관리자 권한을 분리하고 키 삭제에는 지연·다중 승인·경보를 둔다. 키 자료와 복구 절차가 같은 침해 범위에 있지 않은지 확인한다.

무엇을 백업해야 서비스가 돌아오는가

데이터베이스와 파일만 복구해서는 충분하지 않다. 최소한 다음 종속성을 포함한다.

• identity provider, 디렉터리, MFA 복구 절차
• DNS 존, 도메인 등록, 로드밸런서, 방화벽, 라우팅
• TLS 인증서, 개인키, CA·ACME 계정과 배포 설정
• KMS·HSM 키와 비밀 관리자 메타데이터
• IaC, 구성 저장소, CI/CD 설정, 이미지와 패키지
• 데이터베이스 스키마, 메시지 큐, 객체 메타데이터
• 라이선스, 공급자 계정, 외부 API 연결 정보
• 연락망, 사고 대응 문서, 고객 공지 템플릿

인증서와 키의 복구 가능성은 인증서 수명주기 자동화에서 별도로 점검할 수 있다. IaC와 소스 저장소도 공격자가 변조했을 수 있으므로 서명된 기준 버전과 독립 사본을 준비한다.

복구는 순서가 있는 제품이다

랜섬웨어 복구 중 모든 시스템을 동시에 살리려 하면 네트워크와 인력이 병목이 된다. “최소 생존 업무”를 정의하고 종속성 순서를 만든다.

사고 지휘·통신
  → 신뢰 가능한 identity·관리 기기
  → DNS·네트워크·키·비밀
  → 핵심 데이터베이스·스토리지
  → 핵심 애플리케이션
  → 외부 연동·배치·분석
  → 일반 업무 시스템

각 업무에 RPO와 RTO를 적는다.

• RPO: 어느 시점까지의 데이터 손실을 허용하는가
• RTO: 업무를 언제까지 다시 시작해야 하는가

백업 주기가 RPO를 만족해도 복원 속도가 RTO를 만족하지 않을 수 있다. 대규모 데이터를 원격 저장소에서 내려받는 시간, 데이터베이스 재색인, 무결성 검사, DNS 전환, 고객 검증 시간을 포함해 측정한다.

깨끗한 복구 지점을 찾는다

가장 최신 백업이 항상 최선은 아니다. 공격자가 침투한 뒤 며칠 또는 몇 주 동안 잠복했다면 최신 사본에 웹셸, 악성 계정, 변경된 정책이 포함될 수 있다.

복구 전에 다음을 수행한다.

• 침해 타임라인과 최초 접근 추정 시점 정리
• 백업 시점별 악성 파일·계정·설정 변경 검사
• 운영 네트워크와 분리된 clean room에서 복원
• EDR·로그 수집·네트워크 제한을 먼저 적용
• 관리자 비밀번호, 토큰, 키, 인증서 회전
• 애플리케이션 smoke test와 데이터 무결성 검증
• 깨끗함을 확인하기 전 인터넷과 운영망 연결 금지

백업의 악성코드 검사 결과만으로 안전을 선언하지 않는다. identity와 설정, 예약 작업, 클라우드 정책 같은 비파일 상태를 함께 검토한다.

복구 리허설의 최소 단위

전체 재해 복구 훈련이 부담스럽다면 분기마다 작은 범위를 반복한다.

1. 무작위 백업 세트와 시점을 선택한다.
2. 기존 운영 자격증명 없이 격리된 계정에서 복원한다.
3. 문서만 보고 담당자가 환경을 구성한다.
4. 데이터 행 수가 아니라 실제 업무 시나리오를 검증한다.
5. RPO·RTO, 오류, 수동 단계, 누락 종속성을 기록한다.
6. 실패 항목을 다음 훈련 전에 자동화하거나 문서화한다.

복구 성공률은 “restore job succeeded”가 아니라 로그인, 조회, 쓰기, 외부 연동 등 합의된 업무 테스트를 통과했는지로 측정한다.

흔한 실패 모드

실패	사고 때 벌어지는 일	개선
운영 domain admin이 백업도 관리	탈취 계정 하나로 원본과 백업 삭제	별도 identity·계정·관리망
스냅샷만 백업으로 간주	같은 플랫폼·계정 장애에 함께 손실	독립 사본과 불변 저장소
백업 성공률만 보고 복원 미검증	손상·누락·키 부재를 사고 때 발견	업무 기반 정기 복구 시험
보존 잠금을 관리자가 해제 가능	공격자가 잠금 해제 후 삭제	강화 모드·다중 승인·지연
KMS 키가 같은 계정에만 존재	키 삭제로 모든 사본 무용화	키 권한·복구 자료 분리
최신 백업만 유지	잠복 기간 이전의 깨끗한 지점 없음	계층형 보존과 시점 다양화
모든 시스템 RTO가 같음	자원 경쟁으로 핵심 업무도 지연	업무 우선순위와 종속성 지도
복구 환경이 운영망과 연결	복원 즉시 재감염	clean room과 단계적 연결

탐지 신호

• 백업 삭제, 대량 만료, 보존 기간 단축 시도
• immutability·vault lock·object lock 정책 변경
• 백업 관리자 역할 부여와 MFA·조건부 접근 완화
• KMS 키 비활성화·삭제 예약·정책 변경
• 백업 작업 실패, 데이터량 급감, 압축률·변경률 이상
• 평소와 다른 시간·지역·기기에서 백업 콘솔 로그인
• 복제·오프사이트 전송 중단과 큐 적체
• restore 또는 export 작업의 비정상 증가
• 백업 에이전트 삭제·서비스 중지·로그 비활성화
• 동일 계정에서 운영 파괴 행위와 백업 변경이 연속 발생

이 경보는 운영 SOC와 별도 복구 담당자에게 동시에 전달한다. 공격자가 운영 알림 채널을 장악할 수 있으므로 독립 통신 수단을 준비한다.

운영 체크리스트

• 모든 핵심 업무에 데이터·identity·네트워크 종속성 지도가 있다.
• 백업 사본이 서로 다른 실패 도메인과 자격증명에 분산돼 있다.
• 최소 한 사본은 실질적 불변 또는 오프라인 상태다.
• 운영 관리자는 백업 삭제·보존 축소·키 폐기를 할 수 없다.
• 백업 관리에 MFA, 전용 역할, 짧은 세션, 감사가 적용된다.
• 암호화 키와 복구 자격증명이 독립적으로 보호된다.
• RPO·RTO가 업무 중요도와 실제 복원 시간으로 검증됐다.
• clean room 복구와 자격증명 회전 순서가 문서화돼 있다.
• 최신본 외에 잠복 기간을 견딜 여러 시점이 보존된다.
• 분기별 표본 복구와 연간 통합 훈련을 수행한다.
• 복구 성공은 업무 smoke test로 판정한다.
• 삭제·정책 변경·키 변경 경보가 독립 채널로 전달된다.

초기 침투를 줄이기 위해 CISA KEV 기반 패치 우선순위를 운영하고, 생산 설비 환경은 OT·ICS 원격접속 보안의 외주 계정과 점프 호스트 통제를 함께 적용해야 한다.

최종 판단

백업의 목적은 파일을 보관하는 것이 아니라 신뢰 가능한 업무를 다시 시작하는 것이다. 운영 관리자 권한이 탈취돼도 지울 수 없는 사본, 별도 identity와 키, 여러 복구 시점, clean room, 실제 RPO·RTO 훈련이 있어야 랜섬웨어에 견딜 수 있다.

불변성을 먼저 증명하고 복구를 반복 측정하면 “백업은 성공했다”는 로그를 “서비스를 되살릴 수 있다”는 운영 능력으로 바꿀 수 있다.

참고 기준

• CISA StopRansomware Guide
• NIST Cybersecurity Framework 2.0
• CIS Critical Security Controls v8.1