14. 보안과 랜섬웨어 대응
스토리지 암호화(SED/볼륨/KMS), 전송 암호화(NFS TLS/SMB 3.0/iSCSI IPSec), RBAC와 MFA, 랜섬웨어 대응 3단계(예방/탐지/복구), Immutable 스냅샷 벤더별 비교, 에어갭, 비정상 IO 패턴 탐지와 한계, 감염 후 클린 복구 절차, 관리 네트워크 격리, 보안 감사 대응까지.
시스템엔지니어가 알려주는 스토리지의 모든 것 시리즈15 / 15
- 112. 데이터 효율화 — 중복제거, 압축, 씬 프로비저닝
- 21. 스토리지, 왜 어렵고 왜 중요한가
- 32. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
- 43. 병렬 파일 시스템과 분산 스토리지 — Lustre, GPFS, HDFS
- 54. 프로토콜 깊이 파기 — FC / iSCSI / NFS / SMB / S3
- 65. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
- 76. 도입 검토 — 요구사항 분석과 벤더 선정
- 87-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
- 97-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
- 108. 구축 — 초기 설정과 호스트 연결
- 119. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
- 1210. 일상 운영 1: 볼륨 할당과 변경 관리
- 1311. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
- 1413. 백업과 아카이빙
- 1514. 보안과 랜섬웨어 대응
글꼴
랜섬웨어가 스토리지를 노린다.
예전에는 랜섬웨어가 PC의 파일을 암호화하는 수준이었다. 지금은 다르다. 공격자는 서버에 침투한 뒤 스토리지 관리 계정을 탈취하고, 스냅샷을 삭제하고, 백업을 먹통으로 만든 다음에 프로덕션 데이터를 암호화한다. 스냅샷도 없고 백업도 깨져있으면 복구할 방법이 없다. 이때 협박이 온다.
스토리지 보안은 "나중에 하자"고 미루기 쉬운 영역이다. 기능이 돌아가면 보안은 뒷전이 된다. 하지만 한번 뚫리면 돌이킬 수 없다. 이번 편에서는 스토리지 관점에서의 보안 — 암호화, 접근 제어, 랜섬웨어 대응, 보안 감사 — 을 다룬다.
암호화 — 데이터를 못 읽게 만든다
암호화는 두 가지로 나뉜다. 저장된 데이터의 암호화(Data at Rest)와 전송 중 데이터의 암호화(Data in Transit).
Data at Rest — 디스크에 저장된 데이터
구현 방식:
┌──────────────────────────────────────────────────────────┐
│ ① SED (Self-Encrypting Drive) │
│ │
│ 디스크/SSD 자체가 하드웨어로 암호화한다. │
│ 데이터가 디스크에 기록될 때 자동 암호화, │
│ 읽을 때 자동 복호화. 컨트롤러 CPU 부하 없음. │
│ │
│ 장점: 성능 영향 제로. 디스크를 도난당해도 데이터 보호. │
│ 단점: 디스크가 정상적으로 마운트된 상태에서는 │
│ 암호화가 "투명"하게 동작하므로, 논리적 공격 │
│ (랜섬웨어 등)은 막지 못한다. │
│ SED 디스크가 일반 디스크보다 비싸다. │
├──────────────────────────────────────────────────────────┤
│ ② 소프트웨어 볼륨 암호화 │
│ │
│ 스토리지 OS가 볼륨 단위로 소프트웨어 암호화를 한다. │
│ NetApp: NVE(NetApp Volume Encryption) │
│ Dell PowerStore: 볼륨 레벨 암호화 │
│ Pure: 항상 암호화 (기본 ON, 끌 수 없음) │
│ │
│ 장점: SED가 아닌 일반 디스크에서도 암호화 가능. │
│ 볼륨 단위로 제어 가능 (특정 볼륨만 암호화). │
│ 단점: 컨트롤러 CPU를 사용한다. │
│ 다만 올플래시 컨트롤러에서는 AES-NI 가속으로 │
│ 성능 영향이 1~3% 수준. 거의 체감 안 됨. │
├──────────────────────────────────────────────────────────┤
│ ③ KMS (Key Management Server) 연동 │
│ │
│ 암호화 키를 스토리지 내부에 저장하면, 스토리지를 │
│ 통째로 가져가면 키도 같이 가져갈 수 있다. │
│ → 외부 KMS에 키를 보관하면 이 문제를 해결. │
│ KMIP(Key Management Interoperability Protocol) 표준. │
│ │
│ 장점: 키 관리 중앙화. 키 로테이션 자동화. │
│ 단점: KMS가 죽으면 스토리지가 키를 못 받아서 │
│ 재부팅 시 볼륨을 못 열 수 있다. │
│ → KMS도 이중화 필수. KMS의 KMS(?)가 필요. │
│ KMS 도입/운영 복잡도가 올라간다. │
└──────────────────────────────────────────────────────────┘Data in Transit — 전송 중 데이터
┌──────────────────────────────────────────────────────────┐
│ 프로토콜별 전송 암호화: │
├──────────────────┬───────────────────────────────────────┤
│ NFS │ NFSv4 + Kerberos(krb5p) 또는 │
│ │ NFS over TLS (비교적 새로운 기능) │
│ │ 장점: 도청 방지. 무결성 보장. │
│ │ 단점: 암호화 오버헤드로 처리량 감소 │
│ │ (10~30%). 성능 민감 환경에서는 고민. │
├──────────────────┼───────────────────────────────────────┤
│ SMB │ SMB 3.0 이상: 전송 암호화 기본 지원 │
│ │ AES-128-GCM / AES-256-GCM │
│ │ 장점: 별도 설정 없이도 활성화 가능 │
│ │ 단점: SMB 1.0/2.x는 미지원. │
│ │ 레거시 클라이언트와 호환 문제. │
├──────────────────┼───────────────────────────────────────┤
│ iSCSI │ IPSec으로 암호화 가능. │
│ │ 장점: IP 레벨 암호화. │
│ │ 단점: 설정 복잡, 성능 오버헤드 큼. │
│ │ 실무에서는 전용 VLAN 격리로 대체하는 │
│ │ 경우가 더 많다. │
├──────────────────┼───────────────────────────────────────┤
│ FC │ FC Fabric 자체가 격리된 전용 네트워크.│
│ │ 이더넷과 섞이지 않으므로 도청 위험이 │
│ │ 상대적으로 낮다. │
│ │ FC-SP(Security Protocol) 표준이 │
│ │ 있지만 실무에서는 거의 안 쓴다. │
└──────────────────┴───────────────────────────────────────┘접근 제어 — 누가 뭘 할 수 있는가
스토리지의 접근 제어는 "데이터에 대한 접근"과 "관리 인터페이스에 대한 접근" 두 가지다.
데이터 접근 제어:
┌──────────────────────────────────────────────────────┐
│ · FC: Zoning + LUN Masking으로 호스트별 접근 제한 │
│ (4편, 8편에서 상세히 다룸) │
│ │
│ · NFS: Export Policy로 IP/서브넷 기반 접근 제어 │
│ + Kerberos로 사용자 인증 │
│ │
│ · SMB: AD(Active Directory) 연동으로 사용자/그룹 │
│ 기반 접근 제어. NTFS ACL 적용. │
│ │
│ · S3: IAM 정책, 버킷 정책으로 접근 제어 │
└──────────────────────────────────────────────────────┘관리 인터페이스 접근 제어가 사실 더 중요하다. 랜섬웨어 공격자가 노리는 건 데이터가 아니라 관리 계정이다.
관리 인터페이스 보안:
┌──────────────────────────────────────────────────────────┐
│ ① RBAC (Role-Based Access Control) │
│ │
│ 역할별 권한 분리: │
│ ┌────────────────┬────────────────────────────────┐ │
│ │ 역할 │ 권한 │ │
│ ├────────────────┼────────────────────────────────┤ │
│ │ Storage Admin │ 전체 관리 (볼륨 생성/삭제, │ │
│ │ │ 설정 변경, 펌웨어 업그레이드) │ │
│ ├────────────────┼────────────────────────────────┤ │
│ │ Operator │ 볼륨 생성/확장만. 삭제 불가. │ │
│ │ │ 설정 변경 불가. │ │
│ ├────────────────┼────────────────────────────────┤ │
│ │ Monitor │ 읽기 전용. 모니터링만. │ │
│ ├────────────────┼────────────────────────────────┤ │
│ │ Backup │ 스냅샷 생성/복제만. │ │
│ │ Operator │ 볼륨 설정 변경 불가. │ │
│ └────────────────┴────────────────────────────────┘ │
│ │
│ 모든 사람이 admin 계정을 공유하면? │
│ → 누가 뭘 했는지 추적 불가. 감사 불가. │
│ → 실수로 볼륨 삭제해도 "누구?"에 답 못 함. │
│ → 랜섬웨어 공격자가 admin 하나만 탈취하면 전부 끝. │
├──────────────────────────────────────────────────────────┤
│ ② MFA (Multi-Factor Authentication) │
│ │
│ 비밀번호만으로는 부족하다. OTP, 인증서, 하드웨어 토큰 │
│ 등 2차 인증을 추가한다. │
│ │
│ 벤더별 MFA 지원: │
│ NetApp: ONTAP 9.x에서 SSH MFA 지원 │
│ Pure: Pure1 클라우드 관리에서 MFA 기본 │
│ Dell/HPE: LDAP/SAML 연동으로 MFA 구현 │
│ │
│ 장점: 비밀번호 유출만으로는 로그인 불가. │
│ 단점: MFA 장비/앱 장애 시 관리 접속이 막힌다. │
│ → 긴급 접속용 로컬 admin 계정을 별도 보관. │
│ 이 계정은 봉인(sealed)하고 사용 시 기록. │
├──────────────────────────────────────────────────────────┤
│ ③ 감사 로그 (Audit Log) │
│ │
│ 누가, 언제, 어떤 명령을 실행했는지 기록한다. │
│ 로그를 스토리지 외부(SIEM, syslog 서버)로 전송해야 │
│ 공격자가 로그를 삭제해도 외부에 남아있다. │
│ │
│ 장점: 사후 추적 가능. 컴플라이언스 감사 대응. │
│ 단점: 로그 양이 많으면 저장/분석 비용. │
│ 외부 전송을 안 하면 공격자가 로그까지 삭제. │
└──────────────────────────────────────────────────────────┘랜섬웨어 대응 — 스토리지 관점
랜섬웨어 대응은 "예방 → 탐지 → 복구" 3단계로 나뉜다.
랜섬웨어 대응 3단계:
① 예방 ──► "감염되지 않게"
② 탐지 ──► "감염을 빨리 알아차리게"
③ 복구 ──► "감염되더라도 되돌릴 수 있게"
스토리지에서 할 수 있는 건 주로 ②와 ③이다.
①(예방)은 네트워크/엔드포인트 보안의 영역이지만,
스토리지 관리 계정 보안(RBAC, MFA)도 예방에 해당한다.예방: Immutable 스냅샷
Immutable 스냅샷이란:
일반 스냅샷: 관리자가 삭제할 수 있다.
→ 공격자가 admin 계정을 탈취하면 스냅샷도 삭제 가능.
Immutable 스냅샷: 설정된 보관 기간 동안 누구도 삭제 못 한다.
→ admin이어도, root여도, 벤더 SE여도 삭제 불가.
→ 보관 기간이 끝나야 자동 삭제됨.
벤더별 구현:
┌──────────────┬───────────────────────────────────────┐
│ NetApp │ SnapLock Compliance: 관리자도 삭제불가│
│ │ SnapLock Enterprise: 관리자 삭제 가능 │
│ │ (내부 통제용) │
│ │ 장점: 가장 오래 검증됨. 금융권 인증. │
│ │ 단점: Compliance 모드 설정 실수하면 │
│ │ 보관 기간까지 삭제 불가. │
├──────────────┼───────────────────────────────────────┤
│ Pure Storage │ SafeMode: 스냅샷 삭제 시 Pure 서포트 │
│ │ 에 연락해야 함 (2인 인증 구조) │
│ │ 장점: 관리가 단순하면서도 안전. │
│ │ 단점: 삭제 시 벤더 개입이 필요하므로 │
│ │ 긴급 상황에서 시간이 걸릴 수 있음│
├──────────────┼───────────────────────────────────────┤
│ Dell │ Cyber Vault: 격리된 볼트 환경에 │
│ │ Immutable 복사본 보관 │
│ │ 장점: 에어갭과 결합한 강력한 보호 │
│ │ 단점: 별도 인프라 필요. 비용 높음. │
├──────────────┼───────────────────────────────────────┤
│ HPE │ Alletra에서 Immutable 스냅샷 지원 │
│ │ InfoSight과 연동한 이상 탐지 │
└──────────────┴───────────────────────────────────────┘에어갭(Air Gap):
에어갭이란:
백업/스냅샷 복사본을 네트워크에서 물리적으로 분리하는 것.
┌──────────────────────────────────────────────────────┐
│ [프로덕션 네트워크] │
│ 스토리지 ──복제──► 백업 스토리지 │
│ │ │
│ (네트워크 차단) │
│ │ │
│ [격리된 환경] ▼ │
│ 에어갭 볼트 │
│ (Immutable 복사본) │
└──────────────────────────────────────────────────────┘
완전한 에어갭: 테이프를 꺼내서 금고에 넣기. 완벽하지만 복원 느림.
논리적 에어갭: 복제 후 네트워크 연결을 끊는 자동화. 빠르지만 완벽하진 않음.
장점: 네트워크로 접근 불가하므로 랜섬웨어가 물리적으로 못 닿음.
단점: 완전한 에어갭은 운영이 번거롭고 복원 시간이 길다.
논리적 에어갭은 자동화 구현이 복잡하고,
"연결 끊는 타이밍"에 취약점이 있을 수 있다.탐지: 비정상 IO 패턴 감지
랜섬웨어가 데이터를 암호화할 때 IO 패턴이 달라진다:
정상 상태:
· 읽기 70% / 쓰기 30%
· IOPS 안정적
· 데이터 리덕션 비율 2.5:1
랜섬웨어 감염 중:
· 읽기와 쓰기가 급격히 증가 (전체 파일을 읽고 암호화해서 다시 쓰기)
· 쓰기 비율이 급증 (50% → 90%)
· 데이터 리덕션 비율 급락 (2.5:1 → 1.1:1)
→ 암호화된 데이터는 중복제거/압축이 안 됨
· 파일 확장자가 대량으로 변경됨 (.encrypted, .locked 등)
벤더별 이상 탐지:
┌──────────────┬───────────────────────────────────────┐
│ NetApp │ ONTAP ARP(Anti-Ransomware Protection) │
│ │ 비정상 볼륨 활동 감지 → 자동 스냅샷 │
│ │ + 관리자 알림 │
├──────────────┼───────────────────────────────────────┤
│ Pure Storage │ Pure1 ML 기반 이상 탐지 │
├──────────────┼───────────────────────────────────────┤
│ Dell │ CyberSense (Cyber Vault 연동) │
│ │ 데이터 무결성 분석 │
├──────────────┼───────────────────────────────────────┤
│ HPE │ InfoSight 이상 탐지 │
└──────────────┴───────────────────────────────────────┘
탐지의 한계:
· 느린 암호화(Slow Encryption) 공격은 탐지가 어렵다.
하루에 1%씩 암호화하면 IO 패턴 변화가 미미.
· 오탐(False Positive)이 발생할 수 있다.
월말 대량 배치 처리를 랜섬웨어로 오인할 수 있음.
· 탐지는 "알려주는" 것이지 "막는" 것이 아니다.
알림을 받고 사람이 판단하고 대응해야 한다.복구: 감염 시점 식별과 클린 복구
랜섬웨어 감염 후 복구 절차:
┌──────────────────────────────────────────────────────┐
│ 1. 감염 범위 파악 │
│ 어떤 볼륨이 감염됐는가? │
│ 어떤 호스트에서 시작됐는가? │
│ │
│ 2. 감염 시점 식별 │
│ 스냅샷 히스토리에서 "마지막 클린 시점"을 찾는다. │
│ 데이터 리덕션 비율이 급락한 시점이 단서. │
│ 파일 변경 로그가 있으면 더 정확. │
│ │
│ 3. 네트워크 격리 │
│ 감염된 호스트의 네트워크를 차단한다. │
│ 스토리지 관리 네트워크도 격리 검토. │
│ │
│ 4. 클린 스냅샷에서 복원 │
│ 감염 이전 시점의 Immutable 스냅샷으로 복원. │
│ Immutable이 아닌 스냅샷은 공격자가 이미 │
│ 삭제했을 수 있다. │
│ │
│ 5. 복원 후 검증 │
│ 복원된 데이터가 깨끗한지 확인. │
│ 감염된 호스트를 클린 상태로 재구축 후 연결. │
│ │
│ 핵심: │
│ · Immutable 스냅샷이 없으면 3단계에서 막힌다. │
│ · 감염 시점을 못 찾으면 "언제로 돌릴지" 결정 못 함. │
│ · 호스트를 클린하게 안 만들고 복원하면 재감염. │
└──────────────────────────────────────────────────────┘관리 네트워크 보안 — 잊기 쉬운 공격 벡터
스토리지 관리 인터페이스(SSH, GUI)가 서비스 네트워크에 노출되어 있으면, 서버가 뚫렸을 때 스토리지 관리까지 바로 접근할 수 있다.
┌──────────────────────────────────────────────────────┐
│ 잘못된 구성: │
│ │
│ [서비스 네트워크 10.10.0.0/16] │
│ 서버들 ── 스토리지 데이터 포트 ── 스토리지 관리 포트│
│ → 서버가 뚫리면 스토리지 관리 GUI에 바로 접근 가능 │
│ │
│ 올바른 구성: │
│ │
│ [서비스 네트워크 10.10.0.0/16] │
│ 서버들 ── 스토리지 데이터 포트 │
│ │
│ [관리 네트워크 172.16.0.0/24] (별도 VLAN, ACL 적용) │
│ 관리 워크스테이션 ── 스토리지 관리 포트 │
│ 점프 호스트(Bastion) 경유만 허용 │
│ │
│ → 서비스 네트워크에서 관리 포트에 접근 불가 │
└──────────────────────────────────────────────────────┘
추가 보안 조치:
· SSH 접속 허용 IP를 관리 네트워크 대역으로 제한
· GUI(HTTPS) 접속도 관리 네트워크에서만 허용
· API 토큰은 사용 후 만료 설정. 영구 토큰 사용 금지.
· 불필요한 서비스(HTTP, Telnet, SNMPv1) 비활성화보안 감사 대응 — 증적 준비
내/외부 보안 감사에서 스토리지 관련 질문이 온다. 미리 준비해두면 당황하지 않는다.
보안 감사 시 스토리지 관련 질문 예시:
┌────────────────────────────────────────────────────────┐
│ 질문 │ 필요한 증적 │
├───────────────────────────────┼────────────────────────┤
│ "데이터 암호화가 되어 있나요?" │ 암호화 설정 화면 캡처 │
│ │ SED/NVE 상태 CLI 출력 │
├───────────────────────────────┼────────────────────────┤
│ "관리자 접근 이력이 있나요?" │ 감사 로그 추출 │
│ │ SIEM 연동 화면 │
├───────────────────────────────┼────────────────────────┤
│ "RBAC가 적용되어 있나요?" │ 계정 목록 + 역할 매핑 │
│ │ admin 공유 안 하는지 │
├───────────────────────────────┼────────────────────────┤
│ "백업이 정상적으로 되고 │ 백업 성공/실패 로그 │
│ 있나요?" │ 최근 복구 테스트 결과 │
├───────────────────────────────┼────────────────────────┤
│ "랜섬웨어 대응 방안이 │ Immutable 스냅샷 설정 │
│ 있나요?" │ 에어갭/복구 절차서 │
├───────────────────────────────┼────────────────────────┤
│ "퇴직자 계정이 정리되어 │ 계정 목록 최신화 │
│ 있나요?" │ 비활성 계정 리스트 │
└───────────────────────────────┴────────────────────────┘
감사 대응 팁:
· 증적은 평소에 수집해둬야 한다. 감사 통보 받고 만들면 늦다.
· 월 1회 보안 설정 점검 스크립트를 돌려서 결과를 보관.
· 퇴직자 계정 정리는 HR과 연동해서 자동화하는 게 이상적.
수동이면 빠뜨린다. 퇴직한 지 6개월 된 admin 계정이
살아있는 경우가 실제로 있다.스토리지 보안 체크리스트
┌──────────────────────────────────────────────────────────┐
│ 스토리지 보안 점검 체크리스트 │
├──────────────────────────────────────────────────────────┤
│ □ Data at Rest 암호화 활성화 (SED 또는 볼륨 암호화) │
│ □ KMS 연동 (키를 스토리지 외부에 보관) │
│ □ 관리 네트워크 분리 (서비스 네트워크와 격리) │
│ □ RBAC 적용 (admin 공유 금지, 역할별 분리) │
│ □ MFA 활성화 (최소한 관리자 계정) │
│ □ 감사 로그 → 외부 전송 (SIEM/syslog) │
│ □ 기본 admin 비밀번호 변경 완료 │
│ □ 불필요한 서비스 비활성화 (HTTP, Telnet, SNMPv1) │
│ □ Immutable 스냅샷 설정 (보관 기간 확인) │
│ □ 백업 복구 테스트 (최근 분기 내 실시) │
│ □ 퇴직자 계정 정리 (분기 1회 이상) │
│ □ API 토큰 만료 설정 확인 │
└──────────────────────────────────────────────────────────┘보안은 한 번 설정하고 끝이 아니다. 정기적으로 점검하고, 새로운 위협에 대응해야 한다. 특히 랜섬웨어는 공격 기법이 계속 진화하고 있어서, "작년에 괜찮았으니 올해도 괜찮겠지"는 통하지 않는다.
다음 편에서는 장애 대응을 다룬다. 디스크가 죽었을 때, 컨트롤러가 멈췄을 때, 성능이 급락했을 때. 새벽 3시에 전화가 왔을 때 뭘 어떤 순서로 확인해야 하는지.
이 글이 어떠셨나요?
관련 포스트
Infrastructure
13. 백업과 아카이빙
3-2-1 백업 원칙, Full/Incremental/Differential 비교, 백업 방식 4가지(에이전트/스냅샷/이미지/NDMP)의 장단점, 백업 매체(디스크/테이프/클라우드) 비교, 테이프가 아직 살아있는 이유, 백업 SW 생태계, WORM과 컴플라이언스, 복구 테스트의 중요성, 백업과 아카이빙의 차이까지. 데이터의 마지막 보루.
2026. 06. 29. PM 10:00Infrastructure12. 데이터 효율화 — 중복제거, 압축, 씬 프로비저닝
중복제거 동작 원리와 인라인/포스트프로세스 차이, 압축 알고리즘(LZ4 vs ZSTD) 비교, 컴팩션과 쓰기 증폭(WAF), 씬 프로비저닝의 오버프로비저닝 위험, 벤더별 효율화 구현 차이, "5:1 리덕션"의 진실과 측정 기준의 함정까지. 공짜 점심은 없다.
2026. 06. 22. PM 10:00Infrastructure11. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
스토리지 모니터링 핵심 메트릭(Latency/IOPS/Throughput/Queue Depth), 성능 병목 분석 흐름, QoS 설정과 벤더별 차이, 씬 프로비저닝 용량 관리의 위험, 긴급 용량 확보 방법까지. 장애가 터지기 전에 잡는 일상 운영의 기술.
2026. 06. 15. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.
댓글
댓글을 불러오는 중...