클라우드 컴퓨터 · 가상머신 · 도커 / 컨테이너

한국 대기업이 클라우드로 보안을 운영하는 이유부터 가상화·컨테이너의 차이까지

이 문서에서 다루는 것
  • 클라우드 컴퓨터가 무엇이며 로컬 PC와 어떻게 연결되는가
  • 대기업이 클라우드(VDI)로 운영하면 보안이 좋아지는 6가지 이유
  • 가상머신(VM)의 구조와 클라우드 컴퓨터와의 관계
  • 도커/컨테이너가 VM과 어떻게 다른가
  • 클라우드 저장소 vs 클라우드 컴퓨터의 차이

1. 클라우드 컴퓨터 (Cloud Computer)

1-1. 클라우드 컴퓨터란?

클라우드 컴퓨터란 내 책상 앞에 있는 컴퓨터가 아니라, 인터넷 너머 데이터센터에 존재하는 컴퓨터를 의미합니다. 사용자는 자신의 로컬 PC로 그 원격 컴퓨터에 접속해서 마치 자기 컴퓨터처럼 사용합니다.

로컬 PC (내 노트북) 화면 표시 + 키보드/마우스 인터넷 (TLS 암호화) 데이터센터 서버 #1 서버 #2 서버 #3 클라우드 컴퓨터 실제 연산 / 파일 저장 입력 신호 화면 픽셀
그림 1. 로컬 PC와 클라우드 컴퓨터의 연결 — 데이터는 서버에만, 로컬엔 화면만 전송됨

1-2. 로컬 컴퓨터에서 어떻게 실행되는가?

실제 연산은 클라우드 서버에서 일어나고, 내 로컬 컴퓨터는 화면을 받아서 보여주고 + 키보드/마우스 입력을 보내는 역할만 합니다. 이것이 "씬 클라이언트(Thin Client)" 방식이며, 한국 대기업 VDI의 기본 동작 원리입니다.

① 직원 로그인 사번 + 2단계 인증 ② 브로커 인증 VDI 브로커 서버 ③ VM 할당 내 전용 가상 PC 연결 ④ 화면 송수신 RDP / PCoIP 로컬 PC 키보드/마우스 화면 표시 입력 신호 ▶ ◀ 화면 픽셀 클라우드 컴퓨터 (VM) CPU / RAM / OS / 파일 실제 프로그램 실행
그림 2. 클라우드 컴퓨터 접속 흐름 — ① 로그인 → ② 인증 → ③ VM 할당 → ④ 화면 송수신 시작

1-3. 연결 프로토콜 — 무엇으로 연결되는가?

로컬과 클라우드 컴퓨터는 원격 데스크톱 프로토콜로 연결됩니다.

프로토콜 제공사 특징
RDP
Remote Desktop Protocol
Microsoft Windows 원격 접속의 표준. 회사 노트북에서 가장 흔히 보는 방식.
PCoIP / Blast VMware Horizon 기업용 VDI 전용. 화면을 압축해 적은 대역폭으로 전송. 강력한 암호화.
HDX Citrix 금융권에서 많이 사용. 보안 강도 매우 높음.
VNC 오픈소스 화면을 비트맵으로 전송하는 범용 프로토콜. 가볍지만 보안은 약함.
SSH 표준 리눅스 서버에 터미널(CLI)로 접속할 때. 개발자 작업에 주로 사용.
핵심
프로토콜이 다르더라도 본질은 같습니다 — "내 PC에는 데이터가 안 들어오고, 화면만 들어온다". 이것이 보안의 출발점입니다.

2. 클라우드 컴퓨터에서 보안이 좋은 이유

한국 대기업(삼성, SK, LG, 현대 등)이 사내 업무 PC를 클라우드(VDI)로 운영하는 가장 큰 이유는 보안입니다. 구체적으로 어떤 점이 보안에 유리한지 6가지로 정리했습니다.

❌ 일반 PC 환경 로컬 디스크에 기밀 파일.docx 설계도면.pdf 고객정보.xlsx ↑ USB·메일로 유출 가능 분실 = 자료 유출 ✓ VDI 환경 로컬 PC 데이터: 없음 (화면만) 화면 VM 모든 데이터 여기에 (사내망)
그림 3. 일반 PC와 VDI의 보안 차이 — VDI에선 로컬 PC를 잃어도 데이터는 사내망에 그대로 남음
REASON 01
데이터가 로컬에 없음
모든 파일은 회사 데이터센터의 VM/스토리지에만 저장됩니다. 로컬 PC에는 화면 픽셀만 들어오므로 USB로 복사할 파일 자체가 존재하지 않습니다. 노트북을 도난당해도 기밀 데이터는 회사 안에 그대로 있습니다.
REASON 02
중앙 집중 통제
보안 패치, 백신 업데이트, OS 버전 관리, 권한 부여를 한 곳에서 일괄 처리합니다. 직원 1만 명 PC를 개별 관리할 필요 없이, 표준 VM 이미지 하나만 갱신하면 모두에게 적용됩니다.
REASON 03
즉시 접근 차단 가능
퇴사·이직·인사이동·보안사고 발생 시 계정 하나만 비활성화하면 즉시 모든 접근이 차단됩니다. 물리 노트북을 회수하기 전에 이미 차단이 완료되므로 "회수 전 자료 빼돌리기"가 불가능합니다.
REASON 04
USB / 클립보드 / 프린트 제한
VDI 정책으로 로컬-VM 간 파일 전송, 클립보드 복사, 프린트 출력을 차단할 수 있습니다. 화면 캡처도 차단하거나 워터마크를 강제 삽입할 수 있어 휴대폰 촬영을 추적할 수 있습니다.
REASON 05
완전한 감사 로그
모든 접속/명령/파일 접근이 서버에 기록됩니다. 누가 언제 어떤 파일을 열었는지 추적 가능하며, 보안 사고 발생 시 즉시 원인 파악이 가능합니다. 일반 PC 환경에서는 거의 불가능한 수준의 감사가 됩니다.
REASON 06
망분리 / 격리 강제
VM은 사내망과 외부망을 네트워크 수준에서 격리할 수 있습니다. 업무 VM에서는 인터넷이 안 되거나, 화이트리스트 사이트만 허용하는 식으로 운영 가능. 랜섬웨어가 들어와도 한 VM에 갇히고 다른 VM으로 확산되지 않습니다.
반대로 일반 PC 환경의 위험
직원 노트북에 기밀 파일이 저장되어 있으면 — 분실, USB 복사, 개인 메일 전송, 카페 Wi-Fi 도청, 가족·외부인의 사용 등으로 유출 경로가 너무 많습니다. 한국에선 산업기술보호법·개인정보보호법 위반 시 처벌이 매우 강해서 대기업은 VDI를 사실상 의무화하고 있습니다.

3. 사내망 보안 아키텍처 — 접속 시점의 보안

앞 장에서 " 클라우드(VDI) 환경이 보안에 유리한가"를 다뤘다면, 이번 장은 "어떻게 실제로 지켜지는가" — 즉 로컬 PC와 클라우드 사이에 어떤 보안 장치들이 겹쳐 있는지를 다룹니다. 취약점 점검 시 어느 계층을 봐야 하는지 판단하는 데 필요한 기초 지식입니다.

핵심 원칙 — 다층 방어 (Defense in Depth)
보안은 단 하나의 장치로 끝나지 않습니다. 여러 계층이 겹쳐 있어서 한 계층이 뚫려도 다음 계층이 막는 구조입니다. 공격자는 모든 계층을 차례로 돌파해야 데이터에 도달할 수 있고, 방어자는 어느 한 계층에서라도 탐지되면 차단할 수 있습니다.

3-1. 다층 방어 — 로컬 PC에서 데이터까지의 전체 흐름

로컬 PC에서 클릭 한 번이 일어났을 때, 그 신호는 다음 계층들을 순서대로 통과해야 사내 데이터에 닿을 수 있습니다. 각 계층에서 신원·내용·행동을 검증합니다.

① 로컬 PC (Endpoint) 백신 · EDR · DLP · 디스크 암호화(BitLocker) HTTPS / TLS 1.3 암호화 ② 암호화 통신 계층 (TLS / VPN) 인증서 검증 · 키 교환 · 대칭키 암호화 터널 ③ 방화벽 (Firewall / NGFW) IP · 포트 · 앱 단위 차단 (외부 → 사내 진입 1차 차단) ④ IDS / IPS (침입탐지 / 방지) 알려진 공격 패턴(시그니처) 탐지 · 자동 차단 ⑤ WAF (Web Application Firewall) SQL 인젝션 · XSS · 경로 조작 등 웹 공격 차단 ⑥ VPN 게이트웨이 / ZTNA 사내망 진입 단일 경로 · 등록된 기기만 통과 (NAC) ⑦ 인증 계층 (MFA · SSO · Zero Trust) 사번 + 비밀번호 + OTP/FIDO 키 + 디바이스 인증 ⑧ VDI 브로커 · 권한 확인 사용자 → 어떤 VM에 접근 가능한지 권한 부여 ⑨ VM 내부 보안 백신 · 화면 워터마크 · 클립보드 / USB 제한 · 감사 로그 ⑩ 중앙 데이터 · DB · 파일 서버 저장 시에도 암호화 (Encryption at Rest) 🔍 SIEM / SOC (통합 보안 관제) 모든 계층의 로그를 실시간으로 수집·분석 24/7 모니터링 이상 행동 탐지 시 즉시 알람 발송 → UEBA → SOAR 자동대응 → 계정 자동 잠금
그림 4. 로컬 PC → 데이터까지 거쳐가는 10개 보안 계층 — 우측 SIEM/SOC가 모든 계층을 동시에 감시

3-2. 네트워크 계층 — 방화벽 · WAF · IDS/IPS · 망분리

가장 바깥의 보안. 사내망 경계에서 트래픽을 검사·차단합니다.

장치 역할 구체적 예 / 비고
방화벽
Firewall
IP · 포트 단위 차단. 외부에서 들어오는 위험 포트 차단 외부에서 22(SSH), 3389(RDP) 직접 접근 차단
NGFW
차세대 방화벽
애플리케이션 단위 검사. 페이스북·유튜브 등 앱 자체 차단 가능 Palo Alto, Fortinet, Check Point
WAF
웹 방화벽
웹 요청 검사. SQL 인젝션 · XSS · 경로 조작 등 웹 공격 패턴 차단 Cloudflare WAF, AWS WAF, F5 ASM
IDS / IPS
침입탐지/방지
알려진 공격 패턴 탐지(IDS) / 즉시 차단(IPS). 시그니처 기반 + 일부 행동 기반 Snort, Suricata, Cisco Firepower
NAC
네트워크 접근 제어
등록된 기기 + 인증된 사용자만 사내망 접근 허용 MAC 주소 등록, 인증서 기반 (802.1X)
망분리
Network Segmentation
업무망과 인터넷망을 물리적 또는 논리적으로 분리 한국 금융권 · 공공기관 필수 (법으로 강제)
DDoS 방어 대규모 트래픽 공격 차단 AWS Shield, Cloudflare, NSHC
한국 특화 — 망분리(Network Segmentation)
한국은 「전자금융감독규정」「개인정보보호법」 등에 의해 업무망과 인터넷망의 분리가 강제됩니다.
  • 물리적 망분리: 업무용 PC 1대 + 인터넷용 PC 1대 (두 대 사용)
  • 논리적 망분리: 한 대 안에서 VDI/CBC(Computer Based Control) 등으로 분리
대기업은 비용 문제로 논리적 망분리(VDI) 방식을 주로 채택합니다.

3-3. 암호화 통신 — HTTPS · TLS · VPN

로컬 PC와 클라우드 사이의 통신은 반드시 암호화되어야 합니다. 그렇지 않으면 카페 Wi-Fi, 공유 네트워크 등에서 패킷 도청(스니핑)이 가능합니다.

HTTPS와 TLS의 관계

HTTPSHTTP over TLS의 줄임말입니다. 즉, HTTP 요청을 TLS 암호화 터널로 감싼 것입니다. TLS 연결을 만들 때 클라이언트와 서버는 다음 과정(TLS 핸드셰이크)을 거칩니다.

클라이언트 (브라우저) 로컬 PC 서버 (사내 게이트웨이) 데이터센터 ① Client Hello "TLS 1.3 사용 가능, 암호 스위트 목록" ② Server Hello + 인증서 "이 인증서가 내 신원이다 (CA 서명)" ③ 인증서 검증 · CA 신뢰 체인 확인 · 도메인 일치 · 만료일 확인 ④ 키 교환 (ECDHE) "공유 비밀키 생성을 위한 값 송신" ⑤ Finished (양쪽) "세션키 합의 완료, 암호화 시작" ⑥ 암호화된 통신 시작 (AES-GCM 등 대칭키 암호) 이후 모든 HTTP 요청/응답은 이 터널 안에서 암호화되어 전송
그림 5. TLS 핸드셰이크 — 6단계로 암호화 터널을 만들고 그 안에서 안전하게 통신

🤝 깊이 들어가기 — TLS는 어떻게 비밀을 합의하는가

앞 그림 5에서 "키 교환"이라고 적었는데, 자연스러운 의문이 듭니다 — 인터넷에서 처음 만난 두 컴퓨터가, 누군가 도청하고 있는 와중에, 어떻게 둘만 아는 비밀을 만들 수 있을까? 이걸 해결한 것이 비대칭 키 암호Diffie-Hellman 키 교환입니다.

핵심 아이디어
"비밀을 직접 보내거나 받지 않습니다."
대신 양쪽이 각자 자기 비밀을 가지고 공개적 정보를 주고받은 뒤, 독립적으로 똑같은 비밀을 계산해냅니다. 도청자는 공개된 정보를 다 봐도 비밀을 못 도출합니다.

1단계 비유 — 자물쇠 (비대칭 암호)

기존 자물쇠는 잠그는 열쇠 = 푸는 열쇠(대칭) → 미리 만나서 키를 공유해야 함. 비대칭 암호는 잠그는 키와 푸는 키가 다릅니다.

❌ 대칭 암호
🔑 = 🔑 같은 키로 잠그고 푸름
문제: 처음 만난 둘이 안전하게 키를 어떻게 공유?
→ 닭-달걀 문제
✅ 비대칭 암호
🔓 공개키 (잠금용, 누구나) ≠ 🔑 개인키 (서버만)
해결: 공개키로 잠그면 서버만 풀 수 있음
→ 미리 만날 필요 없음

2단계 비유 — 색깔 섞기 (Diffie-Hellman 키 교환)

실제 TLS는 더 똑똑한 방식인 Diffie-Hellman을 씁니다. 양쪽이 비밀을 직접 보내지 않고도 같은 비밀을 만들어냅니다. 색깔로 비유하면 직관적입니다.

사용자 (브라우저) 서버 ① 공개적 약속 (모두 봄) 기본값: 노랑 ② 비밀 색 고르기 비밀: 파랑 노랑 + 파랑 = 초록 (파랑은 비밀, 초록만 외부로) ② 비밀 색 고르기 비밀: 빨강 노랑 + 빨강 = 주황 (빨강은 비밀, 주황만 외부로) ③ 초록 보냄 (공개) ③ 주황 보냄 (공개) ④ 받은 색 + 자기 비밀 + = 갈색 → 세션 키 도출! ④ 받은 색 + 자기 비밀 + = 갈색 → 같은 세션 키! ⑤ 도청자가 본 것: 노랑 · 초록 · 주황 (다 공개됨) → 그러나 비밀 파랑 · 빨강 모르므로 갈색 도출 불가능 ✓
그림 6. Diffie-Hellman 키 교환 — 양쪽이 비밀을 직접 안 보내고도 같은 세션 키를 도출

실제로는 색깔 대신 큰 소수 또는 타원곡선의 점을 쓰고, 섞는 건 모듈러 거듭제곱이나 점 곱셈입니다. 핵심은 "섞기는 쉽지만 분리(역연산)는 계산적으로 불가능"이라는 일방향 함수의 성질입니다.

합의의 전체 과정 — 누가 무엇을 정하는가

합의 항목 누가 정하나 어떻게
암호 알고리즘
(cipher suite)
클라이언트 ↔ 서버 협상 ClientHello에 "지원 가능 목록" → ServerHello에 "하나 선택" (예: AES-GCM)
서버 신원 보증 CA(인증기관)이 미리 "이 공개키 = 이 서버"를 인증서에 디지털 서명
인증서 검증 클라이언트(브라우저/OS) 미리 설치된 루트 CA 목록으로 서명 체인 검증
세션 키 도출 양쪽이 독립적으로 계산 Diffie-Hellman으로 같은 비밀 도출 — 비밀 자체는 절대 안 보냄
본 통신 암호화 양쪽이 도출된 세션 키 사용 대칭 암호(AES-GCM 등)로 빠르게 암호화
CA(인증기관)는 왜 꼭 필요한가

Diffie-Hellman만 있으면 중간자 공격(MITM)에 무방비입니다. 공격자가 "내가 google.com이야" 하면서 자기 DH 값을 보내면 사용자가 그대로 믿어버립니다. 그래서 "이 DH 값을 보낸 서버가 진짜 그 서버"임을 보증해주는 제3자가 필요합니다 — 그게 CA.

브라우저/OS에는 신뢰하는 루트 CA 목록(Let's Encrypt, DigiCert, GlobalSign 등)이 미리 깔려 있어 그 체인으로 검증합니다. 회사 SSL Inspection이 작동하는 이유도 똑같습니다 — 회사 CA를 직원 PC에 미리 깔아두면, 그 CA가 발급한 가짜 인증서도 "정상"으로 보여 트래픽을 풀어낼 수 있습니다.

핵심 인사이트 — 왜 TLS는 천재적인가
  • 비대칭 암호는 안전하지만 매우 느림 (대용량 데이터에 부적합)
  • 대칭 암호는 빠르지만 키 공유 문제가 있음
  • TLS의 해결책: 비대칭 암호로 세션 키만 안전하게 합의 → 그 세션 키로 빠른 대칭 암호로 본 통신
  • Perfect Forward Secrecy (PFS): 매 세션마다 새 DH 키 생성(ECDHE) → 나중에 개인키가 유출돼도 과거 통신은 풀리지 않음
  • 그래서 답: "누가 합의하는가"의 답은 "양쪽이 각자 계산해서 같은 결과에 도달한다 + CA가 신원을 보증한다"
⚠ 취약점 점검 포인트 — 암호화 통신
  • 오래된 TLS 버전 (TLS 1.0/1.1) 허용 시 — POODLE, BEAST 등 공격에 취약. TLS 1.2 이상만 허용해야 함
  • 약한 암호 스위트 허용 (RC4, 3DES, MD5) — 키 도출 공격 가능
  • 자체 서명 인증서를 "예외 허용"으로 운영 시 — 중간자 공격(MITM) 가능성 매우 큼
  • 인증서 만료 / 도메인 불일치 — 사용자가 경고를 무시하는 습관이 생기면 진짜 공격을 못 알아챔
  • HSTS 미설정 — 첫 접속 시 HTTP로 우회 가능 (SSL Strip 공격)
  • 인증서 핀닝(Pinning) 부재 — CA 침해 시 위조 인증서 통과

VPN과 SSL 터널

외부(재택근무 등)에서 사내망 접속 시 VPN으로 회사 네트워크까지 암호화 터널을 만듭니다.

VPN 종류 특징
IPSec VPN 네트워크 계층(L3) 암호화. 표준 · 성능 좋음. 사이트 간 연결에 강함
SSL/TLS VPN 웹 브라우저로 접속. 클라이언트 설치 부담 적음 (OpenVPN, Cisco AnyConnect 등)
WireGuard 최신 · 가볍고 빠름. 코드 베이스가 작아 감사하기 쉬움. 점차 채택 증가
ZTNA / SDP
Zero Trust Network Access
VPN의 대체. "한 번 들어오면 다 보이는" 평면 네트워크가 아니라, 요청마다 권한 검증

3-4. 인증 — ID/PW · MFA · SSO · Zero Trust

네트워크와 암호화를 통과해도 "누구냐"를 확인하는 인증을 통과해야 합니다. 최근 보안 표준은 단순 ID/PW에서 다중인증(MFA)Zero Trust로 빠르게 옮겨가고 있습니다.

사용자 (로컬 PC) 홍길동 인증 서버 (IdP) SSO · Okta · ADFS 2차 인증 수단 휴대폰 OTP / 보안키 ① ID + 비밀번호 ② PW 해시 검증 (통과 → OTP 발송) ③ OTP 발송 (Push/SMS) ④ OTP 표시 "123456" (30초 유효) ⑤ 사용자가 OTP 확인 ⑥ OTP 입력 전송 ⑦ 세션 토큰 발급 (JWT/Kerberos 등)
그림 7. MFA 인증 흐름 — ID/PW만 알아도 OTP 단계에서 막힘 (비밀번호 유출만으로는 접근 불가)
방식 설명 보안 수준
ID + PW 가장 기본. 단독 사용은 위험 — 비밀번호 유출 시 즉시 침해
MFA / 2FA
다중 인증
OTP, FIDO 보안키, 생체인증 등 2개 이상 요소로 인증 ★★★
SSO
Single Sign-On
한 번 로그인으로 여러 시스템 접근. SAML/OAuth/OIDC 사용 ★★ (편의 ↑)
PAM
관리자 권한 관리
관리자 계정 별도 관리 · 일회용 권한(JIT) · 세션 녹화 ★★★★
Zero Trust "한 번 인증하면 끝"이 아니라 매 요청마다 인증·권한·디바이스 검증 ★★★★★ (현재 표준)
⚠ 취약점 점검 포인트 — 인증
  • SMS OTP만 사용 시 — SIM 스와핑 공격 가능 (FIDO 보안키 권장)
  • OTP 재사용 가능 시 — 한 번 노출되면 시간 안에 재사용 가능
  • 세션 토큰 탈취 시 무방비 — 토큰 짧은 유효 시간 + 디바이스 바인딩 필요
  • 퇴사자 계정 미정리 — 휴면 계정이 공격 통로가 됨
  • 관리자 계정 일반 사용 — 관리자가 평소 업무에 관리 계정 쓰면 침해 영향 확대
  • 비밀번호 정책 부재 — 짧거나 사전 단어 허용, 재사용 허용

3-5. 엔드포인트 보안 — 백신 · EDR · DLP · MDM

네트워크와 인증을 모두 통과한 뒤, VM 또는 로컬 PC 안에서 일어나는 일을 감시하는 보안입니다.

장치 역할
백신 / 안티바이러스 알려진 악성코드 시그니처 매칭. 1차 방어선이지만 신규/변종에는 한계
EDR
Endpoint Detection & Response
행동 기반 탐지 — 새로운/변종 악성코드도 의심 행동(파일 대량 암호화, 비정상 프로세스, 권한 상승)으로 탐지
예: CrowdStrike Falcon, SentinelOne, V3 EDR, MS Defender for Endpoint
DLP
Data Loss Prevention
중요 데이터(주민번호, 카드번호, 기밀문서) 외부 유출 차단. USB 복사 · 메일 첨부 · 웹 업로드 · 클립보드 감시
MDM
Mobile Device Management
회사 모바일 기기 관리. 분실 시 원격 초기화, 앱 설치 제한, 카메라 차단
워터마크 · 화면 보안 VDI 화면에 사번 + 시간 워터마크 강제 삽입 → 휴대폰 촬영 시 유출자 추적 가능
FDE
Full Disk Encryption
디스크 전체 암호화 (BitLocker, FileVault). 도난 시 데이터 보호
패치 관리 (WSUS / SCCM) OS · 소프트웨어 보안 패치 자동 배포. 미패치 시스템이 가장 흔한 침해 경로

3-6. 모니터링 — SIEM · SOC · UEBA · SOAR

모든 계층의 로그는 한 곳에 모여 24시간 감시됩니다. 공격이 발생해도 빠르게 탐지·대응할 수 있도록 하는 "보안의 눈"입니다.

약어 / 풀네임 역할과 예시
SIEM
Security Information & Event Management
모든 서버·장비의 로그를 통합 수집·분석해 위협 패턴을 찾는 시스템.
대표 제품: Splunk · IBM QRadar · ArcSight · Microsoft Sentinel · Elastic Security
SOC
Security Operations Center
24×7 가동되는 보안관제센터. SIEM이 띄운 알람을 사람 분석가들이 분류·대응. "운영자가 있는 방"
예: 회사 SOC, MSSP(매니지드 보안), KISA 사이버위협 대응팀
UEBA
User & Entity Behavior Analytics
사용자별 평소 행동 패턴을 머신러닝으로 학습 → 평소와 다른 행동 발생 시 알람.
탐지 예: 새벽 3시 대량 다운로드 · 평소 안 가던 시스템 접근 · 다른 국가에서 동시 로그인
SOAR
Security Orchestration, Automation & Response
탐지된 사건에 대해 사람 개입 없이 자동 대응하는 시스템. SIEM·UEBA가 알람 → SOAR가 실행.
자동 대응 예: 의심 계정 자동 잠금 · 악성 IP 방화벽 자동 차단 · 격리 VLAN 이동
Threat Intelligence
위협 인텔리전스 피드
외부 보안 회사·기관이 정리해서 보내주는 "이건 악성이다" 리스트를 받아 SIEM·방화벽에 자동 반영.
피드 내용: 악성 IP · 악성 도메인 · 멀웨어 해시 · 알려진 공격자 시그니처
5개의 연결 흐름 — 누가 누구에게 일을 넘기나
  1. Threat Intelligence가 "이 IP는 악성" 정보를 SIEM에 전달
  2. SIEM이 모든 로그 + TI 정보를 비교하며 알람 생성
  3. UEBA가 평소 행동에서 벗어난 사용자를 별도로 SIEM에 보고
  4. SOC의 분석가들이 알람을 보고 진짜 위협인지 판단
  5. SOAR가 확정된 위협에 대해 자동 차단·격리·알림 실행

3-7. 취약점 점검 시 봐야 할 영역

보안 구조를 알았으니, 이제 어디가 약할 수 있는지를 정리합니다. 취약점 점검(보안 진단)을 수행할 때 다음 영역을 우선 확인하세요.

사내 데이터 ① 피싱 / 사회공학 이메일 위장 · QR 피싱 최대 침해 통로 (60%+) ② 인증 우회 SIM 스와핑 · 세션 탈취 토큰 재사용 ③ 중간자 공격 (MITM) 취약 TLS · 위조 인증서 악성 Wi-Fi ④ 미패치 취약점 OS · SW · 펌웨어 CVE 기반 익스플로잇 ⑤ 인사이더 위협 퇴사자 · 협력업체 권한 남용 ⑥ 화면 촬영 휴대폰 · 카메라 VDI도 우회 가능 ⑦ 공급망 공격 3rd-party SW · 라이브러리 업데이트 채널 침해 ⑧ 설정 오류 방화벽 규칙 · 권한 과대 기본 비밀번호 방치
그림 8. 주요 공격 경로(Attack Surface) — 8가지 영역. 모든 경로가 결국 사내 데이터를 향함
CHECK 01
인증 / 권한
MFA 미적용 시스템 / 강제 PW 변경 부재 / 퇴사자 계정 잔존 / 관리자 계정 일반 사용 / SSO 세션 길이 과다 / 토큰 디바이스 바인딩 부재
CHECK 02
암호화 통신
TLS 1.0/1.1 허용 / 약한 암호 스위트 / 자체 서명 인증서 예외 / HSTS 미설정 / 인증서 만료 알람 부재 / 평문 프로토콜(HTTP, FTP, Telnet) 잔존
CHECK 03
네트워크 경계
방화벽 룰 검토 (Any-Any 룰 / 과도한 ALLOW) / 사용 안 하는 포트 개방 / DMZ 구성 적절성 / 망분리 우회 경로 / 무선망(Wi-Fi) 보안 (WPA3·EAP)
CHECK 04
엔드포인트
EDR 미설치 PC / 백신 시그니처 오래됨 / OS 패치 미적용 / USB 정책 우회 가능성 / 디스크 암호화 미적용 노트북
CHECK 05
VDI / 클라이언트
클립보드 / 프린트 / USB 차단 정책 우회 / 화면 캡처 차단 / 워터마크 적용 / 가상 채널 통한 데이터 유출 / 클라이언트 소프트웨어 무결성
CHECK 06
감사 로그 / 모니터링
로그 누락 영역 / SIEM 미연동 시스템 / 로그 보존 기간 / 로그 변조 방지 / 관리자 행동 감사 / 알람 응답 시간(MTTR)
CHECK 07
공급망 / 3rd-party
외주 직원의 사내 접근 권한 / 외부 협력사 VPN 권한 범위 / 오픈소스 라이브러리 취약점(SCA) / SW 업데이트 채널 무결성 검증
CHECK 08
인사이더 / 사회공학
DLP 정책 커버리지 / 직무분리(SoD) 적용 / 모의 피싱 훈련 실시 여부 / 특권 사용자 행동 분석(UEBA) / 출입 통제와 IT 시스템 연계
취약점 보고서 작성 시 권장 구조
  • 발견 사항 — 어떤 계층의 어떤 통제가 부족한가 (위 8가지 분류 활용)
  • 위험도 — CVSS 3.1 기준 점수 + 비즈니스 영향도
  • 증명(PoC) — 실제로 어떻게 악용 가능한지 (안전한 환경에서)
  • 권고 사항 — 보완책 (정책 / 기술적 통제 / 모니터링 강화 등)
  • 우선순위 — 즉시 / 단기(1개월) / 중장기(3-6개월) 분류
한국 환경에선 ISMS-P, ISO 27001, 전자금융감독규정의 통제 항목에 매핑하면 경영진 설득에 효과적입니다.

3-8. 실무 — 로컬 PC ↔ 클라우드 PC 간 새 포트 열기 ("이거 단순 방화벽 문제인가?")

전형적인 상황: 회사 노트북(로컬)과 사내 클라우드 PC(VDI/VM) 간 기본 통신(화면·키보드·마우스·클립보드)은 잘 됩니다. 그런데 내가 로컬에서 개발 서버를 열고 클라우드 PC에서 접속하려 하면 안 됨 (또는 반대 방향도 안 됨). IT 부서에 "방화벽 해제 요청"을 하면서 출발지 IP · 도착지 IP · 포트 번호를 적어 제출합니다.

결론부터 — 단순 방화벽 하나의 문제가 아닐 가능성이 높음
화면·키보드·마우스 같은 "VDI 기본 채널"은 회사가 미리 허용해둔 표준 포트(보통 443 또는 RDP/PCoIP/Blast 같은 정해진 포트)로 다닙니다. 반면 "내가 임의로 연 8080 포트"는 여러 보안 계층 어디서든 차단될 수 있습니다 — 경계 방화벽, 호스트 방화벽, NAT, VDI 채널 정책, 라우팅, 사내 망분리 정책 등. IT 부서가 "방화벽 룰 하나만 추가"한다고 끝이 아니라, 여러 통제를 동시에 풀어줘야 통신이 성립합니다.

막힐 수 있는 위치 — 한 패킷이 거치는 7+ 곳

로컬 PC → 클라우드 PC 트래픽이 거치는 모든 통제 지점 💻 로컬 PC (개발자) 예: 10.20.30.40 localhost:8080에 서버 실행 중 ☁️ 클라우드 PC (VDI/VM) 예: 192.168.100.20 curl http://10.20.30.40:8080 로컬 호스트 방화벽 Windows Defender Firewall · macOS pf · Linux iptables — 인바운드 기본 차단 NAT · 사설 IP 한계 로컬 PC가 사설 IP(10.x/192.168.x)면 외부에서 직접 접근 불가. 포트포워딩 또는 공인 IP 필요 회사 경계 방화벽 (NGFW) 출발지·도착지 IP·포트 기반 룰. 사용자가 신청해야 룰 추가됨 망분리 · VLAN 분리 개발망·업무망·VDI망이 분리됨. 망 간 통신은 별도 게이트웨이·정책 통과 필요 VDI / 클라우드 보안 그룹 하이퍼바이저·VPC의 Security Group이 VM 인바운드 차단 (AWS SG, Azure NSG 등) 클라우드 PC 호스트 방화벽 대상 VM의 OS 방화벽도 별도. 회사 GPO로 강제 차단된 경우 많음 서버 앱의 bind 주소 127.0.0.1(localhost)로만 바인딩하면 외부 차단됨 → 0.0.0.0으로 바인딩 필요 ⭐ 단 하나만 막혀도 통신 실패 "방화벽 룰 추가했는데 왜 안 되지?" → ①·⑥·⑦ 같은 PC 안 통제나 ④ 망분리, ⑤ 클라우드 SG 가 남아있는 경우 흔함

각 차단 지점 자세히

차단 지점 왜 막히나 / 풀려면
① 로컬 호스트 방화벽 Windows·macOS·Linux 모두 인바운드 기본 차단이 기본값. 내 PC에서 서버 열어도 OS 방화벽이 8080을 안 열어주면 외부 패킷이 못 들어옴. "포트 8080 허용" 룰 추가 필요 (또는 회사 GPO 변경)
② NAT · 사설 IP 사내망에서 노트북이 받은 IP(10.20.x.x 등)는 사설 IP라 다른 망에서 IP만으로 직접 못 옴. 회사망 안이면 보통 라우팅으로 해결되지만, VDI망과 사무망이 분리되어 있으면 직접 접근 불가. 포트포워딩 또는 점프 서버 필요
③ 회사 경계 방화벽 사용자가 신청해서 5-튜플 룰(프로토콜, 출발 IP, 출발 포트, 도착 IP, 도착 포트)을 추가해야 통과. 방화벽 해제 신청서가 이걸 위해 존재
④ 망분리 / VLAN 금융·대기업은 업무망 ↔ 개발망 ↔ VDI망이 별도 분리. L3 라우팅이 아예 없거나, 게이트웨이가 정해진 트래픽만 중계. 방화벽 룰만으론 안 됨 — 망분리 예외 신청도 필요할 수 있음
⑤ VDI · 클라우드 SG VDI 브로커·하이퍼바이저·VPC의 Security Group이 별도 인바운드 룰을 가짐 (AWS SG, Azure NSG, VMware NSX). 경계 방화벽과 다른 시스템. 클라우드 운영팀에 추가 신청 필요
⑥ 클라우드 PC 호스트 방화벽 VM 안의 OS 방화벽도 별도. 회사가 GPO·MDM으로 강제 차단해놓는 경우 많음 → 사용자가 못 풀고 운영팀이 푸시해줘야 함. "내 PC인데 왜 안 됨"의 흔한 원인
⑦ 서버 앱의 bind 주소 개발자 본인이 자주 놓치는 부분. 서버를 localhost(=127.0.0.1)로 바인딩하면 로컬에서만 접근 가능. 외부에서 받으려면 0.0.0.0(모든 인터페이스)으로 바인딩해야 함. 코드·설정 한 줄 문제, 가장 쉽게 자가 해결 가능

그래서 방화벽 해제 신청 시 무엇을 적어야 하나

5-튜플 + α — 신청서에 들어가야 할 정보
  • 프로토콜: TCP / UDP / ICMP
  • 출발지 IP: 어디서 시작하는 트래픽인지 (예: 로컬 PC IP 또는 IP 대역)
  • 출발지 포트: 보통 무관(any), TCP는 OS가 임의 할당
  • 도착지 IP: 어디로 가는 트래픽인지 (예: 클라우드 PC IP)
  • 도착지 포트: 서버가 listen 중인 포트 (예: 8080)
  • 방향: 양방향인지, 단방향인지 — 보통 inbound만 명시하면 응답은 자동
  • 사용 기간: 일시적인지 영구인지 (보안팀은 단기를 선호)
  • 사용 사유: 어떤 업무·도구 때문인지 (감사 추적용)
실무 팁 — 신청 전에 자가 점검
  1. 서버 bind 주소부터 확인0.0.0.0인지 127.0.0.1인지. netstat -ano | findstr 8080 (Win) / lsof -i :8080 (Mac/Linux)
  2. 로컬 호스트 방화벽 임시 끄고 테스트 — 권한이 있다면. 풀고 나서 통신되면 OS 방화벽이 범인
  3. traceroute로 경로 확인 — 어디서 패킷이 멈추는지. 예: tracert <클라우드 IP>
  4. 같은 망 내 다른 PC에서 시도 — 망분리/경계 방화벽 vs 호스트 방화벽 구분 가능
  5. 위 셀프 점검을 신청서에 적어두면 운영팀이 어디만 풀면 되는지 바로 안 보임 → 처리 속도 ↑
왜 보안팀이 까다롭게 굴까 — 정당한 이유
  • 한 번 열린 포트는 잊혀지기 쉬움 → 1년 뒤 누가 어떤 사유로 열었는지 모르고 그대로 남음 → 공격면
  • "로컬에서 서버 열기"는 멀웨어의 역방향 셸(Reverse Shell) 패턴과 구분 어려움
  • 한국 금융권은 전자금융감독규정에 따라 비표준 포트 사용을 엄격히 통제. 감사 대비 필수
  • 그래서 사용 기간·사유 명시 + 주기적 재신청 정책이 일반적

4. 연결 이후의 세션 보안 — Runtime 위협과 취약점

앞 장(섹션 3)은 "접속 시점"의 보안이었습니다 — 방화벽을 통과하고, TLS로 암호화하고, MFA로 인증해서 VM에 도착하기까지. 하지만 그 다음이 진짜 문제입니다. 세션이 만들어진 뒤에도 로컬과 클라우드 사이엔 끊임없이 데이터가 흐르고, 그 흐름의 모든 채널이 잠재적 공격 표면(Attack Surface)이 됩니다.

왜 "세션 중 보안"이 중요한가
한국 대기업 보안 사고의 상당수는 인증을 통과한 정상 사용자의 세션을 통해 발생합니다. 외부 해커보다 인사이더(내부자) + 세션 탈취 + 정책 우회 조합이 훨씬 많습니다. 취약점 점검 시 "이미 들어간 사람이 무엇을 할 수 있는가"를 보는 것이 가장 실질적인 위험 평가입니다.

4-1. 세션이 만들어진 뒤 무엇이 오가는가

VDI/RDP 세션에서 로컬과 클라우드 VM 사이엔 화면 픽셀 + 입력만 오가지 않습니다. 프로토콜 안에는 여러 개의 가상 채널(Virtual Channels)이 동시에 흐릅니다.

로컬 PC VDI 클라이언트 모니터 (화면 출력) 키보드 / 마우스 로컬 클립보드 USB 포트 (메모리, 키) 로컬 디스크 (C:) 로컬 프린터 스피커 / 마이크 스마트카드 / FIDO 웹캠 클라우드 VM 사내 데이터센터 화면 렌더링 사용자 입력 수신 VM 클립보드 가상 USB 매핑 매핑된 드라이브 가상 프린터 오디오 리디렉션 스마트카드 채널 웹캠 리디렉션 화면 픽셀 (압축) 키 / 마우스 입력 클립보드 (양방향 가능) USB 리디렉션 (정책) 드라이브 매핑 (정책) 프린트 작업 → 로컬 프린터 오디오 (양방향) 스마트카드 인증 채널 웹캠 (영상 회의용) ⚠ 모든 채널이 단일 TLS 터널 안에 다중화됨 — 네트워크 단에선 채널별 구분 불가
그림 9. 세션 중 흐르는 9개 가상 채널 — 각 채널이 잠재적 유출 경로

4-2. 가상 채널과 정책 — 어디까지 열어줄 것인가

각 가상 채널은 정책으로 열거나/단방향으로 제한하거나/완전 차단할 수 있습니다. 보안 수준은 채널 정책 설정에 크게 좌우됩니다.

채널 기능 권장 정책 (高보안) 위험
클립보드 로컬 ↔ VM 간 텍스트/이미지 복사 로컬→VM 단방향 (입력만)
또는 완전 차단
VM의 기밀 텍스트를 로컬에 붙여넣기로 유출
USB 리디렉션 로컬 USB 기기를 VM에 인식시킴 지정 기기(HID·스마트카드)만 허용 USB 메모리로 데이터 유출 / 악성 HID 키 인젝션
드라이브 매핑 로컬 C: 드라이브가 VM에 마운트 완전 차단 로컬-VM 간 파일 자유 이동 = 데이터 유출
프린트 리디렉션 VM에서 인쇄 → 로컬 프린터로 출력 차단 또는 워터마크/감사 로그 강제 출력물로 자료 반출 (DLP 우회)
오디오 리디렉션 VM 소리를 로컬 스피커로 출력 VM→로컬 단방향 (일반 업무)
차단 (고보안)
오디오 스테가노그래피로 데이터 유출 (드물지만 가능)
웹캠 리디렉션 로컬 웹캠 영상을 VM에 전달 화상회의 시에만 허용 VM 내 악성 SW가 로컬 카메라 도청
스마트카드 인증 토큰 채널 허용 (인증 필수) 채널 자체 취약점 (드물지만 패스스루 공격)
COM/LPT 포트 레거시 시리얼/병렬 포트 차단 대부분 불필요. 공격 표면 축소를 위해 차단
플러그앤플레이 임의 장치 자동 인식 차단 BadUSB · 러버덕키 등 공격 가능
⚠ 가장 흔한 정책 우회 시나리오
  • "읽기 전용 클립보드"라더니 이미지 채널은 열려 있음 — 텍스트는 막혔지만 스크린샷 → 이미지 붙여넣기로 우회
  • 드라이브 매핑은 막혀 있지만 OneDrive/Google Drive 동기화 폴더는 VM 안에서 접근 가능
  • 프린트는 막혔지만 PDF 가상 프린터로 파일 생성 → 다른 채널로 유출
  • USB는 막혔지만 블루투스 키보드/마우스는 열려 있음 — 데이터 입출력 가능

4-3. 세션 토큰 · 세션 하이재킹

MFA 인증을 통과하면 시스템은 세션 토큰(JWT, Kerberos 티켓, 쿠키 등)을 발급합니다. 이 토큰이 "인증된 상태"의 증명서 역할을 하기 때문에, 토큰만 탈취해도 비밀번호와 OTP 없이 세션을 가로챌 수 있습니다 — 이것이 세션 하이재킹입니다.

대표적 세션 공격 시나리오

공격 기법 설명
Pass-the-Cookie 로컬 브라우저에 저장된 세션 쿠키를 탈취 후 공격자 브라우저에 주입. MFA 우회됨.
Pass-the-Hash / Pass-the-Ticket Windows 환경에서 NTLM 해시 또는 Kerberos 티켓을 추출해 재사용. 비밀번호 없이 인증.
Token Replay 네트워크에서 탈취한 토큰을 다른 클라이언트에서 재사용 (디바이스 바인딩 없을 때).
Session Fixation 공격자가 미리 세션 ID를 생성 후 피해자에게 강제 → 피해자 로그인 후 같은 세션 공유.
Man-in-the-Browser 브라우저 확장/악성코드가 정상 세션 안에서 거래 조작 (은행 사기에 흔함).
Golden / Silver Ticket Active Directory 침해 시 영구 유효 티켓 발급. 가장 위험한 침해.
완화책 (Mitigations)
  • 짧은 토큰 유효 시간 + 자동 갱신 (예: 15분, 슬라이딩 윈도우)
  • 유휴 타임아웃 (Idle timeout) — 10~15분 무활동 시 자동 잠금
  • 절대 만료 (Max session) — 8시간 또는 근무시간 후 강제 재인증
  • 디바이스 바인딩 — 토큰을 발급된 기기에서만 사용 가능 (TPM, FIDO 결합)
  • IP/지리 기반 검증 — 갑자기 다른 국가에서 같은 토큰 사용 시 차단
  • 위험 기반 인증 (Risk-based auth) — 행동 변화 감지 시 재인증 요구
  • HTTPS-only + HttpOnly + SameSite + Secure 쿠키 속성 강제

4-4. 데이터 유출 경로 (Exfiltration Vectors)

이미 인증된 사용자(또는 그를 가장한 공격자)가 VM 내의 데이터를 외부로 빼내는 경로는 의외로 많습니다. 모든 경로에 통제가 있어야 의미가 있고, 한 곳이라도 뚫리면 전체가 무력화됩니다.

VM 안의 기밀 데이터 (설계도·고객정보) ① 클립보드 복사 VM → 로컬 텍스트 추출 ② 화면 캡처 PrintScreen · OBS · 매크로 ③ 휴대폰 촬영 기술적 차단 거의 불가 ④ 인쇄 (Print) 출력물로 종이 반출 ⑤ 이메일 / 메신저 외부 메일 · 협력사 채널 ⑥ HTTPS 터널링 웹 트래픽 위장 ⑦ DNS 터널링 DNS 쿼리에 데이터 인코딩 ⑧ 클라우드 동기화 개인 OneDrive · Google ↑↓ 8가지 유출 경로
그림 10. 인증된 세션에서 데이터가 빠져나갈 수 있는 8가지 경로
유출 경로 차단 방법 우회 가능성
① 클립보드 가상 채널 차단 · DLP 텍스트 패턴 매칭 이미지 클립보드 / 작은 단위로 쪼개기 / OCR 우회
② 화면 캡처 PrintScreen 후킹 · 클립보드 이미지 차단 · 캡처툴 프로세스 차단 가상화 SW의 화면 캡처 / 외부 카메라 / 매크로 자동화
③ 휴대폰 촬영 워터마크(사번+시간) 강제 / 보안 구역 출입 통제 / CCTV 기술적 차단 거의 불가능 — 운영·문화로 보완
④ 인쇄 VDI 프린트 채널 차단 · 인쇄 시 워터마크 강제 · 인쇄 감사 로그 PDF 가상 프린터 → 다른 경로로 유출 / 사진 촬영
⑤ 이메일 · 메신저 DLP가 첨부파일·본문 검사 · 외부 메일 차단 · 메신저 제한 암호화 압축 / 작은 단위 분할 / 외부 시스템 호출
⑥ HTTPS 터널링 SSL 인스펙션(MITM) · 화이트리스트 도메인 / Cloud Access Security Broker 인증서 핀닝 회피 / DoH (DNS over HTTPS) / 미허가 도메인
⑦ DNS 터널링 DNS 쿼리 길이 제한 · 비정상 DNS 패턴 탐지 · DNS 화이트리스트 저속이지만 끈질김 — 탐지 어려움
⑧ 클라우드 동기화 개인 클라우드 도메인 차단 (drive.google.com 등) · CASB 새 클라우드 서비스 등장 시 차단 누락 / 우회 도메인

🚧 깊이 들어가기 — 왜 회사 네트워크가 HTTPS 통신을 막는가

HTTPS 차단은 보안 입장에선 합리적이지만, 사용자 입장에선 가장 답답한 통제입니다. npm install도 안 되고, GitHub 일부도 안 되고, 새 도구는 며칠씩 신청해야 하고 — 일이 정말 힘들어집니다. 여기선 왜 막는지어떻게 일을 덜 답답하게 만들지를 정리합니다.

한 줄 요약
과거 HTTP 시대에는 방화벽이 트래픽 내용을 직접 볼 수 있었지만, 지금은 모든 트래픽이 HTTPS로 암호화돼서 방화벽이 안을 못 봅니다. "이게 정상 사이트인지, 데이터 유출인지, 멀웨어 C2인지" 구분 불가. 그래서 회사는 HTTPS를 (1) 완전 차단 / (2) 화이트리스트 / (3) 정중앙에서 풀어 검사(SSL 인스펙션) 중 하나로 다룹니다.

OSI 계층 관점 — 정확히 어디까지 보이고 어디부터 안 보이는가

"방화벽이 안을 못 본다"를 OSI 7계층으로 정확히 보면, TLS는 L4(TCP) 위에서 작동하며 L5 이상을 통째로 암호화합니다. 즉 L4까지는 평문 헤더로 그대로 보이고, L5부터가 암호화 영역입니다 — "L4~L6이 다 안 보이는 것"이 아니라, L4는 보이고 L5부터 안 보입니다.

❌ L7 Application (HTTP) URL 경로 · 헤더 · 요청/응답 본문 · 업로드 파일
❌ L6 Presentation 인코딩 · 압축 · 데이터 형식
⚠ L5 Session (TLS 영역) SNI(도메인명) · TLS 버전 · 인증서 — TLS 1.3+ECH면 SNI도 가려짐
▲▲▲ TLS 암호화 경계 (Encrypted Boundary) ▲▲▲
✅ L4 Transport (TCP) 포트 (443) · 연결 상태 · 시퀀스 번호
✅ L3 Network (IP) 출발지 / 목적지 IP 주소
✅ L1~L2 Physical / Data Link MAC 주소 · 물리 신호

핵심은 L7입니다. "이 사람이 GitHub에 무엇을 올리나", "다운로드 파일에 멀웨어가 있나", "/upload인가 /search인가" 같은 실제 콘텐츠가 안 보이기 때문에 DLP·AV·WAF가 무력화됩니다. L3/L4 단서만으론 "누가 어디로 연결됐다"는 알아도 "무엇을 가져갔다"는 알 수 없습니다. 그래서 회사는 둘 중 하나를 선택합니다 — (a) SSL Inspection으로 L7을 일부러 풀어내거나, (b) 화이트리스트로 도메인(L5 SNI) 자체를 제한하거나.

🤔 헷갈리기 쉬운 점 — "양 끝단 L7은 어차피 평문 아닌가?"

맞아요. 양 끝단 L7에서는 평문입니다.
TLS는 OSI 모델에서 송신측이 위→아래로 캡슐화할 때 L7 출력을 받아 L6에서 암호화합니다. 그 후 L5~L1을 거쳐 네트워크로 송출. 수신측은 거꾸로 L1→L4 헤더를 풀고 L6에서 복호화해서 L7에서 평문으로 처리합니다.

그래서 송신 PC의 L7과 수신 서버의 L7에서는 모두 평문이 보입니다. 문제는 중간 통과 지점(라우터·방화벽)이에요. 이 장비들은 양 끝단의 TLS 세션 키가 없으니 L4까지만 풀어볼 수 있고 L5 이상은 암호화된 덩어리로만 보입니다.
송신 끝단 → 중간 (방화벽) → 수신 끝단 — 각 위치에서 무엇이 보이나 📤 송신 PC (직원) 🛡️ 중간 방화벽·라우터 📥 수신 서버 (GitHub) 위→ 아래 캡슐화 아래 →위 역캡슐화 L7 🔓 평문 git push file.txt L7 ❌ 못 봄 암호화된 덩어리 L7 🔓 평문 POST /repo/file.txt L6 🔒 TLS 암호화 ⭐ 평문 → 암호문 L6 ❌ 못 봄 키 없음 L6 🔓 TLS 복호화 ⭐ 암호문 → 평문 L5 TLS 세션 키 보유 L5 ⚠️ SNI 일부만 L5 TLS 세션 키 보유 L4 TCP 헤더 (포트 443) L4 ✓ 포트·상태 보임 L4 TCP 헤더 제거 L3 IP 헤더 부착 L3 ✓ 출발·도착 IP L3 IP 헤더 제거 L2 MAC 헤더 부착 L2 ✓ MAC 보임 L2 MAC 헤더 제거 L1 비트 송출 L1 그대로 통과 L1 비트 수신 📤 송신 PC: L7 평문 → L6에서 TLS 암호화 → 그 뒤(L5~L1)는 모두 암호문 🛡️ 중간 방화벽: 키가 없으니 L4까지만 풀 수 있음. L5 이상은 암호화된 덩어리 📥 수신 서버: 자기 비밀키로 L6에서 TLS 복호화 → L7에 평문 ⭐ "중간에서 안 보인다 ≠ 어디에서도 안 보인다" — 끝단으로 자리를 옮기면 다시 보인다
⭐ 핵심 통찰 — 양 끝단 L7은 평문이 맞지만, 중간 통과 장비는 키가 없어 L7을 못 봅니다. 회사가 L7을 검사하려면 둘 중 하나:
  • SSL Inspection: 회사가 "중간이 아니라 끝단"으로 위장. 회사 인증서로 TLS를 일단 풀고, 검사한 뒤, 다시 자기 키로 재암호화
  • 엔드포인트 EDR/DLP: PC 안에 검사 소프트웨어 설치. PC 자체가 끝단이니 평문 상태에서 검사 가능 (요즘 트렌드)

예시: 회사 직원이 GitHub에 코드를 푸시할 때 무슨 일이 일어나나

위치 L7에서 무엇이 보이나?
① 직원 PC (송신 끝단) 모든 게 평문으로 보임. 사용자의 git push 명령, 어떤 파일을 푸시하는지, 커밋 메시지까지 다. 그래서 PC 안에 EDR/DLP를 두면 여기서 검사 가능.
② 회사 방화벽 (중간) L4까지만: "PC가 GitHub IP의 443 포트로 TLS 연결 중" 정도만. SNI까지 보면 "github.com"이라는 도메인 이름. 그 안의 리포지토리·파일·코드 내용은 일절 못 봄 → DLP가 작동 안 함.
③ 인터넷 라우터들 (중간) L3까지만: "패킷 IP를 보고 다음 홉으로 라우팅". TCP 상태도 거의 안 봄.
④ GitHub 서버 (수신 끝단) 모든 게 평문으로 보임. 자기 TLS 비밀키로 풀어서 "어느 사용자가, 어느 레포에, 어떤 코드를 푸시" 모두 확인 가능. 그래서 GitHub가 비밀번호 노출이나 악성 코드를 탐지·차단 가능.
⭐ 결론을 다시 한 번 — 사용자 질문에 직접 답하면
  • "수신 시 L6에서 비문이 다 풀린다"맞아요. 단, 수신측 끝단에서만. 중간 장비는 키가 없어 못 풉니다.
  • "송신 시 L6부터 암호화돼 안 보인다"맞아요. 송신측 끝단의 L7은 평문이지만, L6 TLS에서 암호화되어 그 뒤(L5→L1)는 모두 암호문.
  • "L7에서는 다 보일 것 같다""어디의 L7?"이 핵심. 양 끝단 L7은 평문, 중간 장비의 L7은 키가 없어 못 봄. "방화벽이 L7을 못 본다"는 건 중간 위치의 방화벽이라는 뜻입니다.
계층 검사 없이 할 수 있는 것 검사 없이 못 하는 것
L3 / L4
IP · 포트
IP 차단, 포트 차단 CDN처럼 IP 공유 시 부정확 / 거의 모든 트래픽이 443
L5 (SNI) 도메인 단위 차단·허용 — 현재 가장 흔한 방식 ("github.com 통과, dropbox.com 차단") TLS 1.3 + ECH 시 SNI도 가려짐 · DoH/DoT로도 우회 가능
L7 (HTTP 내용) 없음 — SSL Inspection 없으면 일체 불가 DLP(콘텐츠 검사) · AV(파일 스캔) · WAF(공격 패턴) · URL 단위 정책 — 모두 불가

차단 / 제한하는 6가지 이유

이유 설명
① 트래픽 95%+ HTTPS 공격 트래픽과 정상 트래픽이 시각적으로 동일. "그냥 통과"는 사실상 "전부 통과"
② DLP는 평문 필요 암호화된 채로는 "이 데이터에 주민번호·카드번호·기밀이 있다"를 검사 불가
③ 멀웨어 C2도 HTTPS 감염된 PC가 외부 공격자 서버와 통신해도 정상 웹사이트와 똑같이 보임 → 탐지 불가
④ 개인 클라우드 동기화 Dropbox · OneDrive · Google Drive · 카카오메일 모두 HTTPS. 데이터 유출 #1 경로
⑤ Shadow IT 차단 직원이 회사 몰래 쓰는 SaaS (예: 외부 ChatGPT에 사내 코드 붙여넣기) 통제 필요
⑥ 규제 준수 금융감독원·개인정보보호위가 데이터 흐름 검사를 사실상 의무화. 검사 못하면 규정 위반

회사가 HTTPS를 다루는 3가지 방식 — SSL 인스펙션(MITM)이 핵심

브라우저 (회사 PC) 🔑 회사 CA 인증서 미리 설치되어 있음 (IT가 PC 셋업 시) 회사 SSL Inspector / Proxy (중간에서 풀어 검사 — 합법적 MITM) ① 복호화 (회사 개인키) 암호문 → 평문으로 풀어냄 ② DLP 검사 기밀 데이터 · 주민번호 패턴 ③ 멀웨어 · 콘텐츠 필터 AV 스캔 · 카테고리 차단 ④ 정책 확인 화이트리스트 · 카테고리 ⑤ 재암호화 실제 사이트 인증서로 다시 암호화 → 모든 트래픽 SIEM에 기록 실제 사이트 (github.com) 🔑 실제 인증서 (공인 CA 서명) Let's Encrypt 등 HTTPS [회사 인증서] HTTPS [실제 인증서] ⚠ 브라우저는 회사 인증서를 "정상"으로 보기 때문에 경고 없이 통과
그림 11. SSL Inspection 동작 원리 — 회사 프록시가 중간에서 트래픽을 풀어 검사한 뒤 다시 암호화
방식 설명 일하기
① 완전 차단
(블랙리스트)
알려진 위험·비업무 사이트만 차단. 나머지는 통과 비교적 편함 (가끔만 막힘)
② 화이트리스트만 허용 등록된 도메인만 가능. 나머지는 모두 차단. 금융권·공공기관에 흔함 가장 답답 — 새 사이트마다 신청 필요
③ SSL 인스펙션 (MITM) 회사 프록시가 정중앙에서 풀어 검사 → 재암호화. 회사 CA 인증서를 PC에 미리 설치해야 작동. 대기업·중견기업의 표준 방식 대부분 통과 — 단, 일부 도구가 거부 (인증서 핀닝)

🛡️ 양 끝단 L7 가시성 — 왜 회사는 PC에 에이전트를 잔뜩 까는가

여기서 중요한 통찰이 하나 있습니다. TLS는 "이동 중(in transit)"에만 암호화이고, 양 끝단(송신 PC, 수신 서버)에선 L7이 평문입니다. 네트워크 중간에서 못 보면 송신 PC 자체에서 L7을 봐버리면 됩니다 — 이것이 엔드포인트 보안의 본질입니다.

📤 송신 PC (직원) ✅ L7 (HTTP) 평문 엔드포인트 에이전트가 가로챔 ⚙ TLS 암호화 시작 (여기부터 비밀) ✅ L4 TCP / L3 IP 평문 헤더로 외부 노출 설치된 에이전트 • EDR (행동 분석) • 엔드포인트 DLP • 백신 · 보안 키패드 • 브라우저 보안 확장 • 인쇄 · 클립보드 모니터 → L7 모두 보임 🌐 네트워크 경로 ❌ L7 (HTTP) 암호화 방화벽·WAF·IDS 아무도 못 봄 🔒 암호화된 바이트 (중간자가 못 풂) ✅ L4 TCP / L3 IP 방화벽이 라우팅·필터링 중간 장비가 할 수 있는 것 • 방화벽 (IP · 포트) • SNI 기반 도메인 차단 • SSL Inspection (풀어 보기) • IDS · 트래픽 양 분석 → L7은 풀어야만 보임 📥 수신 서버 (목적지) ✅ L7 (HTTP) 평문 서버측 보안이 다시 봄 ⚙ TLS 복호화 (서버가 풀어냄) ✅ L4 TCP / L3 IP 서버 NIC가 수신 서버측 보안 • WAF (요청 검사) • 서버 DLP • 앱 레벨 감사 로그 • API Gateway → L7 모두 보임
그림 12. L7 가시성 — 양 끝단에선 평문, 중간에선 암호화. 그래서 에이전트는 PC에 깔고, 검사는 서버에서 한다

그래서 회사 PC에는 EDR · DLP · 백신 · 보안 키패드 등 에이전트가 잔뜩 깔립니다. 네트워크에서 못 보는 L7을 PC에서 보기 위한 것입니다. SSL Inspection은 네트워크 중간에서 일부러 풀어 보는 방식이고, 엔드포인트 에이전트는 애초에 암호화되기 전 단계에서 가로채는 방식입니다.

엔드포인트에서 L7을 보는 보안 도구

도구 어디에 후킹 L7에서 보는 것
엔드포인트 DLP
Forcepoint · Trellix · Symantec
클립보드 · 파일시스템 · 브라우저 · 메일 클라이언트 API "어떤 파일을 어디로 업로드하나" — TLS 암호화 전에 가로챔
EDR
CrowdStrike · SentinelOne · V3
OS 커널 후킹 · 프로세스 syscall 어떤 프로세스가 어떤 파일을 읽고 쓰는지 · 메모리 안 데이터
브라우저 보안 확장
Netskope · Zscaler agent
브라우저 DOM · JavaScript 레벨 HTTPS 사이트에서 사용자가 입력 · 업로드하는 실제 내용
메일 보안 에이전트 Outlook · 메일 클라이언트 플러그인 메일 본문 · 첨부파일 (전송 전 검사)
인쇄 모니터링 Windows 인쇄 스풀러 어떤 문서를 인쇄하려 하는지 · 워터마크 강제 삽입
입력 / 화면 추적 OS API · 키보드 후킹 캡처 시도 탐지 · 키 입력 패턴 (RPA · 키로거 탐지)
핵심 정리 — L7을 보는 두 가지 방법
  • (A) 네트워크 중간에서 풀기 — SSL Inspection. 프록시가 인증서 트릭으로 L7 복호화 → 검사 → 재암호화
  • (B) 양 끝단에서 가로채기 — 엔드포인트 에이전트. 송신 PC의 앱·OS 레벨에서 L7이 아직 평문일 때 검사
  • 실무에선 둘 다 사용 — A는 알려진 도메인의 광범위 트래픽 검사에 강함, B는 클립보드·파일조작·로컬 행동 추적에 강함
  • A의 약점 — 인증서 핀닝 앱은 우회 (Slack · Signal · 모바일 뱅킹). 신규 도메인 누락
  • B의 약점 — 에이전트 미설치 · 비활성화 · 무력화 시 사각지대 발생
⚠ 취약점 점검 포인트 — 엔드포인트 사각지대
  • 에이전트가 안 깔린 PC가 있는가 — 신규 PC · 테스트 장비 · 협력업체 PC · OT 장비
  • 에이전트가 비활성화 가능한가 — 사용자가 끌 수 있거나, 관리자 권한 / 안전 모드로 우회 가능한지
  • BYOD 정책 — 개인 디바이스에 회사 에이전트 설치를 강제할 수 없을 때 어떻게 통제하는가
  • 에이전트 자체 무결성 — 공격자가 에이전트 바이너리를 변조하거나 신호를 차단할 수 있는가
  • 에이전트 우회 시나리오 — 가상머신 · Linux Live USB · 듀얼 부팅 등으로 에이전트를 우회 가능한가
  • 알람 처리 사슬 — 에이전트가 탐지해도 SIEM에 전달이 누락되거나 SOC가 무시하면 의미 없음 (MTTR 측정 필수)

실제로 일이 힘들어지는 구체적 사례

증상 원인 / 영향
개발 도구 인증서 오류 npm install · pip install · git clone · docker pull이 회사 CA를 신뢰하지 않아 실패. 도구별로 회사 CA 등록 필요
GitHub raw · CDN 일부 차단 README의 이미지나 raw 파일이 안 보이는 경우. CDN 도메인이 화이트리스트에 없을 때 자주 발생
인증서 핀닝 앱 거부 Slack · Signal · 일부 모바일 앱은 SSL 인스펙션을 감지하면 작동 거부 (보안 강화 앱일수록 더 그럼)
속도 저하 모든 요청이 프록시 검사를 거치므로 지연 발생. 큰 파일 다운로드 시 체감
QUIC / HTTP/3 차단 UDP 기반 신 프로토콜은 검사 어려워 아예 막힘 → 일부 사이트가 느리거나 안 열림
WebSocket 제약 일부 실시간 협업 도구·웹 IDE·라이브 알림이 차단됨
새 SaaS 사용 시마다 신청 IT 부서에 화이트리스트 신청 → 며칠 ~ 몇 주 소요. 빠른 의사결정이 어려운 환경
현실적 대응법 — 일을 덜 답답하게 만드는 방법
  • 화이트리스트 신청 절차 파악 — 양식 · 담당자 · 평균 소요 시간을 알아두고, 자주 쓰는 도메인은 일괄 신청
  • 개발자용 별도 망 / DMZ 요청 — 많은 대기업이 개발 영역엔 화이트리스트 완화 또는 별도 인터넷망 제공
  • 회사 CA 인증서 등록 — 사용하는 도구마다 회사 CA를 등록하면 인증서 오류가 사라짐
    • git config --global http.sslCAInfo /path/to/corp-ca.pem
    • npm config set cafile /path/to/corp-ca.pem
    • pip config set global.cert /path/to/corp-ca.pem
    • OS 인증서 저장소(Windows: 인증서 관리자, macOS: 키체인, Linux: /etc/ssl/certs)에 등록
  • 신청 시 이유 명확히 — "왜 필요한가 / 어떤 업무인가 / 대안 검토 여부"를 적으면 승인 빠름
  • 회사 라이선스 도구로 우회 — 외부 ChatGPT 대신 사내 LLM · 외부 GitHub 대신 사내 GitLab · 외부 Slack 대신 사내 메신저
  • ⚠ 금지된 우회는 절대 금물 — 개인 핫스팟 · 개인 VPN · DoH(DNS over HTTPS) · Tor 등으로 회사 정책을 우회하면 징계 사유입니다. EDR · SIEM · NAC에 모두 기록되며 적발 시 인사 조치까지 갑니다.
왜 보안팀은 이렇게까지 막는가
보안팀이 답답하게 막는 이유는 직원을 괴롭히려는 게 아니라 한 명의 실수가 회사 전체를 위험에 빠뜨릴 수 있기 때문입니다. 국내 정보 유출 사고의 상당수가 HTTPS 채널을 통해 발생하며, 한 번의 유출로 수십~수백억 원의 손실과 브랜드 신뢰 타격이 발생합니다. 보안팀 입장에선 "모르는 트래픽은 일단 차단"이 합리적 선택입니다. 답답하더라도 "왜 막는가"를 이해하고 합법적 절차로 풀어내는 것이 결국 가장 빠르고 안전한 길입니다.

4-5. 화면 보호 — 캡처 차단 · 동적 워터마크 · 촬영 추적

화면 자체가 데이터이므로, 화면을 어떻게 보호하느냐가 매우 중요합니다. 세 가지 통제가 일반적입니다.

1) 화면 캡처 차단

2) 동적 워터마크

화면에 사번 + 시간 + IP를 반투명으로 항상 표시. 휴대폰으로 찍어도 누가 언제 찍었는지 추적 가능.

3) 촬영 행위 자체의 탐지

⚠ 화면 보호의 한계
모든 캡처 차단은 로컬 PC의 클라이언트 소프트웨어에 의존합니다. 클라이언트 SW가 변조되거나 다른 OS(Linux 라이브 USB 등)로 부팅된 채 접속하면 보호가 무력화됩니다. 따라서 클라이언트 무결성 검증이 반드시 함께 있어야 합니다 (TPM 기반 attestation, 인가된 단말만 접속).

4-6. 키로깅 · 입력 보안

중요한 함정: 로컬 PC에 키로거가 있으면, 비록 VM은 안전해도 세션 안에서 입력한 비밀번호·민감정보가 로컬 PC에서 탈취됩니다. 세션의 강력한 암호화도 이 단계에서는 의미가 없습니다 — 키 입력은 암호화 전 단계에서 잡히기 때문입니다.

위협 완화책
소프트웨어 키로거 EDR로 후킹 탐지 · 보안 키패드(가상 키보드) · 입력 암호화 SW (안랩 보안키보드 등)
하드웨어 키로거 USB 사이에 끼우는 물리 장치 — 물리 보안이 유일한 답 (CCTV, 정기 점검)
BadUSB / 러버덕키 USB로 위장한 키 인젝션 공격 — USB 정책으로 차단 + HID 화이트리스트
화면 키 노출 비밀번호 입력 시 •••• 마스킹 + 어깨너머 시청(Shoulder surfing) 방지
화면 매크로 RPA · 매크로 도구가 자동 입력 → UEBA로 비정상 속도 탐지

4-7. 세션 중 모니터링 — UEBA · DLP · PAM 녹화

세션이 살아 있는 동안 사용자의 모든 행동은 지속적으로 감시됩니다. "들어왔으니 끝"이 아니라 "들어와서 무엇을 하는가"를 보는 것이 현대 보안의 핵심입니다.

주요 감시 기법

UEBA 탐지가 잘 잡는 이상 패턴 예시
  • 평소 오전 9시~6시 접속 사용자가 새벽 3시에 접속
  • 평소 100MB/일 다운로드 → 갑자기 10GB 다운로드
  • 평소 사용하던 5개 시스템 → 갑자기 30개 시스템 접근
  • 평소 한국 IP → 갑자기 동남아 IP로 접속 (Impossible Travel)
  • 평소 일정한 타이핑 속도 → 갑자기 매크로 수준의 빠른 입력
  • 퇴사 통보 후 갑자기 다운로드 증가 — 가장 흔한 인사이더 패턴

4-8. 하이퍼바이저 · VM 격리 위협

VM은 강력하게 격리되어 있지만 완전 무결하진 않습니다. 같은 물리 서버 위의 다른 VM이나 하이퍼바이저 자체를 공격하는 방법이 존재합니다.

위협 설명
VM Escape
(하이퍼바이저 탈출)
VM 내부에서 하이퍼바이저 또는 호스트로 권한 상승. 매우 드물지만 발생 시 전체 호스트 침해. CVE-2018-12126 (L1TF), CVE-2017-4934 등
Cross-VM 사이드 채널 같은 호스트의 다른 VM의 캐시/메모리 패턴 관찰로 정보 추출. Spectre/Meltdown(CVE-2017-5715/5754), L1TF, ZombieLoad
VM Sprawl 관리되지 않는 잊혀진 VM이 남아 있어 패치 누락 / 침해 거점 / 자원 낭비
스냅샷 유출 VM 디스크 스냅샷 파일을 백업 서버에서 빼낼 경우 — VM 내부 전체 노출
관리 인터페이스 침해 vCenter, Hyper-V Manager 등 관리 콘솔 침해 시 모든 VM 통제 가능
가상 네트워크 공격 같은 가상 스위치의 VM 간 트래픽 스니핑 / VLAN 호핑
⚠ 점검 포인트 — 하이퍼바이저 계층
  • 하이퍼바이저 펌웨어/마이크로코드 패치 최신성 (CPU 사이드 채널 대응)
  • vCenter 등 관리 콘솔 접근 권한 — MFA 필수, IP 화이트리스트
  • 스냅샷/백업 파일 암호화 및 접근 통제
  • 관리 네트워크와 업무 네트워크 분리 (Management VLAN 격리)
  • VM 간 트래픽 마이크로세그멘테이션 (NSX, VMware NSX 등)
  • 잊혀진 VM 정리 절차 (VM Lifecycle Management)

4-9. 세션 종료 · 후처리 보안

세션이 끝나는 시점도 보안의 중요한 부분입니다. 흔히 간과되지만 취약점이 자주 발견되는 영역입니다.

자주 발견되는 후처리 취약점
  • 로그아웃 후에도 서버 측에서 토큰이 유효 → Pass-the-Cookie로 재사용 가능
  • VM은 종료됐지만 디스크 이미지에 임시 데이터 잔존 (논리적 삭제만)
  • 인쇄 스풀 파일이 로컬 PC에 남아 있음
  • 브라우저 캐시에 민감 데이터 잔존 (Cache-Control 미설정)
  • 세션 녹화 파일의 접근 권한 과대 (관리자 외 열람 가능)

4-10. 세션 중 취약점 종합 체크리스트

취약점 점검 보고 시 다음 항목을 "인증 후 세션 영역"으로 분류해 정리하시면 좋습니다.

SESS 01
가상 채널 정책
클립보드 / USB / 드라이브 매핑 / 프린트 / 오디오 / 웹캠 / 스마트카드 각각의 정책 검토. "읽기 전용 클립보드"로 설정됐어도 이미지·파일 채널이 열려 있지 않은지 확인.
SESS 02
세션 토큰 보안
토큰 유효 시간 / 유휴 타임아웃 / 디바이스 바인딩 / IP-Geo 검증 / 위험 기반 재인증. Pass-the-Cookie · Pass-the-Hash 가능성.
SESS 03
데이터 유출 차단
8개 유출 경로(클립보드, 화면 캡처, 휴대폰 촬영, 인쇄, 메일/메신저, HTTPS 터널, DNS 터널, 개인 클라우드) 각각의 통제 적용 여부.
SESS 04
화면 보호
PrintScreen 차단 · 동적 워터마크(사번+시간) · 캡처 SW 차단 · 클라이언트 무결성 검증. 대체 OS 부팅(Linux Live USB)으로 우회 가능한지 확인.
SESS 05
키로깅 / 입력
로컬 PC EDR 적용 / 보안 키패드 사용 / USB HID 화이트리스트. BadUSB · 러버덕키 차단.
SESS 06
실시간 모니터링
UEBA 적용 / DLP 패턴 커버리지 / PAM 세션 녹화 / 명령어 감사 로그 / 파일 액세스 로그 / outbound 트래픽 분석.
SESS 07
하이퍼바이저 격리
CPU/펌웨어 패치 최신성 / vCenter MFA / 스냅샷 암호화 / 관리망 분리 / 마이크로세그멘테이션 / 잊혀진 VM 정리.
SESS 08
세션 종료 처리
토큰 즉시 무효화 / 비영구 VM 초기화 / 로컬 캐시 삭제 / 인쇄 스풀 정리 / 세션 녹화 파일 접근 통제.
실전 점검 시 권장 순서
  1. 정책 문서 확인 — VDI 정책서, 가상 채널 설정, 토큰 정책
  2. 실제 설정 검증 — 정책서와 실제 시스템 설정이 일치하는지 (자주 다름)
  3. 우회 시도 — 통제된 환경에서 클립보드/스크린샷/인쇄 우회 시도
  4. 로그 검토 — 우회 시도가 SIEM에 잡혔는지, 알람이 작동했는지
  5. 대응 시간 측정 — 의심 행동 발생부터 SOC 대응까지 시간(MTTR)
  6. 인사이더 시나리오 — 정상 사용자가 악의로 작동한다고 가정한 시나리오 테스트

5. 가상머신 (Virtual Machine, VM)

5-1. 가상머신이란?

가상머신은 하나의 물리 컴퓨터 위에 소프트웨어로 만들어진 또 하나의 컴퓨터입니다. 마치 컴퓨터 안에 컴퓨터가 들어 있는 것처럼 동작합니다.

① 물리 서버 하드웨어 (CPU · RAM · 디스크 · 네트워크) ② 하이퍼바이저 (Hypervisor) 자원을 쪼개서 각 VM에 나눠주는 관리자 — VMware ESXi / Hyper-V / KVM ③ VM 1 애플리케이션 라이브러리 Guest OS Windows 10 ③ VM 2 애플리케이션 라이브러리 Guest OS Ubuntu 22.04 ③ VM 3 애플리케이션 라이브러리 Guest OS CentOS 9 물리 서버 한 대 위에 여러 가상 컴퓨터가 동시에 존재
그림 13. 가상머신 아키텍처 — 하드웨어 위에 하이퍼바이저, 그 위에 각각의 게스트 OS를 가진 VM들이 동시 실행

하이퍼바이저(Hypervisor)의 두 종류

5-2. 클라우드 컴퓨터 = 가상머신?

결론
네, 거의 같습니다. 대부분의 클라우드 컴퓨터는 가상머신 기술로 만들어집니다. AWS의 EC2, Azure의 Virtual Machine, 네이버 클라우드의 Server 모두 VM입니다. 즉, 클라우드 컴퓨터를 구현하는 기술적 실체가 가상머신이라고 보시면 됩니다.

가상머신의 장단점

장점 단점
완전한 격리 (한 VM이 죽어도 다른 VM 영향 없음) 무거움 — 각 VM이 OS 통째로 가짐 (수 GB)
서로 다른 OS 동시 실행 가능 (Windows + Linux) 부팅 느림 (수십 초 ~ 수 분)
강력한 보안 격리 (하드웨어 수준 분리) CPU / 메모리 오버헤드 큼

6. 도커(Docker)와 컨테이너(Container)

6-1. 컨테이너란?

컨테이너는 가상머신보다 훨씬 가벼운 격리 단위입니다. OS 전체를 복제하지 않고, 호스트 OS의 커널을 공유하면서 애플리케이션과 그 실행에 필요한 라이브러리만 패키징합니다.

도커(Docker)는 컨테이너를 만들고 실행하기 위한 대표적인 도구/플랫폼입니다. 즉, "컨테이너 = 개념, 도커 = 그 개념을 쉽게 다루게 해주는 소프트웨어"로 기억하시면 됩니다.

① 물리 서버 하드웨어 ② 호스트 OS (Linux 커널) — 모든 컨테이너가 공유 ③ 도커 엔진 (Docker Engine) ④ 컨테이너 1 Nginx (웹 서버) + 필요한 라이브러리 ④ 컨테이너 2 Node.js (API) + 필요한 라이브러리 ④ 컨테이너 3 PostgreSQL (DB) + 필요한 라이브러리 컨테이너는 OS 커널을 공유 — 매우 가볍고 빠르게 시작
그림 14. 도커 컨테이너 아키텍처 — 컨테이너마다 OS를 가지지 않고 호스트 커널을 공유

비유로 이해하기

🏢 가상머신 (VM)
"아파트 한 채를 통째로 짓는 것"
자기만의 기둥, 전기, 수도, 부엌, 거실, 화장실 — 전부 따로 가짐. 강하지만 무거움.
🏠 컨테이너 (Docker)
"한 건물 안에서 방만 나눠 쓰는 것"
전기·수도(커널)는 공유하고, 방 안의 가구(앱+라이브러리)만 자기 것. 가볍고 빠름.

6-2. 가상머신 vs 컨테이너 비교

🏢 가상머신 구조 Hardware Hypervisor App Libs Guest OS (통째로) App Libs Guest OS (통째로) App Libs Guest OS (통째로) 🏠 컨테이너 구조 Hardware Host OS (Kernel) ← 공유 Docker Engine App (Nginx) Libs App (Node) Libs App (PG) Libs ↑ Guest OS 없음 (호스트 커널 공유)
그림 15. VM과 컨테이너의 구조 차이 — VM은 각자 게스트 OS가 있고, 컨테이너는 호스트 커널을 공유
항목 가상머신 (VM) 컨테이너 (Docker)
격리 수준 하드웨어 수준 (강력) 프로세스 수준 (상대적으로 약함)
OS 각자 게스트 OS 통째로 호스트 OS 커널 공유
크기 수 GB 수십 MB ~ 수백 MB
시작 시간 수십 초 ~ 수 분 1초 이내
자원 사용 무거움 (큰 오버헤드) 가벼움
OS 자유도 자유 (Windows + Linux 동시) 호스트와 같은 종류의 커널 필요
보안 격리 매우 강함 상대적으로 약함
주 용도 서버 통합 · VDI · 이종 OS 실행 앱 배포 · 마이크로서비스 · CI/CD
실무 팁
실제 회사에선 둘을 같이 씁니다. 보통 VM으로 큰 단위 격리를 만들고, 그 안에서 컨테이너로 앱을 띄우는 2단 구조입니다.

예: 물리서버 → 하이퍼바이저 → VM(Ubuntu) → 도커 엔진 → 컨테이너 여러 개

7. 클라우드 저장소 vs 클라우드 컴퓨터

결론
완전히 다른 개념입니다. 둘 다 "클라우드"라는 단어를 쓰지만 제공하는 서비스 종류가 다릅니다.

클라우드 저장소 = 인터넷 너머의 창고/USB
클라우드 컴퓨터 = 인터넷 너머의 실제 컴퓨터 한 대
☁️ 클라우드 저장소 (Google Drive, Dropbox, S3 등) 파일 저장소 (디스크 공간) ▸ 할 수 있는 것: 업로드/다운로드/공유 ▸ OS 없음 · 프로그램 실행 불가 결제: GB 단위 용량 (예: 100GB / 월) 분류: Storage as a Service 💻 클라우드 컴퓨터 (AWS EC2, Azure VM, 네이버 클라우드 등) OS + 프로그램 CPU · RAM · 디스크 ▸ 할 수 있는 것: 모든 프로그램 실행 ▸ OS 있음 · 개발/서비스 운영 가능 결제: CPU·RAM × 사용 시간 분류: IaaS (Infrastructure as a Service)
그림 16. 저장만 하는 서비스 vs 연산까지 하는 서비스 — 본질적으로 다른 두 서비스
구분 클라우드 저장소 클라우드 컴퓨터
제공하는 것 파일을 저장할 공간 실행 가능한 컴퓨터 한 대
할 수 있는 일 파일 업로드 / 다운로드 / 공유 프로그램 설치, 코드 실행, OS 사용
OS 있나? 없음 (그냥 디스크) 있음 (Windows / Linux 등)
예시 Google Drive, Dropbox, iCloud, AWS S3, OneDrive AWS EC2, Azure VM, 네이버 클라우드 Server, VMware Horizon
결제 단위 GB 단위 저장 용량 CPU 코어 × 시간 · RAM · 사용 시간
XaaS 분류 Storage as a Service IaaS (Infrastructure as a Service)

물론 클라우드 컴퓨터 안에도 디스크는 있고, 클라우드 저장소를 클라우드 컴퓨터에 마운트해서 같이 쓸 수도 있습니다. 하지만 본질적으로 저장만 하는 서비스연산까지 하는 서비스는 다릅니다.

8. 한국 대기업 VDI 구조 예시

실제 한국 대기업이 사내 PC를 클라우드(VDI)로 운영할 때의 전체 구조입니다.

① 직원 노트북 (씬 클라이언트 — 데이터 없음) TLS 암호화 + RDP/PCoIP ② VPN / 접속 게이트웨이 외부 접속의 단일 진입점 ③ VDI 브로커 사용자 인증 (사번 + 2FA) ④ VM 풀 (Pool) VM-001 홍길동 (Windows 10) VM-002 김철수 (Windows 10) VM-N ... (직원 수만큼) ⑤ 중앙 파일 서버 / DB 모든 데이터는 여기에만 저장 (사내망 격리)
그림 17. 한국 대기업의 VDI 구조 — 직원 노트북에는 데이터가 없고, 모든 작업이 사내 데이터센터 안에서 일어남
핵심 보안 원리
직원 노트북에는 데이터가 한 줄도 저장되지 않으며, 화면 픽셀과 입력 신호만 오갑니다. 이것이 한국 대기업이 클라우드(VDI)로 보안을 운영하는 핵심 원리입니다.

9. 한 줄 요약

  • 클라우드 컴퓨터 — 데이터센터에 있는 가상 컴퓨터를 인터넷으로 빌려 쓰는 것
  • 가상머신 (VM) — 한 물리 서버를 소프트웨어로 쪼개서 만든 독립된 컴퓨터 (클라우드 컴퓨터의 실체)
  • 컨테이너 / 도커 — VM보다 훨씬 가벼운, 앱 단위 격리 기술
  • 클라우드 저장소 — 단순히 파일을 저장하는 인터넷 디스크 (클라우드 컴퓨터와 완전히 다른 개념)
  • 보안이 좋은 이유 — 데이터가 로컬에 없음 + 중앙 통제 + 즉시 차단 + USB/클립보드 차단 + 감사 로그 + 망분리
  • 다층 방어(Defense in Depth) — 방화벽 / WAF / IDS·IPS / TLS / VPN / MFA / EDR / DLP / SIEM·SOC가 겹쳐서 작동
  • 접속 시점 점검 영역 — 인증 · 암호화 · 네트워크 경계 · 엔드포인트 · VDI 정책 · 감사 로그 · 공급망 · 인사이더 (8개 카테고리)
  • 연결 이후(세션 중) 위협 — 가상 채널 · 세션 토큰 하이재킹 · 데이터 유출 8경로 · 화면 캡처 · 키로깅 · 하이퍼바이저 격리 · 세션 종료 처리
  • 가장 중요한 관점 — "인증 통과 후 무엇을 할 수 있는가"가 실질적 위험. 인사이더와 세션 탈취 시나리오를 반드시 점검 항목에 포함