백업 보존이란?
백업 보존은 규제, 법률, 사이버보안 요구사항에 따라 중요한 데이터의 복사본을 일정 기간 동안 유지하는 관행입니다. 이는 복구 지점을 얼마나 오래 보관할지, 어디에 저장할지, 그리고 운영 환경을 위협하는 공격으로부터 어떻게 보호할지를 결정합니다.
위험은 현실적입니다. MGM Resorts의 2023년 랜섬웨어 사고에서 회사는 SEC 보고서에 약 1억 달러의 조정 EBITDA 영향이 있었다고 공개했습니다. 공격자가 백업에 접근하거나 이를 손상시키면, 비즈니스 영향은 IT 다운타임을 넘어 기업 전체의 재무적 사건으로 확대됩니다.
많은 기업이 여전히 백업 보존을 저장소 물류 문제로 취급합니다. 복구에 성공하는 조직과 몸값을 지불하는 조직의 차이는 백업 보존 정책을 어떻게 설계, 구현, 집행하느냐에 달려 있습니다.
CISA #StopRansomware 가이드는 백업 보존을 교차 부문 사이버보안 성과 목표 2.R로 지정하며, 중요한 데이터의 오프라인 암호화 백업을 유지하고 정기적으로 가용성과 무결성을 테스트할 것을 요구합니다. 이는 연방 사이버보안의 기본선입니다.
랜섬웨어 그룹은 이제 백업 인프라를 주요 목표로 삼고 있습니다. 귀사의 백업 보존 정책은 이러한 백업이 생존할 수 있는지 여부를 결정하는 청사진입니다.
.jpg)
백업 보존 정책과 사이버보안의 관계
백업 보존 정책은 방어적 통제 수단입니다. NIST 사이버보안 프레임워크 2.0은 하위 범주 PR.DS-11에서 백업의 생성, 보호, 유지, 테스트를 요구하며 이를 명문화합니다. 이는 백업 보존을 엔드포인트 보호, 접근 관리, 네트워크 분리와 함께 보호 통제 아키텍처 내에 위치시킵니다.
공격자 행동을 살펴보면 사이버보안과의 연관성이 명확해집니다. NIST SP 800-209에 따르면, 공격자는 백업 프로세스 자체를 방해하여 향후 복사본을 점진적으로 오염시켜, 사용 가능한 백업이 이미 손상된 상태가 되도록 할 수 있습니다. 보존 기간은 손상 이전의 깨끗한 복구 지점을 유지할 수 있는지 직접적으로 결정합니다.
2021년 Colonial Pipeline 랜섬웨어 사고 당시, 미국 법무부는 DOJ 보도자료에서 440만 달러의 몸값 지급을 언급했습니다. 백업 보존만으로 랜섬웨어를 막을 수는 없지만, 협상 없이 복구 및 재개가 가능한지 여부를 결정합니다.
귀사의 백업 보존 정책은 얼마나 과거까지 복구할 수 있는지, 얼마나 빠르게 복구할 수 있는지, 그리고 공격자가 몸값 요구를 거부할 수 있는 능력을 제거할 수 있는지 정의합니다.
백업 보존 정책의 작동 방식
백업 보존 정책은 조직이 생성하는 모든 백업 복사본의 수명주기를 관리합니다. 각 데이터 분류 계층별로 생성 빈도, 저장 위치, 보호 메커니즘, 보존 기간, 폐기 절차를 명시합니다.
3-2-1-1-0 프레임워크
업계 표준은 기존 3-2-1 규칙에서 최신 랜섬웨어 전술을 반영한 3-2-1-1-0 프레임워크로 발전했습니다.
이 프레임워크는 다음을 요구합니다:
- 운영 데이터 외에 3개의 백업 복사본
- 다른 위험군에 대비해 2가지 다른 미디어 유형
- 지리적 분리를 위한 1개의 오프사이트 복사본
- 1개의 변경 불가능(immutable) 또는 에어갭 복사본, 그리고 백업 검증 테스트에서 0개의 오류
이 모든 요구사항을 준수하면 단일 침해로 모든 복구 옵션이 사라질 가능성을 줄일 수 있습니다.
보존 계층 및 기간
백업 보존 정책은 데이터 분류, 규제 요구사항, 복구 목표에 따라 보존 기간을 정의해야 합니다. Gartner Peer Community에 따르면, 기업 실무자들은 일반적으로 재해 복구용 백업(30~90일)과 규정 준수를 위한 아카이브 데이터(업종별 규정 적용)를 구분합니다.
모든 보존 결정에는 두 가지 시간 기반 목표가 있습니다:
- 복구 지점 목표(RPO): 복구 시 허용 가능한 최대 데이터 손실 기간. RPO가 4시간이면 4시간 이상의 데이터 손실은 허용되지 않습니다.
- 복구 시간 목표(RTO): 허용 가능한 최대 다운타임. 이는 보존 인프라가 사용 가능한 복구 지점을 얼마나 빨리 제공해야 하는지 결정합니다.
이 두 가지 RPO와 RTO가 백업 생성 빈도와 사고 발생 시 보존 인프라의 복구 속도를 결정합니다.
불변성(immutability) 및 접근 제어
불변 백업은 WORM(Write Once Read Many) 기술을 사용하여 전체 권한을 가진 관리자조차도 수정이나 삭제를 방지합니다. NIST SP 1800-25는 백업 시스템이 알려진 머신의 단일 서비스 계정으로 접근을 제한하고, 역할 기반 접근 제어, MFA, 운영 환경과 분리된 인증 프레임워크를 적용할 것을 명시합니다.
이러한 메커니즘이 기반을 마련하지만, 백업 구조화 방식이 각 데이터 계층을 얼마나 효과적으로 보호하는지 결정합니다.
백업 유형 및 보존 전략
백업 보존 정책은 조직이 사용하는 다양한 백업 방식까지 고려해야 합니다. 각 방식은 서로 다른 저장, 속도, 위험의 트레이드오프를 가진 복구 체인을 만듭니다.
- 전체 백업: 전체 백업은 선택된 모든 데이터를 한 번에 복사합니다. NIST SP 800-34는 데이터 중요도와 신규 정보 도입 속도에 따라 백업 빈도를 정책에 명시할 것을 권고합니다. 전체 백업은 복구가 가장 빠르지만, 저장 공간을 가장 많이 차지하고 완료까지 시간이 오래 걸립니다.
- 증분 백업: 증분 백업은 마지막 백업(전체 또는 증분) 이후 변경된 데이터만 캡처합니다. 각 증분은 작고 빠르지만, 복구 시 마지막 전체 백업과 모든 증분 백업이 순차적으로 필요합니다. 이 체인 중 하나라도 손상되면 이후 모든 복구 지점에 접근할 수 없습니다.
- 차등 백업: 차등 백업은 마지막 전체 백업 이후 변경된 모든 데이터를 캡처합니다. 여러 차등 백업이 실행되어도 상관없습니다. 차등 백업은 시간이 지날수록 커지지만, 복구 시 마지막 전체 백업과 최신 차등 백업만 필요하므로 증분보다 빠릅니다.
- GFS 회전 방식과의 결합: 대부분의 기업은 Grandfather-Father-Son(GFS) 회전 방식을 사용해 이 방법들을 결합합니다: 주간 전체 백업은 수개월 보관, 일일 차등 또는 증분 백업은 수주 보관, 월간 또는 연간 아카이브 복사본은 규정 준수를 위해 보관합니다. 보존 일정은 각 계층별로 다른 기간을 명시해야 합니다. 예를 들어, 일일 증분은 14일 후 만료, 주간 전체 백업은 90일 후 만료, 월간 아카이브 복사본은 규제 요구에 따라 1~7년 보관할 수 있습니다.
선택한 백업 유형은 RPO에도 영향을 미칩니다. 시간 단위 증분 백업은 일일 차등 백업보다 더 짧은 RPO를 제공하지만, 복구 체인이 길어져 RTO가 증가합니다. 각 데이터 분류 계층을 백업 방식과 보존 기간에 매핑하여 이러한 목표의 균형을 맞추십시오.
백업 보존 정책 모범 사례
문서상 백업 보존 정책은 실제 구현만큼 강력합니다. 아래 모범 사례는 백업 오염, 신원 정보 유출, 미검증 복구, 모니터링 부족 등 실제 사고에서 관찰된 특정 실패 유형을 해결합니다.
1. 최소 30~90일 불변 백업 저장소 적용
조직의 평균 위협 잠복 기간에 따라 불변 보존 기간을 설정하십시오. CISA LockBit 권고문은 모든 백업 데이터가 암호화되고 불변이어야 하며, 조직 전체 데이터 인프라를 포괄해야 한다고 요구합니다.
90일 보존 기간은 NIST SP 800-209에서 설명하는 백업 오염(공격자가 수주에 걸쳐 점진적으로 복사본을 손상시킨 후 운영 시스템에서 암호화를 트리거하는 공격)에 대응합니다. 30일 보존 기간은 신속히 탐지된 공격에 대응하지만, 장기 잠복 공격에는 충분하지 않을 수 있습니다.
2. 에어갭 또는 논리적 격리 저장소 구현
공격자가 운영 환경을 침해한 동일한 네트워크 경로로 불변 백업에 접근할 수 있다면, 백업의 가치는 사라집니다. NIST NCCoE 가이드는 물리적 에어갭(오프라인 테이프 또는 네트워크 연결이 없는 이동식 미디어) 또는 논리적 에어갭(객체 수준 보존 정책과 강력한 신원 분리를 적용한 온라인 저장소)을 통한 완전한 격리를 강조합니다. 어떤 방식이든, 공격자가 운영 신원 영역에서 백업 제어 영역으로 이동할 수 없어야 합니다.
3. 오류 허용 0의 복구 테스트 수행
3-2-1-1-0의 "0"은 미검증 복구 절차에 대한 0의 허용을 의미합니다. NIST 사이버보안 프레임워크 2.0은 백업 테스트를 명시적으로 요구하여, 이를 권장 사항에서 공식 사이버보안 결과 요구사항으로 격상시켰습니다.
위험 프로필에 맞는 테스트 주기를 구축하십시오:
- 중요 시스템 복구를 월 1회 검증
- 랜섬웨어 시나리오를 모의한 전체 복구 테스트를 분기별로 수행
- ISO 27001 감사를 위한 완전 복구 연습을 반기 또는 연 1회 실시
각 테스트는 실제 복구 시간을 RTO와 비교하고, 체크섬을 통해 데이터 무결성을 검증해야 합니다. 실패한 테스트는 P1 인시던트로 간주하고 다음 주기 전까지 조치하십시오.
4. 격리 복구 환경(IRE) 배포
NIST NCCoE 가이드는 불변 데이터 볼트(IDV)가 포함된 격리 복구 환경(IRE)을 권장합니다. 이는 백업 데이터를 복원 및 분석하되 악성코드를 재유입하지 않는 보안 격리 환경입니다. IRE는 별도의 인증 프레임워크, 전용 네트워크 세그먼트, 독립된 관리자 접근 경로가 필요합니다.
5. 백업 암호화 및 키 관리 분리
ISO 27001 지침에 따라 저장 시 AES-256 암호화와 전송 시 TLS 1.3을 적용하십시오. 암호화 키는 백업 데이터와 별도로 저장하고, 역할을 분리하십시오. 키 삭제 작업에는 MFA를 요구하십시오. 공격자가 동일한 접근 경로로 백업 데이터와 암호화 키를 모두 탈취하면, 암호화는 아무런 보호 효과가 없습니다.
6. 백업 텔레메트리를 보안 운영과 통합
백업 인프라는 SOC가 모니터링해야 할 신호를 생성합니다. NIST SP 800-61은 백업 시스템이 사고 대응 기능과 통합되어야 함을 명시합니다. 백업 텔레메트리를 SIEM 또는 XDR 플랫폼에 연동하고 다음을 모니터링하십시오:
- 백업 크기 또는 소요 시간의 급격한 변화
- 건너뛰거나 실패한 백업 작업
- 백업 인프라에서의 비정상 로그인 패턴
- 예상치 못한 수정 또는 삭제 시도
이러한 이상 징후는 종종 랜섬웨어가 암호화를 트리거하기 전에 나타납니다. SentinelOne의 Singularity Platform은 엔드포인트 및 클라우드 신호와 함께 이 텔레메트리를 연관시켜, 분석가에게 전체 공격 체인에 대한 컨텍스트를 제공합니다.
7. 골든 이미지 및 인프라 코드(IaC) 백업 유지
CISA #StopRansomware Guide는 조직이 중요 시스템의 골든 이미지를 유지하고, 인프라 코드(IaC)를 사용해 클라우드 리소스를 배포하며, 템플릿 백업을 오프라인으로 보관할 것을 지시합니다. IaC 템플릿을 버전 관리하고 변경 사항을 감사하여 전체 환경 복원을 가능하게 하십시오.
8. 파괴적 작업에 대한 쿼럼 기반 승인 구현
단일 관리자가 불변 백업을 삭제하거나 수정할 수 없어야 합니다. 백업 복사본 감소, 보존 기간 단축, 불변성 해제 등 모든 작업에 대해 쿼럼 기반 승인(복수의 승인자)을 요구하십시오. 이는 내부 위협과 특권 계정 탈취 모두에 대한 보호 수단입니다.
이러한 통제를 구현한 후, 보존 기간과 테스트 증적을 컴플라이언스 프레임워크에 매핑하십시오.
백업 보존에 대한 규제 준수 요구사항
백업 보존 기간은 단순한 보안 결정이 아니라, 감사 및 법적 결과를 수반하는 준수 의무입니다. 문제는 각 프레임워크가 서로 다른 요구사항을 부과하며, 많은 조직이 둘 이상의 프레임워크에 해당한다는 점입니다. 규제 프레임워크 간 충돌 시, 각 데이터 분류 계층별로 가장 긴 백업 보존 요구사항을 적용하고 그 근거를 문서화하십시오.
HIPAA
HIPAA는 백업 데이터 보존 기간을 명시하지 않지만, 45 CFR § 164.308(a)(7)에 따라 전자 보호 건강 정보(ePHI)의 검색 가능한 정확한 복사본을 생성 및 유지하는 절차를 요구합니다. HHS HIPAA 시리즈는 보안 문서에 대해 최소 6년 보존을 요구합니다.
GDPR
EDPB 가이드라인 4/2019는 더 이상 필요하지 않은 경우 개인정보 삭제를 요구합니다. GDPR은 백업을 EDPB 가이드라인 9/2022에 따라 처리로 간주하며, 모든 데이터 보호 요구사항이 적용됩니다. 각 보존 기간에 대한 비즈니스 근거를 문서화하십시오.
PCI-DSS
PCI-DSS 요구사항 10.7은 1년간의 감사 로그 보존(3개월은 즉시 접근 가능)을 요구합니다. 요구사항 3.1은 보존 기간을 초과한 저장 데이터의 분기별 안전 삭제 검증을 요구합니다.
SOC 2
SOC 2는 보존 기간을 명시하지 않습니다. 자체적으로 정의하고, 문서화하며, 일관되게 준수하고, 감사 시 효과적인 통제 운영을 입증해야 합니다.
프레임워크 | 백업 데이터 보존 | 문서 보존 | 테스트 필요 | 암호화 필요 |
HIPAA | 위험 기반(명시 없음) | 최소 6년 | 예 | 주소 지정 사양 |
GDPR | 목적 제한, 근거 문서화 | 책임성 원칙에 따름 | 예(적시 복구) | 제32조에 따라 필수 |
PCI-DSS | 비즈니스 근거, 분기별 검증 | 1년 감사 로그(3개월 온라인) | 암시적 | 카드 소지자 데이터에 필수 |
SOC 2 | 조직 정의 및 문서화 | 조직 정책에 따름 | 예(가용성 기준) | 필수(보안 기준) |
컴플라이언스 정렬은 필요조건일 뿐 충분조건은 아닙니다. 실제로 백업 보존을 무력화하는 실패 유형에 대한 계획도 필요합니다.
백업 보존 정책의 과제와 한계
잘 설계된 보존 정책도 실제 사고 시 드러나는 구현 장벽에 직면합니다. 가장 흔한 실패는 정책 자체는 올바르게 구축했으나, 공격자, 인프라 격차, 운영상의 사각지대가 시간이 지남에 따라 효과를 약화시키는 패턴을 보입니다.
랜섬웨어 그룹은 백업을 우선 공격
공격자는 백업 자격 증명을 탐색하고, 패치되지 않은 백업 솔루션을 악용하며, 운영 시스템에서 암호화를 트리거하기 전에 복구 인프라를 의도적으로 손상시킵니다. 백업 인프라가 운영 환경과 동일한 신원 저장소를 공유한다면, 하나의 도메인 관리자 계정이 손상될 경우 전체 복구 능력이 사라질 수 있습니다.
신원 인프라의 사각지대
Active Directory, 인증 시스템, 특권 접근 관리가 보존 범위에 포함되지 않으면, 복구 역설에 직면합니다: 불변 데이터 백업은 존재하지만 접근 복구가 불가능합니다. 백업 보존 정책은 신원 인프라를 1급 백업 대상으로 포함해야 합니다.
프레임워크 간 컴플라이언스 충돌
GDPR의 데이터 최소화 원칙은 HIPAA 또는 PCI-DSS의 장기 보존 요구와 충돌할 수 있습니다. 이러한 충돌 관리는 데이터별 보존 일정, 법적 근거 문서화, 지속적 법률 검토가 필요합니다.
모니터링 격차 및 침묵하는 실패
백업 로그나 알림을 아무도 검토하지 않으면, 실패가 수개월간 발견되지 않을 수 있습니다. 저장소가 가득 차고, 백업 작업이 알림 없이 건너뛰어지며, 실제 복구 시도 시에야 손상이 발견됩니다. 백업 텔레메트리를 보안 모니터링 스택에 통합하면 이 가시성 격차를 해소할 수 있습니다.
주말 및 휴일 공격 타이밍
공격자는 감시가 약화된 시간대를 노립니다. 랜섬웨어 그룹은 IT 인력이 가장 적은 시기에 공격을 감행하여, 백업 침해가 탐지되지 않는 시간을 늘립니다. 자율 모니터링 및 대응 기능이 수동 감독보다 이 취약점을 더 효과적으로 해결합니다.
이러한 과제는 공통된 격차를 시사합니다: 백업 보존 정책은 문서화뿐 아니라 지속적 집행이 필요합니다. 이 격차를 해소하려면 자율적으로 운영되고 전체 복구 환경에 대한 가시성을 제공하는 보안 플랫폼이 필요합니다.
SentinelOne으로 백업 보존 강화
백업 보존 정책은 규칙을 정의합니다. 보안 플랫폼은 그 규칙이 공격 상황에서 지켜지는지 결정합니다. SentinelOne의 Singularity Platform은 랜섬웨어가 백업 인프라에 도달하기 전에 차단하고, SOC가 실시간으로 백업 대상 행위를 탐지할 수 있는 가시성을 제공하여 백업 보존을 강화합니다.
자율 랜섬웨어 롤백
SentinelOne은 행위 기반 AI로 랜섬웨어 활동을 실행 단계에서 탐지 및 차단하여, 암호화가 백업 서버를 포함한 중요 시스템에 도달할 가능성을 줄입니다. 랜섬웨어가 Windows 엔드포인트의 파일을 암호화할 경우, 플랫폼의 롤백 기능은 볼륨 섀도 복사본을 사용해 공격 전 상태로 파일을 복원합니다.
백업 인프라 보호
Singularity Cloud Workload Security는 백업 인프라를 호스팅하는 VM, 서버, 컨테이너, Kubernetes 클러스터 전반에 실시간 보호를 확장합니다. 이 플랫폼은 공용 클라우드, 프라이빗 클라우드, 온프레미스 데이터센터에서 런타임 위협 방지 및 자율 대응을 제공하며, 분석가 개입 없이 영향을 받은 시스템을 격리하고 안전한 상태로 복구합니다.
AWS 백업 통합
SentinelOne은 AWS Backup과 통합되어 클라우드 복구 워크플로우를 간소화합니다. Singularity Cloud Workload Security가 손상된 EC2 인스턴스를 식별하면, AWS Backup에서 복구 정보를 조회하고 SentinelOne 콘솔에서 직접 복원 링크를 제공합니다.
Purple AI를 통한 백업 이상 탐지 조사
Purple AI는 분석가가 대화형 쿼리를 통해 의심스러운 백업 접근 패턴을 조사할 수 있게 하여, 사고 대응 시 복구 옵션 검증에 소요되는 시간을 단축합니다. 초기 도입 기업은 Purple AI가 위협 헌팅 및 조사를 최대 80% 빠르게 만든다고 보고합니다.
Singularity™ AI SIEM
SentinelOne의 Singularity™ AI SIEM은 자율 SOC를 위한 업계에서 가장 빠른 오픈 플랫폼으로, 모든 데이터와 워크플로우를 지원합니다. 데이터 레이크 기반으로 구축되어 엔터프라이즈 전체에 실시간 AI 보호를 제공합니다. 무제한 확장성과 무한 데이터 보존이 가능합니다. 하이퍼오토메이션으로 워크플로우를 가속화하십시오. 엔드포인트, 클라우드, 네트워크, 신원, 이메일 등 다양한 영역을 보호할 수 있습니다. 데이터를 실시간 탐지용으로 스트리밍하고, 자율 AI로 기계 속도 보호를 구현하십시오. 업계 유일의 통합 콘솔 경험으로 조사 및 탐지 가시성도 향상됩니다. 투어 보기.
SentinelOne 데모 신청을 통해 자율 백업 보호가 귀사 환경에 어떻게 적용되는지 확인하십시오.
핵심 요약
백업 보존은 귀사의 조직이 랜섬웨어에서 복구할지, 비용을 치를지 결정하는 사이버보안 통제입니다. 불변성, 에어갭 복사본을 포함한 3-2-1-1-0 프레임워크를 구현하십시오. 분기별로 오류 허용 0의 복구 테스트를 수행하십시오.
백업 보존 일정을 HIPAA, GDPR, PCI-DSS, SOC 2에 맞추고, 백업 텔레메트리를 SOC에 통합하십시오. SentinelOne의 Singularity Platform은 자율 대응과 실시간 가시성으로 이러한 전략을 강화합니다.
자주 묻는 질문
백업 보존 정책은 조직이 데이터 백업 사본을 얼마나 오래 보관할지, 어디에 저장할지, 언제 삭제할지 정의하는 일련의 규칙입니다. 생성 빈도, 저장 위치, 변경 불가능성 요구사항, 폐기 절차를 포함합니다.
보존 정책은 사이버 보안 요구사항, HIPAA 및 GDPR과 같은 규제 의무, 그리고 조직의 RPO 및 RTO 복구 목표에 의해 관리됩니다.
3-2-1-1-0 프레임워크는 기존 3-2-1 규칙에 랜섬웨어 대응을 위한 두 가지 요소를 추가한 것입니다. 추가된 "1"은 공격자가 관리자 자격 증명을 탈취해도 변경할 수 없는 변경 불가능 또는 에어갭 사본을 요구합니다.
"0"은 검증되지 않은 복구에 대한 무관용을 적용하여, 실제 사고 중에 손상 사실을 발견하지 않도록 합니다. 이는 백업 보존을 단순한 저장 위생에서 복구 통제로 전환합니다.
랜섬웨어 그룹은 종종 관리자 엔드포인트에서 메모리 덤프를 통해 자격 증명을 탈취한 후, 백업 콘솔과 저장소로 이동합니다. 패치되지 않은 백업 소프트웨어를 악용하고, 작업 일정을 변경해 보호 공백을 만들며, 보존 설정을 삭제하거나 단축하려 시도합니다.
일부 공격자는 시간이 지나면서 백업을 오염시켜 복구 시 지속성을 재도입하기도 합니다. 접근 경로 차단, 변경 불가능성 적용, 정기적인 복구 검증이 목표입니다.
백업 오염은 공격자가 잠복 기간 동안 백업을 점진적으로 손상시켜, 최근 복구 지점마다 침해가 포함되도록 하는 현상입니다. 암호화가 최종적으로 실행되면, 복구 시 공격자가 다시 유입됩니다.
변경 불가능 보존 기간은 환경 내 일반적인 잠복 기간을 초과해야 합니다. 많은 기업이 30~90일의 변경 불가능성을 시작점으로 삼고, 탐지 속도와 전반적 위험 허용도에 따라 조정합니다.
공격자가 Active Directory 또는 신원 공급자를 침해하면, 백업을 보관하는 시스템에 인증할 수 있는 능력을 상실할 수 있습니다. 데이터는 존재하지만, 안전하게 접근하거나 무결성을 입증할 수 없습니다.
신원 백업이 없으면, 도메인, 서비스 계정, 신뢰 관계를 복구 전에 재구성해야 하는 경우가 많습니다. 이로 인해 복구 시간이 수 시간에서 수일로 늘어날 수 있습니다.
