Chapter 08네트워크 보안

8.1 보안의 4가지 목표

네트워크 보안 교과서의 첫 페이지에는 거의 항상 같은 등장인물이 나온다. 앨리스(Alice)는 메시지를 보내는 사람, 밥(Bob)은 받는 사람, 그리고 그 사이 어딘가에서 패킷을 훔쳐보거나 가로채려고 하는 이브(Eve) 또는 맬러리(Mallory)가 있다. 이브는 보통 도청자(eavesdropper)고, 맬러리는 능동적으로 메시지를 조작하는 공격자다.

이 인물들이 등장하는 모든 시나리오에서 우리가 지키고 싶은 것은 결국 네 가지다.

• 기밀성(confidentiality) — 메시지의 내용은 받는 사람만 볼 수 있어야 한다. 이브가 패킷을 캡처해도 무엇이 적혀있는지 모르게 하는 것.
• 무결성(integrity) — 메시지가 도중에 바뀌지 않았다는 보장. 맬러리가 "내일 보자"를 "내일 송금해"로 바꿨다면 받는 쪽이 그 사실을 알아챌 수 있어야 한다.
• 인증(authentication) — 상대가 진짜 그 사람인지 확인하는 것. 밥이라고 주장하는 그 패킷이 정말 밥에게서 온 것인가?
• 가용성(availability) — 시스템이 제 시간에 제 기능을 한다는 보장. 아무리 암호가 튼튼해도 서버가 DDoS로 다운되면 사용자에게는 불통이다.

네트워크에서 이 네 가지는 따로따로가 아니라 한꺼번에 필요하다. 예를 들어 인터넷뱅킹 화면에 비밀번호를 친다고 생각해 보자. 비밀번호가 평문으로 흘러가면 기밀성이 깨진다. 잔액 조회 응답이 도중에 조작되면 무결성이 깨진다. 가짜 은행 사이트에 접속한 거라면 인증이 무너진 것이다. 그리고 누군가 은행 서버를 마비시키면 가용성이 사라진다. 어느 하나만 빠져도 시스템 전체의 신뢰가 무너진다.

위협 모델 — 누가 무엇을 할 수 있다고 가정할까

보안 설계는 항상 "공격자가 무엇을 할 수 있는가"에 대한 가정 위에서 시작한다. 가장 흔한 가정은 돌프만-야오(Dolev-Yao) 모델인데, 한마디로 "공격자는 네트워크 전체를 본다"는 것이다. 이브는 모든 패킷을 읽고, 변조하고, 새 패킷을 주입하고, 가로채서 막을 수 있다고 가정한다. 다만 암호 자체는 깰 수 없다고 본다.

이 다소 비관적인 가정 덕분에 우리가 만든 프로토콜은 실제 인터넷의 거친 환경에서도 살아남는다. "우리 네트워크는 깨끗하니까 평문으로 보내도 돼" 같은 안일함이 매번 사고로 이어지는 이유다.

공격의 두 부류 — 수동과 능동

공격자의 행동도 두 부류로 나눠 두면 머릿속이 정리된다. 수동 공격(passive attack)은 도청처럼 트래픽을 관찰만 한다. 흔적이 거의 남지 않아 탐지가 어렵고, 그래서 기밀성 보호가 더더욱 중요해진다. 반면 능동 공격(active attack)은 패킷을 변조하거나 새로 주입한다. 중간자(MITM, Man-in-the-Middle), 재전송(replay), 위장(spoofing) 같은 형태들이 모두 여기 속한다. 무결성과 인증은 능동 공격에 대비하는 핵심 도구다.

8.2 대칭키와 공개키 암호

암호의 세계에는 큰 두 부족이 산다. 대칭키 암호와 공개키 암호다. 두 부족은 사이가 나쁘지 않다. 오히려 현대 인터넷은 이 둘을 영리하게 섞어 쓴다. 그래도 성격이 워낙 다르니 따로 살펴보자.

대칭키 — 같은 열쇠로 잠그고 푼다

대칭키 암호는 이름 그대로다. 앨리스와 밥이 똑같은 비밀 열쇠 K를 공유한다. 앨리스는 K로 메시지를 잠그고, 밥은 같은 K로 푼다. 빠르고 효율적이다. 단점은 명확하다 — 만나본 적 없는 사람과 어떻게 K를 공유할 것인가? 이 문제가 공개키 암호가 등장한 이유다.

대칭키 암호는 다시 두 부류로 나뉜다.

• 블록 암호(block cipher) — 평문을 일정 크기 블록(보통 128비트)으로 자르고, 블록마다 변환한다. 대표가 AES(Advanced Encryption Standard)다. 키 길이는 128/192/256비트가 표준이다.
• 스트림 암호(stream cipher) — 키로부터 만들어낸 무한히 긴 비트열(키스트림)을 평문과 XOR한다. 빠르고 메모리가 적게 든다. ChaCha20이 대표적이다.

블록 암호는 한 블록보다 큰 메시지를 어떻게 처리할지를 정하는 운영 모드(mode of operation)가 따로 있다. 한 줄씩만 짚어보자.

• ECB — 같은 블록은 항상 같은 암호문이 된다. 패턴이 그대로 노출되므로 쓰지 말 것.
• CBC — 직전 블록의 암호문을 다음 평문에 XOR한다. ECB의 패턴 문제는 해결되지만 변조 검출은 못 한다.
• GCM — 암호화와 무결성 검증을 동시에 한다. 현대 표준. 인증 태그가 함께 나온다.

공개키 — 우편함 슬롯의 비유

공개키 암호의 직관은 우편함이 가장 잘 맞는다. 누구나 슬롯에 편지를 넣을 수는 있지만, 안에 든 편지를 꺼내는 열쇠는 우편함 주인만 가지고 있다. 슬롯이 바로 공개키(public key)고, 안쪽 열쇠가 개인키(private key)다.

두 열쇠는 수학적으로 짝이지만, 공개키만 가지고 개인키를 거꾸로 알아내는 일은 현실적인 시간 안에 못한다. 그게 공개키 암호의 안전성을 떠받친다.

대표 알고리즘은 RSA와 ECC(타원곡선암호)다.

• RSA — 두 개의 큰 소수를 곱한 결과를 다시 두 소수로 분해(소인수분해)하는 일이 어렵다는 사실에 기댄다. 키가 좀 길다(요즘 권장은 2048비트 이상).
• ECC — 타원곡선 위에서 정의되는 "이산 로그" 문제가 어렵다는 사실에 기댄다. 같은 보안 수준에서 키가 훨씬 짧다(256비트 ECC는 RSA 3000비트급). 모바일이나 IoT에서 인기.

대칭 vs 공개키 — 한눈 비교

디피-헬만 — 만난 적 없는 둘이 비밀을 만든다

공개키 암호의 핵심 응용 중 하나가 키 교환(key exchange)이다. 그중에서도 디피-헬만(Diffie-Hellman, DH)은 거의 마법처럼 동작한다. 공개된 채널에서만 메시지를 주고받았는데, 결과적으로 둘만 아는 비밀이 생긴다.

비유로 가자. 페인트 통이 두 개 있다. 모두가 보는 공통 색(예: 노랑)에 앨리스는 자기만 아는 비밀 색을 섞고, 밥도 자기만 아는 비밀 색을 섞는다. 그 결과로 나온 두 통은 공개적으로 교환된다. 받은 뒤 앨리스는 자기 비밀 색을 한 번 더 섞고, 밥도 자기 비밀 색을 한 번 더 섞으면 — 두 통 모두 정확히 같은 색이 된다. 도청자는 공통 색과 두 중간 통은 봤지만, 비밀 색을 모르므로 최종 색을 만들어낼 수 없다.

실제 DH는 페인트 대신 이산 거듭제곱과 모듈로 연산을 쓴다. 타원곡선 위에서 하는 ECDH는 같은 보안 수준에서 훨씬 효율적이다. 매 세션마다 새 키를 만드는 일시(ephemeral) DH는 나중에 장기 키가 새도 옛 통신은 안전하게 지켜준다 — 이 성질을 전방 비밀성(forward secrecy)이라 부른다.

키 길이는 얼마면 충분한가

"키가 몇 비트면 안전한가"는 자주 나오는 질문이다. 정답은 시대와 알고리즘에 따라 다르지만, 현 시점의 일반적인 권고는 이렇다. 대칭키는 128비트 이상(중요 자산은 256비트), RSA는 2048비트 이상(가능하면 3072비트), ECC는 256비트 이상이면 보통의 위협 모델에서 충분하다고 본다. 같은 보안 등급에서 ECC가 RSA보다 키가 훨씬 짧다는 점도 기억해 두자.

한편 미래 위협으로 자주 거론되는 게 양자 컴퓨터다. 충분히 큰 양자 컴퓨터가 등장하면 RSA·ECC 같은 공개키 암호는 깨질 수 있다고 알려져 있다. 이에 대비해 포스트 양자 암호(PQC, Post-Quantum Cryptography) 표준화가 진행 중이며, 격자(lattice) 기반 알고리즘이 유력 후보로 떠오르고 있다. 대칭키 쪽은 키 길이를 두 배 정도로 늘리면 된다는 직관(그로버 알고리즘 영향)이 알려져 있어 상대적으로 충격이 작다.

8.3 메시지 무결성

기밀성만으로는 부족하다. 이브가 내용을 못 읽더라도, 맬러리는 패킷의 비트를 뒤집을 수 있다. 받는 쪽이 "이 메시지는 도중에 변하지 않았다"고 확신하려면 별도의 장치가 필요하다. 그 장치가 암호 해시(cryptographic hash)를 중심으로 만들어진다.

암호 해시 — 메시지의 디지털 지문

해시 함수는 임의 길이 입력을 고정 길이의 출력(해시값, digest)으로 줄인다. 단순한 해시(예: 자료구조에서 쓰는 해시)와 달리 암호 해시는 세 가지 강한 성질을 만족해야 한다.

• 역상 저항 — 해시값 h가 주어졌을 때 h = H(x)인 x를 찾기 어렵다.
• 제2 역상 저항 — x가 주어졌을 때 H(x)와 같은 다른 x'를 찾기 어렵다.
• 충돌 저항 — H(x) = H(y)인 x, y 쌍을 찾기 어렵다.

입력의 한 비트만 바뀌어도 출력이 거의 절반 정도 무작위로 뒤집힌다(눈사태 효과, avalanche effect). 그래서 작은 변조도 바로 들통난다.

현재 권장되는 표준은 SHA-2 계열(SHA-256, SHA-512 등)과 SHA-3이다. MD5와 SHA-1은 충돌이 발견되어 보안 용도로는 폐기된 상태다 — 신규 시스템에 쓰지 말 것.

MAC과 HMAC — 비밀을 섞은 해시

해시만으로는 무결성을 완전히 보장하지 못한다. 왜냐하면 맬러리가 메시지를 바꾸면서 새 해시값도 같이 다시 계산해 붙일 수 있기 때문이다. 그래서 비밀 키를 함께 섞은 해시 — 메시지 인증 코드(MAC, Message Authentication Code) — 가 필요하다.

MAC을 가장 안전하게 만드는 표준 방식이 HMAC이다. 의사코드로 보면 직관이 잡힌다.

# HMAC 의사코드 (RFC 2104)
# K: 비밀 키, M: 메시지, H: 해시 함수(예: SHA-256)
# ipad = 0x36 반복, opad = 0x5C 반복 (블록 길이만큼)

function HMAC(K, M):
    if length(K) > block_size:
        K = H(K)
    K = pad_zero(K, block_size)

    inner = H( (K XOR ipad) || M )
    outer = H( (K XOR opad) || inner )
    return outer

핵심은 키를 두 번 다른 패턴(ipad, opad)으로 섞어 바깥과 안쪽 해시를 한다는 것. 이 이중 구조가 다양한 공격(특히 길이 확장 공격)을 막아준다.

HMAC은 양쪽이 같은 비밀 키를 공유해야 한다. 그래서 검증은 가능하지만, 누가 만들었는지 제3자에게 증명하지는 못한다. "내가 만든 게 맞다"고 우긴다고 해도, 키를 공유한 다른 쪽도 만들 수 있었기 때문이다. 이 제한을 풀어주는 게 다음에 나올 디지털 서명이다.

디지털 서명 — 인감과 같은 것

한국에서 종이 서류에 인감을 찍는 절차를 떠올려 보자. 내가 가진 인감은 나만 갖고 있다. 그런데 인감 등록증을 통해 누구나 그 인감의 모양은 검증할 수 있다. 결과적으로 도장이 찍힌 문서를 보면 "이건 내가 찍은 게 맞다"는 사실을 부인할 수 없다.

디지털 서명은 정확히 이 구조다. 다만 비밀은 개인키고, 등록증은 공개키다.

대표 서명 알고리즘은 RSA 서명, DSA, ECDSA, Ed25519 등이다. 검증은 공개키로 누구나 할 수 있고, 서명은 개인키 소유자만 만들 수 있다. 이게 부인 방지(non-repudiation)의 기반이다. 앨리스가 만든 서명을 누구나 PUB_A로 검증할 수 있으니, 앨리스는 "내가 안 했다"고 발뺌하기 어렵다.

인증 암호화 — 한 번에 두 마리 토끼

현대 시스템에서는 암호화와 무결성을 따로 다루기보다 인증 암호화(AEAD, Authenticated Encryption with Associated Data)로 한꺼번에 처리한다. 대표가 AES-GCM과 ChaCha20-Poly1305다. 이름의 뒷 절반(GCM, Poly1305)이 무결성 부분이다. AEAD는 암호문에 더해 인증 태그를 만들어내고, 검증할 때 태그가 맞지 않으면 평문을 일절 노출하지 않는다.

"왜 따로 하면 안 되나"라고 물을 수 있다. 옛날에는 흔히 "암호화 따로, MAC 따로(encrypt-then-MAC, MAC-then-encrypt 등)"로 조립했지만, 잘못된 조합은 미묘한 공격(예: 패딩 오라클 공격)을 가능하게 만든 사례가 많았다. AEAD는 표준화된 안전한 조립을 한 묶음으로 제공한다. 신규 설계에서는 무조건 AEAD 모드를 쓰자.

8.4 인증과 PKI

공개키 암호는 멋지지만, 한 가지 결정적인 문제가 있다. 이 공개키가 정말로 그 사람의 것인지 어떻게 아는가? 이브가 가짜 공개키 PUB_E를 "이게 밥의 PUB_B야"라고 우기면 어떻게 막을 것인가.

이 문제를 해결하기 위해 인류는 공개키 기반구조(PKI, Public Key Infrastructure)라는 거대한 신뢰 시스템을 만들었다. 핵심 아이디어는 단순하다 — 공개키에 "이 키는 누구의 것이다"라는 보증서를 붙이고, 그 보증서를 신뢰받는 기관이 서명하게 하는 것.

인증서 — 공개키에 신원을 묶는 종이

디지털 인증서(certificate)는 본질적으로 다음 정보를 담은 문서다.

• 주체(subject) — 인증서가 누구의 것인지 (예: www.example.com)
• 주체의 공개키
• 발급자(issuer) — 누가 이 인증서를 보증하는지
• 유효 기간 — 언제부터 언제까지
• 일련번호, 용도 제한, 확장 필드 등
• 발급자의 디지털 서명 — 위 모든 내용을 발급자가 자기 개인키로 서명

표준 형식은 X.509고, 인터넷에서 가장 널리 쓰인다. 가장 마지막 줄 — 발급자의 서명이 핵심이다. 누군가 인증서 내용을 한 비트라도 바꾸면 서명 검증이 깨지므로 알아챌 수 있다.

CA — 보증서를 발급하는 기관

인증서를 발급하고 서명하는 주체가 인증 기관(CA, Certificate Authority)이다. 우리가 익히 듣는 이름들 — Let's Encrypt, DigiCert, GlobalSign, Sectigo 등. 이들은 도메인 소유 증명을 받고 인증서를 발급한다.

그런데 CA의 인증서는 또 누가 보증하나? 답은 "더 위의 CA". 이렇게 위로 올라가다 보면 결국 자기 자신을 서명한 루트 CA(root CA)를 만난다. 루트 CA의 인증서는 운영체제나 브라우저에 미리 박혀있다. 우리는 결국 운영체제와 브라우저 벤더가 신뢰하는 CA 목록을 신뢰함으로써 시작점을 얻는 것이다.

인증서 체인 — 신뢰의 사슬

실제 웹사이트 인증서는 보통 다음과 같은 사슬을 이룬다.

# 인증서 체인 (간략 텍스트 표현)

[ 루트 CA 인증서 ]
  Subject:  CN=Big Trust Root CA
  Issuer:   CN=Big Trust Root CA   (자기 자신 — self-signed)
  Public Key: ...
  Signature: 자기 개인키로 서명
       |  (브라우저 신뢰 저장소에 미리 박힘)
       v
[ 중간 CA 인증서 ]
  Subject:  CN=Big Trust Intermediate
  Issuer:   CN=Big Trust Root CA
  Public Key: ...
  Signature: 루트 CA 개인키로 서명
       |
       v
[ 서버 인증서 ]
  Subject:  CN=www.example.com
  Issuer:   CN=Big Trust Intermediate
  Public Key: 서버 공개키
  Signature: 중간 CA 개인키로 서명

브라우저는 서버에서 받은 서버 인증서를 읽고, 발급자(중간 CA)의 공개키로 서명을 검증하고, 다시 그 중간 CA의 발급자(루트 CA)의 공개키로 검증한다. 마지막에 닿은 루트 CA가 신뢰 저장소에 있으면 — 통과. 한 단계라도 깨지면 — 그 익숙한 빨간 경고 화면이 뜬다.

신뢰 모델 — 누구를 믿을 것인가

• 계층적 모델 — 위에서 본 트리 구조. 웹의 표준.
• 웹 오브 트러스트(Web of Trust) — 친구가 친구를 보증한다. PGP가 쓴 모델. 분산적이지만 일반 사용자에게는 어렵다.
• TOFU(Trust On First Use) — 처음 본 키를 일단 신뢰하고 외워둔다. SSH가 이 방식.

폐기 — 새어버린 열쇠를 어떻게 무효화할까

아무리 잘 만들어도 사고는 난다. 서버 개인키가 유출되면 인증서를 즉시 폐기해야 한다. 두 가지 표준 메커니즘이 있다.

• CRL(Certificate Revocation List) — CA가 주기적으로 발급하는 폐기 목록. 큰 파일을 받아 와서 일련번호로 검색.
• OCSP(Online Certificate Status Protocol) — 한 인증서의 상태를 CA(또는 그 응답기)에 실시간으로 묻는다. OCSP 스테이플링(stapling)은 서버가 미리 받아온 응답을 핸드셰이크에 끼워 보내 클라이언트의 추가 통신을 줄여준다.

8.5 TLS — HTTPS의 속살

웹에서 가장 자주 마주치는 보안 프로토콜은 단연 TLS(Transport Layer Security)다. URL 앞의 그 's' 한 글자, 자물쇠 아이콘의 정체. 옛 이름은 SSL이고, 지금 표준은 TLS 1.2와 TLS 1.3이다. SSL 2/3과 TLS 1.0/1.1은 폐기되었다 — 신규 시스템에 절대 쓰지 말 것.

TLS는 TCP 위에서 동작하는 프로토콜로, 한 번의 핸드셰이크(handshake)를 거쳐 비밀 채널을 만들고, 그 위에서 응용 데이터를 주고받는다. HTTP가 그 위에 얹히면 HTTPS, SMTP가 얹히면 SMTPS, IMAP이 얹히면 IMAPS다.

TLS 핸드셰이크 — 만남부터 비밀 합의까지

핸드셰이크 안에서 키 교환, 인증, 알고리즘 협상이 한꺼번에 이뤄진다.

• 키 교환 — 보통 ECDHE(타원곡선 디피-헬만 일시키)로 매 세션 새 비밀을 만든다. 전방 비밀성 확보.
• 인증 — 서버는 인증서를 보내고, 그 인증서의 개인키로 핸드셰이크 일부를 서명해 "이 인증서는 진짜 내 것"임을 증명한다. 클라이언트 인증은 선택사항.
• 암호 모음(cipher suite) 협상 — 어떤 알고리즘들을 쓸지 합의. 1.3에서는 선택지가 크게 줄어 단순해졌다.

TLS 1.2 vs 1.3 — 한 줄 차이

TLS 1.3은 1.2의 군더더기를 걷어내고 보안을 강화한 버전이다. 핵심 차이를 짧게.

• 핸드셰이크가 1-RTT로 짧아졌다(1.2는 보통 2-RTT). 재연결은 0-RTT까지 가능 (트레이드오프 있음).
• 위험한 옛 알고리즘(RC4, 정적 RSA 키 교환, CBC 모드 등)을 모조리 제거.
• 모든 핸드셰이크 이후 메시지를 암호화한다(1.2는 일부 평문).
• 전방 비밀성을 사실상 강제한다.

레코드 프로토콜 — 본 데이터의 포장

핸드셰이크가 끝나고 나면 모든 응용 데이터는 레코드 프로토콜로 감싸진다. 레코드는 일정 크기 단위(보통 최대 16KB)로 나뉘고, 각 레코드는 AEAD(예: AES-GCM, ChaCha20-Poly1305)로 암호화·인증된다. 시퀀스 번호가 함께 들어가서 재전송 공격(replay)도 막는다.

8.6 네트워크 계층 보안 — IPsec과 VPN

TLS는 응용 단위로 보안을 건다. HTTPS는 HTTP에만, IMAPS는 IMAP에만 보안이 적용된다. 그런데 어떤 상황에서는 모든 트래픽을 한꺼번에 보호하고 싶을 때가 있다. 회사 본사와 지사를 연결한다든지, 외부에서 사내망에 들어와야 한다든지.

이때 사용하는 게 IPsec이다. 이름 그대로 IP 계층(L3)에서 동작하므로, 그 위에 어떤 프로토콜이 올라가든 한꺼번에 보호된다.

AH와 ESP — 두 가지 보호 프로토콜

IPsec에는 두 핵심 프로토콜이 있다.

• AH(Authentication Header) — 무결성과 인증, 재전송 방지를 제공하지만 암호화는 없다. 헤더와 본문을 모두 보호하지만 IP 헤더의 일부 가변 필드(TTL 등)는 빼고 계산.
• ESP(Encapsulating Security Payload) — 암호화 + 무결성/인증. 거의 모든 IPsec 배포가 이걸 쓴다. AH는 NAT 환경에서 잘 안 맞기도 해서 점점 잊혀지는 추세.

트랜스포트 모드 vs 터널 모드

IPsec은 두 모드 중 하나로 동작한다.

• 트랜스포트 모드 — 원래 IP 헤더는 그대로 두고 그 안의 페이로드만 보호. 호스트 대 호스트(end-to-end) 통신에 적합.
• 터널 모드 — 원래 IP 패킷 전체를 암호화·인증한 뒤 새 IP 헤더로 한 번 더 감싼다. 게이트웨이 사이에서 사용. VPN의 표준 형태.

SA, SPI, IKE — 세 가지 키워드

IPsec은 보호 매개변수(키, 알고리즘, 수명)를 묶은 단위인 SA(Security Association)를 양방향마다 만든다. 패킷이 어느 SA에 속하는지는 SPI(Security Parameter Index)로 식별한다. 그리고 SA를 협상하고 키를 교환하는 별도 프로토콜이 IKE(Internet Key Exchange)다. 보통은 IKEv2가 표준.

VPN의 형태

• 사이트-투-사이트(site-to-site) — 위 그림처럼 두 게이트웨이 사이를 IPsec 터널로 묶는다. 양쪽 사내망이 한 네트워크처럼 보인다.
• 리모트 액세스(remote access) — 개인 단말이 회사 게이트웨이에 VPN 클라이언트로 접속. IPsec 또는 SSL VPN(TLS 기반).
• WireGuard — 비교적 최근에 등장한 가벼운 VPN 프로토콜. 코드베이스가 작고 설정이 단순해 인기를 얻고 있다.

8.7 무선 보안과 운영 보안

마지막으로 우리가 매일 만나는 두 종류의 보안 — 와이파이와 사내 네트워크 경계 — 를 살펴보자.

WPA2와 WPA3 — 와이파이 보안의 현재

7장에서 와이파이의 물리/MAC을 봤다. 여기서는 그 위에 얹히는 암호화에 집중하자. 큰 흐름은 WEP → WPA → WPA2 → WPA3로 이어졌고, WEP와 WPA1은 깨진 지 오래라 사용하면 안 된다.

WPA2-PSK는 4-way 핸드셰이크를 캡처하면 비밀번호를 오프라인으로 추측할 수 있다는 약점이 있었다. WPA3-Personal은 SAE(Simultaneous Authentication of Equals)라는 새 키 교환을 도입해 같은 비밀번호여도 도청자가 추측을 거의 못하게 만들었다. 또 매 세션마다 새로운 키를 도출해 전방 비밀성도 붙는다. 인프라가 지원한다면 WPA3로 가는 게 정답이다.

기업용에서는 802.1X / EAP가 핵심이다. 와이파이 비밀번호를 단말마다 따로 가지고, 인증 서버(보통 RADIUS)가 단말 신원을 검증한다. 사용자별 권한 분리, 회수, 추적이 모두 쉬워진다.

방화벽 — 트래픽의 출입국 심사대

네트워크 경계에 놓이는 가장 고전적인 장치가 방화벽(firewall)이다. 정의된 규칙에 따라 패킷의 통과 여부를 결정한다. 진화 단계로 보면 다음과 같다.

• 패킷 필터(상태 비저장, stateless) — 각 패킷의 헤더(주소, 포트, 프로토콜)만 보고 규칙과 대조. 단순하고 빠르지만, "응답은 들여보내야지" 같은 미묘한 처리에 약하다.
• 상태 저장(stateful) — TCP 연결 상태를 추적해, 내부에서 시작한 연결의 응답은 자동으로 허용. 현재 거의 모든 방화벽이 이걸 한다.
• 응용 계층 게이트웨이/프록시 — HTTP, FTP 같은 응용 프로토콜 내용을 이해하고 필터. 깊은 검사 가능.
• 차세대 방화벽(NGFW) — 위 모두 + IPS, 사용자/앱 인지, TLS 검사까지.

방화벽 규칙은 보통 "기본은 차단, 필요한 것만 허용(default-deny)" 원칙으로 짠다. 반대로 하면 모르는 새로운 위험이 그대로 들어온다.

IDS/IPS — 의심스러운 패턴을 잡아내는 눈

• IDS(Intrusion Detection System) — 트래픽을 관찰하고 의심 패턴을 발견하면 경고를 낸다. 흐름은 그대로 흘려보낸다. 사후 분석에 유용.
• IPS(Intrusion Prevention System) — IDS와 같은 탐지 능력에 더해, 의심 흐름을 차단까지 한다. 통신 경로상에 있어야 한다(인라인 배치).

탐지 방식은 크게 둘로 나뉜다. 시그니처 기반은 알려진 공격 패턴(스트링, 바이트 시퀀스)과 일치하는지 본다. 빠르고 오탐이 적지만 새로운 공격에는 약하다. 이상 탐지(anomaly detection)는 평소 트래픽의 통계적 정상 범위를 벗어나는 흐름을 잡는다. 새 공격에 강하지만 오탐이 많다. 실무에서는 둘을 섞어 쓴다.

운영의 또 다른 축들

네트워크 보안의 마지막 그림에는 기술 외에도 챙길 게 많다. 로그 수집과 SIEM은 분산된 장비의 이벤트를 한 곳에 모아 상관 분석을 가능하게 한다. 패치 관리는 새로 발견된 취약점을 적시에 막는 가장 기본적인 무기다. 최소 권한 원칙(least privilege)은 사용자나 서비스에 꼭 필요한 권한만 주어, 한 계정이 뚫려도 피해 범위를 좁힌다.

그리고 잊기 쉬운 한 가지 — 사람이 가장 약한 고리라는 점. 피싱, 비밀번호 재사용, 사회공학 같은 공격은 어떤 암호 알고리즘도 막아주지 못한다. 보안 교육과 다중 인증(MFA)은 기술 못지 않게 중요한 통제다.

한 줄 요약

• 네 가지 목표 — 기밀성·무결성·인증·가용성. 어느 하나만 빠져도 신뢰가 무너진다.
• 두 부족의 협업 — 공개키로 빠르게 비밀을 합의(DH/ECDHE)하고, 본 데이터는 빠른 대칭키(AES-GCM, ChaCha20-Poly1305)로 보호하는 하이브리드 구조가 표준.
• 해시 + 비밀 — HMAC은 양쪽 검증, 디지털 서명은 누구나 검증 + 부인 방지. 둘은 다른 도구다.
• PKI는 인증서의 사슬 — 서버 인증서 → 중간 CA → 루트 CA. 운영체제·브라우저의 신뢰 저장소가 시작점이다.
• TLS는 핸드셰이크에서 끝낸다 — 키 교환·인증·알고리즘 협상이 한 번에. 1.3은 1.2를 단순화·강화한 현재 표준.
• 심층 방어 — 암호 한 겹으로 끝내지 말 것. 방화벽·IDS/IPS·인증·VPN·제로 트러스트를 함께 쌓는다.