TLS·SSH와 보안 관리 프로토콜 | 정보보안기사 필기

보안 프로토콜은 통신 상대를 확인하고 전송 내용의 기밀성·무결성을 보호하기 위해 사용한다. 인증에 성공해도 수행 가능한 작업은 인가 정책으로 따로 제한한다.

1. 암호 기술의 역할을 서로 바꾸어 이해하지 않는다

키 교환, 인증, 데이터 보호는 다른 기능이다

기능	대표 수단	직접 증명·제공하는 것
키 교환(Key Exchange)	(EC)DHE, PSK 기반 교환, SSH KEX	양쪽이 공유 세션 키 재료를 만들도록 함
상대 인증	X.509 인증서·서명, SSH Host Key, PSK	연결 상대가 특정 키를 소유한다는 근거
사용자 인증	SSH 공개키 서명, 비밀번호, MFA	서버가 접속 사용자의 계정을 확인
데이터 보호	AES-GCM, ChaCha20-Poly1305 등 AEAD	대량 데이터의 기밀성과 무결성
권한 부여	계정 정책, ACL, 역할, Command 제한	인증된 주체가 수행할 수 있는 작업 제한

공개키 연산은 일반적으로 Handshake에서 키 교환이나 서명 검증에 사용되고, 실제 대량 데이터는 효율적인 대칭키로 보호된다. 따라서 “서버 공개키로 모든 응용 데이터를 암호화해 보내고 서버가 개인키로 계속 복호화한다”는 설명은 TLS 1.3이나 SSH-2의 일반적인 데이터 보호 흐름과 맞지 않는다.

서명은 암호화와 목적이 다르다

암호화는 권한 없는 사람이 내용을 읽기 어렵게 한다.
전자서명은 특정 개인키 소유자가 해당 데이터에 서명했음을 검증하게 한다.
인증서·호스트 키와 관련된 서명 검증은 상대의 개인키 소유와 교환 내용의 무결성을 확인하는 데 사용된다.
서명이 유효해도 그 서비스가 업무상 허가되었거나 안전한 콘텐츠를 제공한다는 뜻은 아니다.

2. TLS는 Handshake와 Record 보호로 나누어 이해한다

TLS(Transport Layer Security)는 신뢰하기 어려운 네트워크에서 클라이언트와 서버 사이의 보호 채널을 만든다. HTTPS가 대표적이지만, TLS는 특정 응용 프로토콜 하나에 종속되지 않는다.

TLS의 두 핵심 구성요소

Handshake Protocol
- 사용할 TLS 버전과 암호 매개변수를 협상한다.
- 키 교환으로 공유 비밀을 만든다.
- 인증서·서명 또는 PSK로 상대를 인증한다.
- 이후 Record 보호에 사용할 Traffic Key를 파생한다.
Record Protocol
- 응용 데이터를 Record 단위로 나눈다.
- 설정한 알고리즘과 키로 기밀성·무결성을 제공한다. TLS 1.3에서는 AEAD를 사용한다.
- 방향별로 별도 키와 Nonce 상태를 관리한다.

TLS가 TCP 위에서 동작하는 경우 TCP는 신뢰성 있는 바이트 스트림을 제공하고, TLS가 그 스트림 위에서 암호학적 보호를 추가한다. TCP 연결이 정상이라는 사실만으로 TLS 상대가 검증된 것은 아니다.

SSL·TLS 버전의 기본 구분

구분	시험 관점
SSL 2.0·3.0	취약한 구형 프로토콜로 사용하지 않는다.
TLS 1.0·1.1	구형 버전으로 현대 환경에서는 사용을 중단한다.
TLS 1.2	안전한 알고리즘과 올바른 설정이 필요하며 기존 환경에서 널리 사용된다.
TLS 1.3	구형 알고리즘을 줄이고 Handshake와 보호 구조를 단순화·강화했다.

제품 화면의 SSL 인증서, SSL VPN이라는 이름만 보고 실제로 SSL 3.0을 사용한다고 판단하면 안 된다. 실제 협상 버전과 암호 설정을 별도로 확인한다.

3. TLS Handshake의 핵심 흐름

다음은 인증서를 사용하는 TLS 연결의 기능을 단순화한 흐름이다. 정확한 메시지 순서는 버전에 따라 다르고, PSK 방식 등에서는 인증서 교환을 하지 않을 수 있다.

Client와 Server가 지원 Version·암호 방식·난수를 교환한다.
Key Exchange로 공유 비밀을 만들고 Session Key를 파생한다.
Server는 Certificate와 서명으로 신원을 증명한다.
양쪽이 Handshake 내용이 변조되지 않았음을 확인한다.
이후 Application Data는 대칭키로 암호화·무결성 보호한다.

시험에서는 Message 이름을 모두 암기하기보다 협상·키 설정·상대 인증이 데이터 보호로 연결되는 관계를 이해한다.

4. 인증서와 Host 검증

Certificate는 공개키와 주체 정보를 CA 서명으로 연결한다. Client는 서명 Chain, 유효기간, 폐기 여부, 접속한 Host Name과 Certificate의 일치 여부를 확인해야 한다.

CA 서명만 유효하다고 안전한 통신이 되는 것은 아니며, 잘못된 Host Certificate 경고를 무시하면 중간자 공격에 노출될 수 있다.

5. SSH의 세 기능

SSH는 원격 관리 통신을 보호하며 다음 기능을 구분한다.

전송 계층: Server Host Key 확인, Key Exchange, 암호화·무결성 보호
사용자 인증: Password·Public Key 등으로 사용자 신원 확인
연결 계층: Shell·Command·File Transfer·Port Forwarding Channel 제공

SSH Port는 일반적으로 TCP 22지만 Port 번호만으로 실제 Protocol을 확정하지 않는다.

6. SSH에서 구분할 키

Host Key: Server 신원을 확인한다.
User Key: 사용자가 개인키 소유를 서명으로 증명한다.
Session Key: 실제 연결의 암호화·무결성 보호에 사용한다.

Host Key 변경 경고는 장비 교체일 수도 있고 중간자 공격일 수도 있으므로 별도 경로로 Fingerprint를 확인한다.

7. Telnet·SSH·SNMP 보안 비교

프로토콜	대표 Port	보안 특징
Telnet	TCP 23	계정·명령을 평문으로 전송할 수 있어 보호되지 않은 관리망에서 사용하지 않는다.
SSH	TCP 22	서버 인증, 사용자 인증, 기밀성·무결성을 제공한다.
SNMPv1·v2c	UDP 161/162	Community String 기반이며 자체 기밀성 보호가 약하다.
SNMPv3	UDP 161/162	사용자 기반 인증·무결성·선택적 암호화를 제공할 수 있다.

원격 관리 Protocol은 관리망 분리, Source 제한, 강한 인증과 로그 기록을 함께 적용한다.

SNMPv3도 설정에 따라 noAuthNoPriv(인증·암호화 없음), authNoPriv(인증·무결성), authPriv(인증·무결성·암호화)로 구분된다. 버전 이름만으로 암호화 사용을 확정하지 않는다.