백업 보안: immutable backup, ransomware 대응, restore 권한 분리

백업이 공격 대상이 된 시대

랜섬웨어 공격자는 더 이상 운영 데이터만 암호화하지 않는다. 공격이 정교해지면서 백업 시스템을 먼저 탐색하고, 접근 가능한 백업을 삭제하거나 암호화한 뒤, 운영 DB를 공격한다. 피해자가 복구 수단을 잃고 나면 몸값 협박이 시작된다.

2024년 이후 DB 랜섬웨어 사고의 상당수에서 "백업도 함께 암호화되었다"는 보고가 반복된다. 이는 기술적 문제가 아니라 구조 문제다. 백업 스토리지가 프로덕션 네트워크와 같은 자격증명을 공유하거나, 백업 파일을 읽기/쓰기로 마운트해두면, 운영 계정이 침해된 순간 백업도 함께 잃는다.

이 장은 백업 자체를 보호하는 설계인 immutable backup, 랜섬웨어 대응 절차, 복구 권한 분리를 다룬다.

1. 3-2-1-1 규칙: 현대화된 백업 원칙

전통적인 3-2-1 규칙(3개 사본, 2개 미디어 유형, 1개 오프사이트)은 랜섬웨어 이전의 설계다. 오프사이트 사본도 네트워크로 접근 가능하면 공격자가 삭제할 수 있다.

3-2-1-1 규칙은 여기에 하나를 더 추가한다.

마지막 +1이 핵심이다. 공격자가 관리자 계정을 탈취하더라도 immutable 사본은 삭제하거나 덮어쓸 수 없어야 한다.

2. Immutable Backup: 기술 구현

2.1 S3 Object Lock

AWS S3 Object Lock은 객체를 WORM(Write Once, Read Many) 모드로 보호한다. 버킷 생성 시 활성화해야 하며, 활성화 후 비활성화할 수 없다.

두 가지 모드:

# 버킷 생성 시 Object Lock 활성화 (생성 이후 변경 불가)
aws s3api create-bucket \
  --bucket db-backups-immutable \
  --object-lock-enabled-for-bucket

# 기본 보존 정책 설정 (Compliance 모드, 365일)
aws s3api put-object-lock-configuration \
  --bucket db-backups-immutable \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Days": 365
      }
    }
  }'

2.2 GCS와 Azure의 동등 기능

GCS에서는 버킷에 Bucket Lock을 적용하면 retention policy 자체를 단축하거나 삭제할 수 없게 된다.

# GCS: 버킷에 180일 retention policy 설정 후 lock
gcloud storage buckets update gs://db-backups-immutable \
  --retention-period=180d

# lock: 이후 retention 기간 단축 불가 (불가역적)
gcloud storage buckets update gs://db-backups-immutable \
  --lock-retention-policy

2.3 MinIO와 온프레미스 WORM

클라우드를 사용하지 않는 환경에서는 MinIO가 S3 호환 WORM 기능을 제공한다. 온프레미스 NAS/오브젝트 스토리지에 immutable 백업을 구현할 때 활용한다.

# MinIO: 버킷 생성 + Object Locking 활성화
mc mb --with-lock myminio/db-backups-immutable

# 기본 보존 정책 설정
mc retention set --default COMPLIANCE 365d myminio/db-backups-immutable

3. Air-Gap: 네트워크 분리

Air-gap은 백업 스토리지가 프로덕션 네트워크나 인터넷에서 완전히 단절된 상태를 말한다. 공격자가 네트워크 경로를 통해 도달할 수 없으므로 가장 강력한 보호 방법이다.

구현 방법별 수준:

대부분의 조직에서 현실적인 선택은 크로스 계정 격리 + Object Lock Compliance의 조합이다. 테이프 air-gap은 복구 시간이 길기 때문에, 장기 보관이나 규정 준수용으로는 적합하지만 빠른 복구에는 제약이 있다.

4. 복구 권한 분리 (Restore Access Control)

백업 생성 권한과 복구 실행 권한을 분리하는 것은 보안과 운영 모두에서 중요하다.

4.1 왜 분리해야 하는가

• 내부자 위협 방지: 복구 권한을 가진 사람이 데이터를 무단으로 복원해 이전 상태로 되돌리거나 민감 정보를 추출할 수 있다.
• 실수 방지: 운영 중인 DB에 실수로 복구를 실행해 현재 데이터를 덮어쓰는 사고를 방지한다.
• 감사 추적: 복구 작업에 별도 승인과 감사 로그가 남아야 컴플라이언스 요건을 충족한다.

4.2 권한 구조

4.3 AWS IAM 정책 예시

// 백업 쓰기 계정: 업로드만 허용, 삭제 불가
{
  "Effect": "Deny",
  "Action": [
    "s3:DeleteObject",
    "s3:DeleteObjectVersion",
    "s3:PutObjectRetention"
  ],
  "Resource": "arn:aws:s3:::db-backups-immutable/*"
}

// 복구 실행 계정: 읽기만 허용
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:GetObjectVersion",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::db-backups-immutable",
    "arn:aws:s3:::db-backups-immutable/*"
  ]
}

5. 랜섬웨어 대응 절차

5.1 복구 시점 선택의 함정

랜섬웨어가 실행된 시각 이전으로 복구하더라도 공격자가 언제 최초 침입했는지 파악해야 한다. 침입 후 수주 또는 수개월을 잠복한 뒤 랜섬웨어를 실행하는 패턴이 늘고 있다. 최초 침입 시각을 모른다면 복구한 환경에도 공격자의 백도어가 포함될 수 있다.

• 감사 로그(앞 장에서 다룬 내용)가 최초 침입 시각 추정에 결정적이다.
• 가능하면 격리 환경(별도 VPC/계정)에서 먼저 복구한 뒤, 침입 흔적을 제거한 후 프로덕션으로 전환한다.

5.2 자격증명 교체 체크리스트

복구 완료 후 반드시 다음을 교체해야 한다.

• DB 관리자 계정 비밀번호
• 애플리케이션 서비스 계정 비밀번호
• 클라우드 IAM 액세스 키 (backup agent 계정 포함)
• SSL/TLS 인증서 (인증서 저장소가 침해된 경우)
• KMS 키 접근 정책 검토

6. 복구 리허설: 백업이 실제 작동하는지 검증

"백업은 테스트하기 전까지는 백업이 아니다." 백업이 있어도 실제 복구를 해보지 않으면 복구 시간과 성공 여부를 알 수 없다.

리허설 주기별 목표:

# 간단한 MySQL 복구 검증 스크립트 예시
#!/bin/bash
BACKUP_FILE="$1"
TEST_PORT=33061

# 격리된 MySQL 인스턴스에서 복구 테스트
docker run -d --name mysql-restore-test \
  -e MYSQL_ROOT_PASSWORD=testpass \
  -p $TEST_PORT:3306 mysql:8.0

sleep 10

# xtrabackup으로 복구
xtrabackup --prepare --target-dir=$BACKUP_FILE
xtrabackup --copy-back --target-dir=$BACKUP_FILE \
  --datadir=/tmp/restore-test-data

# 테이블 수 확인
TABLES=$(mysql -h127.0.0.1 -P$TEST_PORT -uroot -ptestpass \
  -e "SELECT COUNT(*) FROM information_schema.TABLES" --skip-column-names)

echo "복구된 테이블 수: $TABLES"

# 정리
docker stop mysql-restore-test
docker rm mysql-restore-test

7. 운영 체크리스트

마무리: 백업은 마지막 방어선이다

운영 DB 보안이 뚫려도 immutable 백업이 살아있으면 복구할 수 있다. 반대로 운영 DB 보안이 완벽해도 백업이 함께 침해되면 복구 수단이 없다.

3-2-1-1 규칙, Object Lock Compliance, 복구 권한 분리, 정기 리허설은 선택이 아니다. 랜섬웨어가 DB 환경을 직접 겨냥하는 지금, 이것들이 운영자의 기본 책임 범위다.

다음 장에서는 SOC 2, PCI DSS 같은 규정 프레임워크에서 실제로 증적을 수집하고, 통제를 매핑하고, 예외를 관리하는 실무를 다룬다.

References

• SentinelOne, "What Are Immutable Backups? Autonomous Ransomware Protection": https://www.sentinelone.com/cybersecurity-101/cybersecurity/immutable-backups/
• AWS Documentation, "Amazon S3 Object Lock": https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
• Object First, "S3 Object Lock for Ransomware Protection": https://objectfirst.com/guides/immutability/s3-object-lock-for-ransomware-protection/
• AWS in Plain English, "How to Use Object Lock in Amazon S3 with Compliance Mode": https://aws.plainenglish.io/how-to-use-object-lock-in-amazon-s3-with-compliance-mode-for-immutable-backups-and-worm-regulatory-f1f3bb4006c3
• SeqOps, "Backup Strategies Against Ransomware — 3-2-1-1 Guide": https://seqops.io/knowledge-hub/ransomware-prevention/backup-strategies-ransomware
• Object First, "3-2-1 Backup Rule Explained & Why It's No Longer Enough": https://objectfirst.com/guides/data-backup/3-2-1-backup-rule-and-strategy/
• Impossible Cloud, "The 3-2-1 Backup Rule Modernized": https://www.impossiblecloud.com/en-us/magazine/3-2-1-backup-rule-v2-2-new
• ComputingForGeeks, "Immutable Backups on Linux: Ransomware-Proof Strategy with MinIO, Restic, and Borg": https://computingforgeeks.com/immutable-backups-ransomware-proof-linux-minio-restic-borg/
• AvePoint, "What Is an Immutable Backup and Does It Actually Stop Ransomware?": https://www.avepoint.com/blog/backup/immutable-backup
• AWS, "Protect against Ransomware and Insider Threats with Best Practices on Data Resiliency": https://pages.awscloud.com/rs/112-TZM-766/images/DMWQ1D4S1T3-Protect%20against%20Ransomware%20and%20Insider%20Threats%20with%20Best%20Practices%20on%20Data%20Resiliency.pdf