서버가 몇대 없고, 사용자의 숫자도 얼마 안되는 경우 각 서버별로 수동으로 유저를 추가하거나 권한을 부여해서 수동으로 관리하는것이 가능하다. 하지만 아래와 같이 점점 서버의 숫자가 많아지고, 유저들도 늘어나는 경우 관리에 드는 비용이 점점 커진다.
- 각 서버별로 접근 가능한 사용자(=클라이언트)들의 권한을 관리해야하는 경우
- 서버가 추가될때마다 혹은 유저가 추가/삭제 될때마다 매번 접근가능 유저를 등록하고 관리해야 하는 경우
이런 경우에는 클라이언트/서버 외에 제3의 인증서버(Authentication Server, AS)를 도입 하고, 이와 연동된 티켓 부여 서비스(Ticket Granting Service, TGS)를 통해 티켓을 발급하여 유효한 티켓이 있는 유저만 서비스 서버(Service Server, SS)에 접속을 할 수 있도록 제어하는 커버로스(Kerberos) 프로토콜 을 도입하여 편리하게 관리하는 것이 가능하다.
Kerberos Protocol 동작 순서
참고: 아래 설명에서 encrypt(키, 데이터)는 키값으로 데이터를 암호화 한다는 뜻이다.
- 클라이언트가 ID/PWD 또는 공개키 등으로 클라이언트의 머신에 먼저 로그인
-
클라이언트가 아래 메시지를 AS로 전송
- User ID (암호화 되지않은 일반 텍스트)
- AS는 User ID가 DB에 존재하는지 찾아본 후 존재하는 경우 아래 두 메시지를 리턴
- encrypt(key: 클라이언트 PWD기반 비밀키, data: “TGS 세션키”)
- 티켓을 발급받을 수 있는 티켓(Ticket-Granting-Ticket, TGT) = encrypt(TGS 비밀키, “Client ID, 주소, 유효기간, TGS 세션 키”)
- 클라이언트는 아래 두 메시지를 TGS로 전송 (TGS 세션키는 수신한 메시지를 복호화해서 획득)
- Authenticator = encrypt(key: TGS 세션키, data: “Client ID, timestamp”)
- TGT (클라이언트는 TGS 비밀키를 모르기때문에 복호화 또는 데이터 조작 불가)
- TGS는 전달받은 TGT(TGS 비밀키로 복호화 가능), 암호화된 Authenticator (TGS 세션키로 복호화 가능)를 모두 복호화 해서 안에 담긴 Client ID가 일치하는지 확인하여 일치할 경우 아래 두 메시지를 리턴
- encrypt(key: TGS 세션키, data: SS 세션키)
- Ticket = encrypt(key: SS 비밀키, data: “Client ID, 주소, 유효기간, SS 세션키”)
- 클라이언트는 아래 두 메시지를 SS로 전송
- Authenticator = encrypt(key: SS 세션키, data: “Client ID, timestamp”)
- Ticket
- SS는 전달받은 Ticket, Authenticator를 복호화 해서 안에 담긴 Client ID일치 확인 후 일치할 경우 아래 메시지를 리턴
- encrypt(key: SS 세션키, data:Authenticator안에 담겨있던 timestamp)
-
클라이언트는 전달받은 timestamp와 자신이 Authenticator에 담아보냈던 timestamp의 값이 일치하는 확인 후, 일치할경우 실제 작업을 시작한다.
Kerberos Protocol 단점
- 커버로스 서버가 SPOF(Single Point Of Failure) 이기 때문에 이 서버가 다운되면 기존에 이미 로그인된 유저를 제외한 새롭게 로그인을 시도하는 유저가 서버에 접속하는것이 불가능해진다.
- AS, TGS, SS간에 서로 비밀키를 미리 알고있어야 하기때문에 동기화 이슈가 존재한다.
- 인증이 한번 완료되면 유효기간이 존재하긴 하지만 티켓이 클라이언트에 보관되므로 티켓이 탈취될 가능성이 있다.