Kerberos: 신뢰할 수 있는 제3자 인증 프로토콜

개요

Kerberos는 개방형 네트워크 환경에서 안전한 사용자 인증을 제공하는 프로토콜
MIT에서 개발된 네트워크 인증 프로토콜로 그리스 신화의 세 개의 머리를 가진 지옥의 문지기 이름에서 유래
중앙화된 제3자 인증 시스템을 통해 안전한 네트워크 통신 보장
대칭키 암호화 방식을 기반으로 하여 패스워드가 네트워크상에 노출되지 않도록 설계
현재 마이크로소프트 윈도우 서버의 Active Directory, 유닉스/리눅스 환경에서 널리 사용 중

Kerberos의 핵심 구성요소

1. AS(Authentication Server)

사용자 최초 인증 담당
사용자 ID와 패스워드 확인 후 TGT(Ticket Granting Ticket) 발급
사용자 인증 데이터베이스 관리
실제 구현에서는 KDC(Key Distribution Center)의 일부로 동작

2. TGS(Ticket Granting Server)

서비스 접근 티켓 발급 담당
클라이언트가 제출한 TGT 검증 후 서비스 접근용 티켓 생성
실제 구현에서는 KDC의 일부로 동작

3. Ticket

클라이언트의 신원을 증명하는 암호화된 데이터 구조
TGT(Ticket Granting Ticket): AS에서 발급, TGS 접근 권한 제공
서비스 티켓: TGS에서 발급, 특정 서비스 접근 권한 제공
제한된 유효 기간을 가짐

4. Service Server

실제 서비스 제공하는 서버
Kerberos 티켓을 검증하여 클라이언트에게 서비스 제공
자체적인 서비스 키를 KDC와 공유

5. Client

사용자/서비스 요청자
티켓을 이용해 서비스에 접근
자신의 비밀키(패스워드 기반)를 이용해 인증 과정 참여

Kerberos 인증 프로세스

sequenceDiagram
    participant C as Client
    participant AS as Authentication Server
    participant TGS as Ticket Granting Server
    participant SS as Service Server

    C->>AS: 1. 인증 요청 (사용자 ID)
    AS->>C: 2. TGT + 세션 키(클라이언트 비밀키로 암호화)
    C->>TGS: 3. TGT + 서비스 ID + Authenticator
    TGS->>C: 4. 서비스 티켓 + 서비스 세션 키
    C->>SS: 5. 서비스 티켓 + 새 Authenticator
    SS->>C: 6. 서비스 응답 (선택적 인증)

상세 인증 과정

초기 인증 단계 (AS Exchange)
- 클라이언트가 사용자 ID를 AS에 전송 (패스워드는 전송하지 않음)
- AS는 사용자 ID를 확인하고 TGT와 TGS와의 세션 키 생성
- TGT는 TGS의 비밀키로 암호화, 세션 키는 클라이언트의 비밀키로 암호화하여 전송
- 클라이언트는 자신의 비밀키로 세션 키를 복호화 (패스워드 기반)
티켓 부여 단계 (TGS Exchange)
- 클라이언트가 TGT, 서비스 ID, 그리고 Authenticator(timestamp, 클라이언트 ID 포함)를 TGS에 전송
- Authenticator는 TGS와의 세션 키로 암호화
- TGS는 TGT를 복호화하고 Authenticator 검증
- 유효할 경우, 서비스 티켓과 서비스 세션 키 발급
- 서비스 티켓은 서비스 서버의 키로 암호화, 서비스 세션 키는 TGS 세션 키로 암호화하여 전송
서비스 접근 단계 (Client/Server Exchange)
- 클라이언트가 서비스 티켓과 새로운 Authenticator를 서비스 서버에 전송
- 서비스 서버는 티켓을 복호화하고 Authenticator 검증
- 선택적으로 서비스 서버는 세션 키로 암호화된 타임스탬프로 응답하여 상호 인증 수행
- 인증이 완료되면 서비스 제공

Kerberos 특징

장점

단일 로그인(Single Sign-On): 한 번의 인증으로 여러 서비스 접근 가능
패스워드 비노출: 네트워크상에 패스워드가 전송되지 않음
상호 인증: 클라이언트와 서버가 서로 신원 확인 가능
시간 제한: 티켓에 유효 기간이 있어 보안성 강화
정교한 접근 제어: 서비스별로 다른 티켓과 권한 부여 가능

단점

시간 동기화 필요: 모든 구성 요소의 시계가 동기화되어야 함 (일반적으로 5분 이내)
중앙 서버 의존성: KDC가 단일 장애점(SPOF)이 될 수 있음
복잡한 구현: 초기 설정과 관리가 복잡함
비밀키 관리: 많은 수의 비밀키 관리가 필요

실제 구현 사례

1. 윈도우 Active Directory

Windows 2000부터 기본 인증 프로토콜로 Kerberos 채택
도메인 컨트롤러가 KDC 역할 수행
그룹 정책과 연동하여 세밀한 접근 제어 제공
사용자가 도메인에 로그인하면 자동으로 Kerberos 티켓 발급

graph TD
    A[사용자 로그인] --> B[도메인 컨트롤러]
    B --> C{인증 성공?}
    C -->|예| D[TGT 발급]
    C -->|아니오| E[로그인 실패]
    D --> F[도메인 리소스 접근]
    F --> G[서비스 티켓 요청]
    G --> H[리소스 사용]

2. 리눅스/유닉스 환경

MIT Kerberos나 Heimdal Kerberos 구현체 사용
SSH, NFS, LDAP 등 다양한 서비스와 통합 가능
PAM(Pluggable Authentication Modules)을 통한 시스템 인증 연동
Red Hat 계열에서는 FreeIPA/IdM으로 통합 ID 관리 솔루션 제공

3. 크로스 플랫폼 환경

Active Directory와 리눅스/유닉스 시스템 간 Kerberos 인증 연동
웹 애플리케이션에서 SPNEGO/GSS-API를 통한 싱글 사인온 구현
하둡(Hadoop) 생태계에서 보안 인증 메커니즘으로 활용

보안 고려사항

패스워드 복잡성: 약한 패스워드는 오프라인 사전 공격에 취약
티켓 탈취 위험: 메모리에서 티켓 정보 추출 가능성 존재 (Pass-the-Ticket 공격)
암호화 알고리즘: 레거시 RC4 대신 AES 암호화 사용 권장
티켓 갱신: 장시간 유효한 티켓은 보안 위험 증가
KDC 보호: 인증 서버는 물리적/논리적으로 철저히 보호 필요
위임 제한: 제한된 위임(Constrained Delegation) 기능 활용

발전 방향

PKINIT: 공개키 인프라와 Kerberos 통합으로 스마트카드 인증 지원
AES 암호화 강화: 레거시 RC4/DES에서 AES-256으로 전환
모바일 환경 지원: 모바일 기기에서 Kerberos 사용 방안 개발
제로 트러스트 아키텍처: Kerberos를 제로 트러스트 모델에 통합
클라우드 환경 적용: 하이브리드/멀티 클라우드 환경에서 통합 인증 제공

결론

Kerberos는 대규모 네트워크 환경에서 안전하고 효율적인 인증 제공
단일 로그인(SSO)과 강력한 인증 메커니즘으로 보안성과 사용자 편의성 동시 제공
다양한 플랫폼에서 구현 가능하며 엔터프라이즈 환경에 적합
시간 동기화, 중앙 서버 의존성 등 운영 시 주의할 점 존재
현대 네트워크 보안의 중요한 구성 요소로 계속 발전 중

Keywords

Authentication Protocol, 인증 프로토콜, Ticket-based Security, 티켓 기반 보안, Single Sign-On, 단일 로그인, KDC, 키 분배 센터, Active Directory, 액티브 디렉토리, Mutual Authentication, 상호 인증, Network Security, 네트워크 보안

728x90