들어가며

사용자가 아침에 PC를 켜고 도메인 계정으로 Windows에 로그인합니다. 그리고 브라우저로 사내 관리 시스템에 접속하면, 비밀번호를 물어보지 않고 바로 대시보드가 나타납니다. 마법이 아닙니다. Windows가 로그인하는 순간 이미 받아둔 Kerberos 티켓을 브라우저가 자동으로 꺼내 쓰기 때문입니다. 놀라운 점은 이 과정에서 비밀번호가 네트워크를 타고 단 한 번도 전송되지 않는다는 것입니다. 이 글은 “비밀번호 없이 인증한다”는 말이 도대체 어떻게 가능한지, Kerberos의 3단계 흐름부터 브라우저가 티켓을 전달하는 SPNEGO까지 그 원리를 따라갑니다.

SSO: 비밀번호를 한 번만 치는 세계

사내 시스템이 열 개라면 어떨까 상상해 보세요. 메일, 파일 공유, 웹 관리, CRM에 접속할 때마다 아이디와 비밀번호를 입력해야 합니다. 하루에도 수십 번입니다. 사용자는 결국 같은 비밀번호를 재사용하거나 어딘가에 메모해 두고, 그 순간 보안은 무너집니다. SSO(Single Sign-On)가 풀려는 문제가 바로 여기에 있습니다 — 한 번의 로그인으로 여러 서비스에 자동으로 인증되게 만드는 것.

아래 그림은 SSO가 없는 세계와 있는 세계를 나란히 보여줍니다. 윗부분과 아랫부분의 차이에 주목하세요. SSO가 없으면 서비스마다 비밀번호가 따로 필요하지만, SSO가 있으면 한 번 받은 티켓(TGT)으로 모든 서비스에 자동 인증됩니다. 핵심은 “비밀번호를 서비스에 직접 보내지 않는다”는 점입니다 — 티켓이라는 간접 증빙으로 인증이 이루어집니다.

SSO가 없는 세계 (각 시스템마다 별도 로그인):

  사용자 → 메일: 아이디/비밀번호 ✓
         → 파일공유: 아이디/비밀번호 ✓
         → 웹관리: 아이디/비밀번호 ✓
         → CRM: 아이디/비밀번호 ✓
          
  문제: 매번 비밀번호 입력, 기억해야 할 비밀번호 많음

SSO가 있는 세계 (한 번만 로그인):

  사용자 → [한 번 로그인] → TGT(티켓) 획득
         → 메일: 자동 인증 (티켓 제시)
         → 파일공유: 자동 인증
         → 웹관리: 자동 인증
         → CRM: 자동 인증
          
  장점: 한 번만 로그인, 비밀번호 1개만 기억

핵심: SSO의 본질은 “비밀번호를 한 번만 치는 편의”가 아니라 “비밀번호를 서비스에 직접 보내지 않는 구조”입니다. 티켓이라는 매개체를 두어 비밀번호 노출 면적을 최소화합니다.

SSO가 무엇인지는 정리됐습니다. 하지만 “티켓”이라는 말이 나왔으니, 이 티켓을 발급하고 검증하는 Kerberos 세계의 등장인물들을 먼저 짚고 넘어가야 합니다.

Kerberos의 등장인물들

티켓 기반 인증이라는 아이디어를 실현하려면 몇 가지 역할이 필요합니다. 티켓을 발급하는 주체, 티켓을 받는 주체, 티켓을 검증하는 주체가 각각 구분되어야 합니다. Kerberos는 이 역할들을 명확히 나누어 놓았고, 각각에 고유한 이름을 붙였습니다. 아래 용어들이 한 번에 헷갈릴 수 있지만, 놀이공원 비유로 하나씩 대응시키면 그림이 잡힙니다.

아래 표를 읽을 때 ‘비유’ 열에 주목하세요. KDC는 매표소, TGT는 입장권, 서비스 티켓은 놀이기구 탑승권입니다. 입장권(TGT) 하나만 있으면 어떤 놀이기구든 탑승권(서비스 티켓)으로 바꿀 수 있다는 점 — 이것이 Kerberos 위임 구조의 핵심입니다.

등장인물을 익혔습니다. 그런데 여기서 가장 중요한 질문이 하나 남아 있습니다 — 이 티켓들은 도대체 어떻게 “비밀번호 없이” 인증을 증명할 수 있는 걸까요? 세 단계의 교환 과정을 따라가면 그 비밀이 풀립니다.

Kerberos 3단계 인증 플로우

“비밀번호를 보내지 않으면서 어떻게 인증하느냐”는 질문의 답이 바로 이 세 단계에 있습니다. Kerberos는 티켓을 “비밀번호 해시로 암호화”하는 아이디어를 씁니다. KDC와 클라이언트가 같은 비밀번호 해시를 알고 있으므로, KDC가 그 해시로 암호화한 티켓은 올바른 비밀번호를 가진 사용자만 열 수 있습니다. 비밀번호 자체를 보낼 필요가 없는 이유입니다. 이 암호화된 티켓이 세 단계에 걸쳐 어떻게 만들어지고 전달되는지를 보겠습니다.

아래 다이어그램은 AS Exchange, TGS Exchange, Client-Server Exchange 세 단계를 시간순으로 보여줍니다. 읽을 때 각 단계가 “어떤 키로 무엇을 암호화하는지”에 주목하세요. 1단계에서 TGT는 KDC의 비밀키로 암호화되고, 2단계에서 서비스 티켓은 서비스의 비밀키로 암호화됩니다. 마지막 3단계에서 서비스는 자신의 비밀키로 티켓을 풀어보고 인증을 확정합니다. 비밀번호는 어디에서도 평문으로 오가지 않습니다.

  ┌──────────┐          ┌──────────┐          ┌──────────┐
  │  클라이언트 │          │   KDC    │          │  서비스   │
  │ (사용자 PC)│          │ (AD DC)  │          │(웹 관리)  │
  └────┬─────┘          └────┬─────┘          └────┬─────┘
       │                     │                     │
       │  ┌─── 단계 1: AS (Authentication Service) Exchange ──┐
       │  │ 1. "TGT 주세요"                                     │
       │  │───────────────────▶                                │
       │  │                        2. TGT 발급                   │
       │  │  TGT = KDC비밀키로 암호화된 티켓                      │
       │  │  Session Key (클라이언트-서비스 통신용)               │
       │  │◀───────────────────                                │
       │  └────────────────────────────────────────────────────┘
       │                     │                     │
       │  ┌─── 단계 2: TGS (Ticket Granting Service) Exchange ─┐
       │  │ 3. "이 TGT로 웹관리 서비스 티켓 주세요"              │
       │  │───────────────────▶                                │
       │  │                        4. 서비스 티켓 발급            │
       │  │  Service Ticket = 서비스 비밀키로 암호화               │
       │  │◀───────────────────                                │
       │  └────────────────────────────────────────────────────┘
       │                     │                     │
       │  ┌─── 단계 3: Client-Server Exchange ──────────────────┐
       │  │ 5. 서비스 티켓 제시                                  │
       │  │───────────────────────────────────────────────────▶│
       │  │                                          6. 티켓 검증 │
       │  │                                          (자기 비밀키로)│
       │  │                                          → 인증 성공! │
       │  │◀───────────────────────────────────────────────────│
       │  └────────────────────────────────────────────────────┘

세 단계를 풀어 설명하면 이렇습니다. 1단계(AS Exchange)에서 클라이언트는 KDC에 “TGT를 주세요”라고 요청하고, KDC는 TGT를 발급합니다. 이때 TGT는 KDC 자신의 비밀키로 암호화되어 있어 클라이언트는 열어볼 수 없지만, 가지고는 있을 수 있습니다. 2단계(TGS Exchange)에서 클라이언트는 이 TGT를 KDC에 다시 보내며 “웹 관리 서비스 티켓을 주세요”라고 합니다. KDC가 TGT를 자기 키로 열어 신원을 확인한 뒤, 서비스 전용 티켓을 발급합니다 — 이 티켓은 서비스의 비밀키로 암호화되어 있습니다. 3단계(Client-Server Exchange)에서 클라이언트가 이 티켓을 웹 서비스에 제시하면, 서비스는 자신의 비밀키로 티켓을 열어보고 인증을 완료합니다.

핵심: 비밀번호는 네트워크로 절대 전송되지 않습니다. KDC는 사용자의 비밀번호 해시로 티켓을 암호화하므로, 올바른 비밀번호를 가진 사용자만 티켓을 열 수 있습니다. 그리고 각 서비스는 자기 키로만 티켓을 검증하므로, 티켓을 중간에서 빼앗아도 다른 서비스에는 쓸 수 없습니다.

3단계 흐름을 이해했으니, 새로운 질문이 떠오릅니다. 이 티켓 교환은 TCP 고유의 프로토콜로 이루어지는데, 웹 브라우저처럼 HTTP만 이해하는 클라이언트는 어떻게 Kerberos를 쓸 수 있을까요? 그 다리를 놓는 것이 바로 SPNEGO입니다.

SPNEGO: HTTP 위에서 Kerberos를 태우다

Kerberos는 원래 자체 프로토콜 위에서 작동합니다. 그런데 웹 서비스는 HTTP로 통신합니다. 브라우저가 Kerberos 티켓을 “어떻게” 서버에 전달할지가 문제입니다. 답은 의외로 단순합니다 — HTTP Authorization 헤더에 티켓을 Base64로 인코딩하여 실어 보내는 것입니다. 이 표준화된 협상 방식을 SPNEGO(Simple and Protected GSSAPI Negotiation Mechanism)라고 부르고, 브라우저와 서버는 Negotiate라는 이름으로 이를 주고받습니다. 왜 새로운 프로토콜을 만들지 않고 HTTP 헤더를 쓸까요? 기존 인프라를 전혀 바꾸지 않아도 되기 때문입니다 — 방화벽, 프록시, 로드밸런서가 모두 그대로 작동합니다.

아래 시퀀스는 브라우저가 SPNEGO로 Kerberos 인증을 수행하는 전 과정입니다. 읽을 때 2단계의 401 응답과 4단계의 Authorization 헤더에 주목하세요. 서버가 먼저 “나 Negotiate 인증을 지원해”라고 선언(2단계)하고, 브라우저가 그제야 티켓을 획득해 헤더에 담아 재전송(4단계)하는 이 두 박자가 SPNEGO의 핵심입니다. 비밀번호 입력 칸은 이 흐름 어디에도 등장하지 않습니다.

브라우저                         웹 서버
    │                                  │
    │ 1. GET /dashboard                │
    │────────────────────────────────▶│
    │                                  │
    │ 2. 401 Unauthorized              │
    │    WWW-Authenticate: Negotiate   │
    │◀────────────────────────────────│
    │                                  │
    │ 3. KDC에 서비스 티켓 요청         │
    │──────────▶ KDC (AD DC)           │
    │           ◀──────────            │
    │    서비스 티켓 획득               │
    │                                  │
    │ 4. GET /dashboard                │
    │    Authorization: Negotiate      │
    │    <base64 Kerberos 티켓>        │
    │────────────────────────────────▶│
    │                                  │
    │                          5. 티켓 검증
    │                          (keytab + gssapi)
    │                          → 사용자: user@EXAMPLE.LOCAL
    │                                  │
    │ 6. 200 OK + JWT                  │
    │◀────────────────────────────────│
    │                                  │
    │ 로그인 화면 없이 자동 인증!       │

흐름에서 한 가지를 더 짚겠습니다. 1단계에서 브라우저는 평범한 GET 요청으로 시작합니다. 서버는 2단계에서 401과 함께 WWW-Authenticate: Negotiate를 보내며 “비밀번호가 아니라 티켓을 원해”라고 알립니다. 이 신호를 받은 브라우저는 3단계에서 KDC로부터 서비스 티켓을 받아오고, 4단계에서 그 티켓을 Authorization 헤더에 담아 다시 요청합니다. 서버는 keytab(서비스 비밀키 파일)으로 티켓을 검증한 뒤, 6단계에서 JWT나 세션을 내어줍니다. 사용자는 끝내 비밀번호를 치지 않습니다.

서비스 측 설정: SPN과 Keytab

SPNEGO가 작동하려면 서비스 측에 두 가지가 준비되어야 합니다. SPN(Service Principal Name)으로 서비스를 KDC에 등록하고, 그 서비스의 비밀키를 keytab 파일로 추출하는 것입니다. 아래는 그 설정 과정입니다 — SPN 등록, keytab 추출, 권한 설정, 환경변수 순서를 따라가 주세요.

# 1. 서비스 주체 이름(SPN) 등록
ad-tool spn add HTTP/ad-tool.internal service_account

# 2. Keytab 추출
ad-tool domain exportkeytab /etc/krb5.keytab \
    --principal=HTTP/ad-tool.internal@EXAMPLE.LOCAL

# 3. 권한 설정
chmod 644 /etc/krb5.keytab

# 4. 환경설정
# KERBEROS_ENABLED=true
# KERBEROS_KEYTAB=/etc/krb5.keytab
# KERBEROS_SPN=HTTP/ad-tool.internal

SPNEGO가 어떻게 Kerberos를 HTTP에 올리는지까지 살폈습니다. 그렇다면 마지막으로 확인할 것이 있습니다 — 도메인에 가입된 PC에서 브라우저를 켤 때, 사용자가 아무것도 하지 않아도 이 흐름이 “왜” 자동으로 시작되는지. 그 비밀은 Windows 로그인 순간에 이미 숨어 있습니다. 그 전에, 먼저 SSO를 구현하는 방법이 Kerberos만 있는 게 아님을 짚고 넘어가겠습니다.

왜 Kerberos인가: OIDC, SAML과의 비교

SSO를 구현하는 방법은 Kerberos만 있는 게 아닙니다. 웹 기반의 OIDC도 있고, 엔터프라이즈 표준인 SAML도 있습니다. 그런데 왜 사내망, 특히 도메인 가입 PC 환경에서는 Kerberos를 선택할까요? 답은 “가장 안전해서”가 아니라 “비밀번호를 아예 네트워크에 보내지 않기 때문”입니다. OIDC와 SAML은 최종적으로 사용자가 IdP(Identity Provider) 화면에서 비밀번호를 입력해야 하지만, Kerberos는 도메인 로그인 시점에 이미 티켓을 받아두므로 이후 어떤 비밀번호 입력도 필요 없습니다.

아래 표는 세 가지 SSO 방식을 비교합니다. “비밀번호 전송” 열에 주목하세요. Kerberos만이 “없음”으로 표시되어 있습니다. 나머지 둘은 어딘가에서 비밀번호가 네트워크를 탑니다. 사내망처럼 사용자가 이미 도메인 계정으로 PC에 로그인한 환경에서는, 이 차이가 “비밀번호 없는 완전한 SSO”를 가능하게 하는 결정적 요인이 됩니다.

핵심: Kerberos가 사내망에서 독보적인 이유는 “강력한 암호” 때문이 아니라 “비밀번호 자체를 보내지 않는 구조” 때문입니다. 사용자가 도메인에 로그인한 순간 이미 신원이 확립되어 있으므로, 이후 서비스 접근에서는 비밀번호 입력이 아예 존재하지 않습니다. OIDC·SAML이 “비밀번호를 안전하게 전달”하는 데 집중한다면, Kerberos는 “전달할 비밀번호가 없게” 설계했습니다.

세 방식의 차이까지 정리됐습니다. 이제 이 모든 원리가 도메인 가입 PC에서 사용자 눈에 어떻게 보이는지 — 그 조용한 마법을 확인하겠습니다.

클라이언트의 경험: 마법이 작동하는 순간

지금까지 KDC, 티켓, SPNEGO를 따라왔지만, 사용자가 실제로 경험하는 것은 그 어느 것도 아닙니다. 사용자는 그저 PC를 켜고 도메인 계정으로 로그인한 뒤, 브라우저 주소창에 사내 시스템 URL을 칠 뿐입니다. 그리고 아무 팝업도, 아무 입력 칸도 없이 대시보드가 나타납니다. 마법의 정체는 시간선에 숨어 있습니다 — Windows 로그인 그 순간에 이미 1단계(AS Exchange)가 자동으로 실행되어 TGT가 PC에 저장되어 있었던 것입니다.

브라우저가 사내 시스템에 접속하면 2단계(TGS)와 3단계(CS)가 순식간에 일어납니다. 브라우저는 저장된 TGT를 꺼내 KDC에서 서비스 티켓을 받고, SPNEGO로 그 티켓을 서버에 전달합니다. 이 모든 것이 밀리초 단위로, 사용자가 눈치채지 못하는 사이에 완료됩니다. Windows의 IE·Edge·Chrome은 기본으로 이 동작을 하며, Firefox만 about:config에서 network.negotiate-auth.trusted-uris에 사내 도메인을 등록해 주면 됩니다. 사용자가 “비밀번호 없이 로그인됐다”고 느끼는 그 순간은, 사실 세 단계의 티켓 교환이 조용히 치러진 결과입니다.

이제 Kerberos의 모든 조각이 맞춰졌습니다. 돌아보며 무엇이 이 설계를 우아하게 만드는지 정리하겠습니다.

마치며

이 시리즈의 이전 글에서 TOTP는 “같은 비밀키를 사전에 나눠 가졌기에 통신을 생략할 수 있다”는 우아함을 보여주었습니다. Kerberos는 그 사상을 한 걸음 더 밀고 나갑니다. 비밀번호를 증명하되 비밀번호는 보내지 않는, 이 역설을 푸는 열쇠가 바로 “비밀번호 해시로 티켓을 암호화한다”는 발상입니다. KDC와 사용자가 같은 비밀번호 해시를 알고 있으니, 그 해시로 잠근 티켓은 진짜 주인만 열 수 있습니다. 비밀번호라는 가장 민감한 비밀이 네트워크 위에 단 한 번도 올라가지 않는다는 사실은, 보안이란 곧 “더 강한 암호”가 아니라 “위험한 정보를 아예 주고받지 않는 설계”라는 진리를 다시 한번 확인시켜 줍니다.

그리고 티켓 기반 위임의 2단 구조는 그 자체로 작품 같습니다. TGT라는 마스터 티켓 하나로 어떤 서비스 티켓이든 받아낼 수 있으니, 한 번의 인증이 무한한 서비스로 확장됩니다. 동시에 각 서비스 티켓은 그 서비스의 비밀키로만 열리므로, 한 서비스가 침해당해도 훔친 티켓은 다른 서비스에 쓸 수 없습니다. 최소 권한과 최소 노출이 프로토콜 설계 단계부터 녹아든 것입니다. TGT 탈취의 위험은 남아 있지만, 그 위험마저 짧은 만료 시간과 정기적 갱신으로 다스리는 것이 Kerberos의 설계 철학입니다 — 완벽을 추구하기보다 위험을 구조적으로 통제하는 태도입니다.

마지막으로 감동적인 것은 SPNEGO의 실용적 절제입니다. 새로운 프로토콜을 만들지 않고, 그저 HTTP 헤더에 티켓을 올렸을 뿐인데 기존의 모든 인프라 — 방화벽, 프록시, 로드밸런서 — 가 그대로 작동합니다. 그리고 도메인에 로그인하는 아침 한 번의 입력이 하루 종안 수십 개의 서비스를 비밀번호 없이 열어줍니다. 사용자가 체감하는 것은 “그냥 되는” 조용함뿐이지만, 그 조용함 아래에는 비밀번호 해시로 암호화된 티켓, 2단 위임 구조, HTTP 위의 협상이라는 세 겹의 설계가 밀리초 안에 조용히 돌아가고 있습니다. 들리지 않는 곳에서 완벽하게 작동하는 기계의 우아함 — 그것이 Kerberos가 가진 가장 깊은 매력일 것입니다.

이전 글: (4) MFA & TOTP

다음 글: (6) JWT 토큰