개인공부/네트워크

[네트워크] 안정성을 위한 기술

개바리여리 2025. 10. 28. 23:46

 

안정성을 위한 네트워크 구성적 방법으로

이중화와 다중화 , 로드 밸런싱 등이 있다.

 

이중화

결함을 감내하여 가용성을 높이기 위한 가장 기본적이고 대표적인 방법

'예비(백업서버)를 마련하는 방법' 이다.

서버 및 NIC , 스위치 같은 장비도 이중화의 대상이 될 수 있다. 

여기서 백업 장비를 여러개 두는 것을 다중화 라고 한다.

 

- 액티브 / 스탠바이 

한 시스템은 가동하고 다른 시스템은 백업 용도로 대기 상태로 두는 구성방법

문제가 발생할 경우 스탠바이가 대신 동작하게 된다.

 

- 액티브 / 액티브

두 시스템을 모두 가동한다.

 

로드 밸런싱

트래픽의 고른 배분을 위해 로드 밸런서(전용 네트워크 장비)를 두어서 트래픽을 여러 서버로 분배하여 접속하게 한다.

L4 스위치는 IP주소와 포트 번호와 같은 전송 계층의 정보를 바탕으로 로드 밸런싱을 수행한다.

L7 스위치는 URI, HTTP 메시지 , 쿠키 등 응용 계층의 정보까지 활용하여 로드 밸런싱을 수행한다.

 

로드 밸런싱 소프트웨어를 설치하면 일반 호스트도 로드 밸런서로 사용이 가능하다.

ex: Nginx 등

 

일반적으로 이중화 및 다중화 된 서버와 클라이언트 사이에 위치한다.

클라이언트들은 로드 밸런서에 요청을 보내고, 로드 밸런서는 해당 요청을 각 서버에 균등하게 분배한다.

 

단순히 서버를 돌아가며 부하를 전달하는 라운드 로빈 알고리즘이 있고

연결이 적은 서버부터 부하를 전달하는 최소 연결 알고리즘도 있다.

(혹은 응답 시간이 가장 짧은 서버를 선택할 수도 있고 여러가지 방법이 존재한다.)

 

프록시

클라이언트가 선택한 메시지 전달 대리자

프록시를 언제 어떻게 사용할지는 클라이언트가 선택한다. (클라이언트와 가까이 위치한다.)

ex : 캐싱, 클라이언트 암호화, 접근제한 등의 역할을 수행

 

  • 클라이언트의 요청을 대신 서버에 전달한다.
  • 주로 “출구(Outbound)” 요청을 제어하거나 가속한다.
  • 클라이언트가 명시적으로 설정해야 한다. (ex. 브라우저 프록시 설정)
  • 캐시, 필터링, 익명성 제공 등 “클라이언트 이익” 중심.

서버 입장에서는 “이 사람이 진짜 클라이언트인지 모름”

 

  • Forward Proxy (전달 프록시) : 브라우저에서 “프록시 서버 설정” 해둔 경우
    (회사나 학교에서 인터넷 검열·캐시·로그용으로 사용)
  • Reverse Proxy (역방향 프록시) :
    서버 앞단에서 NGINX가 대신 요청을 받고, 실제 서버로 전달
    (로드밸런서, SSL 처리, 보안 필터 등)

 

 

게이트 웨이

네트워크 간의 통신을 가능하게 하는 입구역할을 하는 HW 혹은 SW

'아웃 바운드 연결에 대해' 오리진 서버 역할을 수행하는 중계자

 

  • 주로 프로토콜 변환, 네트워크 경계 연결 역할.
  • HTTP ↔ HTTPS, MQTT ↔ HTTP, REST ↔ gRPC 등 이종 통신을 연결.
  • “서버 입장”에서 요청을 받는 형태.
  • 클라이언트는 이걸 “서버인 줄 알고” 요청을 보냄.
API Gateway 클라이언트가 /api/user 로 요청 → 실제로는 여러 마이크로서비스로 라우팅
Mail Gateway 회사 내부 메일(SMTP) ↔ 외부 Gmail 서버 연결
Payment Gateway 쇼핑몰 ↔ 카드사/은행 ↔ 결제 네트워크 연결
IoT Gateway 센서의 MQTT 신호 ↔ 클라우드의 HTTPS 요청 변환

 

 

 

https://develop-actas.tistory.com/77

 

[CIA와 대칭키, 비대칭키]

CIA보안 목표와 요구사항을 달성하기 위한 3요소, 즉 보안 시스템, 정책, 암호화, 인증 등의 기준 목표이자 기준 1. Confidentiality (기밀성) 허가되지 않은 사람이 데이터를 열람할 수 없도록 보호하

develop-actas.tistory.com

 

SSL 과 TLS

인증과 암호화를 수행하는 프로토콜

TLS는 SSL을 계승한 프로토콜이다. 

 

HTTPS는 메시지 송수신 단계에서 TLS 과정이 덧붙혀졌다고 생각하면 된다.

 

1. TCP 쓰리 웨이 핸드셰이크 

https://develop-actas.tistory.com/104

 

2. TSL 핸드셰이크

 

이 주요 메시지를 통해 키교환이 이루어지며 검증이 이루어진다.

 

- 클라이언트의 ClientHello 메시지

암호화된 통신을 위해 서로 맞춰야 할 정보들을 제시하는 메시지 (지원 TLS 버전, 사용가능 암호화 알고리즘, 해시 함수 등)

- 서버의 ServerHello 메시지

클라이언트의 메시지에서 제시된 정보들을 선택하는 메시지

-서로가 메시지를 주고받으며 암호화 통신을 위해 사전 협의해야 할 정보들이 결정

 

* 암호 스위트 (cipher suite) : '사용 가능한 암호화 방식과 해시 함수' 를 담은 정보  

 

서버는 Certificate 메시지와 CertificateVerify 메시지 전송 (인증서와 검증을 위한 디지털 서명)

클라이언트는 이 메시지를 토대로 서버의 공개 키를 검증

 

 

  • ClientHello
    → “내가 이런 버전, 이런 암호 알고리즘 쓸 수 있어요!”
  • ServerHello
    → “좋아, 그중 이거로 하자.”
  • Certificate
    → “이게 내(서버)의 신분증(= 인증서)이야.”
  • CertificateVerify + Finished
    → “내가 진짜 이 인증서 주인이라는 걸 서명으로 증명할게.”

 

서버가 보내는 인증서(Certificate) 안에는 다음 정보

서버의 공개키 public key
서버의 도메인 이름 예: www.google.com
인증서 발급 기관(CA)의 이름 예: DigiCert, Let's Encrypt
인증서 유효기간 2025-10-28까지
발급 기관의 디지털 서명 CA가 이 인증서를 진짜라고 서명함

 

정상적인 경우

  • https://www.google.com 접속
  • 서버가 인증서(공개키 + CA 서명)를 보냄
  • 브라우저는 “이건 DigiCert에서 서명한 인증서네”
  • 내 OS/브라우저에는 DigiCert의 공개키가 이미 내장돼 있음
  • 검증 성공 → “이 서버는 진짜 구글!”

중간자 공격

  • 해커가 네트워크 중간에 끼어서 가짜 “google.com” 서버를 띄움
  • 자신이 만든 공개키를 포함한 가짜 인증서를 보냄
  • 브라우저가 CA 목록에서 서명을 찾지만 실패
  • 검증 실패 → “이 사이트는 신뢰할 수 없습니다” 경고창

TLS는 실제 데이터 전송은 대칭키로 한다(성능 때문에). 하지만 그 대칭키를 안전하게 합의/교환하는 데는 **비대칭기법(공개/개인키 또는 DH 계열)**을 쓴다.

 

RSA 키 교환 방식 — 직관적(하지만 요즘은 잘 안 씀)

  • 클라이언트: 랜덤으로 pre-master-secret 생성
  • 클라이언트: 이 pre-master-secret을 서버의 공개키로 암호화해서 보냄
  • 서버: 자신의 개인키로 복호화 → pre-master-secret을 얻음
  • 양쪽: pre-master-secret으로부터 대칭 세션키 유도 → 이후 대칭 암호(AES)로 통신

=> 여기서는 클라이언트가 서버 공개키로 암호화하고 서버 개인키로 복호화한다.

 

(현재 표준) (EC)DHE + 서명(인증) — TLS 1.2의 권장/그리고 TLS 1.3

  • 키 교환: 클라이언트와 서버가 서로 Ephemeral DH(또는 ECDH) 파라미터를 교환해서 공통의 공유 비밀(shared secret) 을 계산한다. 이 과정 자체로 양쪽은 같은 대칭키를 만들 수 있음.
  • 서버 인증: 서버는 자신의 개인키로 (DH 파라미터 등)에 서명을 한다 (CertificateVerify에 해당).
    클라이언트는 서버가 보낸 인증서 속 공개키로 그 서명을 검증한다.
  • 결론: 서버는 개인키로 '서명' → 클라이언트는 공개키로 '서명 검증'. 실제 공유 비밀은 DH에서 나오므로 서버 공개키로 공유비밀을 복호화하지 않는다.

서명(CertificateVerify 또는 ServerKeyExchange 서명)을 서버 개인키로 생성해서 보내면,
클라이언트는 인증서의 공개키로 그 서명을 검증함으로써 “이 인증서의 개인키 소유자가 실제로 이 핸드셰이크를 수행했다”라고 확인한다.

 

검증의 목적은 서버가 실제로 그 인증서(=도메인)에 대한 개인키를 가지고 있는지, 그리고 핸드셰이크 데이터가 위조되지 않았는지를 확인

 

공개키로 복호화하는 건 특정(옛)모드(RSA key-exchange)에서만 있었고, 요즘(=E(D)HE 방식, TLS1.3) 은 공개키로 서명 검증하고 DH로 공유키를 만들기 때문에 공개키로 데이터를 복호화하는 과정은 보통 없다.

 

TLS 에서 서버의 개인키는 핸드셰이크 단계 (서버인증 + 세션키 생성) 에서 사용하여 "내가 진짜 서버" 라는 것을 증명

 

 

3. 암호화된 메시지 송수신

 

실제 HTTP, HTML, JSON, 이미지 등 데이터 송수신은
서버 개인키가 아니라, 세션키(session key) 라는 대칭키로 암호화된다.

 

TLS가 핸드셰이크 과정에서 만들어낸 세션키(예: AES 128비트)를 기반으로
이후의 모든 통신이 아래와 같이 진행된다.

 

클라이언트 ──(AES 세션키로 암호화)──▶ 서버
서버 ──(같은 AES 세션키로 암호화)──▶ 클라이언트

 

대칭키를 쓰는 이유는 비대칭키는 느리다 -> 수학적 연산이 많아서 암복호화가 느림.