아니요. 클라이언트는 TGT를 티켓 발급 서비스(TGS)에 제시해 원하는 서비스의 티켓을 요청하고, 발급된 서비스 티켓을 실제 파일 서버 등 응용 서비스에 제시합니다.
TGT와 서비스 티켓은 받는 주체와 용도가 다릅니다. Kerberos가 신원을 인증했다고 해서 그 주체의 모든 파일 권한까지 자동 승인되는 것은 아닙니다. 아래 인물·서버 이름과 흐름은 새로 만든 학습용 예시입니다.
세 주체와 두 티켓을 먼저 구분합니다
Kerberos V5에서는 클라이언트가 자신을 인증하고, 키 배포 센터(KDC)가 티켓을 발급하며, 클라이언트가 접근하려는 응용 서비스가 티켓을 검증합니다. KDC의 인증 서버(AS)는 초기 인증 교환을 처리하고, 티켓 발급 서버(TGS)는 클라이언트가 특정 서비스에 접근할 때 필요한 서비스 티켓을 발급합니다. 구현에서 AS와 TGS가 하나의 KDC 안에 함께 운영되더라도 두 교환의 역할은 구별할 수 있습니다.
초기 로그인 때 받는 티켓 발급 티켓(TGT)은 사용자의 장기 비밀을 매번 서비스에 보내지 않고도, 이후 KDC에 추가 서비스 자격 증명을 요청할 수 있도록 연결합니다. TGT의 대상은 서비스가 아니라 TGS입니다. 파일 서버가 직접 TGT를 받아 사용자 로그인 자격을 확인하는 구조로 외우면 안 됩니다. 사용자는 먼저 TGS에게 TGT와 인증 정보를 담은 요청을 보내 파일 서비스용 티켓을 얻고, 이후 별도의 응용 서비스 교환에서 그 서비스 티켓을 파일 서버에 제시합니다.
| 순서 | 요청 주체와 상대 | 사용·발급되는 자격 | 목적 |
|---|---|---|---|
| 1. 초기 인증 | 클라이언트 민지가 AS와 교환 | TGT 발급 | 사용자의 초기 인증 뒤 TGS에 후속 티켓을 요청할 기반을 마련 |
| 2. 서비스 티켓 요청 | 민지의 클라이언트가 TGS에 요청 | 기존 TGT를 제시하고 cifs/files.example 서비스 티켓 요청 | KDC가 해당 서비스에 맞는 티켓 발급 |
| 3. 서비스 인증 | 클라이언트가 files.example의 파일 서비스에 요청 | TGS가 발급한 서비스 티켓과 authenticator 제시 | 서비스가 요청 주체와 티켓을 검증 |
| 4. 자원 접근 판단 | 파일 서비스가 공유 폴더 요청을 처리 | 서비스가 적용하는 권한 정책 | 인증 성공 외에 파일별 허용 여부를 따로 판단 |
TGT가 서비스 티켓으로 바뀌는 곳은 TGS입니다
민지가 회사 계정으로 로그인해 files.example의 공유 폴더를 열려고 한다고 합시다. AS와 초기 인증을 마친 민지의 클라이언트에는 TGS 요청에 사용할 TGT가 있습니다. 클라이언트는 이 TGT와 요청 대상 서비스 이름을 TGS에 보내 파일 서비스가 사용할 자격 증명을 요청합니다. TGS는 요청을 확인한 뒤 서비스 티켓을 응답에 포함할 수 있습니다. 이제 클라이언트는 해당 서비스 티켓과 authenticator를 응용 서비스에 보냅니다. RFC 4120은 TGS 교환과 application-server 교환을 서로 다른 절차로 정의합니다. 따라서 ‘로그인할 때 받은 TGT를 모든 서버에 반복 제시한다’는 설명은 대상과 흐름을 모두 놓칩니다.
실제 서비스 티켓은 요청한 서비스의 장기 키로 보호되어 그 서비스가 검증할 수 있도록 발급됩니다. 티켓이 다른 서비스 이름을 대상으로 발급됐다면 목적 서비스가 일치하는지도 확인해야 합니다. 티켓은 서비스 이용 요청의 인증 수단이지, 사용자가 그 서버의 모든 파일이나 관리자 기능을 허가받았다는 결정이 아닙니다. RFC 4120은 응용 서비스가 자신의 authorization 판단 책임을 진다고 밝힙니다. 사용자의 권한 그룹, 공유 폴더 ACL, 응용 프로그램 정책 등이 별도로 접근을 제한할 수 있습니다.
접근 기록의 티켓을 읽는 다섯 질문
- 지금 기록된 교환이 AS, TGS, 응용 서비스 중 어디에서 발생했는지 확인합니다.
- 요청이나 발급된 티켓의 대상 principal이 TGS인지 특정 서비스인지 적습니다.
- 클라이언트가 기존 TGT로 TGS 서비스 티켓을 요청했는지 흐름을 확인합니다.
- 응용 서버가 받은 서비스 티켓이 의도한 서비스와 일치하는지 확인합니다.
- 인증 성공과 파일·명령별 권한 결정을 서로 다른 기록으로 검토합니다.
Microsoft Learn의 Windows Server 개요는 클라이언트, 접근 대상 서비스, KDC라는 세 주체를 설명합니다. 이는 Windows 환경의 Kerberos V5 소개이지, 모든 구현이 Active Directory에서 같은 방식으로 배치된다는 뜻은 아닙니다. 프로토콜 역할을 정리할 때는 RFC 교환을 기준으로 삼고, 운영 환경의 KDC·서비스 이름·로그 형식은 해당 제품 문서와 설정에서 확인하세요. TGT를 가지고 있다고 해서 이미 목표 응용 서비스에 로그인한 것과 같다고 추정해서도 안 됩니다.
TGT를 서비스 티켓이라고 부르거나 인가까지 추론하지 않습니다
흔한 오답은 ‘클라이언트가 TGT를 파일 서버에 전달하고 파일 서버가 KDC에 인증한다’고 쓰는 것입니다. 일반 흐름에서 TGT는 TGS 요청에 사용되고, 실제 파일 서버에는 그 서비스에 맞게 발급된 티켓이 전달됩니다. 다음 실수는 KDC가 발급한 티켓을 사용자 권한 승인과 동일시하는 것입니다. Kerberos는 네트워크상 principal을 인증하도록 돕지만, 응용 서비스는 서비스 정책과 자원 권한을 별도로 확인합니다. 문제에서 묻는 것이 티켓 발급인지 파일 접근 허용인지 먼저 나누세요.
티켓의 받는 주체를 말하며 순서를 회상합니다
회상 연습: 민지가 AS에서 TGT를 받은 뒤 파일 서버 files.example에 접속한다. TGT는 누구에게 쓰고, 파일 서버에는 무엇을 보내며, 서비스 티켓 발급만으로 폴더 읽기 권한이 보장되는가? TGT는 TGS에 후속 서비스 티켓을 요청할 때 사용합니다. 서비스 티켓은 파일 서비스에 제시합니다. 폴더 권한은 서비스가 별도로 판단하므로 티켓 발급만으로 보장되지 않습니다. 이 사례는 교육용으로 직접 작성했으며 실제 출제 문항이나 판매 카드의 복제가 아닙니다. 정보보안기사 집중 180제의 실제 구성은 /decks/security#focus-180 안내에서 확인하세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
민지가 AS에서 TGT를 받은 뒤 파일 서버 files.example에 접속한다. TGT는 누구에게 사용하고, 파일 서버에는 어떤 티켓을 제시하며, 티켓 발급만으로 폴더 접근이 승인되는가?
정답과 해설 확인
TGT는 TGS에 서비스 티켓을 요청할 때 사용합니다. 파일 서버에는 files.example 서비스용 티켓을 제시합니다. 폴더 권한은 서비스가 별도로 판단하므로 자동으로 승인되지 않습니다.RFC 4120은 TGS 교환과 application-server 교환을 구분합니다. Kerberos 인증과 응용 서비스의 권한 부여도 같은 판단이 아닙니다.