안정성을 위한 기술
사용자가 폭증하면 서버가 불안정해지고 부하가 가증될 것이다.
이럴 때 어떤 기술을 사용해서 해결할까?
네트워크가 안정적이다 라고 말할 때의 안정성은 특정 기능을 언제든 균일한 성능으로 수행할 수 있는 특성 으로 정의될 수 있다.
그렇다면 안정성은 어떻게 수치화할 수 있을까?
안정성의 정도를 나타내는 용어로 가용성 과 고가용성 이라는 용어가 있다.
가용성
가용성 이란 컴퓨터 시스템이 특정 기능을 실제로 수행할 수 있는 시간의 비율이다.
다시 말해, 전체 사용 시간 중에서 정상적인 사용 시간을 의미한다.
이를 수식으로 나타내면 다음과 같다.
업타임이란 정상적인 사용시간을, 다운 타임이란 정상적인 사용이 불가능한 시간을 의미한다.
해당 수식의 결괏값이 크다는 것은, 전체 사용 시간 중에서 대부분을 사용 가능하다는 의미이며, 이를 가용성이 높다 라고 말한다.
가용성이 높은 성질을 고가용성(HA; High Availability)
일반적으로 안정적이라고 평가받는 시스템은 99.999% 이상을 목표로 한다.
9가 다섯개 라는 의미에서 파이브 나인스 라고도 한다.
가용성을 높이려면 다운타임을 낮춰야 한다.
다운타임의 발생 원인을 모두 찾아 원천적으로 차단하기는 실질적으로 어려우므로, 문제가 발생하덜도 계속 가능할 수 있도록 설계하는 것이 중요하다.
문제가 발생하덜도 기능할 수 있는 능력을 결함 감내 라고 부른다.
이중화
이중화 란 결함을 감냏여 가용성을 높이기 위한 가장 기본적이고 대표적인 방법으로, 쉽게 말해서 예비(백업)을 마련하는 방법 이다.
이중화할 수 있는 대상은 다양하다.
서버 컴퓨터 네트워크 인터페이스(NIC) 스위치 와 같은 물리적 장비 뿐만 아니라, 데이터베이스 웹 서버 프로그램 등도 이중화할 수 있는 대상이다.
이중화할 수 있는 대상들은 대부분 문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상 이라는 공통점이 있다.
문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상 을 가리키는 용어가 있는데,
이것이 바로 단일 장애점(SPOF; Single Point Of Failure) 이다.
예를 들어, 다음 그림에서 라우터가 고장나면 제공받는 서비스 전체가 동작하지 않기 때문에 SPOF는 라우터이다.
가용성을 높이기 위해서는 SPOF를 이중화하는 것이 좋다.
이중화 구성 방식
이중화 구성에는 크게 두 가지 방식이 있다.
액티브/스탠바이(active-standby) 와 액티브/액티브(active-active) 이다.
액티브 란 가동 상태를 의미하며 스탠바이 는 액티브의 백업으로서 대기하는 상태를 의미한다.
액티브/스탠바이
한 시스템은 가동하고, 다른 시스템은 백업 용도로 대기 상태(스탠바이)로 두는 이중화 구성 방식이다.
시스템에 문제가 발생할 경우 스탠바이 시스템이 자동으로 액티브 시스템을 대신하여 동작한다.
이렇게 자동전환 되는 기능을 페일오버(failover) 라고 한다.
하지만, 두 장비가 동시에 가동되는 것은 아니기에 하나의 장비를 사용할 때에 비해 성능상의 큰 변화를 기대하기는 어렵다.
액티브/액티브
두 시스템 모두를 가동 상태로 두는 구성 방식이다.
이렇게 구성하면 부하를 분산시킬 수 있어 성능상의 이점을 가질 수 있다.
다만, 한 시스템에 문제가 발생하면 순간적으로 다른 시스템에 부하가 급증할 수 있으며, 이로 인해 추가적인 문제가 발생할 수 있다.
다중화
이중화가 무언가를 이중으로 두는 기술 이라면, 무언가를 여러 개 두는 기술 인 다중화도 있다.
다중화하면 이중화된 구성에 비해 더욱 안정적인 운영이 가능하다.
이중화/다중화의 사례로 윈도우에서 사용되는 티밍 과 리눅스에서 사용되는 본딩이 있다.
두 기술은 여러개의 네트워크 인터페이스(NIC)를 이중화/다중화하여 마치 더 뛰어나고 안정적인 성능을 보유한 하나의 인터페이스처럼 보이게 하는 기술이다.
예를 들어, 1Gbps 속도를 지원하는 인터페이스 세 개를 티밍하여 하나의 3Gbps 인터페이스를 사용하는 것과 같은 효과를 얻을 수 있다.
로드 밸런싱
고가용성을 요구하는 호스트는 일반적으로 서버이므로, 서버 중심으로 얘기해보자.
서버를 다중화했더라도 특정 서버에만 트래픽이 몰릴 경우, 가용성이 떨어질 수 있다.
트래픽의 사전적 정의는 주어진 시점에 네트워크를 경유한 데이터의 양 인데, 일반적으로 트래픽 측정은 노드에서 이루어지므로 주어진 시점에 특정 노드를 경유한 패킷의 양 이라고 이해하면 되겠다.
트래픽의 고른 분배를 위해 사용되는 기술이 로드 밸런싱(load balancing) 이다.
로드 밸런싱은 로드 밸런서 에 의해 수행된다.
로드 밸런서는 L4 스위치 L7 스위치 로 수행할 수도 있지만, 로드 밸런싱 기능을 제공하는 소프트웨어를 설치하면 일반 호스트로도 로드 밸런서를 사용할 수 있다.
로드 밸런서는 다음 그림처럼 이중화나 다중화된 서버와 클라이언트 사이에 존재한다.
클라이언트는 로드 밸런서에 요청을 보내고, 로드 밸런서는 해당 요청을 각 서버에 균형있게 분배한다.
다중화된 서버 환경에서 어떤 서버에 문제가 생긴다면 다른 서버들이 이를 빠르게 감지할 수 있어야 할텐데, 현재 상태를 주기적으로 체크하는 검사를 헬스 체크 라고 한다.
이 헬스 체크는 주로 로드 밸런서에 의해 수행된다.
로드 밸런싱 알고리즘
로드 밸런서가 요청을 전달할 수 있는 서버가 여러 개 있을 경우, 어떤 서버에 요청을 전달해야 할까?
부하가 균등하게 분산되도록 부하 대상을 선택하는 방법을 로드 밸런싱 알고리즘 이라고 한다.
대표적인 로드 밸런싱 알고리즘에는 단순히 서버를 돌아가며 부하를 전달하는 라운드 로빈 알고리즘(round robin) 과 연결이 적은 서버부터 우선적으로 부하를 전달하는 최소 연결 알고리즘(least connection) 이 있다.
두 알고리즘은 가중치 를 부여해서 알고리즘에 따라 동작하되 가중치가 높은 서버가 더 많이 선택되어 더 많은 부하를 받도록 동작할 수도 있는데, 이를 각각 가중치 라운드 로빈 알고리즘 과
가중치 최소 연결 알고리즘 이라 한다.
라운드 로빈 알고리즘이 아래 그림과 같이 단순히 서버를 돌아가며 부하를 전달한다면,
가중치 라운드 로빈 알고리즘은 두 번째 그림과 같이 가중치가 다섯 배인 서버 1에 다섯 배 많은 부하를 전달한다.
암호와 인증서
멀리 떨어진 컴퓨터와 민감한 메시지를 주고 받기 위해서는 암호화가 필요하다.
암호화 란 원문 데이터를 알아볼 수 없는 형태로 변경하는 것을,
복호화 란 암호화된 데이터를 원문 데이터로 되돌리는 것을 의미한다.
대칭 키 암호화 방식과 공개 키 암호화 방식
키와 원문 데이터 에 수학적 연산 과정을 거치면 암호문 이 생성된다.
이 수학적 연산 과정을 암호화 알고리즘 이라 한다.
주고 받는 데이터를 암호화하고 복호화하는 방법에는 대칭 키 암호화와 비대칭 키(공개 키) 암호화 방식이 있다.
대칭 키 암호화 방식
다음 그림과 같이 암호화와 복호화에 동일한 키를 사용하는 방식이다.
다만, 이 방식은 상대방에게 안전하게 키를 전달하기가 어렵다는 문제가 있다.
암호화 키와 복호화 키가 동일하기 때문에, 키가 유출된다면 큰 문제가 발생할 것이다.
키를 안전하게 상대방과 공유하는 방법 은 사실상 메시지를 안전하게 상대방과 공유하는 방법 과 다를 바가 없으므로, 그 방법으로 메시지를 주고받으면 되지, 굳이 암호화를 할 필요가 없을 것이다.
그래서 등장한 것이 공개 키 암호화(비대칭키 암호화) 방식이다.
공개 키 암호화(비대칭키 암호화) 방식
암호화를 위한 키와 복호화를 위한 키가 다른 방식이다.
이 한 쌍의 키를 각각 공개 키 와 개인 키 라 부른다.
암호화를 위해 사용된 공개 키 는 이름처럼 누구에게나 공개해도 무방하고, 암호화만을 위해 사용되었기 때문에 원문 메시지를 유추할 수 있지도 않다.
만약, A가 B에게 안녕, 나는 A야 라는 문자열을 안전하게 전송하고자 한다면, 어떤 일이 일어나는지 확인해보자.
- A가 B의 공개 키를 요청하고, B는 A에게 공개 키를 전달한다. (공개 키는 그냥 전송해도 된다.)
- A는 전달받은 공개 키로 메시지를 암호화하고, B에게 전송한다. (제 3자가 보아도 암호문을 이해할 수 없다.)
- 개인 키를 가지고 있는 B가 암호를 복호화하여
안녕 나는 A야라는 문자열을 확인할 수 있다.
공개 키 암호화 방식은 대칭 키 암호화 방식에 비해 암호화 및 복호화에 시간과 부하가 상대적으로 많이 들지만, 키를 안전하게 공유할 수 있다는 장점이 있다.
하지만, 대칭 키 암호화는 암호화 및 복호화를 빠르게 수행할 수 있기 때문에, 이 두 방식을 결합하여 사용하는 방식이 많다.
대칭 키 암호화 방식 + 공개 키 암호화 방식
공개 키 암호화 방식에서 복호하여 메시지 원문을 얻었다면, 이 방식에서는 대칭 키를 복호화한다고 생각하면 편하다.
대칭 키(세션 키)를 안전하게 공유하는 것이 문제 였기 때문에, 이 대칭 키를 공개 키 암호화 방식 으로 암호화 한 뒤, 전달 받는 쪽에서는 개인키로 복호화 하여 대칭 키를 얻고, 그 대칭 키로 메시지 본문을 얻는 방식이다.
이러한 방식으로 활용되는 대칭 키를 세션 키 라고한다.
인증서와 디지털 서명
인증서
인증서 라는 용어는 일반적으로 공개 키 인증서 를 일컫는다.
공개 키 인증서 란 공개 키와 공개 키의 유효성을 입증하기 위한 전자 문서이다.
내 컴퓨터가 웹 서버와 공개 키 암호화 방식으로 통신한다고 가정했을 때, 나는 웹 서버로부터 공개 키를 전달받게 될 것이다.
그런데, 과연 이 공개키를 신뢰할 수 있는가?
이에 대한 신뢰성을 위해 웹 서버는 아래와 같이 여러 내용을 포함한 인증서를 전송한다.
이러한 인증서는 인증 기관(CA; Certification Authority) 라는 제 3의 기관에서 발급한다.
인증 기관 은 인증서의 발급, 검증, 저장과 같은 역할을 수행할 수 있는 공인 기관이다.
인증서에는 이 공개 키 인증서는 진짜야. 내가 보증할게 라는 내용을 담은 서명(signature)이 있고, 이 값을 바탕으로 인증서를 검증할 수 있다.
서명 값은 인증서 내용에 대한 해시 값(fingerprint) 을 CA 의 개인 키로 암호화하는 방식 으로 만들어진다.
CA는 이렇게 얻어낸 정보를 서명 값으로 삼아 클라이언트에게 인증서와 함께 전달한다.
디지털 서명
디지털 서명 이란 개인 키로 암호화 된 메시지를 공개 키로 복호화함으로써 신원을 증명하는 절차를 말한다.
CA가 보낸 서명 은 해시 값을 개인키로 암호화 한 것 이라고 했다.
그럼 우린 이 서명을 복호화하여 해시 값을 얻고, 우리가 직접 인증서 데이터에 대한 해시 값을 구한 뒤, 비교할 것이다.
값이 일치한다면 인증서는 확실히 CA의 개인 키로 만들어졌음을 보장한다.
HTTPS: SSL과 TLS
지금까지 배운 대칭 키 암호화와 공개 키 암호화 방식, 공개 키 인증서를 기반으로 동작하는 프로토콜로 SSL(Secure Socket Layer) 과 TLS(Transport Layer Security) 가 있다.
SSL과 TLS는 인증과 암호화를 수행하는 프로토콜이며, TLS는 SSL을 계승한 프로토콜이다.
SSL/TLS를 사용하는 대표적인 프로토콜은 HTTPS(HTTP over TLS) 이다.
HTTPS 는 HTTP 메시지의 안전한 송수신을 위해 개발된 프로토콜이다.
오늘날 주로 사용되는 TLS 1.3을 기반으로 HTTPS가 어떻게 동작하는지 간략하게 알아보자.
HTTPS 메시지는 크게 다음과 같은 단계를 거쳐 송수신한다.
- TCP 쓰리 웨이 핸드셰이크 (4장 학습)
- TLS 핸드셰이크
- 암호화된 메시지 송수신
1. TCP 쓰리 웨이 핸드셰이크
1번은 이전에 학습했다.
TCP 연결을 수립하기 위해 두 호스트가 각각 SYN, SYN+ACK, ACK 플래그가 설정된 TCP 세그먼트를 주고받는 것이 쓰리 웨이 핸드셰이크였다.
2. TLS 핸드셰이크
꽤 복잡하지만, TLS는 암호학에 대한 기반 지식을 요하기 때문에 처음부터 모든 메시지와 의미를 외울 필요는 없다고 한다.
TLS 핸드셰이크의 핵심은 두 가지이다.
1. 암호화 통신을 위한 키를 교환한다 2. 인증서 송수신과 검증이 이루어진다.
위 그림의 메시지를 살펴보자.
Client Hello
가장 먼저 클라이언트는 ClientHello 메시지를 보낸다.
해당 메시지는 암호화된 통신을 위해 서로 맞춰 봐야 할 정보들을 제시하는 메시지이다.
지원되는 TLS 버전 사용 가능한 암호화 방식과 해시 함수 키를 만들기 위해 사용할 클라이언트의 난수 등이 포함되어 있다.
이 때, 사용 가능한 암호화 방식과 해시 함수를 담은 정보를 암호 스위트(cipher suite) 라고 한다.
다음 그림처럼 생겼다.
Server Hello
서버는 Client Hello 에 대한 메시지 응답으로 ServerHello 메시지를 전송한다.
Server Hello 메시지는 제시된 정보들을 선택하는 메시지이다.
따라서 이 메시지에는 선택된 TLS 버전 암호 스위트 등의 정보 키를 만들기 위해 사용할 서버의 난수 등이 포함되어 있다.
Client Hello 와 Server Hello 메시지를 주고 받으면 암호화된 통신을 위해 사전 협의해야 할 정보들이 결정된다.
이렇게 결정된 정보를 토대로 서버와 클라이언트는 암호화에 사용할 키를 만들 수 있다.
이것이 TLS 핸드셰이크에서의 키 교환이다.
이 단계 이후부터 클라이언트와 서버는 키로 암호화된 암호문을 주고받을 수 있게 된다.
Certificate , CertificateVerify
서버는 인증서 를 의미하는 Certificate 메시지와 검증을 위한 디지털 서명 을 의미하는 CertificateVerify 메시지를 전송한다.
클라이언트는 이 메시지를 토대로 서버의 공개 키를 검증하게 된다.
Finished
이어서 서버와 클라이언트는 TLS 핸드셰이크의 마지막을 의미하는 Finished 메시지를 주고 받는다.
이 후, TLS 핸드셰이크를 얻어낸 키를 기반으로 암호화된 데이터를 주고받는다.
TLS 1.3 에서는 Finished 메시지와 함께 암호화된 메시지를 전송할 수 있다.
HTTPS에 대해서 설명해주세요.
HTTPS는 HTTP와 달리 SSL/TLS 프로토콜을 통해 데이터를 암호화하여 전송하기 때문에 보안적인 측면에서 우수한 장점이 있습니다.
SSL/TLS이 뭔가요?
SSL은 컴퓨터 네트워크에서 통신 보안을 제공하는 프로토콜입니다.
SSL은 핸드셰이크 과정에서 인증 기관, 인증서, 공개키 암호화, 대칭키 암호화를 사용하여 클라이언트와 서버 간의 암호화된 통신을 가능하게 합니다.
TLS는 SSL이 표준화되면서 변경된 이름입니다.
대칭키 암호화 방식에 대해 설명해주세요.
대칭키 암호화는 하나의 동일한 키를 사용하여 암호화와 복호화를 수행하는 방식입니다. 암호화 및 복호화 속도가 빠르다는 장점이 있지만, 안전하게 키를 공유하기 어렵다는 단점이 있습니다.
비대칭키(공개키) 암호화 방식에 대해서 설명해주세요.
비대칭키 암호화는 서로 다른 키를 사용하여 암호화와 복호화를 수행하는 방식입니다.
암호화에 사용하는 공개키와 복호화에 사용하는 개인키 한 쌍으로 이루어져 있으며, 공개키는 누구나 알 수 있지만 개인키는 비밀로 유지됩니다.
이 방식은 키를 안전하게 공유할 수 있다는 장점이 있지만, 대칭키 암호화보다 연산 속도가 느리다는 단점이 있습니다.
전자 서명에 대해서 설명해주세요.
전자 서명은 비대칭키 암호화 방식을 사용하여, 개인키로 데이터를 암호화하고 공개키로 이를 검증하는 기술입니다.
전자 서명이 공개키로 검증 가능하다는 점을 이용해, 특정 개인이 서명했음을 신뢰할 수 있습니다.
HTTPS 암호화 과정에 대해 설명해주세요. (SSL Handshake의 동작 과정을 설명해 주세요.)
SSL HandShake는 크게 4단계로 이루어집니다.
첫 번째로, 클라이언트는ClientHello메시지를 보냅니다.
이 메시지에는 지원하는 TLS 버전, 암호 스위트, 키 생성을 위한 클라이언트 난수 등이 포함되어 있습니다.
두 번째로 서버는Client Hello에 대한 메시지 응답으로ServerHello메시지를 전송합니다.
이 메시지에는선택된 TLS 버전암호 스위트키 생성을 위한 서버의 난수등이 포함되어 있습니다.
세 번째로, 클라이언트는 서버의 공개키로 세션 키를 암호화하여 서버에 보내면, 서버는 자신의 개인 키로 복호화하여 세션 키를 얻게 됩니다. 이후 클라이언트와 서버는 이 세션 키를 이용해 대칭키 암호화 방식으로 데이터를 주고 받습니다.
마지막으로, 클라이언트와 서버는 대칭키 암호화를 사용해 본격적인 HTTPS 통신을 시작합니다.
