RADIUS와 TACACS+의 AAA 처리 방식은 어떻게 다른가

RADIUS 기본 Access 교환은 인증 자료와 접속 요청 맥락을 함께 받고, 응답에서 서비스 허용·거부와 접속 설정 속성을 전달할 수 있습니다. TACACS+는 인증·인가·회계를 서로 다른 프로토콜 유형으로 구분해 장비의 개별 명령 인가 같은 처리를 설계할 수 있습니다.

RADIUS 회계 규격은 RFC 2866으로 별도 정의되며 TACACS+도 세 기능을 모두 반드시 써야 하는 것은 아닙니다. 전송 보호는 또 다른 축입니다. 최근 RADIUS/1.1과 TACACS+ over TLS 문서를 기본 UDP/TCP 교환과 혼동하지 않습니다. 가상의 장비 사례는 직접 만든 학습 예시입니다.

AAA라는 약어가 같아도 패킷과 판단 단위는 다릅니다

네트워크 장비에 접속하는 이용자를 확인하는 AAA는 Authentication(인증), Authorization(인가), Accounting(회계)을 가리킵니다. RADIUS와 TACACS+는 모두 이 영역에서 쓰일 수 있지만 프로토콜이 요청과 응답을 조직하는 방식은 다릅니다. RADIUS 기본 규격에서 NAS는 Access-Request를 인증 서버에 보내고 Access-Accept, Access-Reject 또는 Access-Challenge를 받습니다. Access-Accept에는 사용자를 연결할 서비스의 구성 정보가 들어갈 수 있습니다. 따라서 ‘RADIUS는 인증만 하고 인가는 하지 않는다’고 단정하면 응답 속성의 역할을 놓칩니다.

TACACS+ RFC 8907은 packet type을 Authentication, Authorization, Accounting으로 분리하고 각 기능을 별도 절에서 다룹니다. 장비 운영에서는 인증된 사용자가 특정 명령을 실행할 수 있는지 매 명령 단위로 인가하는 등 구분된 처리가 가능해집니다. 그렇다고 모든 배포가 AAA 세 기능을 전부 켜야 하는 것은 아닙니다. RFC는 구현이나 배포가 세 가지를 모두 사용할 필요는 없다고 설명합니다. 둘의 차이를 한 단어로 외우기보다 요청·응답이 어느 판단을 담는지, 회계 기록이 어떤 경로로 생성되는지 따져야 합니다.

명령 실행을 요청한 가상 운영자 로그를 풉니다

운영자 유진이 라우터에 로그인해 show route 명령을 실행하려고 한다고 합시다. RADIUS 흐름에서는 NAS가 Access-Request를 보내고 서버의 Access-Accept가 서비스와 접속 설정 속성을 줄 수 있습니다. 하지만 그 패킷 하나만으로 이후의 명령 각각을 별도로 승인하는지까지 알 수는 없습니다. 장비와 서비스 설정을 봐야 합니다. 접속 세션 중간의 명령을 누가 수행했는지 기록하는 회계는 RADIUS 기본 Access 응답과 같다고 부르지 말고, 별도 Accounting 규격과 장비가 생성한 기록을 살펴야 합니다.

같은 상황에서 TACACS+를 사용하면 로그인 인증 교환과 명령별 authorization 요청을 각각 식별해 볼 수 있습니다. 예를 들어 show route는 허용하지만 write memory는 거부하는 정책이면 장비가 해당 명령을 TACACS+ Authorization 요청으로 서버에 질의하는 구성일 수 있습니다. 서버 응답에서 허용 여부와 관련 attribute를 확인하고, 실제 장비의 명령 실행·거부 로그와 대조해야 합니다. TACACS+ Accounting 기록에는 Start, Stop, Update가 있을 수 있지만 이 기능도 배포에서 실제 활성화됐는지 확인해야 합니다. ‘TACACS+라서 모든 명령을 자동으로 기록한다’고 추정하지 마세요.

비교표를 채울 때 AAA와 전송 보호를 따로 봅니다

1. 질문이 사용자 로그인 인증인지, 서비스 접근 속성인지, 명령별 인가인지 표시합니다.
2. RADIUS Access-Request와 Accept/Reject/Challenge의 실제 요청·응답을 확인합니다.
3. TACACS+ packet type과 서버 응답이 authentication·authorization·accounting 중 무엇인지 구분합니다.
4. Accounting이 어느 별도 표준 또는 기능으로 설정됐는지와 실제 생성 기록을 확인합니다.
5. 기본 규격 버전과 RADIUS/1.1 또는 TACACS+ TLS 등 별도 transport profile을 기록합니다.

표준 업데이트 상태도 차이를 읽을 때 중요합니다. RFC 2865는 2000년 RADIUS 기본 규격이며 RFC 9765는 2025년에 RADIUS/TLS 또는 DTLS에서 ALPN으로 RADIUS/1.1을 협상하는 Experimental 프로파일을 정의합니다. 이 문서는 기존 UDP/TCP 동작을 바꾸지 않는다고 명시합니다. RFC 8907의 TACACS+ 기본 문서도 RFC 9887이 2025년에 TLS 1.3 전송 프로파일로 업데이트했습니다. RFC 9887은 Proposed Standard입니다. 이 최신 문서 두 개를 언급하더라도 실제 조직이나 제품이 프로파일을 사용한다고 말하려면 장비 설정과 협상 기록이 필요합니다.

‘RADIUS는 인증만’ 또는 ‘TACACS+는 항상 암호화’라고 외우지 않습니다

첫 번째 오해는 RADIUS의 Access-Accept가 서비스 구성 속성을 전달할 수 있다는 점을 무시하고 인증만 처리한다고 단순화하는 것입니다. 반대 방향의 오해는 모든 authorization을 RADIUS Access 교환 하나가 세밀한 명령 단위로 수행한다고 가정하는 것입니다. 실제 단위는 구현과 설정에 달려 있습니다. 둘째, TACACS+라는 이름만으로 TLS 보호가 적용됐다고 추론하지 마세요. RFC 9887은 TLS 1.3을 쓰는 별도 프로파일이고, 원래 RFC 8907 자체는 보안 전송을 의무화하지 않습니다. 프로토콜의 AAA 구조와 전송 보호 상태는 서로 다른 칸에 기록해야 합니다.

누가 인증했고 누가 명령을 허용했는지 답해 봅니다

회상 연습: 운영자 유진의 로그인은 성공했지만 write memory가 거부됐고, show route는 허용됐습니다. TACACS+에서 확인할 AAA 유형과 추가 기록을 말하세요. 로그인은 Authentication, 명령별 허용 여부는 Authorization으로 나뉘어 처리됐을 수 있습니다. 이후 수행·거부 사실의 회계 기록을 주장하려면 Accounting 기능과 실제 로그가 있는지 확인합니다. 사용한 TLS 프로파일도 별도로 점검해야 합니다. 사례와 질문은 교육용 창작물이며 실제 시험 문항이나 집중 180제 카드 인용이 아닙니다. 상품 구성은 /decks/security#focus-180에서 확인할 수 있습니다.