호다닥 톺아보는 Kerberos

Overview

오랜만에 작성하는 보안 관련 글입니다!
이번 포스팅에서는 꽤나 오래되었지만 아직도 많은 기업들 사이에서 사용하고 있는 인증방식인 Kerberos에 대해서 간단히 알아보도록 하겠습니다.

그 케르베로스 맞습니다. 머리 세개달린 명계를 지키는 수문장 멍뭉이…!

Kerberos란?

Kerberos는 네트워크 인증 방식 중 하나입니다.
주 목적은 보안이 보장되지 않은 네트워크 환경에서 요청을 보내는 유저와 서버가 서로의 신뢰성을 확보하기 위함입니다.

주의해야 할 점은, Kerberos는 사용자의 신원을 인증해주는 역할만 하지, 그 사용자가 접근할 수 있는 서비스나 리소스를 검증하지는 않습니다.
즉, 리소스에 대한 사용자의 액세스를 결정하는 것은 각 서비스의 책임이라고 보시면 됩니다.

그러면 어떻게 Kerberos가 사용자의 신원을 인증해줄 수 있는지, 그 방법을 알아보기 전에, 주요 용어부터 짚고 넘어가겠습니다.

Windows 운영체제 같은 경우엔, Windows2000 이상 버전부터 Kerberos를 기본 인증 방법으로 사용하고 있습니다.
클라이언트를 Windows 도메인에 가입시킬 경우, 해당 클라이언트에서 Windows 도메인 및 해당 도메인과 신뢰 관계가 있는 모든 도메인의 서비스에 대한 인증을 Kerberos를 통해 한다고 보시면 됩니다.

반대로 클라이언트나 서버 둘 중에 하나라도 신뢰관계에 있지 않다면 인증을 위해 NTLM을 사용한다는데 이건 나중에 다룰 일이 있다면… 언젠가…

Kerberos 주요 용어

KDC(Key Distribution Center) : 서버와 사용자에 대한 신뢰관계 정보를 관리하는 중앙 DB
AS (Authentication Server) : 인증서버, 사용자로부터 인증을 수락하는 서버
TGS (Ticket Granting Server) : 티켓 발급 서버, 각 서버를 이용하기 위한 티켓을 발급하는 서버
Principal : KDC가 인증하는 사용자 및 서버
Realm : 동일한 KDC아래의 시스템들을 논리적 그룹으로 정의

Authentication Flow

뭔가 많이 복잡해보이지만 별거 없습니다. 천천히 따라가보겠습니다!

1. Client Authentication

1. 로그인시도 : 사용자는 id를 cleartext로 암호화하지 않고 AS로 보냅니다.(pw는 전송하지 않음)
2. AS는 DB(ex. LDAP, AD)에 유저id를 확인 후 있다면 다음 데이터 반환
   • DB에서 찾은 유저 pw기반으로 암호화한 TGS의 세션키
   • 클라이언트의 id와 ip주소, 티켓유효기간, TGS세션키를 TGS비밀키로 암호화한 티켓 발급용 티켓인 TGT(Ticket Granting Ticket)

     여기서 클라이언트가 데이터를 받았을 때, 사용자가 입력한 pw가 틀렸을 경우 메세지를 복호화할 수 없음

2. Client Service Authorization

1. 서비스를 요청할 때, 클라이언트는 다음 두가지를 TGS에 전송
   • 클라이언트 id, timestamp를 TGS세션키로 암호화
   • TGT
2. TGS는 인증정보와 TGT를 복호화하여 클라이언트 id가 일치할 경우 다음 메세지 반환
   • TGS세션키로 암호화한 서비스서버 세션키
   • 클라이언트 id, ip주소, 유효기간, 서비스서버 비밀키로 암호화한 티켓!

     이 단계에서 클라이언트는 서비스 서버에 자신을 인증할 수 있는 충분한 정보를 갖게 된다

3. Client Service Request

1. 클라이언트는 아래 정보를 서비스 서버로 전달
   • 클라이언트 id, Timestamp를 서비스서버 세션키로 암호화
   • 티켓
2. 서비스서버는 티켓과 인증정보를 복호화하여 Client id가 일치할경우 다음 메세지 반환
   • Timestamp를 서비스 서버 세션키로 암호화해서 반환
3. 클라이언트는 전달받은 timestamp와 자신이 인증정보에 담았던 timestamp값을 확인하여 일치하는 경우 서비스 서버에 서비스를 요청할 수 있게 됩니다.
4. 서버는 클라이언트에게 요청된 서비스를 제공 (위에서 언급했듯이 무조건 제공하는건 아니고 서비스 서버의 정책에 따라 제공될수도, 거절할수도 있음)

단점

• 기본적으로 서버가 한대라 장애가 발생하면 로그인못함, 그래서 HA구성을 하거나, 서버가 작동안할때 할 수 있는 대체 로그인 서비스를 구현해야함
• 요청 시간에 대한 요구가 엄격, 요청을 주고받는 서비스들 간의 시간 동기화가 필수 (그렇지 않다면 인증 실패)

---