Infrastructure & Platform Security

1. Overview

인프라 및 플랫폼 보안(Infrastructure & Platform Security, IPS)은 해커가 들어올 수 있는 길목에 거대한 성벽과 해자(Moat)를 파서, 내부의 서버와 데이터베이스가 공격당할 기회조차 주지 않는 물리적/논리적 공간 요새화를 다룹니다.

집의 현관문을 아무리 튼튼하게 잠가도(암호학), 담벼락이 없으면 도둑이 창문으로 들어옵니다. 학습자는 전통적인 방화벽(Firewall)과 침입 탐지 시스템(IDS)을 통해 악의적인 패킷을 쳐내는 '경계 보안(Perimeter Security)'을 익힙니다. 나아가 모든 것이 가상화된 현대 클라우드에서는 AWS VPC(가상 프라이빗 클라우드)로 우리만의 안전한 섬을 만들고, 도커(Docker) 컨테이너를 탈옥(Breakout)하려는 시도를 막아내며, "내부망에 있는 놈도 믿지 마라"는 제로 트러스트(Zero Trust) 철학에 입각하여 뚫리지 않는 인프라를 빚어내는 아키텍트가 됩니다.

2. Scope & Boundaries

In-Scope

• 네트워크 경계 보안 (Perimeter Defense): L3/L4/L7 방화벽, 상태 기반 검사(Stateful Inspection), DMZ(비무장 지대), VPN 터널링.
• 침입 탐지 및 방어 (IDS/IPS): 시그니처 기반(Signature-based) vs 이상 탐지(Anomaly-based), 허니팟(Honeypot).
• 클라우드 인프라 보안 (Cloud Security): VPC 라우팅 격리, IAM(Identity & Access Management) 최소 권한 원칙(Least Privilege), 클라우드 보안 그룹(Security Group).
• 컨테이너 및 플랫폼 보안 (Platform Security): 컨테이너 런타임 보안, 이미지 취약점 스캐닝, 제로 트러스트(Zero Trust) 아키텍처.

Out-of-Scope

• 웹 애플리케이션 소스 코드 취약점: SQL 인젝션이나 XSS처럼 코드 내부의 로직을 고쳐야 하는 문제 $\rightarrow$ 10-03. Application & Data Security 영역으로 위임.
• 물리적 하드웨어 및 서버 랙 설계: 지문 인식 문이나 데이터 센터 전력 차단 대비 $\rightarrow$ 클라우드 시대에는 CSP(Cloud Service Provider)에게 위임된 물리 보안.

Boundaries

• IPS vs. Cryptography (10-01): 암호학(10-01)이 탈취당한 데이터 상자가 열리지 않게 '자물쇠'를 채우는 수학적 기술이라면, IPS(10-02)는 애초에 도둑이 금고방(네트워크) 근처에도 오지 못하도록 레이저망과 경비견(방화벽/IDS)을 배치하는 지리적 차단 기술입니다.

3. Counterexample

• "방화벽 샀으니 우리는 안전하다" (Perimeter Security Fallacy): 외부에서 들어오는 포트는 방화벽으로 다 막았으니 내부망(Intranet)은 안전하다고 맹신하는 구시대적 오만. 직원이 열어본 피싱 이메일 하나로 해커가 내부 직원의 PC를 좀비로 만들면, 방화벽은 완전히 무용지물이 됩니다. 내부망에 침투한 해커가 다른 서버로 자유롭게 수평 이동(Lateral Movement)하지 못하도록, 내부 서버 간에도 통신을 차단하는 제로 트러스트(Zero Trust)를 모르면 시스템은 한 방에 궤멸합니다.
• 클라우드는 클라우드 업체가 지켜준다는 오해 (Shared Responsibility Fallacy): AWS나 Azure를 쓰면 아마존이나 마이크로소프트가 내 DB를 해킹으로부터 지켜줄 것이라고 믿는 행위. 클라우드 보안의 핵심은 '책임 공유 모델(Shared Responsibility Model)'입니다. 클라우드 사업자는 데이터 센터의 물리적 서버만 지켜줄 뿐, VPC의 포트를 0.0.0.0/0(전체 개방)으로 뚫어놓아 DB가 랜섬웨어에 감염되는 것은 100% 고객의 책임입니다. 클라우드 인프라 보안 설정을 모르면 돈 내고 해커의 놀이터를 임대하는 꼴입니다.

4. Prerequisites

• 네트워크 기초 (Basic): IP 주소, 서브넷 마스크(Subnetting), 포트 번호, NAT의 물리적 작동 원리를 알아야 방화벽 룰을 세울 수 있습니다. (08-01, 08-03)
• 리눅스 운영체제 (Recommended): 도커(Docker)의 네임스페이스와 cgroups 격리를 이해하려면 리눅스 커널 구조를 알아야 합니다. (03-03. Virtualization Physics)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 네트워크 방화벽과 DMZ 설계 (Firewall & DMZ)

• Why to Learn: 대문을 활짝 열어놓고 도둑이 안 들어오길 바라는 바보짓을 멈추고, 꼭 필요한 서비스(웹 80, 443 포트)만 길을 터주는 문지기를 세우기 위함입니다.
• What to Learn:
  • Concepts: 방화벽(Firewall), 인바운드/아웃바운드 트래픽, 화이트리스트(Whitelist) vs 블랙리스트(Blacklist).
  • Skills: 상태 기반 필터링(Stateful Inspection) 논리, DMZ(Demilitarized Zone) 망 분리 아키텍처.
  • Tools: 리눅스 iptables, 클라우드 Security Group.
  • Trade-offs: "기본 차단(Deny All), 필요한 것만 허용"하는 화이트리스트 정책이 주는 절대적 안전함 vs 새로운 서버가 추가될 때마다 방화벽 결재를 받아야 하는 극악의 운영 피로도.
• How to Learn:
  • 1단계: 해커가 내 PC로 접근하는 것을 막는 '인바운드 차단'뿐만 아니라, 내 PC에 깔린 악성코드가 해커의 C&C 서버로 몰래 데이터를 빼돌리는 것을 막기 위해 '아웃바운드 차단'까지 설정해야 하는 양방향 방화벽의 물리를 이해합니다.
  • 2단계: 외부에서 접속해야 하는 '웹 서버'는 해커에게 공격당할 확률이 높으므로, 웹 서버(DMZ)와 내부 핵심 데이터를 가진 'DB 서버(내부망)'를 물리적인 방화벽으로 완전히 쪼개어, 웹 서버가 뚫려도 DB까지 못 오게 막는 DMZ 아키텍처를 스케치합니다.
• Implement: 3-Tier(Web-WAS-DB) 시스템에서, Web은 443(HTTPS)만 외부 개방하고, WAS는 Web에서 오는 8080 트래픽만 허용하며, DB는 WAS에서 오는 3306 트래픽만 허용하도록 설계한 방화벽 규칙(ACL) 명세서.

Recommended

Core Topic 02: 침입 탐지 및 방지 시스템 (IDS & IPS)

• Why to Learn: 방화벽이 합법적인 여권(80번 포트)을 가진 자는 무사통과시킨다는 약점을 노려, 여권 속에 폭탄(악성 페이로드)을 숨겨오는 테러리스트를 실시간으로 색출하기 위해서입니다.
• What to Learn:
  • Concepts: 침입 탐지 시스템(IDS: 감시 카메라) vs 침입 방지 시스템(IPS: 자동 방범 문).
  • Skills: 시그니처 기반 탐지(알려진 공격 방어) vs 이상 탐지 기반(알려지지 않은 제로데이 공격 방어), 오탐(False Positive)과 미탐(False Negative).
  • Tools: Snort, Suricata.
  • Trade-offs: IPS를 켜서 해커의 통신을 실시간으로 끊어버리는 강력한 방어력 vs 합법적인 고객의 큰 결제 트래픽을 디도스(DDoS) 공격으로 오인해(오탐) 차단해 버리는 최악의 서비스 장애.
• How to Learn:
  • 1단계: Snort 시스템에 "패킷 안에 UNION SELECT라는 문자열이 포함되어 있으면 경고 알람을 울려라"라는 시그니처(Rule)를 작성하고, 웹 서버를 향해 SQL 인젝션을 날려 탐지되는 과정을 관찰합니다.
  • 2단계: IDS 장비를 네트워크 선의 중간에 꽂는 인라인(Inline) 방식과 옆에서 몰래 패킷 복사본만 떠서 보는 미러링(Mirroring) 방식의 물리적 장애 전파 리스크 차이를 맵핑합니다.
• Implement: 웹 서버 앞단에 오픈소스 IPS(Suricata)를 세팅하고, 불특정 다수의 포트 스캔(Port Scan) 공격 시도가 들어올 때 이를 인지하여 해당 IP를 임시 차단(Ban)하는 자동화 시나리오 구축.

Practical

Core Topic 03: 클라우드 인프라 보안과 IAM (Cloud Security & IAM)

• Why to Learn: AWS, GCP 같은 퍼블릭 클라우드에서 스위치 하나만 잘못 켜도 회사의 전 재산(데이터)이 인터넷에 벌거벗겨지는 대참사를 막기 위해서입니다.
• What to Learn:
  • Concepts: 책임 공유 모델(Shared Responsibility Model), VPC(Virtual Private Cloud), 퍼블릭/프라이빗 서브넷.
  • Skills: IAM(Identity & Access Management) 최소 권한 부여, 베스천 호스트(Bastion Host)와 NAT 게이트웨이 설계.
  • Tools: AWS IAM, AWS Inspector, CloudTrail.
  • Trade-offs: S3 버킷을 'Public'으로 열어 개발을 편하게 하려는 태만함 vs IAM 정책(Policy)을 리소스 단위로 수십 줄 작성하여 철벽을 치는 데브옵스 관리 비용.
• How to Learn:
  • 1단계: 데이터베이스 서버를 절대 '인터넷 게이트웨이'가 연결된 퍼블릭 서브넷에 두지 않고, 인터넷이 완전히 단절된 '프라이빗 서브넷'에 숨깁니다. 이후 관리자가 DB를 수정해야 할 때만 퍼블릭 서브넷의 '베스천 호스트(점프 서버)'를 통해 한 번 꺾어 들어가는 요새화 물리를 실습합니다.
  • 2단계: 개발자 A에게 "EC2 서버를 생성할 권한"은 주되, "데이터베이스를 삭제할 권한"은 절대 주지 않는 IAM 정책(JSON)을 설계하고 할당(RBAC: Role-Based Access Control)해 봅니다.
• Implement: 특정 클라우드 환경(예: AWS)에서 외부 공격표면을 최소화한 VPC 아키텍처(퍼블릭/프라이빗 서브넷 분리, 보안 그룹, NACL 적용) 템플릿 코드(Terraform) 작성.

Advanced

Core Topic 04: 플랫폼/컨테이너 보안과 제로 트러스트 (Zero Trust & Container Security)

• Why to Learn: 마이크로서비스 시대에는 해커가 하나의 작은 컨테이너를 뚫는 데 성공하더라도, 그것이 발판(Pivot)이 되어 데이터베이스까지 털리는 현상을 차단하기 위함입니다.
• What to Learn:
  • Concepts: 제로 트러스트 아키텍처(ZTA), 컨테이너 이스케이프(Container Escape), 공격 표면(Attack Surface).
  • Skills: 도커 이미지 취약점 스캐닝, 루트리스(Rootless) 컨테이너, 쿠버네티스(K8s) 네트워크 정책(Network Policy), 서비스 메시(Service Mesh) 기반 mTLS.
  • Tools: Trivy (이미지 스캔), Istio (서비스 메시).
  • Trade-offs: 내부망의 모든 서버 간 통신에도 암호화와 인증(mTLS)을 강제하여 무적의 보안을 구축하는 제로 트러스트 vs 그 엄청난 암호화 복호화 CPU 오버헤드와 트러블슈팅의 극악 난이도.
• How to Learn:
  • 1단계: 개발자가 구글에서 아무 도커 이미지나 다운받아 실행할 때, Trivy 같은 스캐너로 분석해 보면 그 안에 이미 심각한 리눅스 취약점(CVE) 100개가 들어있는 충격적인 현실을 눈으로 확인합니다. (공급망 공격 방어)
  • 2단계: 컨테이너 A가 해킹당했을 때, 그 해커가 내부망이라는 이유로 컨테이너 B에 마음대로 접속하는 것을 막기 위해 쿠버네티스 NetworkPolicy를 "A는 B와 통신할 수 없다(기본 차단)"로 막아버리는 제로 트러스트의 마이크로 세그멘테이션(Micro-segmentation)을 이해합니다.
• Implement: CI/CD 파이프라인에 도커 이미지 스캐닝 툴을 삽입하여 취약점 점수가 'High' 이상이면 배포를 강제로 차단하고, 쿠버네티스 환경에서 파드(Pod) 간 트래픽을 엄격히 통제하는 네트워크 격리 정책 제안서.

7. Terminology

8. References

Primary References

• [P3] CyBOK - Network Security / Operations & Incident Management — Network defense standards.
• [P1] CS2023 - SEC/Network Security — Layered defense principles.

Secondary References

• [Network Security: Private Communication in a Public World] Charlie Kaufman — Deep network security theory.
• [Cloud Security and Privacy] Tim Mather — Practitioner's cloud guide.

Industry References

• [NIST SP 800-53] — Security and Privacy Controls for Information Systems.
• [AWS Security Best Practices Whitepaper] — Industry standard cloud defense.

9. Final Checklist

Primary Checklist

• 특정 네트워크 아키텍처에서 '단일 장애점(SPOF)'과 '단일 보안 침해점'을 물리적으로 구분하여 개선안을 제안할 수 있는가? (P3)
• OSI 7계층 모델의 각 계층(L3, L4, L7)에서 방화벽이 어떻게 트래픽을 처리하는지 물리적 차이를 기술 가능한가? (P1)

Secondary Checklist

• IDS에서 발생하는 '탐지 누락(False Negative)'과 '오탐(False Positive)'이 보안 운영의 피로도와 안전성에 미치는 물리적 영향을 이해하는가?
• 클라우드 IAM 정책 설계 시 '역할 기반 접근 제어(RBAC)'와 '속성 기반 접근 제어(ABAC)'의 물리적 유연성 차이를 식별 가능한가?

Industry Checklist

• 실무 서비스 환경에서 외부 노출이 필요한 서비스(Web)와 내부 자원(DB)을 물리적으로 레이어링(Subnetting)하여 격리 설계할 수 있는가? (SFIA)
• 컨테이너 기반 배포 시 도커 데몬의 권한 남용을 막기 위한 '비루트(Rootless)' 구동의 보안 이점을 물리적으로 입증 가능한가?