🦠 ① 서울대병원 환자정보 83만건 유출

2021.06 (북한 해킹조직)

서울대병원 서버 해킹 → 환자 81만 명 + 직원 1만 7천명 정보 유출 (북한 해킹조직 소행 확정).

• 의료 업종 보안 투자 8개 산업군 중 최저
• 진료정보·주민번호·진단명
• 의료데이터는 다크웹 고가 거래

💡 교훈 — Air-Gap·Immutable Backup·SIEM·SAC + 의료망 분리

참고: 「서울대병원 환자정보 유출 2021」 검색

🔥 ② SK C&C 화재 → DR 미흡

2022.10.15 (재인용)

판교 DC 화재 + 카카오의 DR 사이트 동기화 지연 → 복구가 5일 걸린 핵심 원인.

• DR 안 시 데이터 동기화 미흡
• BCP 시험 부족
• RPO·RTO 사전 정의 부재

💡 교훈 — 3-2-1-1-0 백업 + DR 분기 시험 + Sync/Async 복제 설계

참고: 「카카오 IDC 이중화 보고서」 검색

💾 ③ 2025 국가정보자원관리원 화재

2025.09.26 (금)

대전 본원 화재 → 정부 시스템 709개 마비 · 4주+ 복구. DR 사이트 미흡으로 96개 시스템을 대구 센터로 「긴급 이전 복구」.

• 정부 IT의 DR·이중화 부재 노출
• 운영-DR 동시 영향 (단일 사이트 의존)
• 복구 시험 미실시
• 「공공 IT BCP 점검」 의무화 추진

💡 교훈 — 3-2-1-1-0 + Sync/Async 복제 설계 + 분기 1회 복구 시험

참고: 위키백과 「2025년 국가정보자원관리원 화재」

🛡️ 3-2-1-1-0 — 백업 황금 원칙(2024+)

• 3 — 데이터 사본 3벌 (운영 1 + 백업 2)
• 2 — 서로 다른 저장 매체 2종 (Disk + Tape·Cloud 등)
• 1 — 1벌은 사외 (Offsite·다른 사이트·Cloud)
• +1 — 1벌은 Offline / Air-Gap / Immutable (랜섬웨어 무력화 방지)
• +0 — 검증 오류 0건 (SureBackup·이상탐지로 무결성 확인)

"검증되지 않은 백업은 존재하지 않는 백업" — Veeam·Rubrik·Cohesity가 사실상의 표준으로 만든 확장판.

Day 2 오후 · 약 180분

📋 세션 정보

• 회차: 7 / 18 — Day 2 오후
• 소속: 스토리지·백업·DR 통합 도메인
• 카테고리: 인프라 / 데이터 보호
• 예상 분량: 본문 70 슬라이드 + 일러스트 11장
• 강의 시간: 약 90분
• 강사: 박수현 — 젠아이랩스(GenAI Labs) CEO / CTO

🎯 핵심 메시지

"데이터는 어디에·어떻게 저장되며, 어떻게 보호하고, 사라졌을 때 어떻게 되살리는가" — 스토리지·백업·DR 의사결정의 압축 정리.

🧭 학습 목표 (Learning Objectives)

1. 6대 스토리지 유형 — DAS·NAS·SAN·Object·HCI·SDS를 워크로드별로 매핑한다
2. SAN 패브릭 — Director·Edge·Zoning·NPIV·WWN의 동작 원리를 설명한다
3. RAID·Snapshot·Replication — 안전망 3중 구조를 설계한다
4. Tape·LTO·LTFS·VTL — 장기 보존·랜섬웨어 대응의 마지막 방어선을 안다
5. 백업 정책 6종 — Full·Inc·Diff·Synthetic·Forever·Reverse를 비교한다
6. 3-2-1·3-2-1-1-0·Immutable — 랜섬웨어 시대 백업 황금 원칙을 설계한다
7. DR 4단계·RPO/RTO — 사이트 등급과 비용·가용성을 산정한다

1️⃣ DAS

• Direct Attached
• SAS/SATA 케이블 직결
• 단일 서버 전용
• 가장 단순·빠름·저렴

2️⃣ NAS

• Network Attached
• Ethernet + NFS·SMB
• 다수 클라이언트 파일 공유
• 홈디렉·미디어·백업타깃

3️⃣ SAN

• Storage Area Network
• FC·iSCSI·NVMe-oF
• 블록 단위 공유
• DB·VM·미션크리티컬

4️⃣ Object

• HTTP REST + S3 API
• 무한 확장·메타데이터
• WORM·버저닝·Object Lock
• 백업·아카이브·CDN 오리진

5️⃣ HCI

• Hyper-Converged
• Compute + Storage + NW 통합
• vSAN·Nutanix·VxRail
• VDI·중규모 가상화

6️⃣ SDS

• Software-Defined Storage
• 범용 HW + 소프트웨어
• Ceph·GlusterFS·Lustre
• 비용·확장성 우선

🔧 구성

• 서버 내장 디스크 베이 (2.5"/3.5")
• RAID 컨트롤러 + 캐시 + BBU/Flash 백업 모듈
• JBOD (Just a Bunch Of Disks) 외장 enclosure 연결
• 연결: SAS (12Gbps·24Gbps) · SATA (6Gbps) · NVMe (PCIe Gen4/5)

🔌 SCSI 계보

• SCSI (전통 Parallel SCSI)
• SAS (Serial Attached SCSI) — 12G·24G
• SATA (Serial ATA) — 6G
• NVMe (Non-Volatile Memory express) — PCIe 직결

✅ 적합한 용도

• 단일 서버 워크로드 (Web·WAS)
• 부팅 디스크·로컬 캐시
• 가성비·단순 운영 우선
• 공유가 불필요한 데이터
• AI 학습 데이터 로컬 캐싱 (NVMe)

⚠️ 한계

• 공유·이중화 어려움
• Live Migration 불가 (단일 노드 종속)
• 디스크 장애 = 서버 장애
• 확장성 낮음

🐧 NFS (Network File System)

• Unix·Linux 표준 파일 공유
• v3 — 무상태, UDP/TCP, 가장 보편
• v4 — 상태 유지, TCP만, 보안 강화 (Kerberos), ACL
• v4.1 — pNFS (병렬 액세스), 세션 multipathing
• v4.2 — Server-side copy, sparse file

🪟 SMB / CIFS (Server Message Block)

• Windows 표준 파일 공유
• SMB 1.0 / CIFS — 구식, 보안 취약 (비활성화 권장)
• SMB 2.x — Win Vista·2008, 효율 개선
• SMB 3.x — Win 2012+, 암호화·Multichannel·Direct (RDMA)

🧮 비교 매트릭스

🎯 선택 기준

• 운영 서버군 = NFS (홈디렉·App 데이터)
• 사무용 PC 공유 = SMB (AD 통합)
• 혼용 환경 = NetApp·TrueNAS 멀티프로토콜

🟧 FC (Fibre Channel)

• 전용 광 패브릭, 가장 안정적
• 세대별 속도:
• 4 Gbps (2003)
• 8 Gbps (2008)
• 16 Gbps (2011)
• 32 Gbps (2016)
• 64 Gbps (Gen 7, 2019)
• 128 Gbps (Gen 8, 2025+)
• BB Credit·CRC·In-Order Delivery 보장
• WWN·WWPN 식별자

🟦 iSCSI

• IP 위에 SCSI 캡슐화
• 이더넷 + TCP 사용 (저비용)
• IQN 식별자 (iqn.YYYY-MM.com.example:host)
• 10G·25G·100G NIC + DCB/PFC

🟪 FCoE (Fibre Channel over Ethernet)

• FC 프레임을 이더넷에 캡슐화
• Lossless DCB 필요 (PFC·ETS)
• 2010년대 중반 → 2020년대 쇠퇴
• NVMe/TCP·NVMe/RoCE로 대체

🟩 NVMe-oF (NVMe over Fabrics)

• 차세대 SAN 표준
• 변종:
• NVMe/FC — 기존 FC 패브릭 활용
• NVMe/TCP — TCP 위 (저비용)
• NVMe/RoCE — RDMA over Ethernet
• NVMe/IB — InfiniBand (HPC)
• 지연 < 100μs, IOPS 수백만

📊 비교 한 줄

• FC = 안정·고가, iSCSI = 저비용, NVMe-oF = 차세대

📦 Object Storage 특징

• 버킷 → 객체 2단 구조 (디렉터리 없음)
• HTTP REST API (S3·Swift)
• 메타데이터 풍부 — 사용자 정의 가능
• 무한 확장 — 수십 PB·수십 억 객체
• WORM·버저닝·Object Lock — 랜섬웨어 대응
• Erasure Coding 일반적 (RAID 대체)

🧮 적합한 워크로드

• 백업·아카이브 (장기 보존)
• 로그·이벤트 저장
• 미디어 (이미지·동영상)
• CDN 오리진
• 데이터 레이크·AI 학습 데이터셋
• 정적 웹 콘텐츠

🏆 주요 솔루션

🔒 핵심 기능

• Object Lock (Compliance·Governance 모드)
• 버저닝 — 이전 버전 보존
• 수명 주기 정책 — Hot→Cold→삭제

🧱 HCI란

• Compute + Storage + Network을 한 노드에 통합
• 노드 추가만으로 수평 확장
• 전용 SAN 패브릭 없음 (이더넷만)
• 단일 UI로 통합 관리
• VDI·중소 가상화의 사실상 표준

🛠️ 핵심 아이디어

• 각 노드의 로컬 디스크를 분산 스토리지 풀로 묶음
• 데이터 복제 (Replica 2·3) 또는 Erasure Coding
• 메타데이터·캐시는 SSD·NVMe

🏆 주요 솔루션 비교

✅ 장점

• 운영 단순화 (단일 UI)
• 빠른 도입 (수일~수주)
• 노드 단위 확장
• 백업·DR 통합 솔루션 풍부

⚠️ 한계

• 대규모 분리 확장(컴퓨트만/스토리지만) 어려움
• 라이센스 비용 (vSAN·Nutanix)
• 특정 워크로드(초대용량 DB)에서는 SAN 우위

💡 SDS란

• 범용 x86 서버 + 디스크 위에 소프트웨어가 스토리지 기능 제공
• 벤더 종속 탈피·비용 절감
• 블록·파일·객체 통합 가능
• 클러스터로 확장

🏆 주요 솔루션

• Ceph — 블록(RBD)·파일(CephFS)·객체(RGW) 통합, 오픈소스 최강
• GlusterFS — 분산 파일시스템, Red Hat 인수
• Lustre — HPC 병렬 파일시스템, 슈퍼컴퓨터 표준
• BeeGFS — HPC·AI 학습용
• DRBD — 블록 레벨 복제 (HA Pair)
• Storage Spaces Direct (S2D) — MS Windows Server

🆚 SDS vs 어플라이언스

🎯 SDS가 빛나는 곳

• HPC·AI 학습 (Lustre·BeeGFS)
• 대용량 백업·아카이브 (Ceph RGW)
• 클라우드 오픈소스 인프라 (Ceph + OpenStack)
• 비용 절감 정책이 강한 공공·연구

⚠️ 운영 부담

• 노드 장애·재구축·확장이 전부 자체 책임
• 사고 시 벤더 책임 한정적

🔥 Hot Spare

• 정상 동작 중인 대기 디스크
• 장애 발생 시 즉시 자동 재구축 투입
• Global Hot Spare — 전 그룹 공유
• Dedicated Hot Spare — 특정 그룹 전용
• 권고: 그룹당 1개 + Global 1개

⏱️ Rebuild Time 예시

• 1TB SAS HDD RAID 6 → 수 시간
• 8TB SATA HDD RAID 6 → 24~48시간
• 18TB HDD RAID 6 → 수 일 ⚠️
• SSD/NVMe → 빠름 (수십 분)
• 운영 IO 부하 + Rebuild = 성능 저하

📊 Drive Failure Rate

• AFR (Annualized Failure Rate)
• Backblaze 공개 데이터:
• Enterprise HDD: 0.5~1.5%/년
• Consumer HDD: 1.5~3%/년
• Enterprise SSD: 0.2~0.7%/년
• 디스크 100개 운영 시 = 연 1~3개 교체 필요

🛡️ Rebuild 위험 완화

• RAID 6 또는 Triple Parity 적용
• Erasure Coding 도입 (Object·SDS)
• Rebuild 우선순위 정책 — 운영 부하 시간 회피
• Hot Spare 사전 확보
• 정기 Scrub (Patrol Read) — 잠재 오류 사전 발견

🧱 RAID 6 — 듀얼 패리티 P/Q

• N+2 디스크 구성 (데이터 N + 패리티 2)
• 두 패리티 P (XOR) + Q (Reed-Solomon) 를 디스크 전체에 분산 저장
• 2개 디스크 동시 장애까지 데이터 보존
• Rebuild 중 추가 1개 장애도 견딤 → 대용량 HDD 시대 표준
• 쓰기 페널티 6배(읽기 2+쓰기 2 = 패리티 갱신)
• 적합: 18TB+ HDD·대용량 NAS·아카이브
• 벤더: NetApp RAID-DP · Dell PowerMax DRAID6 · Pure RAID-6 · HPE Alletra 9080

RAID 6 단면도 — 분산 P/Q 패리티 + Hot Spare Rebuild

🖊️ CoW (Copy-on-Write)

• Snapshot 시점에 원본 데이터 위치 그대로 유지
• 변경 발생 시: 이전 데이터를 별도 영역에 복사 → 그 후 원본 덮어쓰기
• 읽기 성능 우수, 쓰기 성능 저하 (1회 쓰기 = 1읽기 + 1쓰기 + 1쓰기)
• 채택: 전통 SAN (Dell EMC·HPE·일부 IBM)

🔁 RoW (Redirect-on-Write)

• Snapshot 시점부터 새 쓰기를 새 위치에 기록
• 원본 블록은 변경되지 않음
• 쓰기 성능 우수 (1회 쓰기 = 1쓰기)
• 메타데이터 관리 복잡 (가비지 컬렉션)
• 채택: NetApp WAFL·ZFS·대부분 현대 시스템

🔗 Clone

• Snapshot을 읽기·쓰기 가능한 새 볼륨으로 노출
• 처음엔 원본 공유, 변경분만 별도
• DB 테스트·개발 환경 신속 복제에 활용

⚠️ Snapshot의 한계

• 백업이 아니다 — 동일 어레이에 종속
• 어레이 자체 장애 시 Snapshot도 함께 손실
• 원본 데이터 부분 손상이면 Snapshot도 영향
• 메타데이터 의존 → 파일시스템 손상 시 무력

🎯 활용 패턴

• 패치·업그레이드 전 안전장치
• 시간별 정기 (RPO 단축 수단)
• Clone으로 테스트 DB 신속 생성
• 백업의 보조 수단으로 위치 잡기

🧊 CoW vs RoW — Snapshot 두 갈래

• CoW (Copy-on-Write) — 쓰기 발생 시 원본을 복사 후 덮어쓰기
• 쓰기 1회 = IO 3회 (Read + Copy + Write)
• Dell PowerStore · vSAN ESA · HPE Alletra
• RoW (Redirect-on-Write) — 쓰기를 신규 위치로 리다이렉트, 원본은 유지
• 쓰기 1회 = IO 1회 (Write only)
• NetApp WAFL · OpenZFS · Pure Purity//FA
• 핵심: Snapshot ≠ 백업 — 어레이가 죽으면 Snapshot도 죽는다

Snapshot CoW vs RoW — IO 경로 차이

🔄 Synchronous Replication

• 원본·복제본 동시 쓰기 후 응답
• RPO = 0 (데이터 손실 0)
• 거리 한계 ~ 100km (지연 < 5ms 권고)
• 비용 높음 (전용 회선·동등 사양)
• 사이트 간 응답시간 지연이 운영에 영향
• 미션크리티컬 (금융 코어·결제)

⏳ Asynchronous Replication

• 원본 쓰기 응답 → 일정 주기로 복제본에 적용
• RPO 수 초 ~ 수 분
• 거리 무제한 (대륙 간 가능)
• 운영 성능 영향 최소
• 일반 기업 DR의 표준

🏆 주요 솔루션

🌐 Stretched Cluster

• 두 사이트가 단일 클러스터로 동작
• LUN이 양쪽에서 동시 활성 (Active-Active)
• VMware vMSC·Hyper-V Stretch
• 거리·지연 제약 엄격

🗜️ Deduplication (중복제거)

• 동일한 블록을 1번만 저장, 나머지는 참조
• Inline — 쓰기 시점에 즉시 처리 (성능 영향 ↑)
• Post-Process — 일단 기록 후 백그라운드 처리

📦 Compression (압축)

• LZ4·Snappy·Zstd·Deflate 알고리즘
• Inline·Post-Process 동일 구분
• 텍스트·로그에서 효과 큼, 영상·암호화 파일은 효과 적음

🎯 효과가 큰 곳

• VDI (동일 OS 이미지 수십~수백) — 10:1 이상
• 백업 데이터 — 5:1 ~ 30:1
• DB 로그·텍스트 — 2:1 ~ 5:1

⚖️ 트레이드오프

📊 실효 절감률 측정

• Veeam 백업: 5~10:1 일반적
• VDI 부팅 이미지: 10~20:1
• DB: 2~3:1
• 영상·암호화 파일: 1.1:1 (효과 미미)

⚠️ 주의

• 암호화 후 Dedup·Compression 불가 — 순서 중요
• 메타데이터 손상 = 전체 데이터 손실 가능
• CPU·메모리 사양 충분히 확보

🎚️ Tiering (자동 계층화)

• 데이터 접근 빈도에 따라 자동 이동
• 일반 계층:

🔥 Tier 0: NVMe  (Hot)
🟧 Tier 1: SSD
🟨 Tier 2: SAS HDD
🟦 Tier 3: SATA HDD
☁️ Tier 4: Cloud Cold (S3 Glacier·Deep Archive)

• Cloud Tier — 자동 클라우드 오프로드 (NetApp FabricPool·Pure Cloud Block Store)
• 정책: 30일·90일·1년 미사용 → 다음 Tier로 이동

📦 Thin vs Thick Provisioning

⚠️ Thin Provisioning 과할당

• 가상 1TB 할당 × 100개 = 100TB 가상
• 실제 디스크 50TB → 사용량 50TB 도달 시 모든 LUN 일제 정지
• 실사용량 모니터링 + 알람(70%·80%·90%) 필수
• 정기 회수 (UNMAP) 운영

📋 운영 권고

• DB·미션크리티컬 = Thick
• VDI·일반 = Thin + 강한 모니터링

📂 LTFS란

• Tape에 파일시스템 메타데이터를 별도 파티션으로 저장
• 일반 OS 마운트 가능 (Linux·Windows·macOS)
• 파일 단위 접근 — cp, mv로 직접 다룸
• LTO-5+ 지원, 산업 표준 (ISO/IEC 20919)

🎯 활용 패턴

• 방송·미디어 — 영상 마스터 보관
• 연구·과학 — 측정 데이터 장기 보존
• 공공·아카이브 — 법정 보관
• 클라우드 백업 — AWS S3 Glacier 기반

🆚 LTFS vs 전통 Tape

⚠️ 주의

• 순차 매체 — 임의 접근 느림 (수십 초~수 분 탐색)
• 헤드 위치 이동 비용 큼
• 쓰기 후 자주 수정하는 데이터에는 부적합

🛡️ Tape의 본질적 강점

• 오프라인 매체 — 네트워크에서 분리되면 사이버 공격 불가능
• WORM — 본질적으로 한 번 쓰면 변경 불가
• 장기 보존 — 30년+ (적정 환경)
• 저비용 — GB당 단가 가장 낮음
• 에너지 효율 — 보관 중 전력 소모 0

📊 비용 비교 (대략, GB 당)

• HDD: $0.02 / GB / 월 (전력 포함)
• Object Cold: $0.004 / GB / 월
• Tape: $0.001 / GB / 월 + 초기 HW

🦠 랜섬웨어 대응 가치

• 운영망·관리망·백업망 다 침해되어도
• 오프라인 Tape은 격리되어 살아남음
• 실제 사건: 2020+ 다수 기업이 백업까지 암호화당해 몸값 지불
• 이후 Tape 복귀가 보안 권고로 부상

⚠️ Tape의 한계

• 복구 시간 길다 — 수 시간~수 일
• 순차 매체 — 부분 복구 비효율
• 물리 보관·운반 비용
• 카트리지·드라이브 노후화 관리

🎯 권장 운영

• 일별 Inc → 디스크, 주별 Full → Tape
• Tape는 오프사이트 보관 (사외 보관소)
• 분기 1회 복구 시험

🔥 Hot Backup

• 서비스 운영 중 백업
• DB Online Backup (Oracle RMAN·MS SQL VSS)
• Snapshot + 백업 SW 통합
• 응용 일관성 (Application-Consistent)
• 무중단 필수 환경

❄️ Cold Backup

• 서비스 중단 후 백업
• 가장 안정적 (정합성 100%)
• 야간 점검 윈도 활용
• 현대 거의 사용 안 함

🌤️ Warm Backup

• 단시간 일시 정지 후 백업
• 짧은 점검 윈도 활용
• 일부 DB·중요도 중간

🧬 일관성 수준

• Crash-Consistent — 디스크 상태만 (응용 미인지)
• File-System-Consistent — FS sync
• Application-Consistent — DB·App 협력 (VSS·Agent)

📌 VSS (Volume Shadow Copy Service)

• Windows 표준 Snapshot 프레임워크
• Exchange·SQL·SharePoint·AD 응용 일관성

🎯 권장 패턴

• Hot Backup + Application-Consistent = 현대 표준
• DB는 Native Backup Tool + 백업 SW 연계
• Oracle RMAN
• MS SQL Native Backup
• PostgreSQL pg_basebackup
• MongoDB mongodump
• 트랜잭션 로그 별도 백업 → 시점 복구

⚠️ 흔한 실수

• DB 파일을 일반 파일 백업하면 깨질 위험
• VSS Writer 비정상 → 백업 실패
• 트랜잭션 로그 백업 누락

🧪 검증 단계

1. Job 성공 확인 — 백업 SW의 status (기본)
2. 체크섬 검증 — SHA-256·CRC
3. 샘플 복구 시험 — 정기 무작위
4. 전체 복구 시험 — 분기·반기
5. 자동화된 검증 — 백업 후 자동 부팅·테스트

🛠️ 자동 검증 솔루션

• Veeam SureBackup — 격리 샌드박스에서 자동 부팅·테스트
• Commvault DASH — 자동 복구 시험
• Rubrik Live Mount — 즉시 마운트 검증
• Cohesity TestDev — 격리 환경 자동 생성

📋 정기 점검 체크리스트

• [ ] 일별: Job 성공률 100%인가
• [ ] 주별: 무작위 1건 복구 시험
• [ ] 월별: 보고서 + 실측 RTO 기록
• [ ] 분기별: 전체 DR 전환 시뮬레이션
• [ ] 반기별: Live DR 훈련
• [ ] 연: 정책·매체·솔루션 재검토

🚨 흔한 실패 패턴

• 백업 Job은 성공인데 데이터는 실제 백업되지 않은 경우 (Agent 오류)
• Tape 카트리지 자체 불량
• 복구 시 의존 라이브러리·DB 누락
• 비밀번호·인증서 정보가 없어 복구 불가

"백업이 정상 수행되고 있습니다"는 의미 없는 보고. "복구 시험 분기 1회 + 최근 실측 RTO + 검증된 복구 절차서"가 실질적 답.

🌬️ Air-Gapped (에어갭)

• 물리적·논리적으로 운영망과 분리된 백업
• 평시 분리 → 백업 시점에만 연결 → 다시 분리
• 종류:
• 물리 에어갭 — Tape 카트리지 오프라인 보관
• 논리 에어갭 — VLAN 분리 + 일시 활성화
• 시간 에어갭 — 백업 윈도 외 차단
• 자동화: 백업 SW + NW 자동화 연동

🪨 Immutable Backup

• 한 번 기록되면 변경·삭제 불가
• 보존 기간 동안 그대로 보존
• 시스템 관리자도 삭제 불가 (Compliance 모드)
• 랜섬웨어가 접근해도 데이터 보존

🔐 구현 방법

🎯 권장 조합

• 1차: Veeam Hardened Repository (즉시 복구)
• 2차: S3 Object Lock (Immutable 클라우드)
• 3차: LTO WORM (오프라인 최종 방어)
• → 3중 Immutable

🪨 WORM (Write Once Read Many)

• 물리적 또는 논리적으로 한 번만 쓰기 가능
• 금융·의료·공공 법정 보관에 사용
• 매체별 구현:
• CD-R·DVD-R·BD-R — 광 매체 (구식)
• LTO WORM 카트리지 — 별도 모델
• WORM Disk — 어플라이언스
• WORM Object Storage — S3 Object Lock

🔐 S3 Object Lock 모드

Governance 모드 - 일반 사용자는 삭제 불가 - 특별 권한(s3:BypassGovernanceRetention) 보유자는 가능 - 운영 유연성 + 보안

Compliance 모드 - 누구도 삭제 불가 (Root 계정조차) - 보존 기간 동안 100% 보존 - 법정 요건·랜섬웨어 최고 방어

📋 Object Lock 설정 예시

Retention:
  Mode: COMPLIANCE
  RetainUntilDate: 2027-12-31
LegalHold:
  Status: ON

• Retention — 시간 기반 (만료 후 삭제 가능)
• Legal Hold — 무기한 (수동 해제 전까지)
• 동시 적용 가능

🎯 활용 패턴

• 금융: Compliance 모드 + 5~10년 보관
• 공공: Compliance + 법정 보관 기간
• 일반 기업: Governance + 90일~1년
• 의료: Compliance + 10년+

⚠️ 주의

• 보존 기간 동안 저장 비용 청구 지속
• 잘못 설정하면 수정 불가 — 신중히 적용
• 버킷 단위·객체 단위 모두 가능

🔢 추가된 1과 0

+ 1 (Offline) - 오프라인·에어갭 1부 - Tape 카트리지 오프라인 보관 - 또는 Immutable Object Lock - 랜섬웨어 격리의 최종 방어선

+ 0 (Zero Errors) - 백업 후 검증 시 오류 0 - 자동화된 복구 시험 통과 - 체크섬 무결성 확인 - "검증된 백업만 백업"

🛡️ 시각화

3 — Copies (원본+2)
2 — Different Media (Disk+Tape·Disk+Cloud)
1 — Offsite (다른 건물·도시·클라우드)
1 — Offline (Tape WORM·Immutable)
0 — Errors (검증 통과)

🎯 실무 매핑

• 3-2-1-1-0 충족 = ISMS-P·금융 점검 통과 수준
• 핵심 시스템은 모두 이 수준 필수
• 일반 시스템은 3-2-1 만으로 충분할 수 있음

📋 점검 질문 (TA 면접 단골)

• "당신 환경의 3-2-1-1-0 수준은?"
• "마지막 검증 복구 시험 일자는?"
• "Immutable 백업 보유 여부?"

🦠 2020+ 사건의 공통 패턴

• 평균 잠복 기간 수 주~수 개월
• 백업 시스템 무력화가 암호화보다 우선
• AD 관리자 권한 탈취가 핵심 단계
• "백업이 있어도 백업 시스템이 살아 있어야 효력"

🎯 2단 공격의 본질

• 1단 — 백업 무력화 (Shadow Copy 삭제·Veeam 콘솔 침투·Tape 카탈로그 파괴)
• 2단 — 일제 암호화 (운영·복제·온라인 백업 동시)
• → Immutable·Air-Gap·Hardened Repo 가 마지막 보루

🚨 1단계 — Detection (탐지)

• EDR·SIEM·NDR 경보
• 사용자 신고 (파일 열리지 않음)
• 백업 Job 비정상

🛑 2단계 — Containment (격리)

• 감염 호스트 즉시 네트워크 분리
• AD 관리자 계정 비활성화
• 백업망 물리 차단 (운영 영향 격리)
• 외부 인터넷 차단 (C2 통신 차단)

🔍 3단계 — Investigation (조사)

• 침투 경로·시점·범위 식별
• 감염 시점 이전 백업 확보
• 포렌식 (디스크 이미지·메모리)
• 법적 절차 (경찰·KISA 신고)

🛠️ 4단계 — Recovery (복구)

• Immutable·Offline 백업 확보 확인
• 깨끗한 환경(새 서버) 준비
• 백업 시점 이전으로 복구
• 시스템 단계적 재구축
• 응용 검증 후 서비스 재개

📝 5단계 — Lessons Learned

• 사고 보고서 작성
• 침투 경로 차단 (패치·정책)
• 백업 정책 강화
• 직원 보안 교육
• 모의 침투 정기화

❌ 절대 하지 말아야 할 것

• 몸값 지불 → 복호화 보장 없음
• 백업 검증 없이 운영 망 재연결
• 사건 미보고 (법적 의무)

🏢 BCP (Business Continuity Plan)

• DR은 IT 인프라 영역
• BCP는 업무 연속성 — 사람·프로세스·외부 통신·물리 공간 포함
• BCP > DR > 백업·복구

📐 BIA (Business Impact Analysis)

• 업무별 중단 시 영향도 분석
• MTPD (Maximum Tolerable Period of Disruption)
• 등급별 우선순위
• → DR 등급 결정의 출발점

🏗️ DR 사이트 위치 결정 변수

• 거리 — 동일 재해 영향 회피
• 네트워크 비용 — 거리 ∝ 회선료
• 법규 — 금융 30km+ (전자금융감독규정)
• 인력 가용성 — 원격 운영 가능 여부

🗺️ 한국 DR 사이트 표준

⚖️ 거리의 트레이드오프

• 동기 복제 가능 한계 = ~100km (지연 5ms 이내)
• 100km+ → 비동기 복제 필수
• 1000km+ → 회선 비용 폭증

🎯 권고

• 동일 지진대·동일 전력망·동일 통신망 회피
• 통신 회선 물리적 이중화 (2개 통신사·2개 경로)

🔥 화재

• 가장 흔한 데이터센터 재해
• 진압 후에도 수증기·연기·연쇄 누전
• 화재진압 가스 (FM-200·Inergen·Novec-1230) 후 환기 필요
• 수 시간~수일 복구 불가
• → DR 사이트 절체 필요

💧 침수

• 1층·지하 데이터센터 위험
• 누수 감지기 필수
• 폭우·태풍·내부 배관 파열
• 한 번 침수되면 장비 거의 폐기

🌍 지진

• 한국도 안전지대 아님 (포항·경주)
• 진동 차단·내진 설계 필수
• 동일 지진대 회피 → DR 거리 결정 요인

⚡ 정전 (장기)

• UPS·발전기로 단기 대응
• 디젤 발전기 연료 = 보통 8~24시간분
• 장기 정전(수일+) = 운영 중단
• 한전 2회선·자가발전 + DR 필요

📡 통신 케이블 단절

• 광케이블 굴착 사고
• 통신사 1개 의존 = 리스크
• 2개 통신사·2개 물리 경로 필수
• 수 시간~수일 복구

🦠 랜섬웨어

• 21세기 가장 빈번한 "재해"
• 기술 사고가 아닌 공격
• Immutable·Air-Gap 필수
• BCP 시나리오 1순위

🦠 팬데믹·인력 불가

• COVID-19 사례
• 원격 운영 체계 필수
• 출입 인력 격리·교대
• 데이터센터 운영 BCP 별도

🏗️ 건물·시설 재해

• 천장 누수·에어컨 고장
• 전력 분전반 사고
• 시설 노후화

🎯 시나리오별 대응 매트릭스

💰 초기 구축 비용 (CapEx)

🔁 운영 비용 (OpEx, 연간)

📊 5년 TCO

• 초기 8.5억 + 운영 17.5억 = 약 26억
• 동일 가용성 클라우드 DR = 약 20~25억 (지속)
• 비교: 자체 DR vs AWS DR vs DRaaS

1️⃣ 스토리지 유형

• 워크로드별 6대 유형 매핑
• SAN vs HCI vs Object

2️⃣ 프로토콜

• FC vs iSCSI vs NVMe-oF
• NFS vs SMB

3️⃣ RAID 레벨

• DB = RAID 10
• 대용량 = RAID 6 / EC

4️⃣ Snapshot 정책

• 주기·보관 기간
• CoW vs RoW (벤더 종속)

5️⃣ Replication 모드

• Sync vs Async
• 거리·RPO

6️⃣ Dedup·Compression

• Inline vs Post
• 실효 절감률 보수적 산정

7️⃣ Thin vs Thick

• 워크로드별
• 모니터링 정책

8️⃣ 백업 정책

• Full·Inc·Synthetic·Forever
• GFS 보관 기간

9️⃣ 백업 매체 3계층

• 1차 Disk/VTL · 2차 Object Lock · 3차 Tape WORM

🔟 Immutable·Air-Gap

• 매체별 구현
• Compliance vs Governance

1️⃣1️⃣ DR 단계 결정

• 4단계 + Active-Active 중 선택
• BIA 기반

1️⃣2️⃣ 훈련 정책

• Tabletop·Walkthrough·Simulation·Parallel·Full
• 주기 + KPI

📑 DR 설계서 목차

1. 사업 개요·범위
2. BIA (Business Impact Analysis) - 핵심 업무 목록 - 중단 시 영향도 - MTPD·RTO·RPO 도출
3. DR 등급 결정 - 4단계 중 선택 근거 - 비용 산정
4. DR 사이트 위치·계약 - 거리·통신·접근성 - 코로케이션 vs 자체
5. DR 아키텍처 - 인프라 구성도 - 복제·동기화 방식 - 네트워크 토폴로지

6. 절체 절차 - Failover 절차 - Failback 절차 - 의사결정자·승인자
7. 데이터 동기화 모니터링 - 복제 지연·오류 알람 - RPO 실측
8. DR 훈련 계획 - 5단계 훈련 주기 - 실측 결과 기록
9. 이해관계자 통신 - 사고 시 알림 흐름 - 외부 통신 (고객·언론·당국)
10. 사후 검토·개선
    • 훈련 결과 반영
    • 설계서 갱신

🎯 산출물 권고 분량

• 본문: 80~150 페이지
• 별첨: 절차서·연락처·점검표

📜 SOP 구성

1. 목적·범위
2. 역할 정의 - CISO·CIO·TA·운영팀·홍보팀·법무팀 - 외부 연락처 (KISA·경찰·MSSP)
3. 탐지 기준 - EDR·SIEM 경보 조건 - 사용자 신고 채널
4. 초동 격리 절차 - 호스트 분리·계정 비활성화 - 백업망 차단 의사결정자
5. 조사·증거 보전 - 디스크 이미지·메모리 덤프 - 로그 보존

6. 복구 절차 - Immutable 백업 식별 - 복구 우선순위 - 단계별 시스템 재구축
7. 외부 통신 - KISA 신고 (24시간 내) - 개인정보 유출 시 통지 - 고객·언론 응대
8. 사후 조치 - RCA 보고서 - 정책·인프라 강화 - 직원 교육
9. 체크리스트·점검표
10. 연락처·에스컬레이션 매트릭스

🎯 SOP 권고

• 분기 1회 검토·갱신
• 모의 침해 훈련 시 SOP 따라가기
• 인쇄본도 비치 (NW 차단 시 디지털 접근 불가)

🚨 상황

• 운영자 실수로 핵심 테이블 DELETE
• 동기 복제본도 함께 삭제 (사이트 B에도 적용됨)
• 백업: 전일 야간 Full (자정)
• 사고 시점: 당일 14:00

❓ TA가 던지는 질문

1. RTO·RPO 등급은?
2. 시점 복구(PiTR) 가능한 DB인가?
3. 트랜잭션 로그 보관 여부
4. 백업 + 로그로 14:00 직전 복구 가능?
5. 전체 롤백 vs 부분 복구?

✅ 대응 절차

1. 격리 — 추가 변경 차단 (운영 일시 중지)
2. Snapshot 확보 (있다면)
3. 복구 결정 - Full + Archive Log → 13:59 시점 복구 - 별도 인스턴스에 복구 후 데이터만 추출 → 운영 인스턴스에 INSERT
4. 검증 — 데이터 정합성
5. 서비스 재개
6. 사후 보고 — 사용자 권한 재검토·감사 로그 강화

📌 교훈

• 복제 ≠ 백업 — 본 시나리오가 정답
• 트랜잭션 로그 백업이 PiTR의 전제
• DB Native Backup이 일반 백업보다 우선

🦠 상황

• 운영 서버·파일·NAS 일제 암호화
• 백업 디스크도 함께 암호화 (네트워크 마운트 상태)
• 동기 복제본도 암호화 상태로 복사됨
• → 일반 백업·복제 전부 무력화

🛡️ 보존된 자원

• 오프라인 Tape WORM (격리 보관)
• S3 Object Lock (Compliance) Immutable
• Veeam Hardened Linux Repository (변경 불가)
• → 3중 Immutable 중 일부 살아남음

✅ 대응 절차

1. 격리 — 전체 NW 차단, 외부 인터넷 차단
2. 조사 — 침투 시점 파악 (감염 이전 백업 확보)
3. 깨끗한 환경 준비 — 신규 서버·OS·NW 분리
4. 복구: - Tape 또는 Object Lock에서 마지막 정상 백업 복구 - 감염 시점 이전 데이터로 환원
5. 검증 — 악성코드 잔존 검사
6. 단계적 서비스 재개
7. KISA·경찰 신고 (의무)

📌 교훈

• "복제 + 백업 디스크"만 있으면 무력
• Immutable + Offline 2중이 최종 방어선
• 사후 침투 경로 차단·직원 교육·정기 훈련

⚡ 상황

• 강남 운영 사이트 인근 변전소 화재
• 한전 2회선 모두 동시 차단
• UPS 30분 + 자가발전기 가동
• 발전기 연료 12시간분 → 장기화 우려
• 운영팀 DR 절체 결정

🎯 RTO/RPO 목표

• 운영 RTO 1시간 / RPO 5분
• DR 사이트: 천안 (Warm Standby + 비동기 복제)

✅ 절체 절차

1. 결정 — CIO 승인 (사전 정의된 의사결정 매트릭스)
2. 고객 통지 — 점검 안내 (전화·SMS·홈페이지)
3. DB 비동기 복제 종료 — 마지막 복제분 적용
4. DR DB 활성화 — Read-Only → Read-Write 전환
5. DNS 변경 / GSLB 전환 — 트래픽 DR로
6. 응용 서비스 가동 — 미리 준비된 인스턴스
7. 검증 — 헬스체크·기본 트랜잭션
8. 서비스 재개 — 30분 내
9. 사후: - 실측 RTO/RPO 기록 - Failback 일정 수립 - 운영 사이트 복전·검증 후 Failback

📌 교훈

• 절체 자체보다 Failback이 어려움
• 정기 훈련이 실측 시간 단축의 유일한 방법

❌ 1. RAID = 백업

• RAID는 디스크 결함 대응만
• 사용자 실수·랜섬웨어 무력

❌ 2. 복제 = 백업

• 동기·비동기 모두 실수도 함께 복제
• 시점 복구 불가

❌ 3. Snapshot = 백업

• 어레이 자체 장애 시 함께 손실

❌ 4. 백업 = 복구 검증

• 백업 Job 성공 ≠ 실제 복구 가능
• 분기 1회 복구 시험 필수

❌ 5. Thin Provisioning 무한 과할당

• 실사용량 모니터링 누락
• 100% 도달 시 일제 정지

❌ 6. 모든 시스템 = 미션크리티컬

• 비용 비현실적
• BIA로 등급 분류 필수

❌ 7. 백업 디스크에만 의존

• 랜섬웨어가 NW 마운트 백업 같이 암호화
• Immutable + Offline 1중 이상 필수

❌ 8. DR 사이트 = 백업·복구의 끝

• 정기 훈련 없는 DR은 무용
• 절체 절차·인력 가용성 동반 필요

📜 국내 규제

• 전자금융감독규정 (금융위)
• 금융 DR 사이트 30km+
• 일 1회 이상 백업
• 분기 1회 모의 훈련
• 개인정보보호법
• 백업·복구 가능한 수단
• 안전한 보관·파기
• 정보통신망법
• 침해사고 24시간 내 신고
• 공공 SW 사업 데이터 요구사항
• 백업·보관 기간 명시

🏆 국내 인증

• ISMS-P — 정보보호·개인정보보호 관리체계
• 백업·복구 항목 점검
• CSAP — 클라우드 보안
• 백업·DR 요건

🌍 국제 표준

• ISO 27001 — 정보보호 관리체계
• 2.9.3 백업
• A.17 BCP
• ISO 22301 — BCM (사업연속성 관리)
• NIST SP 800-34 — Contingency Planning
• NIST CSF — Recover 기능
• PCI-DSS — 카드사 보안
• HIPAA — 의료 데이터 보안
• GDPR — 데이터 보호

🎯 TA의 점검 포인트

• 자사 적용 규제 목록 작성
• 규제별 백업·DR 요건 매트릭스
• 정기 점검 (분기·연)
• 인증 갱신 일정 관리

① 스토리지 6대 유형

DAS·NAS·SAN·Object·HCI·SDS — 워크로드별 매핑

② SAN 패브릭

Director·Edge·Zoning·NPIV·WWN

③ RAID + 안전망

RAID 6/10·Hot Spare·Rebuild = 디스크 결함 안전망

④ 고급 기능

Snapshot·Replication·Dedup·Tiering·Thin Provisioning

⑤ Tape 르네상스

LTO-9·LTFS·VTL·WORM·D2D2T·D2D2C

⑥ 백업 정책 + 3-2-1-1-0

6종 정책·GFS·Immutable·Hardened·Air-Gap

⑦ DR 4단계 + 훈련 5단계

BIA → 등급 → 사이트 → 절체 → 훈련 → 사후

🎯 핵심 메시지

• RAID + 백업 + 복제 + Immutable + DR = 5중 안전망
• 검증되지 않은 백업은 존재하지 않는 백업
• RPO/RTO는 요건, 수단은 TA가 설계