Kerberos 티켓 기반 인증의 구조와 운영 고려사항
Kerberos의 AS·TGS·KDC 구조와 티켓 기반 인증 흐름, Active Directory 및 리눅스 환경의 운영 고려사항을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
티켓을 거쳐 서비스에 도달하는 인증 방식
Kerberos는 개방형 네트워크에서 사용자 인증을 안전하게 처리하기 위한 프로토콜이다. MIT에서 개발됐으며, 이름은 그리스 신화에 나오는 세 개의 머리를 가진 지옥의 문지기에서 가져왔다.
중앙화된 제3자 인증 시스템을 통해 네트워크 통신을 보호하고, 대칭키 암호화를 사용해 패스워드가 네트워크에 노출되지 않도록 설계됐다. 마이크로소프트 윈도우 서버의 Active Directory와 유닉스·리눅스 환경에서 널리 쓰인다.
인증을 나누어 맡는 주체
AS(Authentication Server)는 사용자의 최초 인증을 처리한다. 사용자 ID와 패스워드를 확인한 뒤 TGT(Ticket Granting Ticket)를 발급하고, 사용자 인증 데이터베이스를 관리한다. 실제 구현에서는 KDC(Key Distribution Center)의 일부로 동작한다.
TGS(Ticket Granting Server)는 TGT를 검증한 뒤 특정 서비스에 접근할 수 있는 티켓을 만든다. 이 역시 실제 구현에서는 KDC의 일부다.
티켓은 클라이언트의 신원을 증명하는 암호화된 데이터 구조다. AS가 발급하는 TGT는 TGS 접근 권한을 제공하고, TGS가 발급하는 서비스 티켓은 특정 서비스 접근 권한을 제공한다. 두 티켓 모두 제한된 유효 기간을 가진다.
Service Server는 티켓을 검증한 후 실제 서비스를 제공한다. 이를 위해 서비스 서버는 자체 서비스 키를 KDC와 공유한다. Client는 사용자 또는 서비스 요청자로서, 패스워드 기반의 비밀키와 티켓을 이용해 인증 절차에 참여한다.
AS에서 서비스 서버까지 이어지는 흐름
초기 인증인 AS Exchange에서 클라이언트는 사용자 ID만 AS에 보내며, 패스워드는 전송하지 않는다. AS는 사용자 ID를 확인하고 TGT와 TGS 사이에서 사용할 세션 키를 생성한다. TGT는 TGS의 비밀키로 암호화하고, 세션 키는 클라이언트의 비밀키로 암호화해 전달한다. 클라이언트는 패스워드 기반의 비밀키로 세션 키를 복호화한다.
TGS Exchange에서는 클라이언트가 TGT, 서비스 ID, Authenticator를 TGS에 전송한다. Authenticator에는 timestamp와 클라이언트 ID가 포함되며 TGS와의 세션 키로 암호화된다. TGS는 TGT를 복호화하고 Authenticator를 검증한 뒤, 유효하면 서비스 티켓과 서비스 세션 키를 발급한다. 서비스 티켓은 서비스 서버의 키로, 서비스 세션 키는 TGS 세션 키로 암호화해 보낸다.
Client/Server Exchange 단계에서 클라이언트는 서비스 티켓과 새 Authenticator를 서비스 서버에 제출한다. 서버는 이를 복호화하고 검증한다. 필요하면 서버는 세션 키로 암호화한 타임스탬프를 응답해 상호 인증을 수행하며, 인증이 끝나면 서비스를 제공한다.
단일 로그인과 중앙 인증의 교환 조건
Kerberos는 한 번의 인증으로 여러 서비스에 접근할 수 있는 단일 로그인(Single Sign-On)을 제공한다. 네트워크로 패스워드를 전송하지 않고, 클라이언트와 서버가 서로 신원을 확인할 수 있다. 티켓에는 유효 기간이 있으며 서비스별로 티켓과 권한을 다르게 부여할 수 있다.
대신 구성 요소의 시계가 동기화돼야 하며, 일반적으로 5분 이내의 동기화가 필요하다. KDC는 단일 장애점(SPOF)이 될 수 있고, 초기 설정과 관리도 복잡하다. KDC와 서비스가 공유하는 많은 수의 비밀키를 관리해야 한다는 점도 운영 부담으로 남는다.
플랫폼별 활용 방식
Windows 2000부터 Windows는 Kerberos를 기본 인증 프로토콜로 채택했다. 도메인 컨트롤러가 KDC 역할을 수행하며, 그룹 정책과 연동해 세밀한 접근 제어를 제공한다. 사용자가 도메인에 로그인하면 Kerberos 티켓이 자동으로 발급된다.
리눅스와 유닉스 환경에서는 MIT Kerberos 또는 Heimdal Kerberos 구현체를 사용할 수 있다. SSH, NFS, LDAP 같은 서비스와 통합할 수 있으며, PAM(Pluggable Authentication Modules)을 통해 시스템 인증과 연결한다. Red Hat 계열에서는 FreeIPA/IdM이 통합 ID 관리 솔루션을 제공한다.
크로스 플랫폼 환경에서는 Active Directory와 리눅스·유닉스 시스템 사이의 Kerberos 인증을 연동할 수 있다. 웹 애플리케이션은 SPNEGO/GSS-API로 싱글 사인온을 구현하며, 하둡(Hadoop) 생태계에서도 보안 인증 메커니즘으로 활용된다.
티켓과 KDC를 보호할 때 보는 지점
약한 패스워드는 오프라인 사전 공격에 취약하다. 메모리에서 티켓 정보를 추출할 가능성도 있으므로 Pass-the-Ticket 공격을 고려해야 한다.
암호화 알고리즘은 레거시 RC4 대신 AES 사용을 권장한다. 장시간 유효한 티켓은 보안 위험을 키울 수 있으므로 티켓 갱신을 관리하고, KDC는 물리적·논리적으로 철저히 보호해야 한다. 위임이 필요할 때는 제한된 위임(Constrained Delegation) 기능을 활용한다.
공개키·클라우드 환경으로의 확장
PKINIT는 공개키 인프라와 Kerberos를 통합해 스마트카드 인증을 지원한다. 암호화는 레거시 RC4/DES에서 AES-256으로 전환하는 방향이며, 모바일 기기에서 Kerberos를 사용하는 방안도 개발되고 있다.
제로 트러스트 아키텍처에 Kerberos를 통합하거나, 하이브리드·멀티 클라우드 환경에서 통합 인증을 제공하는 방식도 적용 대상이다. Kerberos는 대규모 네트워크에서 안전하고 효율적인 인증을 제공하면서, 단일 로그인과 강력한 인증 메커니즘을 함께 제공한다. 다양한 플랫폼에 구현할 수 있지만 시간 동기화와 중앙 서버 의존성은 계속 관리해야 할 조건이다.