"비밀은 둘이 알면 비밀이 아니다." — 그런데 수천 명의 사용자가 서로를 신뢰해야 한다면? KDC는 바로 그 불가능을 가능하게 만든다.
🎯 이 글에서 다루는 것
KDC(Key Distribution Center)가 무엇이며 왜 필요한가
KDC를 구성하는 두 핵심 모듈, AS와 TGS의 역할
KDC가 관리하는 세 가지 키(마스터 키, 세션 키, 티켓)의 차이
티켓 기반 키 분배 흐름을 5단계로 완전 정복
실무에서 흔히 마주치는 KDC의 함정과 보안 원칙
📌 도입 — 왜 우리는 KDC가 필요한가?
회사에 직원이 1,000명 있다고 가정해 보자. 모든 직원이 서로 안전하게 통신하려면 몇 개의 비밀키가 필요할까? 정답은 약 499,500개(n×(n-1)/2)다. 이걸 어떻게 발급하고, 갱신하고, 폐기할까? 한숨이 절로 나온다.
이 문제를 푸는 가장 우아한 해법이 바로 KDC(Key Distribution Center) 다. KDC는 "모두가 신뢰하는 중앙 비밀 보관소"가 되어, 두 당사자가 서로 처음 만나는 순간에도 안전한 통신 채널을 열어준다. 이것이 바로 우리가 흔히 들어본 Kerberos 인증 시스템의 핵심이고, Active Directory가 내부적으로 돌리고 있는 메커니즘이며, 클라우드와 빅데이터 플랫폼(Hadoop, Spark 등) 인증의 표준이다.
🔍 KDC란 무엇인가 — 신뢰의 중심
KDC는 이름 그대로 "키를 분배해 주는 중앙 서버" 다. 모든 사용자와 서비스는 KDC에 자기 비밀키(마스터 키)를 미리 등록해 두고, 다른 누군가와 통신해야 할 때마다 KDC에 "쟤랑 안전하게 얘기할 수 있게 해 주세요"라고 부탁한다.
KDC는 두 개의 주요 서비스로 구성된다:
구성요소
영문
역할
인증 서버
AS (Authentication Server)
사용자가 누구인지 확인하고 첫 번째 티켓(TGT)을 발급
티켓 발급 서버
TGS (Ticket Granting Server)
실제 서비스 접근에 쓰이는 서비스 티켓을 발급
이렇게 인증과 티켓 발급을 분리한 이유는 단순하다. 사용자의 비밀번호(마스터 키)를 가능한 한 적게 사용하기 위해서다. 비밀번호는 하루에 한 번만 쓰고, 그 이후에는 임시 신분증(TGT)으로 대신한다는 발상이다.
🗝️ KDC가 다루는 세 가지 키
KDC의 키 관리를 이해하려면 키의 종류부터 명확히 구분해야 한다.
1. 마스터 키 (Master Key / Long-term Key)
사용자나 서비스가 KDC에 등록할 때 만드는 영구 비밀키다. 보통 사용자의 비밀번호를 해시한 값으로 만들어진다.
수명: 비밀번호 변경 전까지 유효 (수개월 ~ 수년)
저장 위치: KDC의 데이터베이스 + 사용자 본인 머릿속
중요 원칙:절대로 네트워크를 타고 흐르지 않는다. 마스터 키는 오직 "다른 키를 암호화하는 용도"로만 쓰인다.
2. 세션 키 (Session Key)
두 당사자가 짧은 시간 동안 통신할 때 사용하는 일회용 대칭키다. KDC가 그때그때 새로 만들어 준다.
수명: 보통 8~10시간 (정책에 따라 조정 가능)
특징: 매번 새로 생성되므로 한 번 노출돼도 피해가 제한적
장점: 마스터 키를 직접 노출시키지 않고도 두 당사자가 안전하게 통신 가능
3. 티켓 (Ticket)
KDC가 발급하는 암호화된 출입증이다. 안에는 세션 키와 사용자 정보, 유효 시간이 들어있다.
비유하자면 TGT는 "놀이공원 입장권", Service Ticket은 "각 놀이기구별 탑승권" 이다. 입장권 하나만 받아두면 그날 종일 재인증 없이 여러 놀이기구를 즐길 수 있다.
🔄 KDC의 키 분배 흐름 — 5단계 완전 정복
이제 진짜 흥미로운 부분이다. 사용자가 어떤 서비스에 접근할 때, KDC와의 사이에서 무슨 일이 벌어질까? 아래 다이어그램을 보면서 따라가 보자. (다이어그램은 본문 아래에 있다.)
[1단계] 사용자 → AS: 인증 요청 사용자(Alice)가 자기 ID를 평문으로 AS에 보낸다. 비밀번호는 보내지 않는다. 이 시점부터 KDC의 정교한 설계가 빛난다.
[2단계] AS → 사용자: TGT + 세션 키 AS는 두 가지를 만들어 응답한다.
TGT: TGS만 풀 수 있도록 TGS의 마스터 키로 암호화
세션 키(Alice ↔ TGS용): Alice의 마스터 키로 암호화해서 동봉
Alice는 자기 비밀번호로 마스터 키를 만들어 응답을 푼다. 풀리면 인증 성공. 이때 비밀번호는 네트워크를 단 한 번도 흐르지 않았다.
[3단계] 사용자 → TGS: 서비스 티켓 요청 이제 Alice는 TGT와 "어떤 서비스에 접근하고 싶은지"를 TGS에 보낸다. TGT는 TGS만 풀 수 있으므로 위변조가 불가능하다.
[4단계] TGS → 사용자: Service Ticket + 새 세션 키 TGS는 다시 두 가지를 만든다.
Service Ticket: 해당 서비스 서버의 마스터 키로 암호화
새 세션 키(Alice ↔ Service용): 기존 세션 키로 암호화
[5단계] 사용자 → 서비스 서버: 접근 Alice는 Service Ticket을 서비스 서버에 제시한다. 서비스 서버는 자기 마스터 키로 티켓을 풀어 Alice의 세션 키를 얻고, 이제 두 사람은 안전하게 통신할 수 있다.
핵심을 한 문장으로 요약하면 이렇다.
"KDC는 자신의 마스터 키를 이용해, 만난 적 없는 두 당사자에게 공통의 세션 키를 안전하게 심어준다."
🛡️ KDC 키 관리의 보안 원칙
KDC가 30년 넘게 살아남은 데는 이유가 있다. 다음 원칙들 덕분이다.
마스터 키 비전송 원칙: 마스터 키는 KDC와 클라이언트 사이에서도 절대 전송되지 않는다. 오직 키를 암호화하는 용도로만 쓰인다.
세션 키 단기성: 세션 키는 짧은 수명을 가지며, 만료되면 자동 폐기된다. 키 노출의 영향 범위를 최소화한다.
타임스탬프 기반 재전송 방지: 모든 메시지에 타임스탬프(Authenticator)를 포함하여, 누군가 패킷을 가로채 재전송해도 작동하지 않게 만든다.
티켓의 자급자족성: 서비스 서버는 KDC에 매번 묻지 않고도, 자기 마스터 키만으로 티켓을 검증할 수 있다. 이로써 KDC의 부하가 분산된다.
대칭키 기반의 효율성: AES-256 같은 대칭키 알고리즘을 사용해 빠른 암호화/복호화가 가능하다.
⚠️ 주의사항 — KDC를 운영할 때 빠지기 쉬운 함정
실무에서 KDC(특히 Kerberos/AD 환경)를 운영하다 보면 반드시 마주치는 문제들이 있다.
단일 실패점(SPOF)의 함정: KDC가 다운되면 전체 인증이 마비된다. 반드시 마스터 KDC + 슬레이브 KDC 이중화로 구성해야 한다.
시계 동기화(Clock Skew) 이슈: 타임스탬프 검증 때문에 클라이언트와 KDC의 시간 오차가 5분(기본값)을 넘으면 인증이 실패한다. NTP 서버 동기화가 필수다.
오프라인 사전 공격 가능성: 약한 비밀번호의 마스터 키는 가로챈 응답으로부터 오프라인에서 추측당할 수 있다. 강력한 비밀번호 정책 + Pre-authentication 활성화가 필요하다.
Kerberoasting 공격: 서비스 계정의 약한 비밀번호를 노린 공격이 실제로 매우 흔하다. 서비스 계정은 30자 이상의 랜덤 비밀번호나 gMSA(group Managed Service Account) 사용을 권장한다.
티켓 수명 관리: TGT 수명을 너무 길게 잡으면 탈취 시 위험이 커진다. 보통 10시간 이내로 제한하는 것이 표준이다.
✅ 정리 — KDC, 결국 무엇을 기억해야 하나
KDC의 키 관리는 결국 "마스터 키는 숨기고, 세션 키는 자주 갈고, 티켓으로 위임한다" 라는 세 줄로 정리할 수 있다. 사용자의 비밀번호를 단 한 번도 네트워크에 노출시키지 않으면서, 만난 적 없는 두 당사자가 즉시 안전한 통신을 시작할 수 있게 만드는 정교한 설계다.
다음 학습 단계로는 이런 주제들을 추천드린다.
Kerberos 5 RFC 4120 정독 — 프로토콜의 모든 디테일이 담겨 있다
Active Directory의 KDC 구현체 분석 — 실무 환경에서 가장 흔하게 만난다
PKINIT 확장 — 비밀번호 대신 인증서로 AS 인증을 수행하는 방식
클라우드 환경의 Kerberos — AWS Managed AD, Azure AD DS의 동작 방식
다음 시간에는 "Kerberoasting과 Golden Ticket 공격 — KDC를 노리는 실제 공격 시나리오" 로 이어가도 좋을 주제다.
