본문으로 건너뛰기
보안 8분 읽기

불변 백업은 복구 훈련으로만 믿을 수 있다

백업 불변성을 켰더라도 실제 복구 시간, 권한 분리, 삭제 방지 설정을 주기적으로 검증해야 하는 이유를 다룬다. Immutable Backup·Recovery·Ransomware 관점에서 공격 경로를 쉬운 예로 풀고 예방, 탐지, 대응 순서로 확인할 항목을 제시한다.

강지원
에디터
2026년 6월 25일
불변 백업은 복구 훈련으로만 믿을 수 있다

핵심 요약

불변 백업은 삭제와 덮어쓰기를 어렵게 만들지만, 복구 가능성을 보장하지 않는다. 운영 계정과 분리된 권한, 보존 정책, 암호화 키, 애플리케이션 의존성, 실제 RPO·RTO를 함께 시험해야 한다. 파일 복원부터 전체 서비스 복구까지 단계별 훈련과 증거를 남겨야 백업을 신뢰할 수 있다.

백업 콘솔에 “성공”이 표시되고 객체 잠금이 켜져 있어도 실제 사고에서 복구하지 못할 수 있다. 백업 파일이 손상됐거나, 복호화 키가 같은 계정과 함께 잠겼거나, 인증 시스템과 DNS가 없어 복원한 애플리케이션에 로그인하지 못하는 경우가 있기 때문이다.

불변성은 공격자가 백업을 삭제하거나 바꾸는 것을 어렵게 하는 통제다. 복구 가능성은 필요한 시점의 데이터가 있고, 의존 서비스와 자격 증명을 확보했으며, 목표 시간 안에 검증된 상태로 복원할 수 있는지에 관한 별도 능력이다.

보호 대상과 복구 목표를 먼저 정한다

모든 데이터를 같은 주기와 기간으로 백업하면 비용만 늘고 우선순위가 흐려진다. 서비스별로 다음을 기록한다.

항목질문
업무 영향서비스가 멈추면 어떤 고객·매출·법적 의무가 영향을 받는가
RPO허용 가능한 최대 데이터 손실 시점은 얼마인가
RTO언제까지 최소 기능을 복구해야 하는가
복구 순서신원, 네트워크, 데이터베이스, 앱 중 무엇이 먼저인가
의존성KMS, DNS, 인증서, SaaS, IaC, 라이선스가 필요한가
검증 기준파일 존재가 아니라 어떤 업무 기능이 성공해야 하는가

RPO와 RTO는 희망 시간이 아니라 실제 훈련에서 측정한 결과로 갱신한다. 경영진이 요구한 목표와 현재 기술 능력 사이의 차이는 위험으로 기록한다.

불변성을 여러 층으로 구성한다

하나의 “immutable” 옵션만 믿지 않는다.

  • 소스 데이터의 버전 관리와 삭제 지연
  • 백업 저장소의 WORM·객체 잠금 또는 변경 불가 스냅샷
  • 운영 계정과 다른 계정·프로젝트·구독
  • 별도 관리자와 MFA, 긴급 접근 절차
  • 다른 리전 또는 오프라인·논리적 에어갭 사본
  • 보존 기간 변경과 법적 보존의 별도 승인
  • 백업 카탈로그와 복구 문서의 독립 사본

예를 들어 S3 Object Lock은 버전 단위 WORM 보호를 제공하며 보존 기간과 legal hold를 지원한다. 그러나 새 버전이나 삭제 마커의 동작, governance와 compliance 모드 차이, 권한을 제품 문서에서 확인해야 한다. 제품 이름이 달라도 “누가 보존을 줄일 수 있는가”와 “관리자 탈취 시 어떤 사본이 남는가”를 시험한다.

백업 관리자와 운영 관리자를 분리한다

운영 서버 관리자, 클라우드 조직 관리자, 백업 관리자가 같은 계정과 MFA 수단을 쓰면 한 번의 계정 탈취로 운영과 복구 수단이 함께 사라질 수 있다.

  • 백업 정책 변경과 복원 실행 역할을 분리한다.
  • 보존 기간 단축·잠금 해제·저장소 삭제에 다중 승인을 요구한다.
  • 백업 계정은 일상 운영 도구에 로그인하지 않는다.
  • 복구용 자격 증명은 조직 IdP 장애 시에도 사용할 수 있게 보관한다.
  • 비상 계정 사용 시 즉시 경보와 사후 감사를 수행한다.
  • 백업 에이전트 토큰은 소스 쓰기 권한을 갖지 않는다.

관리자 비상 계정제로 트러스트 신원 경계를 백업 제어면에도 적용한다.

암호화 키를 복구 계획에 포함한다

암호화된 백업은 키 없이는 무용지물이다. 반대로 키를 백업과 같은 계정에 두면 침해 영향이 함께 번진다.

  • 어떤 백업 세대가 어떤 키와 버전을 사용하는지 기록한다.
  • 키 비활성화·삭제 전 백업 복원 의존성을 확인한다.
  • 재해복구 계정이 필요한 복호화 권한을 얻는 절차를 시험한다.
  • 키 관리 로그와 백업 관리자 로그를 교차 검토한다.
  • 긴급 키 교체 후 오래된 백업의 복원 가능성을 확인한다.

키 수명주기는 클라우드 KMS 키 계층 설계와 연결한다.

네 단계로 복구를 훈련한다

1단계: 단일 파일·객체

삭제된 파일 하나를 지정 시점에서 복구하고 해시, 권한, 메타데이터를 검증한다. 가장 간단하지만 경로와 카탈로그 오류를 빨리 찾을 수 있다.

2단계: 데이터베이스 시점 복구

격리된 환경에서 특정 시점으로 복원한다. 트랜잭션 로그, 스키마, 애플리케이션 버전, 사용자 권한을 함께 확인한다. 행 수만 보지 말고 대표 업무 쿼리와 무결성 검사를 실행한다.

3단계: 서비스 복구

IaC로 네트워크와 컴퓨트를 만들고, 비밀값·인증서·DNS를 연결해 최소 사용자 흐름을 실행한다. 복원된 데이터가 있어도 애플리케이션 버전이 맞지 않으면 실패할 수 있다.

4단계: 계정 침해·리전 상실 훈련

운영 계정과 IdP를 사용할 수 없다고 가정한다. 별도 계정에서 연락망, 비상 자격 증명, KMS, DNS, 외부 SaaS 의존성을 복구한다. 의사결정은 재해복구 테이블탑과 결합한다.

고의로 실패 조건을 넣는다

정상 경로만 시험하면 실제 사고의 마찰을 발견하지 못한다.

  • 최신 백업 세대가 손상됐다고 가정한다.
  • 운영 관리자 계정을 사용할 수 없게 한다.
  • 복호화 키 권한이 빠진 상태로 시작한다.
  • 복구 대상 리전의 용량이 부족하다고 가정한다.
  • DNS와 인증서 담당자가 부재한 상황을 만든다.
  • 복구 문서의 한 단계가 오래됐거나 잘못된 상태를 넣는다.
  • 네트워크 대역폭을 제한해 대용량 복원 시간을 측정한다.

훈련 중 안전을 위해 실제 운영 데이터와 고객 트래픽을 격리하고, 테스트 데이터의 개인정보 처리 기준을 정한다.

성공 증거

복구 완료를 “서버가 켜졌다”로 판단하지 않는다.

  • 선택한 복구 지점과 실제 데이터 시각
  • 시작·첫 서비스·전체 검증까지 걸린 시간
  • 복원한 객체 수, 오류와 재시도
  • 해시·무결성·애플리케이션 테스트 결과
  • 사용한 계정, 키, 승인, 변경 로그
  • 실패한 단계와 수동 우회
  • 예상 RPO·RTO와 실제 차이
  • 다음 개선 항목, 소유자, 기한

증거는 백업 시스템 안에만 두지 않는다. 시스템 자체가 손상됐을 때도 볼 수 있는 별도 위치에 보관한다.

탐지해야 할 위험 신호

  • 백업 성공률은 높지만 복원 시험이 장기간 없다.
  • 보존 기간 또는 잠금 모드가 짧아진다.
  • 백업 관리자·KMS 관리자 권한이 같은 사용자에게 추가된다.
  • 백업 에이전트가 대량 삭제·변경을 시도한다.
  • 저장소의 새 백업 크기가 평소보다 급격히 작아진다.
  • 카탈로그에는 있지만 실제 객체가 없거나 해시가 다르다.
  • 복구 키·비상 계정 사용 기록이 승인 없이 발생한다.
  • 백업 비용이 갑자기 줄면서 보존 세대도 감소한다.

실패 모드

실패결과교정
불변성 옵션만 확인손상·키 누락을 발견 못함단계별 실제 복원
운영과 백업이 같은 관리자동시 삭제·잠금 가능계정·역할·MFA 분리
파일 복원만 시험앱·DNS·IdP 의존성 누락서비스와 계정 상실 훈련
RTO를 추정치로 관리사고 시 일정 약속 실패실제 시간 측정과 갱신
최신 사본만 복원잠복 손상에 취약여러 세대 샘플링
복구 문서가 백업 시스템 안에만 있음시스템 장애 시 절차 접근 불가독립된 런북 사본

운영 체크리스트

  • 서비스별 RPO·RTO와 복구 순서가 승인돼 있다.
  • 불변·교차 계정·다른 리전 또는 오프라인 사본이 있다.
  • 운영 관리자와 백업 관리자가 분리돼 있다.
  • 보존 단축·잠금 해제·삭제에 다중 승인이 필요하다.
  • 백업 세대와 KMS 키 버전의 의존성을 알고 있다.
  • 파일·DB·서비스·계정 상실 복구를 단계별로 시험한다.
  • 손상·키 누락·대역폭 제한 같은 실패를 주입한다.
  • 실제 RPO·RTO와 업무 테스트 결과를 기록한다.
  • 복구 문서와 증거가 독립 위치에 있다.
  • 실패 개선 항목에 소유자와 완료 기한이 있다.

참고 기준

결론

불변 백업은 공격자가 지우기 어려운 사본일 뿐, 복구된 서비스가 아니다. 권한과 키를 분리하고, 여러 실패 조건 아래에서 데이터와 애플리케이션을 실제로 되살려 목표 시간을 측정할 때 비로소 백업을 신뢰할 수 있다.

전체 댓글 0

댓글을 불러오는 중입니다...
새로고침

태그

Immutable Backup Recovery Ransomware

공유하기

관련 기사