정보보안심화 · 13분 읽기

Kerberos·LDAP·RADIUS·TACACS+의 역할과 인증 흐름

수업에서 짧게 등장한 중앙 인증 기술을 디렉터리·티켓·네트워크 접근·장비 관리의 서로 다른 역할로 풀어 설명합니다. 원문의 개요를 RFC의 메시지 흐름으로 보충합니다.

개념부터 찾아보기

정의·역할·동작 원리를 독립 페이지에서 확인하세요. 본문의 밑줄 용어에도 설명이 있습니다.

Kerberos LDAP RADIUS TACACS+

이 노트에서 설명할 수 있게 되는 것

네 기술의 인증·인가·디렉터리·기록 역할을 구분한다.
Kerberos의 TGT와 서비스 티켓, RADIUS의 요청·응답 관계를 설명한다.
인증 성공·정책 적용·실제 세션 기록을 서로 다른 단계로 읽는다.

먼저 알면 좋은 개념보안의 기준: CIA·AAA와 위험 판단 대칭키·공개키와 DES·AES의 내부 구조

01개념과 구성 요소

디렉터리의 ··속성을 검색·변경하며 로 연결의 인증 상태를 설정한다.
의 ·와 티켓·세션 키를 이용해 서비스에 인증한다.
·네트워크 접근 와 장비 관리 에 쓰이며 메시지·권한 적용 지점이 다르다.

02Kerberos에서 서비스 인증이 이루어지는 순서

초기 인증클라이언트가 교환과 필요한 사전 인증을 통해 와 세션 키 정보를 얻는다.
요청와 인증 정보를 이용해 에 특정 서비스의 티켓을 요청한다.
서비스 자격 수신가 해당 서비스가 해석할 수 있는 티켓과 클라이언트가 사용할 세션 키 정보를 전달한다.
티켓· 제시클라이언트가 서비스에 티켓과 세션 키에 근거한 를 보낸다.
유효성·재생 검사서비스가 티켓·시간·재사용 조건을 검사하고 필요하면 상호 인증 응답을 제공한다.
업무 인증된 신원이 어떤 파일·행·관리 기능을 사용할 수 있는지는 서비스의 별도 정책으로 판단한다.

03이름이 비슷해도 같은 자리를 대체하지 않는다

역할의 은 신원 확인, 은 허용 작업 결정, 은 사용·행위 기록이다. 실제 시스템은 이 기능을 여러 프로토콜과 데이터 저장소에 나누어 구현한다.
기술별 기능는 디렉터리 접근, 는 티켓 기반 서비스 인증, 는 네트워크 접근 , 는 장비 관리 에 자주 쓰인다.
프로토콜 교체 한계/VPDN의 group을 나 이름으로 바꾸기만 해서는 같은 대화가 성립하지 않는다. 중앙 계정 저장소를 공유하더라도 클라이언트가 수행하는 대화와 권한 적용 지점은 별개다.

04LDAP: Entry·DN·Attribute

··속성는 계층적인 디렉터리의 를 검색·추가·수정하는 프로토콜이다. (Distinguished Name)은 를 식별하며 속성은 uid·이름·그룹 관련 정보처럼 객체의 값을 표현한다.
스키마사용자와 그룹의 정확한 스키마는 디렉터리 구현·objectClass에 따라 달라진다.
검색 조건애플리케이션은 base , 검색 범위, , 반환 속성을 지정해 필요한 사용자를 찾을 수 있다. 디렉터리 검색 결과에 이름이 있다는 사실이 로그인 인증 성공은 아니다.
계정·검색용 서비스 계정과 에 사용하는 신원도 구분한다. 에 사용자 값을 문자열로 붙이면 query의 의미가 바뀔 수 있으므로 필터 문맥에 맞는 안전한 구성이 필요하다.

text

예시 DN: uid=learner,ou=people,dc=example,dc=test
검색 기반: ou=people,dc=example,dc=test
의도한 질문: uid가 learner인 entry의 필요한 속성 조회

디렉터리에서 찾음 ≠ 비밀번호 확인 성공 ≠ 앱 관리자 권한

원리를 설명하는 가상 학습 예시입니다.

05LDAP Bind와 보호 채널

방식는 클라이언트와 서버가 인증 정보를 교환해 세션의 인증 상태를 설정하는 작업이다. 이름과 비밀번호를 사용하는 simple 와 SASL 방식은 같은 보안 조건이 아니다.
보호 채널비밀번호가 사용되는 경우 보호된 채널과 서버 신원 검증이 중요하며 단지 포트 번호만 보고 암호화를 확정할 수 없다.
는 기존 연결에 를 시작하는 방식이다. 실패 뒤 평문으로 계속 진행하거나 인증 실패를 익명 접근 성공과 혼동하면 의도한 신뢰 경계가 깨진다.
속성 권한조회 권한과 속성별 접근통제는 성공 이후에도 서버 정책으로 적용된다.

채널 준비보호가 필요한 전에 채널과 서버 신원을 검증한다. 실패를 평문 진행으로 대체하지 않는다.
Simple 또는 구성한 SASL 교환으로 연결의 인증 상태를 설정한다.
SearchBase ···반환 속성을 정해 필요한 를 조회한다. 검색용 신원과 사용자 신원은 같지 않을 수 있다.
권한 집행디렉터리가 인증 상태와 정책에 맞는 ·속성 접근을 허용한다. 검색 결과에 계정이 있다는 사실은 사용자 비밀번호 검증과 다르다.

06Kerberos: KDC·AS·TGS와 TGT

··의 는 와 역할을 제공한다. 교환에서 클라이언트는 초기 인증에 필요한 절차를 거쳐 와 세션 키 정보를 얻는다.
보호의 보호된 내용은 가 사용할 수 있도록 암호화되어 있으며 클라이언트가 임의로 사용자 이름이나 만료를 고쳐 쓰는 증명서가 아니다.
구분는 모든 업무 서버에 그대로 내미는 최종 과 다르다. 비밀번호를 매 서비스에 반복 전송하지 않고 에 필요한 서비스의 티켓을 요청하는 기반으로 쓰인다.
사전 인증실제 pre- 방식은 확장과 환경에 따라 달라질 수 있으므로 단순 그림을 모든 인증 방식의 상세 바이트 흐름으로 보지 않는다.

07서비스 티켓과 Authenticator

티켓 요청클라이언트는 와 인증 정보를 이용해 에 특정 서비스의 자격을 요청한다. 의 보호된 부분은 그 서비스가 해석할 수 있도록 암호화되며 클라이언트는 별도로 받은 세션 키를 사용한다.
세션 키서비스에 티켓과 를 제시하면 서버는 유효성·시간·재사용 여부 등 조건을 검증한다.
·Replay와 ·시간 검사는 과거 메시지의 재사용을 제한한다. 티켓만 복사한 문자열이 사용자의 현재 증명과 완전히 같지 않다는 점이 핵심이다.
상호 인증·시간상호 인증을 사용하는 경우 서버 응답도 클라이언트가 검증한다. 시계 차이·만료·잘못된 서비스 이름은 정상 사용자에게도 실패를 만들 수 있다.

원리 심화

08Kerberos 티켓·세션 키·Authenticator의 암호 경계

경계의 보호된 부분은 가 읽을 수 있는 키 문맥으로 암호화된다. 클라이언트는 티켓을 전달하지만 그 내용 전체를 직접 복호화하는 주체는 아니다.
세션 키클라이언트는 교환에서 얻은 클라이언트– 세션 키를 사용해 요청의 를 만든다.
서비스 세션 키는 대상 과 클라이언트–서비스 세션 키를 제공한다. 의 보호된 부분은 대상 서비스가 검증한다.
새 요청 증명는 해당 세션 키 소유와 시각 문맥을 증명한다. 티켓 문자열의 존재만으로 새 요청의 정당성을 증명하지 않는다.
재생 방어서버는 적절한 대체 방어가 없다면 허용 시계 오차 안의 이력을 로 관리한다. 같은 Principal을 공유하는 서버들의 문맥도 중요하다.

예제로 추적

09가상 TGT와 서비스 티켓의 서로 다른 만료

유효기간현재 시각을 09:30, 종료를 10:00, 기존 종료를 09:00이라고 가정한다. 시계 오차 허용 범위 밖의 차이다.
판정는 아직 유효하므로 정책과 계정 상태가 허용하면 에 새 을 요청할 수 있다.
기존 티켓09:00에 끝난 을 계속 보내면 서비스는 만료로 거부할 수 있다. 가 남아 있다는 사실이 그 티켓의 기한을 늘리지 않는다.
재발급 경로클라이언트는 와 적절한 로 새 을 받아 서비스 인증을 다시 수행한다.
업무 새 인증이 성공해도 애플리케이션 역할·객체 권한 검사는 별도다. 성공을 모든 업무 접근 허용으로 해석하지 않는다.

검증·예외

10Kerberos 오류를 비밀번호 문제로만 보지 않기

서비스 이름접속 이름·SPN·서비스 계정의 키 문맥이 맞는지 확인한다. 같은 서버의 별칭이라도 대상 Principal이 달라질 수 있다.
시간과 재생Ticket 만료·아직 유효하지 않음·Clock skew·반복 를 구분한다. 모두 동일한 인증 실패 문자열로만 기록하지 않는다.
키 갱신서비스 계정 키 변경 뒤 서버의 키 자료가 갱신되었는지 확인한다. 티켓의 키 버전과 실제 서비스 키가 달라질 수 있다.
서버 다중화같은 서비스 Principal을 여러 서버가 공유할 때 replay 방어·키·시간 정책이 일관되는지 본다. 한 서버에서만 성공하는 패턴은 분산 상태의 단서다.

11SSO와 애플리케이션 인가

·는 초기 로그인 결과를 바탕으로 여러 서비스에 다시 인증하는 사용자 경험을 줄인다. 인증이 성공해도 파일·DB 행·관리 기능에 대한 최종 는 서비스 정책이 결정한다.
객체 소유권티켓의 유효성과 사용자가 해당 자료의 소유자인지는 서로 다른 질문이다.
신뢰 기반·서비스 키와 클라이언트 자격 캐시는 중요한 신뢰 기반이다. 암호화된 티켓을 사용한다는 사실만으로 단말 탈취·잘못된 위임·키 유출의 영향이 사라지지는 않는다.
운영 전제의 안전성도 티켓·서버 신원·재생 검사와 단말의 신뢰 상태를 전제로 한다.

12RADIUS: 단말·NAS·서버

단말·VPN·무선· 등의 단말은 (Network Access Server)를 통해 접근한다. 관점의 client는 보통 이며 사용자의 PC 자체와 같지 않다.
Access 응답가 를 보내면 서버는 정책에 따라 ··로 응답할 수 있다.
Challenge·속성Challenge는 추가 인증 대화를 요구하는 상태이므로 최종 성공과 다르다. Accept의 속성은 세션 시간·필터·주소·네트워크 조건을 전달할 수 있고 가 지원·적용해야 실제 접근 제한이 된다.
현장 집행중앙 서버가 응답했다는 사실만으로 모든 속성이 현장에서 집행되었다고 볼 수 없다.

접근 요청단말이 를 통해 VPN·무선· 등의 접근을 시작한다. client 역할은 보통 가 맡는다.
가 과 필요한 접근 문맥을 서버에 전달한다.
응답 처리서버가 Reject·Accept·Challenge 중 해당 결정을 보낸다. Challenge이면 추가 인증 대화를 진행하며 최종 성공으로 처리하지 않는다.
속성 적용Accept의 시간·필터·주소 등 속성을 가 지원·적용해야 실제 제한이 된다. 세션 사용 이력은 으로 별도 기록한다.

13Accounting·세션·네트워크 인가

은 시작·종료·중간 갱신 등 세션 사용 기록을 전달하는 역할이다. 인증이 허용되었어도 실제 세션이 시작하지 않거나 종료 기록이 누락될 수 있다.
세션 연결사용자·· ID·시간·종료 이유를 연결해야 접속 이력을 해석할 수 있다.
는 인증·network ·을 각각 선언하고 virtual template에 연결한다. 목록을 만들었지만 인터페이스나 서비스에 바인딩하지 않으면 그 정책이 적용되지 않을 수 있다.
보호 범위전통 의 공유 비밀과 일부 보호 필드를 전체 트래픽의 현대적 보호와 동일하게 취급하지 않는다.

14TACACS+: 장비 관리와 명령 인가

장비 관리는 장비 관리자 로그인과 명령별 ·을 구분해 운영하는 용도로 사용된다. 로그인 성공 뒤 어떤 명령을 실행할 수 있는지 서버 정책을 묻는 흐름은 네트워크에 접속할 을 정하는 질문과 다르다.
명령 인증·명령 ·행위 기록은 서로 다른 정책으로 관리할 수 있다.
본문 RFC 8907은 기존 본문 보호를 으로 설명하며 강한 기밀성·무결성 보장을 제공하는 최신 암호 채널처럼 취급하지 않는다. 의 헤더까지 패킷 전체가 강하게 암호화되는 것은 아니다.
헤더·관리망관리망 격리와 보호된 전송 경로, 공유 비밀 관리가 여전히 필요하다.

15중앙 서버 장애와 실패의 구분

오류와 거부Timeout·서버 오류·명시적 인증 거부는 서로 다른 결과다. 장비의 가 어떤 실패에서 다음 방식으로 넘어가는지는 제품 동작에 따라 확인해야 한다.
중앙 거부를 무조건 로컬 계정으로 우회하거나 중앙 장애 때 모든 관리 접속을 잃는 구성 모두 의도와 다를 수 있다.
단계별 기록로그에서는 요청이 나갔는지, 어느 서버가 어떤 결정을 했는지, 가 어떤 권한을 적용했는지, 에 실제 세션이 기록되었는지를 이어 읽는다. 이 기술들은 단순한 “중앙 로그인” 한 기능이 아니라 신원 자료·암호 자격·정책 집행·기록의 결합이다.

학습 확인

이해했는지 확인하기

디렉터리 조회·인증·인가·세션 기록을 구분해 설명할 수 있는가?
실패가 신원 검증·시간·서비스 이름·통신 중 어디서 발생했는지 구분했는가?
중앙 정책이 실제 서비스에 연결되고 적용된 근거가 있는가?